search

retro100 / dosbox-wii

DOSBox Wii
http://wiibrew.org/wiki/DOSBox_Wii
GNU General Public License v2.0
7 stars 1 forks source link

Controls dont read ingame? #4

Closed carnage702 closed 3 years ago

carnage702 commented 3 years ago

After mapping the buttons the games just dont read any button you press that is mapped on wiimote or classic controller , and once this triggers, it will never revert back, not even if you delete all confs/mappers and start dosbox fresh.

you can see the discussion here. https://gbatemp.net/threads/dosbox-conf-and-map-files-collection-for-wiiflow.348496/page-14#post-9448420

last pages

retro100 commented 3 years ago

Maybe the problem is that the new devkitPro and libogc etc are not full compatible with the old versions. See may second message on https://github.com/dborth/dosbox-wii/pull/57

Also on the https://github.com/retro100/dosbox-wii/tree/v1-7_r1_wiimpathy branch I have to fix the issue with no wiimote response. I have to add a WPAD_ScanPads() at the main loop.

Does the problem also exist on the new version 1.7x beta2? Or only on the old 1.7x beta?

carnage702 commented 3 years ago

Maybe the problem is that the new devkitPro and libogc etc are not full compatible with the old versions. See may second message on dborth#57

Also on the https://github.com/retro100/dosbox-wii/tree/v1-7_r1_wiimpathy branch I have to fix the issue with no wiimote response. I have to add a WPAD_ScanPads() at the main loop.

Does the problem also exist on the new version 1.7x beta2? Or only on the old 1.7x beta?

the issue is wierd for some people beta 1 worked and then stopped working altogether and even with a fresh install it never readed or loaded any mapper.

on beta 2 all 3 of us had no controls, if you map lets say control to any controller button on wiimote or CC, it will not register anything ingame.

For me neither beta1 or 2 worked i can map and save the buttons, but once ingame i click on the button and nothing happens, for others it was just beta 2, for me on beta 2 i can point the wiimote to the screen and only when the wiimote is on screen is that i can even register the home button, if wiimote isnt on the screen i cant even get home button to work at all.

seems something is either not loading/reading the mapper files or not sending the controls to the games, because it creates the files just fine and you can see on the sd card its all good the files themselves.

Tetsuo-78 commented 3 years ago

