Coder shows possible way in which some elements of Street Fighter 2 might be possible

[roondar]

Yeah, AGA attached sprites all use the odd palette. It's one of those "WHY!?" things.

[d4rk3lf]

@Roondar
Thanks for clarification bro.

I am not sure why people wants parallax that bad. Imho, it doesn't add that much visually (especially in 1vs 1 fighting game (I agree it adds much to the side scroller shooter games (or even platforms)), and I'd always prefer great gameplay, over the parallax.

I mean, even in this (great) demo, he is starting with parallax in his test. To mee, ot looks like building a house from the roof. Why not starting the project with characters and all moves, and great gameplay (no slowdown), and then, if enough memorry left, you do parallax, and/or animated BG?

[mcgeezer]

Originally Posted by Muzza

All true but when you attach them they have to be adjacent sprites (even must attach to odd) and they all use the odd palette. So you have four attached sprites up to 64 pixels wide but sadly all sharing the same 16 colours.
If this isn’t true I want to know how as it recently frustrated me!

umm... You may be right as this makes sense.
I'm going to try it tomorrow.

Edit - Thought about it and read some more, you are right so I guess each character would need to be 8 colours only which will probably make it look crap.

[mcgeezer]

Originally Posted by d4rk3lf

@roondar

to mee, ot looks like building a house from the roof. Why not starting the project with characters and all moves, and great gameplay (no slowdown), and then, if enough memorry left, you do parallax, and/or animated bg?

exactly!

[Retro1234]

well I suppose everyone wants to know if it was possible.

if the tile set didn't save much then maybe the snes character sheet could fit into memory complete.

[DanScott]

Originally Posted by d4rk3lf

I am not sure why people wants parallax that bad. Imho, it doesn't add that much visually (especially in 1vs 1 fighting game (I agree it adds much to the side scroller shooter games (or even platforms)), and I'd always prefer great gameplay, over the parallax.

I mean, even in this (great) demo, he is starting with parallax in his test. To mee, ot looks like building a house from the roof. Why not starting the project with characters and all moves, and great gameplay (no slowdown), and then, if enough memorry left, you do parallax, and/or animated BG?

Because they are tackling this from a technical point of view... "how can the Amiga 1200 do what we see graphically in the coin-op?", rather than coming at it from the point of view of actually making a great playable game.

Having said that, there's no reason why they can get a good conversion of the game in there too.. they have a whole playfield free for the characters

[roondar]

Originally Posted by d4rk3lf

@Roondar
Thanks for clarification bro.

I am not sure why people wants parallax that bad. Imho, it doesn't add that much visually (especially in 1vs 1 fighting game (I agree it adds much to the side scroller shooter games (or even platforms)), and I'd always prefer great gameplay, over the parallax.

Yeah, I kind of agree. Parallax does look nice, but I'd rather have a more fun game

I mean, even in this (great) demo, he is starting with parallax in his test. To mee, ot looks like building a house from the roof. Why not starting the project with characters and all moves, and great gameplay (no slowdown), and then, if enough memorry left, you do parallax, and/or animated BG?

Yeah, this is normally the way to go. I guess that for this prototype the focus was on the visual primarily because that's what people tend to judge games by. Edit: I do agree with Dan here as well, if you have a good GFX engine then you ought to be able to make a good game out of it too. Basically, game development is about balancing time vs rewards

[mcgeezer]

Originally Posted by DanScott

Because they are tackling this from a technical point of view... "how can the Amiga 1200 do what we see graphically in the coin-op?", rather than coming at it from the point of view of actually making a great playable game.

Having said that, there's no reason why they can get a good conversion of the game in there too.. they have a whole playfield free for the characters

If they do it on a stock Amiga I'll be the first to eat the humble pie.

Memory is the big problem (but you know this).

[DanScott]

Yeah, I definitely think an "on the fly" decompression system would work.

When you trigger an animation on a character, you are going to require the first frame of the animation sequence right away to display. The first frame will need storing uncompressed. Then the next frame of animation, does that get displayed actually on the next update after that ? I seriously doubt it... even on the 3rd frame after that, would it switch to another frame of animation, i doubt that too..

anyway with that said, you then could run a CPU task in the background decompressing the next frames of the animation sequence before they are actually needed... animation sequence changes suddenly ? fine... halt the task, grab the first uncompressed frame of the new anim, and set the task off again for the new anim sequence...

Decompressing could simply be constructing the next frames from 8x8 tiles (or 16x16 if that makes you more comfortable), to even perhaps a proper fast LZ decompress of the data

[roondar]

That's a clever solution. But honestly, it also feels like a pain to implement and get it to work properly. One of those things that's easy to write down but maybe not so much to code

[DanScott]

Originally Posted by roondar

That's a clever solution. But honestly, it also feels like a pain to implement and get it to work properly. One of those things that's easy to write down but maybe not so much to code

I don't think it would be too much stress to get it working TBH

[roondar]

Well, what I'm getting at is the different compression rates/speed of decompression you might get for each frame. It may end up being difficult to guarantee that all frames will be decompressed fast enough (though obviously you do have some time so it may end up being fine).

[malko]

Originally Posted by mcgeezer

[...] But keep in mind.... everything HAS to work in 2mb of CHIP ram otherwise - NOBODY WOULD HAVE PURCHASED THE GAME!!!!

