Currently editable:
- Audio samples
- Music (sort of; interface is still shit)
- Events/Dialogue
- Maps
- Tilesets
- World map
- Palettes
- Tiles
How much of this will be exportable to a rom for the first release I'm not sure. But at least you'll be able to screw around. Getting it all read-in correctly is the hard part anyway, dumping it back out to the rom shouldn't be too bad.
Here's a picture of gaia's navel in the newest map editor, with the collision layer turned on.
The white squares are object locations.. mostly (if not all) Buzz Bees on this map. Dark squares are door/walk-over event/sign locations.
Here are some maps that still do not look right (with zsnes screencaps for reference):
Palette issues in Tasnica. This happens on every map with this tileset, and a few others.
Map decompression issues. These still pop up here and there. A lot of the code in this game really makes no sense whatsoever, particularly some of the stuff they do with map "compression." Music was the same way. Also in this screenshot, the transparency on the red clouds (which otherwise look correct, unlike the background layer) is supposed to be additive; it's not, so they look rather stupid.
Tasnica interior; shadows shown with additive transparency rather than averaged transparency.
18 comments:
First!
So glad you finally did an update, so many people are looking forward to this.
It's nice to see that you are still working on this. I feared all the work you have done is vanished.
One question, do you plan to release all the information you gathered by reversing this game if you, for some reason, stop working on the editor?
PS: Whats your profession that you are so experienced in asm? Or is it just thirst for knowledge and for fun that you learned about these things?
At some point yes I will probably release all the information I know. Organizing it into something that makes sense is almost as large a task as finishing the editor itself, since my documentation at this point is largely the editor itself and comments I've left in the code.
Most of the asm work I've done has not been professional or academic, but I am a "software engineer" by title. I used to play a lot of SNES games online with someone who would refuse to play most games unless I hacked the game up and added 2 player controls. That gave me some practice with 65816.
This project actually started in late 2004 or early 2005 after I did some SPC research for someone working on an FF6 editor, and found that no one had yet touched SOM.
This is absolutely the best news I've read in the last month. Thank you so much for keeping at it. Cannot wait for it to release. A couple of questions: Will we be able to add graphics: for example adding graphics from Secret Of Evermore-and, perhaps adding sprites? What about the over world-can we create custom maps?
I'm not planning on supporting addition of tiles or sprites for a while, but you can certainly modify the ones that are there, including the graphics themselves, how they're formed into tilesets, and which maps use them. Same goes for sprites, but that research is not quite as far along. I have found where player tiles are assembled into sprites, but it will not be editable for a bit yet.
The overworld map is nearly fully editable at present including which tiles go where, which ones are landable, the tile graphics/palettes themselves, and where you end up when you land on each sector of the map. The stuff that is still missing includes sky graphics, flammie graphics, stuff like that.
If we can modify existing graphics, couldn't we just replace the boy-sprite for example, with the one from SOE? Maybe using yy-chr, as Lunar Magic does?
After i get map, tile, and event stuff pretty solid, the character sprites would probably be next. So if you wanted to change the SOM boy into the SOE boy, or dog, for example, it would be doable then. That research is sort of halfway there at the moment but still needs work.
Well, the problem with just replacing the graphics is will the dimensions of the characters match up. Maybe a couple frames of the SOE boy's movement have limbs in different locations than the SOM boy's.. you'd want to be able to rearrange the tiles that make up each sprite for it to look good.
Can't wait to test it out, and thanks for the answers.
''Well, the problem with just replacing the graphics is will the dimensions of the characters match up. Maybe a couple frames of the SOE boy's movement have limbs in different locations than the SOM boy's.. you'd want to be able to rearrange the tiles that make up each sprite for it to look good''
That's what the SM community is doing all the time. The thing that helps is that Fusoya made Lunar Magic split the graphic file, so you get manageable graphic files containing the sprites in all their movements-then you can easily draw over it.
Yep! And thanks for your support.
I'll look at what he's done - maybe there's a standard way that sprites are assembled. Like i said, I found it for SOM, but it's not exactly right there with the graphics and I'm not sure how a tool like Fusoya's would automatically detect it.
But I suppose the answers to all of your questions are yes - eventually. It's all a matter of time and research. I would like for everything you could possibly want to do .. within reason.. to be doable.
His editor does the splitting of the gfx files. So instead of opening the whole rom in yy-chr, you open the gfx files and edit them. I've seen the same thing attempted with other editors in development-Yoshi's Island and Super Mario All-Stars, but they're not finished yet, so I can't say how successful they are.
I forgot to ask: I'm assuming you can modify movement and actions of non controllable sprites and objects? I apologize for so many questions, but you are the only one developing an editor for games like SOM or SOE, and not those turn-based ones.
They all seem to be done in a similar fashion, so once player sprites are editable, NPCs and enemies won't be far behind. Bosses are a little trickier in general since the graphics are compressed, but somewhere around here I have info on that compression - i just haven't gotten around to screwing with it yet.
Another thing that SOM defines that I'll want to have editable is the animation of all these sprites.. which ones get chained together for a running animation for example. What i've been calling the "events" (NPC or other input-driven actions combined with dialogue) reference these by number, so it would be nice to know/show which is which.
As for enemy AI, that info is stored in a little table of actions that I found once. There was a point at which I had rabites spawning other rabites like Green drops do, and stuff like that. I think that will be fun to mess around with.
Hey Mop, I noticed in this post you mention that white (or yellow), squares are enemies. Will they some day be represented graphically as we edit? And is the event logic something like: If a then b or c, etc?
Event conditional logic is done by conditional branches - if event flag lt/et/gt a certain value, jump to this event, else jump to this event. This is a little wasteful of events, and iirc, there are 1024 of them max. Whether this number is easy to expand, I'm not sure offhand.. there may not be more than 10 bits available for things like NPCs to reference it without some serious hacks.
Once the sprite processing is done, yeah, map objects will be represented by the standing animation for the associated npc/enemy.
Post a Comment