Release DraStic Nintendo DS emulator

[Stainy]

Oh!  That's funny!  So it's the sand that I'm stuck in and not the emulator stuck on me!  Thanks for the hint.  

hehehe

 

[Exophase]

I updated the emulator to version 2.3.0.0p in the repo. See the linked readme on the first post for what's changed (although admittedly I probably missed some things). Unfortunately, nothing Pandora specific this time except an icon cache file. But at least it's out a little earlier than the non-beta Android version.

Please ask here if you have any questions about new features, and please tell me if anything was broken.

 

[Linux-SWAT]

I'll try this, and while I think about it, I noticed the screen sometimes move "too much", when playing Picross with the previous version.

 

[ekianjo]

I'll try this, and while I think about it, I noticed the screen sometimes move "too much", when playing Picross with the previous version.

what do you mean exactly by "too much" ?

 

[Exophase]

Love it, I always get old complaints only right after I release something.

Sometimes games jitter the contents of the screen for a temporal anti-aliasing effect, there isn't an awful lot that can be done about it on displays that have better response times than DS's.

 

[Ziz]

Love it, I always get old complaints only right after I release something.

Sometimes games jitter the contents of the screen for a temporal anti-aliasing effect, there isn't an awful lot that can be done about it on displays that have better response times than DS's.

The DS screen is even worse than the Pandora's one?

 

[Exophase]

The DS screen is even worse than the Pandora's one?

I'm not totally sure, but I really doubt that the shaking graphics in Picross 3D is an emulator bug rather than intentional (it happens in DeSmuME too). From a quick look on my DS Lite I couldn't see any shaking, but the graphics also looked smoother. DS does have edge anti-aliasing that neither emulator implements (couldn't tell if it was enabled here), but that wouldn't explain the textures also looking smoother. DeSmuME developer zeromus looked into it and concurs that it's deliberately done by changing the texture transform matrix:

http://ngemu.com/threads/picross-3d.136652/

One kludgy thing you can do to try to work around the shaking is setting frameskip to manual 1.

 

[Linux-SWAT]

Ok thanks.

I'll keep my other old complains for the next release :^p.

 

[Hồng Thất Công]

Thanks Exphase.  Lots of fixes and optimations yet in this version according to your readme.  Amazing to see you can still squeeze juices out of a dried orange and improve on an already perfect emulator 

 

[Exophase]

I have a big list of CPU emulation optimizations I want to attempt too, but they'll have to wait for the next version. I'm also really nervous about them breaking the emulator, since I've had to fix dozens of bugs in that part of the code as it is, so I'll probably make it possible to switch to a separate experimental mode to get the optimizations (which you can then get out of if it breaks something)

 

[Hồng Thất Công]

Have you had any thought of using DSP capability for anything on DraStic? 

 

[levi]

Picross 3D does jitter on a real DS - it's not an antialising attempt as far as I can tell, but some weird rounding error type thing I suspect.

 

[Exophase]

Have you had any thought of using DSP capability for anything on DraStic?

notaz was experimenting with moving some of the 3D rendering to the DSP. I gave him an integer-only version with optimized Newton-Raphson divisions (DSP is super bad at normal divisions and floating point in general) and worked to move critical structures to its embedded fast SRAM. Despite this, it was still much slower than the normal NEON version (like 4x slower, also about the same speed as the C version), so it really only accelerates things a little if you have it render a small part of the screen while the CPU renders the rest. If the rendering is allowed to start really early it accelerates things a little more by having the DSP render part of the screen while the non-rendering emulation happens. But this causes big graphical problems in various games.

It looked like it'd give a non-negligible speedup, but he gave it to EvilDragon to test and he says in practice it made things slower. It sounded like it interacts poorly with frameskip.

Maybe notaz wants to try more with it. If he does I'll see about releasing it. But don't expect much. For the DSP to really be useful I think it would need to have code that's carefully optimized for it, but that could be extremely hard.

Picross 3D does jitter on a real DS - it's not an antialising attempt as far as I can tell, but some weird rounding error type thing I suspect.

I doubt it's not deliberate. It's not a rounding error, they're changing the texture transformation matrix which causes the sub-texel offsets of the textures to wiggle slightly. I couldn't see jitter on a DS Lite, although I only went into the tutorial. What sort of DS are you using?

 

[PowerGod]

(I'm always interested and scared at the same time when they get technical )

 

[levi]

I played Picross 3D originally on my DS lite.  IIRC it was most obvious on the larger puzzles, rotated to angles where the nearest bricks were very near.

 

[rohezal]

Exophase, would it be possible to have the rendered image filtered by the dsp to avoid sharp edges or upscale it nicer?

 

[Exophase]

Exophase, would it be possible to have the rendered image filtered by the dsp to avoid sharp edges or upscale it nicer?

Yes, but will I do it? Probably not.

 

[rohezal]

Sorry I did not want to sound demanding. Thank you for your hard work on Drastic and for the free Pandora version of it .

 

[Hồng Thất Công]

You know, I would not mind paying for a PYRA DraStic version with all the bells and whistles. I bought an Android version but due to physical controls on the Pandora, I tend to use the Pandora version much more.

 

[Exophase]

Sorry I did not want to sound demanding. Thank you for your hard work on Drastic and for the free Pandora version of it .

No problem, you didn't sound demanding at all. I'm just spread kind of thin with stuff to do on this. I do want to do some Pandora-specific work like USB gamepads, configurable controls, and maybe some screen stuff. Using the DSP is just not high on the list, unless notaz wants to mess around with it.

You know, I would not mind paying for a PYRA DraStic version with all the bells and whistles. I bought an Android version but due to physical controls on the Pandora, I tend to use the Pandora version much more.

For the Pyra version Lordus and I are interested in putting in a GLES path for shaders and positioning and stuff. Not really looking to do that sort of thing on Pandora because the overhead is too much for something that needs all the CPU time it can get, but on Pyra it should be better.

Not to say the Pyra version will have all of the features of the Android one, but then again you may be able to run the Android version too.