More than one warp per screen

stevenshepherd

New member
I am always hesitant to post things in here because I understand that not every idiosyncratic thing can be included. But I think a lot of us would get use out of having more than one warp per screen. For example, and action/adventure/RPG town with more than one house on the screen that you want to walk in to, or you warp into a dungeon and want to have a warp on the first screen (thus there is a warp out tile on that screen and a warp to another room in the dungeon on that screen). Also allows for branching paths where the player chooses, say, door #1, #2, or #3
 

MrElephant

Member
I second this, and mentioned it in my other post. Towns just are not possible without having multiple warps, and you would think people would want this included (DW1 FF etc).
 

chronosv2

New member
This is something that's going to require a good bit of ASM to pull off. Technically it's possible with Text Groups and re-purposing some text boxes, but I'm not quite sure how one would go about doing it yet.
It could be technically implemented as a feature but that would require rewriting how the screen data is stored, so I think this is going to have to be a user-solved problem.
Edit: Just did some math in a spreadsheet. Even if you borrowed the "Warp out to Underworld" bit from the Screen Info dialog for all four screens, one row of screens is 48 bytes for 3 additional exits. Multiply that by 16 columns and you get 768 bytes, or 3 text boxes worth of data, used. Multiply that by 2 for underworld and you've used 1,536 bytes, or 6 text box areas, for your warps. And like I said, that doesn't even take into account overworld or underworld.
If you do want to have overworld/underworld toggles for each and you don't mind doing some binary math in your code you'll need another text box worth of data for the "Which map" flags. - Edit: Actually, not quite a full text box if you want to go squeezing out every last bit -- technically each of the 3 additional exits would be 3 bits, so you could squeeze 2 and 2/3rd screens into each byte: 00011122 23334445 55666777 888999AA ABBBCCCD DDEEEFFF = 6 bytes per row = 192 total bytes needed)
 

stevenshepherd

New member
Very interesting! I appreciate the thorough response and completely understand that there are hard limits in place that might make it impossible. We might just have to get creative with level design :)
 

chronosv2

New member
I don't think it'll be impossible, but a few more things need to be in place before it'll be reasonable, I think. As it stands now it'd be difficult but doable... I'm almost tempted to do it just to see if I can!
For one, you can make changes to the files the program outputs as long as you run the TestBat.bat program externally (and hold onto your changes in another file so that when you DO run that command to update the files you can restore it quickly).

Just as an example, though, in the code the editor creates you have npcText01.dat and npcText02.dat, each of which hold 256 text entries as you set in the text area.
In its simplest implementation, not using the overworld/underworld extra text box, I'd use Text506 through Text511 to store the information.
If the screen ID were between #$00 and #$55 I'd look up Text506, if it's between #$56 and #$AA I'd use the last byte of Text506 and 254 bytes of Text507, and if it's between #$AB and #$FF I'd look at the last 2 bytes of Text507 and all of Text508. If it's an underworld screen I'd do the same thing but with Text509, Text510 and Text511.
Of course, none of this takes into account each warp having its own warp in point. If you want each one to have its own warp in you'd need another 6 text fields worth of data.

So it'd be hard, but not impossible.

Basically, to add a feature we sacrifice another -- text space.
 

chronosv2

New member
Glad to shed some light on it. I'm sure there are other ways and other banks we could utilize to do it, but without an in-depth understanding of the way the memory is handled I wouldn't even begin to know where to put it and how to access it.
 

MrElephant

Member
The whole reason for creating towns is for talking to more characters, so I wouldn't think that would be a good method. We should wait until the rpg module comes out, and see what happens.
 

stevenshepherd

New member
Definitely! I am all for waiting until more stuff comes out with official solutions and features as opposed to hitting my head against the wall trying to force NESmaker it to do something in these early stages :) Lots of other things to work on, like tiles, sprites, story, etc.
 
Top Bottom