Street Fighter 2 GFX Test

[Anakirob]

You'll probably run into problems if you try and use the upper registers in your inline ASM. a0-a3, d0-d3 are fine, all the others cause problems from memory. The 68k code posted above will probably cause a crash when imported into Blitz.

Working on a demo coded in Blitz using inline ASM many years ago our coder (Ript^DisasterArea) had to work around this problem.

[Daedalus]

I'm not sure if the same applies for Blitz 2.1, but according to the AmiBlitz documentation, only registers A4-A6 and D7 are reserved for compiler use, the rest can be used as you please from Blitz ASM.

The following registers are used across basic functions and must not be trashed:

A4 is reserved for the local variable base within functions
A5 is reserved for the global variable base
A6 is reserved for library access
D7 is reserved for intermediate results between Basic code

...and of course the Stack should not be trashed.

[Master484]

Ok, good to know about the potential problems with those registers.

Today I quickly tested the code pieces posted, and when compiling, all the long commands like these gave a "syntax error":
move.b (a5,d0.w),(a1)+

Both code examples had a line with multiple parametres like this, and both gave a syntax error on such lines. But all the other lines that were shorter were seemingly OK.

But, even if I could get this to run, most likely I couldn't adapt it to any real use, because I can barely understand the ASM code and the working mechanism. Even if this small example would work fine, I still couldn't build upon it without first learning at least the basics of ASM.

And even if I get smarter and would suddenly understand it, the end result would still not run at 50 FPS, because as I explained in a previous post, this whole mirroring process requires: 1. Blit the Blitz "Shape" we want to mirror into a separate bitmap. 2. Transfer some info to the CPU registers. 3. Perform ASM mirror code to the bitmap to mirror it. 4. Read the mirrored bitmap data back to Blitz Shape. 5. And after this Blit the mirrored Shape into the actual game screen.

And I tested that process without the ASM code, and it caused slowdown. So even if I could get this to work, I think speedwise it could only barely beat the Blitz's own XFlip. So it might not be worth it after all, especially with my zero ASM skills. But anyways, thanks for all the help and code examples.

Store the sprites/objects with the top half facing left, and the bottom half facing right (ie... a 64 pixel high sprite, the top 32 pixels are facing left, the bottom 32 facing right)

Then you only have to flip one half depending on if you want the left or right facing version.

This is a good idea, and even if I can't use the ASM routines, I think I'll test this method with the Blitz XFlip on small objects...I think XFlip could handle small arm and leg BOBs in real time at least, if it only had to mirror half of them. And considering the large amounts of arms and legs in this game, this too might save quite a lot of RAM.

And maybe also some of the "victory celebration" frames of certain characters, and other stuff like that might also be OK to mirror with Blitz XFlip; so we could split some of those frames into half vertically, and do the XFlips when fight ends; the pause would only be 1 or 2 seconds.

[dlfrsilver]

Just a few informations i got here and there about the CPS1 arcade hardware :

- The 68000 deals with the tiles metadas (in words)
- The Graphics roms are only connected to the graphics tilemap chips
- The 68000 has no access to the graphic tiles
- The 68000 takes care of the collisions (all done in software !)
- The 68000 send requests to the graphic hardware : "print tile $3452 at X 128 Y 64 on tilemap 2".
- The AI, state machines, all those are processed by the 68000.

[roondar]

Originally Posted by dlfrsilver

Just a few informations i got here and there about the CPS1 arcade hardware :

- The 68000 deals with the tiles metadas (in words)
- The Graphics roms are only connected to the graphics tilemap chips
- The 68000 has no access to the graphic tiles
- The 68000 takes care of the collisions (all done in software !)
- The 68000 send requests to the graphic hardware : "print tile $3452 at X 128 Y 64 on tilemap 2".
- The AI, state machines, all those are processed by the 68000.

