Homebrew RetroArch - A new multi-system emulator

[seam]

i for one am more concerned with accuracy and speed than having a flashy menu etc. but there are always going to be idiots that bitch about MORE features, BETTER menu, etc etc... i think allowing the cores to accept arguments which will allow the games to be loaded in the users favorite loader(wiiflow,gx,postloader, etc) will probably stop people complaining ... hopefully. ha. at any rate, just ignore the idiots. there are plenty of people who appreciate this program and who understand that accuracy/speed is more important than all else.

keep up the great work

 

[the_randomizer]

Final Fantasy Advance series - Playable, but the audio and framerate slow down probably to around 50-55fps

Yeah, the FInal Fantasy GBA games don't even run at fullspeed on PS3/360 - neither do they run at fullspeed on a Pentium 4 2.4Ghz.

Hopefully gpSP will be able to nail them at much lower clock speeds.

It doesn't help that Final Fantasy VI was badly ported (especially the Mode7 effects when on the airship and chocobo, they ran half speed on real hardware). Yeah, it's bad, but I guess those games really taxed the GBA's 16.7MHz ARM7TDMI CPU. Final Fantasy 5 is the only one that runs full speed on the GBA.

gpSP sounds like an awesome emulator, though

 

[tueidj]

4) The prime priority of RetroArch is about providing a multi-platform base and doing a bang-up job in terms of performance and compatibility. Anything that goes against that (such as CPU filters that slow down even more) will not be included if the host platform does not support something like programmable pixel/vertex shaders (for the reason that these shaders would come at zero performance cost).

To be honest if this is your goal, you really want to have another look at your wii-specific code:
- mem2_manager is rubbish, it makes no attempt to avoid fragmentation as well as being slow. lwp_heap is only designed to carve the physical memory into smaller heaps which are presumed to use their own managers, it isn't meant to be used for general purpose alloc/dealloc work.
- gx_video seems to have a lot of copy-pasted code. You don't need to reload texobjs every time they change (invalidating the specific textures is enough), don't need to clear the EFB on every copydisp because it redraws the entire screen each time, don't enable depth testing, separate the gx drawing and vsync stages by using SetDrawDone so you can render to the EFB while waiting for the current XFB to be displayed, get rid of the unnecessary *_Flush() calls in gx_frame() and use the VI scaler rather than GX to do the horizontal resizing. This is all in addition to the performance and quality loss associated with using an RGBA texture instead of an indexed texture that I pointed out earlier.
It might be all well and good to say you outperform all the other wii emulators but if you want to claim your code gives the "best" performance, make sure it's got no low hanging fruit first. If you manage to get all that done then start looking at using multiple TEV stages and indirect textures, you'll find the wii graphics hardware can actually do a lot of the things that shaders are commonly used for.

 

[LibretroRetroArc]

To be honest if this is your goal, you really want to have another look at your wii-specific code:
- mem2_manager is rubbish, it makes no attempt to avoid fragmentation as well as being slow. lwp_heap is only designed to carve the physical memory into smaller heaps which are presumed to use their own managers, it isn't meant to be used for general purpose alloc/dealloc work.

I didn't hack up that code so will leave it to ToadKing for comment.

- gx_video seems to have a lot of copy-pasted code. You don't need to reload texobjs every time they change (invalidating the specific textures is enough), don't need to clear the EFB on every copydisp because it redraws the entire screen each time, don't enable depth testing, separate the gx drawing and vsync stages by using SetDrawDone so you can render to the EFB while waiting for the current XFB to be displayed, get rid of the unnecessary *_Flush() calls in gx_frame() and use the VI scaler rather than GX to do the horizontal resizing.

The video code was somewhat naively coded back in December of last year and hasn't really undergone any substantial changes - it makes no claim of being the fastest video driver out there. Will definitely look into those suggestions you offered up though and we appreciate all the help and code feedback we can get.

