Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
Xkeeper wrote:
Disassembling, not decompiling. Large difference.
Knowing RAM values might be of some help, I guess. It'll lead to figuring out what things do faster, if nothing else.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
The movement algorithm in Super Mario Kart (for the SNES) is more weird and counter-intuitive than I had initially thought, and there are many unanswered questions which make doing a good TAS of it very tough or impossible.
I think a good understanding my only be possible by decompiling the game. I noticed here that some people had decompiled other games, and wondered if anyone had any advice on how to do it.
I already have the addresses of many of the variables in RAM, could that help?
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
AzHP wrote:
flagitious wrote:
I think so, but working with a very long movie (1.7MB), the save states while recording are typically around 150KB. So I'm not really sure any more... maybe it uses compression?
Savestates are just dumps of the RAM, they should be the same size for each game no matter what the size of the movie.
I think they're zipped too, which may change their size a bit.
oh man, more techniques/glitches I didn't know about -- I'm going to have to change my planned routes again :)
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
AzHP wrote:
Make your bot change input every other frame? I dunno how much that would affect the accuracy, but you could try it.
I'm having to do something like that - basically if it hits something, I reload two saves back rather than one (to ensure its at least two frames away from hitting a pipe). This doesn't hurt the accuracy of my bot, but does make it take longer to work out the run.
Incidentally, Mario Kart only checks for left/right input every other frame, but it seems to check for 'hop' input every frame (and if you press hop on frame 0 you can next hop on exactly frame 18).
Currently, changing input every 4 frames, the bot takes overnight to do 5 laps of Mario Circuit 1 on time trial. As soon as I work out how to get my bot to record to smv files I'll post one here :)
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
Well my bot's going pretty well, but I've hit an interesting problem:
Immediately after reloading, it appears to go straight through a pipe... but then when I play back the actions my bot did, it hits the pipe.
Now at first I just thought I hadn't properly saved the actions my bot did, but now I think its because for one frame after a reload, the pipes aren't in the right place.
Here are some screenshots I took as evidence:
In the below frame, the bot is about to go off the course... so it reloads:
Then after it reloads, the pipes are in the wrong place!
One frame later, they jump to where they should be:
Since the bot appears to be desyncing by going through a pipe immediately after it reloads, I think this is more than just a visual glitch.
I've made a temporary hack to get around this, but it's not a proper fix and could become a problem later. Really the state should be reloaded exactly as it was when it saves.
Anyone have any idea what could be causing this?
The DSP1 chip?
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
looks like I don't have the right version of snes9x (no wonder it seemed saving states made it go funny).
Is the source code to 'improvement 9' avaliable anywhere?
Also... I don't understand the snes9x version naming scheme at all
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
nitsuja wrote:
Huffers wrote:
but I find it desynchs (what a suprise)... I think this may be being caused by the code in snes9x that saves or loads savestates advances the game state a few frames each time it's called... but that seems very strange.
I'm quite sure that is not the problem (somebody would have noticed such a huge bug by now when trying to perform frame-precise maneuvers). It's probably either a bug in your code, or a problem with the version of Snes9x you based your code on. If you didn't use anything from this version then it is likely to desync because previous versions did not save the state of the DSP1 chip in the savestates, and Mario Kart is among the very few games that use that chip.
Heh, by 'strange' I meant 'unlikely' :)
I think I've found what in my code was (at least partly) causing my desynchs -- haven't got round to fixing it yet though.
I'm using DeHackEd's version of snes9x, which I've modified a bit myself. Thanks for letting me know about the DSP1 state thing - that could really screw my run up since my bot saves and loads almost every frame. I'll have to check DeHackEd's version saved it, and if not I'll try doing some diffs and apply them :-S
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
DK64_MASTER wrote:
Huffers wrote:
But I've ran into a problem at the moment; the bot saves a list of 'actions' its tried to a file so I can play it back later (and make a snes9x movie file), but I find it desynchs (what a suprise)... I think this may be being caused by the code in snes9x that saves or loads savestates advances the game state a few frames each time it's called... but that seems very strange.
Does it desynch immediately, or is it successful until a point?
If nothing goes right, there might be a bug in your progam (like the duration between button presses is incorrect). If it works sometimes, then it's probably SNES9x's fault, or a hard to find bug in your program :(.
Actually, it might be beneficial to play time trials with your bot. It would be a better indication if it works or not, as it is less random, and might be faster for your bot to provide the fastest route.
Just some suggestions...
yeah, it's probably a problem with my code, but it does seem like snes9x's load/save functions cause a few frames to be skipped.
I'm going to test it out on the time trial maps, but I'd like to do the GP mode when I get it working properly -- because I think that's way more interesting, and probably not that much harder once the bot kinda works.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
Right, I've tested my (very early and crappy) bot out on two corners and a straight connecting them on Mario Circuit 1 on time trial mode... it took about 2 minutes to work out solutions to them, with the input buttons being changed every 10 frames (3 times a second) -- but I know I can get the bot much faster than this, and when I do I'll be able to run it changing the input every frame.
Here's an update on how it works:
It does a depth first search of the possibilities.
In order to not have to search all the possibilities, it searches the most direct ones first -- and uses the first solution it finds that doesn't crash into something or do something else blatantly stupid.
By 'most direct ones first' I mean I first mark all the areas as being left corners or right corners, then (if its in a left corner zone):
it first tries turning left.
its second choice is to hop left
its third choice is to go straight.
Its actually a bit more complicated than this, because I think there's sometimes an advantage in hopping/turning the other way at the end of a corner to straighten out (and there are a few tricks I've thought of too, so the bot won't have to look at so many possibilities), but thats the basic idea.
If it hits another Kart or obstacle or doesn't get the power up it wants it just backtracks and tries the next most direct route.
To manipulate luck to get the power up of choice I may try making it first try pressing on and off the 'use' button while it doesn't have anything to use (I'm not sure if pressing brake in midair does anything or not...) - that way it'll hopefully change the power up it gets without having to comprimise its route.
But I've ran into a problem at the moment; the bot saves a list of 'actions' its tried to a file so I can play it back later (and make a snes9x movie file), but I find it desynchs (what a suprise)... I think this may be being caused by the code in snes9x that saves or loads savestates advances the game state a few frames each time it's called... but that seems very strange.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
DK64_MASTER wrote:
Huffers wrote:
just an update, I've wired up a stub of the bot to snes9x.
The stub successfully creates input, reads Mario Kart's variables, and saves/loads game states to/from arrays.
Now I'm ready to start working out the quadralaterals and the 'meat' of the bot.
Just working out the shortest path for each level won't do much especially if there is CPU interaction.
It would work for time-trials, though :). You could eliminate most of the computations by "hardcoding" the track width, length coordinates. Instead of taking a million years, it would only take about 100 ;).
Or are you just going to be using the bot for short segments? Like bisqbot?
Actually, I'm quite interested to see some of the pseudocode you have. I probably won't understand any of it, but I'm mainly interested in how you managed to interact with SNES9x remotely? Did you call some DLLs? Viewing fmod.dll just gave me a bunch of sound/music functions...
I'm going to use the bot for the whole of the track, from just after accelerate is pressed to get a turbo-start, until it hits the finish line.
I got around the problem of calling snes9x remotely by... not calling it remotely! I've hacked in code to call my bot in the bit where snes9x checks for keyboard input.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
just an update, I've wired up a stub of the bot to snes9x.
The stub successfully creates input, reads Mario Kart's variables, and saves/loads game states to/from arrays.
Now I'm ready to start working out the quadralaterals and the 'meat' of the bot.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
DarkKobold wrote:
What does 8th overall mean?
Coming in last place overall in the tournament.
This is actually quite tricky, as you get disqualified if you come less than 4th on any of the races.
EDIT:
I've made a RAM map for Super Mario Kart :D
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
I noticed that for several runs, eg. Megaman 1 and Excite Bike, the memory locations where game variables are stored were found.
Does anyone have any advice on how to find these locations?
I intend to write a bot to try out cornering possibilities for Super Mario Kart, and the bot needs to be able to tell what its position/speed/etc is, so it can automatically select the best possibilities.
I'm not bothered about how to 'watch' these locations in the emulator (I intend to fiddle with the snes9x source anyway to allow the bot to call it, so I could just insert printf statements if necessary), I'd just like to know how people go about finding them in the first place.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
Well I've posted this problem on the snes9x bugs forum here, but in the meantime, could you upload the binary somewhere?
Might that work for me?
EDIT: just tried compiling it with the DGA and Vidmode extensions enabled, still the same problem though
EDIT: fixed it! I was using gcc 3.4.6... when I switched to gcc 3.3.6 it worked :)
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
Well it compiles and runs but mode 7 looks bizarre
http://www.geocities.com/huffers2002/Screenshot-1.png
the rom isn't corrupt - it works fine with the binary pre-compiled version of snes9x 1.43, but this problem isn't specific to the DeHackEd version of snes9x.
I tried compiling snes9x 1.43 myself and that has this problem too, so I'll ask about it on the snes9x forum.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
DeHackEd wrote:
Edit the makefile. Find "-DUSE_DGA_EXTENSION" and delete it. Rerun make.
You could also install the DGA development libraries, but I don't see that as being worth the effort.
Now I've done that make gives me this error:
/home/ajh02/snes9x-improvement7-src-unix-dehacked-June20_2k6/snes9x/unix/x11.cpp: In function ‘void S9xProcessEvents(bool8)’:
/home/ajh02/snes9x-improvement7-src-unix-dehacked-June20_2k6/snes9x/unix/x11.cpp:1617: error: ‘FromPause’ was not declared in this scope
does TASvideos have an irc channel by the way?
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
I haven't had much success:
In the binary version of snes9x 1.43 on linux, comma, period, apostraphe, tilde and backslash all seem to do nothing, even when the game is paused by pressing 'pause'.
And 'make' fails when trying to compile DeHackEd's version (./configure seems to work though). The first error make gives is:
X11/extensions/xf86dga.h: No such file or directory
I'm using gcc 4.0.3.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
there seems to be no complete list of controls anywhere for the linux version of snes9x.
As far as I can tell:
fX = save
shift fX = load
shift - = slow down
shit + = speed up
shift 1 = record movie
shift 2 = play movie
shift 3 = movie stop
If there isn't a frame advance for it I'll hack the source myself (if I can get it to compile), but really I don't see why it should work on Windows but not Linux (whats OS specific about frame advance?).
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
I've improved the routes, new versions here. Any comments/criticism will be appreciated.
I've got some higher quality map png files ripped from the game now, but I'm still using the old crap ones for the moment
Note that many of these routes are crazy - but I want this run to be as glitched-out and manic as possible. A glitch free run can come later
The RAM I'll use is here. This is a empty/new ram on which I just completed the 100cc tracks myself.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
AngerFist wrote:
Huffers wrote:
I'm pretty sure a lot of the most impressive shortcut jumps are only possible on 150cc mode, so I won't bother making this TAS unless I can do it in 150cc mode (which will mean getting an exception made for this run to start from a RAM).
Do it in 150cc mode(we've said we want a 150cc mode TAS for a long time now), exception granted, now go!
smashing :)
A Runnelid wrote:
I don't want to sound harsh, but if these are the routes you were planning to use, there is a chance people will be able to beat your times using a console.
Thanks for the advice :)
Not harsh at all, the reason I put the routes up wasn't so much because I thought they were great, but because I thought I needed a starting point to get some suggestions/criticism as I had no idea,
I'll take a look at that site and your other forum post then update my planned routes.
Experienced Forum User, Published Author, Former player
Joined: 3/23/2006
Posts: 211
Getting closer to when I may actually have some time to work on this.
The old routes I posted were crap, these should be better
I'm pretty sure a lot of the most impressive shortcut jumps are only possible on 150cc mode, so I won't bother making this TAS unless I can do it in 150cc mode (which will mean getting an exception made for this run to start from a RAM).
Then after it reloads, the pipes are in the wrong place!
One frame later, they jump to where they should be:
Since the bot appears to be desyncing by going through a pipe immediately after it reloads, I think this is more than just a visual glitch.
I've made a temporary hack to get around this, but it's not a proper fix and could become a problem later. Really the state should be reloaded exactly as it was when it saves.
Anyone have any idea what could be causing this?
The DSP1 chip?
