ZSNES board

What, so 5% more people can use your program? I'd just as well expect them to get a PC emulator or dual boot windows to the same degree you'd expect someone to code 3D in OpenGL just for them. Should the coder choose a specific API to cater to 5% more people or should the 5% of people cater to the ...

Nifty. let me see if I can get it working right.

Bahamut_ZERO_939 wrote:. Yes I know SDL wraps to DirectX when used in Windows

Directx 5, SDL wraps to DX5. Something rather important to note.

unless the memmap info for a ROM comes from the cart that originated it, its suspect.

My guess is, the minimal DX8 SDK doesn't have proper support for direct sound?

Nightcrawler wrote: Sure if you know something about that stuff. I've never programmed a single thing using TCP in my life.

Its really easy.

the image that all snes emulators display is one untouched by the hardware the snes uses to convert it into something the TV understands.

if you can, get a hold of a DVD with a THX optimizer, make sure your TV is setup correctly.

I dunno, you could just say, have zsnes dump the requested data to a file, or a piece of shared page.

or, use IP and work it that way.

Local Procedure call might be worth looking at.

Ichinisan wrote:I'm sure a feature like this will come anyway when the new GUI materializes...

and still be a pain in the ass to implement.

what happens if you pass an argument before the rom?

This is a bug in libc IIRC.

sane way to do it would be to have a FAQ forum, and add stuff as questions come along

What exactly are you doing with your controller that SDL cannot handle? More importantly, you are talking about the difference b/w DX 7 and DX 8, which has nothing to do with SDL. Why do you assume it would be worse? SDL on windows is a flimsy wrapper to DX anyways, and linked to only use DX5. So y...

pspad is godlike.

i'd perfer WxWidgets over gtk.

and SDL isn't really at the same level of functionality as DX. I think all the input improvements made with the switch to DX8 would be lost.

they intend it to be modular, so a native Win32 API GUI wouldn't be out of the question.

because no single snes emulator team has enough people to properly start from scratch. if everyone decided to start a new one from scratch, designing the thing could take six months to a year before any coding gets done on it. and the vast masses of snes emu users wouldn't care beyond when the next ...

Agozer wrote:SRM files are interchangeable(sp?) between the two emulators.

yes, because they are just dumps of the Save RaM of the roms

I used blackbox with a mixture(mostly GTK) for a while.

but, real men use tar.

600 functions in one file, or 600 functions in 600 files.

same crap. different piles.

there is an an option when you create users along the lines of "protect my files from other people"

tho, if you set your cousins up as limited users, they shouldn't be able to see any of your files, outside of those you put in the shared folder.

test this.

for the sake of proper preservation of data, well eventually need to move from emulation to simulation of the snes.

like it or not, those carts still contain info outside of the ROM, even if its only how the traces exist on the PCB.

yeah.

these filters are crap. lets add random noise in a vain attempt at simulating the image displayed on a inferior device. ya!

if you can't code this yourself sprite, then I doubt you'll see this in snes9x or zsnes anytime soon.

I don't think many people have taken into consideration overscan.

ATI linux drivers bite.

yeah. install the proper drivers for your video card.

yeah. someone drank alot of coffee.