Hi, I'm the other guy from that discussion. Thanks for the wonderful work you're doing! Yes the problem persists in the new version. The only difference is that now you can access and use the menu with the Home button, and the Virtual Keyboard works again, but mapper files won't be recognized. I use Dosbox Wii as a Wiiflow plugin, with the dol file on SD:/wiiflow/plugins/dosbox and the DOSBox folder with conf map and games on the root of USB. In my case beta 1 was working. Then after days of heavy use, the controls just stopped working, permanently. The only time I've experienced something similar (using Wiimpathy's mod), was when I tried to use a Wiiflow Lite version compiled with devkitppc_r35.

niuus commented 3 years ago

on beta 2 all 3 of us had no controls, if you map lets say control to any controller button on wiimote or CC, it will not register anything ingame.

Can confirm, no game input at all on Beta 2. Only Home button and moving inside that menu works, though i don't have to point the Wiimote to the screen. This happens with Wii Classic Controller and Wii U Pro Controller. Wii 4.3, loading through Homebrew Channel 1.1.4, SD card only.

retro100 commented 3 years ago

I create some builds with the original 1.7 Version and some small bugfixes to compile/support with/the current devkitPro/libogc version.

The is a special release for finding/testing https://github.com/retro100/dosbox-wii/releases/tag/v1.7.bugfinding

The file dosbox-wii_v1-7_various_fixes.zip contains multiple different builds.

The basis for the bugfixes is the original version 1.7 from https://github.com/dborth/dosbox-wii The bugfixes are in the my branch v1-7-dborth https://github.com/retro100/dosbox-wii/tree/v1-7-dborth

The file dosbox-wii_v1-7_fix1.dol and apps/dosbox-wii-fix1/boot.dol are the same. Also the file dosbox-wii_v1-7_fix2.dol and apps/dosbox-wii-fix2/boot.dol and so on... For testing with HBC simple copy the directories dosbox-wii-fix1, and so on until dosbox-wii-fix6 to your apps directory.

The differences between the versions can be seen at:

fix1: Small changes for update to current devkitPro/libogc version. fix1: https://github.com/retro100/dosbox-wii/commit/b50c3013ea74298e2fa629c2254eec1edf930ffb

fix2: Update Makefile for using auto generated headerfiles from bin2o… fix2: https://github.com/retro100/dosbox-wii/commit/64f887cea311ad57bcc1ab6cd809c2275a01256b

fix3: Some bugfixes for keyboard and some updates from libwiigui repo. fix3: https://github.com/retro100/dosbox-wii/commit/1f0aa4511a435e7c997a6244e2ce04685a7f2e6a

fix4: update/scan the current pad/button states with WPAD_ScanPads(). fix4: https://github.com/retro100/dosbox-wii/commit/9e90ccefdd8ca2b71083dcd602d1554c975c37f9

fix5: update/scan with WPAD_ScanPads() and PAD_ScanPads(). fix5: https://github.com/retro100/dosbox-wii/commit/79fac5bb93201e284b3e20115c15ad35de244bcd

fix6: update/scan with UpdatePads(). fix6: https://github.com/retro100/dosbox-wii/commit/0e14b6952a4746e9531d915eb250499039c00282

fix4 should have the same behaviour(bugs) as the pre-release 1.7x beta2 r4301 dynrec fix3 should have the same behaviour(bugs) as the pre-release 1.7x beta r4301 dynrec

Please test fix6 and fix5 if they are working or have the same bugs.

On my Wii's with the builds fix1, fix2 and fix3 no controller are working. So it looks like that the original v1.7 souce code is not compatible (not bugfree) with the current devkitPro/libogc version.

carnage702 commented 3 years ago

I create some builds with the original 1.7 Version and some small bugfixes to compile/support with/the current devkitPro/libogc version.

The is a special release for finding/testing https://github.com/retro100/dosbox-wii/releases/tag/v1.7.bugfinding

The file dosbox-wii_v1-7_various_fixes.zip contains multiple different builds.

The basis for the bugfixes is the original version 1.7 from https://github.com/dborth/dosbox-wii The bugfixes are in the my branch v1-7-dborth https://github.com/retro100/dosbox-wii/tree/v1-7-dborth

The file dosbox-wii_v1-7_fix1.dol and apps/dosbox-wii-fix1/boot.dol are the same. Also the file dosbox-wii_v1-7_fix2.dol and apps/dosbox-wii-fix2/boot.dol and so on... For testing with HBC simple copy the directories dosbox-wii-fix1, and so on until dosbox-wii-fix6 to your apps directory.

The differences between the versions can be seen at:

fix1: Small changes for update to current devkitPro/libogc version. fix1: b50c301

fix2: Update Makefile for using auto generated headerfiles from bin2o… fix2: 64f887c

fix3: Some bugfixes for keyboard and some updates from libwiigui repo. fix3: 1f0aa45

fix4: update/scan the current pad/button states with WPAD_ScanPads(). fix4: 9e90cce

fix5: update/scan with WPAD_ScanPads() and PAD_ScanPads(). fix5: 79fac5b

fix6: update/scan with UpdatePads(). fix6: 0e14b69

fix4 should have the same behaviour(bugs) as the pre-release 1.7x beta2 r4301 dynrec fix3 should have the same behaviour(bugs) as the pre-release 1.7x beta r4301 dynrec

Please test fix6 and fix5 if they are working or have the same bugs.

On my Wii's with the builds fix1, fix2 and fix3 no controller are working. So it looks like that the original v1.7 souce code is not compatible (not bugfree) with the current devkitPro/libogc version.

fix 1 for me no controls at all not even wiimote pointing at the screen or home button nothing, wiimote pointer only works in the mapper itself.

fix 2 same as abode

fix 3 same as abode

fix4 when i point to the screen the wiimote A is recognized as a mouse right click but no other inputs work and wiimote aiming mouse also doesnt work

fix 5 mouse emulation works same as home button still no mapper gets readed or button i choose besides when pointing wiimote at screen and A emulating mouse click

fix6 same as abode

bonus test i reverted back to 1.7 official and even tryed r and now my controlls dont work either so something is very wierd, it seems when this bug happens it will affect all dosbox versions and mappers dont work.

since you are codding dosbox i just want to know where does dosbox stores stuff, besides the .conf and .map where does dosbox stores saves/ extra settings? on wii itselkf? on a hidden file inside the sd card somewhere? inside the games folders?

retro100 commented 3 years ago

since you are codding dosbox i just want to know where does dosbox stores stuff, besides the .conf and .map where does dosbox stores saves/ extra settings? on wii itselkf? on a hidden file inside the sd card somewhere? inside the games folders?

I only try to update and apply some patches... :-) At the moment I am not aware of any other storage locations where dosbox would save anything.