It might be especially interesting to see how they dealt with collisions. These are usually done in software on the Amiga as well so a comparison with how a proper arcade fighter does this with how Amiga fighters do it (which IMHO often felt off in this regard) might teach us all something.

Good work on the analysis

[dlfrsilver]

Originally Posted by roondar

It might be especially interesting to see how they dealt with collisions. These are usually done in software on the Amiga as well so a comparison with how a proper arcade fighter does this with how Amiga fighters do it (which IMHO often felt off in this regard) might teach us all something.

Good work on the analysis

Thanks. Honestly, if i had enough knowledge, i would comment and reverse back to ASM the full SF2 CE arcade code. This is quite straight.

it contains a lot of datas (AI tables, metadata), that have to be externalized.

the main game code as program, should be something like 500kb (more or less).

[redblade]

Is your port going to be full 6 button CD32 controller support?

[Tigerskunk]

Originally Posted by roondar

It might be especially interesting to see how they dealt with collisions. These are usually done in software on the Amiga as well so a comparison with how a proper arcade fighter does this with how Amiga fighters do it (which IMHO often felt off in this regard) might teach us all something.

Good work on the analysis

SF and a lot of other fighting games use dynamically per frame allocated bounding boxes for areas that can be hit (usually shown in green in images), and for the areas that are executing the hit, like a fist or leg (usually shown in red in these images)...


You can see this principle in action here:

[ Show youtube player ]

[Master484]

Is your port going to be full 6 button CD32 controller support?

Most likely yes. Blitz Basic has a simple command to read all the buttons of a CD32 pad, so if it works, then surely I'll use it. But a normal joystick + one button option will also be available.

SF and a lot of other fighting games use dynamically per frame allocated bounding boxes for areas that can be hit

Yes, this is probably the best method. Although in our case it'll be just 1 hitbox per fighter (or maybe 2 at most), that automatically resize depending on the animation frame. And the hitbox areas in SF2 are far from "pixel perfect"; you can often hit opponents by just punching the "air" in front of them, so I would imagine that collision detection will be quite straightforward

[dlfrsilver]

Originally Posted by Steril707

SF and a lot of other fighting games use dynamically per frame allocated bounding boxes for areas that can be hit (usually shown in green in images), and for the areas that are executing the hit, like a fist or leg (usually shown in red in these images)...


You can see this principle in action here:

[ Show youtube player ]

SF2 arcade machine works the bounding boxes in Software via the 68000.

[idrougge]

Originally Posted by Master484

In Blitz games, all Blitting is done with "Shapes". Shapes are "Blitz objects", and in the beginning of the game, their image data is first taken from normal Bitmaps that you load into the program. But after putting the Bitmap data to a Shape, the Bitmaps themselves are then typically deleted to save RAM, and from this point onwards only Shapes are used to draw GFX into screen.

That's not how you do it. You load shapes with LoadShapes. No grabbing, copying and erasing bitmaps.

Originally Posted by Master484

So I guess that if we wanted to mirror a Shape with in-line ASM code, we would at least need to know the start address of the image data inside the Shape, it's width and height, and know how the Blitz Shapes actually work "under the hood".

That's perfectly documented, and the shapes format is basically just a raw bitmap with a header containing necessary information for the blitter.
Here's the shape format in all its glory: http://www.amigacoding.com/index.php...ct_types#shape
Here's a script for dumping information about a shapes file: https://github.com/idrougge/ShapesInfo

Originally Posted by Master484

One other idea that I just got is to do the mirroring using the Blitz "Scroll" command; we could Blit the Shape into a small external bitmap that is twice it's X size, and then "Scroll" each Y-line of the image into the other half in inverted order, and after this we would read this mirrored data back into the Shape. I don't know how slow this process would be, but I think I'll test it.

It would be horrendously slow, because you'd be doing 64 tall blits for a 64 pixel wide enemy.

[idrougge]

Originally Posted by Daedalus

