Post by zeromus

Posted: 7/26/2010 8:51 PM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

I assumed you started your movie on the official 0.9.6 release. Otherwise, youre wasting your time trying a hacked 0.9.6 build. I cannot explain why it would desynch sooner with the hacked 0.9.6 build. I would have expected the latest svn to desynch sooner in more ways. I am really confused as to how you are getting this wacky issues when you havent even made it far enough in your movie (i assume) to do a reset. (I wouldnt expect your movie to synch after a reset, as that is where the problems that I saw began) Here is one common problem and its resolution: if a movie is recorded based on the existence of nonempty sram, then a game will boot up quicker since it doesnt have to initialize the save memory. Perhaps your movie supposes the game boots faster than it should because it somehow got started (from a reset?) with a nonempty sram. You can sometimes repair the movie by adding blank frames to the *edit: Also please redownload the http://dl.dropbox.com/u/4260750/temp/desmume_096_plus_r3723.zip and try it as I may have built it incorrectly with some compile options which (maybe) affect synch

Posted: 7/26/2010 11:54 PM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

I started my movie on the official 0.9.6 version. To clarify, the problem with using reset was only the faulty SRAM behavior (savestates don't update the completion percentage). I'm not sure if adding blank frames will help the matter and it would conflict with the problem klmz pointed out. I will try your new version tomorrow (and will update this post, I guess).

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 7/27/2010 12:59 AM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

there shouldnt be any synch difference between the hacked 0.9.6 build and official 0.9.6 except for consequences of the original problem. that means there shouldnt be synch differences for anyone else, but that is easy enough to test just by dropping in someone else's complete dsm

Posted: 7/27/2010 1:31 AM

Quote

theenglishman

Active player (348)

Joined: 3/21/2006
Posts: 940
Location: Toronto, Canada

The Mac version of DeSmuME does not appear to have any TAS tools - not even frame advance (just movie recording, and save/load state). Either I'm a total moron or something's a bit fishy here, and I think I know which option I prefer ;)