The bug is very very strange. On my Wii the Wiimote controller stop working for Dosbox Version "1.7x beta r4301 dynrec" from one to another day. All very weird...

Maybe it's easyer to build it with an older devkitPro version to "fix" or avoid this bug.

Does anybody know which devkitPro and lib versions was used for compilation for the Dosbox Wii v1.7 released on June 30, 2012 or which devkitPro and lib versions was used for Dosbox Wii R1 v1.7 (Wiimpathy) released on April 2016?

Tetsuo-78 commented 3 years ago

Fix 1, 2 and 3: controls not working at all. Fix 4, 5 and 6: Home button and IR pointer are working. Mappers not. Returning back to Dosbox Wii R1 v1.7 (Wiimpathy) everything is working again

niuus commented 3 years ago

Fix 1, 2 and 3: controls not working at all. Fix 4, 5 and 6: Home button and IR pointer are working. Mappers not. Returning back to Dosbox Wii R1 v1.7 (Wiimpathy) everything is working again

Besides running at least 20% slower than Beta 1 or 2, i had the exact same results.

retro100 commented 3 years ago

In the next days I will try to compile with the old devkitPro / lib versions and hopefully the bug with controller input doesn't arise.

Besides running at least 20% slower than Beta 1 or 2, i had the exact same results.

I think the 20% slower are because the "bugfinding versions" in dosbox-wii_v1-7_various_fixes.zip based on original version 1.7 from https://github.com/dborth/dosbox-wii with sync to dosbox SVN r3778. And the beta's are synced to SVN r4301. I think dosbox simple made some performance optimizations between r3778 and r4301 (also for the normal (non-dynamic) mode).

vaguerant commented 3 years ago

Is it possible the problem here is not initializing the controllers first?

I don't know anything about the history of devkitPPC, but it seems like modern stuff uses a WPAD_Init() (Wiimotes and extension controllers) or PAD_Init() (GameCube pads) before input starts being scanned. GitHub search is imperfect, but I wasn't able to find any WPAD_Init()s in DOSBox-Wii at all, it seems like input.cpp just starts running the *PAD_ScanPads() functions raw.

carnage702 commented 3 years ago

Is it possible the problem here is not initializing the controllers first?

I don't know anything about the history of devkitPPC, but it seems like modern stuff uses a WPAD_Init() (Wiimotes and extension controllers) or PAD_Init() (GameCube pads) before input starts being scanned. GitHub search is imperfect, but I wasn't able to find any WPAD_Init()s in DOSBox-Wii at all, it seems like input.cpp just starts running the *PAD_ScanPads() functions raw.

well the mapper itself does work so does mouse emulation and the A button so the controls must be initialized i would guess or lse they wouldnt work on the mappers no?

Wiimpathy commented 3 years ago

With SDL, input should already be initialized and scanning controllers. Well, as long as you call SDL_JoystickOpen (which contains WPAD_ScanPads) and use the different poll functions and SDL joy structs. You can also skip this abstraction, and poll input with WPAD... from wiiuse directly. I also remember having issues with WPAD_ButtonsHeld not responding correctly. One of the bugfix here is adding WPAD_ScanPads. But maybe the problem is not about the controllers libs at all. Since it seems to work in the mapper which is polling joy with SDL exclusively.

