Snes Transparencies, A Temporary Solution?

[FluffyPanda]

Just out of curiosity, are you using the hardware blitter? Doesn't that support any kind of masking mode?

I don't know jack about the blitter hardware in the GP2x, but it seems kind of odd in this day and age to have hardware that can't handle a transparent layer like that.


Also, I've not been on these boards all that long, but when did DaveC become everybodies favourite flame target? And why? Seriously, he must be the only person on these boards who gets flamed in threads he's never posted in! :blink:

 

[FluffyPanda]

However, disable transparencies completely and you remove a shedload of code and processing time as you don't even have to bother to look for it.

The way transparencies seem to be rendered now is that they are just opaque (I looked at CastleVania IV and the mist in the beginning is solid rather than transparent, but still there). So obviously those layers are still being rendered, they are just not doing the addition or subtraction per pixel, those operations are left out to conserve speed.

Ah, I think I see. It isn't the actual colour merging operation that takes the time, but polling the layer to see if it's a transparent one and then applying it appropriately.

If that's right then I have to admit to being surprised. It sounds like a few extra if statements to me... but then I've never written an emulator

 

[Mudi]

The atmospheric effects in Secret of Mana and Chrono Trigger (among a bunch of other RPGs) might be a good transparency to test on, and they are really fast to get to in the game...

 

[DaveC]

You do have to admit that it is a bit ironic that someone who rants about "accuracy" (i.e. no stretching, blurring, smudging of colors etc etc) thinks it is a "good idea" to have transparencies rendered at every other line (ugh, that is ugly) etc.

Again, not that I care either way ... just ironic.

​

It is actually very simple and not ironic at all.

Playing 1:1 requires no extra CPU and shows all of the games graphics pixel per pixel nothing is missing and no blur is added.

This solution may be the difference between no transparencies at all and a compromise that will allow graphics that would be missing to show. Obviously I prefer true transparencies but if the hardware is not strong enough this is better than nothing.

 

[Minkoff]

Obviously I prefer true transparencies but if the hardware is not strong enough this is better than nothing.

​

The hardware probably is strong enough. We're already seeing fast, though transparency-free, emulation with a C sound core and a completely unused 266MHz CPU. Also, Squidgey did say that this wouldn't help much... so, let's leave it to him.

 

[Morwynd]

You do have to admit that it is a bit ironic that someone who rants about "accuracy" (i.e. no stretching, blurring, smudging of colors etc etc) thinks it is a "good idea" to have transparencies rendered at every other line (ugh, that is ugly) etc.

​

DaveC is simply suggesting something that would make it MORE accurate than it is now.

How is that ironic or inconsistent?

 

[God Ginrai]

I've just found what appears like water in Megaman9 near the start and move a little to the right and it goes up and down the screen as you hop on a small craft made of what looks like woodish. Perfect

Actually, scratch that. Megaman9 causes the DMA routines to fall over :/ Time to find another game.

​

Another good idea would be Zelda: A Link to the Past. The Rain, and the escape to the sanctuary both use Transparencies I think.

 

[rokdcasbah]

http://john.quarkct.com/gp2x/castlev-trans.zip

squidge, inside you will find:

1. a file of a certain that i'm probably not supposed to post a link to here but it's for the greater good. i'll take it down shortly. it's "castlevania: dracula x"

2. a save state about 10 seconds into the game where, as you will see, "background layer 3" contains a transparent flame effect.

it's not totally cut and dry as the flames also do some sort of shifting around but hopefully this helps a little.

edit: the file's been taken down. hopefully those who want it know of other places to get it

 

[Squidge]

Thanks rokdcasbah Also, I seem to have found the exact picture DaveC has posted in Megaman7, and generated a nice little save state for that one.

Hmmm, me has a cunning plan Most likely will be incompatible with some games, but it may be useful for some, so probably ok as a hack item... Lets just call it using the hardware how it wasn't supposed to be used

Damn, I could so much more if I had proper access to the hardware. I can see myself using a trampoline shortly and shufling linux off to the recycle bin

 

[DaveC]

Thanks rokdcasbah Also, I seem to have found the exact picture DaveC has posted in Megaman7, and generated a nice little save state for that one.

