Release DraStic Nintendo DS emulator


Not for the moment but as no Pandora users ever reported this, i suppose all was fine with earlier SZ. BTW notaz rewrote all the vsync code in latest SZ so maybe this can be the reason for this strange issue.
 
The emulator shouldn't ever skip frames if frameskip type is set to none. And it only does an explicit wait for vsync at game startup, or when a state is loaded. After that implicit times are used, which works because the system time and the refresh rate are derived from the same clock. This means that the frame rate should appear to be exactly 60Hz when measured on the Pandora.

If this assumption is wrong it'll cause the frame flip drifts out of the vblank period, maybe that could cause a big stall and halve the framerate. If the initial vsync is off this could maybe exacerbate the problem.

Can you confirm that it always happens after same amount of time? And does it persist after a save state is loaded, or when the game is reset?
 
Well, for Chrono Trigger (the game i tested mostly) this issue can occur even very soon, just start a new game and it usually happens at the very beginning of the game (first time you walk in World Map or in Leene Square you can just let Chrono run for a while and usually all becomes very choppy). It also happens after a save state is loaded (maybe not instantly but it still happens). Cant say when the game is reset. However the easiest way to reproduce this is just play the game for a while with frameskip set to none.

EDIT: i also tried launch the game then restart (always with frameskip set to none) and that issue is still present. If i set show speed option to yes in Drastic menu the number on top left corner (i am playing with 2x1 mode) fluctuates like crazy while the number on the right stays constantly at 100%.
 
Last edited:
I just found a strange behaviour with Drastic 2.3 and latest SZ.
Are you sure it was different on other SZ versions?

The emulator shouldn't ever skip frames if frameskip type is set to none. And it only does an explicit wait for vsync at game startup, or when a state is loaded. After that implicit times are used, which works because the system time and the refresh rate are derived from the same clock.
Unfortunately this is not true, there is a small drift and always was, I've only minimized it as much as I could. The drift even differs between different pandoras, I'm not even sure why.
 
Unfortunately this is not true, there is a small drift and always was, I've only minimized it as much as I could. The drift even differs between different pandoras, I'm not even sure why.

Do you know how much the drift is?

I don't think that's the problem though.
 
Are you sure it was different on other SZ versions?

Not 100% sure because i didnt use that much my Pandora in the last year (it was recently shipped to Germany for RMA) but being Drastic 2.3 released over one year ago it seems pretty strange noone noticed this issue before so i suppose with earlier SZ Drastic performed correctly.
 
I just upped a video (unfortunately made with really poor quality) which show the issue i found:


This was with frameskip set to none, scrolling is very choppy at the beginning of the video, then becomes perfectly smooth at the end when Chrono exit Leene Square.
 
Can you do the same sort of video with auto-frameskip set to something like 1 or 2? I know you said you tested with auto-fs, but I'd like to see a video.

I've seen this sort of jittering happen when the timing is marginal w/o frameskip. It has to do with how the audio synchronizes, and it could be that something else is getting more in the way of audio latency now. I could try a build with increased buffer sizes to see if it helps. But auto-frameskip will allow the emulator to skip frames to keep the audio buffering from falling into the danger zone. Just being able to skip one frame at the right time can keep it synchronized without having to skip more later. And under these circumstances I haven't seen this jitter, unless the auto-frameskip has to skip frames and the render time still ends up exceeding the buffering time (like in the more demanding 30Hz games, like FF:4HoL on a 1GHz device)
 
Can you do the same sort of video with auto-frameskip set to something like 1 or 2? I know you said you tested with auto-fs, but I'd like to see a video.

Sorry no video this time but i think i'll made another one tomorrow. In the meantime, as you suggested, i made a straight 20 mins Chrono Trigger shortplay with auto frameskip set to 1 and the scrolling was smooth 99% the time (i only noticed some very minor slowdowns in Guardia Forest and some very minor audio stuttering when entering/exiting towns and buildings). I'll also try later Chrono Trigger and some other NDS games with auto-fs 2 and report.
 
Here is a new video made with autoframeskip set to 1:


EDIT: I must say with both auto frameskip 1 and 2 Chrono Trigger performs a lot better than with frameskip 0 altough still some occasional drop of frames can be noticed during gameplay. I also tested again Contra 4 (this time with autoframeskip 1) and performance was indeed very good with smooth scrolling most of the time (well, except the tunnel stages but that was because my Pandora is not fast enough being only overclocked to 800 Mhz).
 
Last edited:
I could try a build with increased buffer sizes to see if it helps.

In case you release a new Drastic build, please can you add the ability to set the CPU clock speed from within the GUI? Moreover NDS Bios in PND need to be fixed, right now i am using my own bios in Drastic 2.3 to have all sfx intact in Chrono Trigger.
 
Last edited:
In case you release a new Drastic build, please can you add the ability to set the CPU clock speed from within the GUI? Moreover NDS Bios in PND need to be fixed, right now i am using my own bios in Drastic 2.3 to have all sfx intact in Chrono Trigger.
That and set the Sysspeed would be a realy nice Feature :)
 
I'm gearing up for an RPi 2/3 release, hopefully:

https://www.raspberrypi.org/forums/viewtopic.php?f=78&t=170820

For those who are wondering - and the main reason I'm posting this here - I do intend on incorporating the controls configuration features into a Pandora version sometime relatively soon. And possibly some screen positioning options, although on Pandora they can't be completely freely configurable; the theoretical best is only one screen that can be freely scaled. I also probably will not include the hires rendering option for Pandora, it's just too demanding.

The RPi version may also serve as a basis for a Pyra version, at least initially.
 
Last edited:
I'm gearing up for an RPi 2/3 release, hopefully:

https://www.raspberrypi.org/forums/viewtopic.php?f=78&t=17082

For those who are wondering - and the main reason I'm posting this here - I do intend on incorporating the controls configuration features into a Pandora version sometime relatively soon. And possibly some screen positioning options, although on Pandora they can't be completely freely configurable; the theoretical best is only one screen that can be freely scaled. I also probably will not include the hires rendering option for Pandora, it's just too demanding.

The RPi version may also serve as a basis for a Pyra version, at least initially.
Just a heads up that I have a PI2 sat under my TV. ;)
 
I may have an OMAP5 devboard... just saying.

For the current RPi port to be usable on Pyra it'd need OGL ES support. Is that currently implemented?

Otherwise I was going to do a DRM backend for it. But I don't really know how to code this yet. I need a good reference.
 
Back
Top