Street Fighter 2 GFX Test

[Master484]

Question about the Amiga data management, is it better if i put for example Ryu per animation bank in horizontal row, or better in vertical row ?

Maybe horizontal row is better. That's how I always put GFX frames to IFF images in my own projects. So for example I would put all walking frames to one row, and all jump frames to another row underneath it, and so on.

As much as a fast ram version would be better, i think the whole point you started was to better the awful US Gold version in the same limitations was it not Master484?

Well, the original goal was just to make a small demo that would be better than the Us Gold version, preferrably running on same hardware: A500/A600. But even this demo that I posted already exceeded the 512K Chip + 512K Slow configuration because Triple Buffering took so much RAM. So now it needs 1 MB Chip, with 2 MB minimum very close, and a Fast RAM requrement isn't so far away either.

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.

For a comparison of how the Amiga sliced up the various graphics, have a look at an early rip entry for Street Fighter 2 containing the graphics for 5 of the characters.

Very interesting, somehow I had forgotten that your website had these GFX rips. This is great material that can be used as a reference at least when designing the GFX frames.

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.

[nobody]

you could improve the ugly palette of the original a lot i think.

(16 colors palette i did)

[Shatterhand]

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.

This is a problem I had when coding with Blitz. Is this a limitation of the language or is a hardware limitation?

I'd think everygame would do the xflip at runtime, but it seems I am wrong!

[dlfrsilver]

Originally Posted by nobody

you could improve the ugly palette of the original a lot i think.

(16 colors palette i did)

Try to do the same for the 12 fighters please

[nobody]

[Master484]

you could improve the ugly palette of the original a lot i think.

(16 colors palette i did)

Wow, these look awesome indeed.

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.

[dlfrsilver]

Originally Posted by Master484

Wow, these look awesome indeed.

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.

excellent !!!

[spud]

Originally Posted by Shatterhand

This is a problem I had when coding with Blitz. Is this a limitation of the language or is a hardware limitation?

I'd think everygame would do the xflip at runtime, but it seems I am wrong!

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?

[Master484]

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.

That could indeed be one possible method; top parts of a character could be stored in RAM in both right and left versions, but leg parts would only have one direction stored in RAM, and then we would only need to XFlip the leg part when needed.

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.

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?

Yes, inline assembly can be freely added to Blitz code, and this is most likely the only way to mirror GFX in real time. But I don't know anything about assembler coding. And also such a routine would need to be compatible with the Blitz "Shape" system also, and I don't know how complicated that would be.

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.

[chb]

Originally Posted by Master484

Yes, inline assembly can be freely added to Blitz code, and this is most likely the only way to mirror GFX in real time. But I don't know anything about assembler coding. And also such a routine would need to be compatible with the Blitz "Shape" system also, and I don't know how complicated that would be. 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.

Mirroring in asm is best done using a flip table, which just contains for every value the flipped one of it. You have two possibilities: byte- or word-based. A byte table is 256 bytes, a word word table 65536 words = 128k. The tables should reside in fast ram. Word based is around 2x faster than byte based.

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:

; 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 is 52 cpu cycles, word based 26 (both at full speed cpu memory access).
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).

; 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

It is a bit slower however (68 cycles), when mem speed is unrestricted.

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.

[idrougge]

Originally Posted by roondar

It depends. If you wish to scroll while keeping the full bitmap in memory, then yes - it will take a lot of chip-memory. However, the optimal way of scrolling a screen horizontally (cork-screw scrolling) uses far less memory than that.

It is possible, I suppose, that Blitz Basic doesn't support such a system natively. In which case you'd indeed need much more memory.

I have posted sources for a corkscrew scroller in Blitz here: http://eab.abime.net/showthread.php?t=81634

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).

Originally Posted by roondar

I tend to agree with this, but I do feel that a competent fighter AI will take a lot more cycles than a simple shmup enemy. Not too mention that collision detection is vital to do just right, which might mean doing quite a few more calculations than in simpler games.

While arguably more complex, there is always only one enemy and only of a single kind. That means you can optimise the hell out of your enemy, unlike systems where twenty different kinds of enemies may show up in the course of a few frames.

[Tigerskunk]

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.

[Asman]

Originally Posted by chb

; 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)+

You are missing to clear d6 and d7, so you must add 8 cycles. This gives a 60 cycles. But you can save 4 cycles if you are using only one data register like d0. Mean

  moveq #0,d0
  move.b (a0)+,d0
  move.b (a5,d0.w),(a1)+
  move.b (a0)+,d0
  move.b (a5,d0.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)+

This routine is bad. Will cause guru on 68000 machines, because of trying to read word from odd address. And you must double the d6 because of words.
Mean

 moveq #0,d6
 move.w (a0)+,d6
 add.l d6,d6
 move.l (a5,d6.l),(a1)+

Total cycles = 38 cycles.

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).

; 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

It is a bit slower however (68 cycles), when mem speed is unrestricted.

You can speed a bit this approach. First table is 00ab --> ba00 and second one is just ab --> ba. Then

	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.

[Master484]

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".

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.

This is a good idea, and maybe should be used if even ASM couldn't flip frames at 50 FPS. I remember that even the arcade version had slowdowns at certain points, although not with special moves, but during damage/falling down frames...at least in the Capcom Classics Collection version in PS2 this slowdown happens, I don't know the reason for this, but these damage / falling down frames would probably be the best candidates for "slow frames".

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.

Yes, maybe this too could be used for additional speed boost.

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.

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.

Good AI is indeed essential. It won't be easy to make, but speed wise I believe Blitz can easily handle it...it's just one complex enemy, that switches between diffrerent "combat tactics" modes (such as defensive and aggressive, and these have sub modes like long range vs close range combat), and these mode change depending on what Player does, and variables such as energy, difficulty level, and so on, with some randomness added in. It'll be time consuming to code, but the end result should run fast enough.

[roondar]

Originally Posted by idrougge

I have posted sources for a corkscrew scroller in Blitz here: http://eab.abime.net/showthread.php?t=81634

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).

This is true, though you shouldn't need that much blitter time considering you only have to blit a small part of the bitmap every frame and can use a basic copy operation.

Such a thing could be enough to go over the frame budget, obviously. But I don't consider the overhead to be that big.

While arguably more complex, there is always only one enemy and only of a single kind. That means you can optimise the hell out of your enemy, unlike systems where twenty different kinds of enemies may show up in the course of a few frames.

Well, this is true - but many simple AI routines are no more complex than 'approach player', 'move on path' or 'fire gun', which are vastly simpler than a fighter AI would need to be competent. I'm not sure which would take more time as I have not tried it yet.

[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.

I tested this idea of mine, and it was slower than doing a normal XFlip.

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.

[dlfrsilver]

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

[Master484]

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.

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

Scrolling the screen horizontally in every Y-line is probably quite fast because no actual drawing is needed, just scrolling. And I think the characters and all "foreground objects" in Elfmania are sprites, so this line scrolling doesn't affect them at all, and this is why this effect is possible to do in the first place on a standard A500.

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.

[DanScott]

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.

[Asman]

@DanScott
In this approach you still will need more memory to copy and flip objects.