You have to be careful with those palettes though, they affect more things than you'd realize. I know, since I had to mess with them a while back. Think of that palette as the common sprite palette and then think about if you really want to messing around too heavily with them.
I'm trying to changer a PLM into a scroll pointer. I've tried editing the scroll blocks in the room, but SMILE says that it can't, and that perhaps the scroll pointer is 0000 or 0001, which it is. So, I'm guessing there's something specific I'd need to put in there, but how would I find it?
Scroll PLMs tell the game to treat certain screens differently than the preset behavior. I guess they would work with a 0000 or 0001 value, but I've never tried. The simple solution would be just to give that screen actual scroll data, even if every screen is to be shown... then you can edit it normally.
If scroll PLMs work with 0000/0001, Jathys might want to edit SMILE functionality to let you edit them in those rooms. Until then, you've gotta work with it as it is.
Yeah, the problem isn't the PLM at the moment, but the fact that the scroll editor itself won't let you change the colour of the scroll blocks, as it makes the aforementioned complaint. I'll have to use another room for now... Darn.
I found a new heat BG effect: Goto Fx1, set lava/acid and move the sideways scrollbar until C (tide and other settings) Check 'bg warp-line shift', NOT 'bg warp-cascade heat'. You'll get this:
For comparison this is the other heat effect:
w/o heat:
For more variations.
@ Quietus: I solved this problem by taking the scroll pointer of a 1x1 room and swiched it with your rooms scroll pointer. I suggest taking one of the item rooms.
Scroll PLMs work perfectly fin whether the room has a scroll pointer or not. The scroll pointer only determines what data is loaded into the room upon ENTRY to the room, and it doesn't make the scrolls stuck like that. Think of having scroll pointers of $0000 or $0001 exactly the same as if you had any other value in there. The only difference is that ALL the screens will be the same color.
If you want screens with different colors, you HAVE to change the scroll pointer to something else (free space in $8F; 1 byte per screen), but it won't make any difference to scroll PLMs.
The only difference is that ALL the screens will be the same color.
Yes, they're all blue, which makes hiding things impossible.
Could you give it the same scroll pointer as another room that has the correct scroll data you're after, or would it be better to just point to free space? In which case, which digits do you enter? (in both the hex editor, and SMILE's pointer box) I had a look in a hex editor, but searching for 'bank $8f' didn't appear anywhere obvious, unless it was just a rubbish editor...
Take a room with the exact same dimensions, set it scroll to be equal to the scroll value of the room you're using. Then you can just edit that scroll data, remember where you save the info to, and use those pointers in the other room.
Alright, so I FINALLY found out why the 2 rooms, 793FE and 794FD, won't resume after pausing the game. As it turns out, the BG Data pointer has become/is invalid for one reason or another. I found out by going to Background Editor>Edit Background, when SMILE through a Subscript out of Range "9" error and crashed. So I went in, changed the BG Pointer to 0000 just to check, and the game will resume play after it's paused.
Now, is there any specific reason as to why the 2 rooms randomly have this happen, or is it the fact that it's because they are also Scrolling Sky rooms? Anyways, all is well and hope this helps other people with the same issue as I did.
Embarrasing Fact: Power suit made by lowest bidder
I've had similar issues, but at that point I just disassembled the original BG_Data routines and reassembled them to my liking and to avoid crashing. And I'm not sure if I have a copy of the original code anywhere.... oops. The table for the routines when you unpause is at 82E9D5. I'm guessing you're using a patch to fix the sky scrolling; you'll have to modify the code at option E (pointer to that code is at 82E9E3) to use the new format properly too.
Alright, so I FINALLY found out why the 2 rooms, 793FE and 794FD, won't resume after pausing the game. As it turns out, the BG Data pointer has become/is invalid for one reason or another. I found out by going to Background Editor>Edit Background, when SMILE through a Subscript out of Range "9" error and crashed. So I went in, changed the BG Pointer to 0000 just to check, and the game will resume play after it's paused.
Oh, so it's the sky fix patch that may corrupt the start button? I tried to change the bg pointer to 0000 and as you said the start button issue was gone. However, the vomit was back so it didn't really help. What would be needed is an updated sky fix patch that won't crash the game in this way, or something like that. In the original game there's no vomit, but as soon as it's modified it shows up. I find that mighty strange and wonder what causes it.
And another thing: I've put a scroll PLM right above the ship because I need to switch some scroll areas immediately when loading to get the scrolls right. So this scroll changes 5 scroll areas. But when I set this scroll like this, the room next to landing site in the rom get's messed up and I get a runtime error in SMILE. What? Why? Nevermind, I worked around it. It's still strange though and could need an explanation.
I've not been able to get my sky scrolling patch to corrupt unpausing. Try redownloading it
Well, look at that. It worked like a charm, and it was so simple. Thx PJ.
Another question: (It never ends =)) The room 9a90 (chozo statue with a camera eye) is 1x1 and 28572 in size. I find this to be a huge waste so I wonder if I can without any trouble expand the room (in volume, not rom size) to for example 5x5? Will the byte size remain the same thus not corupting the rom? This room has two events and that's pretty nice.
You can always change room dimensions without changing the level data used. However, I wouldn't necessarily trust the counter for that room. SMILE determines how much space is left based on a text file in the files folder (level_entries.txt). It's not always right, because that's a user-compiled list. If you have a stupid amount of free space showing up, it's probably not safe to use more than the room already uses. Far wiser to just repoint the level data to free space, such as an expanded bank.
A quick look at that room shows that there is data stored immediately after the original $9B bytes the room uses. I don't know what that stuff is for or if it's important, but if you edit it, be aware that you're changing unknown stuff.
"When I try to edit the colors of the tiles in the Graphics Editor my changes don't show up int he game."
If that is correct then, go to the top of the graphics editor and there will be a tab where you can save the palette file I believe. If that isn't it then I'm sorry, I'll have to check SMILE in a little bit.
Hey all, I'm planning to add on an extra bank (or more) to the SM rom and point all the palette and tile table data there. So, I'm wondering... how big do they get? How much space do I need for each table and palette so I can change them without having to worry about overwriting the next one?
Also, I'm making a patch of this when it's done, if anyone wants it I could upload it.
There's a patch like that already. It's only for the first 15 tilesets though. But the ones after them are just Kraid's, Croc's and Draygon's rooms. And Ceres.
Wow. 13 extra banks, even using one that was already i the ROM. Well, I got an answer to my question at least. I guess I'll use the patch to save some time, and repoint the other stuff by myself.