I'm not sure if the same applies for Blitz 2.1, but according to the AmiBlitz documentation, only registers A4-A6 and D7 are reserved for compiler use, the rest can be used as you please from Blitz ASM.

D7 is reserved, you say? Bloody hell, I must check all my inline asm so it doesn't trash that.

[Tigerskunk]

Originally Posted by dlfrsilver

SF2 arcade machine works the bounding boxes in Software via the 68000.

Well, yeah. That's what bounding boxes do.

It's not a hardware sprite collision detection going on or something.

[idrougge]

Originally Posted by Master484

And even if I get smarter and would suddenly understand it, the end result would still not run at 50 FPS, because as I explained in a previous post, this whole mirroring process requires: 1. Blit the Blitz "Shape" we want to mirror into a separate bitmap. 2. Transfer some info to the CPU registers. 3. Perform ASM mirror code to the bitmap to mirror it. 4. Read the mirrored bitmap data back to Blitz Shape. 5. And after this Blit the mirrored Shape into the actual game screen.

Just load the register with the address of the shape's bitmap data.

GetReg a0, Addr Shape(0) ; Moves address of shape 0 to address register 0
GetReg a0, myshape\_data ; Moves address of myshape's bitmap data to a0

[Master484]

That's not how you do it. You load shapes with LoadShapes. No grabbing, copying and erasing bitmaps.

Yes I guess that's the better way of doing it, although until now I have always used "load bitmap + getashape". But maybe I should try the LoadShapes method too, as the manual description sounds like this is the way it was meant to be done.

Just load the register with the address of the shape's bitmap data.

Ok thanks.

[idrougge]

Either you load the shapes directly from disk or you INCBIN them in your binary and just CludgeShape them.

[Daedalus]

Originally Posted by idrougge

D7 is reserved, you say? Bloody hell, I must check all my inline asm so it doesn't trash that.

I guess it depends on what "for intermediate results between Basic code" means. You might get away with it if you're not nesting expressions too deep or something like that. Probably safest to avoid it though.

@Master484

Most likely yes. Blitz Basic has a simple command to read all the buttons of a CD32 pad, so if it works, then surely I'll use it. But a normal joystick + one button option will also be available.

Yep, not sure if it uses lowlevel.library or not though, which would limit you to Kickstart 3.1+. It's not difficult to read it with some creative peeks and pokes however, which will work on any Kickstart.

[idrougge]

Originally Posted by idrougge

Either you load the shapes directly from disk or you INCBIN them in your binary and just CludgeShape them.

DecodeShapes I mean.

[Master484]

I've played around with this demo again, and made a small test to see how it would run on AGA 128 color mode.

The ADF has been added to attachments of the first post of this thread.

Minimum requirements : A1200 and 2 MB.



Commands:
1 - create fireball
2 - create Balrog
3 - create Blanka
4 - create horizontal 64*16 object
5 - create vertical 16*64 object
8 - 25 FPS MODE
9 - 50 FPS MODE
Joystick - scroll level

---

Firstly, the 128 color palette has been divided into 2 parts: first 64 colors are for the background and the remaining 64 colors are for the BOBs.

This allows a different 64 color palette for each level and also allows using copper effects on the 64 background colors without affecting the BOB colors. And also I made it so that that the 3 first background colors are always transparent, black (0,0,0) and white (255,255,255), and these 3 colors can also be used by the BOBs. So the BOB 64 color palette doesnt need to have tranparent, black or white.

All BOBs take their colors from the last 64 colors of the palette, and these colors stay the same throughout the game. The current BOB palette in this demo is just a placeholder filled with random colors, but if well designed, 64 colors should be enough for almost arcade perfect colors ( or Amiga perfect ), especially because the 64 BOB colors doesnt need to include transparent, black or white.

---

All drawing operations are done in 128 colors, but it's still quite fast, a good amount of objects can be drawn in 25 FPS. Although full 50 FPS seems impossible in this many colors and with game objects this big.

