English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. Blitz Basic

 
 
Thread Tools
Old 04 February 2017, 16:46   #1
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 281
32 color shmup demo



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.
Attached Thumbnails
Click image for larger version

Name:	BulletRainV3shot.png
Views:	446
Size:	6.8 KB
ID:	52059   Click image for larger version

Name:	Bullet_Hell_demoV5.png
Views:	382
Size:	11.4 KB
ID:	52313   Click image for larger version

Name:	AGADualPlayfieldShooter.png
Views:	547
Size:	23.4 KB
ID:	52668  
Attached Files
File Type: zip BulletRainV3.zip (49.5 KB, 44 views)
File Type: zip BulletRainV6.zip (130.1 KB, 55 views)
File Type: zip AGADualPlayfieldShmup.zip (135.8 KB, 42 views)

Last edited by Master484; 31 March 2017 at 15:22. Reason: added AGA demo version
Master484 is offline  
AdSense AdSense  
Old 04 February 2017, 17:25   #2
Gzegzolka
Registered User

 
Join Date: Feb 2014
Location: Warszawa / Polska
Posts: 997
Very nice work ^^
Gzegzolka is offline  
Old 04 February 2017, 21:26   #3
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,045
You should spread out background updates evenly across frames. Here's one way to do it:
http://eab.abime.net/showthread.php?t=80646
idrougge is offline  
Old 04 February 2017, 23:17   #4
Predseda
Puttymoon inhabitant
Predseda's Avatar
 
Join Date: Mar 2007
Location: The City of Townsville
Age: 39
Posts: 4,484
I will try it for sure!
Predseda is offline  
Old 04 February 2017, 23:47   #5
s2325
Zone Friend

s2325's Avatar
 
Join Date: Jun 2006
Location: Gargore
Age: 37
Posts: 17,724
nice job
s2325 is offline  
Old 05 February 2017, 00:38   #6
Lemming880
Registered User

Lemming880's Avatar
 
Join Date: Nov 2014
Location: NL
Posts: 111
Works nice.
Lemming880 is offline  
Old 05 February 2017, 10:46   #7
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 281
Quote:
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.
Master484 is offline  
Old 05 February 2017, 16:29   #8
carrion
Registered User

carrion's Avatar
 
Join Date: Dec 2016
Location: Warsaw area
Posts: 50
impresive demo
I think it's good time to ask which is faster
bitting few big bobs or a lot of small bobs?
carrion is offline  
Old 05 February 2017, 19:49   #9
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 281
Quote:
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.

Last edited by Master484; 05 February 2017 at 19:56.
Master484 is offline  
Old 05 February 2017, 20:13   #10
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 261
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!!!

Last edited by Havie; 05 February 2017 at 20:34. Reason: Muppet typos!
Havie is offline  
Old 05 February 2017, 23:11   #11
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,045
Quote:
Originally Posted by Master484 View Post
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.
idrougge is offline  
Old 06 February 2017, 01:41   #12
Raislin77it
Zone Friend
Raislin77it's Avatar
 
Join Date: Jan 2005
Location: italy
Age: 40
Posts: 219
Quote:
Originally Posted by idrougge View Post
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
Raislin77it is offline  
Old 06 February 2017, 02:58   #13
Anakirob
Unregistered User
Anakirob's Avatar
 
Join Date: Nov 2005
Location: Tasmania
Age: 35
Posts: 858
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.
Anakirob is offline  
Old 06 February 2017, 10:40   #14
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 281
Quote:
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.

Quote:
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 is offline  
Old 07 February 2017, 14:01   #15
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 281
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.
Master484 is offline  
Old 11 February 2017, 19:30   #16
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 261
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!
Havie is offline  
Old 12 February 2017, 11:32   #17
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 281
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.
Master484 is offline  
Old 14 February 2017, 03:53   #18
Anakirob
Unregistered User
Anakirob's Avatar
 
Join Date: Nov 2005
Location: Tasmania
Age: 35
Posts: 858
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.
Anakirob is offline  
Old 14 February 2017, 09:22   #19
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 261
Quote:
Originally Posted by Anakirob View Post
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).
Havie is offline  
Old 15 February 2017, 04:53   #20
Anakirob
Unregistered User
Anakirob's Avatar
 
Join Date: Nov 2005
Location: Tasmania
Age: 35
Posts: 858
Quote:
Originally Posted by Havie View Post
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)

Last edited by Anakirob; 15 February 2017 at 05:19.
Anakirob is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Color Saturation and Color Tint/Hue Retro-Nerd support.WinUAE 19 28 August 2017 10:06
Printing in color with WinUAE on color laser source support.Apps 7 14 April 2013 01:32
ISO true color to 256 color algorithm Lord Riton Coders. General 19 15 April 2011 18:49
New ShMUp, help required Marcuz project.Amiga Game Factory 3 28 June 2007 10:49
Cloudphobia (shmup) Dastardly Retrogaming General Discussion 0 07 November 2003 17:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:28.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.37143 seconds with 13 queries