This is all in addition to the performance and quality loss associated with using an RGBA texture instead of an indexed texture that I pointed out earlier.

It might be all well and good to say you outperform all the other wii emulators but if you want to claim your code gives the "best" performance, make sure it's got no low hanging fruit first.

Low hanging fruit for sure, but not something that requires a significant rewrite of our core code that might adversely affect other platforms' performance, such as indexed textures in this case. I would like to see some kind of estimate of how much of a performance gain this would be before heading in that direction. Of course, patches and pull requests are always welcome as ever.

If you manage to get all that done then start looking at using multiple TEV stages and indirect textures, you'll find the wii graphics hardware can actually do a lot of the things that shaders are commonly used for.

on PS3/360 we can use text-based HLSL/Cg shader files and load them at runtime with a runtime shader compiler. I don't see anything like that being possible for Wii - and I'm certainly not going to be hand-compiling in specific shaders in the RetroArch binary itself. So if that's not possible, I don't see myself heading in that direction.

Then there's the question of what we're essentially looking at here - what do you mean by 'a lot of the things that shaders are commonly used for'? Any specifics? As far as I understand it, it's still totally fixed function - we won't be able to make a CRT shader or port over any of the game-aware shaders that we've made for use on PS3/360/PC.

And it doesn't look as if any other emulator on Wii has used TEV for the purpose of doing filtering like seen in HQ2x/2xSaI/5xBR or whatever, so question is again, if this is all possible and totally achievable, why haven't we seen anything of the sort and why are they still sticking to CPU filters? Any example code, documentation to look at?

 

[tueidj]

There is obviously the YUV->RGB conversion code used in mplayer/wiimc that shows how multiple TEV stages can be chained together (these days this conversion is commonly done with a shader on PCs, rather than use a YUV overlay).
So that's how you can change the RGB values, but what about changing texture co-ordinates? That's where indirect textures come into play:

Here's an example of what I would call a "reverse pincushion" CRT shader (CRT.OpenGL) implemented via indirect warping (courtesy Extrems):

If you're really committed to using a shader-based language rather than getting your hands dirty with GX_* functions in C code, there is even a tool for that: TEVSL
I think the reason none of the other emulators have implemented anything like this is because a) they couldn't be bothered and b) there are no existing samples, if you want to be better than everybody else then it stands to reason that you must at least create some code from scratch. The demo scene (I believe that one is created by the same guy who made TEVSL) is never lazy.

 

[Toad King]

To be honest if this is your goal, you really want to have another look at your wii-specific code:
- mem2_manager is rubbish, it makes no attempt to avoid fragmentation as well as being slow. lwp_heap is only designed to carve the physical memory into smaller heaps which are presumed to use their own managers, it isn't meant to be used for general purpose alloc/dealloc work.

I didn't hack up that code so will leave it to ToadKing for comment.

mem2_manager was mainly implemented so we avoided the libogc issue where mem1 would be locked out unless the mem2 heap was empty. I assumed you initialized any number of heaps you wanted and used the allocate/free functions as named. The lack of almost any documentation at all has been an issue not only in this, but in several aspects of the Wii/GC port.

 

[tueidj]

It can do that, but it sucks at it. If devkitPPC publically exposed the dlmalloc functions (which it uses for libc's memory management), mspaces could be used instead. Otherwise there are plenty of public domain heap managers that give better performance; BGET for example.

 

[Hielkenator]

Reading all previous post.
I would like to thank the devs for their work and their clear explanation.

People that have seen me on gba temp know that I mean no harm.
I'm usually very curious about things, and like to give lots of feedback.
I fully respect any devs reason for the decisions they make.

Usually I do not get heated in these conversations.
I rather help people.

If I offended anybody in any way, I appologize sicerely.

On topic: GBA Game Metroid Zero Mission, has suffered from lag and sound jittering for along time now.
Though it's slightly faster on retroarch, it's still unplayable.
Would there be hope for this game to run more fluidly on the next rev.?

I have too many roms imho to get them all unzipped at this point.
But then again I'm a bit anal when it comes to rom collecting.
Having all roms, from all regions, in all version + the trained and translated ones for all available emulators on Wii is a bit over the top for most people.
But I have them, some I've had for years when it was only possible to play them on PC.
It might sound funny but I'm getting acctually a little emotional over these retro games.
I'm well into my thirdtees, and I have so many good memories about a lot of these systems.
It's all about growing up.

In short: I love what you guys do and I love this community thank you all.

This is not a problem really, I'll just have to cope when testing various games.

 

[tmv_josue]

4) ......Anything that goes against that (such as CPU filters that slow down even more) will not be included if the host platform does not support something like programmable pixel/vertex shaders (for the reason that these shaders would come at zero performance cost).

