32 color shmup demo

[Master484]

This is a small demo that I made to see if Blitz could run a 32 color "arcade" bullet rain shmup with 100+ objects on screen.

ADF is in the attachment. Source code is included, you can freely use the code in your own projects.

And this time the graphics too are actually made by me, these objects were taken from a work-in-progress OCS 32 color shooter gfx set, and once the whole set is ready I'll post it to OpenGameArt for everyone to use.

---

Demo Requirements: ECS with 1 MB of RAM

Keys

1 - delete objects
2,3,4,5 - create enemies and bullets

L - fire mega laser

Fire - Shoot lasers (hold down for auto-fire)
Space - Shoot many lasers at once

---

The drawing routines in this demo are optimized for extremely high BOB amounts, or at least I tried to make them so, and below is short explanation on how it works.

Firstly players ship is a 32 pix wide 16 color sprite, using 4 channels. But everything else are BOBs or Tiles, and use 32 colors. Two commands are used : "Block" and "Blit", and everything in the screen is drawn every frame with 2 drawing "passes".

First the whole screen is filled every frame with size 32*32 Tiles. But instead of drawing the tiles, they are "BlockScrolled" from a separate "scroller bitmap" into the main playfield. And the "scroller bitmap" is updated with a new set of tiles at 2 screen intervals, that means when 2 screens have been scrolled. This is the only time when tiles are blitted. On A500 at least you'll notice a short pause in the scroll every 2 screens. In an actual game I think a 6 screen interval or so would be better, but in this demo we use just 2 screens.

The tile filling "BlockScroll" always completely erases everything that was drawn to the game area during the previous frame. And scrolling too is achieved with the Blockscroll; the area which is Blockscrolled from the scroller bitmap gets it Y-position updated by 1 pixel every frame.

And after the Blockscroll is done, other objects are then drawn to the game bitmap, using a simple "Blit" command. Blit is the fastest Blitz drawing command that still offers transparency, but it's rarely used because it can't "save and restore" the background like BBlit does. But in our case we don't need to care about this drawback, thanks to screen being filled with tiles every frame.

The demo also has collisions on place: Bullets and Enemies are checked vs Player, and Player bullets are checked vs Enemies. So the speed at which this runs is close to what it would be in an actual game.

---

So, the whole thing works like Xenon 2, everything is drawn every frame. Basic speed is always 25 FPS, and when screen gets crowded you get 14-17 FPS on average.

But 14 FPS is still very playable, and the drawing system is very resistant to "additional graphics". For example 40 bullets + 20 enemies on screen still remains quite playable.

The biggest benefit of this system is that the "background damage" caused by 100 BOBs is cleaned as fast as the damage of just 1 BOB. Normally doing BG copy-saves and repairs in 32 colors for 100 BOBs would be extremely slow, but here it costs only 1 frame.

So we get a 25 FPS shooter engine, with the a capability to support lots of BOB at a still playable 14-17 FPS frame rate.

Another benefit is that there is no need for "re-draw buffers" or "queues" that are needed for QBlit and BBlit. So we can draw an unlimited number of images every frame, without the fear of running out of Buffer or Queue space. The only limit is the game object collection, which I limited to 1000 active objects at once.

---

So surely one could make a "bullet hell" shooter with Blitz, with full 32 colors. Although a red "14 FPS" warning sticker would be required on the game box.

[Gzegzolka]

Very nice work ^^

[idrougge]

You should spread out background updates evenly across frames. Here's one way to do it:
http://eab.abime.net/showthread.php?t=80646

[Predseda]

I will try it for sure!

[s2325]

nice job

[Lemming880]

Works nice.

[Master484]

You should spread out background updates evenly across frames. Here's one way to do it:
http://eab.abime.net/showthread.php?t=80646

Yes, currently the background scroll rate "lives" too much, I'll try to fix this for the next version.

Also I hope get the Player sprite running at 50 FPS, no matter how slow everything else runs; reading the joystick + doing ShowSprite on the vertical blank interrupt should be able to achieve this.

And then this would be almost like Battle Squadron, which uses Player + Scroll at 50 FPS and enemies at 25 FPS.

