Homebrew RetroArch - A new multi-system emulator

[the_randomizer]

Question about Snes9x Next, why do games seem to run "slower" after an hour or so of game play? By slower, I mean by beginning to hear audio crackling, and slight framerate dipping on games that shouldn't have framerate issues in the first place. Is there a memory leak when one is using the Retroarch cores? Exiting and opening up the emulator seems to help, but I shouldn't have to do this every time I experience this issue.

Does this only happen with SNES9x Next or with any other core?

Didn't notice it in other cores, just noticed it in Snes9x Next, but only after 60 or so min. GenplusGX, etc all run fine but I guess it wouldn't hurt to test them more. Crap, I know I should have done that, oh well.

 

[wiikey]

Hi all
too all you retroarch users should i move over to retroarch for my emulators? what are the benefits if any?

 

[Disorarara]

Some RetroArch cores operate faster than other emulators, but it's currently lacking in features.

 

[the_randomizer]

Some RetroArch cores operate faster than other emulators, but it's currently lacking in features.

That's intentional, the more features that are added, the more memory it takes. RetroArch is constrained enough as it is.

 

[MassiveRican]

I had a question if anyone can help. There is a root folder for retroarch which has a "savestates" folder in it yet when I save my game with SNES9x-NEXT for example the save files are never there. They actually save in the same folder as the roms. I'd really like to be able to separate my save states from my games or choose a different folder for my savestates. Is there any way to do this properly or will there be support for this in the near future?

My roms are still on USB1://snes9xgx/roms is this a problem? Should I move my romset within a retroarch folder to get better save functionality?

Just seen [member='Toad king']'s comment on the savestate issue a couple of pages back so I'm glad that it could get taken into consideration. It's not a huge bother by any means but I'm into organization and classification a lot so hopefully it will be implemented. Again thanks guys for making such a rock solid emulator.

 

[Disorarara]

Some RetroArch cores operate faster than other emulators, but it's currently lacking in features.

That's intentional, the more features that are added, the more memory it takes. RetroArch is constrained enough as it is.

I know that much, It's just a comparison to other emulators.

 

[MassiveRican]

Some RetroArch cores operate faster than other emulators, but it's currently lacking in features.

That's intentional, the more features that are added, the more memory it takes. RetroArch is constrained enough as it is.

I know that much, It's just a comparison to other emulators.

True, honestly what RA does is an ends to a means. They put in as much as possible w/o sacrificing performance.

What's beautiful about this is we get the best of both worlds, u want a fancy GUI with more features implemented we have that option, if we're in the mood to play a game at full speed the way it's intended to be played, hell yea NOW we finally have that option as well and I'll add with only few features missing. Love the Wii Scene.

 

[the_randomizer]

Personally, I couldn't care less about its GUI appearance, but I only care about how the actual ROMs are emulated, and both this and Snes9xGx are as close to the real deal as you can get, yes, even more so than the virtual console (mostly due to the bilinear filtering and how it simulates the look of a CRT).

 

[the_randomizer]

I had a question if anyone can help. There is a root folder for retroarch which has a "savestates" folder in it yet when I save my game with SNES9x-NEXT for example the save files are never there. They actually save in the same folder as the roms. I'd really like to be able to separate my save states from my games or choose a different folder for my savestates. Is there any way to do this properly or will there be support for this in the near future?

That would certainly explain why I couldn't find the saves in the save directory, I thought I did something horribly wrong.

I know that much, It's just a comparison to other emulators.

Personally, I couldn't care less about its GUI appearance, but I only care about how the actual ROMs are emulated, and both this and Snes9xGx are as close to the real deal as you can get, yes, even more so than the virtual console (mostly due to the bilinear filtering and how it simulates the look of a CRT). But as for the memory leaks (which leads to a gradual loss in performance after an hour or so in Snes9x Next), I hope they look into it.

 

[StupidGamer1]

I use this emulator for GBA,arcade and pr boom. Don't like the fact it unzips roms before playing them. I stick to the other emulators for that due to the roms not having to unzip.

 

[Rydian]

I use this emulator for GBA,arcade and pr boom. Don't like the fact it unzips roms before playing them. I stick to the other emulators for that due to the roms not having to unzip.