My current project: Something mysterious (oooooh!) My username is all lower-case letters. Please get it right :(

Posted: 7/27/2010 10:53 AM

Quote

klmz

Editor, Emulator Coder, Expert player (2158)

Joined: 5/22/2007
Posts: 1134
Location: Glitchvania

It's not impossible for us (reads: adelikat) to accept a "fixed" revision of 0.9.6 as the new mainstream here, if it could get around the reset issue with otherwise no difference in timing from the official 0.9.6 release.

<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

Posted: 7/27/2010 11:06 AM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

Zeromus: My movie syncs on your new version. However, the problem with SRAM doesn't seem to be fixed on it. When I use reset, the completion percentage is always 0%. Desmume doesn't seem to create a new .dsv file upon starting a new game...

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 7/27/2010 5:18 PM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

desmume isn't supposed to create a new .dsv file upon starting a new game. dsv was never supposed to be used or created while recording or replaying a movie. it should be getting beyond 0% though, i tested on super princess peach. maybe I'll test on your game. But you should upload your movie so i can see the exact same thing you are.

Posted: 7/27/2010 5:34 PM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

dsv was never supposed to be used or created while recording or replaying a movie

No, I thought it is supposed to when the save memory initializes or when the % raises. But it isn't created ever (which is related to the other problem I pointed out in my original post). http://dehacked.2y.net/microstorage.php/info/354021844/KSSU%20TAS.dsm 2696 - Kirby Super Star Ultra (U)(Xenophobia) Note that I didn't use the reset in this movie yet.

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 7/27/2010 7:24 PM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

Like i said, it isnt supposed to be used or created EVER when recording or replaying a movie. Otherwise it would get confused with the dsv that was already there which would make movie synchage impossible. I am unable to download that dsm. The webserver is flaky. But anyway, if you havent used reset yet, then it doesn't demonstrate the problem of the completion % being at 0% when you reset. So it isn't the useful test case I hoped for. Are you expecting to be able to play a movie, then stop the movie, and have access to the savefile resulting from playing the movie? Because that isn't going to happen. The savefile created by the movie is supposed to be in a virtual sandbox and it never appears on the disk (except as part of the savestates made while tasing). Although if you were to stop a movie and then save the game, it might write the dsv to the disk.

Posted: 7/27/2010 10:07 PM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

Here is an alternative download link. http://npshare.de/files/4e3aa2a9/KSSU%20TAS.dsm What I'm expecting after the reset is that the completion percentage is at the point where it should be. When I play through Spring Breeze, I want the completion percentage to be at 9%. I want to use a reset at this point in the movie and go on. But the after resetting, the completion percentage is still at 0%. (Again, this is another problem. The original problem: Switching between savestates doesn't change the completion percentage. The new problem: The completion percentage always stays at 0%.)

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 7/28/2010 10:52 AM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

Here is how things are right now: Your hacked build (0.9.6 + r3723) works accurately. The completion percentage is raised as I proceed through the game. When I load an old savestate, the percentage is lowered as I expect it to be. I continued on my movie and reset the game. Now when I play back my movie on Desmume 0.9.6 x86 NOSSE2, the game says "initializing save data" after the reset. The completion percentage is always 0%. I can try to redownload this version of desmume and see if that helps, but I'm busy with other things now.

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 7/28/2010 5:46 PM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

Of course. the public release of desmume 0.9.6 is broken in this respect. thats what I fixed in the hacked build! Now what you need to do is try some published dsms made on 0.9.6 in the hacked 0.9.6 build to see if they still synch, so that folks can decide whether or not to bless it as official.

Posted: 7/28/2010 8:45 PM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

Of course. the public release of desmume 0.9.6 is broken in this respect. thats what I fixed in the hacked build!

But this should not be the case. The problem I stumbled upon with 0.9.6 first was that the completion percentage doesn't get updated when switching between savestates. The completion percentage actually raised throughout the run. NOW it is always 0%. Since the dsv isn't created, it says initialzing savedata. I tried redownloading now and I got the same problem. Then I copied the ROM into the new emulator folder and it created a dsv this time, for some reason. After the reset, it didn't say initializing savedata. However, it was still at 0%. Please differentiate between two problems here.

The original problem: Switching between savestates doesn't change the completion percentage. The new problem: The completion percentage always stays at 0%.)

I'm pretty sure that the official 0.9.6 build behaved correctly except for the fact that it didn't update the %. The reason why it is now always 0% is unknown to me and it confuses me greatly. Here is what can be done: -Maybe try to fix the 0% error, but I don't have any clue how. -Replay published runs on the hacked build to prove that timing is correct, then continue my movie on the hacked build (if that's okay with klmz, adelikat and others). -Wait for desmume 0.9.7 and redo the movie (which would be unfortunate).

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 7/28/2010 10:25 PM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

Yes, it should be the case. There should be no dsv created while recording or replaying a movie and any pre-existing dsv should be ignored. When you reset during a movie, youre still recording or replaying, and there will be no dsv still, and you will observe that isn't at 0%. If you stop the movie first, and then reset, then anything may happen, but I am not very much concerned about that. There is no bug right now during TASing in the hacked build, and to prove otherwise will require a dsm with a reset in it that exhibits an error in the completion %.

Posted: 7/28/2010 10:47 PM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

zeromus wrote:

Yes, it should be the case. There should be no dsv created while recording or replaying a movie and any pre-existing dsv should be ignored. When you reset during a movie, youre still recording or replaying, and there will be no dsv still, and you will observe that isn't at 0%. If you stop the movie first, and then reset, then anything may happen, but I am not very much concerned about that. There is no bug right now during TASing in the hacked build, and to prove otherwise will require a dsm with a reset in it that exhibits an error in the completion %.

