Snes Transparencies, A Temporary Solution?

[deadlychicken22]

Everything I have tried EXCEPT tetris attack has run very well speed-wise and has had only a few graphic/sound glitches. Most games run 15-30 fps but for some reason tetris attack runs at about 5-10 when you actually get into a game (the menus are much quicker). Could you please look into this? Tetris attack is one of my favorite games ever. Anyways, thanks for all of your work squidge, I will be donating once the speed is boosted a little and the graphics/sound glitches are minimized.

 

[Blah]

How about implementing the alpha (yes, thats alpha, not transparency) using a Look-Up-Table for the needed calculations...

 

[rokdcasbah]

i like calling it transparency. mostly because it pisses pedantic people off.

but seriously: http://www.gp32x.de/board/index.php?showtopic=24958&st=15
lookup tables may not be efficient in this setting, if i am reading this right, they cannot be cached all at once by the cpu. also, i'm guessing that the lookup table would have to be calculated whenever the palette changed?

but more importantly i think the reason for the "hack" is simply because
-a- the emulator's not done yet
-b- it will be someday soon but needs more optimization
-c- squidge is perhaps waiting for enough of a general speed increase in order to do transparency/translucency/alpha in a way that's closer to the way the snes does it, -d- transparency/translucency/alpha was asked for enough times that squidge decided to do a quick fix while working on more general speedups.
-e through z- limitations of the current linux implementation, hardware limitations, limitations due to lack of source and/or knowledge of a lot of the hardware, use any personal superstitions you may have to fill in the rest.

ps. ianas (i am not a squidge)
pps. brits may feel free to substitute "optimisation" for "optimization"

edit: gotta stop posting before i finish my thought.

 

[Squidge]

This is how a snes creates the illusion of transparency:

• Renders your normal screen, which may consist of upto 4 background layers plus the object layer (sprites)
• Render your 'subscreen', which again may consist of upto 4 background layers plus the object layer.
• The snes hardware then either subtracts or adds one from/to the other to create the final screen that the user sees.

Now obviously this is all very time consuming, so the way the emu works at the moment for transparency is:

• Guesses which layers are supposed to be transparent, only allowing 1 layer, and prefers the front-most layers (by looking at the priority list of the background)
• Renders your normal screen, which may consist of upto 4 background layers plus the object layer (sprites). The layer guessed to be transparent has every other line missed.

Obviously this has big disadvantages - we don't really know which layers are supposed to be transparent, and we don't know by how much they are supposed to be transparent.

The advantage is that it is more than twice as fast as proper transparency calculation.

So, regardless of the way transparencies are calculated - either through missing pixels out, using lookup tables, etc - it's not going to make a big difference. Most of the time is spent building the subscreen.

 

[Ryan]

[*]Guesses which layers are supposed to be transparent, only allowing 1 layer, and prefers the front-most layers (by looking at the priority list of the background)

Interesting post there, Squidge.

Would it be possible to allow the player to select the transparent layer themselves? You could display a list of the layers in any spare border space along with the volume bar..

At least that would solve enough of the problems being reported here to pretty much close the issue for now.

Another thing I've always thought: would it really make much difference were the emulator only to draw every other frame, with a calculated "inbetween" frame to smooth it all out.

 

[FluffyPanda]

Another thing I've always thought: would it really make much difference were the emulator only to draw every other frame

​

I think that's pretty much the definition of frameskip.

 

[Ryan]

Another thing I've always thought: would it really make much difference were the emulator only to draw every other frame

​

I think that's pretty much the definition of frameskip.

​

Yes, but with a frameskip you're litirally missing the frame out, right? Calculating the "inbetween" frames should smooth things out enough for no-one to ever notice the frameskip..

 

[Squidge]

Calculating in between frames when you have the previous and after is fine, but how do you calculate the next frame without looking to see what it is (and by which time you may as well complete drawing it) ?

Unless you mean have two seperate frame skips, say frame skip 1 for the main screen and frame skip 2 for the subscreen? That could produce some interesting results when they go out of sync...

 

[abigsmurf]

You could implement a key frame type thing where once every 10 or so seconds it fully renders it (or at a minimum checks to see if its in sync)

 

[Radek]

This is how a snes creates the illusion of transparency:

• Renders your normal screen, which may consist of upto 4 background layers plus the object layer (sprites)

• 
  
  That is 5 playfields?
  
  

  [*]Render your 'subscreen', which again may consist of upto 4 background layers plus the object layer.

  
  These are another 5?
  
  

  [*]The snes hardware then either subtracts or adds one from/to the other to create the final screen that the user sees.