Hmmm, me has a cunning plan Most likely will be incompatible with some games, but it may be useful for some, so probably ok as a hack item... Lets just call it using the hardware how it wasn't supposed to be used

Damn, I could so much more if I had proper access to the hardware. I can see myself using a trampoline shortly and shufling linux off to the recycle bin

​

Is that "HH" mode still being done or has that project died? That would probably be the best. The sooner we ditch linux the better. It has been a SNAFU from the lack of direct hardware access, to the GPL tirades of the GPL freaks.

Do you think this dithered transparency trick could give us zero CPU hit transparencies?

If your "cunning plan" is using a different technique will it be as fast and compatible as the dithered transparency trick? If so maybe you could put in an option somewhere as "accurate" and "fast and compatible"

 

[rokdcasbah]

i don't think any particular program having direct hardware access alters the gpl issue at all...the key thing being that there is a product being sold in violation of the license. please note that i'm not trying to start another needless debate, just pointing something out.

 

[Squidge]

HH is still in the cards, and is slowly becoming more and more useful.

The dithered and other methods will not give zero cpu hit transparencies. That is still pretty much a pipedream. My cunning plan will hopefully be fast, but I seriously doubt it will be compatible (eg. it'll only work with games that use mode 1 backgrounds, and will totally corrupt any games that attempt to subtract or add multiple background layers against the main screens background layers, and possibly further side effects).

Having accurate transparency would involve changing most of the graphics code across several files, and would seriously reduce speed. Thats not really an option.

The problem is that you can't just say "This part of the screen will be transparent, so draw it slightly differently" or "this background layer has x% transparency". You are just given two screens - a subscreen and a main screen, and both have 4 backgrounds. You then have to take the main screen and add or subtract the subscreen against it. Drawing the main screen saps enough enough processing power, never mind drawing the subscreen as well, and then finding out which pixels would actually make a noticable difference (otherwise you'd end up dithering the entire screen as soon as color addition/subtraction was enabled). So the current version of the code tries to guess which layers out of both screens should be drawn, and draws them on top of each other. This is still not simple however, as every pixel drawn has to be checked to see whether it needs to be drawn on top of the current surface or below it (ie, ignored), depending on it's priority.

However, if my cunning plan works, it will give the same looking effect (opaque line, transparent line) as your original suggestion, just done in a completely different way, and much less compatible. It would probably be best in the long run to allow a second, manual way to apply the "opaque line, transparent line" effect to individual layers as well as the automatic (guesswork) approach. This would at least allow you to play games such as Megaman7 past the water levels.

===

EDIT: Hmmm, my idea actually seems to work (In megaman7, at least). Speed drops from 30fps to 28fps when the hack is enabled. Not bad, but probably not good enough for DaveC

 

[DaveC]

However, if my cunning plan works, it will give the same looking effect (opaque line, transparent line) as your original suggestion, just done in a completely different way, and much less compatible. It would probably be best in the long run to allow a second, manual way to apply the "opaque line, transparent line" effect to individual layers as well as the automatic (guesswork) approach. This would at least allow you to play games such as Megaman7 past the water levels.

===

EDIT: Hmmm, my idea actually seems to work (In megaman7, at least). Speed drops from 30fps to 28fps when the hack is enabled. Not bad, but probably not good enough for DaveC

​

Howcome the PSP SNES emu has full sound and full transparencies at full speed? Is it really *that* much more powerful than the GP2X? It is only 333 MHz, but I guess the memory is much faster or the CPU is better. Well I guess it would have to be to do that. That is too bad, now all PSP fanbois will always wave their perfect SNES emu in our face Hopefully there will be more tricks but it seems full SNES on the GP2X hardware is just out of reach still, right?

I noticed that the sound is rather garbled too , would using the fixed sound core from Reesy's updated GP32 version help that any?

Well 28 vs 30 FPS is not too bad. The only question is how many games will be compatible with that. Good luck.

 

[Radek]

