Beats of Fire

[Bamiga2002]

Works! Renamed "NEW_SOUNDS" to "NEW SOUNDS" and can now test.

[leathered]

Well done for getting that to work Bamiga, I'll check the files to make sure this is not an issue for others. It should definitely be NEW SOUNDS, not sure where the underscore came from. I created the ADF in UAE after struggling to get a clean copy on a real floppy, so maybe it had something to do with that?

[Bamiga2002]

Fluid animation on Haggar . But the enemies are like on my worst nightmare - they never die argh!
With 8 enemies the music is heard randomly but with only 1 it won't interrupt so much.

Keep going this will be good

[s2325]

I think files should stay in .iff format in next versions as it will be easy to make new backgrounds and fighters. I'm still waiting for Lotus-style game with customizable graphics and music.

[leathered]

I agree, although I've been wondering if there's a more memory efficient way of storing the data to make it more viable for floppy users. What I have in mind is an expanding HD file with the stages available as single disk demos. The disk usage isn't very efficient ATM, there was a lot of palette swapping that I kept several .iff files on the disk for, even though I cleared the unnecessary image data.
Also the characters will be stored as .iff and ripped; Haggar's data needs to be put onto one sprite sheet, it's mostly in one place but there were several edits as single images.
I'll put this on the 'to do' list for the next upload.

The same also applies to the SFX (.iff) and music (octamed). You can use your own, if the music playback is slow then speed it up in octamed and save. The timing of the playback is different to when playing it through the sequencer – updating in 2 vbl which is I believe what accounts for the change.

[OlafSch]

Originally Posted by Lielo

Thanks to everyone for taking the time to check this and respond! You helped make a rough day @work disappear.

A bit more information I think:

This project was started with the intention of creating a decent side scrolling beat-em-up for the Amiga. There have been some notable attempts but for me there was always something missing! Final Fight was one of my fave arcades of the era and after plugging away in Amos Pro for a couple of weeks I switched to Blitz Basic2. So I'm not an amazing programmer and this is my first attempt using BB2.
I haven't posted before now as I'd hate for this to become another one of those projects that just runs out of steam. I think now that even if Final Fight becomes out of reach there's enough here to begin creating something decent for the Miggy. I'm definitely interested in making another game either after this or as soon as it becomes too much. Bearing this in mind, If someone wants to help with graphics or improving the code then that would be great.
I'm sticking with FF for now... Good learning curve!

Technical stuff that should help explain some of the issues:

Dual playfield display - one for bobs (the baddies) and one for the background. 2 Palettes of 15 colours (minus colour 0 in each case)
Player is a 64px wide sprite sharing its palette with the parallax background.
The parallax layer is made of 3 colour sprites and sits behind both playfields. The player sprite is displayed either in front or below the bobs playfield to add the illusion of depth. The remaining bob priority is controlled by selective blitting - which I've made as fast as I can whilst sacrificing a bit of accuracy.

It aint perfect!

@Boo Boo. If I push the number beyond 6 I get the same thing. It could be the style of blitting I've gone for. I'll check older versions, but of course, there has to be a limit! Could just be the lack of DMA time, or my programming!

@ frikilokooo. The colour in the shadow is due to me messing with the colour of the parallax background layer. I reduced a lovely 16 colour scene to 3 colours but ATM I'm using the wrong registers.
I also get the weird background colours sometimes, it's just something you press on with when your program is 'young' and you're fed up of messing with the graphics! But will be fixed. As to the other bugs, they are numerous and I appreciate them being pointed out.

@s2325. Thanks for posting that! Looks the same as mine albeit a baddy or 2. Is this 020? It's encouraging if that's the case.

Great work. Have just tested it on Aros Vision and it works.

Screenshot here:
http://www.natami-news.de/Aros/FinalFight.png

[Havie]

A quick quesiton on how you did the collision detection? I was writing Target Renegade for the PC a while back and spent a lot of time setting up hit point boxes for each character and testing collisions between these boxes. Seemed to work ok but was posible overly complicated plus was concerend that characters who were obviosuly not in line with each other could still hit each other (if that makes sense?). So how have you done it or do you know a website that explains it? I would love to finally finsih the game (and maybe port to Amiga?).

[Codetapper]

Havie: Assuming your hotspot for each character are their feet, you can test if the character should even be checked for collisions by seeing if they are very close to each other's Y coordinate. If they're within say 4 pixels, then they're close enough so continue the tests for your collision rectangles. If not, skip that character. That should work fine!

[leathered]

@ OlafSch. A lovely shot featuring the weird 'neon-sludge' city backdrop when the registers load badly! Great to know it's working on Aros, thankyou for testing it!

@ Havie. There are of course several ways; colour to colour, sprite to bob, zone to zone. Whichever you choose you'll use some way of working out the depth for this style of game.

