Calm down people, I'm not throwing stones at Desmume...
I test with other games, and works very well and even better that neon/no$gba.
Just wonder why 'some games' gets these not optimal emulation...
Desmume is the emulation with more features than any other, just pointing a 'effect'...
3D games with 3D graphics works, polygons/meshs works amazing, no slowdown.
2D games with 2D graphics works, sprite engine perfect, no slowdown.
2D games using 3D graphics, like castlevanias, the fps slowdown too much.
Is just a case to be study, and see if is really need some improvements...
Sorry for my english, and really sorry if people thinks that I hate Desmume...
Actually, some games that do run at 60-62 fps don't run smoothly, as if they rushed out 60-62 frames within half a second and then halted until the fps were calculated.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Actually, some games that do run at 60-62 fps don't run smoothly, as if they rushed out 60-62 frames within half a second and then halted until the fps were calculated.
Auto frameskip was dumb enough to do exactly what you are saying in 0.9.4, but that has been fixed in 0.9.5. (Well, let me know if you find a circumstance where it still happens in 0.9.5.) Also, keep in mind that some games don't really run at 60 fps, especially if there are 3d graphics on both screens.
HarryPitfall wrote:
3D games with 3D graphics works, polygons/meshs works amazing, no slowdown.
2D games with 2D graphics works, sprite engine perfect, no slowdown.
2D games using 3D graphics, like castlevanias, the fps slowdown too much.
That's not quite how things are. For example, try Yoshi's Touch & Go. It's 2D with 2D, but it emulates very slowly. There are probably some slow fully-3D games as well.
Basically, CPU-heavy and 3D-heavy games are likely to emulate slowly right now in desmume. Yoshi's Touch & Go emulates so slowly because it uses 100% of the DS's CPU (probably unnecessarily). Order of Ecclesia emulates so slowly because it is extremely 3D-heavy (polygons covering every pixel, and many layers of polygons).
It might be the case that scenes with 3D rendering are likely to draw more layers of polygons per pixel if they have a fixed or 2D viewpoint, which would explain (part of) why things like Order of Ecclesia and NSMB (map screen only) are so slow in desmume.
Anyway, this is not necessarily something worth focusing on. Certain games are heavier than other games, and this will always be true. Currently some games are heavy enough to cross some arbitrary threshold that depends on how fast your computer is. But maybe some general optimizations would be sufficient to push all of these games into "fast enough" territory.
There are various things you can try to make too-slow games run faster, but they will only go so far at the moment.
I'm having visual issues with "Point Blank" DS regardless of region. I'm not aware if there are other issues but there is a bug with one of the mini games, not rendering the target.
Does the issue occur in all versions of desmume or is it just in the latest version (0.9.5). If so, is the issue in the official 0.9.5 or the improvement version 0.9.5 r3179 or both?
Thats something im not sure of, just realized I didn't try different emus. (Although my current recording would get killed if I went from rev3179 , from previous experiences of this emulator and it's timings)
edit:
0.9.2-rrv1 (win32 executable) no targets
0.9.2+ (r2693) no targets
0.9.4+ (r2964) no targets
0.9.5 (r3179) no targets
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
http://desmume.org
Desmume 0.9.6 finally released!
This is a big release for the TAS community. 0.9.6 offers a big increase in lag reduction and more accurate emulation. As demonstrated in this submission, 0.9.6 is finally the matured emulator we've been wanting. In addition it has lots of fixes related to save/loadstating & movie making.
I stumbled into some problems when TASing Kirby Super Star Ultra.
I'd like to use resets in my movie, but the savegame seems to act weird. Basicly, once the completion percentage in the game updates, it keeps the new completion percentage regardless of subsequent loading of an old savestate (with the old completion percentage).
I'm playing back my movie to a point where a reset would result in a completion percentage of 6%. I'm making a savestate here. Now I'm playing back to the point where a reset would result in 9%. I'm loading my savestate and a reset results in 9% now!
SRAM apparently isn't included in savestates, so all the savegame-related stuff is up to what happens to the .dsv. The .dsv doesn't update its savegame when I'm loading any savestate.
After I realised this problem, I stumbled right into another one: I deleted my .dsv, and now it isn't created anymore after restarting desmume, loading the rom and playing back the movie. Because of this, resets now result in "corrupted" and "initialising savegame" messages.
These errors prevent me from TASing the game. In order to solve the problem with savegames, SRAM should be included in savestates.
desmume does store sram in the savestate. unfortuntely, some other logic related to movies and save memory was pretty much completely broken. your reproduction steps were helpful for debugging this. thanks for your research and patience. just now in r3723 i checked in some code to address these problems. let me know how it goes as you test it. i'll debug it with you until it works right.
Hello zeromus.
Thank you for helping. I would like to try out revision 3723. However, I can't find a download link to that build and I'm not familiar with SVN and related programs that are required. I was said to install Tortoise and 2010 Visual C++ Express, but the latter is too big and enforces more downloads and installs. It's too much of a hassle for me to have to download all these files, learn about how to use them and more only in order to view a small revision. Perhaps someone is willing to compile it and upload it for me? I'm afraid I can't afford checking out your work, though I would like to see if it fixed anything.
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
I tried it now and the problem seems to be fixed. I can't spot any inaccuracies with the completion percentage when resetting the game. I have yet to see if I can continue my speedrun on this version of desmume, but I'll worry about it tomorrow. Thank you!
I tried it now and the problem seems to be fixed. I can't spot any inaccuracies with the completion percentage when resetting the game. I have yet to see if I can continue my speedrun on this version of desmume, but I'll worry about it tomorrow. Thank you!
Please be warned that we might reject movies that refuse to sync with any mainstream revision of the emulator.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
I just came around to testing if my movie file from the original version syncs with r3723. It does not sync!
Is there no way to fix the problem with SRAM without affecting timing?
i think the changes could be safely ported into the 0.9.6 release branch.
i am somewhat confused as to how anything ever synched at all with the sram being broken as it was. but if that isnt the issue, then it should synch on 0.9.6. i think it is possible that the bug would never manifest unless recording resets, so that would explain why nobody noticed it. additionally, recording resets was totally broken in other ways and I am confused how you were able to effectively do it at all. but that was fixed in r3723 also
http://dl.dropbox.com/u/4260750/temp/desmume_096_plus_r3723.zip
try that
It doesn't work on your version (0.9.6 + r3723) either.
It desyncs at the menu of the game right away.
The build I tried before at least got to frame ~2500 before it desynced.