Although getting the scroll to 50 FPS in this demo is impossible, thanks to the "draw everything every frame" system; when the background is drawn, all objects too need to be drawn immediately afterwards, and this limits the frame rate to 25 FPS at maximum.

---

But I think SEUCK games too run at 25 FPS at maximum, and quickly drop to 17 FPS or less when action gets too much. Or did they even have 17 FPS as the maximum frame rate, I can't remember? So compared to that, this is looking good: we have the same frame rate as SEUCK, but with 32 colors instead of 8+8 colors, and we are still able to draw a little bit more objects I think.

Who knows, if I have time, maybe I could even turn this engine into "SEUCK on steroids"...32 colors, infinite object amounts on screen, music support, powerups and other goodies, with frame rates comparable to Xenon 2, SEUCK and other "average" Amiga shmups...doesn't sound too bad at all.

[carrion]

impresive demo
I think it's good time to ask which is faster
bitting few big bobs or a lot of small bobs?

[Master484]

impresive demo
I think it's good time to ask which is faster
bitting few big bobs or a lot of small bobs?

Blitting a few big bobs is almost always faster.

For example one 32*32 BOB is faster than four 16*16 BOBs, despite both of them covering the exact same pixel amount on screen.

I think I once made tests with the "BBlit" command, where I counted that 40 % of the command time actually went to the BBlit operation itself, because it saves the background area under the BOB first and also BBlit requires the "Unbuffer" command every frame, which adds even more slowdown. And so only 60 % of the BBlit command time went to the actual drawing process of the image. This was for 16 color BOBs. But I can't remember how I actually got these numbers.

---

But the faster "Blit" command that is used in this demo doesn't have the extra overhead of "BBlit", and so it can draw large amounts of even those small 8*8 bullets.

But still the bigger 32*32 BOBs are faster to draw, if you simply compare the pixel amounts blitted: it takes as many as 16 8*8 bullets to cover the same pixel area than one 32*32 BOB covers. And in this demo you can have exactly ten 32*32 enemies on screen without slowdown. The same pixel amount covered by 8*8 bullets would need 160 bullets, and that would cause huge slowdown, despite the 160 bullet graphics having the same combined pixel amount than those 10 enemies.

[Havie]

Tried it out on a real 1200 (030@40mhz). Pretty impressive but does slow down quite a lot when blitting the big bobs - don't see so much slow down on bullets so if your intention was to create a bullet hell engine - looks a real possibilty.

One thing i have notice through my own efforts is that winuae seems to blit faster than a real Miggy (it may be a setting I have to change in Winuae) i.e. I have a working Doodle Jump engine which seems fast enough when tested through Winuae (and I do limit processor speed etc.) but is slower on real hardware. This is where sprites v bobs comes in...

I found an interesting sprite routine a while back (might have been here?) which might be worth investigating for more speed? It's call bb2vspr and can be found on the Aminet:

http://aminet.net/package/dev/basic/BlitzLstApr98

Just download the Blitzlist and unzip.

Keep up the good work!!!

[idrougge]

Originally Posted by Master484

For example one 32*32 BOB is faster than four 16*16 BOBs, despite both of them covering the exact same pixel amount on screen.

A 16*16 bob is a 32*16 bob in 15 out of 16 positions.
A 32*32 bob is a 48*32 bob in 15 out of 16 positions.

[Raislin77it]

Originally Posted by idrougge

A 16*16 bob is a 32*16 bob in 15 out of 16 positions.
A 32*32 bob is a 48*32 bob in 15 out of 16 positions.

???

ah yes, the "shift" value!
this explain the difference from one 32x32 pxl bob and 4 16x16 pxl bob

[Anakirob]

I don't know if you're considering doing this already, but I would consider drawing extra large stationary enemies (such as bosses) to the backdrop image. I think SWIV did this. Only problem I can think of is it will most likely require some additional game logic. But I imagine you've still got pleanty of CPU time, it's just using the Amiga's graphics chipset that's pushing the envelope.

[Master484]

Tried it out on a real 1200 (030@40mhz). Pretty impressive but does slow down quite a lot when blitting the big bobs - don't see so much slow down on bullets so if your intention was to create a bullet hell engine - looks a real possibilty.

Most likely on such fast A1200 the speed started at 50 FPS and then sharply dropped to 25 FPS when a few of the bigger enemies were drawn, I noticed this happening on the emulator when testing it on a A1200 config.