The problems I pointed out in my original post and in the last few posts refer to the emulator's behavior when in movie-recording mode. Yes, I was recording a movie so this should not be the case. So we're having a "Yes, it is" "No it isn't" argument here... We can go on like that, but that would be pointless, wouldn't it? I'm pretty sure that when the first time I wanted to include a reset, I was in recording mode. However, as this is increasingly confusing to me, chances are that you are correct. I stumbled into the 0% problem when I wanted to bypass the first problem by advancing a frame and a time and seeing if a reset results in a greater %. I will try running a dsm that uses a reset (if there is one) and I will then talk to adelikat and klmz about whether it is okay to use the hacked build.

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 7/29/2010 1:32 AM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

We don't have to argue when the point can be proven either way with a dsm. You could make your own dsm with a reset. I thought that was the point of this whole situation, anyway. The old castlevania DS tas -- dawn of sorrow maybe--? may use reset, as I recall, but the bug in question did not (I think) exist in 0.9.4 which is what it was recorded on.

Posted: 7/29/2010 2:23 PM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

Hmm... Obviously, there shouldn't be a dsm which was made with 0.9.6., using a reset. It shouldn't be possible due to the very problem we're discussing here. I talked to adelikat and he seems to approve your modified build for now, since the timing is the same as the official version and it only fixes the SRAM problem. I'm going to need to acquire both the binary and the source version of your modified build. Apparently, adelikat is also going to contact gocha about a potential 0.9.6+ version (which this modified build would derive into along with some more fixes). Thank you very much for taking your time discussing my problems with desmume. I appreciate it.

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 8/4/2010 8:48 AM

Quote

MUGG

Editor, Expert player (2330)

Joined: 5/15/2007
Posts: 3933
Location: Germany

Okay, I stumbled right into another critical emulation glitch it seems... Desmume 0.9.6+r3723 decided to reset the game during movie playback without me actually using a reset. http://dehacked.2y.net/microstorage.php/info/1477488714/KSSU%20TAS%20-%20BU2.dsm 2696 - Kirby Super Star Ultra (U)(Xenophobia) The movie always resets at frame 16592. I tried to repair it (redo the section where it resets, then playing back the movie), but it still resets at the same frame again. If I load a savestate before frame 16592 in read-only after the reset occured, it immediately resets after loading the state. If I redo the section with the reset and load a savestate before frame 16592 in read-only mode, the glitch still occurs as well (and this time seemingly at another frame than 16592).

Youtube • Livestream • Progress 11th TASer of the Decade 2010-2019 !

Posted: 8/4/2010 4:51 PM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

I see a reset in the dsm on frame 16592. Just erase that and try and patch it up from there. I have no explanation right now for those other bugs and I don't have time to debug it anytime soon. As you might can tell, this is a nest of evil in desmume, and fixing one thing is likely to break another. It's best not touched more than the absolute minimum until someone is ready to renovate it. As long as replay of resets works correctly then we're minimally covered. I just did a couple of quick tests involving recording of resets and re-recording of not-resets and couldnt find any bugs. But I'm no taser and most of what you guys do confuses me so I'm not sure that it proves anything.

Posted: 8/10/2010 5:49 AM
(Edited: 12/24/2012 10:06 AM)

Post subject: DeSmuME 0.9.6 r3896

Quote

gocha

Any

Emulator Coder, Former player

Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya

I made a build of 0.9.6 r3896. It's not PGOed since I'm lazy. http://gocha.is.land.to/down/desmume/desmume_0.9.6_r3896.zip Changes (after the public release)

RAM Search: Fix counting of number of changes.
merge r3739 --start-paused fixes to release branch
Ram Watch: Add Separator button
port dsv movie fix from trunk
RAM Search: fix reset to update previous values
RAM Search: redraw the list when search size/format is changed.
add "background input" option
allow multiple selection at Cheat List and RAM Watch
RAM Search: allow adding two or more watches/cheats at the same time
RAM Search: fix the restoration of the selection range on data size changed.
Add workaround for line poly (improve Castlevania Portrait of Ruin: trajectory of ricochet, dart, and glow of warp stone, etc.)

