why you get stuck on the same level for 800 lines

Transcript (I wrote this in notepad sorry about the incessant linebreaks)
NES tetris levels up when it shouldn't and doesn't level up when it should. Leveling up doesn't sound hard to get right, but let me
walk through the relevant code and show you what happened.
The code to check for level ups is pretty simple. First, it checks if the lines cleared is a multiple of 10. It adds lines one at a time so it never
misses one - no bugs here. Next, it checks if the line count is more than 10 times the level. This is where everything falls apart.
Here's what the code does. It divides the current line count by 10, and then compares it to the current level. Sounds fine until I show you the
actual numbers it's manipulating; there's a conflict in the data format. I'm going to write out the numbers in hexadecimal as they appear in memory,
and the reason you level up at 100 lines should be quite apparent. The line count truncated to its upper 2 digits is a larger number than the level.
The level, as you can see, is directly stored as its binary representation, but the line count is stored such that when it is read as hexadecimal, it
appears to be in base 10. This is handy for on-screen processing, and they could have easily avoided this error with a bit of extra code, but they did not.
Essentially to see if a level-up should happen, write the current level in hexadecimal, and see if it's smaller than the upper 2 digits of the line count.
If it is, then it will level up. So for example, on a 29 start, we transition at 200 lines, because level 29 written in hex is 1D, which is greater than
19 but less than 20.
Now let me tell you why sometimes there's no level up when there should be one. From an 18 start, level 235 will last for an incredible 800 lines.
Let me show you what that looks like in the calculations. Firstly, the line you would transition to level 236 is 2300. Something I haven't mentioned
yet is that the top digit of the line count is actual normal binary, so in memory that looks like 1700, truncate to 70. The level is stored in memory
as EB. Well, EB is greater than 70 so clearly a levelup is supposed to happen, right? Nope. The way the numbers are compared is by saying, if I were
to subtract one number from the other, would the result be positive or negative? Now because we're working in bytes, positive/negative is distinguished
by 00-7F being positive and 80-FF being negative. So let's do the math. If we rewind to 2290 lines, we get EA-69. This comes out to 81, a negative num.
EB-70 is not negative. It's 7B, a very high positive number. The game won't level up. And this will go on, because if we look at the next time it should
level, we get EB-71. We're subtracting a bigger number, so it's not going to be negative either, it's moving down to 7A. We have to go all the way out to
3100 lines. In memory, that's going to be EB-F0. That's negative 5. Finally, we move forward to level 236.
You might be wondering why it desyncs in the first place, which just comes back to the mixed formats. When you clear 10 lines,
your level and truncated lines both increase by 1. But when you cross any 100 line barrier, the truncated lines increases by 7, because it goes
from 9 to 0. That's skipping over A,B,C,D,E, and F in hexadecimal. The level doesn't do that, so you essentially desync by 6 for every 100 lines. If you
do 128 divided by 6 you'll see the result rounds up to 22, corresponding to the 2200 lines it takes to hit the superlevel from 0. Now because different
start levels result in different line counts corresponding to each level, that means that the exact point you hit the superlevel depends on when you started; a 0
start hits 200 lines and is comparing 20 to 14, whereas an 18 start hits 200 lines and is comparing 20 to 1A. Starting at higher and higher levels pushes
it further and further away, but you should note that the delay before first transition is actually the same thing as the superlevel, you just start midway
through it instead of at the beginning, unless you start on level 127 where you really do experience the full 800 before moving to 128.

[@Fleetato]

thank you I was wondering why I get stuck for 800 lines at 235 all the time !

[@Casually_Sleeping]

Urhm... Actually, it's impossible to get to 235 🤓

[@helenbooth5109]

​@@Casually_Sleeping bro shut up

[@Casually_Sleeping]

@@helenbooth5109 no 🤓

[@j_b_04]

@@Casually_Sleeping​​⁠​⁠ummh actually you’re wrong Stackrabbit got to 237. The killscreen isn’t always at the same level. While Blue Scooty got the screen on 157 this doesn’t mean 157 is the maximum. I recommend you do some research before claiming something to be impossible. I’m not 100% sure but I believe Blue Scooty didn’t even get the first possible killscreen

[@Casually_Sleeping]

​@@j_b_04 that video was at beyond human-like comprehensions. (Not possible by human ☺︎) and was done by an AI that tried it's best not to crash. And the best we have so far is 157. So if he got to level 235 then he would've done a recording to set a world record immediatley. So he's joking. Therefore, it's impossible to get to level 235. Edit: it's been two months and I just realized that bro said "Blue Scooty" 💀💀💀

