When I press the keys I've selected in Joypad Configuration, the emulator hangs, for as long as the key is being held.
This makes doing anything in a game virtually impossible.
This is using the Beta-3 compiled release from 4 days ago (c2a23a9).
I'm sorry we did not have an issue template, I just added one, can you please give some information about your configuration:
Interface (wX, GTK, etc.)
Build (is this the pre-built or your own build)
Running Windows 8.1 Pro, honestly not sure about Interface, but like I said I'm using the pre-built Beta-3 release from 4 days ago. Github says it's from commit f7f67ff, the .exe says it's from c2a23a9 though.
I expect that key presses trigger the actions or button presses they are mapped to.
The emulator hangs whenever any of the keys I've configured are held down (also causes the audio to be stuck in a loop exactly like what happens in #45, I don't think the two issues are related though.)
Run the emulator, load a game, press any keys that have been configured (it isn't limited to standard controls, special hotkeys also cause the same issue.)
Operating System (Windows, Mac, Linux, etc.): Windows 8.1 Pro
Interface (wX, GTK, SDL, MFC, default is wX): Not really sure how to check, but ↓
Version of code (pre-built binary version, or commit ref, or just "master"): Using pre-built binary version.
I have issues myself on windows with the keyboard while other people don't, there is something weird going on with this, perhaps we will use SDL for keyboard input at some point.
Right now trying to figure out if this is an issue specific to this build.
One thing you can try is installing msys2, starting the MINGW 32 shell, and running ./installdeps and following the instructions to try your own build.
Well, I tried. Can't compile.
This is straight from the repo, I'm fairly certain I'm not missing any files from it, if I'm doing something wrong then I don't really know what.
There is dependencies\sdl\include\SDL_joystick.h , not very sure about it but I tried copying that over to src\sdl but it still said it couldn't find that file, somehow. I probably shouldn't do that since I have no clue whether that SDL_joystick.h is correct or not, anyway.
Oh sorry, that was a PR we just merged earlier today...
@Ammako should be fixed, please try again! The #include statement in that PR was wrong.
Well, it does compile, doesn't run unless I place it in mingw32\bin since it complains about every single dependency being missing and I don't really want to register all of these (I don't think it should be necessary, and no clue why it asks for all of that.)
Anyway, it compiles, and it runs, but not very well. The input bug is still there, but this also happens on most games.
LoZ: A Link to the Past still looks normal though, not sure what makes it any different from the others.
Are you using a VM or something like that?
Also you can run it from the shell by just typing ./visualboyadvance-m
Nope, this is a regular Windows install. I have Beta 2 from Sourceforge which works fine in every way, the pre-built Beta 3 looks normal aside from that input problem, but this compiled version has a messed up display on my end for some reason.
(I didn't realize that running it directly from mingw32 would automatically get the dlls, that's good to know.)
Alot of really weird shit has been happening with this project, first the keyboard broke in two interfaces between minor builds where there was no code related to the keyboard at all, now this crap.
Am I the only one who has been having this problem, or has anybody else experienced it?
I can compile a bunch of versions and figure out where it stops working, could be a long hunt though since I wouldn't be able to tell exactly when that started.
For the graphical problem there's still a possibility it's an issue on my end making it compile or run wrong, unless other people are getting the same results. I guess I'll try compiling the same version as was used for the pre-built and see.
Eh, I downloaded 4 older versions and none of them will compile successfully, so I guess I can't really do that. Something's up with XAudio2.h, because having re-downloaded the version which I had working yesterday doesn't work anymore because it can't find XAudio2.h (other older commits I've tried had the same problem.)
At the moment we know of the issue and are working to fix it. Be patient. As for xaudio2 you need to download the git master using git clone https://GitHub.com/visualboyadvance-m/visualboyadvance-m.git and then the installdeps script will clone the proper git submodule to allow xaudio2 support.
Ah well, apparently I didn't realize that ./installdeps also added extra stuff to the vba git folder itself every time. My bad!
@Ammako I heard of more issues with LTO so I disabled it on Win32 for the time being, can you try to build again (with master) and see if it fixes the artificats and such?
The same problem with graphics is still present, along with the input problem.
@Ammako Can you try both the Simple and the OpenGL renderer and see which one has the graphics issue?
I did, and I didn't see a difference.
@Ammako Ok thanks! So it must be an emulation bug. Just to make sure the hardware is fine, does your windows run stable without crashes and blue screens? Have you run memtest86 at any point recently?
I don't remember any blue screens since I got it about two years ago. Closest thing to a crash was from the battle.net app, which gets very unstable if I leave it running while updating gpu drivers (it locked up my whole computer when I tried pulling it back up after drivers were done updating), otherwise nothing.
Nothing has ever given me any trouble aside from these newer commits of VBA-M, even the older ones work fine (and even the pre-compiled beta 3 that spawned this bug report about input.)
As for memtest, I haven't.
Just an update, I can reproduce the emulator freezing on button presses issue now in my windows VM, so I should be able to figure out a fix soon, just as soon as I figure out how to make it show a debug console in windows.
This seems to be some kind of strange random issues in how wxWidgets handles the keyboard.