About Snes Emulation


Series-8 said:
I think a Hybrid tile, pixel by pixel render is the way to go. (SNES may have a wimpy CPU~ but it has non-wimpy PPU chips)

Mind you it will be 100% ARM9 ASM. leveraging the MMSP2 2d hardware.

It would have to be many stages:

Stage 0:

Background Tiles;

Would convert all SNES background tiles into a 16Bit Type format,
(Paying attention to each tiles pallet (mid-frame pallet fiddling is argh!))
and buffer these in memory. (I'd rather have it create new tiles for pallet change than change all the tiles, burn, memory, burn!)

They just get fast, block moved to the frame buffer. (possibly using rotation of the 2D accel. too.)

There is a background tile map, that keeps track of what is where. If the background map is changed, but still only scrolling up/left/right/diagonnaly/down (e.g not a whole new screen) then the tile buffer is just shifted over with a MMSP2 memory block move
That's basically what I was going to try for gpSP. There are drawbacks to this approach though, you trade a lot of computational complexity for cache inefficiency down the road. However, you don't need to shift the map, that isn't how these updates work (at least not in GBA games). The games simply modify a row/column/both and update the horizontal/vertical offsets. This relies on the wraparound of the maps, but is much less expensive for the game than updating the entire thing.

But storing 16bpp isn't good because of midframe palette changes, and it uses more memory (again cache efficiency), it's better to expand the colors line by line.

Series-8 said:
There are actually 4? layers of background tiles, thus transparency / mask data is also stored in the tiles.
The MMSP2 2D Accelerator supports this. ( I think, the docs arn't the clearest)
If it supports colorkeyed blits then that can be used. SNES colors are "only" 15bpp so you can use the remainding pixel for this, but you want are paletted 8->16bpp blits (don't know if it supports these).


Stage 2 (0):

Series-8 said:
Mode 7.

Either brute CPU matrix transforms on the 'stock' layer rendered by stage 0, or possibly with some matrix transform help from the MMSP2 video??? decode hardware (????).

This Stage actually takes the output of stage 0 and messes with it basically.
I REALLY don't think that the 2D hardware on GP2X supports arbitrary linear transforms like SNES. However, transforming a bitmap is less computationally expensive when it isn't chunked into tiles (and again, less cache efficient too)

Stage 1:

Series-8 said:
Sprites;

They render right on top of the now background filled fb for that frame.
(in the render order the SNES uses of course)
Except they can appear beneath the background layers.

Series-8 said:
Trick A:
Areas that have not had any sprites cover the tile area are skipped over from the last frame.
(Assuming the Stage 1: tile buffer is not 'dirty' -- the background is the same)

This stage is actually using a modified version of the Stage 1 pipeline (Tiles), except sprites are like tiles that can be anywhere and have alpha channel information (true transparency)

and there are fewer of them, and they have more complex order. The MMSP2 may also handle sprite clipping(?)
I don't think so. Keeping track of how dirty the screen is sounds like overkill and it really shouldn't be necessary when the overall amount of work has been reduced. I also don't think that the MMSP2 can do all of these 2D tricks, but clipping can possibly be cheated by extending the scanline space and overdrawing.

Series-8 said:
only standard sprites with no colour addition or subtraction (only rotation and mask information)
Sprites on SNES don't rotate/scale.



Series-8 said:
Stage 3:

Transparency layer;

HDMA and other funky layered effects, especially colour addition.
(for sprites and backgrounds)

It may be possible to use lots of indexed pallets, thus transparency effects become 'cheap'~
It makes a cross-lookup pallet for each colour combination.
There are more palette combinations than there are pixels on the screen, and changing a palette entry or blend settings requires changing every last one of them.


Series-8 said:
Or not as the SNES has a 15-bit total pallet...
(MMSP2 supports 16-bit in hardware) -- but only for games without any transparency / colour addition...

Thus no nasty colour addition math per pixel / line. Just fast lookup of a pre-cooked value in a table somewhere. (assuming sprite A does not cover Sprite B and Sprite C, just background 1/ 2/ 3/ 4, ect...)

Do any SNES games have sprites that use colour addition / subtraction with MANY sprites?

E.g: More than 2?
The thing here is that even with saturation control performing color addition/subtraction in software probably isn't going to be slower than looking it up in a huge cache inefficient table (remember, only 16KB of dcache here)

If SNES is like GBA in this regard then overlapping sprites don't blend correctly. But color addition/subtraction is usually used for a background layer.

Series-8 said:
I just had a stupid idea.

The LCD makes colour addtion rather tricky... (RGB5:6:5 conversion, pallet lookup insanity,ect... and SNES many and strange pallets)

The TV output has all kinds of video --nee scanline type fiddling capabilities...

Why not have colour addition ~ and perhaps HDMA like effects on that instead of messing about with a frame buffer (s).
Okay, that one totally lost me, doesn't that mean you'd have to use the TV output? And I somehow doubt it'd support what you want, HDMA can refer to a whole lot of things on a per scanline basis, like windows, the palette, scroll registers (wavy effects), matrix registers (3D effects), etc.
 
Last edited by a moderator:
Squidge said:
Sure, we could rewrite the bulk of a snes emulator in asm, but why do that when we can remove effects such as transparency and raster effects, and then watch you spit bubbles and bitch like crazy on the forums?
...
Any more stupid questions?
What? You mean, like, that being an obnoxius whiner and raising forum hell as soon as someone does something not entirely like I WANT IT TO BE DONE has consequences? As in, like, pissing people off and discouraging people? Why, I'd never... :blink:

...Sarcastic? Me?

Apart from that, I'm with Naples in liking the dual renderer idea. I guess I'm not enough of a floodposter to make a difference in the general stream of feedback, though...
 
Last edited by a moderator:
wow i see coding isn't as easy as i thought it was

and i thought it was hard to begin with :)
 
damned said:
wow i see coding isn't as easy as i thought it was

and i thought it was hard to begin with :)
The hard part isn't the coding, it's ignoring the morons that think anything that runs slow can just be quickly rewritten in asm for an instant speed up.

Oops, sorry, I was only thinking that, didn't mean to type it ;)
 
Last edited by a moderator:
Hah hah, I'd thought most on the slow parts already ARE in ASM. (and ARMs are pretty lean and mean chips)

I'm hoping the 2D MMSP2 hardware can cut down on some overhead to tackle the ugly problems (darn transparency and Mode 7).

Also I'm pretty sure sprites can scale and rotate. Remember Super Mario Worlds Final boss (Bowser?)

(I think it may actually be Mode 7???)


What I'm talking about is actually two things:

-Simple rotation~ rotate 90 degrees, 180 degrees, 270 degrees. <- 2D Hardware supposedly handles this.

-Arbitrary Rotation (Mode7), Brute CPU transforms on a bitmap.


Also the Tile engine would render TO a bitmap(?)

There is one question however~ the docs mention the destination always as 'display' for ROPs which does not mean that its a arbitrary FB somewhere in memory, but could be a dedicated HW frame buffer that can only be written to... which would be very problematic for the tile renderer.

Also the stages must be recursive~ it loops thru the stages many times to compose a screen.

ALSO I keep a copy of the LAST rendered layer; (tiles not sprites)
Thus for screens that have not scrolled;
No full reconstruction the scene is needed, just one BIG FAT Blit over to the output FB, and the other layers rendering on top.

Hence the need to keep track of what was where last frame.

I think the clipping can work also; I just cut whatever part of the sprite is clipped out from the template area with a Blit and stick that onto where-ever.

Does anyone actually know the MMSP2 2D hardware at all? Has anyone even tried to use it?

I'd really love to see even a crude comparison on some basic tile engine performance.
 
"The hard part isn't the coding, it's ignoring the morons that think anything that runs slow can just be quickly rewritten in asm for an instant speed up."

Squidge is right. Assembly isn't an optimization. It's a language. Remember that. And don't forget that lovely GCC compiler reduces that higher level C/C++ code to assembly when linked. You can output that assembly, and fine tune it even. But sometimes GCC outputs good code! THere are many times rewriting something by yourself in "ASM" makes things SLOWER!

It's like saying, don't speak English because it's a slow language. Speak Spanish, it's faster. Sometimes you forget you're talking to a 90 year old man with a slur!
 
Series-8 said:
Hah hah, I'd thought most on the slow parts already ARE in ASM. (and ARMs are pretty lean and mean chips)

I'm hoping the 2D MMSP2 hardware can cut down on some overhead to tackle the ugly problems (darn transparency and Mode 7).
I'm going to say that the 2D hardware can neither blend nor do aritrary affine transformations, not from anything I've seen on it.

Series-8 said:
Also I'm pretty sure sprites can scale and rotate. Remember Super Mario Worlds Final boss (Bowser?)

(I think it may actually be Mode 7???)
Yeah, it's mode 7. Easy to make an entire layer look like a sprite when it's the only thing scaling and rotating. Before you mention Yoshi's Island as another example, I'm pretty sure it was done in "software" thanks to the SuperFX chip.


Series-8 said:
What I'm talking about is actually two things:

-Simple rotation~ rotate 90 degrees, 180 degrees, 270 degrees. <- 2D Hardware supposedly handles this.
But these are so fast to do in software anyway, you'd may as well integrate it into another step. That and things aren't usually rotated in these nice increments.


Series-8 said:
-Arbitrary Rotation (Mode7), Brute CPU transforms on a bitmap.
Also the Tile engine would render TO a bitmap(?)

There is one question however~ the docs mention the destination always as 'display' for ROPs which does not mean that its a arbitrary FB somewhere in memory, but could be a dedicated HW frame buffer that can only be written to... which would be very problematic for the tile renderer.

Also the stages must be recursive~ it loops thru the stages many times to compose a screen.



I'll leave you to those thoughts >_>

Series-8 said:
ALSO I keep a copy of the LAST rendered layer; (tiles not sprites)
Thus for screens that have not scrolled;
No full reconstruction the scene is needed, just one BIG FAT Blit over to the output FB, and the other layers rendering on top.
You can't do this because the sprites need to be rendered inbetween the layers, not on top of them, unless you do Z-compare (but good luck fitting this in within the rest of the hardware rendering model you have)

Series-8 said:
Hence the need to keep track of what was where last frame.

I think the clipping can work also; I just cut whatever part of the sprite is clipped out from the template area with a Blit and stick that onto where-ever.

Does anyone actually know the MMSP2 2D hardware at all? Has anyone even tried to use it?

I'd really love to see even a crude comparison on some basic tile engine performance.
I think all of your ideas are just looking at the SNES hardware in too much of a simplistic way, it's really pretty tricky. It's a lot worse than a software game engine would be. I won't elaborate too much from there, but I don't think you'll get highly compatible results with an approach that's too high level. You need to break it down to correctly account for each nuance.. I won't go into tremendous detail though.
 
Last edited by a moderator:
Series-8 said:
I'm hoping the 2D MMSP2 hardware can cut down on some overhead to tackle the ugly problems (darn transparency and Mode 7).
It can do neither very well. Ie, It can do transparency, but it's more of a "If this color is transparent, then don't bother drawing" rather than the snes's color addition/subtraction technique. It can do rotation in 90 degree chunks, but this means that both the source and destination must be uncached and in physical memory. Easier to do it with the processor. No one has yet done in-memory scaling - all people have done is set the LCD scale registers which just adjust how it appears.

Series-8 said:
Also I'm pretty sure sprites can scale and rotate. Remember Super Mario Worlds Final boss (Bowser?)
Sprites can flip on the H & V axis. That's all.

Series-8 said:
There is one question however~ the docs mention the destination always as 'display' for ROPs which does not mean that its a arbitrary FB somewhere in memory, but could be a dedicated HW frame buffer that can only be written to... which would be very problematic for the tile renderer.
Blitter can use any physical/uncached area of memory, and apply any ROP to it stated in datasheet.

Series-8 said:
ALSO I keep a copy of the LAST rendered layer; (tiles not sprites)
Thus for screens that have not scrolled;
No full reconstruction the scene is needed, just one BIG FAT Blit over to the output FB, and the other layers rendering on top.
Nice idea, but what happens if the rom decides to change a palette or tile entry half-way down the screen? (seems quite common). Your going to have to check every pixel in every tile of that saved rendered layer to see if it needs changing. At that point, you may as well regenerate it.

Series-8 said:
I think the clipping can work also; I just cut whatever part of the sprite is clipped out from the template area with a Blit and stick that onto where-ever.
Thats fine until some game decides to use HDMA to alters the registers half way through a screen update.

On the Genesis/Megadrive, lots of emu's got away with ignoring all drawing operations until the end of the frame and then doing everything then. Your techniques would work very well in that situation. However, in the SNES world, doing that just gives you a black screen on a large number of games (as the screen is usually changing several times per frame via HDMA), so its not really practical.
 
Last edited by a moderator:
Series-8 said:
Still even before I would evaluate the performance (and write something) of this I'd need:

#1. Learn ARM9 Assembly.

#2. Learn MMSP2 HW Registers properly

#3. Learn Linux Kernel level driver implementation

#4. Learn exactly HOW the SNES's PPU chip works (and its glitches and oddities)

#5. Hope that there are no weird surprises (Like not being able to convert the colour spaces correctly 15-bit palletized RGB is NOT the same as 16-bit 5:6:5 RGB. Half-High colour to High-Colour (not True colour).
Also possible bad effects from overclocking, due to memory timing changes. And/or the fact that the 2D hardware just may not be enough.
Totally leaving alone the idea of using MMSP2 for SNES emulation. The list above is a good point to mention something, which is probably clear to most here.
There are lots of guys who would love to optimize SNES emulation (including me), but to do so, one must master at least #1, #4 (I would add here: knowing how an emulator work). I am able to code arm9 asm and are highly motivated to try to squeeze every possible optimization out of it, but nothing more. On the other side are some guys here who know perfectly how the SNES and an emulator work.
I guess you all got the point now. We have maybe reached a state where it is not possible for ONE individuel to reach the goal. Why not try to build up a team for optimizing SNES?
 
Last edited by a moderator:
Is there a GP32 SNES emulator? Maybe someone could continue Spot. ;P
 
Alternatively, has anyone yet tried the GBA SNES emu? Ok, it's squished onto a teeny emulated screen, but well, maybe it'd run at a decent speed on GPSP. Doubt it, but it's always possible.
 
This thread is full of laughs and win ^_^

SNESAdvance doesn't have sound though, and I don't think anyone would be willing to accept that (that and it's probably slower and far less compatible than what anyone has anyway)

It'd be an interesting way of getting gpSP's renderer to do SNES instead >_>
 
QUOTE
It'd be an interesting way of getting gpSP's renderer to do SNES instead >_>


Go Exophase! :)

(Saves me having to do it ;) )
 
Squidge + Exophase + ZodTTD = Portable SNES emulator? I'm in if you guys are.
 
Probably have better luck with notaz getting onboard. Squidge and Exophase are usually quite busy. :)
 
Back
Top