Snes Transparencies, A Temporary Solution?


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.


I am hoping once we ditch linux and coders have full access to the hardware we will get some great speeds with sound on these tougher emus. That is what I am hoping anyway.
 
Last edited by a moderator:
The Linux problem is that almost the only people who don't want it are the "non-coders". Linux makes developing and debugging loads easier than if you were working directly over the hardware, yeah, it might get in the way when trying to directly access the hardware, but for the majority of coders the former is preferable.
 
The Linux problem is that almost the only people who don't want it are the "non-coders". Linux makes developing and debugging loads easier than if you were working directly over the hardware, yeah, it might get in the way when trying to directly access the hardware, but for the majority of coders the former is preferable.

Linux has many restrictions. For one thing it doesn't allow the efficient use of both cores in emulators. It is mainly just designated for video decoding.

It doesn't allow for reading the screen state or something like that, which is the reason that there is no palette switching in DrMD (ex: water effect in Sonic). It doesn't allow for "banging the metal". This is needed for things like this SNES emu to get good accurate emulation at a good speed.

It doesn't allow the use of the full 64 MB of RAM. I think it was said that only 24 MB was left after linux was loaded. This means trouble for large ROMs in NeoGeo emulation, among other things.
 
Last edited by a moderator:
Thats bullshit davec, you have full access to the hardware from Linux (apart stuff that is used by Linux of course, like the mmu).

Using both cores in Linux is EXACTLY the same as in raw hardware as you access them in raw hardware, same with 2d hardware and stuff.

You can as well nmap more than 24mb of memory, the only thing that gets in your way are some reserved addresses (framebuffer and so on) of course its a bit more work than letting Linux do it, but thats also how you would do it without Linux.

There are no "major" handicaps when using Linux, of course it takes a few mb ram away and a few cpu cycles, but i don't think its more than a few %.

Feel free to correct me / prove me wrong.
 
The major problems linux causes (for me) are:
  • Virtual/Physical addressing and not being able to translate between the two, which means the memory is effectively split in half.
  • You can't efficiently use the hardware acceleration features due to the above.
  • No access to the mmu, meaning memory >32mb is uncached and unbuffered.
  • No access to IRQ's, so:
    • Stuff like screen swapping on VBlank becomes much more difficult.
    • Communication between the two processors, DMA, hardware acceleration/etc has to be done via bus hogging polling system instead of the way it was designed - an efficient interrupt-driven system. For example, the blitter could be much faster if the processor was put to sleep whilst the blit was in process so the blitter has full unrestricted access to the memory bus.
Also, yes, large rom support is an issue. They can't be loaded into the linux section if they are too big, and the upper 32mb is too fragmented with reserved stuff to be useful either (and is much slower than the first 32mb due to the uncached & unbuffered attributes it has, and which can't be modified).
 
Yey, just optimized my previous transparency hack and now there's only a 1 fps frame drop, and it actually does more than the last one :) ie, Moving to a non-transparent area from a transparent one no longer leaves crap on the screen :)
 
how did you do the transperencys?
oh and what about useing sdk2x, would get you out of linux quite easy.

>You can't efficiently use the hardware acceleration features due to the above.
wich hardware fetures are capped by this? sdl/mnilib and the movie player seem to be able to use 2d acerlator layers and decodeing support.
 
Transparencies are currently done by guessing which layers are going to be transparent against what backgrounds, and then drawing those backgrounds and only drawing every other line of the guessed transparent layers (in practice, it's a little bit more complex, but thats the basic idea).

sdk2x isn't finished yet - it doesn't have proper file system support for example. It does have SD support, but not proper file system support yet.

All hardware features are capped by that. It doesn't stop you from using them all-together, it just stops you from using them efficiently. So rather than stopping the processor and entering a "wait for interrupt" mode, you have to busy-poll the relevent hardware for example. In the case of the blitter, this means you are using valuable address bus cycles that the blitter could otherwise be using, and therefore actually slowing it down.
 
That's good to here Squidge. I hope this 'hack' doesn't drop compatibility too much.
 
It's completely optional - you decide whether you want it on or not. It works really well in Megaman7, but really screws up the first part of the game in Castlevania, so needs to be disabled for that. There will be further transparency hacks however, it'll just be a case of finding the correct one to use.
 
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.

That's the best post of the week. Thank you! I would sig that if I believed in sigs.
 
Last edited by a moderator:
Here's the current code:

http://www.squidgey.plus.com/pre/squidgesnes.gpe

I'd advise copying your existing directory to another name (ie. making a duplicate) and then installing this into the new directory. It's a little faster due to some code differences, but the main thing is the transparency hack. It works nice on Megaman7 on the water levels, and a few other games where you can't see where your going, but games with transparency in the background (eg. Castlevania) it really screws up.

Don't forget to enable the hack in the options screen.

THIS VERSION IS ALPHA! IT IS NOT FOR PUBLIC RELEASE
 
i saw this "fast sprites" options in some emulators for different emulators.
but what is the meaning of it actually? (or what is the advantage not having them enabled?)
 
The Transhack doesn't crash with Zelda: Lttp, but it just shows black for all of the background and shows the rain on top of it. I think we need a better solution. :/
 
Back
Top