TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.2k stars 385 forks source link

[feature request] melonds - return RTC value (somehow) #2153

Open Liger0 opened 4 years ago

Liger0 commented 4 years ago

Actionable points:

Original post follows.


Since the NDS is becoming supported in the developement versions of bizhawk via MelonDS, I wanted to share those 2 features which would be useful.

Lid hotkey to set it open/closed: This would be useful as the seed would be stuck while the internal date advances: this way you can advance the date to the one you desire and still advance the frame independently to be able to hit a determinate initial seed on the pokemon games when pressing on the "Continue" button in an easy way.

Date: Well, this would work along with the lid hotkey, effectively showing the internal clock while doing the advancements. This would also work for gba games (RS only for pokemon), so you can see by the date if you hit the correct seed.

zeromus commented 4 years ago

There's been a lid control since march.

I don't understand the question about displaying the date. What is an "advancement?" Are you going to run desmume in fast forward for weeks to get it to the date you want? We generally don't know what pokemon gamers are doing, because even a million pokemon gamers on a million keyboards can't compose a single coherent paragraph by chance or even when put together by experts.

Liger0 commented 4 years ago

There is no lid hotkey in the hotkey -> NDS setting. Also, advancement refers to frame advancements, which are what you see via frame counter and are already able to manually advance. And no, it's not desmume, nor it is for weeks, nor in fast forward, we are talking of about some thousands of frames, nothing extreme. For the date, making it show on the screen like for the FPS/Frame counter via the "View" option from the toolbar is what I am referring to.

YoshiRulz commented 4 years ago

The lid open and close buttons are in Config > Controllers.... Your other suggestion could be done with a Lua script, or maybe RAM Watch.

zeromus commented 4 years ago

There is lid hotkey in config > controller, if you bind it. How does a few frame advances change the date? a few thousand frame advances will change the MINUTE at best Yoshi: I still dont know what date or time he's talking about, but the HW RTC is probably not easily accessible via memory. It's done in hardware registers and read out by a complicated serial process. We would need to run it out of the core as like a CPU register or as a special fake-registers memorydomain (more scalable than the cpu registers framework, albeit more cryptic)

Liger0 commented 4 years ago

The lid open and close buttons are in Config > Controllers.... Your other suggestion could be done with a Lua script, or maybe RAM Watch.

Thanks, I didn't see that option as it isn't visible without opening a rom, which I now understand since that menu changes depending on the core used. The hotkey options for NDS were all I noticed

There is lid hotkey in config > controller, if you bind it. How does a few frame advances change the date? a few thousand frame advances will change the MINUTE at best

The date includes the minutes and seconds, which is pretty obvious, unless you wanted me to state: Year Month Day Hour Minute Second Millisecond If you go at 23:29, which is the time, that'll will increase the day, which may effect the year in case of the last day. I didn't think I needed to explain this so closely.

So, if an internal clock is used, advancing the frame should also advance properly the seconds and so on to be able to match them with the lid option. I think it already does it by now, or maybe not?

zeromus commented 4 years ago

I don't understand what any of this has to do with the lid condition. You can advance whether the lid is open or closed. The NDS RTC doesn't support milliseconds. If you think the millisecond matters, then you are asking about clock managed by the game software, in which case you will have no choice but to do it through lua and we can close this ticket

Liger0 commented 4 years ago

I don't understand what any of this has to do with the lid condition. You can advance whether the lid is open or closed. The NDS RTC doesn't support milliseconds. If you think the millisecond matters, then you are asking about clock managed by the game software, in which case you will have no choice but to do it through lua and we can close this ticket

No, I'm only referring to seconds, nothing smaller is needed. The lid condition refers to the fact the seed, which advances depending on the frame, will stop advancing with the lid closed, although the time will advance, so you can wait for the time to advance until a certain point, having the combination of data/time and seed needed. Without the lid, they would advance both and you can't easily make them match.

Anyway, I think all of this is possible already, in which case this ticket could be closed as the lid can be opened and closed, the time advances either ways correctly indipendently on the lid condition and is stored in save states and stop to advance when the emulator is paused, and you stated that showing the date without lua isn't to be considered.

zeromus commented 4 years ago

Since milliseconds doesn't matter, you could be asking about the HW RTC clock, in which case lua can't be used. And now that youve described it more, the game is likely to be paused and not using its own internal timer while the lid is closed.

We can leave this ticket open as a feature request to pipe the RTC out of the emulator core. But try to find out if people have done it through lua (when the game wakes up it may resume read ing the RTC into a known location which can be easily read through lua)

CasualPokePlayer commented 2 years ago

Why exactly is this needed? Assuming you don't manually change RTC within the DS firmware, you can just have Use Real Time set to false and measure RTC according to the set initial time and frame count.

YoshiRulz commented 2 years ago

That would require a fixed frame rate; I seem to recall something about a 30 fps mode? Besides, we shouldn't make users keep reinventing the wheel (though for Lua there's only so much we can do).

CasualPokePlayer commented 2 years ago

There is a fixed framerate for RTC. I don't know what you mean by 30 fps mode, that sounds more a game construct rather than a console construct (the DS runs at 59.8261 fps).

YoshiRulz commented 1 year ago

How about making WaterboxCore.GetRtcTime public and exposing it in NDSLuaLibrary? Just need to add [RequiredService] public NDS Emulator { get; set; }. edit: And it seems to be a Unix timestamp, so make that clear in the docs. I don't think returning a formatted string would be a good idea.

CasualPokePlayer commented 1 year ago

That could work usually (probably slightly better than the frame count idea.)

Although to be clear that does not actually correspond exactly to the RTC reported by the emulated software. GetRtcTime is meant as a monotonic clock, which just ticks every frame. RTC can be changed on the DS, so to support that the core internally sets an offset to the RTC to match up with the set time while the monotonic clock has no modifications done. In practice this isn't really an issue unless someone decides to go change RTC in the firmware.

YoshiRulz commented 1 year ago

No point in half-assing it. I was just hoping that would be sufficient, as I didn't see an obvious getRTC function on the unmanaged side.

CasualPokePlayer commented 1 year ago

Since a lot of cores have RTC anyways maybe it could be best to expose this in IDebuggable (?) / some new interface? as a new field. Like "CurrentRTC" (defined as seconds since Unix epoch, or just total seconds when epoch is not applicable like for GB, or null if RTC is not being emulated currently or NIE if RTC is not applicable to the core at all, granted latter wouldn't be needed for a new interface). Maybe more fancy with a new interface? This was it would be simple to expose in other cores without dealing with specific console lua libraries and not slapping it in cpu registers.