Language…
16 users online: anonimzwx,  BeeKaay, codfish1002, DanMario24YT, Domokun007,  Eevee, HaruMKT, hhuxy, Knight of Time, margot, nonamelol1, Pizzagamer9791,  Ringo, ShoopDaWhoop, SysDataSoft, VLSkoot - Guests: 287 - Bots: 321
Users: 64,795 (2,375 active)
Latest user: mathew

Lunar Magic suggestions and discussion (LM v2.52)

Link Thread Closed
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 143
  • 144
  • 145
Originally posted by imamelia
Shoudn't there be one more step, like using a batch file or something?

Yes, there is. But double clicking on a batch file takes no more than one second unless your fingers are old and slow.

Quote
Not to mention I haven't the slightest idea where to get said headers.

This was solved over IRC (but now he's got some other problems, which I didn't have when setting up the build environment).

Quote
Not using headered ROMs means people won't have an editor for hacking at all.

What's wrong with xkas?
Code
%sprptr($105, Level105Spr)
%levptr($105, Level105Obj)
%shead($105, 5, 11, 0, 0, 0, 0, 2, 2, 0, 0, 0, 0)
Level105Obj:
%phead(1, 0, 2, 0, 0, 0, 8, 0, 0, 0, 0, 0, 7)
%obj(0, 24, 4, 2, $14)
%obj(5, 21, 3, 5, $14)
%obj(9, 18, 2, 8, $14)
%obj(4, 21, 11, 2, $13)
%obj(8, 18, 11, 2, $13)
%obj(12, 18, 5, 8, $13)
%obj(5, 24, 4, 2, $3F)
db $FF

Level105Spr:
db $04
%spr(10, 14, 0, $B9)
db $FF


Quote
I know his editor is supposed to support headerless ROMs

Correct, and he said that it most likely won't support headered ROMs either.
That makes two tools that won't open headered ROMs. Maybe we could offer p4edit (or whatever it's called) to people who doesn't want headers and LM for people who wants headers? All header haters are smart enough to add headers when needed, and we can add a huge warning saying "FOR EXPERTS ONLY" on p4edit.
<blm> zsnes users are the flatearthers of emulation
If it counts for anything my editor is taking quiet a bit of time and thus I have made a wrapper for LM in the mean time. But before I release that fully I will take a crack at running LM in a debugger and patching LM directly which would be even better.

In regards to headers in my own editor, I plan to half support them in initial releases by removing them and letting them manually add them on save if desired. This is a transitional phase so that other tools can be reworked for headerless support, in phase two it will only remove them. I think this approach should a bit less dramatic, and help ease the change in.
Originally posted by byuu
I don't know what you're talking about. bsnes is GPLv2, it's a one-line change to ui/cartridge/cartridge.cpp


Errr, I think you misunderstood. By "affording others the same respect", I was referring to respecting other authors developing their own software (not Bsnes) as they wish.

To be more specific I'm talking about situations like here where you advised Imamelia to direct his disdain at myself regarding copier headers. Admittedly pretty minor, but it doesn't set a respectful tone for later.

Originally posted by byuu
As I've always said, it's about practicing what I preach. Imagine if I were to go around calling alcohol evil, yet I were to sell alcohol in my restaurant because that's what people like to drink with their meals? How can I support headers while trying to eliminate them at the same time? It's hypocritical.


For the headers, I'd merely call it being pragmatic. Copier headers are hardly evil after all... I consider it a technical issue myself, not a moral one.

Originally posted by byuu
Nach and I got along for many years at first, from 2004-2009'ish. Even after all of that time of talking with him, I was not able to convince him to remove even a single excess file extension from ZSNES.

I didn't ask him to remove SMC, but weird ones like MGD/MGH/UFO. No dice. Some people simply won't change no matter what you do. If you deal with that for many years, you end up with a bad attitude like I have.


I'd just agree to disagree and leave it at that. It's only a file extension... not worth letting it affect your attitude or relationships.

Originally posted by byuu
LM won't write directly to disk every time. It'll load the file into memory, and write it all out when saving.


Actually no, LM really does write each change to the ROM file individually. It's useful being able to modify the ROM in an external hex editor then saving something in LM without it losing the hex editor changes.

