Ok, so this is a big bag of awesome, and the votes warrant acceptance. So instead perhaps the convo should shift towards obsoletion.
One thing I don't like is when there is a glitched run and a non-glitched run that uses glitches. So I'd like to avoid that situation before it happens. Thus, I vote that this obsolete the published movie.
I was always under the impression there was a category for both "glitched to hell" games and "doesn't really use major glitches to blow up the game". You know, like forbidding zipping or whatever.
andymac wrote:
[...] I tried to TAS a short segment of this, and within a short period of time, managed to save a number of trivial frames. I'm not going to elaborate [...]
Generally when you want to see a movie improved, you elaborate on how it can be improved. Making other people do the same work is redundant and draining.
Back it up and help out others instead of saying "spooooooky frames could be saved, but I won't tell you anything about where, so just trust me on that one".
In the German version of Link's Awakening DX (don't know if it works for other versions), type in "MOYSE" as name. You'll get the famous Totaka song.
Wrong. :D Actually it's an entirely different song made by Moyse himself, if I remember right.
A decent GBS player should open up to track 60, which is that music:
GBS of the German version
If you feel more advanced you can use gui.gdscreenshot and gui.gdoverlay (?) to take a picture of the screen and overlay it, using gui.register to show it. Maybe I'll check in on that soon, though the movie to test would definitely help.
Was it that? You're probably right, but I remember that simple combinations of N and A got you there regardless. First time I reached that level was on accident using that code.
There were probably other ones, given.
AAAAAAAA is the first (real) level, too :) (Lets you skip the intro)
Still wrong:
That was taken using a freshly extracted VBA with the option set to In-Game.
Though my suspicions were right...
If you take a screenshot using the screenshot button (F12 by default) it completely ignores your settings and doesn't save the Lua overlay.
If you take a screenshot from the menu or record an AVI, then it will appear. This should be an easy fix.
Perhaps while you're at it you could do a simple check to find the starting index for screenshots too.
lua can show up in screen shots if you have the text in-game
Wrong. I tested that (turned off transparent, in-game, on-game, on-screen)... the overlay text (display, framecounter) changed shape and size but still didn't show up in screenshots.
That was actually the first thing I tried.
Issues requires login and bleh.
Anyway:
- Lua doesn't show up in screenshots. This is bad.
Nobody likes crappy screenshots.
- Still no way to tell what color a pixel is under a specific point. This is bad too.
Other than that no complaints so far, other than yet another deviation in what functions do what. More encouragement to work on a global x_functions.lua I guess.
danke for the implementation if nothing else, and thank god for using Gens's font. Need all the space we can get :|
On an unrelated note it still starts taking screenshots from #1 regardless of how many there actually are, leading to a rewrite fest. This is also bad.
Oh, I get it. Use "Pause after movie playback completed", then wait for the text to disappear before stopping AVI recording.
That might do it. Not sure, though, but...
I was under the impression Bisqwit was leaving. You know, for good. Vanishing. Poof, gone. Aparrently I was wrong at some point, so since he still seems to be around:
Given that you have "left" tasvideos and moved on, are you still interested in games? If so, which? Things like Go, Mega Man, etc. Do they still interest you, or have you moved on from those as well?
If yes, do you still watch TASes on occasion? If so, which? What do you look for in them?
What on earths name would their legal justifications be? Ads on a site are totally fine, then it would be illegal to have ads on this site as well as we provide videos showing game footage. Hell, SDA even puts several ads on their games pages, dont you think they checked the legal circumstances beforehand?
shh, logic makes heads explode
--
also difference: the chrono trigger remake was a remake that you would download and play through
whereas a TAS is not a game that you download, it is a movie you watch.
given that fan/gitch videos have been up for years and years and years and some have reached partner status I think all of this FUD is completely fucking unwarranted
I could be completely wrong, but I believe that some memory values can change more than once per frame. Anyway, maybe it's a job for VBA-SDL-H?
Memory can change several times per frame (and often does, just try setting a write breakpoint at 0000 in FCEUX's hex editor for example)
Tried opening VBA's Memory Viewer and hitting the "Save" button, by any chance? That's kind of what it's there for.
EDIT: oops, not beaten by pirate_sephiroth
There's no harm in trying. Christ.
Given that there are (as said) LPers out there that do partnerships...
Also lol at the YouTube ad whiners. You get a popup (silent) in the middle of the video that you can close the instant it appears. Do they seriously bother you that much? How do you live?
In short, hey, go for it.
It's not that the emulator itself isn't close enough, but the timing of movie startup. Many (probably most) games either run on an universal timer or otherwise change randomness since the moment of power-on. Delaying movie start by as much as one frame can throw off the randomness completely.
Also, frames themselves are divisible units (which is not very important for making movies on an emulator but very prominent if you try to do so on the actual hardware), so there will need to be a way to synchronize the keypresses to particular times within a frame when they produce the needed result.
Do not forget that NES RAM is not initialized by default. A randomization system that relied on uninitialized RAM as a seed could be particularly devious.
Why in Metadata the author is HappyLee and not you? I guess steal others work is not allowed either.
Author cannot be changed (without a bit of work) and it is often eaiser to begin rerecording from where the imrpvements begins instead of starting fresh and reinventing the wheel.
But sure!
1 = 37.84
:)
It's nice to see that this movie was finally improved. I was wondering if anybody would take what I learned and put it to use!
Congratulations on discovering the other tricks, too. I probably never would have found them if I tried TASing it.
gui.register is called repeatedly even during emulator-pause mode (otherwise the onscreen text like "State saved" would never leave), while "disappear" is only drawn when the emulation advances.
Otherwise, if you had something that drew to the screen using gui.register you would end up having some very interesting trails.
Lack of "print" console functionality in non-Gens emulators is probably the most annoying and debilitating difference I've noticed so far, though. Having to debug with modal popup dialog boxes instead of real logging is painful. It's possible to work around that with enough effort but it's a big waste of time to accomplish something that Lua is supposed to have a working function for already. (And don't say that "print" is only supposed to go to stdout... Lua actually recommends replacing print with a version that instead goes to something like an application-specific console window.)
You can create something similar with gui.text and a table, but yeah.
Xkeeper wrote:
- Change EMULATORNAME.command() to "emu.command()". There's little sense in having 3 (4, 5, etc) variations on the same commands.
That's sensible. Although it's easy to get the same result by adding something like "emu = emu or gens or snes9x" at the top of every script, this would make for one less thing to worry about.
Yeah. What would actually be even better is to have "emu.version()" return {emulatorname, versionnumber}, allowing scripts to selectively change functions to handle arguments differently based on them. That way if you write a nice interface for emulator A, you don't have to rewrite all the functions for another one, and can instead just use the same module for all of them.
Xkeeper wrote:
- Bump FCEUX up to use full 24-bit color like SNES9x and Gens. This will greatly increase the flexibility with Lua painting, remove the huge speed penalty for drawing (every non-named color is a speed hit because it has to look it up; this is especially noticable if you do a lot of pixel(x, y, "#FF0000") v. using "red").
I'd call it 32-bit color, since 24-bit color would be missing the alpha component, and it's quite useful to have full alpha transparency control in the drawing functions. But that speed comparison you give is a bit weird. I guess FCEUX does some really inefficient color conversion for "#FF0000" to be noticeably slower than "red". Well, the fastest thing even with 32-bit color is to use numbers instead of strings, so for example 0xFF0000FF for 32-bit color red would be fastest since it avoids allocating any memory or going through string tables at all.[/quote]
I actually meant 32-bit, I guess; it's just 24-bit is what is actually drawn (8R8G8B). I'm just used to calling it 24-bit.
FCEUX's comparison is to run though every palette color and calculate how close it is to matching the color you gave (and the function to check picks some pretty bizarre ones). Combine this with some bizarre palette functionality (colors will randomly shift if you load/reload the same palette) and... yeah.
Results aren't cached (and doing so would be another performance hit, especially if you like using dynamic colors), so every single call to a drawing function has to look it up again.
Generally my system tops out at drawing about 2000~2500 individual pixels to the screen before it starts choking.
Xkeeper wrote:
- Make all the commands actually work the same. Does joypad.read read the user's input, the movie's input, or the input set by joypad.set? Choose one and make it a standard.
I think it's really bad when it's not able to read the movie's input, since then a script that works fine when you're recording will totally fail when you try to play back the same input since it's not getting the button presses anymore. So I'd say joypad.read should always get the same buttons the emulated game is getting (whether they come from the user or from movie playback), and things that need to know what buttons the user is trying to press even when the emulation is normally supposed to ignore that input should use a different function for that special purpose (that's what joypad.peek is for in Gens).
I wasn't saying that you shouldn't be able to check movie input at all! Just that it isn't consistant anywhere.
Xkeeper wrote:
(For example you could create a basic hitbox drawer that just took 4 memory addresses and drew them to the screen without having to modify the rest of the code).
Sorry to pick on this particular example, but... 4 memory addresses? I think that having a "drawbox" function already covers most of the cross-game code reuse you could get out of hitbox drawing code, and that there's not much point attempting to generalize something that's so commonly vastly different from game to game, especially when going across platforms.
The whole point was that it was just a simple example. Would you prefer something more like "takes two values representing X and Y speed and graphs them out as a scrolling linechart"?
Invalid Session. Please resubmit the form.
There is an updated binary in the downloads already which has had input.get and a bunch of other additions for a while now. At the moment this is "snes9x-1.43-rerecording-svn-r98.zip" or "snes9x-1.51-rerecording-svn-r67.zip" in the downloads list (depending on whether you want to use 1.43 or 1.51), the same as or only slightly older than the latest trunk version.
That should really be put onthe front page somewhere.
That was taken using a freshly extracted VBA with the option set to In-Game.
Though my suspicions were right...
If you take a screenshot using the screenshot button (F12 by default) it completely ignores your settings and doesn't save the Lua overlay.
If you take a screenshot from the menu or record an AVI, then it will appear. This should be an easy fix.
Perhaps while you're at it you could do a simple check to find the starting index for screenshots too.
- Still no way to tell what color a pixel is under a specific point. This is bad too.
Other than that no complaints so far, other than yet another deviation in what functions do what. More encouragement to work on a global x_functions.lua I guess.
danke for the implementation if nothing else, and thank god for using Gens's font. Need all the space we can get :|
On an unrelated note it still starts taking screenshots from #1 regardless of how many there actually are, leading to a rewrite fest. This is also bad.
