Posts for Grogir

Experienced Forum User
Joined: 12/11/2018
Posts: 13
Btw should we swap to english language? I forgot to do it last time but it's in the rules and costs only 1 frame
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Here is my simulation https://onlinegdb.com/HJMXHhQQ4 Tried to reproduce at best the behavior of running on both platforms, and it results in the two sequences we have (the process takes a few minutes but doesn't find anything after the first %). Constants at the top might be changed, especially the #define uncommented to display specific sequences. Now I think we're pretty much done with this
Experienced Forum User
Joined: 12/11/2018
Posts: 13
I'm not able to reproduce this sequence, frame 13 should give 750 speed, using "Tintin in Tibet (Europe) (En,Fr,De,Nl)" with both core. Ignoring the speed, it results indeed in a 765/835 speed but the "JorWat25" sequence was better At frame 100 I'm getting x=479.6328 With JorWat one I was getting x=479.9062 I realized the other day that subx was in big endian mode while x is in little endian, it may be your problem? I'm getting x like this :
local x=mainmemory.read_u16_le(0x42)+mainmemory.read_u16_be(0x44)/65536
In genesis it's easier:
local x=mainmemory.read_u32_be(0xEEC8)/65536
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Hmmm I see, he's using the fact that the speed increases by 50 when switching from running to walking below 384, and increases by 140 for the opposite case, so he reaches 768+ quicker. After this the logic is same as mine (release run key when above 768). I didn't notice this on SNES version, as it works differently on genesis, where releasing "run" too early is just losing time.
Experienced Forum User
Joined: 12/11/2018
Posts: 13
There is a little issue with disassembly on Genesis/68000, instructions SUBI and ADDI are not showing the correct registers I found in CPUs/68000/Instructions/IntegerMath.cs at lines 192 and 519 that
int reg = (op >> 0) & 3;
should probably be set to
int reg = (op >> 0) & 7;
as it is on the other 2 functions (lines 135 & 465). The bug can be reproduced on "Tintin Au Tibet (E) (M6) [!]" using the following lua commands : emu.disassemble(0x135C88) emu.disassemble(0x135C94) emu.disassemble(0x12D1EE) (I can submit the bug later in git if needed)
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Sure, I'm asking you what series of input it is in order to make my own researches. If the one I found on SNES is wrong, the one I found on Genesis is probably also wrong.
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Can you explain or screen the method you're talking about? I'm curious now. Actually I've already tried a bot using lua script, but it was way too slow (I remember it took like 30 minutes or 1 hour for less than 10k tries) so instead I tried a simulation in C++ and found the same results, I can't be sure its 100% accurate though.
Experienced Forum User
Joined: 12/11/2018
Posts: 13
ViGadeomes wrote:
Grogir wrote:
Seems a lot easier on SNES :D
Sorry to do not have sharing my learning before but I'll break your brain : I found it too but it's not because it's the fastest way to reach the 835-765 speed that you have the best way to begin running thanks to JorWat25 (on SNES, didn't try on genesis but since it is the same mechanics, i'm sure it is the same...). You can see that by looking your x position, x sub position on different way to reach 835-765 on the same frame.
I'm already taking this into account, I'm not trying to reach the speed asap, I'm only releasing the running key above 768. Did you find a better way or not ? (I'm 99% sure there is not)
creaothceann wrote:
Shouldn't all this be in a Sega Genesis Games subforum thread?
Well this is a very specific thread about a game that is on multiple platforms, sorry for disturbing you
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Seems a lot easier on SNES :D But it's always good to know the mechanics behind
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Ok, I investigated a bit, here are my conclusions : 1. The maximum speed when sprinting is 768 (which is 3px/frame) The maximum when walking is 384 (1.5px/frame) 2. When sprinting, the speed increases by 70/frame When walking, the speed increases or decreases by 25/frame (it increases when below 384, but we don't care about this) 3. The speed is not capped at 768, instead it just decreases by 70 when it is above. That's why it bounces every frame. Above, below, above, below... 4. 70 and 25 being multiples of 5, the maximum speed we can have is 765/835 The worst sprint is 700/770 5. Its a little more complicated though, the speed goes directly from 0 to 360 if you sprint from first frame (75 if you walk), then only after this it increases by 70/frame (25 if walk) 6. Considering you start with 360, with https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm I've come to conclusion that you need to drop (release B) at least 9 frames to be able to reach 765 360 + 9*70 - 9*25 = 765 (that's already what we're doing, in the image above or memory's video we have 9 frames without B) 7. When to drop the frames ? In order to lose the least possible time we need to do it at the highest speed. Do not drop frames from beginning ! Only drop them above 768, that way you can manipulate speed while still running fast. Pressing B while above 768 is very bad since you will lose 70 speed instead of only losing 25 if you release the key. That means a very simple rule : -> If speed>768 but isn't 835, release B -> Every other case, press B This way is better than the previous image. 8. I thought that even after reaching 835, since when you keep pressing B you lose 70, it could have been better to release B, lose 25, lose 25 again etc, so you maintain yourself longer above 800 speed, but it doesn't work. Luckily, maintaining B and the 765/835 speed is better than repeating the process infinitely, so we won't have to do 50000 frames one by one. 9. Same process applies after a jump or anything that break the 835 speed Note : it seems better to jump on a 835 frame and drop on the ground at a 765 one than the opposite (most of the time we wont really have the choice though) 10. I'm still not sure this is the best way to start, this is only if we start at 360 speed (see point 5.), maybe we can drop less frames in total by starting walking for one or two frames. Edit: I did more testing and math, starting by walking before running is useless. The image above is good. 11. Numbers must be different on SNES, but the idea should be the same.
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Thanks for the info! I've done a small break with this TAS but I will work on it at some point . Thats true, your way is better than Memory's one when used in this configuration : However, I'm not sure this is the best possible solution and what method we could use to proove this one is the best other than trying all combinations. I don't see any logic in this speed trick lol. The main thing I noticed for now is that after a jump, the speed goes slower again but its easier to get it back to 835 (only 3 or 4 B frames have to be removed).
Experienced Forum User
Joined: 12/11/2018
Posts: 13
Memory wrote:
Found a trick in this game fairly quickly: https://youtu.be/nLn6gqhh4Os by letting go of the run button at key points you can move faster than simply holding it the entire time. Lua: User movie #51910010557814257
Wow, good job, I feel so stupid that I never noticed this, I guess I have to restart from scratch now
Experienced Forum User
Joined: 12/11/2018
Posts: 13
ViGadeomes wrote:
Wow, I was afraid that it is the SNES version..... But I'm very curious about the strats and the use of HPs because I don't do any of them
The SNES one has a few differences though, the route can't be the same as it has a lot more apples, also some obstacles can be passed on SNES and not on Genesis (like dogs in the hotel), the opposite is probably also true. Basically in Genesis version you can never heal yourself from level 7 until the end