You could leave your zones as they are, but add an additional check to see if the y axis is 'in range'.
If you don't want to check the Y axis you can make smaller zones. One way would be to make a zone around the attacking limb (say an arm) and work out a smaller zone for the baddies, say in their mid section. Adjust each zone so that it will miss if positioned too high or too low.

This engine uses (quite crude!) proximity detection which will trigger a hit on certain animation frames only. It worked out faster simply because the code was already there (used to work out AI) and was easy to adapt.
Certain PC languages allow for a Z axis and though it's not necessary for a 2d game you could use that to determine when at appropriate depth. The other thing that could pull the rug from your feet is airial attacks, you just need to work out where the 'ground' is and whether what's standing on it will be hit or not. For the same reason as Codetapper suggested above re. 'blitting order' make sure that your hotspots are at the feet of your characters, it makes working out the 'depth' a lot easier.
Just keep it simple as you'll be testing for each object per loop.

[leathered]

Heh heh, Codetapper beat me to it!

[leathered]

Originally Posted by Codetapper

I wonder what the game would look like if you switched to 32 colour mode (or maybe 64) with this setup instead:

Use 4 sprites for the parallax layer, but attached so 15 (unique) colours. Have a copperlist that repeats the sprites across the screen so you would have a 128 pixel wide background across the entire screen. This would eliminate the gaps that appear in certain places.

I understand what you were saying now. I've been thinking lately on vertical sprite re-use to create a status bar and ground objects; got confused. I've never tried using the copper to re-use the sprites, but attaching 8 across the screen was one the possiblilites as I was 'writing up' the display attributes.
Been messing with the current display, scrolling it in 1 vbl, with the parallax layer and player sprites updating every 2. Working out the rest of the updates including synching the blits properly, but it's much smoother and runs well with 2 enemy bobs up. Trying this I also discovered a faster and more accurate AI routine which I can definitely use. It pays to go digging sometimes.

Your posts got me trying ASMpro again... ah, maybe one day.

[Mrs Beanbag]

For collision detection between large numbers of rectangles, look up interval trees.

For efficient disk storage of game data, look up Lempel Ziv compression (Powerpacker, Imploder et al use variants of this).

Personally I'd look into using a more efficient music format than Octamed, which was designed for musicians more than games programmers.

[trydowave]

Now this is more like it!! Very impressed. Still don't understand how you can do all this in your spare time and US Gold couldnt do it at all. Love how you got all the moves in here., music and parallax.
Question. Taking out the parallax could this of been done (music and fx combined, all moves etc) on a standard A500 ECS?

[Mrs Beanbag]

Sometimes I wonder if US Gold got sent the wrong hardware reference manual.

[trydowave]

Hello Mrs Beanbag... I keep bumping into you Be it here or on Lemon Amiga. And yes... US Gold Are SH!TE!

[Predseda]

Very interwrestling - erm, interesting!

[leathered]

Thanks Mrs B- looks similar to a sorting method I was using to order the blits a while back. As for the music, blitz2 supports octamed and soundtracker formats, but for me it seemed the player for the soundtracker was broken – probably a compatibility issue. The med player is a touch awkward but at least it works and with standard blitz libraries atm. Would love to try another player though. Lot's of research to do...

Hmm, my problem with the US. Gold version was the lack of interesting gameplay and atmosphere – combo system gone, enemies just gang up on you. By then I'd become kind of sad when I saw their name on the tin – you just hoped they hadn't fluffed another one up. I'm positive you could have got more 'game' in the OCS version, even with the frame cut – all the moves are potentially there, and AI can be developed? With AGA, still got to fit in more baddy types, a load of objects etc. I play the OCS to have a look at how it was done – still got some respect for it (you should have played it on ST , besides, I've still got a way to go to catch it in some respects), but yeah, I wouldn't be doing this if I was satisfied with that version.

And beat-em-ups just play better with music+fx! Interwrestling fact! Not sure why it was so often missing with the miggy's great sound capabilities - you often get one or the other. A lot of this must be down to development time...

[frikilokooo]

Sidescrolling beat'em ups on Amiga are very bad in general for me the only one that I really like is this one .Megadrive and Snes had better sidescrolling beat'em up titles compared to Amiga.If there is a game that is missing on Amiga is a good sidescrolling beat'em up and a good similar Cabal game too.

[Graham Humphrey]

Originally Posted by Lielo

As for the music, blitz2 supports octamed and soundtracker formats, but for me it seemed the player for the soundtracker was broken – probably a compatibility issue.

The standard tracker-playing commands for Blitz are rubbish. They just don't work. If you install the Blitz Support Suite there is a much better library for playing tracker modules although there can be problems using it with older setups but as your game is AGA only that won't be an issue.

[Mrs Beanbag]

AMOS is the same, the tracker converter doesn't convert perfectly and I tried two different extensions and both had major flaws, so I eventually wrote my own from the playroutine supplied with ProTracker itself.

I could make that public domain, actually. I probably should.