[@LadyArtemis2012]

This is one of the things that I love about old video games. I love how developers who are trying to get the most they possibly can out of very limited memory and processing capability come up with creative ways of accomplishing that. And I especially love seeing when those things start acting in completely unexpected ways. The generation 1 pokemon games are an absolute goldmine of these kind of issues and I love them so much for it.

[@Lylcaruis]

its sad that no one has to do this anymore, if people still optimized you could run every game at max settings on a 3060 or something

[@LadyArtemis2012]

@@Lylcaruis I mean, let's be frank. This is not "optimized". After all, my entire point was about the interesting bugs and glitches that occur. Optimizing games has never really happened because it just isn't cost efficient. Every month you spend developing a game to improve its code is a month you aren't making money from sales of that game. The primary goal of game development isn't optimization, it's finding a solution that is "good enough". If anything has changed, it's the ability of developers to patch games after they release and how that has impacted the criteria for "good enough".

[@Lylcaruis]

@@LadyArtemis2012 I mean they were forced to cut corners due to hardware limitations which is somewhat similar but yea it isn't really the same thing

[@SioxerNikita]

​@@LylcaruisAlso, graphical rendering today in the game engines are very well optimized, actually. When games aren't optimized it is usually the internal mechanical code... Graphics are just that intensive if you want it to look good

[@Lylcaruis]

sometimes code can have a big effect on performance, there are ps2 games that still look good and run well on its respective hardware, also games like sonic unleashed have very unoptimized graphics, dont forget that, and that ran on a ps3, which came out in 2006, and it still looks great today@@SioxerNikita

[@chrisrasmussen2938]

At 2:39 you begin to understand that you are lost. At 2:46 you realize he's teaching you rocket science.

[@bitti1975]

