Testing out unreleased cores

RetroArch General
#1

Came across the following post on another board:

http://www.mediafire.com/?1y4x31w5qv1y97k

Core included are the latest revisions of Nestopia, Genplus GX, Gambatte, and Yabause. Also included is a version of Genplus GX that enables its own NTSC-Composite filter, since the regular NTSC filters do not work well with it. Another thing to note is that unlike the “official” Gambatte core, the one I have compiled has a GBC color palette enabled, so Gameboy games will have color if you wish to play that way. Otherwise, use the “official” core.

My system is W7 64bit. I’ve test them.

Nestopia

Works perfectly. Nestopia has better and more accurate colors than most of the other NES cores for RetroArch.

Genesis-Plus-GX-NTSC

Works fine. Very neat. Would like one that is S-video rather than composite. Who made this and where is it maintained?

Gambatte-color

Works in everything I’ve tried. Yabause

Haven’t gotten it to work in anything yet. Dracula XX loads fine, but inputs do not work. Panzer Dragoon II Zwei loads but does not go past the menu. Has anyone had any more luck with it? I’m not expecting much from it since it seems to be very early in development.

#2

Interesting. Could you link the board please? It would be good if I could get some feedback on yet-unreleased/in-development ports - that will help when I finally have time to bump them up to ‘bundle/release’ status.

#3

Most of them seem ready to be released (at least for Windows), but Yabause looks like it’s still very alpha/beta. I don’t expect it for a long time.

While we’re on the topic of cores, I’ve never gotten GBA-Meteor to ever work. No idea why. VBA-Next works perfectly.

Could you link the board please?

https://archive.foolz.us/vg/thread/23818984/#24522813

Post from /vg/'s Emulation General. That thread is always around.

#4

Genesis-Plus-GX-NTSC

Works fine. Very neat. Would like one that is S-video rather than composite. Who made this and where is it maintained?

It’s just one parameter to change in “libretro.c” and the “Makefile.libretro”. As such, it is not a separately maintained fork or anything but just an option at the building stage.

I just complied all of the variants (monochrome, composite, svideo, rgb) from source for Win64 if you want to give them a try. This should work for Master System and MegaDrive alike. Grab them here: http://www.denki-den.com/tmp/libretro-git-genplus-ntsc.zip

@Squarepusher

I think I can help here but I just don’t want to throw intermediate/wip builds around to have people complaining even more/harassing the team.

I have environments set up for Linux x64, Win64 and Wii. I think I have everything in place for Android too (android-sdk/ndk,ant, platform-tools etc…) but can’t seem to find a noob friendly compilation guide yet.

#5

Come on IRC and we can talk about getting your build environment up and running for Android. #retroarch, freenode.

#6

You can find the current Emulation General on the /vg/ boards. Just use the catalog to find it. http://boards.4chan.org/vg/catalog

I just complied all of the variants (monochrome, composite, svideo, rgb) from source for Win64 if you want to give them a try. This should work for Master System and MegaDrive alike. Grab them here: http://www.denki-den.com/tmp/libretro-git-genplus-ntsc.zip

Neat. Thanks.

#7

Hello, I’m the guy who compiled and uploaded that, er, compilation of cores. Well, except the NTSC version of Genplus, which I actually got from this very board. This is my first post here, so hello, I suppose.

In any case, I’m actually quite new to this whole compilation business. I tried to compile a couple more cores, such as Desmume and DOSBox, but they all gave me several errors. Now, keep in mind, I’m using Windows 7, which from what I’ve read and experienced can be quite difficult to get a proper compiling environment set up in. I’m surprised I even managed to compile what I did. I certainly was not expecting the Gambatte core I compiled to have color!

All that said, I have done my fair share of testing (furthering the emulation cause has become a recent hobby of mine), and I think I can give some preliminary feedback on a few things:

  • Nestopia works like a dream. I was annoyed at how the colors for FCEU and especially bNES looked, although from what I understand NES has improved a lot on that front on higan proper. Nestopia has very nice colors, and looks quite a bit closer to how the real NES looks on my TV, a Sony 27FS100. Now, mind you, I know NTSC signal decoding comes with its own can of worms, so colors varying from emulator to emulator just as they would from TV to TV is understandable, but hell, I wanted my colors to look like how they look on my TV, damn it. Getting Nestopia to work on RetroArch was my primary motivation for researching how to compile, and I’m damn glad I did.

  • Yabause is, as stated by Tripulent, a mixed bag. I actually did get a couple of games to work with it, with varying success. Virtua Fighter Remix boots up and I can “play” it, and by play I mean get into a match and wait for the whole screen to glitch out like crazy and for me, the CPU, or both of us to get ringed out within seconds. I tested Symphony of the Night, and just like Tripulent, the game boots up but accepts no inputs, so meh. Nights, however, I am able to play quite nicely. It suffers from a couple of graphical errors, but for the most part it’s quite playable. Overall, Yabause has a looooooong way to go, but hell, the fact that I can use a CRT shader with it already makes it worthwhile IMO.