Isn't it related to the newlib changes once again and how it's failing to access files sometimes? For example, all getcwd, opendir are(were?) unreliable. The conf may not be found. Similar issue with retoarch and genesis GX lately. See eke discussion and fixes : https://github.com/ekeeke/Genesis-Plus-GX/issues/357#issuecomment-809811217

Maybe check cross.pp : https://github.com/retro100/dosbox-wii/blob/master/src/misc/cross.cpp Debug what the LoadBinds() from sdl_mapper is returning? Possible sprintf truncate warnings too ?

retro100 commented 3 years ago

A new beta build is available https://github.com/retro100/dosbox-wii/releases/tag/1.7x.beta3 I compiled it with old devkitPPC / libogc and other old lib versions to hopefully avoid this bug. See https://github.com/retro100/dosbox-wii/blob/master/INSTALL_Wii.md at the end for the used versions.

Also a menu for increase/decrease cycles and frameskip from Wiimpathy's modified R1 Version is included (not all features currently included).

The downside of the beta3 build with the old devkitPPC / libogc is that the performance is lower. Benchmark has only 2.6 FPS instead of 3.0 FPS. I use PC Player Benchmark with DOS/32A instead of DOS4GW. With the original DOS4GW file the values are even lower.

For performance reasons, it would probably be better to use the latest devkitPPC version and find the bug. But for now I hope we have a functional version ;-)

@Wiimpathy thanks for the links.

Also the original Dosbox 1.7 Version is for testing included. Recompiled with my old devkitPPC / libogc installation which I also used for beta3.

niuus commented 3 years ago

A new beta build is available https://github.com/retro100/dosbox-wii/releases/tag/1.7x.beta3 I compiled it with old devkitPPC / libogc and other old lib versions to hopefully avoid this bug. See https://github.com/retro100/dosbox-wii/blob/master/INSTALL_Wii.md at the end for the used versions.

Also a menu for increase/decrease cycles and frameskip from Wiimpathy's modified R1 Version is included (not all features currently included).

The downside of the beta3 build with the old devkitPPC / libogc is that the performance is lower. Benchmark has only 2.6 FPS instead of 3.0 FPS. I use PC Player Benchmark with DOS/32A instead of DOS4GW. With the original DOS4GW file the values are even lower.

For performance reasons, it would probably be better to use the latest devkitPPC version and find the bug. But for now I hope we have a functional version ;-)

@Wiimpathy thanks for the links.

Also the original Dosbox 1.7 Version is for testing included. Recompiled with my old devkitPPC / libogc installation which I also used for beta3.

Tested and... Wii Classic Controller working!

Cons:

Minor QoL request:

carnage702 commented 3 years ago

A new beta build is available https://github.com/retro100/dosbox-wii/releases/tag/1.7x.beta3 I compiled it with old devkitPPC / libogc and other old lib versions to hopefully avoid this bug. See https://github.com/retro100/dosbox-wii/blob/master/INSTALL_Wii.md at the end for the used versions.

Also a menu for increase/decrease cycles and frameskip from Wiimpathy's modified R1 Version is included (not all features currently included).

The downside of the beta3 build with the old devkitPPC / libogc is that the performance is lower. Benchmark has only 2.6 FPS instead of 3.0 FPS. I use PC Player Benchmark with DOS/32A instead of DOS4GW. With the original DOS4GW file the values are even lower.

For performance reasons, it would probably be better to use the latest devkitPPC version and find the bug. But for now I hope we have a functional version ;-)

@Wiimpathy thanks for the links.

Also the original Dosbox 1.7 Version is for testing included. Recompiled with my old devkitPPC / libogc installation which I also used for beta3.

well same sd and same files

on wii everything works fine(abit slower than before but better than before dynarec for sure) i can use wiimote and CC and such and map buttons at will everything responds like it should

on wiiu no controller works like before so something must be way lost imo, since this rev on wiiu doesnt not recognize controller imputs not even home button to bring the overlay, and wiiu overclock is a thing of beaty for this, i guess devkit went way way behind and vwii compat was lost?

Tetsuo-78 commented 3 years ago