It's not, it's just modular arithmetic (although I agree he could explain it better). E.g. 5 o'clock minus 7 hours is 10 o'clock, but you can equally interpret it as -2 o'clock because it takes 2 hours to get to 0 o'clock (aka 12 o'clock). The difference for 8-bit computers is that they roll over at 2^8=256 instead of 12. So EB-F0=FB=-5 (or in decimal: 235-240=251=-5).

[@chrisrasmussen2938]

I was more or less trying to make a funny as he was drawing a rocket.

[@bitti1975]

@@chrisrasmussen2938 I see. You've a vivid imagination..

[@epicow_1973]

​@@bitti1975honestly he shouldve given this explanation.

[@DB-YGO]

My brain is far too potato to understand any of this

[@near5148]

I understand it quite well

[@DB-YGO]

@@near5148 Congratulations

[@tropicalpalmtree]

Same. Blows my mind and this tech is 40 years old. Computer programming is insane to me and its hard to believe what humans can create. I can't fathom what a modern console/computer is doing constantly.

[@cuf_]

​@@tropicalpalmtreeyeah like a rtx 4090 is doing absolute miracles in a pc think about how that thing does raytracing for example? It needs to recreate light in its "head" and calculate the trajectories and how the light bounces using some tiny pices of silicon and copper.

[@oosha2000]

Same

[@raffimolero64]

I know this video is 1 year old, but I'm often confused in this video and want to help explain. It's the lack of base conversion or notation. I sometimes don't know when a number is written in base 10 (decimal) or 16 (hexadecimal). There are also not enough examples to explain new concepts. We have to have keen ears to understand what is said word-by-word. For example, when he says "The level written in hex is compared to the top 2 digits of the line count" there are not enough examples. I could provide 2 or 3 examples of converting between "line number as displayed" to "line number as represented in hex" and "line number as converted to decimal": as displayed: "123" as represented: 0x123 as converted to decimal: 1*16^2 + 2*16 + 3 = 291 adding quotes and the 0x notation are important for readability. as displayed: "999" as represented: 0x999 as decimal: 2457 In hexadecimal, numbers go from 0, 1, 2, 3, 4, 5, 6, 7 8, 9, A, B, C, D, E, F, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20, 21, 22, and so on. Let's see what the game does to keep the numbers in decimal. *[The following might not actually be what happens. There is at least 1 other way to implement this.]* 0x89 is actually 137 in base 10. Adding 1 gives us 138, or 0x8A. But that's now how decimal works! So it pretends to add in decimal. When it sees an A, it zeroes that digit, making 0x80, then tries to add to the next digit: 0x80 + 0x10 is 0x90. That is how it goes from "89" to "90". What about hundreds? 0x399 is actually 921 in base 10. Adding 1 gives us 922, or 0x39A. That's an A! It zeroes that digit, making 0x390, then tries to add to the next digit: 0x390 + 0x10 is 0x3A0. That's another A! It zeroes that digit, making 0x300, then tries to add to the next digit: 0x300 + 0x100 is 0x400. That's how it can go from "399" to "400". What about thousands? 0x999. I won't convert to base 10. Just know that adding 1 makes it 0x99A. Zero the first, 0x990. Add 0x10. 0x9A0. Zero the second, 0x900. Add 0x100. 0xA00. That's another A, right? But the game only displays 3 digits. It doesn't expect the player to reach past 999 and doesn't bother to check the third. So it counts A00, A01, A02, and the first 2 digits continue on in decimal as normal, until it hits A99, at which point adding 1 gives B00. When deciding to level up, the line counter is divided by 0x10 in *hexadecimal*, which basically just takes out the first digit the same way dividing by 10 in base 10 does. Say you were at "120" lines. It's stored as 0x120 hex. 0x120 / 0x10 = 0x12 written in decimal, that would be: 288 / 16 = 18 The math checks out. All three numbers map to each other perfectly. More importantly, 120 lines doesn't give us 12 in decimal. It gives us 0x12, which is 18. To level up from 29, you're supposed to reach 290 lines. But you need not 190, not 290, but 200 lines. At 1:17, he says this is because "1D ... is greater than 19 but less than 20." But this is never illustrated. The best way to illustrate would be to start counting in hexadecimal and decimal at the same time: 0x16 = 22 in decimal. 0x17 = 23 0x18 = 24 0x19 = 25 (This is what happens after the line counter converts "190 lines" to hex and divides by 0x10; it results in 0x19 and is actually the number 25 in memory.) 0x1A = 26 (The line counter never reaches this number as it pretends to be decimal. It would never allow any of the letter digits ABCDEF.) 0x1B = 27 0x1C = 28 0x1D = 29 (This is our level, which the counter just stores directly as 29.) 0x1E = 30 0x1F = 31 0x20 = 32 (This is the result of converting "200 lines" to hex and dividing by 0x10. As you can see, 32 > 29. Therefore 0x20 > 0x1D. Therefore 0x20 > 29 decimal.) 0x21 = 33 0x22 = 34 0x23 = 35 0x24 = 36 0x25 = 37 0x26 = 38 0x27 = 39 0x28 = 40 0x29 = 41 (The result of converting "290 lines" to hex and dividing by 0x10. 41 is Way past the mark.) Furthermore, at 1:45, you say "The top digit of the line count is stored in normal binary" but we can't actually see the binary representation nor can we see how 2300 maps to 1700 or vice versa. Turns out it's really every digit after the smallest 2. So hundreds and thousands and beyond are in hex. He uses 0x1700 as an example. This is the raw number from the line count. Remember: the right 2 digits are pretending to be decimal, while the left ones stay hex. Basically, think of 1700 as (0x17 * 100 decimal) + (00 decimal). 0x17 is 23 decimal, times 100 is 2300, + 00 is still 2300. At 2:07 he says that 0x00-0x7F are positive, 0x80-0xFF are negative. going from 0x00 to 0xFF, you count in binary from 0b00000000 to 0b11111111. 0x7F in binary is exactly 0b01111111, the largest number that starts with a 0 in 8 bit binary. This is 127 decimal. 0x80 is exactly 0b10000000. The top bit is 1, so it's considered negative. Anything larger than that will still have a 1 for its top bit all the way to 0xFF, or 0b11111111, or 255 decimal, or negative one. Basically, if the second hex digit is 8 or larger, like 0x80 or 0x92 or 0xA3 or whatever, it's negative. 0 - 1 gives you 255 because of wraparound. 255 + 1 gives you 0. So, 255 must equal -1. 254 is -2, 253 is -3, all the way to 128 which is -128. I don't understand why he used 0xEA - 0x69 = 0x81 as an example. I could also say 0xEA - 0x68 = 0x82, which is also negative. Maybe it's because he'd been levelling every 10 lines for the past couple levels? As for 0xEB - 0xF0 = 0xFB, the smallest number that would result in a negative would actually be 0xEB - 0xEC = 0xFF, but you'd need a line counter of 0x1EC0, and the second digit skips over ABCDEF, so that's why you use the next best, which is 0x1F00. The previous possible line count is 0x1E99. 0xEB - 0xE9 = 0x02, positive. These stuff could be visualized better, but unfortunately just like the original video, it takes time to plan out how to explain these concepts to the layman.

[@Borgathan]

Extremely underrated commment. I'm comp sci and I was having a hard time wrapping my head around what he was saying because of some of these ambiguities. I understand hex -> decimal conversions than your average layperson but I've never been skilled enough at mental math to follow along like you'd need to for this video. If I sat down and solved the conversions maybe it would've helped me but luckily you did that for me :) I think not painstakingly explaining how to convert hex to decimal is totally fine but he needed to provide clarifying examples and clearly notate as you did. Its unfortunate because I really like this style of video and think the execution was good otherwise.