Originally posted by byuu
and yet I've never seen a personal attack here on FuSoYa like every last thread I see here has on me


Oh, that's easy. Just spell your name backwards on web boards. Casual users won't know it's you, so you can post unmolested! ;)

Kidding aside though, that's why I felt the need to step in here. Wanted to head off any personal attacks against anyone before it got out of hand.

Originally posted by Kaijyuu
Oh don't worry, I at least have given him plenty of shit for that.


And I'd rather you not, if you don't mind. If for some unforseen reason I did chose to release the source in the future, it would be in spite of such behavior, not because of it.

Originally posted by imamelia
My apologies. I guess that post was a bit more accusatory than I meant it to be.


Alright, no hard feelings.
Originally posted by Ayosuf
Originally posted by Kaijyuu
Oh don't worry, I at least have given him plenty of shit for that.


And I'd rather you not, if you don't mind. If for some unforseen reason I did chose to release the source in the future, it would be in spite of such behavior, not because of it.

Haha, I fully realize that :P I was mostly being facetious about the "giving you shit" part, though if you truly think my pushing is obnoxious go ahead and say so. It's never been my intention to insult or irritate; my suggestions here and elsewhere are just me wanting what's best/easiest for my personal hacking endeavors.
Quote
In regards to headers in my own editor, I plan to half support them in initial releases by removing them and letting them manually add them on save if desired. This is a transitional phase so that other tools can be reworked for headerless support, in phase two it will only remove them. I think this approach should a bit less dramatic, and help ease the change in.


Yeah, it was only because I snapped that it was so dramatic.

If I ruled the world, yeah, this would be my approach via emulation:

Step 1: start with a popup warning, "Copier header detected. Support for these are deprecated. Would you like me to remove them? Yes / No / Always / Never"

It's important that IPS patches are transformed along with the change. A very easy thing to do.

Wait a few months.

Step 2: remove the "Never" option. It is critical that this build add other desirable features and major improvements, like a new sound engine to fix SMW fireballs, for example.

Wait a few months. Tools will likely update at this point, as will some ROM piracy sites.

Step 3: "Copier headers are no longer supported. To play this game, it must be removed. Shall I remove the header? Yes / No / Always"

A no option now will result in game loading being canceled. Again, there has to be a major reason to upgrade. Support some new special chips and re-add netplay support here. Add some TAS and debugging features for good measure.

Wait a few months. The rest of the piracy sites will update as they'll be inundated with requests to.

Step 4 (optional): remove the message, and remove the detection. This last step isn't pragmatic, but it does fulfill the goal of no longer having to detect such things.

-----

Of course, with no real market share, I'd only be asking the people who already have clean ROMs. And as soon as I moved on to even step 2, everyone would switch back to another emulator.

Quote
Errr, I think you misunderstood. By "affording others the same respect", I was referring to respecting other authors developing their own software (not Bsnes) as they wish.

To be more specific I'm talking about situations like here where you advised Imamelia to direct his disdain at myself regarding copier headers. Admittedly pretty minor, but it doesn't set a respectful tone for later.


You're right, I'm not very respectful of different positions as I used to be. It's definitely not a positive attribute of myself.

I wasn't meaning in that post for imamelia to go and complain to you. I was more meaning that Geiger had the right idea in removing them. What was irritating was tools that would intentionally keep adding them back. Of course, idealism aside, both will irritate a user. They want their preferences respected, and neither of us do that right now.

Quote
For the headers, I'd merely call it being pragmatic. Copier headers are hardly evil after all... I consider it a technical issue myself, not a moral one.


To lend background, I've been releasing translation patches since 1998. I have had to deal with people's IPS patches failing due to headers vs no-headers since then. And pro-tip: once you have an emulator, you not only get questions about your patches, but about everyone's patches ever made.

I tried a two-pronged approach and made an IPS alternative with Nach as well. It failed to gain any traction, less popular than PPF and Xdelta.

I've had to support headers in my emulator, in my assembler, and in my earlier translation patches. I've had to perform ROM/LoROM conversions with $200 offset calculations in my head far too many times (LunarAddress is very nice, by the way.)

If you ever want to experience pain, try detecting where the internal game headers (with vector addresses) are at in a ROM. Now try doing it with a header involved. And now try doing it with the first three years of copier-PD software that do not pad their ROMs to an even multiple of 32KB.

