Language…
11 users online: CONLUSH666, Darknubs,  Deeke, DrewV123, Fyre150, Humpty Dumpty Magazine,  icrawfish, mariogamer88, MrNapkino, SF - The Dark Warrior, Skewer - Guests: 54 - Bots: 202
Users: 58,121 (2,492 active)
Latest user: Hadgold

Lunar Magic suggestions and discussion (LM v2.52)

Link Thread Closed
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 143
  • 144
  • 145
Any chance of including this or something like it in Lunar Magic? It seems to break in the newest version anyway, and yes, I had the 2MB+ option unchecked. For advanced use, those tables could be placed at $07EA00 or something. (I wasn't even using the extra ExGFX files, just the layer swap option....)

Also, might you possibly include a list of all the data you used for sprite displays? It could be useful for some of the more complex ones (such as the rotating platforms) for people doing custom versions of them.

----------------

I'm working on a hack! Check it out here.
Something strange i found.
So I opened the Object Editor and selected the two tiles that make the top of a pipe.

Then I select a tile in the level


Then I close the Object Editor, and Shift+Ctrl+Right Click and this happens:



Was Lunar Magic set to have it where Shift+Ctrl+Right Click can work without the Object Editor open?
I do art commissions cheap! PM here or DM via Discord for more details.

**Layout by Erik557


Originally posted by imamelia
Any chance of including this or something like it in Lunar Magic?


Unlikely.

Originally posted by imamelia
Also, might you possibly include a list of all the data you used for sprite displays?


It doesn't currently exist in list form.

Originally posted by Ruberjig
Was Lunar Magic set to have it where Shift+Ctrl+Right Click can work without the Object Editor open?


Seems so. Doesn't really harm anything, but suppose it should be shut off to better match what the help file says.
Originally posted by FuSoYa
Originally posted by imamelia
Any chance of including this or something like it in Lunar Magic?


Unlikely.

Hm...how hard would it be to do some sort of VRAM customization for current versions? I'd think the patch would just need some read3() functions to work, but since it barely touches original SMW code at all, I don't even now what addresses I'd read. (Of course, it wouldn't be a problem if $2107-$210C had mirrors...would that be something worth adding to LM?)

Originally posted by FuSoYa
Originally posted by imamelia
Also, might you possibly include a list of all the data you used for sprite displays?


It doesn't currently exist in list form.

I see. How about binary data?

----------------

