Originally posted by YakovAbout the Levels being in the same place as Objects/Sprites: true, it might look kinda awkward, but I want that you'll be able to see the level name along with its number. Should I make a separate dialog for that?
I think a separate dialog for the level list would be good. (It would only be needed when loading levels or making screen exits.)
Maybe if the level you're currently viewing contains a screen exit to another level, that level could show up differently on the list?
Also, I think it should be possible for users to create a file containing their own hack's level names (and possibly other things). (It could be like Lunar Magic and the music track names-- if you give the file the same name as the ROM, but with a different extension, the editor automatically loads the file, overriding the default level names. There could be an option in the editor for editing this custom level list.)
By the way, "level name" has two meanings. There needs to be a way to distinguish this type of level name from the level titles that appear when you select a map icon...
Originally posted by YakovFor the time being, I'm going to place restrictions per each block of whatever (e.g. message block 1 has X bytes, message block 2 has Y blocks).
So each message will be stored in the same bytes as the original message? This makes sense. (Anyway, it's likely that there are more pointers to the messages than I know of.)
By the way, if a message is edited to be shorter than it was originally, it should be safe to fill in the space after the end of the message (...FF 0F FF FF) with FFs.
Edit: Actually, since the pointers to the message blocks are known, as well as the entire structure of the messages, it could be possible to just add new messages in some other data...
I was asking about level data and sprite data. If you edit a level to use fewer bytes than the original level used, the FF FF FF FF (for sprite data) or object FF (for level data) will need to be moved earlier, as the game would otherwise interpret the remaining data as more objects/sprites.
There would then be an unused block of data.
What I'm wondering is, if you're looking to increase the level back to its former size (most people would probably delete the whole level initially, then gradually add objects/sprites), how will the editor detect that this space is not used for another purpose? I was thinking of filling in the unused block entirely with FFs, but it's possible that the next section of data might begin with FF (unlikely, but possible), and therefore be misinterpreted as part of the end of the data-- meaning if you change the next level and it no longer begins with FF, the previous level would have no end.
Originally posted by YakovAnd finally, since I don't know how to render graphics stored in the ROM, nor do I want to resort to EggVine's method of ugliness (AKA blocks with numbers), I'll probably be using images for that.
Image files containing the in-game graphics? Or just images with more detail than Eggvine's colored rectangles?
If you use images of the in-game graphics, make sure the graphics change when you change the tileset!
And could you also try to make it load the graphics with the correct palette in the header (when applicable)? (If you use in-game graphics with fixed palettes, it would probably make people biased toward making levels with those palettes.) You could test out the different palettes to find the colors, and manually store the colors somewhere in the editor. (At least until the palette offsets are found.) Then use some sort of image file (not sure what though) that can appear with varying palettes.
And about the graphics in the ROM, I have a feeling that they're stored somewhere near the end, in a way that has a direct correspondence between pixels and some number of bits. I've seen images made of hex values when scrolling through there.
---
Edit:
I just thought of an entirely different way to structure the editing:
Just add new levels, messages, etc. in the x400000+ range, and modify the pointers.
I do not think this a good way to structure the editor itself though. (Not to mention it would make the editor completely incompatible with the SNES version if it only worked this way.)
Maybe, once the details are worked out of how the editor will store changes in data length, I could make some kind of base hack that basically adds a lot more space for each level, message, and so on...
–=–=–=–=–=–=–
Advynia: a Yoshi's Island editor - Alyssa's Unlikely Trap demo 3