It may not be the biggest issue in the world, but headers do absolutely nothing, nothing at all, useful.

Quote
I'd just agree to disagree and leave it at that. It's only a file extension... not worth letting it affect your attitude or relationships.


Oh, it was many things. He wanted me to support JMA, which I did. I had to work with others to patch it for 64-bit support he never added. Then he would only allow the change under GPLv2 (my emulator had a no-fork clause back then), and wouldn't fix upstream after a couple years. Never did get support for non-ANSI filenames.

He had the NPS patch format, so I helped revise, advertised the spec for two years on RHDN, released all the tools, added the emulator support to bsnes and Snes9X, and ... nothing. He never released any tools, never supported it with ZSNES, etc.

Then it came to memory maps. HiROM and LoROM are made-up terms, real memory maps are more complex and have 40+ configurations. We need the PCB IDs to know exact mirroring. He had access to log this info via NSRT but would not do so because, surprise, games don't often read from the mirrored areas. Eventually resulted in me buying the entire USA set and recording them myself. JPN set may never happen :/

Then the file extensions issue. Then supporting arcane interleave formats. Then about applying my VRAM-write-block patch. On and on.

It's not like we got in a big fight or anything. He just stopped talking to me. I don't really blame him, I've always been vocal about my critiques with their emulation. Most specifically their inaction toward fixing them, even when I'd provide patches. For instance, they want to keep allowing those illegal VRAM writes solely because old ROM hacks/translations depend upon them.

Quote
Actually no, LM really does write each change to the ROM file individually. It's useful being able to modify the ROM in an external hex editor then saving something in LM without it losing the hex editor changes.


Drat. So then the only truly transparent option will be to hijack your file write commands via DLL API hooks to manually adjust the offsets :/

Would it offend you if I or someone else were to take a shot at that? It'd be in the form of a launcher that loads in your unmodified program as a debuggee process.

No sense even trying if you would be upset by it, or worse, try and block such actions in future releases.

Quote
And I'd rather you not, if you don't mind. If for some unforseen reason I did chose to release the source in the future, it would be in spite of such behavior, not because of it.


For what it's worth, please disregard my comments. Especially about the SFX tracer. I'm sure everyone knows I am intolerable, but I'd hate for my actions to cause detriment to others.

I'm absolutely huge on this open source thing and all. But I do know where you are coming from. For the first five years I had a no-derivatives license because I feared people would hack bsnes to run broken software like the VRAM write and Addmusic/echo buffer stuff. Speaking only for myself, I eventually came to realize that just because some people will do bad things doesn't mean that others who would do good should suffer for it.
A little editor where you can edit the paths of the Creating Blocks.
In regards to the header/headerless issue, why not just do the following: Add headerless ROM support, but only as a difficult-to-find option hidden behind technical-sounding error messages. The former protection would ensure that people not specifically looking for the option wouldn't find it, and the latter would ensure that those few who do accidentally stumble upon it will be scared off by the technical details they don't understand (something along the lines of, "Warning: you are about to remove the header from your ROM. This may cause incompatibilities with edits that base themselves off of pre-existing PC-based offsets that assume a headered ROM, as well as cause some third-party tools to completely corrupt your ROM. Only continue if you are absolutely sure of what you are doing."). The final step is to internally add a header when creating an IPS patch, and then removing it afterwards if it didn't exist to begin with (to keep support with the hundreds of already existing IPS patches out there that only support headered ROMS).
I should get a new layout.

Probably won't, though.
Originally posted by byuu
I was more meaning that Geiger had the right idea in removing them. What was irritating was tools that would intentionally keep adding them back. Of course, idealism aside, both will irritate a user. They want their preferences respected, and neither of us do that right now.


More importantly they want things to just work, after which they worry about preferences. LM has the advantage of having gone from less to more user friendly, since previously it didn't open headerless ROMs at all but recently at least adds a header. Bsnes has gone in the opposite direction, by previously supporting both but removing that functionality... not really surprising that users rebel against that.

Originally posted by byuu
It may not be the biggest issue in the world, but headers do absolutely nothing, nothing at all, useful.