Not correct.
There have always been people ready to upgrade their computer hardware. Otherwise no expansion card would have been sold, ever.

Originally Posted by Tsak

You have to admit though that at least from an artwork perspective (but also the way that this implementation is done) it's not your typical 'here, see a couple bobs moving and call it a demo'. It's clear that there's some serious thought and effort put into this to maximise the visual result. I don't remember seeing any version or demo of this game (including all AGA tries) looking this good and utilising that many tricks to get it done.

Originally Posted by neoman

[...] We are not interested into dick waving contests. Instead we want to make an enjoyable game milking the HW as much and effective as possible.

[Frio]

@mcgeezer: in your memory usage calculations, did you account for the sprites facing both directions?

@roondar: it would be rather easy to ensure that the decompression fits within a given time budget (with some affordance for unknown conditions such as interrupts), as for each animation frame this could be calculated in advance, and some frames could be pre-discarded based on this information.

The arcade system uses tightly packed blocks of 16x16 pixels for sprites, and I recall seeing the layout of the animation sheets for ROM allocation didn't leave much wasted space, so in theory it is possible to calculate the space required to store EXACTLY all the animation frames for all characters and then double that (remembering that the Amiga does not have the ability to flip them horizontally)...

Fightin' Spirit had quite a bit of clever memory management work to run on 1MB A500, and then on the A1200...

[mcgeezer]

Originally Posted by malko

Not correct.
There have always been people ready to upgrade their computer hardware. Otherwise no expansion card would have been sold, ever.

No publisher back in the day would have released a hit arcade game conversion that required their customers to significantly upgrade their a1200.

Yes people will point to Team 17 games that needed extra fake fast to run but that is a different scenario.

[aros-sg]

Originally Posted by Frio

The arcade system uses tightly packed blocks of 16x16 pixels for sprites

I would try doing that for Amiga version, too. And no masks at all. Instead have a scratch blit buffer, where you reconstruct the complete sprite and mask (including flipping if necessary) *with cpu* from this packed blocks before blitting.

Maybe using 32x16 instead of 16x16 so you can use 32 bit read/writes.

With cpu you can read 4 plane words/longs into register, creating mask by ORing all together and flip if necessary all in one "step".

As for the BOB blit: in theory you can blit both players with COPY and only the area where second player blit overlaps first player blit you need COOKIECUT blit. The second blit for such cases needs to be split up into smaller blits -> think Region functions of graphics.library. (Region = list of non overlapping rectangles to describe any possible shape. Used a lot in windowing systems).

Actually the RESTOREing (clearing in case of blank background, or copy back from restore buffer if non-blank background) part of BOBs can in theory be almost completely "optimized" away for any kind of situation/number of objects, but computations/number of blit splits may be too much depending on how the objects move, how many of them and how often end up overlapping. If you have two screen buffers + an always clean restore buffer.

foreach frame
{
 /*update a region R_NEW describing the area where you are in the progress of blitting
   objects into during each bob blit */

 R_NEW = new Region();
 
 foreach bob blit
 {
   blitregion1 = blit rect INTERSECTING with R_NEW
   blitregion2 = blit rect MINUS blitregion1
   
   blit blitregion1 using COOKIE CUT blit with background (C) = current (hidden) screenbuffer
   blit blitregion2 using COOKIE CUT blit with background (C) = restorebuffer
 
   add (OR) blit rect to region R_NEW.
   
   remove (CLEAR) blit rect from region R_OLD.
 }

 /* Restore blit only for those area where there were BOBs last time (frame), but not this time (frame).
 
 for each rect in R_OLD
 {
   COPY blit from restore buffer to screenbuffer
 }
 
 delete R_OLD
 
 R_OLD = R_NEW
}

Something like that.

[ross]

Originally Posted by aros-sg

Something like that.

This can work, add a pre-(de)pack stage, that can also be something from LZ(78) family, maybe better than a LZ(77/SS) because a 'global' dictionary is probably more effective in this scenario, and you have excellent space management.
It remains to be understood how much stress is this for the poor 020 and the bottleneck cause chip-ram

[lilwshu]

Originally Posted by mcgeezer

No publisher back in the day would have released a hit arcade game conversion that required their customers to significantly upgrade their a1200.

Yes people will point to Team 17 games that needed extra fake fast to run but that is a different scenario.

Gametek released Super Streetfighter 2 Turbo that needed a hard drive, probably as an attempt to make an easy couple of quid from the CD32 version. It looks fantastic until it tries to move.

You are right though - nobody would have paid extra on an expansion to play SF2 when you could get a SNES with two 6 button pads and the game for less than the memory expansion.

[S0ulA55a551n]

Originally Posted by lilwshu

Gametek released Super Streetfighter 2 Turbo that needed a hard drive, probably as an attempt to make an easy couple of quid from the CD32 version. It looks fantastic until it tries to move.

You are right though - nobody would have paid extra on an expansion to play SF2 when you could get a SNES with two 6 button pads and the game for less than the memory expansion.

Just watched some of the long play. it looks like each move has 1 or 2 frames of animation at most. IT really does look good, but that must be borderline unplayable . Its certainly not very watchable

[lilwshu]

Originally Posted by DanScott

Because they are tackling this from a technical point of view... "how can the Amiga 1200 do what we see graphically in the coin-op?", rather than coming at it from the point of view of actually making a great playable game

And of course there is already a great playable version of Super SF2 on the Amiga, it just looks crap.