Another Unreleased Game - Blaze

[Mrs Beanbag]

Originally Posted by keithbugeja

No, it's more like I wasn't clear enough. Let's say you have a typical side-scrolling shoot 'em up (like R-Type), with right-to-left scrolling; for every block (or tile) worth of horizontal hardware scrolling (say 16 pixels), the whole playfield is copied (blitted) and moved 16 pixels to the left, and a new column of tiles is drawn at the rightmost edge of the screen to fill the empty space.

Blitting the entire playfield is completely unnecessary... you just shift the start of screen memory one word to the right and keep on going. As long as you have a little extra Chip RAM to move into, the image just wraps round and round. Remember memory is always linear, the 2 dimensions of the screen are an illusion.

In Blaze, scrolling doesn't happen this way - instead, the screen is composited from tiles each and every frame. Hardware is still used to control the scrolling at the granularity of pixels, but no 'software' scrolling is used, so to speak. The advantage of this method is that the whole playfield could be animated without any penalty in performance. Moreover, since the screen is basically redrawn at each change, one doesn't need to save the portions of background behind software sprites (bobs). The flip side is that the technique is limited in terms of fill-rate, which is why Blaze runs at around 25 Hz.

This sounds like the technique i suggested for converting NES games, since only 2 bitplanes are required there so it may be able to run at 50 fps.

BTW Mr Beanbag redraws the background behind bobs by refreshing from the tile map, it doesn't save the background behind bobs at all. But it only redraws in rectangular regions, not the whole screen.

In a later project, I had experimented with decoupling the pixel scrolling from the rest of the rendering, and running it at 50 Hz. This resulted in silky-smooth scrolling, but sprite movement became very jittery (Think Superfrog). For the player sprite, solving the jitter was just a question of using hardware sprites, which are independent of the background, but for the other sprites, I had no suitable solution.

if the other sprites can also be updated at 50fps, there is no problem. Although Mr Beanbag does experience this problem, because the hardware scrolling has granularity of 1/4 pixel horizontally, and of course bobs are restricted to full pixel motions, so sometimes enemy sprites that are chasing the player can appear to vibrate slightly. But 1/4 pixel scrolling is not possible on OCS anyway.

[keithbugeja]

Originally Posted by Mrs Beanbag

Blitting the entire playfield is completely unnecessary... you just shift the start of screen memory one word to the right and keep on going. As long as you have a little extra Chip RAM to move into, the image just wraps round and round. Remember memory is always linear, the 2 dimensions of the screen are an illusion.

Thanks for your clarifications. How would this work for large maps? If, say, I keep moving screen memory to the right, would I not eventually reach the boundaries of allocated memory, independent of representation?

Originally Posted by Mrs Beanbag

if the other sprites can also be updated at 50fps, there is no problem. Although Mr Beanbag does experience this problem, because the hardware scrolling has granularity of 1/4 pixel horizontally, and of course bobs are restricted to full pixel motions, so sometimes enemy sprites that are chasing the player can appear to vibrate slightly. But 1/4 pixel scrolling is not possible on OCS anyway.

Thanks again for enlightening me! I hadn't the faintest clue that hardware supported a granularity of 1/4 pixel horizontally. So I might be misunderstanding your answer, but the problem I experienced was not due to spatial resolution but disparity in temporal updates. In particular, the player camera logic was running as an ISR at 50 Hz, decoupled from the rendering, which ran at 25 Hz. The ISR also updated the registers that controlled the start of screen memory and per-pixel scrolling; this made up for the slower map-drawing updates, and kept the scrolling running at 50 Hz. The sprites on the other hand updated during map drawing cycles, at 25 Hz, so every other frame they would move with the scrolling background, giving the impression they were somehow vibrating.

Caveat: Only true if memory serves me well.

[NorthWay]

Originally Posted by keithbugeja

Thanks for your clarifications. How would this work for large maps? If, say, I keep moving screen memory to the right, would I not eventually reach the boundaries of allocated memory, independent of representation?

This is harder to explain in words than showing with a bit of thick string/rope and a tin can.