The question isn't whether they're useful, but whether dropping support for them entirely causes more grief than good. If it were an issue of emulation accuracy it would be understandable, as bsnes serves a rather important niche in that area for which I'm sure many are appreciative. Or if you were in a position to set standards as you've mentioned, at least it would ensure a transition over a limited period of time. But since that's not the case...

Well, it's your software so totally up to you of course. I just don't think I'd do the same in your position.

Originally posted by byuu
Drat. So then the only truly transparent option will be to hijack your file write commands via DLL API hooks to manually adjust the offsets :/

Would it offend you if I or someone else were to take a shot at that? It'd be in the form of a launcher that loads in your unmodified program as a debuggee process.

No sense even trying if you would be upset by it, or worse, try and block such actions in future releases.


As long as it's distributed entirely separate from LM, I wouldn't mind too much. Although I'd appreciate it if you could include some kind of disclaimer for users about not reporting any bugs to myself if running LM through such a process.

Originally posted by byuu
For what it's worth, please disregard my comments. Especially about the SFX tracer. I'm sure everyone knows I am intolerable, but I'd hate for my actions to cause detriment to others.


Alright, no problem. I was rather taken aback when I first saw the SFX post actually... had to think for a few minutes before even vaguely remembering that one or two people might of asked for the source at some point. Couldn't imagine much reason for you to be offended by my declining to provide it either.

Originally posted by byuu
I'm absolutely huge on this open source thing and all. But I do know where you are coming from. For the first five years I had a no-derivatives license because I feared people would hack bsnes to run broken software like the VRAM write and Addmusic/echo buffer stuff. Speaking only for myself, I eventually came to realize that just because some people will do bad things doesn't mean that others who would do good should suffer for it.


Sounds similar to arguments over whether LM has made it too easy for people to modify SMW without really knowing how to hack. ;)

As for myself regarding source code, I just consider it a personal choice best left up to the author. If he wants to donate his code, that's very generous of him. If not, not a big deal since it's his to do with as he wishes.

Originally posted by Kipernal
why not just do the following: Add headerless ROM support, but only as a difficult-to-find option hidden behind technical-sounding error messages. The final step is to internally add a header when creating an IPS patch, and then removing it afterwards if it didn't exist to begin with (to keep support with the hundreds of already existing IPS patches out there that only support headered ROMS).


The registry-only option someone else mentioned is somewhat tempting, but I think most patches still tend to be made in LIPS and not LM. SMWC could perhaps get around it by only accepting patches for headered ROMs, but personal web sites... still feels like opening up a can of worms to me.

I guess if p4 or someone wants to try making a launcher or whatever for LM, that'll take care of it for now for the few that really want it. Can always re-evaluate the header situation again in a few years if needed. But unless snes9x or zsnes decides to drop headers as well, I'm probably not going to worry about it much.
Quote
Bsnes has gone in the opposite direction, by previously supporting both but removing that functionality


Oh yes, absolutely. Of course, I don't care anymore if people use it or not. It would be funny though if I just silently removed them instead. Then bsnes and LM could fight each other incessantly :P

I mean technically it does, I include a tool that does it for you in two clicks. It's really no different from forcing header addition. People are just ... people about it.

Quote
The question isn't whether they're useful, but whether dropping support for them entirely causes more grief than good.


In the short term, it is worse. If everyone were on board, in the long term it would be a net benefit. Patches would always just work, and all tools wouldn't have to support both to be universally compatible.

You guys may have a lock on SMW always having a header thanks to LM, but the presence of headers is far less predictable for any other game. And in fact, more and more ROM sets are coming with no headers period, from what I have heard.

Quote
As long as it's distributed entirely separate from LM, I wouldn't mind too much.


Cool, thanks. I've a million things to do, it's just something I thought might be fun to try if I ever have time.

Quote
Alright, no problem. I was rather taken aback when I first saw the SFX post actually... had to think for a few minutes before even vaguely remembering that one or two people might of asked for the source at some point. Couldn't imagine much reason for you to be offended by my declining to provide it either.


It's a philosophy thing. I see not releasing source as keeping secrets, hoping to maintain popularity. I am especially upset when someone takes really complex open source software like Snes9X, which I've personally helped program, and subsequently hides their improvements to it.

