Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
No, you don't have to translate the addresses into hexadecimal. If you actually have the decimal addresses, then you can just specify them as such. For example, to read a byte from position 15 (decimal), you would do emu.readbyte(15). This would be equivalent to emu.readbyte(0xf). The reason why hexadecimal usually is used, is that that, due to hardware reasons, gives the roundest numbers, with consistent numbers of digits, etc.
Normally when you find addresses yourself or on the internet, they will already be expressed in hexadecimal. You will then enter them with a 0x in front, to tell lua that it is a hexadecimal number, and not a decimal number. But since you seem to have found the something as rare as addresses expressed in decimal, you just enter them without the 0x in front.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
To clarify, there are several ways of doing this:
#1: The far most common one is to play through the game in slow motion with recording on (not avi recording, but input recording) and perform the inputs you need. The result is an .smv file, which can be played back as many times as you want, always giving the same result. Remember that you can use savestates while recording, so the emulator itself can be pretty close to the sort of tracker program you want, with the additional advantage that it actually shows you the result of your input at the same time.
#2: If you want to produce an .smv file without playing through the game to produce the inputs, it is possible to create an smv file from scratch. Various tas editors exist, I believe, but I have never used one. In lieu of those, you would have to read the smv specification, and create a program that produces an smv file with the inputs you want. This is probably too cumbersome to be worth it.
#3: A third option is to use LUA-scripts to create the inputs. You would then play the game with recording on, as in the first method, but your LUA script would press the keys, not you. This method also requires programming, but far less than the second option.
From what I have heard so far, I think what you really want is option #1 - the standard way of producing a TAS. But it is hard to know when you explain yourself so tersely.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Baxter: Wouldn't the movie it's supposed to obsolete be the currently published run in the same category. I.e. wouldn't having category information in the submission solve this automatically?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
mmbossman wrote:
What about game specific categories?
amaurea wrote:
I suggest a text-field for category entry, as well as a drop-down box with previously used categories for that game.
I guess I didn't make it clear enough, but when submitting a run for game X, you have a drop-down box to choose from, which contains the categories used for previous submissions for game X. If the correct category is not on that list, then you use a text-entry field to enter the category, which will then be available on the drop-down-box the next time somebody makes a submission for that game.
The point of the drop-down box instead of just having a text entry field is to avoid having the same category being spelled in slightly different ways for each submission.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I have a suggestion: How about making the category something you specify when submitting a run? That would make the workbench thread titles more informative, and it would be nice to have category information in the submission database. I suggest a text-field for category entry, as well as a drop-down box with previously used categories for that game.
The category of the submission and that of the publication should be connected, so that in case the run ends up being published under another category than it was submitted as, the submission entry should be automatically updated.
If this is introduced, every published run could have its corresponding submission entry updated automatically quite easily. The runs that became gruefood could either be manually assigned a category (sounds like too much work, perhaps), or assigned a dummy category for the time being.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Kuwaga: The lua scripts never actually make the emulator frameadvance. Instead, the emulator runs the scripts once per frame, and does not continue before they are finished for this frame. The emulator does something like this:
while(true)
{
call lua's beforeemulation hooks
emulate a frame
call lua's afteremulation hooks
if(displayframe)
{
call lua's graphics hooks
update screen
}
call main lua function
}
Note that these calls do not happen in parallel, but one after another, so that the emulator does not do anything while lua is running, but only continues when lua returns (by calling "emu.frameadvance" in the case of the lua main function). In the case of multiple scripts, the emulator calls the first one, which does something and then returns by calling emu.frameadvance. When the emulator gets back control, it calls the next one, and so on. So emu.frameadvance does not advance the frame, it simply says "I'm done for now, continue doing whatever you were doing".
DarkKobold: If you look at the pseudocode I posted above, you will probably see the cause of your problem. The lua main loop is called after the screen has been updated, but before the next frame has been emulated. So at this point, your script has access to the previous frame's state, but anything you draw will appear the next frame, and thus effectively lag one frame. To avoid this problem, you can use the other lua hooks. Afteremulation, for example.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
When you call framadvance (at least in snes9x, which is what I have experience with), control returns from the lua script to the emulator. The current location in the lua script is remembered, and execution continues there the next time lua the lua main section is invoked (it is a coroutine yield). So yes, a more accurate name would be wait_for_next_frame. There is no point of changing this now, though. If you want a new name for it you can just define an alias.
Entirely separate from this issue, it is possible for the script to control the speed of the emulator. Typically, the choices are: Normal speed (as if the script weren't controlling the speed, so you can frame advance, fast forward etc. as you please), turbo (which is like holding down the turbo button) and maximum (full speed emulation with no frames rendered). Usually a script will use either normal or maximum, there is little use for the turbo setting.
It is also possible for the script to override the user's keypresess with its own ones. So all in all, it is pretty flexible. You should give it a try - figuring it out that way is much simpler than trying to make sense of it through this thread.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I've hacked up a proof-of-concept for an automatic encoding service: http://84.208.109.225/~sigurdkn/cgi-bin/smvlist
It is quite limited: Only supports snes9x-rr-1.43 movies with the most common sync settings, might occasionally use the wrong rom due to the issue Nach pointed out (but I haven't had this happen myself), and runs on my laptop, which is not always on or connected to the internet. But anyway, feel free to give it a shot. The usage should be quite self-explanatory: Just select an .smv file, and push submit to have it encoded. This is up for testing purposes, so don't hesitate to upload.
Edit: OK, taking this down now, as I'm going for a long trip, and nobody tried uploading any smv for encoding.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I thought sorting by completion time would put them in their correct place, without needing to prune them. That won't handle cases where the submission is artificially short for some reason, though. But I think a bigger problem is the category stuff. Is the category a submission belongs to available anywhere, or is that only decided during publication?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I thought Gruefood Delight was a hand-picked set of enjoyable gruefood runs, not an automatically updated list of all submissions sorted by game, category and completion time. I think both would be nice to have.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I like this idea. While the runs are available by digging in the gruefood section, it would be nice to have them available in organized form. Some published runs are very obsolete, with much less obsolete submissions being rejected. An example of this is Ocarina of Time. Having a list of all submissions, rejected or not, for each game, would make it much simpler to see what the current record is, and this list could also be linked to from the description of publications that are more obsolete than the best gruefood.
The list could look something like this: A list of each game, organized like the list of published runs. For each game, have a list of categories, and sort the submissions for each category by completion time, with an icon beside each submission indicating its fate, which could be: Current published run, published but obsoleted, gruefood and pending judgement.
Most of this could be constructed automatically, I think. The problem might be the category - which I'm not sure if is specified during submission, or decided upon during the judging process, so that gruefood runs wouldn't have a category available in the database.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This is a collection of clips for marvel vs. capcom 2 made using programmable controllers: http://www.youtube.com/watch?v=hx_xAmwENa8
It looks like the timing requirements should be quite strict here, so console based TASes might not be as infeasable after all. It would be very interesting to hear what desyncs were encountered when making this TAS.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Nach wrote:
That won't work if the ROM dump you have is interleaved, nor will it work for BS dumps.
I can also add it requires them to be decompressed.
Yes, that's right. At least on the compression. As for interleaved and BS, I'm not familiar with those, so I'll take your word it doesn't work there either.
I wrote this "romcrc.cpp" a long time ago, so I am a bit fuzzy on it, but I think I read the algorithm bsnes uses (which I forgot to credit, sorry), and then simplified it down to the minimum I thought necessary, which was apparently a bit too far. So you can easily make a more general version by not simplifying it like that, if you don't already have one. That said, it has worked for the roms I have tried it on.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I know some of you have made systems like this before - dehacked, for example. But I just make one myself, and thought some of you might find the setup useful.
Basically, the goal is to be able to automatically encode a snes9x smv file:
smvenc movie.smv movie.mkv
with no other input needed.
The smvenc script is defined here:
http://folk.uio.no/sigurdkn/smvenc
It depends on snes2mkv, which encodes from the raw video and audio snes9x dumps:
http://folk.uio.no/sigurdkn/snes2mkv
It also uses a few other small tools for extracting information from the smv file:
http://folk.uio.no/sigurdkn/bread.cpphttp://folk.uio.no/sigurdkn/smvcrc.cpp
Additionally, an assumption is that a directory with symlinks from checksum to rom exists. I.e. if you have a snes rom /home/foo/roms/X.smc with checksum 05fbb855, then you should have a directory containing a symlink named 05fbb855 pointing at that file, and similar for the other roms you want the script to handle. The purpose of this is to avoid having to specify the rom yourself. The rom crc can be computed this way:
http://folk.uio.no/sigurdkn/romcrc.cpp
And that's it, I think. You'll have to edit the hard-coded path to the index directory to point at your own directory in smvenc. Also, you need snes9x-1.43 rerecording, Xvfb and ffmpeg.
I made most of this before I automated the encoding itself, since I wanted to be able to play an smv file simply by clicking on a link to it. But that is something I haven't gotten to work, since firefox refuses to look at anything but the mime type when determining what to do with a file, and smvs don't have an associated mime type. Stupid firefox.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Soft resets don't have to be quite as soft as the controller-activated ones. On the snes, pressing the reset button on the console does a soft resets which acts as a non-maskable interrupt, causing the code to jump to the location stored in the reset vector. This sort of reset should be possible to emulate accurately, and since it is non-maskable, it will probably interrupt the sram write just like a power cycle would do (unless the reset code has special handling to avoid this).
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
STaRDoGGCHaMP wrote:
amaurea wrote:
Why don't you want a resolution of 256x224?.
Because it sucks, too small. But I found out that ticking the "Simple2x Resize (for HiRes)" option solves my problem.
I really don't get this. When somebody plays back your encode, they can scale it up and down as they please, so what is the point of resizing it in the encode? All the encodes here are in the native resolution. That doesn't mean that you can't watch them in whatever resolution you want.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Generally, you first record the smv file, and then you record to avi while playing back the smv file. That way, the slowness of the encoding won't mess things up for you. It sounds like you have gotten this far already. You definitely don't want to use anything like fraps. I don't understand why you ask if you need to use fraps when you already have discovered that snes9x will do it directly.
Why don't you want a resolution of 256x224? It is the native snes resolution for non-high-res games. That is how much information is actually there, and increasing the resolution would just mean interpolating, which I'd say is the player's job, not something to do in the video file itself. It would only make the file size bigger, and not add any quality at all.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Looking at this document: http://www.romhacking.net/docs/%5B196%5Dregs.txt it seems like a program can read from the controllers whenever it wants, but that the usual way of doing it is to use the auto joypad read service, which polls the joypads once per frame (I think) when enabled.
So it seems like you could conceivably have games which would benefit from sub-frame input. We could ask byuu to be sure, I guess.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Nach wrote:
Derakon:
adelikat and I have been discussing setting up an automated encoding machine. There's some issues we need to work out though, such as getting the emulators to accept all the encoding params via command line, possibly even running in window less mode, uploading to somewhere, and somehow working out the ROM images available on the system.
I have a quite automated system for encoding snes runs. I think the only think missing is automatic determination of how long to encode. I guess I could just set it to stop encoding x% after the input is done. I do it by first having set up a hash database in the file system, with a directory with symlinks from rom hash to rom file. Then, given an smv, I read out the checksum, and look it up in the hash directory, and play it with snes9x set to dump raw audio and video to disk. To avoid wasting disk space, the output video file is a fifo. Ideally, the output audio file would also be a fifo, but that causes deadlocks, so I have to do the encoding in 3 steps: First I cat the video fifo to /dev/null, and just dump the audio. After that, I start ffmpeg encoding from the audio file and the video fifo, and do the first pass and second pass of the encoding.
This probably isn't the best way of doing things, but it is pretty automatic and flexible. Perhaps you can do something similar?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
#1: No idea what you're after here. I guess you could try to be faster (but unportable) by subtracting 4 from the exponent of the floating point numbers instead, that isn't what I would call a more correct solution.
#2: Replace the last one with: vVec.z = -vVec.y;.
#3: Already solved.
#4: I guess you want the backwards looping here too, then, since you have no faith in the compiler's ability to optimize: for(size_t I = vVector.size(); I--;) ulMax = std::max(ulMax, vVector[I]); However, I would do this this way: unsigned long ulMax = vVector.empty() ? 0 : *std::max_element(vVector.begin(),vVector.end());
#5: I would have gone for ulSwitch = !(ulSwitch&1). But with the extra assumption that ulSwitch should be 0 or 1 to begin with, I would just do ulSwitch = !ulSwitch.
#6: ulX = ulIndex & 0xf; ulY = ulIndex >> 4;
#7: I don't think we can answer this without knowledge of what "Do something" is. Looks fine to me, though.
#8: Let's see.. If we assume that alignment = size for the members (not always true), then if all have the same size (8), then the order doesn't matter. If only one has size 4, then the order still doesn't matter, as the whole struct will be padded to fit the alignment of its most stringent member. If two of them are size 4, then they should be put together. The initial code already has this property, as does Bisqwit's suggestion, so if those are wrong, I can't see how to improve them.
Edit: Fixed typo.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Thanks for the new segment! It's nice to see the redesign metroids being effortlessly outmaneuvered and treated like harmless kittens instead of the monsters they were when I encountered them. Too bad you needed that huge pause for luck manipulation, though - that did not look good. But if you're aiming for in-game time, then I guess that's a good way to manipulate with minimal frame loss.
When I play back the final smv (which I'm hoping to see in the workbench soon) I'll make sure to display only in-game frames, since redesign, even more so than regular Super Metroid suffers from having the blazingly fast action broken up by non-ingame frames like door transitions and pause screens.
Anyway, keep up the good work!