[@bettloserspielanfanger7051]

Thank u for this comment it realy helped me unterstand the video. Even as Someone without any wnowledge on the field. Great work

[@Kalaphant]

Super helpful comment. So, from my understanding of why 0x1F00 specifically: It needs 0xEB - 0xF0, and the 0xF0 comes from 0x1F00. And that is actually 0x1F * Dec100 (0x1F is Decimal 31; 31*100=3100, so you beat it at 3100 lines). At 3,000 lines, it's 0x1E * 100, and 0xEB - 0x1E is positive. The main question I have is, what do you mean by "and the second digit skips over ABCDEF, so that's why you use the next best"? You say "you'd need a line counter of 0x1EC0". Is this full hex? That'd be over 7K lines, but then 1F00 would be 7.9K. Is it the 0xEC * 100 thing? That would be 2,360 lines, which is actually what you're supposed to need. I just did this on Level 0 start, where the long Level is 219, and it seems to work by using 0xDB - 0xE0, which is the same as 0xEB - 0xF0 (-5).

[@pREpArE5311]

“Mom can i play tetris” “No! Go study for your maths” Him:

[@eflat7_]

Skill issue is CRAZY ☠i love nestris guy

[@wiirambo7437]

Sure it will take only a few months before Fractal or Eric can casually play 810 lines of charcoal on killscreen speed...

[@LilHana]

@@wiirambo7437have i got news for you

[@justinsi1097]

Dude you are literally too smart

[@saarhamelech7092]

and now its reached HUMANLY!

[@rogersasanka3408]

One must imagine Sisyphus happy.

[@NinthSettler]

This will be brutal when tetris pros get this good

[@GordonFreemanFan349]

Already done. Check Alex t. He even beat this level

[@brinleyhamer729]

@@GordonFreemanFan349 not in a real run

[@Human0987]

I will call this the Acid Demon Level, Pure Green Hell

[@Hekza0024]

hey

[@Kalaphant]

I've been curious about this for little while

[@_lightless]

Vi hart but code

[@Kalaphant]

1:00 Wait, so it's comparing Decimal 15 to Hex 10? Because Hex 10 is 16, and 15

[@victoriamitchell413]

Now do the levels from hell( Levels 249-255) And why you can simply crash the game at those levels by placing a piece

[@hydrantdude3642]

The scoring code runs whether or not you clear a line. It crashes for the same reason as the earlier levels, it just takes a lot longer because the math of adding 0 over and over is much less time consuming than adding 40/100/300/1200.

[@victoriamitchell413]

@hydrantdude3642 Okay I get your point But then why don't Any line clears crash the game Is it because it's always a multiple of the frames to the calculation Unless it is a singular piece

[@hydrantdude3642]

@@victoriamitchell413 the game crashes when the switch routine is interrupted. if the scoring takes so long that the switch routine doesn't even happen before the interrupt, no crash happens. each amount of lines cleared, including no lines cleared, has its own window of levels where it triggers the crash.

[@victoriamitchell413]

@@hydrantdude3642 oh ok

[@tcscomment]

wait, Tetris devs implemented software BCD?

[@QUASAR098]

very well made! maybe redo nes terris but with bugs fixed?

[@codetaku]

But that would make the challenge to hit level 0 so much less interesting

[@QUASAR098]

@@codetaku this post was made prior to my knowledge about the journey to level 255

[@andrewqi6695]

thats tetris GYM basically

[@kowx8649]

@@andrewqi6695 I guess you've known 810 isn't patched in Gym?

[@andrewqi6695]

@@kowx8649 yeah there was a version on gym without glitched colors or the 810 line level but they were not released because players wanted the bugs

[@Lefty7788tinkatolli]

Not to mention, level 235 on an 18 start is CHARCOAL.

[@whyaminamedthis]

nah bro its greeeeeeeeeeeen+ u be talkin bout a different level start

[@nathanpatty6020]

@@whyaminamedthis not exactly. between levels 164-179, a level desync happens where the game will level up but it will stay behind a level visually. So If you're on level 165, it will display level 164. Because the level before the green level is charcoal, that is what is displayed for the 800 lines level. On gym however, this desync is fixed, so the green color palette is used.

[@whyaminamedthis]

@@nathanpatty6020 oh fr? i didnt know my bad

[@potatopotato6704]

...wait why does J look like that

[@hydrantdude3642]

from an 18 start the long level glitch also happens on a level where the color glitch makes J pieces completely black except for the shines.

[@renakunisaki]

skill issue

[@aptiveviennapro]

What about a Lvl 0 start? Does the 810 line thing also happens ay Lvl 235?

[@CrimsonDevil_Rias]

No. A TAS of NES Tetris for the fastest 255 levels by someone named quad8 shows that the 810 lines level is Level 219 when starting at Level 00. The 810 lines level is chosen at random every time you choose a different level to start on. Normally the greatest players start at Level 18. As a result, they are expected to run into a 810 line level at Level 235 (but due to a level desync in an unmodified cartridge/ROM, the color palette doesn't update to dark green and instead remains at Charcoal).

[@aptiveviennapro]

Oh ok

[@LavaCreeperPeople]

wow

[@FrosstKatt]

Can you explain this in tf2 terms

[@urkerab]

That's what happens when you do a signed comparison of unsigned numbers on a processor which can't actually do true signed comparison in the first place...

[@tcscomment]

what are you comparing then?

[@skylerdale5351]

i’m lost but i’m not sure why. i thiiiiink it’s because i don’t know what the expected behavior is supposed to be. doesn’t tetris level up once every 10 lines? how do you get to level 15 with only 100 lines??

[@hydrantdude3642]

you start on level 15

[@natnew32]

Expected behavior is "if (lines cleared / 10) > level, move to next level" It only checks this once every multiple of 10 line is cleared though. Which is good because the calculation is bugged. "lines cleared" isn't stored as hexadecimal- instead a weird hybrid of both decimal and hexadecimal, where the base 10 decimal digits... are read as hexadecimal digits. For example, "513" in base 10, should be represented as 0x201, but it's stored as 0x513, which is 1299 in decimal. The game does not fix this when doing the check above. The difference between "what the game reads the value is" and "what the value ACTUALLY is" grows with time. Oh yeah, there's more. this actually only applies to the ones and tens digit, because clearing 1000 lines wasn't accounted for. Decimal 999 -> 0x999, Decimal 1000 -> 0xA00. Whatever. That's not really an issue usually. Keyword, usually. OK, so say we survive far enough until level 235. The game now does the check. Now I actually simplified things earlier: what it REALLY does is "is (level - (lines cleared / 10) < 0)?" Which, generally, is actually better than the previous because it can deal with rollover. But there's a catch: the result is 8-bit signed. clearing level 234 requires 2290 line clears. Internally it's line 0xEC, with 1690 line clears. The leading 1 gets truncated because it wasn't supposed to be needed, so it's read as 0x690. (Somehow we've ended up with, in decimal, 1050 lines cleared...) Whatever, 0xEC - 0x69 = 0x83. This is decimal -125, so we're good; we make it to level 235. 10 lines later, we're at level 235 and 2300 clears. line 0xED as expected, line clears is 1700, truncated to 0x700. 0xED - 0x70 = 0x7D, translating to decimal 125. This is not a negative number, so the game thinks "(lines cleared / 10) IS NOT > level", and it keeps going. What about 2310 line clears? Let's skill the hullabaloo; 0xED - 0x71 = 0x7C, decimal 124. Still not negative. 2320 lines? 0xED - 0x72 = 0x7B, Decimal 123. Nope, keep going. 2330 lines? 0xED - 0x73 = 0x7A, Decimal 122. Still not negative. As you would expect, this won't be negative for a very, very long time...

[@naumbtothepaine0]

@@hydrantdude3642wait you can start on a specific level not just level 1?

[@thebestthingbeforeslicedbr8562]

​@@naumbtothepaine0 yeah, that's why Tetris tournaments take like 15 minutes, not hours.

[@thebestthingbeforeslicedbr8562]

@@natnew32 I get most of it, but why is the "catch" that it's a sixteen bit signed integer? Isn't it an 8-bit signed integer? I mean, for the calculation to work, it obviously has to be signed, and we aren't even coming close to the maximum or minimum values. The way you explained it, it seems like the only problem is that 83 is seen as negative, but 83 as a 16-bit signed integer is 131, not -125. As an 8-bit signed integer, it is -125, as expected. So was that a slip-up mistaking 16 for 8, or am I just not getting something?

[@kellyfreas]

Oh.

[@ahuachapan2]

Patch it. You will be a hero for Tetris community.