Gambatte color - Like I said before, I had no idea compiling this core without extra stipulations before compilation would make it default to Gameboy Color mode. It was a welcome surprise, truth be told. A few games like Kirby’s Dreamland 2 benefit from it quite a bit, although of course the Super Gameboy palette would have been preferable. Speaking of which, I do hope we get Super Gameboy implementation in a future revision of the bSNES core. I’d really love to use those nice NTSC filters on it.

Which brings me to Genplus. I have just tested the cores compiled by Tanuki, and I love them. I was ok with the composite version, but I really wanted RGB for some time now. I spent a good hour or so playing with it, and I have to say, combined with the CRT shader (with gamma correction turned off, as I assume the NTSC filtering on the core already takes care of it just as the bSNES filters do), the RGB core looks absolutely phenomenal. One oddity, however: the NTSC cores seem to horizontally stretch the screen to a ridiculous proportion if aspect ratio is set to auto. Locking it into 4:3 easily fixes this, of course, but I thought that was weird.

Awesome.

I do have one question before I end this rambling wall of text: do any of the Mednafen cores have the ability to enable NTSC filtering as well? It would be great to have NTSC versions of Mednafen-PSX, for instance. Hardly a pressing matter, of course, especially if it’s currently not possible, but it’d be nice all the same.

#8

Hello GPDP,

I just tried to test your compiled cores on Retroarch-win32-0.9.8. It seems, your cores works on Win 64-bit only. Are you able to compile cores which are compatible with Win 32-bit too? I´m using WinXP 32-bit.

Thanks in advance.

Kind Regards,

Anna

#9

Hi AnnaWu,

Could you try these? http://www.denki-den.com/tmp/genplus32-ntsc.zip

I don’t have any 32bit system to test them on but hopefully I got that mingw32 cross-compiling stuff right!

I see you are the one behind QMC2, thanks for a great program!

#10

Thanks Tanuki. :slight_smile: Basically, your libreto files are working on the real 32-bit system, i.e on my WinXP Pro 32-bit.

The audio output by using by Maister´s “libretro-git-genplus-x86.dll” based on Genesis Plus GX v1.7.1 sounds better for me. With your libreto files based on newer Genesis Plus GX core I have some sound distortions, no matter which settings I use.

#11

It’s probably better if you go with a CRT shader instead. It will take the strain off your CPU and onto your GPU instead.

#12

Oh, I already use the CRT shader for damn near everything (I even managed to port an earlier, non-interlaced version of it to Pete’s format for use with PCSX-R, and put it up for download). Thing is, I like to combine it with NTSC filtering. I find it produces better colors and blending than just the shader alone does.

As for CPU strain, I’m running on a Core i7. Only with the bSNES Accuracy core running an NTSC filter while playing an intensive game like Mega Man X3 have I ever experienced any slowdown. For the most part, CPU strain is hardly an issue for me. I’m just looking to get the best possible picture out of my games, no matter what it takes.

The reason I asked about NTSC filtering for the Mednafen cores is because they are not very compatible with the regular NTSC filters, most likely because they were written with bSNES in mind and thus expect a 256x224 resolution, and they do not work well with games that use some other resolution like 320x240, such as PS1 games. It appears possible to compile Genplus so that it uses its own NTSC filtering from the core itself to get around this issue, so I was asking if the same was possible for Mednafen cores.

#13

[quote=“GPDP”]

Oh, I already use the CRT shader for damn near everything (I even managed to port an earlier, non-interlaced version of it to Pete’s format for use with PCSX-R, and put it up for download). Thing is, I like to combine it with NTSC filtering. I find it produces better colors and blending than just the shader alone does.

As for CPU strain, I’m running on a Core i7. Only with the bSNES Accuracy core running an NTSC filter while playing an intensive game like Mega Man X3 have I ever experienced any slowdown. For the most part, CPU strain is hardly an issue for me. I’m just looking to get the best possible picture out of my games, no matter what it takes.

The reason I asked about NTSC filtering for the Mednafen cores is because they are not very compatible with the regular NTSC filters, most likely because they were written with bSNES in mind and thus expect a 256x224 resolution, and they do not work well with games that use some other resolution like 320x240, such as PS1 games. It appears possible to compile Genplus so that it uses its own NTSC filtering from the core itself to get around this issue, so I was asking if the same was possible for Mednafen cores.[/quote]

