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

[roondar]

Originally Posted by Retro1234

so the boat and the characters are large bobs? really?

I thought the boat was one of the two layers of Dual Playfield, not a bob. But it's been two weeks or so since I watched the video so I can't recall all what they said

[Retro1234]

Sorry just edited by post ill just put my edit here in a min.

Originally Posted by Retro1234

the boat is moving - it's huge bob?

edit: sorry no that's not what was said I thought earlier in the video he said it was a huge bob
I only skimmed the video, just looked so fake to me sorry if this is not the case, probably best he uploads it for proof

Thanks.

[Retro1234]

Ok Ok so its just basically the same as mcgeezer except they are using large Bobs for the characters and sprites for the water.
So all sprites are used up on water etc ok cool still looks very PC animation and very misleading.

[DanScott]

Yes, they are using one playfield and hardware sprites to construct the backgrounds, leaving one playfield free for all foreground bobs (players and effects etc..)

To move the ship up and down, they only need to adjust the bitplane pointers

[Retro1234]

Thanks, really what I was wanting to know is what part of the video is on Amiga rather than what parts of the video are possible or not possible I'm not questioning the theory but what part was Amiga.

maybe parts at 23ish and 26, thanks everyone for the confirmation.

[roondar]

To be fair, I'm not entirely sure any of what is shown in the video is actually captured from an A1200, it looks very clean for a capture. But it could be WinUAE for the Amiga parts. I don't actually know. All I did was quote them, it's up to others to make of their statements what they will.

For the record, I don't think most of what they've shown is impossible. Whether or not the extreme BPLCON4 stuff at the end can all be done exactly as shown is an open question (though some form of what they suggest ought to be doable, if fiddly as hell to get into the Copperlist and design for every single level). Same with the memory requirements for characters with all moves rather than just them doing their idle animations as they haven't gone into how they want to deal with storing character GFX yet. But, I'm inclined to keep an open mind and see what they come up with next.

Hopefully they can release an actual executable version at some point, better than just video I think.

[Retro1234]

yeah winuae whatever just first time I saw it I just thought click bait a load of video clips etc but all cleared up up now thanks

[mcgeezer]

Originally Posted by Tsak

Nice work

However would you like to elaborate further in regards to which part from that video is debunked? You say doing the player sprites with the blitter/cpu things become complicated. What do you mean? No enough blitter time left? Issues with ordering? Something else?

Let's say they have the whole front playfield spare and use it purely for the player sprites as I recall they said they would do in their video. For the first player they can get away with a combination of straight blits and CPU moves to render the first player. For the second player, things are more complicated because that player has to be cookie cut into the playfield. So this means they have to hold a copy of the mask as well as the bitmap data.

Let's also assume they can hold all player frames unpacked in ram (which they can't) as they are rectangles up to 128x128 in size, the blitter can't render that size rectangle as a straight copy and then the same size again in a cookie cut .... and THEN clear them again in one frame.

So holding all the frames unpacked in ram... they run out of chip ram.

Packing the frames in ram? Well then they have to unpack the frames into the correct position using the CPU...doubtful at 50FPS. They might be able to hold the first frame of each move in ram and unpack the rest but again I'm dubious about this with the ram requirements.

Don't forget that each opposite frame needs to be mirrored and shifted on the fly too. (taking into account the trick Dan mentioned about holding the upper and lower sprite parts in different directions - most of the times the players will face each other which negates the need to do this, but I accept it is an efficiency)

Let's say they do what I did and create 16x16 tiles of each sprite and rebuild them each frame, this is doable until it comes to the second player because the mask then needs to be included when mirroring the frame along with being shifted.

Knowing what I know now they could look to hold mirrored copies of the tiles in chip ram and use the blitter purely for rendering with the barrel shifter, but then even this approach would need calculating and cookie cutting would be intensive.

Originally Posted by Tsak

Other than that I should note that Dan might have a point with the projectiles and effects ordering. How would you approach this issue?

Effects can be blit into either the playfield or a hardware sprite - makes no difference, colours in both the hardware sprite playfield and front playfield would have to be reserved though.

Originally Posted by Tsak

Another question is in regards to frames, character tiles and ram. Can you still have the characters saved and stored split into 16px wide tiles/parts and reconstruct them as 64 wide sprites or to use sprites you need to save each frame/part only as a 64 wide one? I was under the impression that when you choose to use f.e. 64 wide sprites you can only have the parts saved as 64 wide as well, so f.e. even if a character frame is much less (say 32px wide) you are still forced to save it as 64 wide non the less.

*edit: by 'saved' I mostly mean the chip ram it needs to occupy (which is the main issues here), not the disk/storage space.

Yes, 64 wide sprites does not mean tiles need to be 64 wide. You allocate
chip ram filling up the size you need and then fill it with what ever bitmap you want, no need to shift it, and the data in there is not affected by other things going on in the playfield so you can keep the data there for multiple frames at zero cost.

Apologies if I waffled on.

[invent]

Nice work on the tech demo mcgeezer

Was following this for a few weeks and couldn't resist a quick mockup.

Cut up this scene into 8 pixel blocks (16 colour copper per split), kind of similar to Boss Machine technique. Reducing 109 colours was no small challenge and still needs alot of tweaking in the upper part.