To me, I just don't use closed source stuff. I just kind of figured your tracer had source when I used it at first, or I wouldn't have even bothered, so I guess you can say it was my fault. I was going to ask you, but I saw your "don't even ask" message.

On the bright side, it helped me choose GPL instead of BSD for my license. I would have been *far* more upset had someone done that to my code.

Quote
Sounds similar to arguments over whether LM has made it too easy for people to modify SMW without really knowing how to hack. ;)


I don't think that's a problem. It may flood the market with way too many bad hacks, but so long as you're not an idiot using the Good7z SMW pack and have some actual ratings to go by, the best will sort themselves to the top. In the right hands, LM can do some amazing stuff.

It's just odd that some of those people call themselves ROM hackers. It'd be like calling yourself an auto mechanic because you can fill your windshield washer fluid.

Quote
As for myself regarding source code, I just consider it a personal choice best left up to the author. If he wants to donate his code, that's very generous of him. If not, not a big deal since it's his to do with as he wishes.


It's a bit like capitalism versus socialism. Do you believe intellectual ventures should be used for self-betterment, or for the betterment of all? Some people think that without rewards, people won't innovate. Others, like myself, think that simply helping others is reward enough. Of course, that doesn't put food on the table, does it? Working for free is a lot more difficult when everyone else works only for profit.

I just think of computer programs like math. Imagine if the fast fourier transformation wasn't public, because the author didn't want others to use his work?

Quote
unless snes9x or zsnes decides to drop headers as well


Well, ZSNES is already dead. Once Windows 9 or 10 removes 32-bit BC, that will be the end of it.

I *may* be able to implement the more pragmatic "optionally remove headers if found" into Snes9X, but that'd be about it.

The only real hope those against headers have would be if bsnes were to take a larger share of 64-bit only OS' ZSNES users, and gain traction as computers continue to become faster and faster. With a compelling GUI like SSNES, having netplay, real-time rewind, multi-pass shaders, etc; that's not completely unforeseeable.

But it wouldn't be for a good many years, probably well after you've discontinued LM.
While I certainly enjoy the discussion, I would like to mention two feature suggestions.

First, it would be nice if it were possible to edit the original tile animation. I know we can just disable it and ExAnimate things, but that is a pain to do and uses up slots. We can also do it by writing our own hacks (I've already done so), but that causes the animations to show up as garbage in Lunar Magic. It would be nice to get the best of both worlds and have Lunar Magic install a hack that makes the animations much more customizable. (Even if it weren't a feature in the editor itself, at least somebody could hex-edit them.) There might have to be a flag of some kind for compatibility purposes...but maybe not.

Second, I think having an option to insert GFX32/33 into the ROM uncompressed wouldn't be a bad idea. I don't know how much it would affect things like ExAnimation and certain patches, but I do know that it would free up a TON of RAM (36,096 bytes, to be exact) at the expense of ROM space...although it would then also free up space in banks 08-0B.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Instead of just the normal FG/BG sprite GFX bypass, I think it would be nice if it was easier to tileset mix by setting the FG and BG settings individually.
Mario's Vanilla Journey

Progress: 22/72 levels complete
Originally posted by byuu
It would be funny though if I just silently removed them instead. Then bsnes and LM could fight each other incessantly


I imagine many users would even prefer that, as they don't care about headers one way or the other. ;)

Originally posted by byuu
It's a philosophy thing. I see not releasing source as keeping secrets, hoping to maintain popularity.


Amusingly, that brings to mind an email I once received several years back suggesting I release the source to LM as it would make me famous and popular. But assuming that everyone releases source for that reason would be no more valid than your assumption that everyone doesn't for the same reason.

Originally posted by byuu
I am especially upset when someone takes really complex open source software like Snes9X, which I've personally helped program, and subsequently hides their improvements to it.


No offense, but if you were uncomfortable with the more permissive license of Snes9x you could have simply chosen not to contribute to it. You know very well that not all authors mind granting the freedom to not release source to other developers.

Originally posted by byuu
Quote
As for myself regarding source code, I just consider it a personal choice best left up to the author. If he wants to donate his code, that's very generous of him. If not, not a big deal since it's his to do with as he wishes.