Tested beta3 and I can confirm that now the mappers are working again on Wii. Thanks for incorporating Wiimpathy's mod to adjust cycles, really useful for me. I'm noticing however that the settings aren't saved to the .conf files after you close Dosbox. but maybe you are already aware of this. Performance-wise I'm barely noticing that it's slower, the games I've tried are still playable.

retro100 commented 3 years ago

The bug is fixed (hopefully) ;-) Compiling with current devkitPPC / libogc is no problem. SDL_GetTicks() at sdl-wii library (and also the sdl version of devkitPro) doesn't start with zero if the current libogc version is used. But it should. The API docs of SDL_GetTicks() says: "Returns an unsigned 32-bit value representing the number of milliseconds since the SDL library initialized."

The problem was that the behaviour of the libogc function gettime() changed in a newer (current) version of libogc (I don't know at which libogc version this happend). The old libogc Version returns a timestamp relative to the starting point wenn the app (dosbox) was started. The current libogc version returns a very high value. Maybe the absolute time (system time)??? but definitely not the time since the app is started. But sdl-wii (and also the sdl version of devkitPro) rely on the old behaviour. The bugfix was very easy. See https://github.com/dborth/sdl-wii/compare/master...retro100:bugfix-SDL_GetTicks Finding the bug was very hard (and time intensive). The bugfix also works for old libogc versions. The function gettime() returns a 64bit value. SDL_GetTicks() supports only a 32bit value. If SDL_GetTicks() doesn't start at zero the 32bit value is not enough. The dosbox uses GetTicks() (which calls SDL_GetTicks()) to calculate some timing behaviour. For example, Dosbox only updates the status of the joysticks every few milliseconds. If a update is necessary is calculated with the help of SDL_GetTicks(). This logic doesn't work with the wrong SDL_GetTicks() implementation. This was also the reason why the Home-Button for the menu stops from one day to another day :-D (because the value of SDL_GetTicks() get to high).

A new beta pre-release is available. https://github.com/retro100/dosbox-wii/releases/tag/1.7x.beta4 For finding the bug a virtual console was implemented. This virtual console is now used to show the logs/messages from dosbox. So the bug is responsible that there is now a new feature in dosbox-wii ;-)

I hope I can now close this issue :-D

carnage702 commented 3 years ago

The bug is fixed (hopefully) ;-) Compiling with current devkitPPC / libogc is no problem. SDL_GetTicks() at sdl-wii library (and also the sdl version of devkitPro) doesn't start with zero if the current libogc version is used. But it should. The API docs of SDL_GetTicks() says: "Returns an unsigned 32-bit value representing the number of milliseconds since the SDL library initialized."

The problem was that the behaviour of the libogc function gettime() changed in a newer (current) version of libogc (I don't know at which libogc version this happend). The old libogc Version returns a timestamp relative to the starting point wenn the app (dosbox) was started. The current libogc version returns a very high value. Maybe the absolute time (system time)??? but definitely not the time since the app is started. But sdl-wii (and also the sdl version of devkitPro) rely on the old behaviour. The bugfix was very easy. See dborth/sdl-wii@master...retro100:bugfix-SDL_GetTicks Finding the bug was very hard (and time intensive). The bugfix also works for old libogc versions. The function gettime() returns a 64bit value. SDL_GetTicks() supports only a 32bit value. If SDL_GetTicks() doesn't start at zero the 32bit value is not enough. The dosbox uses GetTicks() (which calls SDL_GetTicks()) to calculate some timing behaviour. For example, Dosbox only updates the status of the joysticks every few milliseconds. If a update is necessary is calculated with the help of SDL_GetTicks(). This logic doesn't work with the wrong SDL_GetTicks() implementation. This was also the reason why the Home-Button for the menu stops from one day to another day :-D (because the value of SDL_GetTicks() get to high).

A new beta pre-release is available. https://github.com/retro100/dosbox-wii/releases/tag/1.7x.beta4 For finding the bug a virtual console was implemented. This virtual console is now used to show the logs/messages from dosbox. So the bug is responsible that there is now a new feature in dosbox-wii ;-)

I hope I can now close this issue :-D

i can confirm everything works on wiiu even, retro100 you are a god i love you xD