Yeah I’ve seen those too. Tyrian is a better effort IMHO and I think I’ve even mentioned it once but I don’t know where to start
I’m working with the dosbox core but I can’t get an autoexec section to work in dosbox.conf, nor can I disable the hotkeys to enter the commands manually in the dosbox shell.
Is this the section I need to modify?
Enable other hotkeys.
If this hotkey is bound to either keyboard, joybutton or joyaxis,
all other hotkeys will be disabled unless this hotkey is also held at the same time.
This is useful for RETRO_KEYBOARD centric implementations
which query a large area of the keyboard, where it is not desirable
that hotkeys get in the way.
Alternatively, all hotkeys for keyboard could be disabled by the user.
input_enable_hotkey =
There only seems to be one entry there, but two descriptions are listed?
Anyway I tried input_enable_hotkey = “false” and also input_enable_hotkey = “f11” but neither seems to be a valid entry because it gets erased and nothing changes.
edit: Got some more problems with 3do:
=== Config end === RetroArch: Loading dynamic libretro from: “/home/user/libretro-super/dist/unix/libretro-3doh.so” RetroArch [ERROR] :: dylib_load() failed: “/home/user/libretro-super/dist/unix/libretro-3doh.so: wrong ELF class: ELFCLASS32”. RetroArch [ERROR] :: Failed to open dynamic library: “/home/user/libretro-super/dist/unix/libretro-3doh.so” RetroArch [ERROR] :: Fatal error received in: “load_dynamic()”
It came out as 32bit? That’s bad?
maybe that’s bad , but honestly bah not hard to fix 
for 64bit just remove the m32 to CFLAGS and SHARED in ifeq ($(platform), unix) section and add -fpermissive to the global CFLAGS.
not tested in linux but works great with mingw64 on WIN64.
[quote=“7rtype”]
maybe that’s bad , but honestly bah not hard to fix
for 64bit just remove the m32 to CFLAGS and SHARED in ifeq ($(platform), unix) section and add -fpermissive to the global CFLAGS.
not tested in linux but works great with mingw64 on WIN64.[/quote]
Now I get this error:
=== Config end === RetroArch: Loading dynamic libretro from: “/home/user/libretro-super/dist/unix/libretro-3doh.so” RetroArch: Version of libretro API: 1 RetroArch: Compiled against API: 1 RetroArch: ROM loading skipped. Implementation will load it on its own. RetroArch: Environ SET_KEYBOARD_CALLBACK. RetroArch: Environ SET_PIXEL_FORMAT: XRGB8888.
I compiled this for 64-bit linux last night, and it looks like the problem comes from it not autodetecting the ‘unix’ platform properly. If you add platform=unix, it compiles fine (at least on my end).
that’s strange hunterk, i’ve just tested build in linux64 , and only with a “make -f makefile.libretro” it success . at least for me on my old Ubuntu 12.04
unix must be default :
ifeq ($(platform),)
platform = unix
BTW ,i saw guaripolo have done an update to proper fix ild64 bu (the -fpermissive works but it’s not very nice) have to update when i’ll have time.
@xenphor , sorry but i don’t see any error in your log , post more revelant logs if you want feedback.
and first be sure to :
Put bios in bios/ dir (rename it to bios.bin) Put iso files in games/ (ext have to be *.iso)
and launch by:
retroarch -v -L ./libretro-3doh.so games/myiso.iso
Ok the problem was that the config.ini file wasn’t in the system directory.
It seems to run well but it doesn’t look like vsync is working?
edit: Also seem to be having issues with street fighter freezing now twice. I can’t reset, have to quit.
Would a BGB Core be possible and would a TGBDual already compiled core be too much trouble?
Also, I would like to have Higan’s Super Game Boy have a separate core with a more laptop processor friendly speed. Speed that is like 1.9 or 2.0 GHZ processing power to work at full speed or something. Is that considered to be too much trouble?
There isn’t really any reason to use bgb instead of gambatte, AFAIK, unless you’re already using higan and just don’t want to open up another emu. Gambatte is much faster, more accurate and more compatible.
Likewise, Higan’s SGB is just bgb running inside of bsnes, so there’s not really anything to be done to speed it up, short of using gambatte for it instead.
As for TGBDual, I’m not sure what kind of a state it’s in right now, but if you tell me which platform you’re using, I can try to compile it sometime in the next couple of days.
I am running Retroarch on a windows 8 computer and I would like x86_x64 and x64 versions of TGB Dual. Could you compile that for me?
Ah, crap. I just looked into it and TGBDual doesn’t even build for Windows currently. Sorry dude 
It’s okay. I can wait until the core can be compiled in windows. By the way, do you have Yabuse that will work with Saturn Bomberman, Saturn Bomberman Fight, And Bomberman Wars? I really love those games and I am willing to use my Xbox 360 controller to play those games on retroarch.
Sure it does
make CXX=x86_64-w64-mingw32-g++ CFLAGS="-static-libgcc -static-libstdc++"
=> https://dl.dropboxusercontent.com/u/125 … x86_64.dll
make CXX=i686-w64-mingw32-g++ CFLAGS="-static-libgcc -static-libstdc++"
=> https://dl.dropboxusercontent.com/u/125 … al-x86.dll
There seem to be framerate issues at the moment, but I’m able to successfully load the 64-bit one in wine’d retroarch.
Thanks a lot for the x86 version of the TGBDual core because 32-bit builds be neglected here. : )
Any chance to get the Accurate Mednafen PC-Engine core inside RetroArch any time soon?
I second that.
I’ve been testing mednafen stand-alone and there are some issues present in pce_fast only. Like in Violent Soldier, just watch the demo when the ship is going into a base: under the top border scrolling there is a line blinking with some picture out of the place. That’s not happening in pce standard.
A bit unrelated but pce_fast on retroarch is never fullscreen, there’s always a black border on top I can’t get rid off.
I haven’t noticed any differences coming from stand alone Mednafen (which defaults to accurate PCE emulation) in the games I play, but more accuracy is always nice. I don’t think it’s much slower than PCE_fast either.
I’m still hoping the issue with the core volume options not working right gets fixed some day too. I originally posted that issue 9 months ago. I suppose there’s not as much interest in PCE/TG16 compared to the other cores.
How about an MSX core aswell? BlueMSX is an excellent open source emulator. The MSX had some great games, the original 2 Metal Gear games being notable, and some great support from Konami. I’d love to see a port of this to RA.
Well I attempted to port the Accurate Mednafen PC-Engine core to RetroArch, after some work I finally got it to compile but it crashes when you try to load a game. I’ve tried as best as I could to resolve the issue but as of now my coding skills are not good enuff. If anyone wants to take a look and see what they can do, then they are more than welcomed to do so: