Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
While I can't help directly on the commentary, since my english is not that great, I guess I can help with knowledge and key points in the SM64 runs. If you need any help with that, I'll be happy to do so!
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
comex wrote:
2. Can the run be improved to avoid lag in the first place, e.g. by using fixed camera mode? This might make it less entertaining, but should save time, including on console - as well as reduce divergence between emulators.
Run was already prepared to avoid as much lag as possible, including on lag that would just affect on console and not on emulator (both mupen and bizhawk).
comex wrote:
First of all, BizHawk's N64 backend is Mupen - the latest version of libmupen64plus. Apparently mupen64-rr is over a decade old, so it would make sense for there to be divergences, but a lot should be directly comparable.
Also - if the run syncs but ends up with a different time, I'm guessing (could be wrong) that the divergence is primarily caused by video lag - that is, on some frames, the RSP/RDP is taking more than the allotted time to render the scene, and the specific amount of time differs between tests on Mupen, BizHawk, and real N64 (because neither version of mupen properly emulates the RSP/RDP's cycle timing).
I honestly never checked why Bizhawk is slower, but it seems to be mostly at the intro (power up). Then they seem to run at the same speed (Bizhawk's core is Mupen after all, as you said).
Mothrayas wrote:
adelikat proposed an alternative compromise: the movie is still submitted as a BK2 file, but the displayed time will be changed to reflect that of the equivalent M64 file.
Would this work for you? This would solve the SM64 community's gripe with the BK2 reporting an off time, while publishers can still encode and publish in BizHawk.
I'll agree with whatever Plush says, since he's the one who worked on the improvement.
As for my personal opinion, I agree with what adelikat said time ago, both emulators are currently inaccurate. Just because Mupen gets closer to console's time doesn't mean it's more accurate. However I can understand the SM64 TAS community concern here (including me), which is having an improvement of 2 frames that'd lead into a final time that is 2 seconds slower, and even slower than console just doesn't look nice. So in my opinion submitting as BK2 and keeping M64 timing would be a fair solution I guess.
Finally, from what I've checked so far, console runs games a bit slower (59.8xFPS vs 60FPS), but loading times are faster (This applies to both Mupen and Bizhawk). This makes console almost as fast as Mupen on this category, but much slower (~1 min) on 120 star, since there aren't that many loading times there.
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
brunovalads wrote:
I'm testing the script and it's amazing! The main lag problem is drawing inside fors. Since the main RNG drawing is
Language: lua
local rngcols = 12
for i=0,rngcols-1,1 do
for j=0,17,1 do
--[...]
drawRNGsquare(j,i,clr)
end
end
you're drawing 216 squares each frame, which indeed lags (my fps drops from 60 to 45, which is not that bad). I removed just this square printing and my fps went back to normal, as you can see. I noticed that this RNG grid is like a stream of values: the squares are floating from the right to the left, like if it was printing the current RNG value + the past 17 values (correct me if I'm wrong). If so, is it really necessary printing past values?
Yeah, I know most of the lag comes from there. Printing a similar grid like this doesn't have any effect on lag on other emus like VBA (FractalFusion did a similar lua) and Desmume, but unfortunatelly it does here.
The grid doesn't print the past RNG values, it prints the current RNG plus the next 18 * (number of rows) values. It helps predicting the RNG and manipulate it (how to hit a critical hit as fast as possible, capture a pokemon, get a certain encounter, etc).
My solution for this grid right now is having a "-" and "+" button just below that adds and eliminates rows. By eliminating some rows in that grid I can run the lua with almost no lag.
Pokota wrote:
Fun fact - you can't currently draw image files onto a lua canvas, unless you can and I'm just a dumb. The goal is to put these image files onto a separate canvas so that the emulator window remains uncluttered while streaming/recording.
Language: lua
<codeblock>
That looks interesting! I'll have a look at this, thanks!
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
Pokota wrote:
If the RNG changes every frame, then it's going to get slowed down since then the script has to be re-run every frame. Including all of the drawing. I'd suggest not using the RNG tab if you don't actually need it (or only using it if you need TAS precision on the RNG which at that point wouldn't you be doing frame-advance anyway?)
Can you share the script? I'm curious to know how it works and to see how it runs on my machine.
Yeah, that's what I currently do. I'd like to have a way to run the script like each 2 or 3 frames, but drawing is cleared after each frame (I don't know if it's possible to change this).
This is the link of the lua: https://www.dropbox.com/s/l8dte92o51pw6p2/PokemonGen3Lua.zip?dl=0
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
brunovalads wrote:
Can you show a screenshot to understand better the situation?
This would be an example:
brunovalads wrote:
Do all this data need to be printed everytime?
No, in fact I have stuff like that button at the top right to hide the right part of the screen (also that'd also stop making all the pokemon calculation and drawing), but for example the square grid at the bottom left slows down the emulator itself.
dan wrote:
See http://tasvideos.org/BizHawk/LuaFunctions.html, specifically the event tab. The following works, although you may need a command to unregister the function if you reload the script. I've noticed a weird quirk where you have multiple definitions of the same function and the workaround is to manually clear the registered functions.
local function mkdasher()
.
:
end
-- define an anonymous wrapper function that calls the named function
event.onframestart(function() mkdasher() end, "mkdasher")
I don't see how that helps either. That still causes the emulator to lag, since it waits for the function to be drawn completely.
Also I have another question, everytime frameadvance is called the whole lua is cleared. Is there a way to refresh the lua manually and only update it when I want to? That'd probably be a workaround if possible.
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
So I was trying to build a lua script for Bizhawk that displays data on the screen. I notice that if I try to display a lot of data (calling draw functions many times) and I make a loop with emu.frameadvance(), emulator slows down a lot since it tries to refresh the whole thing every frame.
Is there any way to solve that issue? When I do lua scripts on Desmume I usually call gui.register() to draw stuff, and emu.registerafter() for memory reading / writing and calculations. Is there any similar solution in Bizhawk?
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
Trully a masterpice. I hope this TAS gets the recognition it deserves.
And obvious yes vote.
Some comments I'd like to add to the run:
- Really interesting way to clip through the water at the beginning.
- Nice star cancel, I know those strats are really hard to optimize and it looks pretty clean.
- Never would have expected that ending in the gomboss battle with the double goomba hit. That was trully amazing.
- Really nice new 50 star door skip. To be honest I really don't know why we never thought of that before in previous TASes.
- That BitS was spectacular with the triple jumps.
And finally good job keeping a high entertainment value for the run in terms of movement and such. I know it's quite hard to do so in this game so that's a really nice bonus imo.
Again, congrats to the authors.
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
Overall I enjoyed the TASBlock this year, you guys are able to show new technical stuff every year which is something really hard to do, so congrats to everyone involved. However, I'm sorry but as z1mb0bw4y said there are a few things that I didn't really like and I feel like posting my personal opinion too.
Masterjun wrote:
I'm the one who suggested keeping my Pong and Snake run a secret, even from the TASVideos community. I personally still want to keep that element of surprise.
Yes exactly, you suggested keeping your run a secret. The authors of both SM64 and Portal runs didn't even know about it. I know the main purpose was streaming a video on this case but I don't think it'd be harmful to inform the authors about it (PMs do exist) to avoid misleading commentaries. (Specifically talking about SM64, we even suggested to send Tyler to AGDQ at the end of page 3 of this thread, but we were completely ignored, guy who discovered most of the new tricks and his name wasn't mention even once during the whole run).
Masterjun wrote:
And not being able to explain glitch-heavy TASes in realtime, which usually require several pages of submission text to get all the details in? Like that's easy and reasonable to do right?
It's not about being able to explain every detail about the TASes in real time, it's about giving commentary according to what it's happening during the TAS. I can't personally talk about Portal because I don't know about the run, but I could make a list about some explanations given during the SM64 run that shows that the commentator doesn't really know what is going on during those sections in the run.
And again, I don't know why it's so hard to properly credit TASes that aren't directly involved or made for the TASblock. You can clearly see the difference between the DS Brain Age TAS last year where every single person that contributed to it was creditted at the end of the run, and the SM64 run in 2014 referred to "A bunch of TASers", or this 2 runs with literally no credit.
Again, I think everything else in the TASBlock was really good and I'll keep watching and supporting it every GDQ, but I really wanted to give my opinion about this one.
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
Plush wrote:
mkdasher wrote:
- When your speed is 47, if you do a perfect input, your speed will go to 47.15. Instead, you can force your joystick tilt to be worse to get a 47.9999 speed.
I was wondering, this isn't useful on every circumstance, is it? I mean, let's take as an example a LJ starting from 45.55:
45.55 +1.15 => 46.7
At this point, I could either do the trick you say
46.7 => 46.999 => 47.999 => (+0.15)
or just normally tilt
46.7 => 47.85 => 48 => (+0.15)
You can see by eye that normally tilting is faster (47.85 > 46.999). So since I'm very bad at maths, I was wondering, in what range(s) simply tilting is faster than doing the trick you mentioned? :v
You are supposed to do the trick to get 47.999, not 46.999.
If your speed is lower than 46.85, a perfect input will always get you a speed lower than 48, so there's no reason to do that.
If your speed is higher than 47.85, a perfect input will give you over 48, so unless you're trying to force your angle, the trick is useless as well.
So the range you would usually do this is 46.85 to 47.85.
(For jump diving, there's a equivalent range, which goes from 30.85 to 31.85).
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
Previous Air longjumping state formula can be generalized into just Air state as follows (again credits go to Tyler):
Language: c
float hSpeed; //horizontal Speed from previous state (we assume this was already initialized).
float vSpeed; //vertical Speed from previous state.
float F0 = 0;
float F1 = 32;
if (longjumping) F1 = 48;
if (hSpeed > 0)
{
if (hSpeed > 0.35) hSpeed -= 0.35;
else hSpeed = 0;
}
else
{
if (-0.35 > hSpeed) hSpeed += 0.35;
else hSpeed = 0;
}
if (inputPossible){ //Indicates if input is enabled or disabled. When you jump off a slope, input is sometimes ignored.
int S0 = facingAngle - moveAngle; // angle goes from -32768 to 32767.
float F2 = joystickTilt / 32; //joystickTilt is just a value that goes from 0 to 32
hSpeed += F2 * cos(S0) * 1.5;
F0 = SM64Operation.sin(S0) * F2 * 10; //this is not used to calculate horizontal speed so ignore.
}
if (hSpeed > F1) hSpeed -= 1;
if (hSpeed < -16) hSpeed += 2;
xSpeed = cos(moveAngle) * hSpeed + F0 * cos(moveAngle + 16384)); //reminder angles go from -32767 to 32768
ySpeed = sin(moveAngle) * hSpeed + F0 * sin(moveAngle + 16384));
This explains why when you single jump, double jump, dive, WK, etc. Speed gets capped when your speed is higher than 32, but longjumping speed increases faster until your speed is 48.
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
Well, I'm gonna explain how this works exactly on game's code, and then I'll try to explain a bit more about it. (Credits to Tyler for finding out basically all the formulas I'm gonna show right now).
To understand this, we have to understand that Longjumping consists on 2 different states:
1. Releasing a Longjump
2. Being in air after a Longjump.
Being in air after a Longjump
I think the clearest way to show this is with some pseudocode.
Language: c
float hSpeed; //horizontal Speed from previous state (we assume this was already initialized).
float vSpeed; //vertical Speed from previous state.
if (hSpeed > 0)
{
if (hSpeed > 0.35) hSpeed -= 0.35;
else hSpeed = 0;
}
else
{
if (-0.35 > hSpeed) hSpeed += 0.35;
else hSpeed = 0;
}
int S0 = facingAngle - moveAngle; // angle goes from -32768 to 32767.
float F2 = joystickTilt / 32; //joystickTilt is just a value that goes from 0 to 32
hSpeed += F2 * cos(S0) * 1.5;
F0 = SM64Operation.sin(S0) * F2 * 10; //this is not used to calculate horizontal speed so ignore.
if (hSpeed > 48) hSpeed -= 1;
if (hSpeed < -16) hSpeed += 2;
calculateXSpeedAndYSpeed(); // Calculating x speed and y speed based on the horizontal speed you just got.
Now let's see what this means in the different scenarios:
- If you're forward longjumping, if your speed goes from 0.0001 to 48, your speed will increase at most 1.15.
- If your speed is higher than 48, your speed will increase at most 0.15.
- If you're backwards longjumping, if your speed goes from -16 to -0.0001, your speed will decrease at most -1.15.
- If your speed is lower than -16, your absolute speed will always decrease by at least 0.85 (your speed will increase by at least 0.85).
- When your speed is 47, if you do a perfect input, your speed will go to 47.15. Instead, you can force your joystick tilt to be worse to get a 47.9999 speed.
Releasing a longjump
This one is very simple, just multiply speed by 1.5, and if speed is higher than 48, cap speed to 48. As you can see there's no cap here for negative values, which makes BLJ possible.
Another important thing to say is, on the frame where you release a longjump, you get both releasing state and air state. You can notice this when you are forward longjumping at high speed, when you release a longjump you don't see a 48 but a 48.15 (speed was capped to 48, then you got a 0.15 increment from the air state).
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
TASVideos logo in the forums seems too complex to make it. There's also that Megaman on TASVideos main page. So I made this up, I guess this isn't exactly the logo but well, tell me what you think.
Experienced Forum User, Published Author, Experienced player
(658)
Joined: 5/16/2009
Posts: 235
Fortranm wrote:
Link to videohttp://tasvideos.org/userfiles/info/26579427510741237
I started a glitchless test-run for Pokemon Diamond. This WIP contains the first hour of the game, up to the second rival fight.
https://kb.speeddemosarchive.com/Pok%C3%A9mon_Diamond/Pearl/Platinum
I'm using the Abra/Kadabra from in-game-trading as the main battle Pokemon. The purpose of this test-run is to see if this route is actually faster than using Piplup. It's hard to compare though since there isn't another glithless English D/P TAS AFAIK.
As you can easily see, the luck-manipulation is terrible and I didn't pick IVs and natures for Turtwig and Machop. The Abra from trading has set IVs and nature so the initial RNG seed doesn't matter too much after the first gym.
Arkanoid
Pinball
Unowns 1+2
The Hey Listen text could probably be displayed in a different way.