I am usually available on Discord server or Twitter.

Posted: 8/15/2010 6:22 PM

Quote

Toothache

Active player (279)

Joined: 4/30/2009
Posts: 791

I would like to request a fix to the 2038 problem that Desmume currently experiences. In Pokemon DS games, a Pokemon's initial seed (and therefore its random stats) can be influenced by the starting date the DS is set to. RNG manipulating Pokemon to have the best stats has been known about for some time, and this knowledge can even be applied to a TAS. I did not test this myself, but a valid date for the best IVs for a starting pokemon was found to be in the year 2088, but unfortunately setting Desmume to this date (or almost any date it seems after 2038) causes it to crash. Without the ability to choose all possible dates safely (a DS has a date range between years 2000 and 2099) a Pokemon DS TAS will be severely hampered, and will in fact be sub-optimal since better stats were available in the game but prohibited by the emulator. Thanks in advance.

Posted: 8/15/2010 7:42 PM

Quote

zeromus

Editor, Emulator Coder

Joined: 8/7/2008
Posts: 1156

I'm not sure if the 64bit time_t replacements are available on every 32bit compiler. This could hamper portability. I suppose we could try it and see. Or we could look at someone else's time library. I am trying to amass excuses to checkin boost but i always hesitate to checkin 239847129849231 files. There are probably other replacement candidates but I don't know them.

Posted: 2/2/2011 12:46 PM

Post subject: DeSmuME 0.9.7 released

Quote

gocha

Any

Emulator Coder, Former player

Joined: 6/21/2006
Posts: 401
Location: Japan, Nagoya

DeSmuME 0.9.7 released http://sourceforge.net/projects/desmume/

ChangeLog wrote:

0.9.6 -> 0.9.7 (r3493-r3654-r3812) General/Core: bug: fix a ton of old, broken cpu opcodes and CP15 logic bug: return Z1 and Z2 from TSC (fixes some touch logic) bug: gba slot save type detection improved bug: handle unusual rom headers more correctly bug: dont confuse motion pack commands with save memory commands bug: make cheat system a little less flaky and add AR 1.54 support bug: fix nondeterministic backup memory behaviour while rerecording bug: correct emulation of register accesses of wrong size and during powerdown bug: rewrite --cflash-path emulation bug: rewrite IPC/GX FIFO, IRQ flag generation, and wait-for-IRQ logics bug: rewrite RTC calendar handling; now supports years > 2038 enh: auto-DLDI patching for homebrew enh: --gbaslot-rom=self mounts self.nds in slot2 enh: more realistic exception handling enh: piano controller emulation enh: modular slot-1 system for exact emulation of homebrew cards Graphics: bug: edge marking colors were wrong bug: handle some "invalid" vram configurations correctly bug: convert half of geometry engine to fixed point bug: fix sprite blend+fadein/fadeout bug: improve rasterizer shadows bug: fix main memory display DMA bug: fix some raster fx timing bugs enh: add a hack for improving some non-stencil shadows Windows: bug: misc fixes and improvements to gpu viewer tools bug: sub screen layer display toggling fixed bug: fixes and improvements to ram watch, ram search, cheats list bug: fix start-paused commandline bug: fix memory leaks when sound disabled bug: improve load average calculators and add arm7 load average enh: background input support enh: add vsync option enh: support more knobs on joysticks enh: import cheats from R4 database enh: add xinput rumble for 360 pads Linux/OSX: bug: crash less in recent roms list enh: Add horizontal screen layout and swap screen ability to gtk frontend (noodlebox) enh: Big improvement to joystick support, support complex configurations and multiple devices (noodlebox)

I am usually available on Discord server or Twitter.

Posted: 2/2/2011 4:49 PM

Quote