Homebrew RetroArch - A new multi-system emulator

  • Thread starter Thread starter Toad King
  • Start date Start date
  • Views Views 747,719
  • Replies Replies 3,294
  • Likes Likes 27
Status
Not open for further replies.
Can't be done because that's how FBA works internally. You change for instance sfa3.zip to Street Fighter Alpha 3.zip and the emulator breaks down in its 'game detection'.

For the next release there will be an option to 'prettify' names automatically in the 'filebrowser' - it might be a bit slower but more appealing/easier.
Ok no worries. Keep up the great work RetroArch Ninjas!
 
No, you just don't have the BIOS files in the proper place. They now need to go into your 'system' directory.

Thanks! I'll give it a shot.

I very much doubt that. If there's a pitch issue, then it's likely that it affects the entire libretro port of NEStopia and not just on Wii.

Oh I see. Well, I hope it gets attention because Nestopia sure is nice from what I've seen thus far. For now though I guess FCEUmm will have to do because it sounds virtually identical to the original NES.


I already tried an 'automatic native resolution switching mode' but I have not included it because it was error prone and it would occasionally completely glitch out the graphics where only a shutdown of the app would get me normal video again.
I know about all the games on SNES that try to do resolution change, and it's really trivial to begin with. Most of the games just use it for some stupid 'copyright/title screen' and then never use it again or (in Seiken Densetsu 2/SD3's case) it just uses it for menu screens or when it needs to render text.

I'll try to return to some kind of 'native auto-resolution switching' but if it can't be done in a stable fashion then it's not going to be included.

And everytime SNES9x GX or any of the other 'GX-brand' emus would automatically resolution switch, there would be a horrible audio pop to go with it - no thanks to that. So IF it can't be done right, it will not be done at all.

I've just confirmed that using 512x224p for SNES9x works for all games. In fact, it actually VERY slightly sharpens the image on all 256x224p content without any distortion, or any stretching (at least on a CRT. have not tested a HDTV, nor do I plan to as HDTV's already distort anything lower than their native resolution, ESPECIALLY lower than 480i/p). So basically - from what I can tell at least - there seems to be no need for native auto-resolution switching, especially when all content looks better (slightly sharper) in 512x224.

So unless someone can post any issue with using ONLY 512x224 exclusively, then we can pretty much rest assured that 512x224 is what you should be using for SNES9x.


P.S. Is there any chance we will see a way around the "squeeze" that's currently implemented only on Seiken Densetu 3? I know it may seem trivial, but the menus look SO much better in their native resolution.
 
For those who want to play Kirby's Dreamland 3, Snes9x GX must be used to bypass the levels that use pseudo hi-res 512 dithering (or whatever they call it), for the foreground rocks/cacti and semi-transparent water levels. Unless that was fixed, haven't tried it yet.

Thanks! I'll give it a shot.



Oh I see. Well, I hope it gets attention because Nestopia sure is nice from what I've seen thus far. For now though I guess FCEUmm will have to do because it sounds virtually identical to the original NES.




I've just confirmed that using 512x224p for SNES9x works for all games. In fact, it actually VERY slightly sharpens the image on all 256x224p content without any distortion, or any stretching (at least on a CRT. have not tested a HDTV, nor do I plan to as HDTV's already distort anything lower than their native resolution, ESPECIALLY lower than 480i/p). So basically - from what I can tell at least - there seems to be no need for native auto-resolution switching, especially when all content looks better (slightly sharper) in 512x224.

So unless someone can post any issue with using ONLY 512x224 exclusively, then we can pretty much rest assured that 512x224 is what you should be using for SNES9x.


P.S. Is there any chance we will see a way around the "squeeze" that's currently implemented only on Seiken Densetu 3? I know it may seem trivial, but the menus look SO much better in their native resolution.
So, using 512 x 244 doesn't create a dip in the framerate at all?
 
P.S. Is there any chance we will see a way around the "squeeze" that's currently implemented only on Seiken Densetu 3? I know it may seem trivial, but the menus look SO much better in their native resolution.

Not unless we can magically make SNES9x's tiled rendering any faster than it already is, no. Blitting a 512x224 image is going to be much more CPU-intensive than a 256x224 image.
 
I can put out a Gamecube build but it will be TOTALLY UNSUPPORTED - and by that I mean - it is up to you to check if most of the 'ROMs' on cores will even fit into memory. Prboom Doom games don't right now for instance.

It is basically a total straight port of the Wii version.
It is OK, I will check the GameCube bulid if you put it out . Will it support SD Gekko?
As you can see, I am not the only one who are waiting for a Gamecube port. So, please.
I will read the pdf doc about Android port and try to find out why my USB gamepad not working properly.
 
Hi, I'm using Virtual Boy emu, and every game get stuck in the warning screen.

I tested that it works at least on PS3. On 360/Xbox 1 it is so bugged that I didn't bother including it.

ToadKing might want to test this - I assumed there would be no problems on Wii. Mario's Clash, Mario Dream Tennis all worked here on PS3 (and Android).
 
