Does the mouse work OK in Linux btw? Can you do circles on yourself in Wolfenstein or something like that?
Just saw this in the first post:
Great idea! This is highly interesting to me (and eerily well timed), since I’ve run into performance issues with SuperFX games on the Raspberry Pi while trying to minimize input lag. For example, see this post: http://libretro.com/forums/showthread.php?t=5428&p=49449&viewfull=1#post49449
Any info on what kind of speedup we can be expect?
BTW, I tried building the core on Windows, but got an error:
Regular snes9x2010 builds fine.
1 Like
It is actually slightly slower right now. I compiled it on mac and it worked fine.(That issue seems unrelated since I didn’t change any #defines)
[QUOTE=guicrith;49514]It is actually slightly slower right now. I compiled it on mac and it worked fine.(That issue seems unrelated since I didn’t change any #defines)[/QUOTE] Just cloned the repo with your latest commit and it built without issues on Windows.
As you say, though, it’s still slower. Around 40% slower in a quick test I did. I will follow your updates with interest, though. 
http://caffie.net:31415/Ersanio/super-mario-all-stars-disassembly/tree/master
These seems related to the super mario allstars bug.
There are actually 5 roms in SMA (selector,smb1,smb ll,smb 2,smb3)(4 of them likely being run in 6502 emulation mode),between the selector and loading a game the active rom is likely switched and the console is soft-reset leaving ram the same but clearing everything else.(including button data)
Since snes9x is not built to be messed with in such a low level way the buttons remain in a weird state.
libretro-dosbox have a mouse bug (tested on 4 games), when i use mouse grab toogle or fullscreen, sometimes mouse rests on the invisible wall, but if you move it in the opposite direction several times, then it disappears, in some games this is almost not observed (kyrandia), in some games it constantly appears ((space quest 1 vga, space quest 4, space quest 5) - the easiest way to find this bug, the opening game settings panel). Sometimes it is really annoying that you just can not move the ingame mouse left and right because of some invisible wall.
It happens in Mame or TyrQuake too: that’s a Retroarch input bug.
It happens in Mame or TyrQuake too: that’s a Retroarch input bug.
I would like to know if somebody already created an issue with this glitch? on the bugtracker or not… If not, you do not mind if i create new issue on https://github.com/libretro/RetroArch/issues?.
I think the mouse range is defined by a calculation based on the resolution instead of being relative, something like that… Probably needs a rewrite here but I don’t have the answer.
When I tested libretro-dosbox 3 weeks ago, it didn’t have support for auto cycle rate detection (which standard dosbox has out of the box). That means I have to fiddle out correct cycle values for each game. I see that as one of the biggest flaws with libretro-dosbox. Also, it should be loaded from the dosbox.conf. Right now, these values are ignored and you have to change them from the XMB.
What is driving me crazy is the screen tearing, esp. in games like Jazz Jackrabbit. It gives me headaches. I tried all sorts of things with vsync and double buffering in the config file but it doesn’t help. However, using the same config file with original dosbox 0.74, I don’t have screen tearing.
Another problem is that you cannot type on your keyboard within libretro-dosbox, because you trigger all sorts of retroarch shortcuts. I know only one workaround but it breaks the rest of retroarch: you enable a key modifier to be used with all retroarch-shortcuts. The drawback of this is that you have to press the key modifier on your keyboard and your PS/XBOX/Steam button to get into the retroarch xmb. So either you practically drop gamepad support for retroarch to use the keyboard in libretro-dosbox or you cannot use your keyboard with libretro-dosbox. You could theoretically map all retroarch shortcuts to highly unlikely used keys, but it would be way better, if it would just work. If there is another way to fix this, I’d like to know it. If not, I think one of the following things could improve the situation:
- libretro-dosbox specific shortcut to enter keyboard typing mode (and display a hint how to enter typing)
- only allow the xmb menu shortcut when libretro-dosbox core is loaded
- remap all retroarch shortcuts to be used with key modifiers only when libretro-dosbox core is loaded EDIT: The entire keyboard problem could also be solved by providing a key combo that toggles to expose the entire keyboard to the loaded core. This would avoid creating a dosbox specific hack and that combo could be delivered with retroarch from the start.
I’ve long thought a keyboard/mouse “capture” would be nice for classic computer cores, but I think you can set up a core config override that assigns the hotkey enabler only when that core is loaded, right?
Would it be possible to add support for taking input from a video capture card, perhaps using libavdevice or something similar (my technical knowledge in this area is limited)? I have a few retro consoles hooked up via composite to my Windows machine via a Hauppauge WinTV-HVR-1250 card, and I’d love to be able to play them with RetroArch’s excellent CRT shaders and overlay functionality applied. I also posted in the V4L2 core thread, though I don’t know whether or not that core would be appropriate for what I’m requesting. If this functionality is already present somewhere, please let me know as I haven’t been able to dig up any info on it.
Yes https://github.com/libretro/libretro-video-processor but it is for Linux so you have to dual boot or use an another device.
As far as I know Windows has no unified video in driver and that’s why it’s Linux only.
Hmm… isn’t DirectShow basically the Windows equivalent of V4L2? I see that FFmpeg has support for both, and RetroArch includes an FFmpeg core for playing back video files. How feasible might it be to extend the FFmpeg core’s functionality so that it accepts input from capture devices like the standalone FFmpeg does? https://trac.ffmpeg.org/wiki/Capture/Webcam
I haven’t heard of that but it may be possible. I don’t use Windows or know how to write drivers for it so you have to ask someone else or make a new thread.
Current BlueMSX doesn’t support disk images. The Stand-alone version has a really nice feature to cycle between disks contained in a zip file.
It would be great to have that in Retroarch.
I wish most cores to have an option to debug/view only certain sprite layers, like some emulators do. This way would open the possibility to experiment with different shaders per layer in order to find the best looking result for a core or a game.
The unified shader system across all cores is one of the best features RetroArch has unlike other applications, and I think it should be exploited.
Mednafen PSX-related feature request: An overclock mode that actually tampers with the clock speed. To be exact, it would make the emulated CPU run at the same clock speed it does on some PS2 systems, about 37 MHz. There would be three modes: One to just loosen the timings like the current overclock does, one that only changes the clock speed to the clock speed the PSX CPU runs at on the PS2, and one where it does both.
Not sure if you can prevent audio from speeding up, though.
About the MAME/FBA cores: Could be a way to bypass/serialize the internal mame options (that blue menu) directly to the Options menu for that core, in RetroArch? I don’t know if this is even possible…
we can break some of the options into core options but we figured it’s easier and less confusing for users to just keep the built-in menus intact in this case.