Now obviously this is all very time consuming, so the way the emu works at the moment for transparency is:

So there are 10 playfields and counting from back to front?
So every playfield can be used as source of addition or substraction?
What happens when result is out of range of 5 bit per channel (SNES has 15 RGB DAC, right?), is it clipped?

What is the worst case - how many "a + b" or "a - b" had to be done per second?

• Guesses which layers are supposed to be transparent, only allowing 1 layer, and prefers the front-most layers (by looking at the priority list of the background)
  
• Renders your normal screen, which may consist of upto 4 background layers plus the object layer (sprites). The layer guessed to be transparent has every other line missed.
  

Obviously this has big disadvantages - we don't really know which layers are supposed to be transparent, and we don't know by how much they are supposed to be transparent.

The advantage is that it is more than twice as fast as proper transparency calculation.

So, regardless of the way transparencies are calculated - either through missing pixels out, using lookup tables, etc - it's not going to make a big difference. Most of the time is spent building the subscreen.

​

So there are many surfaces (from all playfields) what have to be blitted in a proper order to final one (and some of them sub or add from the ones in behind)?

 

[Blah]

[...]

but seriously: http://www.gp32x.de/board/index.php?showtopic=24958&st=15
lookup tables may not be efficient in this setting, if i am reading this right, they cannot be cached all at once by the cpu. also, i'm guessing that the lookup table would have to be calculated whenever the palette changed?
[...]

​

Alpha LUT's can be optimized for cacheing by breaking them into smaller "levels". Pea has done it before.

Squidge (below) is refering to the post above this one. Sorry for interrupting the flow...

 

[Squidge]

That is correct. Effect can only be + or -, it can not contain both. The effect can be used on all background however (bg1/bg2/bg3/bg4/objs/back-area) and be affected either by the subscreen (which contains it's own layers) or by fixed color addition/subtraction. You can also use a window mask to only affect part of the display.

The main problem is drawing the backgrounds. Not only do they have to be drawn in the correct order, but they are made up of tiles, and each tile can have it's own priority (so for example, part of a sprite object could appear behind a section of background). Drawing them is not exactly easy either, as they can have seperate color palettes, plus the data inside them is in a bitplane format, and then you can have them drawn normally, or flipped, etc...

On top of all the above comes something else to stop you optimizing too much. At the end of every screen line, the above registers may (and quite often do) change. This allows people to change the square window masks to other shapes by rewriting the registers every line, or make the picture shake or wave by adjusting the horizontal offsets.

All in all, it's quite a bitch of a system

 

[God Ginrai]

I just tried Lttp with the updated Transhack. It doesn't black out the backgrounds this time, but it only makes certain parts transparent, and its normally the HUD. It guesses the wrong layer for the transparencies I guess. :/

 

[Mudi]

Yeah, the latest version of Transhack seems to do that a lot. It's great that backgrounds seem to work in pretty much all cases now, but even in scenes where there should be no transparency it's marking some things as transparent. It's the HUD in Chrono Trigger too.

Does anyone else have problems with the reversed sprite priority with Fast Sprite drawing on, or is that a game-specific thing?

 

[jmetal88]

Yeah, the latest version of Transhack seems to do that a lot. It's great that backgrounds seem to work in pretty much all cases now, but even in scenes where there should be no transparency it's marking some things as transparent. It's the HUD in Chrono Trigger too.

Does anyone else have problems with the reversed sprite priority with Fast Sprite drawing on, or is that a game-specific thing?

​

I have the reversed spirte piroity problems. I don't have that many roms to test out, but I know it does that on Earthbound.

 

[Ryan]

Calculating in between frames when you have the previous and after is fine, but how do you calculate the next frame without looking to see what it is (and by which time you may as well complete drawing it) ?

There's a word you look for when you think about my post. It's "stupid".

 

[Mark1970]

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.

The gp2x doesn't do raster interrupts just yet in Linux. Perhaps with the homebrew firmware it will.

 

[Leshrac]

I'm not sure whether this belongs to this thread or not.

Has anyone else noticed that turning off the sound emulation actually makes games run slower? am I the only one experiencing that?

Is it a bug or a feature?

 

[naples39]

I'm not sure whether this belongs to this thread or not.

Has anyone else noticed that turning off the sound emulation actually makes games run slower? am I the only one experiencing that?

Is it a bug or a feature?

​

It's bug and only happens if you disable sound while keeping a rom open. If you restart squidgesnes and turn off sound from the get-go, most games run at or near 60 fps.