The reason why we have not bothered with CPU filters much in terms of inclusion into RetroArch console ports or in the cores themselves are exactly because the filters are very non-modular to begin with -

  • Color conversion issues arise
  • Filters in C need to be statically compiled as opposed to the shaders which get compiled at runtime
  • All sorts of resolution issues where a certain filter needs to be manually adjusted for a specific resolution/aspect ratio etc.

That is also why it is unlikely you will ever see me or maister going to the trouble of trying to get this NTSC filter to work properly for Mednafen PSX - PSX supports multiple resolutions anyway - some of them like Soul Blade are at 640x224 - so it would be a disaster of a maintenance chore to try to get the CRT filter to output right for all the various resolutions the PS1 supports.

For these reasons we believe shaders are the future (CPUs are becoming less and less important to the bottom line while most of the heavy work today - for games etc. - is done on GPU, which are also getting to be as programmable as general-purpose CPUs), and hence why we have taken a very hardline stance on not really prolonging the lifespan of CPU filters.

I think if blargg were committed to doing a shader version of his NTSC filter, that there would practically be no more need for any CRT filters. That is really the ‘last’ stronghold of CPU filters before they can go off into the sunset and die.

#14

Make no mistake: I agree with everything you’ve stated. I know about the pitfalls associated with CPU filters, and I can see why shaders are and should be the future. However, for whatever reason, we do not yet have proper NTSC shaders, hence why I’m still using the filters. All I was asking is if with current methods, there was a way to get NTSC filtering with Mednafen cores. If not, tough luck, then. All I can do is wait and see if ever said filters get ported to shader format so we can finally leave CPU filters behind in the dustbin of history.

#15

blargg’s NTSC filter is hard to follow because he did a bunch of crazy optimization to allow it to run on whatever machine he had at the time, which I think was something like a 200 mhz PPC… However, the actual process isn’t that terribly complicated: http://wiki.nesdev.com/w/index.php/NTSC_video#Emulating_in_C.2B.2B_code

(you can see this code in action in bisqwit’s mind-boggling 900 line NES emulator)

I believe a lot of the issue with converting that to GLSL is the fact that it requires a lot of branching (if x, then y, otherwise z), and that absolutely murders performance on GPUs, which only excel at parallelism (do x a bajillion times at once).

The existing NTSC shader from maister and cgwg does a pretty good job of it, though I believe it included some compromises to keep the branching to a minimum. There’s still a little bit, though, which is why it’s such a heavy shader.

#16

I see. This is all so very interesting to me. I like knowing how the tools I use work.

That said, I have tried that NTSC shader, and, no offense to Themaister and cgwg’s efforts, I do not like it much. It looks like an extremely poor RF connection or something, which I suppose was the point, but not even the NTSC-RF filter looks that bad. I tried the version that isolates the third pass so it doesn’t have all the RF artifacts, but it still did not satisfy me.

How heavy would a “better” version without compromises be, anyway? You say it would murder GPUs, but are we talking GPUs in general, or just lower end ones? I have a fairly modest AMD 5750, and it does not seem to mind any shader I throw at it, including the halation variant of the CRT shader or the NTSC shader, which appear to be among the heaviest, even while using bSNES Accuracy. Would it buckle to an uncompromised NTSC shader? If anything, I would love to test it out.

Oh, and I’d just like to say thank you all for responding so promptly. You don’t get this kind of support from other emulation communities.

#17

I, too, am curious how heavy a 1:1 GLSL implementation would be, but they didn’t post any in-progress versions, unfortunately, and my GLSL skills are too rudimentary and clumsy to even try it, myself.

There’s another interesting GLSL NTSC shader floating around for OS X’s OpenEmulator (not to be confused with clobber et al’s OpenEmu), but I never got it successfully ported to the XML format :frowning:

You can check it out here: http://code.google.com/searchframe#ZL0nVORUYcA/trunk/libemulation-hal/OENTSCGLShader.fs&q=ntsc%20package:openemulator\.googlecode\.com&ct=rc&cd=1&sq=

I tried giving static values to all of the floats and changing the uniforms but no dice…

There’s also some promising-looking NTSC-related stuff in OpenGLCanvas.cpp that I haven’t tried messing with yet (in green, just down from the top): http://code.google.com/p/openemulator/source/search?q=vertex&origq=vertex&btnG=Search+Trunk

#18

Veeeeeery interesting. Well, I may as well give it a go myself. I managed to blunder my way through cgwg’s CRT shader enough to somehow successfully port it to Pete’s OpenGL2 GLSL spec, so who knows, I may have similar luck here.

Edit: Wow.

But hey, progress!

#19

Nice :smiley:

That’s as far as I ever got, as well.

#20

Thanks for compiling this GPDP. Nestopia, Gambatte color, and Genplus all working without any issues major. I can confirm that the rgb version screws up the aspect ratio in Genplus if it is set to auto.

Other then that its running fine. Ready to be included into RetroArch by default.