[saimon69]

@invent
To keep the perspective effect those two elephants on the left gotta go from the background playfield, guess you are aware of that

[invent]

Hi @saimon69 yes true, (animated elephants each side) I grabbed the arcade background from here https://vgmaps.com/Atlas/Arcade/ probably could of sourced better image.

[redblade]

Originally Posted by invent

Nice work on the tech demo mcgeezer

Was following this for a few weeks and couldn't resist a quick mockup.

Cut up this scene into 8 pixel blocks (16 colour copper per split), kind of similar to Boss Machine technique. Reducing 109 colours was no small challenge and still needs alot of tweaking in the upper part.

Looks great .

I never knew that there were windows on the right hand side. But damn that was an annoying level with those elephants making noises the whole time.

[malko]

Originally Posted by invent

[...] Was following this for a few weeks and couldn't resist a quick mockup.

Cut up this scene into 8 pixel blocks (16 colour copper per split), kind of similar to Boss Machine technique. Reducing 109 colours was no small challenge and still needs alot of tweaking in the upper part.

Impressive result

[Amiga1992]

Originally Posted by d4rk3lf

Also, AI work that way, that even if you choose "very easy", it grows up on the ladder. So after 2-3 fights it switches to "easy", then to "medium", and so on.
That's why it's not easy for most folks, to finish it, even on "very easy" level.

I should do a video showing how i can finish the game using one move. Only Goro proves a bit of a problem.

[d4rk3lf]

I was speaking about MK2 AI.

[gimbal]

MK2 "AI" is a big cheater indeed on any platform; it's pretty much more A than I. I don't remember MK3/MK Trilogy being much better though. Push comes to shove these games were made for human-human fights, the AI was a nice bonus for practice purposes.

[saimo]

Originally Posted by roondar

For the record, I don't think most of what they've shown is impossible. Whether or not the extreme BPLCON4 stuff at the end can all be done exactly as shown is an open question (though some form of what they suggest ought to be doable, if fiddly as hell to get into the Copperlist and design for every single level).

Just a quick note about this. I have admit that I didn't watch the video, but rather I've skimmed through it with the position bar. When I reached the point when boxes show the various color zones, I thought that they were not considering that there are only 256 color registers, which, coupled with the fact that the playfields require 32 registers, gives a maximum of 8 different zones to switch between with BPLCON4, less than those shown in the video. Moreover, either one of the 32 registers segments has to be left for the sprites (lowering the amount of color zones to 7) or 16 colors have to be shared with sprites.
Also, considering the color splits on horizontal basis, besides the complexity of it all, there's also the performance impact: to handle the scrolling, the CPU would have to update a large number of the Copper WAIT instructions each frame.

[roondar]

Originally Posted by saimo

Just a quick note about this. I have admit that I didn't watch the video, but rather I've skimmed through it with the position bar. When I reached the point when boxes show the various color zones, I thought that they were not considering that there are only 256 color registers, which, coupled with the fact that the playfields require 32 registers, gives a maximum of 8 different zones to switch between with BPLCON4, less than those shown in the video. Moreover, either one of the 32 registers segments has to be left for the sprites (lowering the amount of color zones to 7) or 16 colors have to be shared with sprites.
Also, considering the color splits on horizontal basis, besides the complexity of it all, there's also the performance impact: to handle the scrolling, the CPU would have to update a large number of the Copper WAIT instructions each frame.

Yeah, it's all much more complicated than it looks. Admittedly, I'm less worried about the performance impact - though there will be at least a minor one to be sure. I'm more worried about keeping it all working and inside of the limits of the palette.

That said, I suppose a version of what they show ought to be possible with few issues. For example, having a single horizontal split between the boats should definitely be possible without too much issues. You can probably scale this up somewhat, but like I said I'm not completely convinced all of what they show for their ideas on horizontal Copper splits can be done even on a static screen. However, I'm more than happy to eat crow on this if they pull it off

[saimo]

Agreed.
Whether it's doable or not depends also on whether the game is supposed to run at 50 fps on a stock A1200. For example, this (from 21:34 in the video)...



... has 10 colors zones: given that it's 2 more than the hardware can offer, the Copper and/or the CPU have also to update the COLORxx registers dynamically. Moreover, there are 80*2 + 64*5 = 480 horizonal color splits that need to be adjusted each frame. And that's just for this single boat - and we know that the whole scenery is quite richer
Asking the stock A1200 to handle all of this while rendering the big characters (possibly) flipping them in real time, handling the AI (I have no idea of how refined/demanding it is, though), etc. sounds a bit too much to me.
On top of that, actually, even if with proper programming it's possible to have the Copper WAIT+MOVE couples end precisely where the horizontal color splits happen (provided that the color zones are at least 10 pixels wide), still that can't be done at odd boundaries, so I'd say that, regardless of the speed, it is not possible to achieve exactly what shown in the video.

Just for clarity: I'm not saying that the base concepts are not valid, just that they've been a bit over-optimistic.

[saimon69]

Still not a coder but i think there are many misconceptions on the blitter/copper system works; me too i thought in the past that was possible to achieve a simil-tile system using it thanks to the 8 pixel horizontal increment (not counting the parameters change time) and the OP of the video got same misconceptions as i did;