level height, screen x/y, camera x/y

[city41]

Going to dump findings here as I get them. To start, I am pretty positive that "screen y boundary" is a 16 bit value of the level's height in pixels.

Here is mushroom14,room0 (a sky high adventure), it's setting for screen y boundary is ff 03, which translates to 0x3ff -> 1023 pixels -> 63.9375 tiles.

When I change it to fe 03, this is what happens

bottom is the initial value, ff 03, and top is fe 03. If you look at the pattern in the wood, you can see the screen has shifted down by one pixel

when setting it to 00 04, the screen shifts up by one pixel

[city41]

this is a spreadsheet of level settings from all rooms from all e-reader levels

https://docs.google.com/spreadsheets/d/17H2ObLplKjXfYogNK5wYdjnUPAIc5IkqhfZW_5mdINk

"fixed screen center y" is interesting, as it's either 00 00, 10 80 or 10 81 in official levels. By playing around with these bytes I am seeing:

• if the second byte is 7f or lower, these two bytes seem to have no impact
• if the second byte is 80 or higher, it shoots the camera way up to the top of the level
• if the second byte is 80 or higher, then the first byte seems to control the x position of the camera

So far nothing about these bytes say "fixed screen center y" to me. I feel like the names that historically were given to these level settings bytes may have been guesses.

[city41]

camera min and max both seem to be related to when mario is travelling down.

camera min

camera min seems to be how far mario has to go downward before the camera will start following him. set it to a high value like ff and the camera will essentially stop following mario. he can go way down below the camera and not die.

camera max

if this is anything other than 00, it seems to lock the camera from ever going back down again, and instead if mario falls off the bottom of the screen, this value indicates how far he has to fall before he dies. so with the tall level flying leap example, if this is 00, mario can fall down the entire level. if it is 01 or higher, the camera will not follow mario, and instead him going off the bottom of the screen results in death.

worth noting none of the e-reader levels set camera max to anything other than 00. I could see setting it for say levels that have rising lava, or auto scroll vertically. So maybe this is part of the game engine that smb3 doesn't need, but the engine is more versatile? I haven't played smb3 in a while, I don't remember any levels that cause mario to die if he falls off the bottom of the camera, but they are quite common in NSMB.

[city41]

you can now set the height of a room in smaghetti. But when you change it from the default, a warning is shown that changing height is experimental.

That's because changing height still causes strange things that need to be figured out. One of the biggest ones is in taller rooms (say 5+ screens high), it seems high up objects either get ignored or get placed more than once.

[city41]

the gba bg layer in which the level objects reside is 512x512

so that explains why objects seem to get placed more than once in tall levels, as the map is just wrapping.

512px tall means 32 tiles tall, but A Sky-High Adventure's main room is 64 tiles tall. When you climb up to the very top of the level, then jump and go to the very bottom, the map updates as mario falls. So it seems there is something in a level that can enable it to be taller than 512px.

[city41]

I think in the end, this will be possible 🤞

[city41]

Smaghetti now allows room height to be set, capped off at a max of 63 tiles tall. It seems a sky high adventure does nothing special to handle the map wrapping. Instead, as long as a room is 64 tiles or less, the engine handles it just fine. 65 and greater, causes issues as the wrapping gets in the way.

I chose 63 just to have a slight buffer.

So in the end, rooms can still be quite massive. Honestly way too big considering smb3 has no check points :( with large rooms it becomes pretty easy to hit the max level size that can fit in a save file, but that's a problem for another day.

here is the largest a room can be

[city41]

ok the final mystery is moving mario. Currently it's possible to move him anywhere in the level. But the camera starts out not on him in the y direction, and it has to pan to him as the level starts. Once the pan finishes, it's all just fine. I believe player y screen center is the key to that, which ... makes sense. I haven't played with those values recently, but in the past I remember them being very unintuitive. But anyway, getting to the end of this tunnel 👍

[city41]

woohoo! this seems to work, I can't find a scenario where it doesn't. I think I'll move ahead with this and unmark moving mario as experimental.

[nintyalex]

Just one more thing... player y screen center must be less than or equal to camera min to prevent any panning issues as well.

[city41]

Ah ok. I'm still a little shaky on what it is doing. But I'm also a little shaky on what camera min does when it gets beyond 0x40-ish. I have a feeling these two will play a role in say allowing mario to start out at the very top of the viewport.

[nintyalex]

You're right. I tested your formula on those higher values (up to and including screen start y: playerY - playerY, camera min: 0x00), and they all worked perfectly.

[city41]

choosing playerY - 4 and 0x40 for screen start y and camera min is what caused this bug: #122

I've now fixed it by going with playerY - 7 and 0x70

Which is also what classic 1-2 uses, so in general sticking with what Nintendo did is usually safer :)

[city41]

A downside to the current camera solution is it really biases to above Mario. Recent levels that have been made end up where you can't see things just below Mario.

This was a known compromise, and I think the real solution is giving the user the ability to choose how the camera frames Mario. But since so many recent levels are affected by this, might bump it's priority up and tackle it sooner