Joined: 9/12/2014
Posts: 536
Location: Waterford, MI
Booting into firmware during gameplay would be useful for Sims 2 speedruns.
How do you boot into firmware? I've found a good firmware dump marked with a green checkmark and went under sync settings to manual boot but no luck.
Booting into firmware during gameplay would be useful for Sims 2 speedruns.
How do you boot into firmware? I've found a good firmware dump marked with a green checkmark and went under sync settings to manual boot but no luck.
Did you enable real bios? Real NDS bios files are required for firmware boot, firmware boot does not work without them.
Ok, so... Emulations seems deterministic now. The sync settings seem to include everything that needs to be included.
There is only one thing left to implement... And that's very important in my very humble opinion... Native upscaling. Some games, like Metal Slug 7, need it real badly.
There is only one thing left to implement... And that's very important in my very humble opinion... Native upscaling. Some games, like Metal Slug 7, need it real badly.
This is not going to be implemented here. This requires OpenGL/GPU which I believe is not possible to use within waterbox.
Not like it matters overall, casual users can use upstream for goodsizers, and we do not encode DS with goodsizers regardless.
First of all thanks for the hard work CasualPokePlayer!
With the latest dev waterboxing versions the sript for the stylus works.
But only for vertical display, in horizontal, even with inverted display of screens it does not work (see screenshots below).
The stylus does not seem to work correctly if you are in windowed fullscreen or in full screen.
In addition the virtual pad does not work (Schema warning: Schema entry ":'TouchX' will not correspond to any control in definition 'NDS Controller')
Also, is it possible to have a dedicated key for the microphone?
I just noticed that there are some other adjustments that need to be made to the Sync Settings:
"Use Real BIOS" must be forced to True for recording movies;
"Skip Firmware" must be forced to False for recording movies;
"Firmware Override" is already forced to True for recording movies, however the SyncSettings.json file may save it as "False".
For the rest, the Sync Settings seem good.
Edit: another issue found. In TAStudio, if you enable Recording mode and then unpause with the TAStudio window focused instead of the main BizHawk window, it will record the touch pressed for all frames, with coordinates 0, 0. If instead I unpause emulation while the main window is focused, this doesn't happen.
Edit 2: ok this is a major problem. When you try opening the RAM Search window, BizHawk simply freezes.
If in "screen layout" you switch from "vertical" to "bottom" when you re-select "vertical", the stylus is blocked on the upper screen.
And it is only possible to move it in a quarter of the screen.
(Even after closing and reopening Bizhawk.
You have to go back to the bottom to have all of the screen space for the stylus.)
EDIT: This is due to the change of window size.
If we go back to window size x2 the stylus is again correctly on the bottom screen, but if we increase the size of the window (via "view" -> "window size" in 3x, 4x ect this blocks the stylus in a given region that changes depending on the size of the window.
Edit 2: ok this is a major problem. When you try opening the RAM Search window, BizHawk simply freezes.
Strangely enough if you simply insert ram address in ram watch it doesn’t have issues.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
First of all thanks for the hard work CasualPokePlayer!
With the latest dev waterboxing versions the sript for the stylus works.
But only for vertical display, in horizontal, even with inverted display of screens it does not work (see screenshots below).
The stylus does not seem to work correctly if you are in windowed fullscreen or in full screen.
In addition the virtual pad does not work (Schema warning: Schema entry ":'TouchX' will not correspond to any control in definition 'NDS Controller')
Also, is it possible to have a dedicated key for the microphone?
The issue with the script it isn't possible for the script to detect inverted screens (and the proper fix for that is nontrivial). The current work around is to manually set the invert variable within the script. The script should work fine mostly as long as you correctly set it.
The stylus works correctly in all cases from what I recall, but the script might be funky if you do not have the window at the correct aspect ratio (i.e. full screen would be a no go)
Virtual pad not working is due to me changing the Touch axis controls to have a space in the name. Should be an easy fix.
The microphone input is currently implemented as an axis, with 0 silence and 2047 the loudest possible value. You can set the controls for it the same as you would do with other analog controls.
I just noticed that there are some other adjustments that need to be made to the Sync Settings:
"Use Real BIOS" must be forced to True for recording movies;
"Skip Firmware" must be forced to False for recording movies;
"Firmware Override" is already forced to True for recording movies, however the SyncSettings.json file may save it as "False".
For the rest, the Sync Settings seem good.
Edit: another issue found. In TAStudio, if you enable Recording mode and then unpause with the TAStudio window focused instead of the main BizHawk window, it will record the touch pressed for all frames, with coordinates 0, 0. If instead I unpause emulation while the main window is focused, this doesn't happen.
Edit 2: ok this is a major problem. When you try opening the RAM Search window, BizHawk simply freezes.
So for sync settings.
1. I could agree with this, although treatment of this has gotten inconsistent and blah blah casual user tasing also someone will complain we don't require it for desmume when desmume offers support for real bios anyways.
2. Above, although I could disagree. Getting a good firmware dump is a nightmare, and currently I'm having the internal CRC16s checked along with the SHA1 *decrypted* code checked for verification, the latter is questionable in effectiveness and likely different across all 7 NDS firmware revisions, only 3 of which have their hashes recorded.
3. I don't get this. It's handled the same way as the use real time sync setting: the sync setting isn't used and instead it will always be treated as a specific way (we want firmware consistent so it's treated as true). It doesn't matter what the sync settings json saves it as at it will be ignored and treated as true.
TAStudio and touch controls have funky interactions when using the mouse. This isn't in my field to fix at all.
RAM Search freezes? Odd, I assume it's looking at main ram at default and not one of the system buses. I would suspect this issue wouldn't be DS specific anyways, as waterbox cores share largely the same code for handling memory domains.
If in "screen layout" you switch from "vertical" to "bottom" when you re-select "vertical", the stylus is blocked on the upper screen.
And it is only possible to move it in a quarter of the screen.
(Even after closing and reopening Bizhawk.
You have to go back to the bottom to have all of the screen space for the stylus.)
EDIT: This is due to the change of window size.
If we go back to window size x2 the stylus is again correctly on the bottom screen, but if we increase the size of the window (via "view" -> "window size" in 3x, 4x ect this blocks the stylus in a given region that changes depending on the size of the window.
Is this an issue with the script or with actual inputs? The script might have these issues due to the way it works (I'm not qualified to fix it), but actual input should be fine?
IIRC appveyor builds debug, and in debug waterbox has some extra code when reading memory, which makes it VERY VERY slow. Try release build.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Could there a different way to bind the Mic Input? The way it is now is a little annoying, as you have to bind it the same way as the Touch X and Touch Y analog inputs.
Maybe there could be an option in the sync settings that lets you change how loud the mic input is, and then binding that to a hotkey, kinda how the microphone has a hotkey in DeSmuME. This would make using it in TAStudio a bit easier too.
Could there a different way to bind the Mic Input? The way it is now is a little annoying, as you have to bind it the same way as the Touch X and Touch Y analog inputs.
Maybe there could be an option in the sync settings that lets you change how loud the mic input is, and then binding that to a hotkey, kinda how the microphone has a hotkey in DeSmuME. This would make using it in TAStudio a bit easier too.
This is probably more appropriate as a hotkey than some sync setting / in the input roll. I'll take this into consideration.
I've fixed up Virtual Pad. It should work fine now.
I also looked into lua script issues; they're mostly probably not fixable without just making it into a not lua script (which is out of my field). The actual input seems fine, but the lua script doesn't like some settings in BizHawk (anything that screws the aspect ratio is a no go, and BizHawk seems to refuse to expand the screen past 2x, which causes issues with the script if it's set that high).
I couldn't replicate the freezing exactly with RAM Search. All I got was it took a while to get up (which is expected when it's going through >4 million addresses).
So for sync settings.
1. I could agree with this, although treatment of this has gotten inconsistent and blah blah casual user tasing also someone will complain we don't require it for desmume when desmume offers support for real bios anyways.
2. Above, although I could disagree. Getting a good firmware dump is a nightmare, and currently I'm having the internal CRC16s checked along with the SHA1 *decrypted* code checked for verification, the latter is questionable in effectiveness and likely different across all 7 NDS firmware revisions, only 3 of which have their hashes recorded.
Then just force the firmware IF a known firmware file is found in the firmware folder.
So for sync settings.
1. I could agree with this, although treatment of this has gotten inconsistent and blah blah casual user tasing also someone will complain we don't require it for desmume when desmume offers support for real bios anyways.
2. Above, although I could disagree. Getting a good firmware dump is a nightmare, and currently I'm having the internal CRC16s checked along with the SHA1 *decrypted* code checked for verification, the latter is questionable in effectiveness and likely different across all 7 NDS firmware revisions, only 3 of which have their hashes recorded.
Then just force the firmware IF a known firmware file is found in the firmware folder.
Clarification. Real DS does have a firmware screen on boot-up, and it requires both real bios files and real firmware file to get that screen in emulation. But since real firmware files are a nightmare to manage, they are only actually required if the TAS changes system settings mid-game. In other situations we want the TASers to have an option similar to desmume and dolphin where you just load into the game, because that way less potential desync risk is involved if identical firmware can't be found.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I have done quite a bit of work here, and hopefully addressed most things I can handle.
Firmware has massive verification code to check if the actual bootcode is good (although that is lacking due to information on hashes being hard to come back and 7 firmware revisions, along with even no-intro having bad hashes in them, so only 3 known hashes are in), along with checking the internal checksums and some hacked firmware detection.
Firmware settings are mostly in as sync settings, with any not (think it's really just stuff like GBA screen position and alarm?) just set to the same values. Wifi APs are forced to the same values similarly. This should make sync issues just a matter of maybe needing the correct firmware revision.
To clarify further on feos: There are some games which currently do not play nice without actual firmware. The fake firmware generate internally works for most games, but some games will freak out over it (mainly if they at all try to access Wifi settings for whatever reason, or maybe they might just see some bad checksums present and go nope). This is an upstream issue, so until they fix this, you might have to use real firmware for some games due to this.
Even further, using the real BIOS is required if playing an encrypted dump of a game. Only decrypted dumps work without real BIOS, due to the BIOS containing the decryption keys and the fake BIOS put in melon lacking them, and putting the decryption keys in there might be muddy legally, so it's uncertain if they will be added in. Most dumps are decryped iirc, and there's typically a decrypted version of every encrypted dump, so this probably isn't too much of an actual issue.
Some debugging stuff has also been added in. Getting registers, setting registers, disassembly and tracelogger have all been implemented. Memory callbacks have not been implemented, mostly due to wbx stuff not playing nice with them (tl;dr, you will crash hard if you try to get/set regs or read out from a system bus while in a callback).
To list some misc stuff, a game db was added, and vpad is complete with all inputs (should mostly resolve Mic Input issues).
I believe now this should be ready to be merged into BizHawk master. I still would ask for some more testing before marking this as released and ready for 2.7 though, so please keep testing.
I've added random noise into Mic Input, simply set it to -1 and it'll output random noise. Fixes some games which expect random values being spammed rather than just measuring out the loudness.
And with that, the new port as been merged to master! Now it just needs some more testing before it can be marked as release ready, get the latest build here: https://ci.appveyor.com/project/zeromus/bizhawk-udexo/build/artifacts
I've slightly re-worked Mic Input. It's been re-named to "Mic Volume", and controls how loud the mic input fed into the emu by a percentage. Currently, the only mic input fed is upstream's provided white noise. In the future the ability of custom samples to be used should be added (with a sync setting to go use them instead of white noise), but that isn't really so much high priority (considering the lack of games that really need such, and DeSmuMe still exists and isn't going away any time soon).
I feel like in the port to bizhawk, there's no longer proper scaling like you could get on the OpenGL renderer in MelonDS. This makes games more pixelated, which isn't a bad thing per se, but can be a bother to some, including myself.
I've also noticed, clicking *anywhere* in bizhawk, including the settings menu and window title will trigger a tap on the DS screen (not sure where, but it registers as one, since it boots me out of the mario kart DS pre-game showcase)
I feel like in the port to bizhawk, there's no longer proper scaling like you could get on the OpenGL renderer in MelonDS. This makes games more pixelated, which isn't a bad thing per se, but can be a bother to some, including myself.
Scaling like that requires the GPU which is probably not possible to expose from within waterbox, and that also leads to GPU specific issues cough Mupen everything being black on intel igpus cough, general inaccuracies, and potential nondetermination (well, I don't know if games can read out from the raw buffer anyways, so maybe no real determination issues there).
It's also ultimately a lot of work that only appeals to casual players, which may as well use upstream. TASVideos does not use internal upscaling for DS TAS publications, so there is no loss for the purposes of TASes submitted to TASVideos.
DennisOnTheInternet wrote:
I've also noticed, clicking *anywhere* in bizhawk, including the settings menu and window title will trigger a tap on the DS screen (not sure where, but it registers as one, since it boots me out of the mario kart DS pre-game showcase)
BizHawk limitation really. As far as it's aware, your mouse is at the edge of the screen. Blocking a Touch for these cases would require some more hacky code which is a mess. For TASing this probably isn't a real issue, as using the virtualpad would be better.