Yes, if you just keep adding +2 to your bitmap address you will eventually worm your way through all memory. Not good.
If your level has a fixed width and does not wrap around then you only need to add "level pixel width times number of bitplanes" to your screen memory allocation. If your level is 2560 pixels wide in 4 bitplanes then that is just 640 bytes extra.
If your level wraps around then you will need an extra screen buffer that you keep building up while you use the push forward technique already discussed. You typically have a screen buffer twice as wide as the display, push through into the second half, swap to your other buffer, repeat, and go back to the other again. All the time you fill in the non-displayed buffer in small chunks to distribute the load.

(The pysical thing about the tin can is to take the string and begin wrapping it around the can from top to bottom, but as I said(wrote) you kinda need to do it in person to use it to explain sliding screenbuffers.)

[Asman]

@keithbugeja
Again thanks a lot for full source. I'm not sure if this source is the newest version, because I noticed differences with executable in adf. Can you confirm. Thank you

When I tried compile the blaze then my executable is about 100kb not 70kb.

@Mrs Beanbag - about redraws the background behind the bobs. How efficient this technique is ?

[keithbugeja]

Originally Posted by NorthWay

This is harder to explain in words than showing with a bit of thick string/rope and a tin can.

Yes, if you just keep adding +2 to your bitmap address you will eventually worm your way through all memory. Not good.
If your level has a fixed width and does not wrap around then you only need to add "level pixel width times number of bitplanes" to your screen memory allocation. If your level is 2560 pixels wide in 4 bitplanes then that is just 640 bytes extra.
If your level wraps around then you will need an extra screen buffer that you keep building up while you use the push forward technique already discussed. You typically have a screen buffer twice as wide as the display, push through into the second half, swap to your other buffer, repeat, and go back to the other again. All the time you fill in the non-displayed buffer in small chunks to distribute the load.

(The pysical thing about the tin can is to take the string and begin wrapping it around the can from top to bottom, but as I said(wrote) you kinda need to do it in person to use it to explain sliding screenbuffers.)

Your explanation was very clear, thanks!

[keithbugeja]

Originally Posted by Asman

@keithbugeja
Again thanks a lot for full source. I'm not sure if this source is the newest version, because I noticed differences with executable in adf. Can you confirm. Thank you.

No, you are right, it's not the same. Still, the demo was just a fork that removed the options screen and added a congratulatory message at the end. Unfortunately, I could not find a copy of the actual demo source, sorry.

[Retro1234]

If you can update a whole screen in a frame without scrolling couldnt you redraw parts of the baciground and have some parallax?

[keithbugeja]

Originally Posted by Boo Boo

If you can update a whole screen in a frame without scrolling couldnt you redraw parts of the baciground and have some parallax?

I actually tried this, but my implementation turned out to be too slow. If I remember correctly, I had tagged map tiles containing some measure of transparency, to render them using a mask. Rendering without a mask causes the background to be clipped against the border of a tile, even if the tile graphics do not cover all its area. Unfortunately, when I tried this out, the frame rate started suffering (no doubt because of my poor implementation), so I simply dropped it.

I recycled most of the code and used it to simulate foreground objects which partially occlude the player.

[Asman]

Originally Posted by keithbugeja

No, you are right, it's not the same. Still, the demo was just a fork that removed the options screen and added a congratulatory message at the end. Unfortunately, I could not find a copy of the actual demo source, sorry.

No problem.


I have question. How this parallax technically should be done ? It required two blits per map tile ?

[Asman]

Originally Posted by clenched

Assembles fine with VASM Devpac compatible mode. Takes the better part of a second on my PC. Also noticed pressing J repeatedly gives great jumping capability.

WinUAE tests:
- Failed to load at all with Kickstart 1.3
- Loaded OK with Kickstart 2 but mildly glitchy graphics
- A1200 looks fine.
- saw this message on 68000 "FATAL CPU CRASH!" a couple of times.

Maybe I'll try Devpac later and see what happens.
Fine looking game.

EDIT: Using Devpac 3.02, Kickstart 1.3, game looks perfect. Kickstart 2.0 still some slight gfx trouble. Neither showed the fatal message this time. Didn't bother with A1200.

About "FATAL CPU CRASH". Try add dc.b 0 just before label Loop_Data
It seems that devpac automatically add it to align Loop_Data: what is good in this case, because in the code is word access to the Loop_Data. I'm not sure If such possibility has vasm in devpac mode.

[clenched]

Originally Posted by Asman