A frame rate drop from 50 FPS to 25 FPS always looks very bad, but a drop from 25 FPS to 17 FPS isn't so noticeable. On A500 config it starts from 25 FPS, and so the slowdown doesn't look so bad.

Currently the FPS system in the demo is done in the wrong way, causing overspeed (50 FPS) on Amigas that are faster than the standard A500, and then slowing down when the blitting starts.

I'll try to fix this for this next version, so that the frame rate would stay at a stable 25/17 FPS on all Amigas.

I already got the Player sprite to run at 50 FPS at all times by updating it from the VBlank interrupt. But I'll check out that Aminet bb2vspr code to see if it contains something useful.

I don't know if you're considering doing this already, but I would consider drawing extra large stationary enemies (such as bosses) to the backdrop image. I think SWIV did this. Only problem I can think of is it will most likely require some additional game logic. But I imagine you've still got pleanty of CPU time, it's just using the Amiga's graphics chipset that's pushing the envelope.

Yes, this technique will surely be used if I start turning this demo into an actual game. And doing this is very simple, thanks to the flexible game object system, and the shared palette between the background and objects, and the Blitz "Block" command.

[Master484]

I just uploaded an improved version, which has been added to the attachments of the first post.

Changes in version 2:

- Player sprite now always moves at 50 FPS.
- 15 % better BOB drawing speed and more consistent frame rate.
- added info texts to screen panel area, which show current Object amount (text updates every 4th seconds)
- 2 crash bugs fixed ( such as "move to up right corner and press space" )

---

Drawing speed is now much better. On A500 we can have 13 enemies or 29 bullets at 25 FPS.

And Player sprite is now updated from the VBlank interrupt, and it's always drawn at 50 FPS, even with 100+ objects on screen.

On A1200 speed is either 17 enemies and an amazing 50 bullets at 25 FPS. I guess A1200 is so good at drawing the bullets because the collision detection routines are so much faster thanks to the 2x faster CPU.

Also collisions and background draw is now done during frame 1, and object draw + bitmap "Show" is done during frame 2. This allowed 15 % more drawing power.

And speaking about the collisions, I currently use the standard collsion routine command of Blitz ( RectsHit ), which is good, but not the fastest possible way...so I think later I'll add the custom routines from my Megaman X project, and collision check speed should improve about 10%-20% from what it is now.

---

So, this looks quite good, a 32 color shmup is certainly possible with this techinque. And if everything would be drawn in 16 color mode instead of 32 colors, then we could draw maybe 15 % - 20 % more, and still have a separate 16 color sprite palette for 16 "extra" colors. I think I'll test this too, could even run at 50 FPS, at least on A1200.

[Havie]

This is looking better and working better on my real 1200. impressed with the player being independent of everything else and never slowing down - will have a look at what you did to achieve this.

Keep it coming!

[Master484]

Good to hear that it works fine on a real A1200.

The Player always staying at 50 FPS and never slowing down is achieved by a simple interrupt code, that automatically activates every time when the display beam has travelled the whole screen, and the "Vertical Blank" event takes place, at which point the interrupt code is executed. This interrupt code simply updates the sprite coordinates, and this always happens at 50 FPS, because the Amiga display itself always updates at 50 FPS.

However, this trick only works for sprites; if we tried to draw the BOBs at the interrupt, that would take too much time.

This is the first time when I even use the interrupt commands of Blitz, and I'm amazed how easy and simple they are, doing advanced stuff like this is as easy as Gosub + Return, and it even works on real hardware. Lots of new possibilities have opened here.

I also already have a 16 color version done, and as expected it's 20% faster than the 32 color version. I'll release it soon, maybe next weekend.

[Anakirob]

16 colour version should be much faster. I recall modifying the "Monsters in the Dungeon" Blitz example to be a real-time joystick controlled game which used 4 bitplanes ( +4 bitplane background: ) and had 128 16 colour 8x8 "monsters" chasing the player with no slowdown on an A1200. Like you I was just using the regular blit command and clearing the playfield each frame so I expect you'll get similar results.

