Snes Transparencies, A Temporary Solution?


D

DaveC

Internal Development
Joined
Mar 4, 2004
Messages
9,208
As we all know transparencies can slow down SNES emulation so severely that they are eliminated. The current solution is to leave them off, or to make them opaque. That is fine for some things but many games can't be played that way for various reasons.

Would it be possible to do it like this where every other line is not rendered on the transparency layer? It could also be done with a "checkerboard" fill pattern. This is done anyway on many older system to simulate shadows etc. It gives a cheap and dirty pseudo transparency that would make many games that use them more playable without slowing to a crawl. Sure it doesn't look as good as true transparency but it is better than nothing at all.

Couldn't this be done by setting up memory locations or something that could and couldn't be written to by the transparency layer to give very fast results? I think SquidgeSNES may benefit from this.

snestransparency.png
 
If transparencies slow down emulation so much, then how come DrMDx doesn't have problems? (just wondering)
 
DaveC posted on Jan 25 2006 said:
As we all know transparencies can slow down SNES emulation so severely that they are eliminated. The current solution is to leave them off, or to make them opaque. That is fine for some things but many games can't be played that way for various reasons.

Would it be possible to do it like this where every other line is not rendered on the transparency layer? It could also be done with a "checkerboard" fill pattern. This is done anyway on many older system to simulate shadows etc. It gives a cheap and dirty pseudo transparency that would make many games that use them more playable without slowing to a crawl. Sure it doesn't look as good as true transparency but it is better than nothing at all.

Couldn't this be done by setting up memory locations or something that could and couldn't be written to by the transparency layer to give very fast results? I think SquidgeSNES may benefit from this.

snestransparency.png

​
Click to expand...

This is a valid idea and should be fast and easy to implement. However there some others, better I think - similar topic was discussed here.

My idea was to use Arm9 32 bit ALU as some kind of vector unit. Example below:
Code: 
;In R1 and R2 are 2x2 source pixel in 5-6-5 RGB format.
;R3 contains a bit mask:    "11110111110111101111011111011110"
;              RGB bits:     RRRRRGGGGGGBBBBBRRRRRGGGGGGBBBBB
;first/second 16bit pixel:   11111111111111112222222222222222
;R0 will have a final output of mixing.

AND R1, R3; zero first bit of every R, G, B scalar
AND R2, R3; the same as above but for second source pack
MOV R0, R1, LSR #1; divide by 2 first pixel pack
ADD R0, R0, R2, LSR #1; the same as above but for second pack and add results

; That's all - in R0 are results of averaging two packs of two 16bit RGB pixels!
; (effectivelly processing 6 scalars in one go)
; This code should (not counting load/store) execute in just 4 cycles on Arm9.
; This means one transparent pixel per 2 machine cycles. The problem is reduced
; accuracy as every scalar has zeroed first bit. But it's fast...

Once I get SDK running and figure how to use assembler and C compiler I will do some demos. edit: (blah - once I figure how to compile gpe executable I should say instead)

For now I have prototypes made in Python and they are working.
 
Last edited by a moderator:
God Ginrai posted on Jan 24 2006 said:
If transparencies slow down emulation so much, then how come DrMDx doesn't have problems? (just wondering)
​
Click to expand...


Because there arent any transparencies in Megadrive ;) Only raster interrupts for water per scanline and that isn't implemented.
 
Last edited by a moderator:
what about using the flashing transparency? method where you show the sprite every 2 frames as is used on loads of MD games and such

or do it with the checkerd board but every other frame the checkerd board is inversed such as is used for the shields on sonic 1
 
If we all shut up and let the pros handle it, noone would get anywhere fast. o.o

Anyway. It's a valid point that DaveC makes. It would be very fast, but there are better ways of doing it. The one already mentioned here probably would work, but I have no idea how. =(.

The way I would do it (and am, in fact, for my game), is predetermining what each colour would change to if you laid another colour over the top, in a 256*256 array. Unfortunately, we don't have infinite RAM, nor immense clockspeeds, so it cannot be applied to the SNES Emulation, and if it could, we wouldn't need it, because:
256*256*256 (colour1*colour2*alpha) takes up 16mb of RAM. Take into account loading times for creating this table each time the palette is changed, and it all goes belly up.

You COULD do it your way, if you alternated which line was being missed out. It would flicker, though, and give people seizures. (Er.. as the person above me said before I posted =x)

And what IS a raster interrupt?
 
CyberAxe posted on Jan 24 2006 said:
what about using the flashing transparency? method where you show the sprite every 2 frames as is used on loads of MD games and such

or do it with the checkerd board but every other frame the checkerd board is inversed such as is used for the shields on sonic 1
​
Click to expand...

I think that flickering would be real distracting.
 
Last edited by a moderator:
Could someone point me in the direction of some technical docs on the snes? I am interested in how a real snes does transparency.
 
Khatoblepas posted on Jan 24 2006 said:
If we all shut up and let the pros handle it, noone would get anywhere fast. o.o

Anyway. It's a valid point that DaveC makes. It would be very fast, but there are better ways of doing it. The one already mentioned here probably would work, but I have no idea how. =(.

The way I would do it (and am, in fact, for my game), is predetermining what each colour would change to if you laid another colour over the top, in a 256*256 array. Unfortunately, we don't have infinite RAM, nor immense clockspeeds, so it cannot be applied to the SNES Emulation, and if it could, we wouldn't need it, because:
256*256*256 (colour1*colour2*alpha) takes up 16mb of RAM. Take into account loading times for creating this table each time the palette is changed, and it all goes belly up.


And what IS a raster interrupt?
​
Click to expand...

By using a fill pattern of some sort you would lose NO speed at all. As soon as you start averaging pixels and calculating you have lost framerate.

Raster interrupt? That is when the palette is switched during horiz re-trace period. It works great for getting more colors on the screen than you are supposed to have but with the limitation that it only works in horizontal sections. Those many colored raster effects on the ST and the Amiga used it to get more than the normal 16 and 32 colors on screen. The Megadrive uses it (most commonly) to divide the screen into water sections like in Sonic.
 
Last edited by a moderator:
you forget that we have hardware layers, it may be posibil to just draw the transperencys to another layer and set ti to teh wished transperence.
I hav eno idear how many layers the snes itself managed, but maybe theres could be mapped 1:1 on the gp2x's layers and than used for cheap transperence? (complete layer at once)

Also i think syncro did put it pretty clear, i am sure squidge knows better what he does than any of us.
 
You must log in or register to reply here.

Similar threads

D
Possible Solution For Snes Transparencies
Replies
10
Views
2K
DaveC
D
C
Snes Transparencies
Replies
7
Views
2K
nickspoon
nickspoon
T
Transparency Sorting On The Sgx
Replies
3
Views
1K
darkblu
D
E
I Love Squidgessnes
Replies
0
Views
719
evol
E
T
Oh No Not Another Pocket Snes Thread! [f200]
Replies
6
Views
1K
toady
T
Back
Top