The Southsider

Hi there!

 

That's funny that you post your update today - because just this morning, I tried the MSX version of Juno First.

Oh does it suck!

 

BTW:

Perform an HMOVE on every line -> not enough space kernel cycles.

Actually it's just required on the lines where the scrolling is displayed, no?

 

Greetings,

Manuel

Perform an HMOVE on every line -> not enough space kernel cycles.

Actually it's just required on the lines where the scrolling is displayed, no?

 

Yes you are right of course, though there are still not enough spare cycles (as it would require HMCLRs).

 

Chris

Nice work! The HMOVE lines don't bother me, personally. I usually just think of them as another identifying characteristic of 2600 games.

RE: HMOVE lines

 

One more possibility: Since you don't need to put the HMOVE right after the repositioning, you could optionally wait a scanline to do the HMOVE if the line happens to occur on the same scanline.

 

If this helps, I think that an HMOVE can be done from cycle 75 to cycle 6 and still work as expected.

If this helps, I think that an HMOVE can be done from cycle 75 to cycle 6 and still work as expected.

 

After a write to HMOVE, the system takes a certain amount of time to output the necessary pulses to the horizontal counters. This time is 1 1/3 cycles per pulse, plus about 2-3 more cycles IIRC. Note that (1) the number of pulses is the 4 MSB's of the movement register, XOR'ed with $8, (2) all pulses must complete before the end of horizontal blanking, and (3) all pulses for a sprite must complete before its horizontal positioning register is changed.

The game looks great. I'd like to see you attempt some sort of particle effects on explosions next.

 

I would wait until the tail end of development to try to get rid of the HMOVE lines. It just seems like a final touch, not a showstopper.

The game looks great. I'd like to see you attempt some sort of particle effects on explosions next.

 

I would wait until the tail end of development to try to get rid of the HMOVE lines. It just seems like a final touch, not a showstopper.

This requires kernel mods, which are usually quite difficult to do when cycles are already limited. I'd vote for doing it sooner rather than later, since programmers rarely want to mess with the kernel once the game is nearly done.

RE: HMOVE lines

One more possibility: Since you don't need to put the HMOVE right after the repositioning, you could optionally wait a scanline to do the HMOVE if the line happens to occur on the same scanline.

If this helps, I think that an HMOVE can be done from cycle 75 to cycle 6 and still work as expected.

 

Thanks for the suggestion. The repositioning lines are already moved dynamically so that they don't happen on the same scanline as a gridline. It shouldn't be too difficult to do the same with the HMOVEs.

 

After a write to HMOVE, the system takes a certain amount of time to output the necessary pulses to the horizontal counters. This time is 1 1/3 cycles per pulse, plus about 2-3 more cycles IIRC. Note that (1) the number of pulses is the 4 MSB's of the movement register, XOR'ed with $8, (2) all pulses must complete before the end of horizontal blanking, and (3) all pulses for a sprite must complete before its horizontal positioning register is changed.

 

Thanks for the technical explanation. However, I have always wondered why the HMOVEs appear as a small black line on the screen, rather than simply happening invisibly in the background?

 

The game looks great. I'd like to see you attempt some sort of particle effects on explosions next.

I would wait until the tail end of development to try to get rid of the HMOVE lines. It just seems like a final touch, not a showstopper.

This requires kernel mods, which are usually quite difficult to do when cycles are already limited. I'd vote for doing it sooner rather than later, since programmers rarely want to mess with the kernel once the game is nearly done.

 

I have to agree with batari here - the kernel is very difficult to tweak later in the development process. I find that I quickly forget the assumptions that were made during the kernel coding.

 

Chris

Thanks for the technical explanation. However, I have always wondered why the HMOVEs appear as a small black line on the screen, rather than simply happening invisibly in the background?

 

Feeding pulses into the horizontal counter causes objects to move left. Except on late-model Juniors, where feeding pulses during the displayed part of the screen will cause counts to be dropped, it's not possible to move objects rightward by feeding pulses into the count circuit.

 

To allow for rightward movement of objects, the 2600 extends horizontal blanking by 8 pixels following an HMOVE. This causes the counters to receive 8 fewer pulses than they would otherwise, moving objects 8 pixels right. If you specify no motion, what happens is that the pulser circuit feeds in 8 pulses (shoving the object 8 pixels left) but the delayed end of HBLANK causes what would be the first 8 pulses to be skipped. This is why a cycle 74 HMOVE works as it does: the latch that indicates whether to delay the end of HBLANK is reset at the end of each scan line, so it will be immediately reset following a cycle-74 HMOVE. Since the latch doesn't get set, objects get placed 8 pixels left of where they normally would.

The game looks great. I'd like to see you attempt some sort of particle effects on explosions next.

 

I would wait until the tail end of development to try to get rid of the HMOVE lines. It just seems like a final touch, not a showstopper.

This requires kernel mods, which are usually quite difficult to do when cycles are already limited. I'd vote for doing it sooner rather than later, since programmers rarely want to mess with the kernel once the game is nearly done.

 

I'm not talking about doing it after the game is completely coded.

 

I meant that it should be a lower priority, but done before the kernel is completed. In other words, get everything else done in the kernel you want to do, and then see if it's even feasible at that point to get rid of HMOVE lines. You don't want to remove the HMOVE lines and realize that you've just prevented yourself from, let's say, having the enemies extend to the left side of the screen or some other severe limitation. Doesn't seem worth the tradeoff to me.

I meant that it should be a lower priority, but done before the kernel is completed. In other words, get everything else done in the kernel you want to do, and then see if it's even feasible at that point to get rid of HMOVE lines. You don't want to remove the HMOVE lines and realize that you've just prevented yourself from, let's say, having the enemies extend to the left side of the screen or some other severe limitation. Doesn't seem worth the tradeoff to me.

 

That seems fair, though it should be noted that priority does not imply coding sequence. I find it can be helpful to code first the parts of a subkernel whose timing is most fixed even if they might be omitted (e.g. "If I include a colored border, I'll need 5 cycles at this spot on the line). Coding such things early on helps to make clear the constraints the rest of the subkernel has to meet, and will thus help clarify what will be possible.

 

Further, it's important to be willing to tear up and redo subkernels a few times. Archive the old ones in case the new ones don't work (or aren't any better), but unless a subkernel does everything you could want it to do, don't be afraid to try some different approaches. Even one that aren't quite suitable for the task at hand may be a useful addition to your tool belt.