However, if my cunning plan works, it will give the same looking effect (opaque line, transparent line) as your original suggestion, just done in a completely different way, and much less compatible. It would probably be best in the long run to allow a second, manual way to apply the "opaque line, transparent line" effect to individual layers as well as the automatic (guesswork) approach. This would at least allow you to play games such as Megaman7 past the water levels.

===

EDIT: Hmmm, my idea actually seems to work (In megaman7, at least). Speed drops from 30fps to 28fps when the hack is enabled. Not bad, but probably not good enough for DaveC

​

Howcome the PSP SNES emu has full sound and full transparencies at full speed? Is it really *that* much more powerful than the GP2X? It is only 333 MHz, but I guess the memory is much faster or the CPU is better. Well I guess it would have to be to do that. That is too bad, now all PSP fanbois will always wave their perfect SNES emu in our face Hopefully there will be more tricks but it seems full SNES on the GP2X hardware is just out of reach still, right?

PSP has an 3d accellerator with things like the Z-buffer and alphablending. You can do transparencies by utilizing it without putting any higher load on a cpu.

Yes - it's giving for such effects many times more power than gp2x has.

If snes on PSP hadn't access to 3d hardware then it'd have the same problems like we have with gp2x.

 

[Tobriand]

Incidentally, another hack that might be worth turning on. seeing as this time (as opposed to on the GP32) there are 3 more buttons than on a snes controller, might be to add a simple option to scanline each layer if, say, both volume buttones were held plus another. Thus you wouldn't even need to *test* for transparencies. You rely on the user to wait until they need to see through something, and then do what everyone used to before zSnes implemented it's 16-bit mode - namely, cycle through layers until you find the one that's behaving badly.

Doesn't work all the time, but having a quick shortcut to switch Layer 3 especially to a semi-transparent scalined mode (quick shortcut being key) would work perfectly well imo for those transparencies that the hack does not pick up.

And since you're relying on the user to pick up that a given layer needs to be only partially on to continue the game, you eliminate the transparency testing code (and keep those precious frames, methinks...?)

Just a thought, as ever....

 

[Squidge]

Howcome the PSP SNES emu has full sound and full transparencies at full speed? Is it really *that* much more powerful than the GP2X? It is only 333 MHz, but I guess the memory is much faster or the CPU is better. Well I guess it would have to be to do that. That is too bad, now all PSP fanbois will always wave their perfect SNES emu in our face sad.gif Hopefully there will be more tricks but it seems full SNES on the GP2X hardware is just out of reach still, right?

Why are you always so negative? A few points:

This emu has been in development for what, under 3 weeks? Compare that to the PSP version of several months, probably more. Rather than be disappointed, you should be happy that there is progress. There are lots of things to try yet, don't assume everything is impossible from the first test.

Your comparing a 200Mhz machine to a 333Mhz machine. That's a 66% increase. Of course the second one is going to be much faster. You can't expect the 200Mhz one to do the same job at the same speed of the 333Mhz one, it's just not possible. Overclock the GP2X to 333Mhz, and you can bet most games play speed with full sound.

 

[gaterooze]

What Squidge has achieved in 3 weeks is INCREDIBLE. Who knows how much better it will get in time, as more tricks are discovered, etc.

Just enjoy the journey, DaveC -- it's a blast seeing what these amazing coders can do

 

[DaveC]

Yes what Squidge has done is great so far. I am just concerned about the hardware limitations. At first we thought the second core may help but it seems like it may not be as useful as we once thought. No one has been able to do anything with it to speed up emulation. Maybe that is the limits of linux. Flush linux and then maybe we still have a chance to be close. I guess we will have to wait and see, and hope.

 

[Minkoff]

I think by this Sunday (if that's when Squidgey normally does releases) we may already see a very large improvement with speed/vsync.

EDIT: And to clarify, one that uses the 2nd CPU to speed things up significantly.

 

[Hanz™]

Yes what Squidge has done is great so far. I am just concerned about the hardware limitations. At first we thought the second core may help but it seems like it may not be as useful as we once thought. No one has been able to do anything with it to speed up emulation. Maybe that is the limits of linux. Flush linux and then maybe we still have a chance to be close. I guess we will have to wait and see, and hope.

​

I am willing to bet we are not reaching any sort of hardware wall yet.