Snes Transparencies


camokid

Still Fresh
Joined
Jan 24, 2006
Messages
51
Age
42
Website
Visit site
Hi

I was reading this

http://www.gp32x.de/board/index.php?showtopic=25017&hl=

and it was interesting.

It made me wonder about the methods of physically removing lines from graphics that are supposed to be transparent to create this faux tranparent effect. That would allow you to leave tranparencys as opaque.

This could be done really easily in something like photoshop, however, obviously it would take a bit of time. So i guess you'd only do it if you really needed to play a game.

Any way, is there a way to extract, and re-inject images into a SNES rom?

If so it'd be fun to give this a go.
 
Last edited by a moderator:
camokid posted on Feb 8 2006 at 05:30 PM said:
Hi

I was reading this

http://www.gp32x.de/board/index.php?showtopic=25017&hl=

and it was interesting.

It made me wonder about the methods of physically removing lines from graphics that are supposed to be transparent to create this faux tranparent effect. That would allow you to leave tranparencys as opaque.

You know what?! Just wait for a while and you will see how quickly full RGB color addition and substraction can be done... :rolleyes:
(let me say that opaque tricks like skipping scanlines are unnecessary)
 
Last edited by a moderator:
oh i'll wait, no... i cant... agggghhhh.

seriously, i can wait because it's worth it, and im amazed and awed by the great work that's going on with these emulators.

I just wanted to have a go at something myself.
 
How many times do I have to repeat the fact that its not the actually rgb color addtion/subtraction that takes the most time in snes transparencies?
 
Squidge posted on Feb 8 2006 at 06:57 PM said:
How many times do I have to repeat the fact that its not the actually rgb color addtion/subtraction that takes the most time in snes transparencies?

You were talking about some kind of surface predication in your snes emu. You also said that the only the most front surfaces are having transparencies enabled. It is looking like a workaround of some problem...
(I'm talking about your post 104 in this topic)

The problem is that there isn't enough cpu power to just render all the snes' playfields by brute force, right?

If so then then you just replaced one problem with other. This is a valid as long the efficiency was improved. But because now the workaround is consuming more cpu cycles than it's doing transparencies (as it should by its concept) it's not making the core problem (the lack of resources to brute force aproach) any less valid. Therefore the transpariences are the problem thought you managed to deal with them differently.
(and by effect they are consuming less resources thanks to it)
 
Last edited by a moderator:
Squidge posted on Feb 8 2006 at 11:57 AM said:
How many times do I have to repeat the fact that its not the actually rgb color addtion/subtraction that takes the most time in snes transparencies?
Could you make some kind of config file generator that we could use to set what layers should be transparent for which games and such? (For use with your Transhack) Then it will only guess when absolutely needed. ;)
 
Last edited by a moderator:
God Ginrai posted on Feb 8 2006 at 09:16 PM said:
Squidge posted on Feb 8 2006 at 11:57 AM said:
How many times do I have to repeat the fact that its not the actually rgb color addtion/subtraction that takes the most time in snes transparencies?
Could you make some kind of config file generator that we could use to set what layers should be transparent for which games and such? (For use with your Transhack) Then it will only guess when absolutely needed. ;)
That would depend on whether the transparent layer changes in-game.
 
Last edited by a moderator:
Back
Top