Sorry for the offtopic but I was wondering if PS3 and Xbox 360 support programmable pixel/vertex shaders?

 

[Hielkenator]

Just compared Starfox official competition U - on snes gx vs retroarch snes next.
Aswell as Starfox 2 beta.
Both are sfx games.
snesgx is a lot faster.
Hopefully this will be sorted in the next rev.

For the comment on mario advance games.
They are a lot faster on retroarch, but still have major lag on some points.
I thought there was a mention about porting the gba emu originating from PSP?

Also on the NES side of things, will Famicom disk system be supported in the future?
As of now it results in a code dump trying to load these games.

 

[the_randomizer]

Just compared Starfox official competition U - on snes gx vs retroarch snes next.
Aswell as Starfox 2 beta.
Both are sfx games.
snesgx is a lot faster.
Hopefully this will be sorted in the next rev.

For the comment on mario advance games.
They are a lot faster on retroarch, but still have major lag on some points.
I thought there was a mention about porting the gba emu originating from PSP?

Also on the NES side of things, will Famicom disk system be supported in the future?
As of now it results in a code dump trying to load these games.

Because Snes9xGx uses frameskipping, that's why it's "faster". LibretroRetroArch stated that the framerate is for Snes9x Next normal, but since the emulator doesn't use frameskip, the audio isn't quite 60fps. Snes9x Next v2 will fix that, though.

 

[Hielkenator]

Just compared Starfox official competition U - on snes gx vs retroarch snes next.
Aswell as Starfox 2 beta.
Both are sfx games.
snesgx is a lot faster.
Hopefully this will be sorted in the next rev.

For the comment on mario advance games.
They are a lot faster on retroarch, but still have major lag on some points.
I thought there was a mention about porting the gba emu originating from PSP?

Also on the NES side of things, will Famicom disk system be supported in the future?
As of now it results in a code dump trying to load these games.

Because Snes9xGx uses frameskipping, that's why it's "faster". LibretroRetroArch stated that the framerate is for Snes9x Next normal, but since the emulator doesn't use frameskip, the audio isn't quite 60fps. Snes9x Next v2 will fix that, though.

We'll the sound of retroarch is also less consistent.
What cool about starfox 2 beta is the fps is onscreen.
retroarch > 10~12 fps with sound jittering/ speed up slowdowns
snesgx > around 10~20 fps. sound perfect & more playable.

We'll see for the next rev!

 

[LibretroRetroArc]

Just compared Starfox official competition U - on snes gx vs retroarch snes next.
Aswell as Starfox 2 beta.
Both are sfx games.
snesgx is a lot faster.

I made a joking comment earlier to the tune of 'they'll start comparing Star Fox next and mistaking frameskipping for a good framerate' - and what do you know - it's exactly what happens.

Hopefully this will be sorted in the next rev.

There's nothing for me to 'sort' - what you seem to want is frameskipping to disguise the fact when things aren't running at 60fps, and I won't ever, ever resort to that.

We'll the sound of retroarch is also less consistent.
What cool about starfox 2 beta is the fps is onscreen.
retroarch > 10~12 fps with sound jittering/ speed up slowdowns
snesgx > around 10~20 fps. sound perfect & more playable.

