02 December 2016, 14:07 | #41 | |||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
Quote:
I'll try to fit the demo into as small space as possible, but if it needs Fast, then I'll use it. And then, with the one level demo running with 2 fully animated characters, we can then try to optimize RAM use further, and see if it can be made run with just 2 MB Chip. But if Fast is needed, then it still might be OK for me; the three existing SF2 conversions for the Amiga are so dissapointing, that if a good version can be made with 2 MB +1 MB Fast, then maybe it should be done...and I would still get kicks for beating those 3 games with a Blitz Basic game. Quote:
Those look like all the frames for the characters in question. I tried to save to Ryu sheet image as a 32 color IFF and the file took 384 KB of space. This number of course includes all the black space too, but it gives us an idea; when transparency mask cost is added to each frame, the total RAM cost might be close to this 384 KB. Also I did a quick test on how many Amiga version Ryu standing frames would fit on a 320*256 bitmap, also as size comparison I put two of the larger sprites from Elfmania: The frames in the Amiga version are smaller than in the arcade version, and so 18 frames fit into one bitmap. Some moves would take up more, but in many cases arms and legs can be separated into smaller BOBs, and so a typical punch frame for example is composed of the fist arm + main body. I counted that if all Ryu frames were of this Amiga size, then they would fit into eight 320*256 bitmaps. So two fighters of this size would fit into those 16 320*256 bitmaps that we had space for in our RAM plan. Although there is a small problem, and that is that we also need mirrored versions of all frames. Blitz has "XFlip" and "YFlip" commands that can easily mirror anything. But this command is way too slow for real time use. It can be used before the game starts to create mirrored versions of the frames, but both left and right facing frames have to be stored in RAM at the same time. So, even if we used the smaller character frames, they might not fit into the 2 MB...so in fact Fast RAM might be needed even if we cut frames and made things smaller. And also, how much Chip RAM the A1200/AGA can "address" or "see" at one time? I assume it's the 2 MB? And so all GFX and sound and display buffers have to fit into that 2 MB, even if the code and other stuff is put to Fast RAM. And BTW, I don't have a clue how to actually "use" the Fast RAM; so even if we decide to use it, I would then just hope that the Blitz executable automatically goes there when it's loaded, and that GFX and sound automatically go to Chip RAM. --- Also, the arcade version runs in 384*224 resolution. Our current game area screen in this demo is 288*210. So horizotally our screen is about 100 pixels smaller. This is another reason why smaller characters are better: the arcade versions would fill too much of the screen area, and all fighting would be constantly at "close range". So I think that character size should be about the same as in the Us Gold version, but the GFX of course should be made better, with right colors and polish, using the arcade version GFX as a reference. If done well, it would still look great, despite being slightly smaller and missing a few frames. And for animation frame amounts we should probably use the SNES and Us Gold version frame amounts as a reference, and also looking at the frame amounts of similar games like Elfmania and Body Blows could help. In Elfmania for example a lot of the animation "smoothness" comes from the "walking" and "standing" frames; they use lots of frames, but many attack and jump frames are more simple. But in 50 FPS even a 3 frame animation looks smooth. --- Having the Us Gold version sprite sheets is great, I think I'll try to load two of these sheets into the demo, and then add mirrored versions and transparent masks, and then see if it fits into 2 MB, or even to 2 MB + 1 MB Fast. |
|||
02 December 2016, 14:36 | #42 |
Registered User
Join Date: Dec 2013
Location: GR
Age: 47
Posts: 1,416
|
you could improve the ugly palette of the original a lot i think.
(16 colors palette i did) |
02 December 2016, 20:05 | #43 | |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
Quote:
I'd think everygame would do the xflip at runtime, but it seems I am wrong! |
|
02 December 2016, 20:27 | #44 |
CaptainM68K-SPS France
|
|
02 December 2016, 21:00 | #45 |
Registered User
Join Date: Dec 2013
Location: GR
Age: 47
Posts: 1,416
|
|
02 December 2016, 21:08 | #46 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
And those cool palette swaps might be 100% possible to do also, because in the last few days I have been brainstorming about a flexible 16 color BOB / sprite palette system. --- The palette system that I have in mind is somewhat complex, so to describe it properly I made this big "info image": I think it should work OK, but read through the descriptions of the steps and see if you can spot any potential problems. In a nutshell it's a 16 color palette system for all BOBs and sprites, and these colors are palette entries 16-31 in our 32 color palette. The first 16 colors are reserved for backgrounds only. 6 of the colors (black, white and skin tones) can't be changed, but all others can. 3 colors are reserved for "fighter 1" and another 3 colors for "fighter 2". These color sets are "safe". And the remaining 3 colors are "extra colors" that can be freely used for anything, but they are not "safe", and can change depending on selected character combinations. After fighters have been selected, the GFX are loaded from disk. But the GFX will be stored in disk in a special "color format": The fighters "own colors" will always be represented by "3 blues". In addition to this, 3 color entires of the palette, so called "Fighter 2 colors" are never used in the GFX stored in disk. This arrangement makes the following trick possible: Fighter 1 gets it's "real colors" through a simple palette swap of the three Fighter 1 colors. And Fighter 2 gets it's "real colors" through a pixel color change in the bitmap level; the "disk blues" in the bitmap will be changed to the three "Fighter 2" palette colors that are reserved for this purpose. After this pixel color change in the bitmap level, we can do a normal palette swap for those three "Fighter 2 colors" without changing anything else. This should give almost total freedom for character color themes; any character can be given almost any colors. I can see only minor problems, such as fireball colors being off when those "extra colors" described in the image are changed. But of course there could be a system that when Ryu or Ken are selected, the two "extra colors" (those represented by the two purples in the image) would always be set to two blues. I haven't yet really tested this, but I'll do so soon, would be pretty awesome if this works. |
|
02 December 2016, 21:13 | #47 | |
CaptainM68K-SPS France
|
Quote:
|
|
03 December 2016, 12:12 | #48 |
Registered User
Join Date: May 2010
Location: London, UK
Posts: 268
|
I don't know blitz but can you store the characters in two halves, the top half mirrored. You only need to flip half the character each time then. The frame time to write would also be predictable for every frame. Also, and again I don't know anything about blitz, could you use inline assembler to code your own optimised flipping routine for this purpose?
|
03 December 2016, 17:23 | #49 | ||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
But the Blitz XFlip command would still be too slow to do this at run-time; there would be a visible "stop" at each XFlip. And almost every scenario when real-time mirroring would be needed looks like this: Fighter 1 is facing right, and has right facing frames in RAM, and Fighter 2 is facing left and has left frames stored. And then Fighter 1 jumps over Fighter 2, and both fighters turn around. And now, no frames are ready in RAM. So for every action that the fighters now take, for each frame we need to XFlip these animation frames in real time. And this is too much for the Blitz XFlip command, even if only half of each character would need to be flipped. Quote:
So, for the demo at least, I'll just simply store all frames to RAM and worry about mirroring later...according to my calculations about 1,4 MB of Chip RAM might be enough to store both left and right frames for all animation frames and both characters, if the characters are of the same size as in the Us Gold version. And if the code runs from Fast RAM, then we can freely use the whole 2 MB of Chip RAM, and this method might even work for the whole game, and there would still be space for musics and other stuff. Some Amiga games are known to use real-time mirroring; I think Final Fight was one of them, and it has extremely large characters, although they were only 16 color. So it can be done, but only with ASM, and even then I don't know if it would be possible to keep a game like this running at 50 FPS with constant mirroring of two 32 color large (and multi-part) BOBs. |
||
03 December 2016, 20:35 | #50 | |
Registered User
Join Date: Dec 2014
Location: germany
Posts: 440
|
Quote:
For sprites the code is quite easy, as they are in 16 bit wide stripes, so it's only necessary to flip the words themselves, not their order, as you can do this by changing the sprite positions: Code:
; this flips a 16 bit word in memory using byte table ; a0 - source, a1 - dest, a5 - flip table (byte based) move.b (a0)+,d6 move.b (a0)+,d7 move.b (a5,d7.w),(a1)+ move.b (a5,d6.w),(a1)+ ; this flips a 16 bit word in memory using word table ; a0 - source, a1 - dest, a5 - flip table (word based) move.w (a0)+,d6 move.w (a5,d6.w),(a1)+ The byte based version can be written to perform only one write access, which can speed things up if chipram bandwidth is low (lots of bitplane/blitter DMA). It uses two 256-entry word tables where the flipped byte is in the high/low byte, e.g. $XX00 and $00XX, as the 68000 has no byte-swap instruction (rotation is slow). Code:
; this flips a 16 bit word in memory using byte table ; a0 - source, a1 - dest, a5 - flip table (low byte), a6 - flip table (high byte) moveq #0,d7 ; +4 cycl move.b (a0)+,d7 ; +8 cycl add.w d7,d7 ; (table is word size), +4 cycl move.w (a5,d7.w),d6 ; +14 cycl moveq #0,d7 ; +4 cycl move.b (a0)+,d7 ; +8 cycl add.w d7,d7 ; (table is word size), +4 cycl or.w (a6,d7.w),d6 ; +14 cycl move.w d6,(a1)+ ; +8 cycl For bobs wider 16 pix you need to change the word order, too. For a 32 pix BOB e.g. (a,b,c,d,e,f,g,h) is getting (b*,a*,d*,c*,f*,e*,h*,g*), where each letter is a word and * indicates the flipped word. For 64 pix it is (d*,c*,b*,a*,h*,g*,f*,e*). A 86*86 6-plane-BOB (5 planes +mask) would take ~144k cpu-cycles per flip, or 7.2M per second at 50Hz - that's slightly more than the cpu in the a500 has available. With a word-table half of that. That's quite steep, but do you need all animation in 50Hz? One could e.g. use only the basic moves at 50Hz (and store them flipped), while having the special moves in fast ram at 25Hz unflipped. Another, slightly unconventional approach would be using Stephane Dallongeville's lz4w decompressor, which is just amazingly fast - it is in fact slighty faster than the word-table-based flip approach, and the code is much smaller (8kb) than the word table (128kb). So you'd have compressed frames for both directions in memory, as long as compression ratio is around 2:1, it's more memory effective and faster. The animation data should compress reasonable well. BTW, you'd need to compress every frame on it's own, as you can't stop the decompression after n bytes easily. So no inter-frame compression. Last edited by chb; 03 December 2016 at 20:42. |
|
04 December 2016, 04:16 | #51 | ||
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,357
|
Quote:
However, a corkscrew scroller costs blits, which a plain scrolling bitmap doesn't. And blitter time is valuable in a game like this (as in any action game). Quote:
|
||
04 December 2016, 09:41 | #52 |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,798
|
I'd also argue, that half of what makes Street Fighter 2 the game it is apart from its graphics is the gameplay and especially the enemies AI.
I have done some lightweight fighting game AIs in the past, and I'd say that modelling SF2s enemy AI behaviour is not an easy task. |
04 December 2016, 11:27 | #53 | |||
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Quote:
Code:
moveq #0,d0 move.b (a0)+,d0 move.b (a5,d0.w),(a1)+ move.b (a0)+,d0 move.b (a5,d0.w),(a1)+ Quote:
Mean Code:
moveq #0,d6 move.w (a0)+,d6 add.l d6,d6 move.l (a5,d6.l),(a1)+ Quote:
Code:
moveq #0,d0 ;4c move.b (a0)+,d0 ;8c move.b (a5,d0.w),d1 ;14c move.b (a0)+,d0 ;8c add.w d0,d0 ;4c move.w (a6,d0.w),d0 ;14c move.b d1,d0 ;4c move.w d0,(a1)+ ;8c ;total 64c About SF2. Another idea is to keep only left frames + turning frames and during the turning of player to the right you can just flip that left frames. It depends of how many turning frames you have, then you can divide time of flipping. Last edited by Asman; 04 December 2016 at 11:43. |
|||
04 December 2016, 12:33 | #54 | |||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Thanks for the ASM mirroring code examples guys. Maybe if we could somehow integrate methods like this to the Blitz "Shapes", then it might be possible to use them.
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. 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". Quote:
Quote:
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. Quote:
|
|||
04 December 2016, 12:41 | #55 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,438
|
Quote:
Such a thing could be enough to go over the frame budget, obviously. But I don't consider the overhead to be that big. Quote:
|
||
04 December 2016, 18:12 | #56 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
However, it showed that updating the Shape image data by taking it from bitmaps on-the-fly can be done without problems. So if ASM flipping would be used, we don't actually need to worry about the Blitz "Shape" thing. Instead a normal fixed size (such as 80*80) Bitmap can be used: the shape is Blitted to it, and then mirrored with the ASM routine, after which we load the mirrored image back to the Shape. This Shape image updating process is slow in itself, but maybe not too slow; I noticed only a small delay of a few frames when trying it out. So if the ASM mirroring was fast enough, it might be fast enough to be used. And there is a Blitz command with allows us to create a Bitmap into a certain fixed memory location. From the Blitz Manual: --- CludgeBitMap BitMap#,Width,Height,Depth,Memory " CludgeBitMap will create a bitmap object with the proportions for that specified using the memory location given. Of course, the memory location specified must be in chipmem and it is upto the user to ensure that sufficient memory has been allocated. " --- So, could an ASM mirroring routine be used to this CludgeBitMap? If we know the memory location and the X and Y size of the Bitmap, then is this info enough to mirror the data in that "CludgeBitmap" using one of those ASM routines? Although I don't know to what memory location it would be safe to create this CludgeBitmap, or how to even how to check if some Chip mem location is free or not. Maybe a command exists for this too, I have to check. --- --- And about the corkscrew scrolling method, I think there also was some problem with the "border zone", when blitting BOBs that went over the edge of the Bitmap, and so two "partial" blits were needed in this zone. And Blitz has a command for this too, called ClipBlit, but I think it had some limitations, and it was slower than a normal Blit. And also, if tiles would need to be blitted, then I think this would need to be done for three bitmaps at once, because we now use Triple Buffering. So it might slow things down quite a lot, although RAM would be saved. But also lots of different tiles would be needed, because almost every 16*16 area in the levels look different. And these would probably eat up some of the RAM that was saved. So I guess that I would only considering using the corkscrew method if RAM usage would become critical, and no other option was available. And before trying this, I would rather first abandon stuff like Triple Buffering, which I might actually do anyway, if the Sprites bring us enough extra speed. |
|
04 December 2016, 20:42 | #57 |
CaptainM68K-SPS France
|
what you call corkscrew scrolling, is named Line-dscroll. That's what is used for the ground, it moves per line.
I wonder how many CPU cycle it takes on Elfmania, which has an excellent line-scrolling for the ground |
05 December 2016, 11:26 | #58 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
I just read some more about ASM use in Blitz, and it's actually much more simple than I thought, and we don't need that "CludgeBitmap" thing either.
Blitz variables and start addresses of any Blitz object can be put to data registers using the GetReg command, such as: GetReg d0,Addr BitMap(0) And to put data register values back to Blitz variables, PutReg is used: PutReg d1,VariableName.w And direct ASM commands can be put straight into the Blitz code to do operations with these data registers. Sounds simple enough, I'll test if I can get some of the mirroring code pieces posted here working using these commands. Quote:
And also Elfmania seems to be running in 32 color mode...and some of the colors are reserved mainly for the characters, which creates nice contrast between them and the backgrounds. Although the character colors can be sometimes seen in the backgrounds too, but they're usually used for small details only, like some flowers in the waterfall stage. And I think it's always the skin tones that appear in the backgrounds, but never the cloth colors, although I could be wrong. And I think this is because the cloth colors of any character can change quite a lot, between the blue-purple-white ranges; but the skin tones always stay inside a certain color boundaries, although they too have light changes depending on level. And so the skin tones are "safe" to use in the backgrounds too. So maybe it uses a similar system that I described a few posts ago, free color select for the "main cloth colors" for each fighter + shared common colors for skin tones and black & white, that can be used in backgrounds too. This system gives the backgrounds 16 colors + skin tones + black & white, for a total of some 23 colors, boosted by copper effects that can be safely used for those 16 BG-only colors, and this basically turns it into a 64+ color game. And most background animations in the levels are simple rectangular BOB areas with no transparency mask needed; this makes them fast to draw. (and Blitz too has a perfect command for this sort of blitting called "Block", that I hope will be fast enough to add the BG-animations too) And also Elfmania uses the same screen width that we now use: 288 pixels. |
|
05 December 2016, 12:35 | #59 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,213
|
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. |
05 December 2016, 13:19 | #60 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@DanScott
In this approach you still will need more memory to copy and flip objects. |
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 |
|
|