|
Writing a game sprite driver
Hi All, I'm new here.
Back in the day around 91/92 I used to do a bit of assembly on the Amiga. Well a few weeks ago I went up into the attic and found my old trusty A500 with my AR3 Cart and was amazed it still worked, I was surprised at how familiar I was with it so I kind of have the coding bite back again. Around the time of my coding days I mainly had aspirations to be a game developer but found myself doing demo/cracktro routines which was kinda cool at the time but didn't do much for my employment opportunities. So here I am and I have my WinUAE setup perfectly and my Mayflash Joystick adapter all up and running and it is just like the old days. One thing I attempted to do back then was design/build a sprite driver routine. Now what I mean by this is not just how many sprites I can get on screen, I mean how many sprites I can get on screen but have full collision detection of arbitrary objects just like a running game would have - I found it particularly mind bending back in the day so I guess I just might not have been old/wise enough to do it. That said, I want to try and resurrect the challenge so I've had a little think over a couple of hours and came up with some thoughts below around design of the Sprite definitions - it's really just a brain dump but I was wondering if the wheel had already been invented by someone else before I start coding that I could review? Any code I write I'm happy to share with the community. Any tips from seasoned devs are most welcome!!! When I came across the forum I was looking for platformer games that hadn't been ported to the Amiga so the Rygar thread popped up which has been really fascinating to read, I've kind of had that game in my head as I wrote this as I loved it in the arcades (I even tried to port it myself to the GBA back in 2002 in ARM without success). Here goes... starting with events that are found in a tile map which generate sprites. Imagine this being a world that a player can move around in / think Turrican, Robocod 2, Rygar etc The appearance of sprite data depends upon the triggering of events in a map world. Sprited can be created by any of the following: -- Timer based events Based on a timer counter that increments from when the world begins. (Think of when the baddie appears on Bubble Bobble) -- Map point reached or is visible Sprite is generated when a particular map point or counter has been reached in the world. -- Other sprite conditions Sprite conditions such as sprites being destroyed, created or collided. Sprites that are created are tagged with formations, such as: (1) Move Left, Right, Up or Down and do not pass obstacle (2) Move Left and Right and jump over obstacle (think Rygar) (3) Move Left and Right and fall off obstacle (4) x/y formation list - (so think of shoot'emup attack formations) (5) Move Left, Right, Up or Down and pass obstacle (think bullets) (6) Sprite can move but cannot move through obstacles (Rygar) (7) Others..... that I can't think of. When a Sprite is created or is moving around the following properties would need to be maintained. I define word 'sprites' as being either part of the playfield that are animating or as objects that are moving / traversing the playfield or other sprites. Sprite objectId - (var decimal) * Pointer to the sprite Object Id Sprite frameIndex - (var decimal) * Pointer to the sprite type Sprite frameNumber - (var decimal) * Pointer to the current animation frame Sprite frameMoveSpeed - (var decimal) * Sprite move speed, default or defined in sprite object Sprite frameAnimSpeed - (var decimal) * Sprite animation speed, default or defined in sprite object Sprite active - (boolean) * Is the sprite currently on screen Sprite controlJump - (boolean) * Can the sprite be controlled? Jumping perhaps? Sprite controlAttack - (boolean) * Can the sprite be controlled? When attacking? Sprite controlFall - (boolean) * Can the sprite be controlled? when Falling? Sprite controlCollide - (boolean) * Can the sprite be controlled when colliding? Sprite controlCreating - (boolean) * Can the sprite be controlled when being created? Sprite controlDestoyed - (boolean) * Can the sprite be controlled when destroted? Sprite CollisionLive - (boolean) * Is the sprite collision live, i.e. can it be hit? Sprite isEnemy - (boolean) * Is this sprite classed as an enemy? Could be important. Sprite destroyedEvent - (var eventId) * Event to generate on sprite being destroyed Sprite createdEvent - (var eventId) * Event to generate on sprite being created Sprite collideEvent - (var spriteId, eventId) * Event to generate on sprite colliding Sprite isColliding - (boolean) * Is the sprite colliding with another? Sprite isCollidingWith - (array SpriteIds) * This Sprite is colling with these other sprites. Sprite xPos - (var decimal) * X Position on screen Sprite yPos - (var decimal) * Y Position on screen Sprite Objects Every sprite has the following attributes that are pre-defined. Sprite Id - (const decimal) * Unique sprite ID, referenced in maps and formations. Sprite isTile - (boolean) * This defines if the tile is simply part of the world map but moves with it. Sprite isPlatform - (boolean) * Can other can stand on this sprite. Sprite isEnclosed - (boolean) * Can other sprites jump through this sprite. Sprite xSize - (const decimal) * Horizontal Size in pixels Sprite ySize - (const decimal) * Vertical Size in pixels Sprite Type - (const decimal) * This may not be used, possibly used to identify weapons/bullets? Unsure Sprite canJump - (boolean) * Can jump on a platform Sprite canJumpLeft - (boolean) * Can jump left from a platform Sprite canJumpRight - (boolean) * Can jump right from a platform Sprite canFall - (boolean) * Can fall from a platform Sprite canFallLeft - (boolean) * Can fall from a platform from the left Sprite canFallRight - (boolean) * Can fall from a platform from the right Sprite isObstacle - (boolean) * Can other sprites pass or move past this one. Sprite gravity - (const decimal) * Amount of gravity for jumping / falling sprites Sprite collisionEnabled - (boolean) * Defines if this sprite can collide with others (linked to hit point) Sprite defMoveSpeed - (const decimal) * Defines the default move speed of the sprite in the world Sprite defaultAnimSpeed - (const decimal) * Defines the default frame animation speed * Below are the sprite types [Frames Index] Sprite staticId - (const frameIndex) * Unique Id for Sprite animation type (i.e. walking left/static etc) Sprite staticFrames - (array decimals) * Array of frames for the sprite when floating or static Sprite staticMoveSpeed - (const decimal) * Overides default sprite move speed. Sprite staticAnimSpeed - (const decimal) * Overides default sprite animate speed. * Sprite Walking Left Sprite walkLeftId - (const frameIndex) * Unique Id for Sprite animation type (i.e. walking left/static etc) Sprite walkLeftFrames - (array decimal) * Array of frames for the sprite when walking left Sprite walkLeftMoveSpeed - (const decimal) * Overides default sprite move speed. Sprite walkLeftAnimSpeed - (const decimal) * Overides default sprite animate speed. * Sprite Walking Right Sprite walkRightFrames - (array decimal) Sprite walkUpFrames - (array decimal) Sprite walkDownFrames - (array decimal) Sprite jumpUpFrames - (array decimal) Sprite jumpLeftFrames - (array decimal) Sprite jumpRightFrames - (array decimal) Sprite fallDownFrames - (array decimal) Sprite fallLeftFrames - (array decimal) Sprite fallRightFrames - (array decimal) Sprite landDownFrames - (array decimal) Sprite landLeftFrames - (array decimal) Sprite landRightFrames - (array decimal) Sprite leftBounceFrames - (array decimal) Sprite hitRoofFrames - (array decimal) Sprite fireLeftFrames - (array decimal) Sprite fireRightFrames - (array decimal) Sprite fireUpFrames - (array decimal) Sprite fireRightFrames - (array decimal) Sprite climbFrames - (array decimal) Sprite descendFrames - (array decimal) Sprite faceForwardFrames - (array decimal) Sprite faceBackwareFrames - (array decimal) Sprite generateFrames - (array decimal) Sprite destroyedFrames - (array decimal) |
Quote:
You may have to use BOBs instead of sprites depending on the game since the sprite hardware can't produce more than 15 colors with 4 images across on the screen. Using all 8 sprites requires dropping them to 3 colors a piece and each pair has to share a palette even then. BOBs are the blitter-based sprites PC users are more familiar with and can use the whole palette at the cost of draw and undraw time. Sent from my ODROID-XU3 using Tapatalk |
Quote:
I remember in my ST days when I didn't have any Blitter or hardware sprites so had to code sprites routines using the CPU, I'm pretty sure I can remember a fair few of those optimization tricks which will help. Before I write any assembler I'm going to try write pseudo code/logic for the sprite engine... this is something I never did back in the day and would have probably made my life easier. :nervous |
Well I thought I might as well give it a go, version 0.11 of Geezer's sprite engine.
https://youtu.be/XPGP7_-iAdY I decided to take the sprites from the arcade version of Bombjack as they are nice to work with. Use the joystick left/right to move the Sprite I will probably try to implement the Bombjack enemy formations too as I quite like the game and it is a nice challenge to integrate with this. Also, the Amiga port of Bombjack was particularly under par. For the code... It's very early stages at the moment as I get used to the Amiga hardware again so don't expect a lot from this. For example: 1) My code isn't/was never very neat, although any coding tips would be appreciated. 2) I make no use of the Blitter - it's all done using the CPU (I find it hard to shake my Atari ST days I'm afraid) 3) The code isn't memory friendly, it hard codes memory addresses in Chip ram above $5e000 to 80000 so expect that area to get murdered. As I'm enjoying the challenge I'll carry on methinks. Probably in the following order: - Move to using the Blitter - Sort memory allocation out - Improve my Copper use ... many others... maybe someone will look at this... who knows. ;) |
I've improved the engine over the previous version i posted so thought I would update it -
https://youtu.be/CNSD3rIPLl8 It looks like it can currently handle approx 32 * 16 colour 16x16 bobs at 50Hz. I had a look and if I was to recreate a faithful arcade port of Bombjack I would need around 14 moving sprites at any given time based upon 1 x player, 10 x attacking enemies 1 x power ball 1 x lit bomb 1 x bonus / power up There would also be some 32x32 sprites that would need to be dealt with when collisions are made with but these can be handled easily with the hardware sprites on the A500. The engine now has the following improvements: - Sprites are now pushed onto a sprite list, you assign some starting parameters and a handler - Double buffering added - Sprites are now drawn with the blitter using cookie cutter mode - Triple buffer added for fast background restore - Code cleaned up a fair bit - Lots of comments added I'll probably start to look at the collision detection next so if anyone has any good ideas on how to achieve it then let me know? I was thinking of simply tracking the 16x16 cell location of each sprite in and if player 1 is adjacent or overlapping to another then use the sprite masks with the blitter zero flag to determine any collisions. Things to do after that if I have time and energy... - Add in the 32x32 hardware sprite support - (fairly straight forward I hope) - Add in non-animating sprite support, i.e. draw bob once until collision - eg collect bombs. - Sprites aware of platforms etc... as previously stated... lots of work there. It just goes to show... About 12 days ago I had a CPU driven sprite routine that could manage only about 6 sprites in 50Hz, now with a bit of work using the Amiga hardware I've been able to increase this to 32 (and that's with 20 years out of the game). It just goes to show that if them lot down at Elite had put a little bit of effort into the Amiga version then BJ for the Amiga could have been made near enough Arcade perfect, instead they cashed in quickly by porting the ST version - criminal really. |
To make it easier and faster to see where I am with my sprite driver I've decided to upload Youtube videos demonstrating progress.
I've added some limited hardware sprite support and have started working on the collision detection stuff. It can still comfortably handle 28 moving sprites. If anyone is interested in the source code just ping me a message and I'll send it. This is a nice interesting little project that I'm just working on now and then, probably like most of you I have a family, job etc so I can't really say how far this will go... you never know though I may do the whole lo. https://youtu.be/FgXj0wv-2T8 |
Youtube video here adding tilemap collision detection for the metal man enemy.
Routine can now only support 26 movies sprites as opposed to 32 previously. Plenty ways to optimise left though. https://youtu.be/lnE1lnkRCmE |
Another update here to my driver with full tile and enemy sprite collision detection now implemented. Still need to do the bombs though which will be tricky.
It currently manages 24 16x16x16 colour moving sprites across a 16 colour background. https://youtu.be/ev_VJTNy-Jo |
Further update -
So after going down a couple of Rabbit holes I managed to implement the bombs pretty well now. At first I drew all the bombs as sprites and tried to save CPU time by checking if they were not moving, this was still far too CPU intensive as my sprite count went from 28 to 10. Having thought about it I realised that only the lit bomb is ever a moving sprite so now even with the bombs I can still push 24 moving sprites (more than enough for Bombjack). Other changes.
For some reason I forgot to add the bombs in the sprite assets so I'll do that in a later update. I have no idea why a secondary Bomb Jack sprite appears on the right, I haven't debugged it yet but there's nothing obvious. What's hurting my head now is the palettes. The background scenes are 16 colours / 4 planes, and the sprites are 16 colours 4 planes... 5 bit planes is enabled so that I can get the two 16 colours together but I can't work out the palettes properly yet - maybe I'm over thinking it. Loving coding the Amiga again. https://youtu.be/A8I1Uu1nv2w |
Nice stuff, I like the demo videos showing the progress - makes it more real somehow :)
|
I've had a few requests now to share the source code for my project which is very flattering.
Previously I've uploaded the source code to the zone however a member (thanks @frio) suggested that I use Github to share the code which may help facilitate some contributions. Just to re-iterate from my initial post, this aim of this project is to see if I can build something I couldn't achieve when I was much younger. I didn't intend to use Bomb Jack as the game to port as inspiration but given that I love the arcade game and know how it plays inside out it's as good a game as any to convert, additionally the original port to the Amiga was very poor. With that said feel free to use the code in any of your projects as you see fit. I still haven't purchased any xmas presents for my family yet :nuts so I think I best prioritise on that for the next couple of weeks. This will give me a chance to get a handle on using Git so updates may slow down as we approach the New year. The source code can be found here https://github.com/mcgeezer/bombjack-amiga.git If someone can let me know they manage to compile it I would be very grateful. Thanks, mcgeezer |
Quote:
Thanks for sharing the source code !. :great |
Nice stuff, well done. To make it more real play the C64 Bombjack Muzak :)
|
A bit of an aesthetic update here on the driver with the graphics but more so with the palettes which were concerning me.
Changes made are: Fixed....
Added...
Here's a video update, will update GIT shortly. https://youtu.be/R9jvrI48Cwo |
Continuing on with the graphics side of things I've now added in the border and platform tiles, I made this wayyyyy harder than it needed to be last night and woke up this morning and did it in ten minutes.
As I managed to find a nice quick way in under 15 minutes of figuring out the platforms and bomb positions on the arcade I decided to put them together on the first level. Another good addition is to do with the tile palettes. As I can't remember any of my DPaint skills I couldn't remember how to do simple things with the palette and due to the varying number of colours in each scene, the need to move the colour palette around was necessary for the platform tiles. If you ever played the arcade version you'll notice the borders and platforms change gradient colour at different rounds and scenes so I thought I'd pop that addition in this update too. https://youtu.be/gqyKF31RQco Next up will be doing the bomb collection, then the Power Ball and Bonus. Getting there. |
Awesome !
|
Quick update before Die Hard starts at 10pm (UK).
Update here showing where I've added collect bombs functionality. It still has a couple of small bugs which I'll sort tomorrow night some time. Next up on the list is making Bomb Jack float and fly. https://youtu.be/rMf-njBrCpY Yes - I like Die Hard. |
Another short update to show some sprite link work added to the driver.
It can now handle a "loop once" animation as opposed to loop for infinity. Some other internal changes have been added including being able to enable or disable a sprite. This is important because based on an event you can then trigger a sprite animation. In the case of Bomb Jack, when he collects a bomb it plays a short animation. Video demo is here to show what I mean. You'll notice a couple of bugs, when I iron them out I'll upload the code to GIT. Then it's onto more exciting code. https://youtu.be/584zWegde-0 |
Carrying on with another update as I had a good amount of coding time today before I'll have to break for XMAS.
Added
I've uploaded the latest source to my GIT repo, very much needs a tidy up. Next up is to add Bonus, Extra and Special sprites with collision detection. Start adding the other enemies.... some will be easier than others. I'm not looking forward to the saucer as it will involve line draw math which I'm particularly not good at at all so may ask for some assistance from other coders if I get stuck. Also starting to think about the scoring system too which shouldn't be too tough, at that point I'll add the upper and lower display panels. https://youtu.be/AlP1vgOsSEs |
Last update before Christmas.
In order to work on the Bonus/Extra/Special collision detection I thought I'd best put the upper and lower panels in place to show counters etc. After wasting about 3 hours reading the Hardware Reference Manual wrong on how to modify beyond registers with the copper beyond 256 vertical lines I was able to get the panels to work pretty quick. Added:
See video for progress. https://youtu.be/zVcBW6NcWl8 Merry Christmas to all those that are viewing my updates! Geezer |
| All times are GMT +2. The time now is 14:05. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.