18 March 2017, 10:34 | #81 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
I already have the US Gold version graphics from Codetapper's website, and I can make the first playable demo with them. And I can easily "emulate" the drawing stress of the arcade character sizes by simply making the BOB image areas bigger; so the actual arcade graphics files aren't yet needed in this experimentation phase. And when or if the playable demo is one day ready, then we can make more accuracte plans on what size gfx to use, and what stuff needs be ripped from the arcade. --- Also 25 FPS, although an acceptable frame rate for 128 colors, isn't really ideal for a game like this. So I'll make further tests to see if I can make this run at 50 FPS, without sacrificing the color amount and screen size too much. Yesterday I just noticed that using 32 pixel fetch mode instead of the 64 pixel fetch mode actually freed 4 sprite channels, which could be used for two 64 pixel wide 16 color sprites. Which is good, but if the characters are in 64 colors, then the 16 color sprites can't be used for them. But I'll experiment more to see if more sprite channels can be made available somehow, and also I'll test how things would look in 64 color mode, with some kind of combination of 48 color backround and 16 color BOBs and sprites; that might even run at 50 FPS, which would be awesome. |
|
18 March 2017, 11:32 | #82 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
Fireballs could be sprites. They could be 7 foreground colors or so.
|
19 March 2017, 10:55 | #83 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
Although I made some tests, and it seems that by disabling the larger AGA fetch modes and smooth scrolling, and decreasing the screen size to 288 pixels, I could display four 64 pixel wide sprites in 16 colors, in a 128 color mode screen. But this had the side effect of being able to draw only 6 fireball BOBs at 50 FPS before slowdown. But of course the characters themselves could now be made with the sprites, because two 64 pixel wide sprites are enough for one character. Although this would mean a shared 16 color palette for all characters, while the backgrounds would be 64+ colors, but this might be OK if the game ran at 50 FPS, as it most likely would thanks to both fighters being sprites. But I'll experiment further to see what would be the best solution. |
|
12 July 2017, 04:33 | #84 | |
Posts: n/a
|
Quote:
As you can see it does without character shadows and no screen scrolling! MSX hardware has notorious shortcomings regarding screen scroll, so it was preferred to skip this part and even so, I have to say, the gameplay is solid enough and I dare say it plays more like SF2 than any of the official Amiga ports we had. So, at this point the mighty Amiga is behind a 8-bits computer regarding SF2... Something should be made regarding this. |
|
05 May 2018, 10:51 | #85 |
Registered User
Join Date: May 2018
Location: Belgium
Posts: 4
|
Hi,
Quite interesting work. I am pretty sure we can get close to the arcade version because honnestly Us Gold version doesn't honor the system. I hope a demo can be made to show what could have been done. [ Show youtube player ] [ Show youtube player ] [ Show youtube player ] [ Show youtube player ] YS |
08 July 2019, 12:02 | #86 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
This was a good project any news?
|
10 July 2019, 17:45 | #87 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
However, some time ago I made another SF2 test, this time for A1200, using dual PF and sprites from the SNES version. If you haven't seen it yet, then check it out: http://eab.abime.net/showthread.php?t=96990 |
|
10 July 2019, 19:03 | #88 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
Is it ok to poke around and maybe ask a few questions about the code?
What effect do you think it would have on speed vs memory to have the sprites stored split into pieces as they were on the original? http://codetapper.com/amiga/rips/street-fighter-2/ :looking at these sprites it doesn't look like combining different combinations of Tops and Legs creates more frames does it? and I thought this was the point to slice up the graphics Last edited by Retro1234; 10 July 2019 at 20:51. |
10 July 2019, 22:42 | #89 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Storing sprites split into pieces that are aligned vertically (for instance a 16 pixel high strip of a sprite, followed by another 16 pixel high strip, etc) shouldn't have much of an impact. You might need a few more blits or a slightly more complicated hardware sprite setup, but that overhead should be pretty small.
Doing the same horizontally (i.e. 16 pixel wide strips) would be much worse for performance. This is due to the way the Blitter does it's drawing: it always draws on 16 pixel boundaries and needs to use shifts to draw on non-16 pixel boundaries. But those shifts mean the Blitter has to draw an extra 16 pixels. You can sometimes get around it, but most games just draw the extra 16 pixels all the time. Perhaps this example makes it more clear: To draw a 64x16 bob at any given coordinate you like, you make the Blitter draw 80x16 pixels. The extra 16 are for the shift I mentioned. To draw 4 bobs of each 16x16 (which is the same size), you make the Blitter draw 128x16 pixels. The extra 64 pixels are the 16 pixels for shifting each of the four separate objects. So, if you split up a bob/sprite in multiple segments, it's best to do this so that you have the full width every time. |
11 July 2019, 01:06 | #90 |
The Big White Cat
Join Date: Jan 2005
Location: France
Age: 44
Posts: 828
|
As there is many people who dreams about a decent SSF2T on amiga ,many threads about this game, and there is such talented coders with lots of ideas, what about making an open source contest for the best SSF2T tech demo ( or full game ) .
I think ideas or code parts could be better known for those who are interested in and can motive some guys who have left their projects because they where stuck on some parts . It could also be a starting point to know wich language and tricks to use to do such a game, and can motive to begin a new project Last edited by Rochabian; 11 July 2019 at 01:14. |
11 July 2019, 01:30 | #91 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
Personally I just don't think it's worth the trouble, or indeed the many, many years it would take for very competent programmers who knew the system inside out...
Street Fighter II, or any in the series will never be good on the Amiga for various reasons; mainly the controls / lack of buttons but also regarding just how difficult it would be to get arcade perfect, even on ultra high spec Amigas. This is never going to happen in reality, sorry guys. Just play via MAME; end of |
11 July 2019, 16:57 | #92 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
The lack of buttons is essentially a fixed problem these days - just attach a Mega Drive or Playstation to Amiga adapter and use CD32 pad mode. That should be enough buttons
As for playability - I think that's were the real challenge lies and I'm inclined to agree with DamienD on that. Too much time needed to get it right. Hardware wise: if you can accept a compromise or two (i.e. target AGA and run it in Dual Playfield mode, accept the 15+16 colour graphics), it should be doable even without super in depth Amiga knowledge. An AGA Amiga such as the A1200 can display two Street Fighter 2 character sized objects and update them each frame with plenty of raster time to spare. So, if you want arcade perfect down to the pixel: DamienD is right, the Amiga won't manage. If you can accept a "console level port", it's probably feasible. Is this worth it? Depends on who you're asking. Some think ports that are less than perfect are useless, others like the idea of seeing how far the hardware can be pushed to get as close as possible. I lean towards the second of those two. |
11 July 2019, 19:32 | #93 | ||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
The amount of memory saved by this would vary depending on the character, but I would estimate around 20 % memory save, maybe slightly more in some cases. And the speed loss would be maybe 5 % to 10 %, depending on how the splits are done, and how many pieces there are. But having just 2 big pieces like the US Gold SF2 has would still be fast. And sometimes the splitting can actually speed things up. For example look at the Balrog "super punch" frame: it would be a huge blit if drawn as a whole, but when split the overall bob size is a lot smaller, saving both memory and making it faster to draw. Quote:
For example look at the E.Honda sprite sheet: he has many different punch animations, many of which use the same leg parts. Also some of these splits simply make big frames smaller: for example hands, feet or heads are "cut" from the main image to make the frame smaller, or torsos are separated from the bigger leg parts. |
||
11 July 2019, 20:09 | #94 | |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,519
|
Quote:
At the end i think what we want is a playable version, has not necessarily to be one-frame-super-wonder! |
|
11 July 2019, 21:41 | #95 | |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
Quote:
Also saving chip ram these frames could be stored in reverse? Is there enough memory for that 1mb only I'm only interested in the ECS version but as you found out from your AGA tests I believe an AGA version could be very very good because the Characters can be displayed as "sprites* not Bob's. And Super Street Fighter 2 already shows that the gameplay is possible. It might be possible to rip the AI from the Arcade version or Amiga Super Street Fighter 2 Last edited by Retro1234; 11 July 2019 at 21:47. |
|
14 July 2019, 14:04 | #96 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
Even with an ECS Amiga of 1 MB of true chip RAM (A600 and A500+), it would still be hard to squeeze both left and right versions of sprites into that 1 MB. Maybe doable with 8 color sprites, but with 16 or 32 color sprites it's hard. 1 MB sounds like a lot, but it needs to hold everything: the program executable, double buffer bitmaps, background graphics, music, sound effects, and so on. So to make it fit, in all likelyhood you would still need a real time mirroring routine for the sprites. --- If you want to store both left and right versions of every frame, then 2 MB of chip is the minimum. For my AGA demo I counted that the SNES sized graphics would fit into 2 MB, both left and right versions, and there would still be enough space for everything else. But almost the full 2 MB Chip would be used, and even then some animation cuts were needed. |
|
14 July 2019, 14:24 | #97 | |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,773
|
Bummer,
Quote:
Last edited by Retro1234; 14 July 2019 at 14:31. |
|
15 July 2019, 01:20 | #98 |
CaptainM68K-SPS France
|
As said earlier, going for ecs is a nonsense. Aga + fastram + hard drive + 68030 is the only way to go at minimum.
|
15 July 2019, 01:23 | #99 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 8,986
|
Quote:
|
|
15 July 2019, 16:35 | #100 | ||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
Although in Blitz Basic both the Leg and Body parts would be Shape objects. And when a Shape is flipped with the "Flip" command, it stays that way. And so this happens: 1. Player walks right. 2. We flip all leg Shapes to right. 3. All walking frames, both body and leg parts are now facing right. 4. Then fighters jump over each other and switch sides. 5. And now we need to flip all walking parts to left, both body and leg Shapes. And so we end up with Flipping the full frames anyway. Although now that I think about it, there is a workaround to this, and that is to have all frames stored in a Bitmap instead of Shapes, and then every frame we use GetaShape to grab the correct Leg and Body parts, and then Flip one of them. But I think "GetaShape" is quite slow in real time use, and so is "XFlip". It would work, but it would still be slow, thanks to the slowness of the Blitz commands involved. But with a faster horizontal flipping routine this is certainly a good idea. And yes, this way the animation frames have hope of fitting into 1 MB. Quote:
Or maybe both mirroring and unpacking could be used at same time, as some people have mentioned in other threads. |
||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
New Street Fighter 2 for CPC !! | dlfrsilver | Retrogaming General Discussion | 140 | 09 April 2017 20:12 |
Street Fighter 2 | weirdreams | Retrogaming General Discussion | 4 | 20 June 2012 23:15 |
Street Fighter 2 credits | dlfrsilver | HOL contributions | 8 | 20 October 2010 12:46 |
Street Fighter 3 gfx found. | Thorham | project.Sprites | 1 | 22 September 2009 13:13 |
street fighter | stuntpup | project.WHDLoad | 5 | 30 August 2007 20:45 |
|
|