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.
For what it's worth, desmume and fceux have a 2005 vcproj. But 2008 produces faster code, so we can't be bothered to make special builds in 2005 to indulge the wet dreams of children with nothing better to do than test software in old operating systems and then come bug the developers by saying GOTCHA!
Priority one is to get it working, and the second priority is to make it run fast. This is true for any programming cycle. This is quite a broad generalisation, there are definitely exceptions to this, but DesMuMe is not one of them. Don't complain about speed, beleive me, they already know.
Well, I exert considerable energy making it run fast also. But lag isn't running slow. Lag is bad emulation. An artifically laggy game is a buggily emulated game. So in the case of lag, it IS just trying to get it working. Desmume lags because of features which arent emulated yet except with abysmally timed hacks.
Also I should add that I have now personally witnessed mysterious desynchs in 0.9.4. I am looking into it but haven't figured it out yet.
It would be great to have some words from authors (zeromus ?) because it ruin movies making
Lag is of no concern to me. I am trying to make the emulation flawless. That means changing the timing sometimes. Sometimes it makes more lag, sometimes it makes less. You'll thank me later.
1) Play a movie that was recorded from no sram.
2) Stop the movie.
3) Reset (via emulator command).
Now the sram emulation is still disabled while it is supposed to be re-enabled since there is no movie being played/recorded. Re-opening a ROM will enable the sram again, though.
Now that's starting to sound like a plausible bug. Thanks for your testing.
Well, for my part, recording from SRAM doesn't work.
If I attempt to, nothing will happen. I select the .dsv file and check off 'Start from SRAM', but hitting 'OK' does nothing. It doesn't even register, just stays on the little 'Record Movie' window.
Because you didnt specify a dsm file to record to .........
Do you mean the whole battery system doesnt work, or record from sram doesn't work?
It doesn't seem to load. Whether it saves is untested.
EDIT: If it's possible, please keep the dev version timing, as it's much more precise, apparently.
You're going to have to describe your problems more exactly. What are you trying to do, what do you expect, and what is happening.
I found the dev version of 0.9.4 timing differently from non-dev versions. It's less laggy i.e. it's more acurrate, but SRAM doesn't work :(
EDIT: By "acurrate" I mean "presice" ;)
uhhhh i didnt expect any of that. I expected there to be no timing differences. I'll be looking into it.
Do you mean the whole battery system doesnt work, or record from sram doesn't work?
Forget 0.9.3 exists. It was leaked unfinished by asshats. Quit arguing. Its not good for tasers. We were delaying the release to fix these very sync issues.
0.9.4 is what you'll want to use
Also I am tickled by your attitude. Any asshat can make any build they want any time they want with any version number. It's open source, you know. If youre talking to actual desmume developers about a release that isnt on the actual desmume homepage, then it isn't a real release. No matter what the release says.
I downloaded it this morning, the file inside the zip say may 30 (timestamp), when running it in the about menu it say "compiled: May 30 2009 16:26:25"
I second you on that, who knows how many build was made... considering its not posted here its somewhat troublesome to identify a new release
Doesnt sound troublesome to me to have a seperate build number from mainbranch for this emulator like for most others, start by the start, 0.0.1 0.0.2 ect... :p
I uploaded this new build to fix a bug which was crashing mario kart, which was interfering with one of our good irc tasing testers. There is absolutely no desynch potential in this change.
I'm sorry for the confusion, I assumed the build date was good enough, but before I am a party to any more releases, I will make sure we've analyzed how to be more clear going forward.
I honestly don't understand how there can even be thread about DeSmuME development when there's absolutely no sourcecode or documentation about the .dsm format whatsoever. Nobody knows whether or not either of those sufficiently match the standards we have on this site or if they have major flaws. The emulator is win32 only, which already really pissed me off when PCSX was accepted. Does anybody still give a shit about the requirements that we once used to have? Where's Linux support, let alone being able to run it on Mac OSX? Where did you enable the public to make AVIs off emulator input for this? Was there any serious discussion about this emulator and its rerecording features prior to submitting NSMB?
For the record, shinydoofy has made no effort to acquire knowlege of the current state of affairs in desmume and nothing he has said about it should be assumed to be true. Maybe there are issues with it, and maybe it was rushed, but this post is simply not reliable.
Another small bug report, when using the "Load state from..." it checks the latest dir FCEU had used the explorer, most of the cases it is the ROMs dir, I think it should be set to states dir.
Fixed and uploaded interim build.
Phil wrote:
And I still cannot load a state from one movie to another movie. What are the reasons we aren,t allowed to do that?
I don't know, but since there has been such a clamour, I went ahead and changed it from an error to a warning which you may choose to proceed through.
The 2nd error message which imo is a bug:
"Warning: Found unknown save chunk of type 0. This could indicate the save state is corrupted or made with a different (incompatible) emulator version."
I have confirmed this as a bug in the code which recovers from a failed attempt to load a savestate. I have fixed this bug and an interim build has been uploaded to http://fceux.com/zip
Thanks for reporting this. I was able to reproduce it. It was caused by the replay dialog trying to do everything with paths relative to the emulator base directory, and then trying to open the file relative to the process current directory (which you had changed by opening a rom) which caused it not to be able to find the fm2 that you had just picked.
I think you can work around the problem for now by opening the rom from your recent file menu.
Alternatively, I have uploaded an interim build to http://fceux.com/zip which should fix the problem.. however, the build has a number of other untested changes in it. Hope it works for you!
Would it be possible somehow to make a patch that doesn't show the black images with white rectangles in them?
The game told me to display black images with white rectangles. It turned all the colors to black except for one which is white. Then it changed the sprite to a solid block shape. Now, what am I supposed to display?
in this 2.0.2, it DOESN'T tolerate special characters in FM2 file.
Phil, this is caused by you not having input UTF-8 into the fm2 file. You probably input in the form of the windows code page which can do Côté exactly in four bytes; versus UTF-8 which requires six. You can verify this in a hex editor.
The crash is caused by my not handling an error that I shouldve. That will be corrected shortly.
I can't offer you any advice on how to produce a UTF-8 text file other than to use save-as and change the filetype in notepad. I know nothing about internationalization in C and I have no idea how anyone handles any of this robustly.
Edit: I have posted an interim build which fixes phil and truncated's slow open followed by fcm bitching, as well as handles phil's crash from confusing fm2 metadata.
http://fceux.com/zip
Thanks very much for helping us track this down.
I just click "Replay Movie..." and it crashes.
Any ROM and it's not my cfg file since even the default cfg doesn't change anything.
Can you please zip all your movies in whatever directory is involved here and post them somewhere? Perhaps you have created a file which can crash the parser. The code is still new, so this is possible.
I didn't know about the version breakage, but lua is definately not officially distributed as "lua5.1". Check the official Makefile for 5.1.3.
We chose to use the policies instituted by luabinaries because the emulua system is supposed to be easily extensible by means of dropping in shared libraries compiled by third parties, and generally organized at luaforge.net, and they SHOULD be linked against the official luabinaries. For example, do you feel like compiling iuplua? If you do, then you would be able to play with some of the gui scripts that qfox is working on and that everyone is in the process of figuring out how to support better in the emulator. If you manage to figure out how, let me know. But you should probably use the binaries at luaforge.