Writing a game sprite driver

[phx]

Originally Posted by Samurai_Crow

Sprites 3, 5, and 7 must be kept blank, otherwise they will act as the most significant bits of the attached sprites.

You just have to make sure they don't overlap. Otherwise you can use all 8 sprites with 6 color reigsters (instead of 12).

[malko]

Just discovered this thread and enjoyed reading it.
You were not starting from scratch but what such a great progress you made !!!
Finally, coding is like bicycle (once learned you never forget it)

[mcgeezer]

Originally Posted by malko

Just discovered this thread and enjoyed reading it.
You were not starting from scratch but what such a great progress you made !!!
Finally, coding is like bicycle (once learned you never forget it)

Thanks

Coding was done entirely from scratch. Gfx is from the arcade though.

Quick update to say the game over sequence is now sorted and most of bomb jack’s physics are in place - still bugs though so will do a video once sorted.

[mcgeezer]

OK so decent update this one as I now have a very crude playable game of Bomb Jack working.

Have managed to get Bomb Jack's physics working quite well, even have the modifiers (push up on the joystick for more lift and down for faster fall) working to a degree.

What I'm pleased most about here is the end sequence as it really was the most difficult to get going... not so much the GAME OVER sequence or Jack's death sequence, it was more about gluing the two of them together.

Apologies as this one has no audio, my next update will have and hopefully a good run through of levels 1-5 working. It's really about play testing what I have now and ironing out odd bugs here and there.

After that it will be on to the enemies so in between a bit of coding I've been learning a fair bit of trigonometry - amazing what I didn't learn at school.

Anyone who wants to help play test for me to identify bugs please drop me a PM.

Here's the video - Enjoy.

[ Show youtube player ]

[mcgeezer]

OK, another update here - mainly as promised from my last post with a run through of the first levels but with the great tunes added from @saimon69.

Quite a few fixed bugs too.
Fixed all the bombs being redrawn after losing a life
Fixed lots of Jack's physics issues
Fixed annoying issue where bomb collection would get out of sync
Fixed issue with Jack death sequence
Fixed issue with Game Over sequence

Still lots of small GFX issues to fix

There are two major optimisations I plan for the next couple of weeks that require what I would call a lot of core changes to the code - in other words they are tricky.

The first is the Blitter plot routine is slow, it does 5 blits per sprite. If I adjust the display modulo of everything I can get away with just one Blit per sprite which would be a major improvement. Doing this though may have memory implications as I need to keep 5 copies of the sprite masks in memory and at the moment memory is way low - I need to squeeze this into 0.5Mb of Chip Ram.

The second is the hardware sprites. In game I don't use any hardware sprites, however they are really going to come in handy because after I tried the game on my real A500 it became obvious that I hadn't been using Cycle exact timing in emulation.... in other words... when I had 8 enemies on or more I was getting lots of slow down on real A500 hardware.

Thew video here is with Cycle exact on... emulating closer to what is the real hardware. Due to memory constraints it is 1MB Chip, and 0.5Mb Fast in development mode.

There won't be an update for a good few days as I have some important stuff coming up... but hey ho... this is life.

As always... enjoy the vid.

[ Show youtube player ]

P.S. The game is brutally hard, it's stupid that I can't even pass level 5 of my own game hahahaha

[alpine9000]

A middle ground if you use interleaved bitplanes is still do one blit per plane (only one mask needed), but a single blit to restore (or clear) the background (no mask need).

But yeah, if you can spare the chip ram, single interleaved blits are a big performance gain.

[mcgeezer]

Originally Posted by alpine9000

But yeah, if you can spare the chip ram, single interleaved blits are a big performance gain.

I wonder how Andrew Braybrook was able to reset the mask pointers during mid blit. I might take a look in his code before i make my changes.

[alpine9000]

Originally Posted by mcgeezer

I wonder how Andrew Braybrook was able to reset the mask pointers during mid blit. I might take a look in his code before i make my changes.

Got any links to this?

[mcgeezer]

Originally Posted by alpine9000

Got any links to this?

Apologies i must have misread his blog.

Here is what he wrote...

In order to use the blitter most efficiently for plotting objects on screen in one 'blit', we had to supply mask data for each bit plane, which would necessarily be identical to the other bit plane masks. Otherwise you have to reset the data pointers to the one supplied mask for each of the 5 bit planes, so you had to do 5 consecutive blits. That was inefficient because you had to wait for the blitter to finish each bit plane before starting the next, whereas if you blit all 5 bit planes in one go then you can be preparing the next object's plotting data while the blitter does its job. So it was the old fight of space versus time.

Boooooo

[alpine9000]

Originally Posted by mcgeezer

Apologies i must have misread his blog.

Here is what he wrote...

In order to use the blitter most efficiently for plotting objects on screen in one 'blit', we had to supply mask data for each bit plane, which would necessarily be identical to the other bit plane masks. Otherwise you have to reset the data pointers to the one supplied mask for each of the 5 bit planes, so you had to do 5 consecutive blits. That was inefficient because you had to wait for the blitter to finish each bit plane before starting the next, whereas if you blit all 5 bit planes in one go then you can be preparing the next object's plotting data while the blitter does its job. So it was the old fight of space versus time.

Boooooo

Yeah, and triple buffering is another one of those space versus time conundrums.

[mcgeezer]

Originally Posted by alpine9000

Yeah, and triple buffering is another one of those space versus time conundrums.

Yeah, i do triple buffering already and simplifies things alot.