Every emulator unzips ROMs before playing them.

The other emulators just delete the unzipped files when you're done so you don't notice it.

 

[Disorarara]

I had a question if anyone can help. There is a root folder for retroarch which has a "savestates" folder in it yet when I save my game with SNES9x-NEXT for example the save files are never there. They actually save in the same folder as the roms. I'd really like to be able to separate my save states from my games or choose a different folder for my savestates. Is there any way to do this properly or will there be support for this in the near future?

That would certainly explain why I couldn't find the saves in the save directory, I thought I did something horribly wrong.

I know that much, It's just a comparison to other emulators.

Personally, I couldn't care less about its GUI appearance, but I only care about how the actual ROMs are emulated, and both this and Snes9xGx are as close to the real deal as you can get, yes, even more so than the virtual console (mostly due to the bilinear filtering and how it simulates the look of a CRT). But as for the memory leaks (which leads to a gradual loss in performance after an hour or so in Snes9x Next), I hope they look into it.

I wasn't talking about the GUI, SNES9xGx has things like IR control for lightgun games and archive support and fast forwarding, like MassiveRican said above, it's pretty neat that we can use both emulators at our leisure.

 

[MassiveRican]

I use this emulator for GBA,arcade and pr boom. Don't like the fact it unzips roms before playing them. I stick to the other emulators for that due to the roms not having to unzip.

None of my roms are zipped only the arcade ones so it's not really an issue. I use WIiFlow to launch with retroarch and many other emu's on the backend so it's better if the roms aren't zipped anyway.

Oh man if we get IR support,fast forwarding and savestate support in other folders I'll leave every other emu behind lol

 

[Hielkenator]

Still hoping and waiting for a low res fix for PAL region wii's.
Hurray scanlines on my crt TV!

 

[Jacobeian]

I use this emulator for GBA,arcade and pr boom. Don't like the fact it unzips roms before playing them. I stick to the other emulators for that due to the roms not having to unzip.

Every emulator unzips ROMs before playing them.

The other emulators just delete the unzipped files when you're done so you don't notice it.

That's not true. Other emulators unzip files to RAM directly, there is no temporary deleted files, it would be too slow and inefficient to write one file and read two just to load a single file.

As far as i understood, Retroarch does this because it's a multi emulator framework and not all emulators provide the same way to load compressed files and using temporary RAM placeholder is too memory consuming. I guess that is the downside of making an emulator front-end that must support various existing emulators rather than making a multi-emulator where all cores are initially designed to support a common interface (like Mednafen for example)...

 

[quepaso]

I use this emulator for GBA,arcade and pr boom. Don't like the fact it unzips roms before playing them. I stick to the other emulators for that due to the roms not having to unzip.

Every emulator unzips ROMs before playing them.

The other emulators just delete the unzipped files when you're done so you don't notice it.

That's not true. Other emulators unzip files to RAM directly, there is no temporary deleted files, it would be too slow and inefficient to write one file and read two just to load a single file.

As far as i understood, Retroarch does this because it's a multi emulator framework and not all emulators provide the same way to load compressed files and using temporary RAM placeholder is too memory consuming. I guess that is the downside of making an emulator front-end that must support various existing emulators rather than making a multi-emulator where all cores are initially designed to support a common interface (like Mednafen for example)...

This is an absolutely small price to pay for how Retroarch functions. If you guys cannot afford more memory for your pirated games, please leave and dont ever come back, SD cards are so cheap its pathetic, same with USB hard drives. Less bitching about unzipping files, just keep them unzipped in the first place and you're done.

 

[Jacobeian]

honestly i don't care and i am not complaining, just explaining how i think things work because people tend to spread misinformation quite easily , and you know what happen when "someone is wrong on the internet" ^^

retroarch has lot of advantages, the major one being it makes porting emulators to various platform much more easy

 

[Rydian]

That's not true. Other emulators unzip files to RAM directly, there is no temporary deleted files, it would be too slow and inefficient to write one file and read two just to load a single file.

