Posts for zeromus

1 2
44 45 46
Posted: 6/8/2011 6:15 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Ive wondered that too. My best guess is this: notice that it is pretty much only novices who say that. They may be accustomed to their threads getting locked at the end because recently, as a novice, they have been asking a bunch of really dumb questions that make moderators want to shut them up by answering them and then immediately closing the thread. But eventually they learn otherwise. How do you like my theory?
Posted: 6/3/2011 5:12 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Maybe you should make more elaborate bug reports which someone stands a chance of being able to fix. pcsx-reloaded is useful as a reference and that is all. nobody is going to go through pcsx-reloaded and grab random pieces of code hoping that they fix a compatibility bug here or there because we dont know what the implications will be on other games. psxjin is supposed to be a _useful_ tasing platform (unlike pcsx-rr) and not a _perfect_ tasing platform.
Posted: 4/20/2011 6:12 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
thats easy to reproduce. very strange. doesnt seem to happen on any other games. something is odd about this one...
Posted: 4/18/2011 3:13 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
what's "reloading"? you mean loadstate? that would be quite a bug. is it actual lag, as experienced by you, or is the lag counter just triggering wrongly? i dont really care about the lag counter but real lag created by loadstates is a real bug. tell me what part of the game will demonstrate this the earliest.
Posted: 3/15/2011 4:34 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
drink a glass of red wine each day
Posted: 3/14/2011 10:27 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
Nobody needs to change the save size. It was taken out on purpose. If it remained for french, then it was an oversight. If you disagree with me, then use the dev+ version of desmume at your own risk to break your save files.
Posted: 3/7/2011 9:32 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
That feature, along with the Shoelace-Tier and the Pop-Up Hairstylist, has no business in an emulator, plugins or otherwise, and will never return to psxjin. Loading an archived iso is analogous to loading archived roms in other emulators and is not in principle objectionable, however it is hard to believe that anyone uses it given the substantial decompression time and RAM requirements, so I recommend against holding your breath while waiting for it.
Posted: 3/2/2011 8:03 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
arflech wrote:
I wish psxjin had the TAS ISO plugin that allowed you to make .bz archives from the ISOs and then load them, in order to save space.
Yeah, I'm sorry about that. We also deleted the integrated microwave oven and the Give Blowjob menu item.
Posted: 2/14/2011 5:29 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
They'll have to start diving in a cage, that's all. Remember, if one comes after you, hit him on the snout.
Posted: 2/3/2011 9:44 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
The same thing happens to me when falling asleep, and then also in the shower. If someone could jack into my brain right then and download what I've composed in my head then I would basically be the greatest musical genius in all of human history. Then I wonder if beethoven had the same problem and the stuff we ended up with are from him is just the stuff he crapped out during daylight hours in a vague effort to approximate what his dream muse brought to him, and he is disgruntled with how poorly it measures up. Then I could lend him my compositional download equipment and he could put me back in my place.
Posted: 1/27/2011 10:52 PM
(Edited: 1/27/2011 11:11 PM)
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
The most important thing missing from your list someone else suggested: achievements. Along the same lines, for platformers: And another, for platformers: yoshi coins (a collectable designed to encourage more exploration of a re-enterable stage) But it took the notion of achievements to really make them powerful. The very idea of bailing out from levels without penalty in platformers was important. I think checkpoint saving is a good one, but I've always thought that the most ruthlessly implemented 'quicksave' was a great idea also, where you can save anytime (bypassing the checkpoint system) but you MUST load it next time you boot the game, or else it is lost. This provides a compromise between the design niceness of checkpoint saves and the reality of a battery-powered console. Here is another one: animations in response to player performance in puzzle games which otherwise have no player control over unique characters, thus enabling a greater degree of characterization and engagement than would otherwise be possible. I'm not sure where any of these ideas come from. That will be interesting research. And one final proposition: WASD + mouselook, without which we would still be stuck in the dark ages of shooter controls.
Posted: 12/21/2010 7:18 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
arukAdo wrote:
As far as i can tell, the next version doesnt have cd support
It doesnt, and if it does, then it shouldnt, and if I find out about it, it won't.
Posted: 12/21/2010 5:55 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
I thought hatsworth gave you less loot at the end if you collected more loot during the level. Sort of a balancing tactic. That's what I remember from playing it a year ago.
Posted: 12/18/2010 7:57 AM
(Edited: 12/18/2010 9:55 AM)
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
LIFE'S A BEACH Y'ALL!!
Posted: 8/15/2010 7:42 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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: 8/4/2010 4:51 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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: 7/29/2010 1:32 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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/28/2010 10:25 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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 5:46 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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/27/2010 11:38 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
works for me. dunno what to say. I added a reset command at around frame 4300 (after stage 1) and when the menu came back it listed 2% completion
Posted: 7/27/2010 7:24 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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 5:18 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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 12:59 AM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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/26/2010 8:51 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
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 5:39 PM
Quote
zeromus
Editor, Emulator Coder, Experienced Forum User
Joined: 8/7/2008
Posts: 1156
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
1 2
44 45 46