But I recently discovered the AGA 64 pixel fetch mode feature, and turning it on with the Blitz Display Library made all drawing 30% faster. And in addition to this triple buffering is still used: all is drawn with QBlits with Unqueue source bitmap. Together these two tricks make the 25 FPS frame rate possible.

And also screen size is bigger than before: 320*200 game area + a 320*32 status panel. Between the panel and the main area there are six empty lines; this is a Blitz feature. Normally the line amount would be 2 or 3, but it seems that with this screen setup it needs 6. But it's not a big deal.

Also all sprites are lost thanks to the 64 pix fetch mode + 320 pixel wide screen. But this is only true for the game area, I think the panel can still display sprites, and it can be optimized more with them.

Also scrolling is done from the interrupt and always updates at 50 FPS, regardless of the FPS mode or slowdown.

---

Test results on standard A1200 configuration without any Fast RAM:

50 FPS MODE

Fireballs = 9
One character + 3 fireballs.
Two characters at once cause slowdown.

25 FPS MODE

Fireballs = 19
One character + 12 fireballs
Two characters + 6 fireballs

---

If Fast RAM is added, it gives one more fireball. So it would seem that at 25 FPS this game could be made run in 128 color mode.

Although if we count 2 characters + 2 shadows + 2 fireballs, then this leaves us about 2 fireballs worth of power, and 3 fireballs with Fast RAM. And to this we add music, sound effects and AI. So it's very tight, but might just be possible.

---

Also I noticed something interesting: pressing 4 and 5 makes rectangular box objects appear. The two box types have exactly the same pixel amounts, but first box is a horizontal 64*16 box, and the second one is a vertical 16*64 box.

And the interesting thing is that you can draw more horizontal boxes than vertical boxes. 10 horizontal boxes run at 50 FPS, but for the vertical boxes only 7 is needed before slowdown happens.

First I thought that this is caused by the 64 pixel fetch mode, but it also happened without it.

So maybe the Blitter is better at drawing horizontal objects than vertical objects?

Also maybe this is related to the image memory consumption rules; because as you know, adding height to an image consumes more RAM than adding width.

Although blitting one full size 64*128 object was still faster than blitting eight 64*16 BOBs, so we can't actually cheat the system with this. But surely this feature is useful when splitting the animation frames into smaller parts; favoring horizontal areas brings more speed.

---

And that level background image is actually from the US Gold version.

But I made it better, added colors and fixed some things, and now it looks great, although it's still a little bit work-in-progress; a few parts need more polish, and more copper is still possible.

The US Gold version backgrounds are actually great, because they're all 640*216 images, and are designed for the 320*200 Amiga resolution, which is the same screen size that we are now using.

This is why I think we should use them instead of the arcade versions; we just recolor and improve them using the arcade version as a reference, and the end results will be perfect.

But about the fighters, I'm not sure, both the arcade and US Gold versions are possible choices. The problem with the arcade versions would be Chip RAM usage (especially now at 128 colors, and especially if mirrored versions are also in Chip RAM), and also they were designed for the bigger and wider arcade screen, and when put to a 320*200 screen, they are maybe a little bit "too big", meaning that the "long range fighting" aspects of the gameplay could suffer. But I'm not sure how much; because we still havent tested any actual gameplay.

And on the other hand, if the US Gold version characters were used, then the problem would be the quality improvement process: All of them and every single frame would need to be fixed, and recolored in 64 colors, and also some missing frames might need to be added using the arcade versions as a reference. But the good points would be the smaller size, meaning more speed and less RAM usage, and also the character sizes would fit better into the 320*200 screen.

---

But again, this is all still just speculation, and more of a graphics test rather than an actual conversion project. But of course a playable demo might just arrive one day.

[dlfrsilver]

I can give you any arcade asset from the arcade if you need it Master484.