As far as computers are concerned, the drive and RAM are just two aspects of "memory". In fact RAM is "primary storage" and drives and such are "secondary storage". Whether the file is written to RAM and then unallocated, or written to a drive and then having the filesystem mark it as free space, it's the same concept. The file is unzipped to a location temporarily, then when it's not in use the space it was using is marked as "free to overwrite".

Which type of storage is used for this process (as it's a required process for working with compressed ROMs) can differ. In many cases, such as with the PC and other situations where RAM is aplenty, it's fine to unzip a file into RAM and then just unallocate it when it's not needed anymore... but this isn't a PC-only emulator, and it has a lot more to keep track of than normal singe-set emulators for the Wii (to the point that a fancy GUI is out of the question due to RAM limits).

The issue is that RA's simply not hiding it's tracks afterwards, so you're simply seeing the leftovers from a process that's done all the time. That's the main complaint, that it's visible.

However, we've already gone over this issue and come to the conclusion that there's no need to zip your ROMs with modern SD prices as they are. Hell, BSNES/higan has no native compression support for the same reasons.

 

[Jacobeian]

no, unzipping a file to ram and unzipping to a temporary file on a device is definitively not the same thing, if only for the operation speed.
the location in ram is not deleted and is not temporary in the way it is kept that way until you load another file, it's not copied from a temporary RAM placeholder to final RAM destination, it is directly uncompressed to final RAM destination.

uncompressing a zip file and writing it back to a temporary file then reading from this file into RAM is ALWAYS going to be less efficient than directly uncompressing a zip file to RAM, period.

i agree with he last part though, it s a design choice and limitation and is not really that much annoying in the end

 

[Rydian]

no, unzipping a file to ram and unzipping to a temporary file on a device is definitively not the same thing, if only for the operation speed.

So would running the emulator off a USB flash drive versus a USB harddrive not be the same thing either, because of the average lower write speed of a flash drive?

the location in ram is not deleted and is not temporary in the way it is kept that way until you load another file, it's not copied from a temporary RAM placeholder to final RAM destination, it is directly uncompressed to final RAM destination.

The uncompressed copy exists within the system's memory (in both RAM and drive cases) because the compressed copy cannot be used as-is.

To clarify something I mentioned earlier, files on FAT/NTFS drives aren't actually "deleted". Instead the filesystem removes the pointers to that file, effectively marking the space it occupied as "free". This is one of the things that allows programs such as TestDisk to recover "deleted" files. As long as the files are not overwritten, they can be recovered (minus filesystem metadata, such as the filename). This is the same sort of operation used to "remove" things from RAM. When something in RAM isn't needed anymore, the space it occupied is marked as free and then overwritten as needed.

uncompressing a zip file and writing it back to a temporary file then reading from this file into RAM is ALWAYS going to be less efficient than directly uncompressing a zip file to RAM, period.

False. Loading an entire 10MB file into RAM for access uses more RAM then writing a 10MB file to disk and only loading the parts that are needed at the time. RAM is so tight with this setup that the devs have killed off ideas of using a GUI (at least last I paid attention to the talk of it), so any saving (that doesn't impact on emulation speed) helps.

Swapping ROM parts being read isn't something normally thought about as most ROM-based emulation systems work with files that are considered tiny to the host machine... for example the Pokemon Platinum (U) ROM is 128MB, and loading it into Desmume causes the entire ROM to be loaded into RAM because the emulator knows that any system that could run it could very well hold the entire ROM in RAM at once (in fact a single browser tab on an ad-laden website can easily eat up more RAM than that). This is feasible for the host system.

However when you load Kingdom Hearts 2 (3.8GB) into PCSX2, it certainly doesn't load the whole thing into RAM. It loads smaller portions from the drive as needed (the emulator uses ~155MB for me during the intro FMV), and in most cases the performance hit for doing this is negligible, since disc-based systems usually have much slower reads then internal/external storage anyways (this can be seen when loading PSP ISOs from a memory stick, load times are generally shortened compared to running a physical disc).

i agree with he last part though, it s a design choice and limitation and is not really that much annoying in the end

I agree the file should be removed when it's not needed anymore. I just felt the need to point out that the file needs to exist somewhere in order to be used, and on the Wii RAM isn't the vast usable space it is on a PC.