Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Skarsnik wrote:
DaTeL237 wrote:
Surely interesting to see the hitboxes, but I'm wondering how it helps to make the TAS. For me hitting/avoiding enemies was mostly a matter of trial and error (e.g. when to start jumping)
I imagine it would be more useful to find and draw 'hitboxes' of the terrain. With the goal of more easily finding (seeing!) potential shortcuts
Well, it less trial and error mostly. I know when I will get hit (and on the spider it gives me the first vulnerable frame for example)
Also it gets updated for http://imgur.com/6iAbKGt :) (still at the same url linked)
I'm not sure I understand the image. What am I looking at? What are the green boxes inside the wall?
With the hitboxes vizualized... is it clear what happens when you turn around? I remember it's possible to 'hit' things earlier by facing backward to them.
Archanfel wrote:
Update: I successfully achieve zip in W4L3 without using cheats!!! :)
Great, well done! I guess the next step is to investigate the same technique in other places :D
I'm assuming that the zip is possible because the bat pushes MrNutz into the ceiling... going by that assumption I've modified the script to make it easier to search for similar zips.... Hold B for moon-jumping (still using the game's bound checking) and press X to 'teleport' slightly upward. In W4L3 it replicates the zip consistently so I hope it helps
JUMP_INDICATOR_WORD = 0x7e0066;
STATE_INDICATOR_BYTE = 0x7e006d;
Y_VALUE = 0x7e0039;
teleportButton="X";
teleportWasPressed = false;
while true do
local state = memory.readbyte(STATE_INDICATOR_BYTE);
local state2 = memory.readword(JUMP_INDICATOR_WORD);
local input = joypad.read(1);
if (input["B"] and state2>=0) then
memory.writeword(JUMP_INDICATOR_WORD, 100);
memory.writebyte(STATE_INDICATOR_BYTE, 1);
end
if (input[teleportButton] and not teleportWasPressed) then
yVal = memory.readwordsigned(Y_VALUE);
higherVal = yVal - 0x10;
memory.writeword(Y_VALUE, higherVal);
end
teleportWasPressed = input[teleportButton];
snes9x.frameadvance();
end
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Archanfel wrote:
DaTeL237 wrote:
I finally did a short video on the zip :D
I used the LUA script for re-jumping so I'm not sure if it's possible to do without cheats/lua :X
Oh, very nice!!! I guess with help of bats it should be possible without cheats :)
Can please tell exact pixel position of hole in the ceiling? (or provide movie file if possible).
I reproduced it in several spots so it looks like it isn't a specific spot but just the whole ceiling.
Also I now realize that the way it's done (with LUA cheating) is not very consistent so perhaps the same kinds of zip is found in more places
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Skarsnik wrote:
Alright. The TAS is slowy moving. I get some help from Nethr4 on Twitch to figure hitbox of enemies/nuts/coins. I need to redo some part of 1-3 when TASstudio will keep crashing on me. Vertical level are quite tricky.
Here is a preview with the lua script running. (it stop in the middle of 2-1)
https://www.youtube.com/watch?v=AExRTECbPeU
The script can be found here https://gist.github.com/Skarsnik/aa9d6a0f5005ca18502f
Surely interesting to see the hitboxes, but I'm wondering how it helps to make the TAS. For me hitting/avoiding enemies was mostly a matter of trial and error (e.g. when to start jumping)
I imagine it would be more useful to find and draw 'hitboxes' of the terrain. With the goal of more easily finding (seeing!) potential shortcuts
Archanfel wrote:
I checked ceilings at W4L3, but without success :( Seems in genesis version this zip is not exist. Or i doing something wrong...
I finally did a short video on the zip :D
I used the LUA script for re-jumping so I'm not sure if it's possible to do without cheats/lua :X
Link to video
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
DaTeL237 wrote:
I did notice that the game uses a hit-counter and counter for shots from lasers and torpedos. The hit-counter is also increased when a tower, turret or enemy is destroyed by crashing into it. This means the amount of hits can be bigger than the amount of shots.. so it makes me wonder if it's possible to make the game display an accuracy score higher than 100% :)
The game also shows statistics when you fail, so it was a small effort to try getting >100% accuracy... and it works :)
If I don't shoot at all the game registers 100% accuracy independent of the hit or kill count. But if the lasers have been used once or more then the hits/shots ratio is used:
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Derakon wrote:
That was a pretty great trench run. Nice work!
I'm ambivalent about co-op runs personally. They're a lot more difficult to make and they tend to be hard to watch, especially when they're split-screen.
Hmm good point. While watching a LetsPlay of the co-op version I noticed that a good part of the game is quite linear.. in those parts the co-op would only be annoying. Not clear to me yet whether it would be worth the effort. Also I noticed more differences... for example TIEs in the 1st part of Death Star Attack.
solarplex wrote:
DaTeL237 wrote:
alec kermit wrote:
Nice work!
EDIT: You and others might already know this but there is a co-op version of this game included on the SW: Rogue Squadron Rebel Strike disc, allowing you to play through Rogue Leader with splitsceen. If someone does decide to TAS this game I think it would be even more interesting to see a co-op run, but I can definitely understand not wanting to double-up on the amount of complexity.
Wow I did not know that.. indeed that would make for a much more interesting TAS.
Thanks for sharing!
It's certainly a lot easier with the addition of TAStudio. you can just do one controller, roll back and do the other controller lol.
Once Bizhawk supports Dolphin that would make things easier :)
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
alec kermit wrote:
Nice work!
EDIT: You and others might already know this but there is a co-op version of this game included on the SW: Rogue Squadron Rebel Strike disc, allowing you to play through Rogue Leader with splitsceen. If someone does decide to TAS this game I think it would be even more interesting to see a co-op run, but I can definitely understand not wanting to double-up on the amount of complexity.
Wow I did not know that.. indeed that would make for a much more interesting TAS.
Thanks for sharing!
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
So... I did a test TAS of the first level: Death Star Attack
DTM file: http://tasvideos.org/userfiles/info/28275268360685408
Rerecords in the DTM file: 2846
I used several versions of dolphin and ended with 4.0-8534. I tried updating to newer versions of Dolphin (eg 4.0-8711) but then the replay file no longer works so I cannot further update.
Unfortunately I encountered several desyncs which makes continuing not very attractive.
The cinematics look weird in the encoding because Force 9:16 was enabled, but it was the only way I could be decent output at all.
I enter two codes that results in starting with all upgrades so the level itself is shorter.
It includes an 'Advanced Lasers' upgrade that makes each tower in part 1 require about 10 less hits with lasers.
It includes an 'Advanced Torpedos' upgrade that makes sure only 2 instead of 3 torpedos are needed per tower.
It includes an 'Advanced Shields' upgrade that allows me to survive crashing through a tower after it has been hit once (with a charged shot)
Time
The in-game time is only a few seconds faster than the real-time speedrun because the TAS starts without a memory pack.
I found an timer in the RAM. This timer stops during cutscenes. It also stops during out-of-bounds and death animations. I assumed it would be used as my final in-game time. This is why I crash on purpose at the end of part 1 and part 2. But at the end of the level I discovered my assumption to be incorrect. So the pure playing times certainly do not determine the in-game time... but I didn't research exactly what does. My current guess is that cinematics do also count, and thus for in-game time TASes one should use a save-game so the cinematics can be skipped.
Part 1
The most time-consuming is getting close enough to the towers to be in range. I use torpedos on the furthest towers so I don't have to go to them. Also one tower is destroyed by crashing into it, allowing fast movement (towards the furthest towers) to continue for longer.
Part 2
Awesome battle in my opinion :)
Part 3
This is a boring part for a TAS. I chose to make it look like you don't even have to move to complete it. The ship takes minimal detours from a horizontal line. When the TIEs arrive I only spin the X-Wing and make it look like the TIEs and Lord Vader are extremely bad at aiming.
Accuracy is 'only' 84% because the lasers shoot 4 or 2 beams simultaneously and they are all registered individually. In many cases it's impossible to get all beams to hit, for example if the enemy dies on the 1st out of 4 laser beams.
I did notice that the game uses a hit-counter and counter for shots from lasers and torpedos. The hit-counter is also increased when a tower, turret or enemy is destroyed by crashing into it. This means the amount of hits can be bigger than the amount of shots.. so it makes me wonder if it's possible to make the game display an accuracy score higher than 100% :)
Ideas/Findings
I think I should have disabled the crosshairs while I was in the menu. For a TAS they are only blocking the view and dont really help the viewer (or TASer).
The game contains an option to enable 'progressive scan' (instead of Interlacing). In theory it should result in a better picture, but I couldn't see any actual difference. In this run I didn't change it. Also the emulator was running with ProgressiveScan functionality disabled
By now I think a gold-medals TAS would make for a more interesting result because it requires more enemies to be killed. It also makes planning much more complex.
At the start of a section of a level it takes a while before the Roll function becomes available
Bombs are refilled when player loses a life.
Dying just before a cutscene results in shields (but not bombs) to be reset without losing a life.
The left/right control stick rotates the player along the world's horizontal plane. The up/down control stick rotates the player along the player's up/down plane. These rotations are controlled independently, so while rolled to (close to) 90deg... one can rotate twice as fast along the world's horizontal plane.
By button-bashing (at once per 4 frames) it's possible to shoot much faster than when holding the fire-button-bashing.
Speed can be controlled with the L and R button, but also with the trigger. So squeeze the R trigger (without pressing R button) to increase speed.
R button can be used to open wings at any time, so the duration of fast flying can be controlled perfectly, so should always be used when not firing. In this run this could have been used in several places.
There are a range of things that stop me from continuing TASing. However, I hope it inspires someone else to pick up this game :)
Link to video
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
I have a TAS made with 4.0-8534 (and also with some older revisions). In 4.0-8631 (containing the change you refer to) it no longer plays back correctly. Not sure what happens, but it reached 'Movie End' at frame 567/16317.
I didn't try creating a new TAS
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
The goal of most emulators is to produce exactly the same output if it is given exactly the same input. For emulators that are used for making TASes this is a strict requirement. This also means that loading a save-state and doing some things should result in the AI doing exactly the same.
Somewhere inside the game there is an algorithm (a computer program) that determines how an NPC should behave. Typically such an algorithm takes several inputs (eg where is the human player) to decide what the result will be (eg where should the NPC move). All information that is used as input is emulated. So the only way to get a different result is to make sure that the algorithm gets a different input. Another way to say this, is that the only way to get a different result is to make sure that the emulator is in a different state.
Many games have behavior that seems to be random. For example movement of NPCs, trajectories of bullets, when/where enemies spawn, what bonus you get, etc. For this is it common for games to use a Random Number Generator. Again this is an algorithm with input and output. However in this case the input can be just some bytes in the memory of the game that are only there for the RNG. Also the algorithm was designed to produce hard-to-predict (ie 'random') results. Even in this case, if you start from the same state the result will be the same. One way to manipulate an RNG is to make sure the game uses it more or less often.
For you as a starting point I would recommend to start analysing what has and what does not have an effect on the behavior of the NPC
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Heh great improvement. That it's faster is good but that OoB trick would make the run more entertaining :) Did you manage to use the script or find another way of checking for 'holes' in ceilings?
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Archanfel wrote:
DaTeL237 wrote:
Some points for improvement that I found after being published: {frames gained}
W4L3: get into the very top ceiling and zip through {up to 10 seconds}
I will be reach World 4 not soon, but anyway sooner or later time for this problem will come, and would be pity to miss this opportunity again (at least if this zip is workable on Genesis).
Hi Archanfel,
Nice to see somebody working on this game. Your TAS so far is fun to watch for me. I didn't know that the game would tell the player that he collected all coins :)
Unfortunately I don't remember specifically what spots you can zip through. I do know that I made a ceiling_hug.lua script to look for 'holes' in the ceiling to go through. I've attached the code, maybe it'll help you.
Good luck with the coins run!
JUMP_INDICATOR_WORD = 0x7e0066;
STATE_INDICATOR_BYTE = 0x7e006d;
while true do
local state = memory.readbyte(STATE_INDICATOR_BYTE);
local state2 = memory.readword(JUMP_INDICATOR_WORD);
local input = joypad.read(1);
if (input["B"] and (state2>200 or state2==0)) then
memory.writeword(JUMP_INDICATOR_WORD, 100);
memory.writebyte(STATE_INDICATOR_BYTE, 1);
end
snes9x.frameadvance();
end
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
For my animaniacs movie Nitrodon did inspect the assembly in order to figure out exactly how the game comes up with seemingly random outcomes
Using his findings I was able to properly predict and manipulate the game
Whether such an assembly-analysis is the way to go / a viable option depends on the game I suppose
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Looks promising :)
I think the subtitles/notes are a nice touch, although perhaps they shouldn't be embedded into the video (youtube supports 'subtitles' for instance)
You could use it to provide much more info by the way
- what items are picked up
- current amount of ammo
- current amount of pstas
- 'Xth enemy going down'
- traps being avoided
- etc, anything the viewer might have missed :)
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Nahoc wrote:
I'm still interested in TASing this game, but the physics are just too plain weird.. Holding diagonal seems faster at start, but sometimes during falls too. It makes no sense and ends up making the game really hard to TAS. If anyone can figure it out (maybe via memory viewing) tell me!
I wanted to try and figure some stuff out, but then discovered that there are no proper memory inspection tools :/ (because dolphin's byte order doesn't allow the general memory watch tools to be used)
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
You cannot predict every situation, so you cannot make the best choice in a TAS sense.
You don't know whether a lottery ticket is the winning one, you don't know whether you'll be happy with person X, etc. With TAS tools 'the right choice' amounts to the best outcome instead of some choice that incorporates all kinds of factors (risk)
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Heh very smooth :D Seems that you took much more care in preserving 'fast-run' :)
Did you happen to play around with the juggle-the-key-out-of-the-hut idea? :D
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
(too lazy to test it myself + more a suggestion than a question)
Does shooting affect the RNG? (each shot has an inaccuracy-offset.... but is that based on an RNG or just a preset pattern? :))
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Might be that the lightness (L) component is domating your distances? iirc L does not have the same range as a* and b*. Perhaps rescaling them to the same size improves the result
edit: Unfortunately didn't bring my work's laptop (which has MATLAB) :/
edit2: To test the script, run it on a 'full' color map: http://javascript.internet.com/img/slider/hs.jpg
Experienced Forum User, Published Author, Active player
(354)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Randil wrote:
I think the problem lies in the distance function. I'm using the same one I used for the mosaic script I made, namely this: If the pixel you are to choose a color for has RGB values R1, G1 and B1, and color i (i is 1,...,15 since Mario Paint has 15 colors) has RGB values R(i), G(i), B(i), then the distance function is defined as
d=|R1-R(i)|^p + |G1-G(i)|^p + |B1-B(i)|^p
Here the RBG values are between 0 and 255. The script loops through all 15 colors and picks the one that gives the smallest d.
p is a parameter you can change in the script. I used p=1 in the pictures I posted.
I seem to remember Derakon mentioning in the Mosaic thread that you should weight the RGB values differently. I might need to do this. Another option would be to choose an entirely different distance function. Any thoughts on this matter?
