Posts for DeHackEd


Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Ummm... oops? Redownload. Sorry.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
You can try mine. It has aspects of bisqwit's patch in it, as well as the "improved" version's code. If you're recording/playing back from the pre-1.43 snes9x release, specify -wip on the command-line. http://dehacked.2y.net/snes9x-improvement7-unixv2.tar.bz2
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I glued your SMV files together into a single SMV (again). http://dehacked.2y.net/tilus-chronotriggerJ-wip5-glued.zip I checked it and it doesn't desync.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I was planning on processing your last run (the one you submitted) into an AVI, but if you're coming along this well, I think I'll wait for the improved version to finish. Good luck.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
That's an error from the X11 library. I tested the OpenGL code and I give it a "works for me", though I have seen errors like that before when using SSH. I don't know what causes them though.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
If they were planning on allowing the player to get more than 127 lives, you'd think they'd use a field 3 digits wide to display the life counter while they were at it. Maybe it was easier to make it a signed variable and no one gave it a second thought.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Games are tested, but there are certain boundary conditions that are sometimes overlooked. From SMB2, I can't say for sure since I never tried it, but this is how it looks from my perspective. If you collide with an enemy being thrown (something rare since a thrown enemy is usually moving AWAY from you), it might fall into the floor. This is seen twice in the movie. Next, the enemy is picked up while it is under the floor. The result is that the player falls into the floor. Finally, the player climbs down the ladder (which is still working?) and since they go below the bottom boundary, the proceed to the linked area. Stuff like this is probably found by luck most of the time. I found two glitches (?) in Mega Man X entirely by accident in my attempt to get perfect timing and look cool. Yes, a glitch is defined as a flaw in the game's design. Some are inherently present (ie. bad collision detection in general) which can lead to exploits, like wall-jumping (SMB) or even passing straight through walls (practical uses for the High-Velocity Bum-Rush in Mario 64). Having the source code probably isn't too useful for finding such extreme conditions. Unless there's something blatantly wrong, they'd probably go unnoticed. (ie. when the player jumps, are they partially inside a wall? Is this the kind of thing you'd notice?) There's my little rant. All points on buggy game physics are based on attempts at rational thought after watching and/or performing these glitches myself and are not indicative of my owning source code to any of these games. Offer void where prohbitied. :)
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Here's what you bascially have to do. 1) Play the movie in NOT read-only mode. Otherwise, load-state just seeks to the save-state position and keeps playing the movie. 2) Make a save-state where you want to start recording from. You must make this save-state before the movie runs out. Save-stating before you stop recording from your last session is the easy way to do it. 3) If your movie runs out before you can do the next step, you may restart playback and proceed immediately to step 4. 4) Adjust your playback settings for rerecording. Pause the emulator, set speed to 15%, etc. Whatever you're needing. 5) While the movie is playing (position doesn't matter), load-state from the save-state made in step 2. It should say it's re-recording, and you're good to go.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I am honestly shocked that hexing like that worked. As for the movie itself, bravo!
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I'm afraid I can't not approve of this video. I do have one minor complaint though. In your 1p warps run, you killed your toad after the movie ended, but not in this one, even though it seems like killing yourself was a goal. Bad luck during the final battle?
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Okay, here's my unix version from v7. Most of the new options are available by command-line. Notable entries are -upanddown, -wip and -fakemute. Specify -keypress to have the frame display (and frame counter, which is only accurate during movie playback) sent to stderr. I also added frame advance. It's bound to backslash and the [ square bracket ] keys for those keyboards that suck. Keys can't be dynamically bound right now. http://dehacked.2y.net/snes9x-improvement7-unix.tar.bz2 There's a little bit of cruft left over from the patch, and maybe some stuff from my own compiling.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
They don't appear to be gzip'd at all. Rename them to end in .diff and you're golden.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Okay, I botched up applying the patch from v6 to v7. I did it again more carefully and it worked better this time. Sorry, that was my fault and not yours. But the v6 stuff still holds.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
What's broken with v6
$ cd snes9x-improvement6-src/snes9x
$ dos2unix configure Makefile.in `find -iname \*.cpp -o -iname \*.h`
$ sh configure
...
$ make -k
....
gfx.cpp: In function `void S9xDisplayPressedKeys()':
gfx.cpp:3468: error: `Joypad' undeclared (first use this function)
unix.cpp: In function `int main(int, char**)':
unix.cpp:646: error: `S9xProcessEvents' undeclared (first use this function)
unix.cpp: In function `void S9xSyncSpeed()':
unix.cpp:1301: error: `S9xProcessEvents' undeclared (first use this function)
unzip/explode.c:1072:19: crc32.c: No such file or directory
unix/x11.cpp: In function `void S9xProcessEvents(bool8)':
unix/x11.cpp:1742: error: invalid conversion from `wchar_t*' to `uint8'
movie.h:136: error: too few arguments to function `int S9xMovieCreate(const char*, uint8, uint8, uint8, const wchar_t*, int)'
unix/x11.cpp:1742: error: at this point in file
So it comes down to some header file errors, something funny with the unzip code, and changing the parameters of S9xMovieCreate. I had to do some ripping, but I got it. I'm not going to put per-frame data on the image (ie Frame counter); I'm sending it to stdout instead. That chunk of your patch I'm removing. And now the problems from v7's source:
snapshot.cpp:602: error: `FREEZE_ERR_WRONG_VERSION' undeclared (first use this function)
(And a whole lot like it.)
i386/cpuexec.o(.text+0x45e): In function `.noOAMreset':
: undefined reference to `S9xUpdateJoypads'
And I am NOT touching the assembly core.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Don't forget to give us the source code! (or even a diff against the last version) BTW, you broke the unix code, but it was pretty easy to fix, so I'll forgive you.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Every trick in my Mega Man X video I use (except the zero-damage hit) can be done on the real console. I pulled off one or two of the tricks in the famous "Crazy God Technique" SMB1 video (the mushroom midair jump, and I did succeed in the wall-jump... once out of a hundred tries). Really hard to do though.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
It was a little amusing, but nothing spectacular, and not really the purpose of this site. You didn't even reach any obvious goal. It just kinda stopped. Sorry.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Wow.... just wow...
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I finished it. I loved it. I voted yes.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
From your last run through, plus what I've seen so far, this is gonna be one sweet (if long) run.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
If it's necessary to win the game, then add it. If you can technically "win" but get a bad ending, then you could do that and say that this movie does not get the best ending. But I say include it. It makes the run more complete.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Yes, and make sure to use snes9x 1.43 FINAL.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I'm going to have to vote no. There's a lot of missed hits in level 2 which add up to some serious lost time. There's some hesitation in your actions, and so on and so forth.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I had seen that in your video, but was unable to reproduce it without waiting somewhere anyways. I did some checking. I'd have to stall anyways because I wouldn't be able to reach the platform at all, and the stalling wouldn't have been small. It'd be VERY noticable. I do save a little bit of time by not stalling waiting for the fire to go away and don't lose time from kicking against the wall. I didn't check if the net savings was worth the time wasted doing my hop, but my impression is that it's pretty close.
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
FODA: Okay, I didn't play the game through myself. Thanks for the info. About the bidirectional smacking: there were some enemies who took 4 hits from it to go down. Those are the ones who would benefit from my suggestions. You're probably right about the ones who only need two smackings.