Is there a bug with Lunar Magic's restore function and custom sprite Map16? I just tried to restore to a recent point because I accidentally saved to the wrong level (not that there was much in the overwritten one anyway, fortunately), and the sprite Map16 pages turned into...this. I have a copy of the ROM folder for reference.
You can already set a tooltip based on the extra bits. Doing it for extra bytes too would start getting a bit excessive, as currently you can already have up to a quarter of a million sprite tooltips because of x/y settings.
Personally, I'd much rather have tooltips based on extra bytes than XY position, considering the former makes the latter almost pointless. Perhaps there could be a boolean or table kind of command to change the text based on bit values? Something like this, maybe:
A sprite that's [0-1:red|blue|yellow|green], [2:walks|hops] on the ground, [3:falls off|stays on] ledges, and waits [4-7:#*16] frames to activate.
Originally posted by imamelia
None that I've ever heard of. Are you sure you didn't just end up with an older .ssc file that configured an area to use different external sprite GFX files than what you currently have? (remember restore points don't hold those external sprite GFX files)
Well, the restore point was only a short time before the current state, so the .ssc file wouldn't have changed much in that time. Unless there was an .ssc file from much longer ago somewhere? Should I just send you what I have?
Some of you might be familiar with my solid sprite routine, the most recent version of which can be found here. One of the features of it is the ability to detect specifically which side of a sprite the player is touching. Unfortunately, it doesn't work quite right, and it's possible to trigger more than one offset by touching a corner. For instance, if you stand on the top-left corner, you can trigger the flag for touching the left side even though it should only count as touching the top. This means that you can't use a simple AND to check for a specific bit because it can be set by the adjacent corners as well (so LDA $8A : AND #$04 : BNE .TouchedLeft doesn't work), but you also can't check if only that bit is set for the same reason (so LDA $8A : CMP #$04 : BEQ .TouchedLeft doesn't work). I've been trying to fix this and have not had any luck, so I'm posing it to the community.
I like it when other queer people make discoveries about themselves. I don't know how many months you've been gone...I assume you do know about Lunar Magic 3 already? Beyond that, the Mad Scientist ASM contest is pretty new.
It kind of depends on what you're after, honestly. I would say to take it one step at a time. Get familiar with how Lunar Magic works and make a few levels; then try inserting other things like ExGFX, blocks, sprites, and patches; then if you want, try making your own resources (which you have mentioned doing already). Make a short hack if you want, a longer one, or just design random levels until you feel like doing something else.
It makes it even harder to find friends, a job, and things to do out of the house, which were already difficult enough for me. And yeah, there's the constant worry of contracting a horrible disease (especially since my parents work at public schools). I'm definitely ready for it to be over, but I guess too many people aren't following safety guidelines.
My regular username, imamelia, comes from me mishearing a line from Mario Kart 64; Mario's "Mama mia!" quote was downsampled enough that it sounded like "I'm Amelia!". I used that on GameStop, the first online forum I ever registered at, and kept it when I registered here a few months later. I usually use different holiday usernames every year, but this one comes from a villain in the second Trails in the Sky game whose nickname is "The Angel of Slaughter" and whose title is Enforcer No. XV (further details would probably be spoilers).
As for my profile picture, I actually haven't had one for probably the majority of my time here, nor have I had a layout. I want one, but I can never think of ideas for them that are both practical and nice-looking (and I can't code them myself anyway). I chose this one when I was looking through my picture folder and wondered why I hadn't just done this before (answer: because I thought it would be weird to have an avatar but no layout). The picture is of Estelle Bright, also from Trails in the Sky.
The few multiplayer games that I like I can rarely play because I almost never have any other people around to play them with. Keep Talking and Nobody Explodes, Worms, and any of the Tales games come to mind.
I kind of want to put Octopath Traveler on here, too? I wouldn't say that I can't play it, exactly, but I have gotten stuck a lot in that game. Currently, it's on an indefinite hiatus because I came to a boss in chapter 3 that I couldn't figure out a reasonable way to beat, decided to do sidequests first, and have been having trouble figuring out those even with a guide from GameFAQs that I printed out. Presumably, I will eventually finish the game at some point, but who knows.
Well, if Lunar Magic's help file doesn't already say which unsed ROM areas it puts stuff in, it would be a handy thing to list. The hijack map already has some of that info, but having all of the chunks listed would be nice. I might put more code and data there myself, and I don't want to overwrite any LM code or have it overwrite mine. I suppose I do still have cleared level data to use, though, as well as some other things I rarely use and could overwrite like the vanilla backgrounds and credits.
Boo on the custom object stuff. I'll still use them anyway, but...you do realize that the newest version of ObjecTool does come with premade objects, right? The only thing the end user needs to do for those is specify the Map16 tiles (and some other parameters for a few of them).
If I have to choose between changing sprite display data based on X/Y position or extra bytes, I'd take the extra bytes every time. Now that extra bytes exist, there is no reason that any custom sprite should change based on X/Y position anyway, so it's really only useful for normal sprites. Making it possible for Lunar Magic to detect is a good idea, but how will it tell which bits are relevant to the appearance? If the palette of a sprite changes based on bits 5-7 of the first extra byte, I assume that I'd put a 00, 20, 40, 60, etc. somewhere instead of 00, 01, 02? If it has 2 extra bytes and uses the second one as a tilemap/palette index, would it be 0000, 0100, 0200?
Yeah, I thought that comment was baffling, too. When I'm making a hack, I almost never change my ExGFX file numbers. Such a feature wouldn't be useful for me anyway because I use spritesets, but still...
Also, can we get a shortcut to copy a palette from one level to another like you can do with the background? Unless I'm missing something, that currently involves either saving it to a file or copying it one row at a time.
As I just described, it would only use the lower bits of the byte you specify, up to the full byte for a max of 0x100 appearances/tooltips per sprite. LM could figure out how many of the bits are relevant just by looking at all the values you give it for that byte.
All right. It would take some bit rearranging for a lot of sprites, but that shouldn't be too much of a problem on the ASM side. (Changing their data in the editor, on the other hand...)
By the way, have you given any more thought to integrating this into Lunar Magic? I picked the default RAM addresses with that in mind, and it seems like something that could have enough general-use cases to include (like how Lunar Magic gives you a GFX decompression routine to use).
There seems to be a bug with .dsc file parsing. Specifically, custom tooltips and block contents work only if the acts-like setting is 0-1FF. If it's outside of that range, the sprite tile won't show up at all, and the block will use the tooltip for whatever block it's acting like if there is one. For instance, if tile 3B0 is set to act like 206 and 206 is set to act like 130, 3B0 will use the tooltip from 206, but if 206 doesn't have a custom tooltip, then 3B0 will use the tooltip from tile 130.
Sounds like it's working as intended then. If you make a block act like another one, you'll get the block contents and the tooltip for the block that you're acting like. If you chain them and the last custom block (above 1FF) in the chain has no tooltip/content setting, you'll get the settings of the original game tile it's set to act like (at or below 1FF).
So there's no way to set the tooltip and contents based on the Map16 number? Dang it.
Is there a way for a custom block to check its Map16 tile number? Not the acts-like setting, the actual tile number, which is not stored in $03 as the RAM map incorrectly says it is. I know that it's loaded somewhere when processing block code in order to get the acts-like setting, so where do I find it?
Also, on the subject of additions to .ssc files, would it be feasible to support PIXI's per-level sprites as well?
In this case, you probably want to use JML rather than JSL. That way, instead of two RTLs, you can have the different parts of the code end with JML, but the two JMLs can go to different places.
If you really do want to change the return address, though, you can use stack-relative addressing, which is signified by an 8-bit value with ",s" after it. $00,s points to the next byte on the stack, while $01,s points to the last byte that was pushed, $02,s is the one that was pushed before that, and so on. JSR and JSL push a 2- or 3-byte return address to the stack, which is the address of the next byte minus 1, starting with the highest byte. For instance, if you have a JSR at $209000, the JSR will take up 3 bytes, so the code will return to $209003, but the address that gets pushed to the stack will be $9002, first the $90 and then the $02. If you wanted to make the code return 5 bytes later, you could do this:
Or if you wanted to make it return to a specific address, say $209010, you could do this:
LDA #$0F ; remember to subtract 1
JSL works much the same way, except that it pushes 3 bytes, first the bank byte, then the high byte, then the low byte. So if you had a JSL at $209000 instead, then it would take up 4 bytes, return to $209004, and push the bytes $20, $90, and $03 to the stack in that order. Of course, you could use 16-bit mode for both of these code examples as well, enabling it with REP #$20 and adding or storing two bytes at once.
JML goes to the exact address. So do JSR and JSL; it's only the pushed return address that's a byte off. What most likely happened here is that the data bank was incorrect. The data bank is the implied bank byte of a 16-bit address; for instance, LDA $8000 while the data bank is $10 would load from $108000, no matter what bank the code was actually running in. Generally, labels imply 16-bit addresses. In your code, you're jumping from bank 05 to an unknown address in the expanded portion of the ROM, but the data bank is still 05, so your LDA .Table,y is actually loading data from the corresponding address in bank 05 rather than where the custom table is. For instance, if your code ended up in bank 10 and the table was at $10A987, you'd actually be loading from $05A987 instead.
There are a couple ways to fix this; normally, if you're just doing a single load as you are here, you'd use long addressing by putting .l after the address, which will force it to be assembled as the full 24-bit address (in this example, LDA $10A987,y). Unfortunately, there are no opcodes for 24-bit Y-indexed addresses; 16-bit ones can be indexed by either X or Y (LDA $A987,y or LDA $A987,x), and 8-bit ones can only be indexed by X but can be made 16-bit by adding a leading 00 (LDA $D8,x or LDA $00D8,y), but 24-bit addresses can only be indexed by X. And you can't easily use X instead of Y here because X is already being used by a different part of the routine. So here, you need to change the data bank to make it equal to the bank where your code is running, like this:
LDA .table,Y ;until here, where we use custom table instead of vanilla
The PHB pushes the current data bank onto the stack. The PHK pushes the current program bank, which is not the same as the data bank; the program bank is where your code is currently running, so if you JML from bank 05 to bank 10, the program bank will automatically update to 10. Finally, PLB pulls the last byte off the stack and into the data bank. So what this did is put the current program bank onto the stack so that it can be restored after we change it, then PHK followed by PLB copies the program bank to the data bank (fun fact, PHK in code will have a PLB after it probably >90% of the time), then you load your value from the table (which will get the right data now that the data bank is correct), then the second PLB puts the program bank back to what it was before.