Snes Transparencies

[camokid]

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.

 

[Radek]

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)

 

[camokid]

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.

 

[Squidge]

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?

 

[rokdcasbah]

you might want to play around with lunar magic, which is located at http://fusoya.panicus.org/lm/program.html

it is an editor for super mario world. i know it's possible to rip/dump sprites from games...but unless you know asm it's probably tougher to get them back in.

 

[Radek]

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)

 

[God Ginrai]

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.

 

[nickspoon]

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.