About "FATAL CPU CRASH". Try add dc.b 0 just before label Loop_Data
It seems that devpac automatically add it to align Loop_Data: what is good in this case, because in the code is word access to the Loop_Data. I'm not sure If such possibility has vasm in devpac mode.

Your suggestion worked. Thanks. Ran and jumped around for about three minutes with no crash. I'm still mystified why the game doesn't load with 1.3. Since the game assembles so easily, maybe phx will see this thread and have a look.

[Mrs Beanbag]

Originally Posted by NorthWay

If your level wraps around then you will need an extra screen buffer that you keep building up while you use the push forward technique already discussed. You typically have a screen buffer twice as wide as the display, push through into the second half, swap to your other buffer, repeat, and go back to the other again. All the time you fill in the non-displayed buffer in small chunks to distribute the load.

Ah! Well that's a different kettle of fish! Games like Mario, Sonic &c typically don't have maps that wrap around, but let's consider that problem...

We can still do it with wrap-around scrolling. Because once we have scrolled sideways by the same number of screens as the height of the tiles (making sure we reserved that much extra memory) all one needs to do is copy the bottom row of tiles back up to the top, and carry on from there. This is assuming we are using a copper-assisted wrap around for the vertical scrolling as well.

[Asman]

Originally Posted by clenched

Your suggestion worked. Thanks. Ran and jumped around for about three minutes with no crash. I'm still mystified why the game doesn't load with 1.3. Since the game assembles so easily, maybe phx will see this thread and have a look.

Hm... What config did you use? It works on my side with A500 config, cycle exact, 0.5 MB CHIP and 0.5 MB SLOW, OCS, 68000 with 24 bit addressing. WinUAE 3.2.0 64-bit version.

[clenched]

Originally Posted by Asman

Hm... What config did you use? It works on my side with A500 config, cycle exact, 0.5 MB CHIP and 0.5 MB SLOW, OCS, 68000 with 24 bit addressing. WinUAE 3.2.0 64-bit version.

1 meg OCS CE 32-bit 3.2.0 and just now what you posted. It is probably something simple too. Here is the binary to check.

[Asman]

Originally Posted by clenched

1 meg OCS CE 32-bit 3.2.0 and just now what you posted. It is probably something simple too. Here is the binary to check.

Executable is shorter then my. VASM version uses HUNK_DREL32, my usues HUNK_REL32. So probably HUNK_DREL32 is not supported in kickstart1.3, I guess that must be an option in VASM to generate HUNK_REL32.
Try compile with -kick1hunks and back with result.

[clenched]

That fixed it. Thanks again. I think I'll turn all my debugging work over to you from now on.

[Asman]

@clenched

No problem, If I can then I will help .

[Mrs Beanbag]

Originally Posted by Asman

@Mrs Beanbag - about redraws the background behind the bobs. How efficient this technique is ?

i never benchmarked it or compared it to any other technique, it seemed like the obvious way to write it in the first place to be honest, maintaining a copy of the background seemed like more work for me let alone for the blitter, as well as an extra memory requirement. But it seems to work quite well, i can get quite a lot of fairly large bobs on screen at once without any slowdown.

Not including any CPU time, or time taken to write to blitter registers however, it means only 2 blits per bob (per bitplane) rather than 3 (in the best case - of course when a bob spans more than one tile, it is more blits, but the same total blitted area, i.e. 2 times the bob's area instead of 3 times)

Another way to deal with this issue is to draw all the bobs "behind" the tilemap, as is done in Chuck Rock and other games using that engine. Presumably (i'm guessing) it also maintains a mask as it scrolls on another invisible bitplane, and combines that mask with the bob's mask. That way, to remove the bob we can just blast it off in colour 0 using the same mask again and we don't need to worry about restoring the background at all. But, it does require combining the background mask with the bob's mask in a separate blit, so that is 2 times the bob's area, times the number of bitplanes, plus one additional blit in one bitplane. Also clearing the bob might require more DMA cycles than a straight copy.

It could be possible to do some limited-colour parallax using the above technique though. If the background only uses 2 bitplanes, it might be possible to blit the entire screen every frame, through the foreground mask.

[Muzkat]

That looks incredible.

[Asman]

@Mrs Beanbag
Thanks for explanation.