Ah yes, because you can take that emulated FPS counter to the bank for sure - especially when SNES9x GX 'skips' entire frames according to some hoky timer stuff. Are you kidding me?

You want a real comparison? Take the SNES9x GX source, throw out the frameskipping, put some onscreen FPS info in there, then compare.

We'll see for the next rev!

No, we won't 'see' for the next rev - I have nothing to 'prove' and it's likely this is as fast as the Wii can get - SNES9x Next runs faster but it just doesn't resort to frameskipping - which it seems you seem to mistake for a 'good framerate'. if you can't notice frameskipping, there is really no point for me to discuss this further with you - it all stops there and then.

For the comment on mario advance games.
They are a lot faster on retroarch, but still have major lag on some points.

What exactly do you think amounts to 'lag' when you can't even seem to notice frameskipping? Just saying - this is not a free lunch - just saying 'it's laggy' means about as much as me saying 'I think it's smoother/less smooth'.

 

[Toad King]

If you are noticing lag in any game, you should first confirm it's the emulator and not the game itself. Unfortunately the only way to do so right now is to recompile the latest revision of RetroArch and enable the debug display, but until then, I am skeptical of any reports of "lag", since the games being reported are notoriously laggy on the actual systems themselves.

 

[kylster]

Can anyone explain how to use xml cheats? I can't find any info on how to set it up or what codes can be used since it will not be directly supported.
Thanks in advance.

If you are noticing lag in any game, you should first confirm it's the emulator and not the game itself. Unfortunately the only way to do so right now is to recompile the latest revision of RetroArch and enable the debug display, but until then, I am skeptical of any reports of "lag", since the games being reported are notoriously laggy on the actual systems themselves.

I found games run smoother when run off USB then from SD; example would be Star Ocean SNES if I run from my SD the end of battle has a lower FPS then when I run from USB (at almost regular speed) this is the only lag I experience but like I just mentioned it's solved if I run the game from USB.

 

[Hielkenator]

Just compared Starfox official competition U - on snes gx vs retroarch snes next.
Aswell as Starfox 2 beta.
Both are sfx games.
snesgx is a lot faster.

I made a joking comment earlier to the tune of 'they'll start comparing Star Fox next and mistaking frameskipping for a good framerate' - and what do you know - it's exactly what happens.

Hopefully this will be sorted in the next rev.

There's nothing for me to 'sort' - what you seem to want is frameskipping to disguise the fact when things aren't running at 60fps, and I won't ever, ever resort to that.

We'll the sound of retroarch is also less consistent.
What cool about starfox 2 beta is the fps is onscreen.
retroarch > 10~12 fps with sound jittering/ speed up slowdowns
snesgx > around 10~20 fps. sound perfect & more playable.

Ah yes, because you can take that emulated FPS counter to the bank for sure - especially when SNES9x GX 'skips' entire frames according to some hoky timer stuff. Are you kidding me?

You want a real comparison? Take the SNES9x GX source, throw out the frameskipping, put some onscreen FPS info in there, then compare.

We'll see for the next rev!

No, we won't 'see' for the next rev - I have nothing to 'prove' and it's likely this is as fast as the Wii can get - SNES9x Next runs faster but it just doesn't resort to frameskipping - which it seems you seem to mistake for a 'good framerate'. if you can't notice frameskipping, there is really no point for me to discuss this further with you - it all stops there and then.

For the comment on mario advance games.
They are a lot faster on retroarch, but still have major lag on some points.

What exactly do you think amounts to 'lag' when you can't even seem to notice frameskipping? Just saying - this is not a free lunch - just saying 'it's laggy' means about as much as me saying 'I think it's smoother/less smooth'.