It is OK, I will check the GameCube bulid if you put it out . Will it support SD Gekko?
As you can see, I am not the only one who are waiting for a Gamecube port. So, please.
I will read the pdf doc about Android port and try to find out why my USB gamepad not working properly.

If your USB gamepad is not supported - you can report the keycodes to me that each button on your pad generates. I will also need the 'name' of the pad (and I mean - the 'name' that pops up in RetroArch Android) - that way I can put in autodetection. The manual explains this in more detail. (NOT THE CORES MANUAL - but the 'RetroArch Android 'manual).
 
Not unless we can magically make SNES9x's tiled rendering any faster than it already is, no. Blitting a 512x224 image is going to be much more CPU-intensive than a 256x224 image.

Does using the 512 x 244 mode affect speed at all? And were you able to test the funky 512 x 244 pseudo hi res effects in Kirby's Dreamland 3 at all?
 
Not unless we can magically make SNES9x's tiled rendering any faster than it already is, no. Blitting a 512x224 image is going to be much more CPU-intensive than a 256x224 image.

Without the squeeze, does Seiken Densetsu 3 only hit a minor slow down in the menu screen, or during the entire gameplay?
 
Without the squeeze, does Seiken Densetsu 3 only hit a minor slow down in the menu screen, or during the entire gameplay?

It drops FPS down in those scenes to something around the 40fps mark. Having that occur everytime it switches to 512x224 (that means in gameplay too - whenever 'text' is being shown) makes it totally unplayable everytime you fight in the game.

So trust me, this is the best 'compromise' possible given the alternative.
 
Does using the 512 x 244 mode affect speed at all? And were you able to test the funky 512 x 244 pseudo hi res effects in Kirby's Dreamland 3 at all?

Kirby's Dreamland 3 is in the same boat - if I don't do the 'hack' that disables pseudo hires, it will not be fullspeed.

And yes, with software rendering, the less image data you need to block transfer, the faster performance will be. For that reason 256 x 224 will always be much faster than 512 x 224.
 
It drops FPS down in those scenes to something around the 40fps mark. Having that occur everytime it switches to 512x224 (that means in gameplay too - whenever 'text' is being shown) makes it totally unplayable everytime you fight in the game.

So trust me, this is the best 'compromise' possible given the alternative.

So this probably means that SNES9x GX uses frameskipping for this game (which is not good) correct?

P.S. If HBC ever comes to native Wii-U mode, then would that 3 core CPU be more than enough for these quirks?
 
P.S. If HBC ever comes to native Wii-U mode, then would that 3 core CPU be more than enough for these quirks?

I don't deal in speculations - I believe in raw tests on real hardware that gives us raw numbers back. So no way to know right now.

I would suspect it would be fast enough though - on Xbox 360 and PS3 I don't have to bother with 'squeezing' it to 256x224.
 
  • Like
Reactions: Rydian
Kirby's Dreamland 3 is in the same boat - if I don't do the 'hack' that disables pseudo hires, it will not be fullspeed.

And yes, with software rendering, the less image data you need to block transfer, the faster performance will be. For that reason 256 x 224 will always be much faster than 512 x 224.

Fair enough, it's alright since there are alternatives for that game, no biggie :P

Keep up the good work! I like having multiple emulators in one package.
 
For the note, I resolved my issue with DOOM. It appeared my WAD file was corrupted, I replaced it and now DOOM boots. It looks horrible and I can't control it, but I'm not complaining at all, rather what I'm saying is I apparently need to read the manual some more. :)
 
So, using 512 x 244 doesn't create a dip in the framerate at all?

I've tried many, many games, including Yoshi's Island and I don't see any dip in the framerate when using the FPS menu overlay. If there are any issues, I'm sure someone will eventually spot it. If so, then obviously switch back to 256x224.
 
If your USB gamepad is not supported - you can report the keycodes to me that each button on your pad generates. I will also need the 'name' of the pad (and I mean - the 'name' that pops up in RetroArch Android) - that way I can put in autodetection. The manual explains this in more detail. (NOT THE CORES MANUAL - but the 'RetroArch Android 'manual).

The direction button on USB gamepad works, but other button not.
Here's my USB gamepad name and key values from RetroArch Android.

HID[DragonRise.Inc DragonRise USB Gam.
The direction key : src 16777232
square: pad 0: 188 ac=0 src=1281
triangle: pad 0: 189 ac=0 src=1281
cross: pad 0: 190 ac=0 src=1281
circle: pad 0: 191 ac=0 src=1281
L1: pad 0: 192 ac=0 src=1281
R1: pad 0: 193 ac=0 src=1281
L2: pad 0: 194 ac=0 src=1281
R2: pad 0: 195 ac=0 src=1281
SELECT: pad 0: 196 ac=0 src=1281
START: pad 0: 197 ac=0 src=1281

There are houndreds of types of USB gamepads in the world, you can not list them all. So I think the best way is not presetting the key, but mappering it by users themselves.
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum