more than one warp tile per screen

Presumably it will be possible to have more than one warp tile per screen, with each going to a different location? For example, an RPG town where there are 3 buildings on one screen, each with a door.

It's possible. Those screen bytes are super valuable, though. But there might be ways to do it by sacrificing some other things that need screen bytes.

Ah ok good to know! In planning out my screens should I not count on this being a feature then?

We'll probably have x amount of screen variables that can be user defined. YOU could use them to set up warp triggers, and then write code that, if it sees that collision types, reads that byte to know where to go. Someone else may use it to define an additional object on the screen, or something having to do with a second player, or any number of things I can't even conceive of right now. But the idea is there would have to probably be some light coding required to make that work...otherwise, we'd have to make it a hardcoded thing, which would mean that what these byes functioned as could be variable based on needs of the user.

We're also working on what I'm calling "particular" bits. This is a bit hard to explain, but...for instance, in the collision data, there are only 4 bits used for each collision, which allows us to represent a full page of collision in a small space. However, they're all loaded into RAM as full bytes, meaning the first four bits of each collision byte is ALWAYS empty. What I'd like to do is use these to establish specificity in a user defined way. So, for instance, you could use them to determine which exit an exit tile is. As the game loads a screen, it starts with exitNum = 0. When it loads an exit tile, it puts exitNum in the first four bits, and then increases exitNum. So when it gets to the next one, it would be writing one in that extra bit space.

Then, when your player runs into an exit door, it reads the higher bits to know which exit door that is, and then that combined with your custom code (explained in previous post) would let it know which screen data byte to use for what screen it should jump to.

Otherwise, you'd have to use multiple collision types just for exist...Door0 Door1 and Door2, for instance, which seems wasteful, though a LOT easier.

So these are the sorts of concepts we're kicking around.

cool thanks!

These particular bits sounds interesting. I doubt anyone would need more than 8 doors/map, let alone 16. Another thing you could do (a bad practice but it'd work if there's no other choice) is to fill up "warp tile"'s script with a huge ladder to determine x/y of tile and screen number and then warp appropriately. A lookup table would do too, though I don't know how you could put it there so it'd work.