Thank you once again for this "warm" explaination.
Thank you for your precious time to comment on something I'm experiencing.
A lot of defending on your part, wich was'nt needed in my opinion.
Also no need to act belittling.
I'll enjoy your emu even more after this explaination.
But, maybe it's time you'd played some games for yourself, relax.
Original Starwing/Starfox did'nt run NEAR 60 fps/sec, good luck & have fun
Make the friggin' best emulator package for Wii, ever.
Thank you.

 

[LibretroRetroArc]

A lot of defending on your part, wich was'nt needed in my opinion.
Also no need to act belittling.

When I see things being thrown around such as '[insert emulator] is a lot faster', or '[game] is laggy', and when that isn't based on facts, then I will point it out.

Also, I know you mean well but it doesn't really help your case talking about 'lag' when you don't even notice frameskipping. Don't take offense but you might need to start doing some more accurate measurements in the future - such as doing an ABX test - if you really want to help us out with feedback on lag. Just saying it feels 'laggy' in Super Mario Advance is a shot in the dark - 'laggy' compared to what? Laggy according to which tests?

For that matter, I feel Classic controller response right now is a bit patchy too at times - so I'm not saying there are no issues. Just an issue with the way people are reaching conclusions here and the (lack of) factual basis behind it.

Original Starwing/Starfox did'nt run NEAR 60 fps/sec, good luck & have fun

It didn't indeed - it was lucky if it was running at 15fps - most of the time in busy scenes it was running at 8fps or so.

 

[Hielkenator]

A lot of defending on your part, wich was'nt needed in my opinion.
Also no need to act belittling.

When I see things being thrown around such as '[insert emulator] is a lot faster', or '[game] is laggy', and when that isn't based on facts, then I will point it out.

Also, I know you mean well but it doesn't really help your case talking about 'lag' when you don't even notice frameskipping. Don't take offense but you might need to start doing some more accurate measurements in the future - such as doing an ABX test - if you really want to help us out with feedback on lag. Just saying it feels 'laggy' in Super Mario Advance is a shot in the dark - 'laggy' compared to what? Laggy according to which tests?

For that matter, I feel Classic controller response right now is a bit patchy too at times - so I'm not saying there are no issues.

Original Starwing/Starfox did'nt run NEAR 60 fps/sec, good luck & have fun

It didn't indeed - it was lucky if it was running at 15fps - most of the time in busy scenes it was running at 8fps or so.

Thank you, I really love to help you guys with anything.
VBA next is a dream compared to other emu's, especially smb series.
When there are alot of sprites, the game tends to slow down.
If you want I can compare on a real gba system.

 

[the_randomizer]

A good way to compare Snes9xGx's use of frameskipping versus Snes9x Next would be to run an intensive game like Yoshi's Island, and go to level/area where the game had the framerate dip. In World 6, this was especially noticeable; if you compare the two emulators, Snes9xGx uses frameskipping where Next does not, so naturally, Next runs the game full speed regardless of how big the levels are.

Don't get me wrong, I'm not trying to attack Tantric and how he ported Snes9x to the Wii, but for one reason or another, he wanted to use frameskipping and I can respect that. But at the same time, it can act as a double-edged sword and give one a false perception of how a real Snes runs, and some games can lag where it shouldn't.

 

[catuligbat]

A good way to compare Snes9xGx's use of frameskipping versus Snes9x Next would be to run an intensive game like Yoshi's Island, and go to level/area where the game had the framerate dip. In World 6, this was especially noticeable; if you compare the two emulators, Snes9xGx uses frameskipping where Next does not, so naturally, Next runs the game full speed regardless of how big the levels are.

Don't get me wrong, I'm not trying to attack Tantric and how he ported Snes9x to the Wii, but for one reason or another, he wanted to use frameskipping and I can respect that. But at the same time, it can act as a double-edged sword and give one a false perception of how a real Snes runs, and some games can lag where it shouldn't.

this situation could affect some users but , in my case snes9xGX works without problems but mentionated games could exceptions, but in my case playing on snes9xGX with minor querys

But your point is respectable from your point of vision