It's a bit like capitalism versus socialism. Do you believe intellectual ventures should be used for self-betterment, or for the betterment of all? Some people think that without rewards, people won't innovate. Others, like myself, think that simply helping others is reward enough. Of course, that doesn't put food on the table, does it? Working for free is a lot more difficult when everyone else works only for profit.

I just think of computer programs like math. Imagine if the fast fourier transformation wasn't public, because the author didn't want others to use his work?


Economic systems and algorithms? Sorry, but I think you've wandered off topic.

Originally posted by byuu
The only real hope those against headers have would be if bsnes were to take a larger share of 64-bit only OS' ZSNES users, and gain traction as computers continue to become faster and faster. With a compelling GUI like SSNES, having netplay, real-time rewind, multi-pass shaders, etc; that's not completely unforeseeable.


Maybe, but the farther we get from the SNES generation the less people may be looking to play games from it. I think the ones still around will tend to stick with what they know (Snes9x), not to mention Snes9x tends to be very popular to port to handheld devices.

Originally posted by byuu
But it wouldn't be for a good many years, probably well after you've discontinued LM.


Already did that once. The nice thing about hobbies like this one is that you can always come back to tinker with them later if you like. :)



Originally posted by imamelia
First, it would be nice if it were possible to edit the original tile animation. I know we can just disable it and ExAnimate things, but that is a pain to do and uses up slots. We can also do it by writing our own hacks (I've already done so), but that causes the animations to show up as garbage in Lunar Magic. It would be nice to get the best of both worlds and have Lunar Magic install a hack that makes the animations much more customizable. (Even if it weren't a feature in the editor itself, at least somebody could hex-edit them.) There might have to be a flag of some kind for compatibility purposes...but maybe not.

Second, I think having an option to insert GFX32/33 into the ROM uncompressed wouldn't be a bad idea. I don't know how much it would affect things like ExAnimation and certain patches, but I do know that it would free up a TON of RAM (36,096 bytes, to be exact) at the expense of ROM space...although it would then also free up space in banks 08-0B.


I think we've discussed both of these over email before. For animations there's already JW's old tool, which LM supports. For uncompressed graphics to free up RAM, there's already the option of using SRAM.

Originally posted by akacesfan
Instead of just the normal FG/BG sprite GFX bypass, I think it would be nice if it was easier to tileset mix by setting the FG and BG settings individually.