But I have a couple of ideas you might like to try. The first is to get large enemies moving and shooting lots of bullets without framerate drops. You could use a shape with transparency when the enemy is doing normal movement. Then it could stop moving for a moment (at a point where it lines up with the block commands 16 pixel requirement) and unleash a hail of bullets while being rendered with the background layer, before waiting until around half the bullets have left the screen before moving again.

And the second is if you were to make a two playfield (4+4) game, to constantly change the background pallet with the copper. I found I was able to modify 3 AGA colours per line (I think I recall reading that the max is 4), so if you have an entirely new 16 colour pallete every 16 lines then you've potentially got a few more colours available than you would using a single playfield 8 bitplane display.

[Havie]

Originally Posted by Anakirob

16 colour version should be much faster. I recall modifying the "Monsters in the Dungeon" Blitz example to be a real-time joystick controlled game which used 4 bitplanes ( +4 bitplane background: ) and had 128 16 colour 8x8 "monsters" chasing the player with no slowdown on an A1200. Like you I was just using the regular blit command and clearing the playfield each frame so I expect you'll get similar results.

I did something similar - is this a process we all go through when learning? Although I also experimented with using bobs instread of ascii characters to create a Gauntlet like effect (worked but slow and didn't go very far).

[Anakirob]

Originally Posted by Havie

I did something similar - is this a process we all go through when learning? Although I also experimented with using bobs instread of ascii characters to create a Gauntlet like effect (worked but slow and didn't go very far).

Indeed, I did something very similar. And actually had quite a nice little engine, which has sadly been lost many years ago. Anyway, My notes on experimenting with the Monsters code. Note that I was using a stock A1200 at the time.

Initially quite slow

MASSIVE speed improvement by replacing many small Print commands with big NPrint strings. A realtime ascii rouge like on an 8-bit screen could be done at around 12.5 fps on a stock A1200 and maybe a consistent 25 fps with fast memory, possibly only needing to slow down to load or generate more data. I had to set the refresh rate to greater than four frames (I'm a bit vague, but I think 5-8 should be stable but slow) to make the game playable anyway.

Had to change the AI and rendering routines back to how I found them to adapt the code to individual Blits. But I also switched to Blitz mode. I chose an 8 bitplane display which was a different 256 colours for the top and bottom and 4 bitplane + 4 bitplane dual playfield in the middle which was done manually with copper pallete changes and BitplanesBitmap. I didn't want any black lines on my display and had graphics that blended the edges of the panel with the playfield. (Sorry, that Amiga is long gone and I don't have any examples, But I think some of the code was a bonus game in a WIP AHX music disk called Blue Moon I was working on in 2007 I think, which could possibly be floating around on some polish sceners hard drive: )

I used relatively small maps with about 16-64 monsters. I don't know what refresh rate I was getting, but it was fast enough for me to want to make the main loop wait for 4 VWaits, as the mosters still moved in 8 pixel jumps, and therefore quite fast. Although I had a 16 pixel high 8-bitplane scroller at the bottom of the screen going at 25 fps.

I may have made one or two tweaks to the monster AI, but it was pretty much unchanged. But there were a few changes to make Blitting more efficient or even possible. Especially the walls and holes which could be done with Block's and only needed to be done once. When a monster or the player twas over a hole it would just clear the hole for me automatically. I just had to update the string holding the map data in memory when I removed the monster.

Another thing I did which could be useful for this game (the 32 colour shooter) was use the QAmiga command to load level data, which I did every time the player left the edge of the screen. Which I found I could do without missing a beat, although I did have 4 whole frames to load around 40 ascii strings from disk (developed on HD, but tested with about 50/50 success on floppy) and switch back to Blitz mode before the next screen update. Personally I'd like to see more games that take a SWIV style approach to the concept of levels.

Also maybe consider capping your framerate at the lowest acceptable setting to avoid slowdown, I'd rather play at 17fps with no slowdowns than 25 fps if it missed even the occasional frame.

(as you may have guessed I was planning an Egyptian themed realtime rogue like where an unarmed archaeologist had to navigate his way to the burial chamber while avoiding an army of mummies and traps (holes), often using the former to clear the latter. I kinda lost interest about half-way though when I began work on Blue Moon (ECS Multitasking, but I'm not sure how a plain A600 would handle it) and then sadly lost the machine with the data)