Actually, i use quad buffering because i hold another copy of background before my bomb sprites are placed. I could save memory there by only restoring behind the bomb because they dont move. Would save around 30k. Using the hardware sprites is going to save another 16k of collision memory. Plenty of efficiencies still to be made.

[mcgeezer]

I haven't had a great deal of time to code over the last few days.

However, I did manage to get some time so I've knocked up the firebomb bonus screen.

Here's the video, not really that much technically to say about it really. Was very straight forward and I opted to use tiles to draw the whole thing.

Middle screen where the text is uses 3 bit planes, other 2 bit planes are used for text colours.

[ Show youtube player ]

P.S. Not sure why the video and audio are out of sync.

[Tigerskunk]

Can only say the same thing as others had said in this thread: amazing progress.

[mcgeezer]

Well, despite trying pretty damn hard I'm going to have to make the initial release of the game requiring 1Mb ram (0.5 Chip + 0.5 Fast).

I simply can't fit all the required assets into ram in one go. If I create a file or track loader I can probably manage it but even then it will be tricky and would incurr load times (mind you, I could do the load time when the little end of round sequence plays).

At the moment with all the samples, music, assets game code in I have about 120Kb of Chip ram remaining. The executable builds (with compressed assets to 222Kb).

The problem is is that I wanted to add a nice title screen so that will bumb things up a bit and use up that 120Kb chip.

I'm disappointed but nothing I can do in the short term.

[Tigerskunk]

Well, 512k chip+ 512 trapdoor RAM is kind of the basic Amiga configuration, so don't worry. It's even standard on UAE if you choose the Amiga 500 I believe.

It would be different though, if you needed real fast RAM or a faster CPU for the game to run.

[mcgeezer]

Originally Posted by Steril707

Well, 512k chip+ 512 trapdoor RAM is kind of the basic Amiga configuration, so don't worry. It's even standard on UAE if you choose the Amiga 500 I believe.

It would be different though, if you needed real fast RAM or a faster CPU for the game to run.

Yeah thanks, the target is for my Amiga A500 with 0.5Mb trap door ram expansion.... so I take it all I have in my Amiga is fake fast right?

[Samurai_Crow]

Originally Posted by mcgeezer

Yeah thanks, the target is for my Amiga A500 with 0.5Mb trap door ram expansion.... so I take it all I have in my Amiga is fake fast right?

Yes. The trapdoor memory is called "ranger" memory because it is as slow as Chip RAM.

[phx]

Somewhere I have seen that you used fixed addresses for all your graphics, screens and buffers. Maybe you can implement a small memory management into the game, so you can allocate and deallocate Chip RAM. For example, you won't need all the buffers for BOBs, when displaying the title screen.

Originally Posted by mcgeezer

0.5Mb trap door ram expansion.... so I take it all I have in my Amiga is fake fast right?

Depends. When you have a newer, 1MB-capable Agnus, you could also add the trap door as Chip RAM. In any case, all memory will be as slow as Chip RAM.

[mcgeezer]

Originally Posted by phx

Somewhere I have seen that you used fixed addresses for all your graphics, screens and buffers. Maybe you can implement a small memory management into the game, so you can allocate and deallocate Chip RAM. For example, you won't need all the buffers for BOBs, when displaying the title screen.

I could try that but it would still be very tight.

Here's my current memory map.

;
; -= Memory Map =-
;   
; +-----------------------------------------------------------------+
; |$02000-$0ffff > Music Module                   $e000L            |
; |$10000-$1afff > Sprite Masks                   $b000L            |
; |$1b000-$1ffff > Free                           $5000L            |
; |$20000-$2afff > Sprite Assets                  $b000L            |
; |$2b000-$2ffff > Free                           $5000L            |
; |$30000-$37fff > Front Screen Buffer            $8000L            |
; |$38000-$3ffff > Free                           $8000L            |
; |$40000-$48000 > Back Screen Buffer             $8000L            |
; |$48000-$5dfff > SFX Samples                   $16000L            |
; |$5e000-$5efff > Upper panel                    $1000L            |
; |$5f000-$5ffff > Bottom panel                   $1000L            |
; |$60000-$67fff > Post Sprites Screen Buffer     $8000L            |
; |$68000-$6efff > Sprite List structures         $6000L            |
; |$6e000-$6ffff > Hardware Sprites               $2000L            |
; |$70000-$77fff > Pre Sprites Screen Buffer      $8000L            |
; |$78000-$79fff > Tile Collisions                $2000L            |
; |$7a000-$7bfff > Enemy Collisions               $2000L            |
; |$7c000-$7dfff > Bomb Collisions                $2000L            |
; |$7e000-$7e3ff > Copper List                     $400L            |
; |$7e400-$7ff00 > Stack                          $1b00L            |
; |$7fff0-$7ffff > Exception Handler                $10L            |
; +-----------------------------------------------------------------+

; All chip mods are $d400 in size

As you can see it's pretty tight in there.

I keep all of the assets compressed which then unpack to chip ram. I think a good compromise for the game would be full load if the target has a 1/2 meg expansion but if it's a stock Amiga A500 then it'll be track loading the levels.

Each level would load the background scene and music module.

It's an interesting problem, should be a good challenge to solve.

[Shatterhand]

After that it will be on to the enemies so in between a bit of coding I've been learning a fair bit of trigonometry - amazing what I didn't learn at school.

I always say this. I did have trigonometry at school, failed hard at it.Nowadays I understand it very well and even explains it to other people.

I learned it coding games. Schools could do a whole better job of teaching stuff if they did it in a practical way