Check the Super GFX Bypass dialog (unless you mean something entirely different, in which case you'll have to be more specific).
Concerning close/open source vs popularity...

I've never heard that argument before. Gonna agree with fusoya that it's a bit silly to say it'll affect it either way (though it might hurt it a tad bit due to multiple forks causing confusion). However, I *have* heard arguments about preserving *author* popularity. Most of the time when I ask someone why they keep their source closed they respond that they don't want someone changing the name on it and taking credit. Needless to say that's a preposterous reason, as a fork with not besides a name change isn't going to gain much popularity, not to mention it calls into question the author's motivations in the first place.

Not being accusatory here (as you've stated much better reasons in the past); just musing, I suppose


@imamelia's suggestions:
Couldn't these be done with a regular ol' hack? Unless there's something about LM that would get in the way?
Originally posted by Kaijyuu
Couldn't these be done with a regular ol' hack? Unless there's something about LM that would get in the way?

Well, the animation thing could (I've already done it); the animations just won't show up correctly in the editor. Leaving GFX32 and 33 uncompressed...that I'm not so sure about. There would be no way to prevent Lunar Magic from inserting them anyway, and you couldn't use GFX33 in ExAnimations (unless you wrote your own ExAnimation routine).

Where is jonwil's tool, anyway? I don't have that e-mail anymore, and I can't find the tool anywhere. (I'd certainly like to know how it keeps compatibility with Lunar Magic....)

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
Leaving GFX32 and 33 uncompressed...that I'm not so sure about. There would be no way to prevent Lunar Magic from inserting them anyway, and you couldn't use GFX33 in ExAnimations (unless you wrote your own ExAnimation routine).


You can replace LM's copies with 1 byte files if you wanted. Although it might be better to keep them around unless you need the actual ROM space, to keep the animations correct in LM.

You could fix the original game's animations for it by doing a small ASM hack to adjust the source frames, as well as doing the same to LM's ExAnimation ASM and changing the bank byte used by both. Which would leave LM able to still display them correctly without any other changes.


Originally posted by imamelia
Where is jonwil's tool, anyway? I don't have that e-mail anymore, and I can't find the tool anywhere. (I'd certainly like to know how it keeps compatibility with Lunar Magic....)


I could always dig it up again if it's been lost. I modified LM to support it back then on request, and the code has been in LM ever since.
My suggestions is to add patches like imamelia said in page 1 but we are priorizing graphics too much, today we have Edit's ExGFX revolution and ExGFX layer 3, we can have the most über realistic BGs but what happened to the overworld?

Overworld it's too underrated for hacking purposes and thats includes the sprites, we have two OW sprites on sprites sections and less slots for sprites.

My suggestion is, optimize and include known and most used patches and priorize the overworld.
Rather than continuing the discussion, let's just consider the problem resolved.

http://byuusan.kuro-hitsuji.net/solar-magic/sm100.zip

Solar Magic is a launcher application. Take any version of Lunar Magic, past, present or (hopefully) future, and rename it to "Lunar Magic.dll", and now run Solar Magic.exe instead.

This will load in Lunar Magic as a debuggee process, and insert Solar Magic.dll into the process. The DLL will hook and override the Windows file access functions. It will trick GetFileSize, FindFirstFile, ReadFile and WriteFile into thinking the ROM has a header. It hooks CreateFile and CloseHandle as well, so that this only happens on SFC and SMC files. It will return a dummy header when Lunar Magic tries to read it, and it will ignore header writes. As such, you probably don't want to use this with a locked ROM. Note that the launcher also supports headered ROMs as well.

The Lunar Magic executable is completely unmodified. I do not even patch out the checksum test, because it's not necessary. I don't even modify Lunar Magic in memory. I only manipulate the behavior of the kernel32 file access functions.

As such, this tool will likely work with *any* Windows ROM hacking tool that does not support headerless ROMs.

Minimal support is available here:
http://board.byuu.org/viewtopic.php?f=9&t=1804

As I have specified in the included readme: please, please, **please** do not ever bug FuSoYa about this. I would hate for him to be against this, or block this tool from working in his future releases. He was very generous to let me do this, so let's please leave it at that.

Lastly, my sincere thanks to FuSoYa for letting me make this tool.
Regardless of your stance on the matter, now everyone can be happy! FuSoYa does not have to add headerless support or release the source code, bsnes does not have to add header support, and no user has to choose between one or the other. Enjoy!
Most excellent!


Much less hassle than removing and adding headers based on the tool being used.
Originally posted by byuu
http://byuusan.kuro-hitsuji.net/solar-magic/sm100.zip


Best idea I've seen in a while...but it hangs upon loading an Open File Dialog or Save File Dialog (or at the very least takes an obscene amount of time to load it). Standard drag and drop/command line seems to work fine, though, so it's not a big deal.

Also, does anyone know if we can look forward to custom tooltips and sprite collections supporting the extension byte any time soon?
I should get a new layout.

Probably won't, though.
> Much less hassle than removing and adding headers based on the tool being used.

Agreed. The reverse trick could be used on bsnes too, if someone were so inclined. Of course, editing the source would be a lot easier there.

> Best idea I've seen in a while...but it hangs upon loading an Open File Dialog or Save File Dialog (or at the very least takes an obscene amount of time to load it). Standard drag and drop/command line seems to work fine, though, so it's not a big deal.

Well, it doesn't here, but yeah at least drag-and-drop works for you, so that's good. I'm going to guess you have some other thing on your system that's also silently hooking APIs and botching things up ... maybe an anti-virus or custom extension thing?

Anyway, it's open source and I'd be happy to receive any improvements or bug-fixes =)
All of the code is public domain (or ISC if you prefer, your choice). I would also appreciate if anyone here could create and distribute similar launcher packages along with any needed modifications for other header-only tools.
My code shows you how to do all of the hard stuff already, so any changes would be relatively minor and straight-forward at this point.

If enough people are interested, we can extend it to cover more API calls (eg Unicode variants), per-application profiles, and the reverse header->headerless faking.

Would probably just rename it to Header Magic at that point.

Anyway, would the mods/FuSoYa want to fork this off to a separate discussion thread, perhaps?
  • Pages:
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 143
  • 144
  • 145
Link Thread Closed