I'm working on a hack! Check it out here.
Originally posted by imamelia
(Of course, it wouldn't be a problem if $2107-$210C had mirrors...would that be something worth adding to LM?)


Probably not. I think that patch has been incompatible for about a year now, and no one's bothered to update it or mention it much.

Originally posted by imamelia
I see. How about binary data?


Doesn't exist beyond what you can already see in the Map 16 editor.
Hm...well, do you know if the code that you put in bank 1F previously has been altered in any way since version 1.91?

And why not let the VRAM routines use RAM addresses instead of hardcoded values? I see literally no reason this could not be done other than time.

----------------

I'm working on a hack! Check it out here.
Originally posted by imamelia
Hm...well, do you know if the code that you put in bank 1F previously has been altered in any way since version 1.91?


A patch in LM that modifies the tilemap VRAM location registers for levels... come on imamelia, you know enough to be able to guess what patch that is. #ab{:P} At worst, you could have just looked at LM's update list from a year ago. Or my own posts from exactly a year ago today.

Originally posted by imamelia
And why not let the VRAM routines use RAM addresses instead of hardcoded values? I see literally no reason this could not be done other than time.


You just answered your own question. And with the other things edit's patch does, it might not be enough. Plus as I just said:

Originally posted by FuSoYa
I think that patch has been incompatible for about a year now, and no one's bothered to update it or mention it much.
Originally posted by FuSoYa
A patch in LM that modifies the tilemap VRAM location registers for levels... come on imamelia, you know enough to be able to guess what patch that is. #ab{:P} At worst, you could have just looked at LM's update list from a year ago. Or my own posts from exactly a year ago today.

Well, assuming you're talking about smkdan's VRAM patch, that's exactly the problem...that's what the patch hijacks, and I have no idea where any of the code is in Lunar Magic 2.22+. And I'm pretty sure it's not documented anywhere either.

Originally posted by FuSoYa
You just answered your own question. And with the other things edit's patch does, it might not be enough. Plus as I just said:

Originally posted by FuSoYa
I think that patch has been incompatible for about a year now, and no one's bothered to update it or mention it much.

Wouldn't you just have to replace some immediate values with RAM addresses? And yes, that wouldn't cover every function of edit1754's patch, but it would at least make it possible to use VRAM layouts other than the one layout that Lunar Magic actually supports. I've never used that patch either, but it is currently the only way to change the location of anything in VRAM during levels, aside from finding and hacking all the Lunar Magic hijacks and code yourself. (And you can't deny that more people would use such a patch if it were more compatible with Lunar Magic, especially if it were an option within the editor itself.)

This is why people get interested in homebrew...

----------------

I'm working on a hack! Check it out here.
Originally posted by imamelia
Well, assuming you're talking about smkdan's VRAM patch, that's exactly the problem...that's what the patch hijacks, and I have no idea where any of the code is in Lunar Magic 2.22+. And I'm pretty sure it's not documented anywhere either.


It's in the same default place it's always been. Provided the 2MB+ option is off of course, and that it was off before saving anything in your fresh ROM.

Originally posted by imamelia
Wouldn't you just have to replace some immediate values with RAM addresses?


Only if you like uninitialized RAM.

Originally posted by imamelia
(And you can't deny that more people would use such a patch if it were more compatible with Lunar Magic, especially if it were an option within the editor itself.)


Given what you sacrifice to get the extra GFX space in the patch, I'm not so sure of that.
From what I recall before FuSoYa, you said FG/BG Indexes weren't actual options hardcoded into the original smw.

Is there any specific reason for the FG/BG indexes?
Are they just there for keeping track of the original FG/BG combinations actually used in game?
Wouldn't it be a bit more constructive to have a drop-down for FG and BG seperately since they use different map16 pages anyway?

I was also wondering that since Lunar Magic now supports hiding/unhiding sprites and tilesets that will not have proper graphics for the current index; would it be possible to do the same for tileset specific objects. We can see all tileset specific sprites if we toggle them visible, but we can not do the same in the tileset specific object dialog to show all objects despite the FG/BG index. For example designers could use line guides or conveyor belts in the underground tileset albeit with very strange looking graphics without the necessity of having to switch to one of the rope FG/BG index and creating a map16 page for all the underground foreground tiles. It'd be a lot more intuative having the tileset specific object list function like the tileset spefic sprite list.

The tileset-specific objects actually use completely different code depending on the tileset. For instance, you can see that in tileset 0, objects 34, 35, and 36 are, respectively, a forest edge, a forest ledge, and a tree trunk, but in tileset 1, they are instead a double-ended pipe, a rock wall, and a large spike, while in tileset 2, they are red switch blocks, a plant on a column, and a rope conveyor, then in tileset 3, they are blue switch blocks, red switch blocks, and a 4-sided ground square. In fact, technically all of the non-extended objects are tileset-specific; the pointers for objects 01-21 just point to the same code.

----------------

I'm working on a hack! Check it out here.
Originally posted by Galactaknight
From what I recall before FuSoYa, you said FG/BG Indexes weren't actual options hardcoded into the original smw.


No, I said the T value (which you can see listed as part of each FG/BG Index entry) is not a real setting. The FG/BG Index setting itself is in fact part of the original game.

Originally posted by Galactaknight
I was also wondering that since Lunar Magic now supports hiding/unhiding sprites and tilesets that will not have proper graphics for the current index; would it be possible to do the same for tileset specific objects.


Nope, like imamelia said they're replaced with completely different objects in other tilesets.
My mistake but, would it still not be possible to store each tileset specific object in their own different universal act like setting that could be accessed through map16? Does the sprite index simply not rewrite the code as well; if not couldn't that be used as a means to apply the same principal to tileset specific objects? Wouldn't it be a matter of simply just ensuring the tileset specific object's code isn't rewritten to when changing FG/BG index similar to how it does so with sprites not found in the index? I suppose pointing and writing tileset specific objects at a new location where the code could always be located at would be changing the object engine too much wouldn't it.

I'm not entirely sure what you mean by that...objects don't have tables in RAM like sprites do, and they aren't loaded and unloaded; they are basically just pieces of code that run once when a level loads. You're thinking of making the objects go beyond 3F while making them non-tileset-specific? That would require changing the object engine, yes, which would break backward compatibility, which I don't think FuSoYa usually likes doing. Though if you really wanted to use a certain tileset-specific object in a tileset that doesn't have it available, I suppose you could make a custom object that does the same thing (perhaps making use of the pointers at $0DA455, $0DC19A, $0DCD9A, $0DD99A, and $0DE89A). It could even spawn custom tiles set to act and look like the originals if they also were not in the tileset.

----------------

I'm working on a hack! Check it out here.
Originally posted by Galactaknight
My mistake but, would it still not be possible to store each tileset specific object in their own different universal act like setting that could be accessed through map16?


Objects don't "act" like anything, so no.

Not sure if you're just explaining it badly or not, but don't confuse objects with Map16. Objects are simply code routines that place Map16 tile numbers in certain arrangements. After the object list has been parsed during level load, they might as well not even exist as far as the game engine is concerned. During gameplay the interaction is with tiles, not objects.

Originally posted by Galactaknight
Does the sprite index simply not rewrite the code as well; if not couldn't that be used as a means to apply the same principal to tileset specific objects? Wouldn't it be a matter of simply just ensuring the tileset specific object's code isn't rewritten to when changing FG/BG index similar to how it does so with sprites not found in the index? I suppose pointing and writing tileset specific objects at a new location where the code could always be located at would be changing the object engine too much wouldn't it.


Simply put, Nintendo did not set aside enough bits for the object ID field in the level format to be able to have all the objects available at all times. But even if they did, some of the Map16 tiles those objects place change their appearance for different tilesets. And even if they didn't, some of the tile gameplay behaviors also change for different tilesets. So just messing around with objects or the level format alone is not going to solve this.

You're probably better off just creating custom blocks of your own that will have the same behavior in all tilesets.
Hey Fusoya, is it possible to do Layer 3 ExAnimation?

Extras



I should have something witty to put here (even if it's just to update dated info), shouldn't I?

Advertising Space

Originally posted by Roberto zampari
Hey Fusoya, is it possible to do Layer 3 ExAnimation?



Yes and it's set up the same way as normal, only the destination tiles will be 1B00-1CFF.


I swear its like no one reads the help manual these days. :P

I do believe I ran into a glitch with the program though. In the most recent versions it seems that trying to place a ball and chain sprite in a vertical level can tend to make it jump to the opposite side of the screen in LM depending on where you try and drag it.
I'm not near my laptop at the moment, but if you need screen shots I'll be more than happy to provide them.
Layout by LDA during C3.
Minor Bug:
When using the zoom feature in the new "Add Object" window (probably in sprites window too, though untested), close LM and reopen it, when opening the dialog, the list containing all the objects will still be in small size. This can be fixxed by simple un- and reenabling zoom but I thought I'd point it out just for the sake of it.
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Originally posted by Lightvayne
I do believe I ran into a glitch with the program though. In the most recent versions it seems that trying to place a ball and chain sprite in a vertical level can tend to make it jump to the opposite side of the screen in LM depending on where you try and drag it.
I'm not near my laptop at the moment, but if you need screen shots I'll be more than happy to provide them.


That would help, along with a description for how to replicate it.

Originally posted by JackTheSpades
Minor Bug:
When using the zoom feature in the new "Add Object" window (probably in sprites window too, though untested), close LM and reopen it, when opening the dialog, the list containing all the objects will still be in small size. This can be fixxed by simple un- and reenabling zoom but I thought I'd point it out just for the sake of it.


That was fixed a few months ago in 2.31... still using 2.30?
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 143
  • 144
  • 145
Link Thread Closed