I really enjoyed this movie. I liked watching it slow and reading the details.
I was strongly under the impression that many games on this site have equal or more extensive luck manipulation, or route planning, or coordinated efforts. I wouldn't submit a run for publication myself that I knew did not have a level of care put into it similar to this one.
I did love it and I really do wish we can continue to tackle more puzzle-oriented, 50-things-to-consider-every-damn-frame type games. But in many senses this is nothing new or groundbreaking in tasing. But so too is it important for being a DOS game tas.
Cool run and great work to all involved. The high standards of TASvideos march on forever.
With regards to categories, due to how many (realtime) runs I've seen of this game that use the "game over" glitch, I'd personally vastly prefer one of the more restricted categories to ban this trick. The feedback I'm seeing here of people who did not like the game-over invincibility only reinforces my belief. I personally don't mind the trick, but it's been so long since I've seen a run that doesn't use it. Perhaps this is all the more reason to have a category possible here that doesn't use that trick.
I can't speak in an educated manner about every other glitch possible in this game and whether it should be allowed in a restricted category. The game has long been well-known for its glitches and occasional instability (hence the fake error message room). If there was a way to know every minor glitch that people were aware of when the final version of the game came out, that'd be a clear and non-arbitrary goal for a "glitchless" or "no major glitches" or "no major skips" run.
Not to be outshadowed entirely by his brother, Luigi acquires the same personal trainer Mario used (KFC) and accomplishes the same obstacle course, unscathed, a mere 13 seconds slower.
I would suggest a water level for the screenshot.
I remember reading an article about the lengths that the developers of this game went to in terms of piracy protection, so I find it quite excellent that it was possible to modify the emulator to successfully run the game. Based on that article I had quite the feeling that it would be absolute hell to hack/modify the game successfully enough.
Is it really necessary to ridicule the guy so much? I feel like we should be giving all our beginners one free mulligan when they submit a run like this, not understanding the expectations of submissions.
You could say that he deserves some ribbing for not reading the rules, or any of the other easy-to-find explanations about TASvideos. And you'd be right. But this is not ribbing. I say let's give people one free pass: moderate threads like this to remove the most negative replies that don't convey any useful information. Shower the guy in assistance and friendliness. And only then, if he doesn't take the helpful advice and essentially does the same thing again, would it feel appropriate to see all these facetious responses dripping with sarcasm.
Cue a few "gtfo drybes you suck at tasing anyway" :p
^ You are misunderstanding the problem. The randomness in this game is influenced by such factors as uninitialized values which start in an unknown state, and the amount of time the LCD screen physically takes to refresh its pixels.
This is my understanding of it: In theory, let's suppose you have a certain five minute sequence of input, that does nothing but start the game and walk to Viridian city without encounters. Then let us suppose that this sequence actually syncs on a real game boy on some particular power-on. The same input would not even sync the second time around if you powered off the system and immediately tried to play it again.
Some details were mentioned by p4wn3r a few posts below the post you quoted, on the first page of the thread.
Not to sound flip-floppy on opinion, but I don't think I can disagree with much of that post. I guess I asked for it by thinking about the problem of analog input, too. If I may attempt to condense what you said... all valid input to a controller input port must be accepted for TASing to make any sense under certain (and widespread) ideas about what a TAS is.
From your point of view the other items on the list must be much more interesting to discuss.
I always disagreed with L+R for its impossibility. The fact taht you can do it on a third party controller is also meaningless to me since I find it reasonable to assume a game was designed with only the official hardware specs in mind. So I find it very logically easy to file pressing impossible buttons, pressing L+R (same thing imo), and using an actionreplay or gamegenie all under the same category. To me they're all advantages not enjoyed during a legitimate use of the game and console. A game design oversight (they didnt think you could reach this ledge this early in the game) is not the same as a game not handling multiple directions correctly. You're redefining the environment the game is played in. Same with screwing with the cartridge.
On the other hand I see no issue with abusing what happens when the console is power cycled or reset, since this falls within the universe the game was designed in. People taking apart their controllers to press four cardinal directions simultaneously or building custom controllers/peripherals is clearly a different level and type of game abuse.
I agree that well written software handles the unlikely and the improbable with grace. Software written to console specifications has the obligation of doing that. It has no obligation to anticipate the impossible. I believe the following list is completely reasonable to file as impossible: inputs that cannot be generated by correctly functional hardware, input from devices that never existed, cheating devices changing bytes in memory.
Imagine that someone makes a PC game that behaves normally upon any input from some standard 101 key keyboard, but has amazing and unexpected results when fed ASCII characters lower than the keyboard can produce. That's on the game designers for not anticipating an unlikely but possible case. Now imagine the same game was made for a private, proprietary system where the only officially documented input devices were a few specific keyboards incapable of producing those game-breaking ASCII characters. That's a different case. My PC game could be broken just by binding a few hotkeys to produce 0x0F characters. My game for the proprietary system, it is not reasonable to assume I should have anticipated the possibility of generating the 0x0F is there is no way to do that according to specification. Someone coming along afterwards with custom 3rd party hardware that I didnt know about at the time of production, or someone modifying their equipment to be able to produce the special character... how are those any different than a cheat device, or a crooked cartridge, or soldering a resistor somewhere onto the physical hardware to change its properties for the better? All of those things are modifying parameters that were perfectly sane for the designers and programmers to treat as constants. It's not a programming oversight when we press L+R+D all at once, it's us cheating the system. So too when we use invented multitaps or take advantage of an emulator inaccuracy to achieve a result. But not so if we are truly outsmarting the programmer by finding something he didn't anticipate. L+R doesn't feel the same way because it is not an oversight; it could have very easily been accounted for and handled in the veritable menagerie of games for which it allows unexpected behavior. It was instead intentionally ignored and optimized around in the coding of these games because it was rightly treated as a hardware impossibility.
I should also mention that I'm all for runs that take total control of a game and find exploits to directly write to memory. Just not if they have to cheat to obtain that goal by imagining that any hardware modification is cool.
My opinion is sane but proves unpopular here, and I understand why. I understand that emulators have long had L+R U+D capabilities and it was one of the first interesting properties ever discovered in games. So I understand how familiar and used to it we are and how we take it for granted as acceptable.
I am actually not sure how I feel about the fact that in, say, mupen, you can press a stick 100% forward, and it is not possible to press that far on real hardware. Because I suspect the real hardware is not consistent.
My vote is no, because a more accurate emulator is not used, so the slower time is not justified.
cool when did the vote question change to
Do you want this movie accepted? ?
Sorry, allow me to clarify.
I was not entertained by you doing the exact same thing as another run, only slower. I am not inclined to change that opinion after the fact upon learning that neither the previous run nor yours will ever sync or play back on a console. I appreciate that there is no faster way to complete this specific game on the specific core you used.
Is that better? It's nothing personal against you and I would say the same had anyone submitted this run.
^ i'd say the new stuff got shown as much as it could in any speedrun. in fact, it brought back some chilling memories to see that even with optimal swimming, that nautilus keeps up pretty well... hell, that'd make a good screenshot.
nicely done tompa, one more thing to love you for.
My vote is no, because a more accurate emulator is not used, so the slower time is not justified.
As an aside, I feel it is appropriate to credit a previous author in the "by" if a substantial portion of their work and input is being used.
My two cents: the version discussion was over when someone mentioned several pages back that "2.0" is the first C++ release of this originally-shockwave-flash game. Whether or not it is the current "correct" version to use as "latest" is irrelevant because it is, and will always remain, the first hourglassable release, and nobody here seems to be arguing against the school of thought "use the first one or use the most current one". Guess what? It's the first one.
The run itself is sexy, btw. As soon as someone does the no-death mode we won't have to worry about this controversy as there will be a pretty VVVVVV run for everyone's tastes.
By the way, if you're looking for the soundtrack, believe it's called PPPPPP.
I liked how every part was a little different and many novel camera angles were used for castle BLJs. It will take some analysis; I find it hard to say from looking whether some of the parts not already mentioned are faster/slower/the same. The answer is interesting regardless because of how many changes there were from what I've come to expect in a 0 star.
I may be misunderstanding you zwa, but whenever it is possible and does not cost time to do something entertaining, you are highly recommended to do so. That is the spirit of a TAS... when you know it doesn't cost time, screwing around for the sake of showing off, and expressing yourself as a unique author.
So I think you have it backwards. There's no need to do anything fancy when you're making a test run for your own knowledge/skills improvement. You certainly get a chance to try things out, see how they look, be an individual. But that's all your decision to make. In an actual record-setting video like the ones we publish, though, entertainment is of the utmost importance. Movies are rated for quality and for entertainment. People will complain if you don't do things that are elaborate or interesting during 'downtime', or if doing something interesting wouldn't have been any slower than doing something boring, but you did something boring. That's the biggest difference between a good TAS and a GREAT TAS.
You probably know there aren't always a lot of chances to do this, and every game is different. In many games, playing as fast as possible means little or no room for the author to do what he pleases to goof off. Still other games are the opposite, where the majority of the gameplay is a chance to play around and have fun.
Entertainment is in fact so important, that if it can be justified, it's not too rare for TASers to sacrifice a very small amount of speed, in a situation where doing so results in achieving something massively entertaining compared to the absolute-fastest method. You won't really see this on short runs or runs of hotly-contested games, but it is worth knowing. As a community we can be the biggest sticklers for improving a time by every last flippin' frame, and yet we still value entertainment so much that we're willing to give up a few frames if it's truly worth it for the viewing experience, hehe.
It's also a lot more fun to make a run with that attitude. I would encourage you to give that type of thinking a try! Best of luck as you learn and improve your skills.
More stuff was found by testing a ton and by looking for framerules in the game's memory
Great post. Could you (or someone) briefly elaborate on what frame rules, in general, and their associated values can "look like" in memory across a span of N frames? (Like, as opposed to a vanilla counter variable that increments or decrements 1 every frame) May I also ask about a few general things you categorize as "testing a ton" that haven't been mentioned? Or was most of it touched upon already in this thread?
I feel like for finding new things, the utility of viewing memory comes not necessarily from knowing what to look for, but from being able to make an educated guess about what exactly you're looking at and whether it is revealing (or can be used to reveal) a new layer of information. It is hard for me to put this skill into words.
You're using the demo version for the TAS? Not the full version?
I have no idea what these guys are using. I'm not working on this movie and I haven't seen any of their WIP .wtf files.
I wanted to help them with cheat engine, which I have some experience with, so I just followed the link in the first post of this thread, and it took me to a demo of the game. I assumed that was the only version of the game. Since it was the only link I saw in the first several posts. lol. It's been some time since I read the thread initially, and this game is not one I am familiar with.
I suppose if they're using a different version of the game than I am, my tables won't be useful at all. Whoops. Lemme know guys and maybe I can make you a CE table that might actually have useful values
jlun2 wrote:
Lucky. Most games I ran on Hourglass had addresses that CHANGED location every tim I ran it. So I used the "pointer scan" option in Cheat Engine to relocate it every time.
I was wrong about the RAM search thing. a very select few numbers with potential use happened to be at static places in the demo i was looking through. I had to switch to cheat engine to find any good ones.
By using pointer search I was able to find what seems to be some pretty reliable pointers in this particular game. I happened to pick a strong value as the reference and even after multiple restarts, almost every pointer i found still pointed to the right value. Also in this game all the important information is in a close-together bundle in memory. So off that one reliable pointer I could access several values.
If the pointer should stop working then I have to do what you did... re open my scan table, manually locate the value again, and do a search on my table to remove pointers not pointing to the right address... update the values with one that still works, and so forth.
Believe me though I feel your pain. Many games are not this friendly, including WaDF, the one I actually want to work on myself. I'll be forced to do exactly what you wrote unless I can find some reliable pointer chain with a static at the start. I've been running a search now all night, many nodes deep, for a reliable pointer for that game, lol, so we'll see. I feel like if the pointer is too many references away then it becomes a badly time-scaled operation to try finding it, and it's better to find a pointer to a more pointer-trail-friendly address that isn't the one you need but is always at a fixed relative position to the ones you do. Or to try to read the assembly or inspect what is reading/writing values and try to trace back a few possible pointers yourself before doing an exhaustive search
Here are my settings
All default
Edit: And 50FPS as we've recently established.
;)
I cannot figure out the reason I couldn't get the game to work yesterday without using different settings than you specified. The game works fine for me today after a reboot. I found no save files created in either my hourglass folder or the folder i put the game in.
A movie I made today while memory looking also desynced when i tried to load a savestate, but I had the Frame Advance Skips Lag thing enabled. No problems since turning it off. Make sure you are unchecking Frame advance skips lag frames!
After further use of RAM search in hourglass I realized some values aren't there for you. Sorry. Cheat Engine is required. The "speed" values I found yesterday are actually referring to how many pixels per frame the screen is moving. I haven't found the character's speed assuming the screen isn't moving yet. I did find X/Y on screen and Screen on level X/Y though. I made a cheat engine table, please tell me if it works for you. Just have hourglass running, the game running inside hourglass, a movie going, then get into a level... start CE, click the button in the top left and select psychowaluigi_demo_v1_2.exe from the process list, then load up this list. Assuming I picked good pointers, my pointer values for X/Y on screen will work for you. The Screen's Level X/Y are static offsets and should always work.
edit: update: here's a better table. http://www.mediafire.com/download.php?2a5tocu76t4pc6v
if you have aim or skype feel free to message me about this or with any q's. same name as here.
Actually, you probably don't need cheat engine. I just got good results with this game using the RAM search inside hourglass.
I opened RAM search, stood still in a level, searched Equal to Specific Value 0. Then I started walking right with frame advance and once i was moving searched for a greater value. i stopped again and looked for a zero. Eventually I found the X speed. It's one signed byte. I then added it to the watch. It takes a value of 0 if not moving left or right and up to -3 or 3 walking full speed in either direction.
Once you find whatever byte that is, it should stay constant for the whole game. It'll be in a different place whenever you start a new movie file, but not when working off the same initial movie, I think. I checked and it stayed between levels.
At whatever byte that is, the next byte (signed) will give you last direction you moved at least one pixel in (0 for right, -1 for left). At least that's my theory for taht byte. The next signed byte after THAT is your Y speed, positive when falling. The next signed byte after that is the corresponding Y last-direction-moved in.
Use windows calculator in programmer mode, enter the address you found for X speed in hex, and subtract 2DE. Watch the address it gives you (note... as a TWO bit signed) and tell me if that doesn't appear to be the Screen Level X (it increments for every pixel the screen moves right and vice versa). If it's always at that distance relative to the speed, then the value is found for you already now. If not, you'll have to search... trial and error and the process of searching and eliminating. I found it by starting a fresh search, making the screen move right some (then standing still), then chiecking for a number that was different. then i jumped in the air and mid jump i checked for a number out of my subset that was now the same (X screen isnt moving). then i walked left a bit, stopped, and checked for a different number, and by then (and checking how they changed in real time when i pressed jump) i was down to few enough options that I only had to choose the one that made the most sense. And sure enough, the 2-byte value located 2 bytes further up in memory from the Screen Level X seems to be the Screen Level Y. When puzzled or cornered, check your work and consider trying 1 vs 2 vs 4 byte values.
You can just pop those all on your RAM watch and not bother with cheat engine, if it remains this easy. It's like a nice stripped down version of CE anyway. Somehow I wasn't aware that hourglass had this in it, lol :(
Among other things I discovered that when falling your speed Y can exceed 3, so you don't fall at a flat rate equal to your jump, iut's possible to go faster, it's just that this game doesn't seem to use subpixels or a speed sub (havent found one yet), so the acceleration and deceleration physics are somewhat crude in behavior maybe.
Can you tell me what settings you're using on hourglass, before I mess around any further? I did my testing movie with all standard options upon loading hourglass except 50fps, Message Sync Mode -> Unchecked. But my .wtf file is desyncing within the first 32-64 frames.
I got at least two opinions from the IRC chat that a run wouldn't necessarily be rejected for not emulating the sound effects or for using 57fps in hourglass. Interesting.
I also stumbled upon this clip-outside-the-map glitch and i need to figure out how it works, and if it works in more places than here, literally the 2nd to last screen of the game... i initially suspect it's only in this particular spot (and almost certainly only with the flying ball). The framerate makes it difficult to see what he's doing.
http://www.youtube.com/watch?v=Y7kamk0NLAk
Aside from this, the only other public knowledge glitch is that the glass ball doesn't break when it bounces exactly into an inside or outside corner, allowing it to reach a maximum bounce height much higher than all other balls.
If you watched it after my last edit of that post the other day, you saw the fix... I edited the fix into the video, and adjusted the video to play back at a more correct speed. I meant it as sort of a test run or demonstration from the start.
I know very little about optimizing the physics in this game. As such, I didn't try to optimize a great deal beyond the last 2-3 seconds of movement at any given time. I abandoned memory watching without giving it much of a chance, because I couldn't make a pointer-referenced table that would work for me every time, and because I wasn't able to find subpixel positions, speed, or anything that would be truly useful other than screen X/Y. (Translation: lazy and didn't look enough) All I have determined about the physics (and some was discovered along the way, as you noticed) boils down to, the height gained off a bounce when you're holding S will be substantially higher if the ball is moving below a certain horizontal speed. It seems different for each ball.
I would love suggestions on improving it :) I spotted at least a few small improvements myself as I continued on (not even counting optimizing the jumps and physics fully). I am concerned about the publishability of a TAS of this game, though. There's no way to run it at the exact 57.1 framerate it supposedly has, and the sound effects don't play, so I had guessed that for the time being it probably falls under "not emulated well enough" (well, hourglass isn't an emulator but ya know)
I had cheat engine in mind when I mentioned this. I've used it a fair amount (lol, hacking facebook games and the sims for my gf). I've never played this game but I may take a look at in in CE later and try to help.
I would recommend testing that, and anything else you are unsure about with regards to the route or strategies, for sure, before redoing. In hourglass, going back is just so painful. It shouldn't take long to test several of these things since you can essentially play the game in slowdown without rerecording much at all up to the part you need to perform an experiment for comparison. I'd do the experiments in 50fps.
I would also try memory watching the game, on the off chance that the relevant variables are easy enough to locate that they can be of use (I know this pretty much sucks in games that have ridiculously dynamic addressing). If you can get in contact with the programmer of the game through DJ Yoshiman, he might even be able to help with finding memory addresses by providing you with numbers you can search for, such as the speed max value.
