Compatability

[Exophase]

Nice one dude! You plan on doing a commit or two, or at least suggest this workaround to the Desmume developers?

I let the desmume guys know about it on IRC. I'm not touching their code though ;p

[huckleberrypie]

Yeah, saw the commit and SVN builds on Desmume's Sourceforge page. At least that issue's finally over on their end.

[huckleberrypie]

Here's another one I tested out of random (yeah, I have a preference for children's games, but I'm not that much into Hobbie myself):

Game Title: Holly Hobbie and Friends
Device: Lenovo A369i (Mediatek MT6572/512MB RAM)
DraStic version: 2.2.1.2 demo
Report: Sprites suffer from flickering, even on default settings. Game runs on full speed though, well since it's a 2D title and doesn't seem to use any models.

[Exophase]

Looks timing related. Also looks like this game is really poorly programmed.

[huckleberrypie]

Looks timing related. Also looks like this game is really poorly programmed.

Hurr durr, it's yet another example of a rushed cash-in made to cater to them kids regardless of quality. It loads up properly on Desmume from what I've observed, though. Not surprised with the timing issues either.

[Exophase]

I take it back, it's not timing, it's because of the deferred 2D rendering in DraStic. The game changes VRAM mid-frame which is not handled properly. Golden Sun does it too, but it does it via HDMA which is detected, this just writes to a VRAM-based framebuffer. It looks like it writes to and flips the framebuffer completely independently of vsync (funny, kind of similar to what the American Girl games were doing). It might tear, even on a real DS.

I've been thinking about testing without deferred rendering anyway, to see what the performance difference is like.. it was originally designed that way because I thought it could help with threaded 3D but it actually made it worse in the end. But without deferred I don't know if it'd still make sense to render the two 2D screens on different threads, the synchronization overhead might cost too much...

[huckleberrypie]

I take it back, it's not timing, it's because of the deferred 2D rendering in DraStic. The game changes VRAM mid-frame which is not handled properly. Golden Sun does it too, but it does it via HDMA which is detected, this just writes to a VRAM-based framebuffer. It looks like it writes to and flips the framebuffer completely independently of vsync (funny, kind of similar to what the American Girl games were doing). It might tear, even on a real DS.

I've been thinking about testing without deferred rendering anyway, to see what the performance difference is like.. it was originally designed that way because I thought it could help with threaded 3D but it actually made it worse in the end. But without deferred I don't know if it'd still make sense to render the two 2D screens on different threads, the synchronization overhead might cost too much...

So, taking deferred rendering off would be at a significant performance cost, aye?

[Exophase]

So, taking deferred rendering off would be at a significant performance cost, aye?

Don't really know yet. Will try to find out.

[RyanVSGaming]

Game: DSCraft
Device: Amazon Kindle
Desc:
Wont Let Me Launch The Game

[Exophase]

Game: DSCraft
Device: Amazon Kindle
Desc:
Wont Let Me Launch The Game

It's homebrew that needs an SD card image setup first, with the proper files copied to it, and the .nds file needs to be patched for R4 cards. It's not so simple as just running the .nds file.

The whole process is kind of advanced and not documented anywhere for the Android version, but if you're up to it we might put up a thread explaining it or something..