Progress on Action RPG (Cycle 73 HMOVEs)
Jun. 13th, 2009 08:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
owsf2000With my desire to get more enemies on the screen at one time without resorting to necessary flicker, I started work on a horizontal positioning routine that can be used during the visible screen to reuse one of the 2 hardware sprites in the atari 2600. In essence, this should allow me to build a kernel that will allow up to 4 non-blinking objects/monsters on the screen at one time with a minor trade-off. Three of the objects will be bounded to a vertical section of the screen and won't cross each other's scanlines. The fourth can roam freely and will flicker with global monsters if necessary.
This is how it will look in code mind you. To the player it may not look so clear cut as the monsters themselves will be able to swap themselves, when conditions are correct, with the free roaming sprite in hardware and essentially "become" the new free roaming sprite. Naturally the main condition is that the current free roaming sprite must be entirely in that monster's region to be swapped. As far as the player is concerned, nothing unusual will be happening unless a global monster is also on the screen and flickering with the free roaming sprite. At which point the player will notice a shift in which objects are flickering as they exchange places with the free roaming sprite.
Clear as mud? Awesome.
Anyway, repositioning hardware sprites during the visible screen normally result in ugly black bars along the left side of the screen. This is due to the repositioning command "HMOVE" which is normally done at the start of a new scanline. There's no way to cover these up as they get displayed on top of all other sprites (it's more complicated than that but this gives the general idea.) so the most you can usually do is disguise them by leaving the lefthand of the screen entirely black and unused or try to integrate the look of it into your display like some companies did back in the day. Some Activision games for instance simply called HMOVE every couple of scanlines whether it was needed or not, resulting in an "black comb" effect on the left side of the screen.
There is, however, a way to remove them entirely. You simply do the HMOVE command at the end of a scanline instead of first thing in a scanline. The problem with this is that the actual behaviour of the HMOVE changes by doing this. Instead of moving your sprites by -7 to +8 pixels from it's current position, it'll move it from -15 to 0 pixels! IE: lefthand movement only! This means you need to write yourself a new positioning routine AND write a line of code that will reliably trigger the HMOVE on cycle 73 of a scanline. And that's what I've finally pulled off. :)
Not the first to do this. Homebrew authors for the 2600 figured it out years ago, and that's where I got the idea to write it for myself. But it's difficult to write it from scratch since horizontal positioning on the atari 2600 is probably one of the most complex 'basic' things you need to be able to do. It didn't help me much that people count cycles on the 2600 in different ways as well, so it was an exercise in itself to try to find out exactly what they meant by "triggering hmove on cycle 73" ... "so the command has to start on cycle 73 or end on cycle 73, or right before 73, and do I start counting at 'cycle 0' or 'cycle 1'" etc etc.
For the record, it has to end on cycle 73, starting your count at cycle 0. So if the first opcode in the scanline took 3 cpu cycles to complete, it would END on cycle 2. (eating up cycles 0, 1, and 2 to carry out it's 3-cycle instruction) cycle 3 is where the next opcode would start. So the HMOVE would have to start on cycle 71 in order to end on time on cycle 73. The HMOVE command takes exactly 3 cycles to complete so would eat up cycles 71, 72, and 73.
Have I bored you to tears yet? Don't worry, I'll learn/remember how to hide things behind cuts one day.
Still a lot of planning to do on the actual playfield although I'm making some progress.
This is how it will look in code mind you. To the player it may not look so clear cut as the monsters themselves will be able to swap themselves, when conditions are correct, with the free roaming sprite in hardware and essentially "become" the new free roaming sprite. Naturally the main condition is that the current free roaming sprite must be entirely in that monster's region to be swapped. As far as the player is concerned, nothing unusual will be happening unless a global monster is also on the screen and flickering with the free roaming sprite. At which point the player will notice a shift in which objects are flickering as they exchange places with the free roaming sprite.
Clear as mud? Awesome.
Anyway, repositioning hardware sprites during the visible screen normally result in ugly black bars along the left side of the screen. This is due to the repositioning command "HMOVE" which is normally done at the start of a new scanline. There's no way to cover these up as they get displayed on top of all other sprites (it's more complicated than that but this gives the general idea.) so the most you can usually do is disguise them by leaving the lefthand of the screen entirely black and unused or try to integrate the look of it into your display like some companies did back in the day. Some Activision games for instance simply called HMOVE every couple of scanlines whether it was needed or not, resulting in an "black comb" effect on the left side of the screen.
There is, however, a way to remove them entirely. You simply do the HMOVE command at the end of a scanline instead of first thing in a scanline. The problem with this is that the actual behaviour of the HMOVE changes by doing this. Instead of moving your sprites by -7 to +8 pixels from it's current position, it'll move it from -15 to 0 pixels! IE: lefthand movement only! This means you need to write yourself a new positioning routine AND write a line of code that will reliably trigger the HMOVE on cycle 73 of a scanline. And that's what I've finally pulled off. :)
Not the first to do this. Homebrew authors for the 2600 figured it out years ago, and that's where I got the idea to write it for myself. But it's difficult to write it from scratch since horizontal positioning on the atari 2600 is probably one of the most complex 'basic' things you need to be able to do. It didn't help me much that people count cycles on the 2600 in different ways as well, so it was an exercise in itself to try to find out exactly what they meant by "triggering hmove on cycle 73" ... "so the command has to start on cycle 73 or end on cycle 73, or right before 73, and do I start counting at 'cycle 0' or 'cycle 1'" etc etc.
For the record, it has to end on cycle 73, starting your count at cycle 0. So if the first opcode in the scanline took 3 cpu cycles to complete, it would END on cycle 2. (eating up cycles 0, 1, and 2 to carry out it's 3-cycle instruction) cycle 3 is where the next opcode would start. So the HMOVE would have to start on cycle 71 in order to end on time on cycle 73. The HMOVE command takes exactly 3 cycles to complete so would eat up cycles 71, 72, and 73.
Have I bored you to tears yet? Don't worry, I'll learn/remember how to hide things behind cuts one day.
Still a lot of planning to do on the actual playfield although I'm making some progress.
