Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I don't know anything about networking in windows, but it seems to me that the reason you are having problems is that your laptop uses your server as the default gateway when you plug in the cable. It probably does this because the server is running a dhcp server, which responds to the laptop's dhcp queries. Disabling the server's dhcp server, or changing its configuration, might help this.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Oh, I see nobody has posted an update here. We have been testing things a bit with one of the developers on IRC, and found that the emulator is non-deterministic, whether in the fast JIT mode or the very slow plain mode, and regardless of lots of options.
One possible reason for this was tracked down: The emulator initializes the gamecube's time with the computer system time, which makes it unsurprising that every playback of a movie desyncs in a different way.
However, we believe that this easily fixed problem isn't the bottom of it, and it needs a lot of debugging, which we hope that the developers will have time for. The one we spoke to, XK, seemed a bit ambivalent.
But at least we have the recording and playback now, which makes it possible to diagnose the non-determinism in the first place, and which should make it possible to solve eventually, whether they do it, or we.
They also plan on implementing Lua scripting too, so once it is deterministic, I think this will turn into an excellent emulator for TASing.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here is a pretty new one, at least:
http://snes9x-rr.googlecode.com/files/snes9x-1.43-rerecording-svn-r64.zip
If you use this one, then don't include the function I wrote for you above. If you can't get that one to work, then I can help you more effectively on IRC. Just join the #tasvideos channel on irc.freenode.net.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Readbyterange is one of the newer functions in snes9x lua. It is not supported by your version. It should be in the svn version though. I could implement a replacement for readbyterange, but then I'd probably also have to add safeguards agains drawing outside the screen, etc., since that isn't supported in old versions either.
If you wish to test if readbyterange is the only issue with your old version, you could try adding this to the top of the file (not tested):
function memory.readbyterange(a,b)
local res = {}
for i = 0, b-1 do table.insert(res, memory.readbyte(a+i)) end
return res
end
It is nice to see someone trying the script itself, and not just the video, so I hope you'll get it work, even though you may have to upgrade snes9x.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Several people are having trouble downloading the video, it seems. Derakon's problem is probably an incomplete download, so he should try resuming the download. For those who can't get it to complete properly, I have uploaded it to youtube:
http://www.youtube.com/watch?v=QdFUMRFpn74http://www.youtube.com/watch?v=Xynlq_TNQMwhttp://www.youtube.com/watch?v=ZFyQCYhNEkg
However, youtube greatly reduced the quality, making it very hard to see the colored samuses, which removes most of the point, so I recommend the original (or even better, seeing it in the emulator).
Edit: Actually, the quality seems to have mysteriously improved. Does youtube perform some sort of second pass?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Thanks! Feel free to try the script yourself, too. It requires a bit more setup than other scripts, mostly because of the gd image library dependency, but it isn't hard. You just need a new version of snes9x-rr.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Here is a comparison video between Cpadolf and herooftheday's new and old any% non-glitched runs.
http://folk.uio.no/sigurdkn/sm_ghost.mkv
Only in-game frames are shown in this video, cutting away most of the boring stuff. In-game frames are also used for synchronization of the sprites from the different runs. To make it easy to compare room strategies, they are all resynced so that they enter each room at the same time, while they minimap shows where each run really is. The colors are:
Normal: Cpadolf 2
Blue: Cpadolf 1
Green: Herooftheday 2
Red: Herooftheday 1
The numbers at the top of the screen show how many frames behind Cpadolf 2 each of the others are, for each room. (Cpadolf 2 comes out ahead here, because the video uses in-game timing. With real time timing, Herooftheday 2 would win).
The details can be found here:
http://tasvideos.org/forum/viewtopic.php?t=6539&start=168
Edit: Blue and Green were mixed up here. Fixed now in the text. The video is not changed.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Edit: Scroll down to the bottom of this post for the newest version.
Here is an improved version of my old super metroid ghost script:
http://folk.uio.no/sigurdkn/ghost_play.luahttp://folk.uio.no/sigurdkn/ghost_record.lua
Aside from being more robust now, it also supports two new features: The ghosts can be displayed using a proper animated Samus (or anything else, really), and there is a minimap which shows the position of each of the ghosts globally. These features require the gd library for lua, though, so you will have to install that to get this to work. Here is a demonstration of the script:
http://folk.uio.no/sigurdkn/sm_ghost.mkv
This shows Cpadolf's in-game any% non-glitched SM TAS (normal Samus, white cross on minimap), his previous version (blue Samus and cross), and herooftheday's new and old realtime oriented any% runs (green and red respectively).
The settings used to produce this was:
As you can see, it is possible to choose which frames to display, and which to sync by. Here I have chosen the most interesting combination in my opinion, which is to sync by ingame frame, and to display only those frames. Additionally, I have chosen "room" offset mode, which resyncs all the ghosts to enter the room at the same time, which makes it easy to compare room strategies.
Please excuse the poor encoding quality in the demonstration video. Especially the crosses on the minimap are much clearer in reality than in the encode.
A few supporting files are involved: The ghost dumps must be generated by ghost_record.lua before they can be used in ghost_play.lua. Simply load ghost_record.lua in snes9x, start the smv you which to dump a ghost from, and exit the emulator when you are done. A file called "ghost.dump" will be generated, which you can rename to something more suitable.
For ghost graphics, you will need two pose definition files, which are harder to generate, so I'll provide an example here:
http://folk.uio.no/sigurdkn/poses.pnghttp://folk.uio.no/sigurdkn/poses.map
To create the colored ghosts in the example, I simply used a color filter on the above poses.png and used poses.map unchanged. This poses file is slightly incomplete. Some poses are missing, most notably the "exhausted" pose during the mother brain fight. A few map incorrectly, most notably the elevator pose. But it still looks pretty nice.
The minimap I used is this one
http://folk.uio.no/sigurdkn/minimap.png
Please give me feedback on this script if you miss something or can't get it to work. Even without the gd stuff, it should still be an improvement on the old versions with the old crashes Saturn complained about fixed.
Edit: Note: This script assumes that it is safe to draw outside the screen. This is not the case for old versions of snes9x, where this causes the script to crash. I recommend the newest versions for this.
Edit: As LagDotCom pointed out, I had mixed up herooftheday 2 and cpadolf 1. This is fixed in the text above now. The video has not been changed.
Edit: Here is a slightly updated version of the script bundled with some example ghost files and the maps/pose info needed (edit: now also handles resets relatively well): http://folk.uio.no/sigurdkn/super_metroid_ghost.zip
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Let me see if I get this right, defender: You have a snes9x movie (smv file), and want to produce an avi file from it, but it's too slow? How slow is it? How long does it take to encode one minute of game time? How large a file do you have at that point? What are your settings in the dialogue that pops up after you choose where to save the file?
Edit: The default option dumps the video uncompressed to disk. This can be slow if your hard drive is slow.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Don't record directly to avi. Record to smv. Then, when that is done, record the avi while playing back the smv. That way, the avi encoding speed does not matter, and the end result will play back at the correct speed.
Edit: Actually, looking more closely, it seems you already have an smv. In that case, the encoding speed isn't really important, imho. I don't have much to suggest then, except that you could try a less cpu-intensive codec, or if you are using raw video/audio, try using a less disk-intensive codec.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Equal to/not equal to searches should work, with enough patience. However, perhaps it would be better to simply search through the rom after the names you expect to be there. They will probably appear in a table somewhere, which will be in the same order as what you want. Most roms are so small that such a search would be pretty quick, though figuring out the character set might be a bit of work. You would probably have to write such a program yourself, but it wouldn't be more than 20-30 lines, I'm sure.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Seeing this topic, I am reminded of my own problems with compiling snes9x on my laptop. It is a 64 bit machine, which is the source of the problems. Snes9x tries to store pointers in ints, but on my machine, a pointer is twice as big as an int, so that doesn't work.
To avoid having to rewrite the program (normally I guess replacing int with long where the problems appear would work, but in the case of an emulator, I guess it might rely on the size being 4 somehow, so I'd rather not do that), I tried compiling in 32-bit mode, with the -m32 flag to g++. This almost works, but due to a missing 32-bit compatibility library (libXext), which I can't seem to find.
So, does anyone either know if changing the appropriate ints to longs should cause problems, or have a precompiled version of snes9x (linux or windows) with a command line argument for playing an smv upon starting?
whoracle: Your error is very cryptic. It is a link error, i.e. one which happens after the compilation step, where most of the work is done, but the linker is not very helpful with its error messages.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Wow. The Dolphin developers are doing a great job, and you are doing a great job at encouraging them too, it seems!
So now dolphin has recording. I guess that must mean that the emulation is deterministic too, then? Otherwise recording wouldn't work. What is the status on the savestates? Are they complete? I guess implementing rerecording is the best way of finding out.
Oh, and another thing: How long does it take to save/load a savestate in dolphin? It is hopefully nearer that needed for previous consoles than it is for a pc.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
An array is a continuous section of memory containing data of the same type. An array of 10 ints, which are often 4 bytes long, would be a section of memory 40 bytes long. C only cares about where in memory that section starts, so if you have a pointer to the first element of the array, that is all you need to know. This means that arrays and pointers are interchangeable, basically.
To create an array, you may write
int a[10] = {0,1,2,3,4,5,6,7,8,9};
When you do this, a section of memory (on the stack) will be filled with these numbers. In a hex editor, it might look like:
Here, the array starts at position 0x14 in memory, so the variable a will have this value in this case. To look up a value in the array, you do
int b = a[3];
for example. This means: Go to the address contained in a. Add 3 times the size of an integer to that address, and read an integer from it, storing it in b. Doing this, we find: a = 0x14. sizeof(int) = 4, so a+3*sizeof(int) = 0x14 + 0xC = 0x20, where we find the integer value 3, as expected. This makes it easy to see what would happen if we ask for something at a greater position than what was allocated for the array. We just get whatever lies in memory afterward. In this example, a[10] would read the bytes 5D 0A 3E 3E which corresponds to the integer 1044253277. C does not keep track of how long the array actually is.
Any pointer can be treated as an array. For example
int * c = a+6;
return c[3];
This will return the same thing as a[9]. c is a pointer to a place in memory 6*sizeof(int) later in memory than a, that is 0x2C, and we can treat this as an array starting at a later point in the original array a.
Another way of creating an array is to use malloc to reserve an area of memory on the heap:
int * d = malloc(1000*sizeof(int));
This can be used just like the previous arrays, except that you should free up the memory after you're done with it:
free(d);
(this will happen automatically when your program exits, though, so for a small program it is not a disaster if you forget).
And as for what they are useful for, isn't that pretty obvious? Let's say that you want to read in 10 numbers from standard input, and print them back their squares in reverse order. Without arrays, this would look like
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
moozooh wrote:
Then your topic title is misleading, I guess?
How is it misleading? If the straight line from A to B is at an angle which leads to negative rounding errors, then perhaps some almost straight but more complicated path from A to B wold be faster. Seems reasonable to me, though I agree that this probably is negligible.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
An external png sounds like a nice solution. It removes the most difficult part of what I thought of, and also opens for interesting possibilities like making Mario's ghost be Luigi, for example.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Xkeeper wrote:
amaurea wrote:
Telling where you are in a movie is not that hard: you just count how many frames have been executed so far.
Savestates can easily break that idea; if you rewind 10 frames, how will the script know that?
I would use registersave and registerload to make that variable be stored with the savestate.
Xkeeper wrote:
This is why I think there should be an easy-to-use "emu.frames" or "emu.playpos". Preferrably like VBA's, that stores both game and movie frames (i.e., starting recording mid-game = game 100, movie 1), that is savestate-persistant.
I still think that this is a good idea, though.
Xkeeper wrote:
Another problem with this approach is that every other frame will display something from the other movie: Your loop has two frames, one per movie, per iteration, and this will lead to flickering. You can't fast forward past one of these, since there will be no graphics to capture in that case. I guess this could be worked around by not only adding the secondary movie's graphics to the primary one's, but also the other way around, but this would require two screenshot buffers, and would still lead to flickering in the form of things alternately being in front of and behind each other.
No, what you would do is store an external "replay" file that simply has frame# and a few relevant variables (camerapos, area, player location, animation frame). It would use the replay data instead of switching between two movies.
How will you display the correct sprite for the ghost, then? If you just display a hit box, then it sounds just like what I did for super metroid. I guess it would be possible to store the actual sprite in the file too. This could be done in several ways:
1. Store the sprite for every frame. This gives you a very big file.
2. Store every different sprite once, and then the index in that list for every frame. This is probably the best way of doing it. It requires knowledge of the memory address which holds which sprite is being used.
3. Store only the sprite number, and then decode the sprite from the rom during playback. This is probably a bit over the top.
Number 2 is probably the best option here. I am tempted to give it a try.[/list]
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Telling where you are in a movie is not that hard: you just count how many frames have been executed so far.
Another problem with this approach is that every other frame will display something from the other movie: Your loop has two frames, one per movie, per iteration, and this will lead to flickering. You can't fast forward past one of these, since there will be no graphics to capture in that case. I guess this could be worked around by not only adding the secondary movie's graphics to the primary one's, but also the other way around, but this would require two screenshot buffers, and would still lead to flickering in the form of things alternately being in front of and behind each other.
Still, it would be very nice if you could get this to work! Just because I gave up doesn't mean it's impossible.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
XKeeper: actually, this is how I first tried implementing this. It ran horribly slowly, and I also seem to remember some problems from a one frame delay occuring every time you load. Saving and loading state is an expensive operation. To make it less expensive, I tried implementing memory-only savestates, but it did not help much, and I didn't manage to implement them well enough, since they led to desyncs. Which is why I went with the multiprocess approach instead.
Ofcourse, if running time is not an issue, it is probably feasable to fix the other problems and implement a script like the one you suggest, but it would still be a lot of work.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Have made the drawing functions more lentinent, so that any script that draws to the screen does not need to include the same boring screen boundary checking?
I also suggest adding control over which sound channels are played and which backgrounds/sprites are on.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Well, I have next to no experience with this, but this has worked for me before:
Pass 1:
-x264encopts subq=4:bframes=3:b_pyramid:weight_b:threads=auto:pass=1
Pass 2:
x264encopts subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b:threads=auto:pass=2
You will also have to specify bitrate and any sound settings, which I have not tried. But perhaps my silly settings will provoke someone who actually knows something about this to respond.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I think I've heard that shinesparking into mother brain is the fastest way to suicide in Super Metroid (giving you 200 damage per frame, or something like that). Trying to speedboost through will probably not work very well, but it would be nice to see exactly what happens.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Gocha, I have this on second hand, but it seems that when trying to record an avi while skipping some parts of the movie with a lua script (by using speedmode("maximum")), the sound of those parts is included in the avi, even though the video of the skipped frames is not. Thus, audio and video get out of sync.
It would be best if the sound from the skipped frames was not included either. This is relevant for making avis of the recent super metroid run, for example, where it would be nice to skip the 100 10 second long item fanfares involved, as well as countless door transitions etc.
