Banner
The Overworld Design Contest ends in
1 MONTH, 5 DAYS, 12 HOURS, 52 MINUTES AND 16 SECONDS
Views: 897,638,650
Time:
17 users online: Anas, ArmAusStahl, blocc,  brickblock369, Dark Prince, Darkguii, edgar, goldenrules,  K.T.B., KronicTheGreat, mmBeefStew, RanAS, Rykon-V73, Saela, ThEighthSage, tltlvilus, Wyatt - Guests: 91 - Bots: 67 Users: 50,361 (2,288 active)
Latest: jeyson28
Tip: Make sure there is no stylistic clash between the graphics you choose.
Not logged in.
Super Mario Advance 3 hacking
Forum Index - Non-SMW Hacking - Yoshi's Island Hacking - Super Mario Advance 3 hacking
Pages: « 1 2 3 4 5 6 7 8 9 » Link
"ShyGuy Advance", then?

--------------------
"Lip: A Fairy's Tale" project status: Slow (Visit the project thread here!)

Yes, you could say I like Osaka.
How about "ShyGuy 32"?
ShyGuy's Mask.

Alright, screenshots for anyone who cares:


The main window of the editor. Who knows, maybe I'll change it. From here, you can drop a file or go through the Open ROM dialog.


A warning occurs if the user opens a ROM that doesn't have the header I specified earlier.


Here is the list of stuff that will eventually be visible on this list.


And here are all the different Edit... dialogs.

And of course, one bug is present:

This is what happens when you drag a folder into the editor. (P.S.: that dialog was not implemented by me.)
Severity: none


Looks like a good job. If the editor shows the graphics I am going to support this.
One question:

Does it have limited objects/sprites placement just like in EggVine, or you can add as many as you want?
Seeing as SMA3 is essentially a direct port of YI with some changes, I'd guess there are still object and sprite limits, though they probably are less restricting. Even if they aren't, they shouldn't be that big of a burden.

--------------------
"Lip: A Fairy's Tale" project status: Slow (Visit the project thread here!)

Yes, you could say I like Osaka.
Originally posted by Yakov
(screenshots)

The editor looks pretty good so far.

One thing, though... What would happen when you select "Levels"? A list of levels to load? It seems a little strange for that to be in the same place as objects/sprites...


Originally posted by Mippish
One question:

Does it have limited objects/sprites placement just like in EggVine, or you can add as many as you want?

The limited number of available bytes? That's part of the ROM's structure, not Eggvine.

I think the editor could, at some point, have an option to automatically move levels around in the ROM for conserving space. (If so, this would come much later, of course.)


Note: Considering that it seems safe to increase the size of the GBA version, I plan on making a patch that gives some huge amount of space for every level once there's a working version of this editor. (Probably 0x2000 or so bytes per level, assuming the game can handle levels that large.)

I'll need to know how the editor deals with the total object/sprite space first-- that is, after you save a level using fewer bytes than it did originally, I'll need to know how the editor detects that the bytes are still available for that level. (Fill with FFs? Fill with 00s? And what would happen if the next level's data begins with 00 or FF?)

By the way, I have a lot of suggestions on how this editor can be better than Eggvine, but I'm not listing them now. If you're wondering, I'm waiting for a basic working version of the editor before suggesting improvements-- it's likely that a lot of my suggested improvements will already have been done anyway by that point.

–=–=–=–=–=–=–
Alyssa's Unlikely Trap - Zeldara's Glitch City

For the time being, I'm going to place restrictions per each block of whatever (e.g. message block 1 has X bytes, message block 2 has Y blocks).

About the Levels being in the same place as Objects/Sprites: true, it might look kinda awkward, but I want that you'll be able to see the level name along with its number. Should I make a separate dialog for that?

And finally, since I don't know how to render graphics stored in the ROM, nor do I want to resort to EggVine's method of ugliness (AKA blocks with numbers), I'll probably be using images for that.


Originally posted by Yakov
About the Levels being in the same place as Objects/Sprites: true, it might look kinda awkward, but I want that you'll be able to see the level name along with its number. Should I make a separate dialog for that?

I think a separate dialog for the level list would be good. (It would only be needed when loading levels or making screen exits.)

Maybe if the level you're currently viewing contains a screen exit to another level, that level could show up differently on the list?

Also, I think it should be possible for users to create a file containing their own hack's level names (and possibly other things). (It could be like Lunar Magic and the music track names-- if you give the file the same name as the ROM, but with a different extension, the editor automatically loads the file, overriding the default level names. There could be an option in the editor for editing this custom level list.)

By the way, "level name" has two meanings. There needs to be a way to distinguish this type of level name from the level titles that appear when you select a map icon...


Originally posted by Yakov
For the time being, I'm going to place restrictions per each block of whatever (e.g. message block 1 has X bytes, message block 2 has Y blocks).

So each message will be stored in the same bytes as the original message? This makes sense. (Anyway, it's likely that there are more pointers to the messages than I know of.)

By the way, if a message is edited to be shorter than it was originally, it should be safe to fill in the space after the end of the message (...FF 0F FF FF) with FFs.

Edit: Actually, since the pointers to the message blocks are known, as well as the entire structure of the messages, it could be possible to just add new messages in some other data...


I was asking about level data and sprite data. If you edit a level to use fewer bytes than the original level used, the FF FF FF FF (for sprite data) or object FF (for level data) will need to be moved earlier, as the game would otherwise interpret the remaining data as more objects/sprites.

There would then be an unused block of data.

What I'm wondering is, if you're looking to increase the level back to its former size (most people would probably delete the whole level initially, then gradually add objects/sprites), how will the editor detect that this space is not used for another purpose? I was thinking of filling in the unused block entirely with FFs, but it's possible that the next section of data might begin with FF (unlikely, but possible), and therefore be misinterpreted as part of the end of the data-- meaning if you change the next level and it no longer begins with FF, the previous level would have no end.


Originally posted by Yakov
And finally, since I don't know how to render graphics stored in the ROM, nor do I want to resort to EggVine's method of ugliness (AKA blocks with numbers), I'll probably be using images for that.

Image files containing the in-game graphics? Or just images with more detail than Eggvine's colored rectangles?

If you use images of the in-game graphics, make sure the graphics change when you change the tileset!

And could you also try to make it load the graphics with the correct palette in the header (when applicable)? (If you use in-game graphics with fixed palettes, it would probably make people biased toward making levels with those palettes.) You could test out the different palettes to find the colors, and manually store the colors somewhere in the editor. (At least until the palette offsets are found.) Then use some sort of image file (not sure what though) that can appear with varying palettes.


And about the graphics in the ROM, I have a feeling that they're stored somewhere near the end, in a way that has a direct correspondence between pixels and some number of bits. I've seen images made of hex values when scrolling through there.

---

Edit:

I just thought of an entirely different way to structure the editing:

Just add new levels, messages, etc. in the x400000+ range, and modify the pointers.

I do not think this a good way to structure the editor itself though. (Not to mention it would make the editor completely incompatible with the SNES version if it only worked this way.)

Maybe, once the details are worked out of how the editor will store changes in data length, I could make some kind of base hack that basically adds a lot more space for each level, message, and so on...

–=–=–=–=–=–=–
Alyssa's Unlikely Trap - Zeldara's Glitch City

OK, so my initial plan for the editor is the ability to edit the messages. This, I think, should be the easiest part. I think we can shift bytes to give more space for other messages, levels, etc.

About the graphics, although they may be located at the end of the ROM, interpreting them and converting them from GBA to wxWidgets graphics may not be such an easy process, so I'm just using stored graphics.

I'm hoping by Sunday I can have something even a bit presentable.


Originally posted by Yakov
OK, so my initial plan for the editor is the ability to edit the messages. This, I think, should be the easiest part.

That's a good idea. I agree that it's the easiest part.

A suggestion for the text editor-- have an option to manually load a message from any offset (as long as the message starts with FF 05).

If you make a working YI text editor before the rest is finished, do you think you could release it? (And maybe make it compatible with the SNES version, which currently has no text editor? SNES version messages are the same, other than most of them being forced into the x110200-x1201FF range.)


Originally posted by Yakov
About the graphics, although they may be located at the end of the ROM, interpreting them and converting them from GBA to wxWidgets graphics may not be such an easy process, so I'm just using stored graphics.

I'm not expecting graphics rendering/editing to be done anytime soon (unless the GBA Pokémon hackers, who seem to edit graphics often enough, have something that would work for GBA games in general).


By the way, I edited my previous post (adding more about the graphics) before noticing your response.


–=–=–=–=–=–=–
Alyssa's Unlikely Trap - Zeldara's Glitch City

Ugh, cross-compatibility is something that will get complicated, so I'll try to stick to one platform for now. I do like the idea of adding messages at x400000+, as long as the program won't mistakenly read data that it isn't supposed to read.


Is it possible to have levels above 0x3FFFFF? If yes, the problem with the Sprite- and Object limitations could be solved by letting the program relocate the level to a higher section. If the hacker sets more objects than he/she can use and tries to save, the program could ask him, if he/she wants to relocate the level. If he/she says "Yes" he/she can type in how many bytes of space he/she wants for his/her level. The program will give him/her the opportunity to expand the object data to an amount between the bytes he/she is using at the moment and 4,000 bytes (more aren't needed for one level). If he/she sets more Sprites than he/she can use the program will ask him/her either if he/she wants more sprites. Then the hacker can type in a number between the number of bytes of Sprite-data he/she is currently using and 600 (I think 150 sprites are enough). Then the editor will automatically expand the ROM, add 00s of free space and brings the level as it was to the expanded place. And of course it modifies the pointers.

--------------------
NEW! SMW2 Yoshi's Island is done!
Last update: 2012-12-31

<!--NONE OF THAT HAS EVER HAPPENED, MIND YOU! -->

And now, a question: since a lot of the bottom of x3FF--- is blank, can data be placed there instead of expanding the ROM?


Originally posted by Yakov
I'll have to be honest with you people: does anyone even care about the editor (and by "anyone" I mean over π people)?! Because, honestly, there hasn't been much feedback. Hell, nobody even came to an agreement for the name!

Now, don't get me wrong, even though maybe mol-1 people care about this, I will continue to make the project. At least pretend to care about this, after all, C++ isn't the easiest thing to program for, you know!

And now, a question: since a lot of the bottom of x3FF--- is blank, can data be placed there instead of expanding the ROM?

Well, you probably already know this, but I certainly care about this editor. And it appears Jeorge535 and Mippish care as well, considering their signatures.

There aren't that many people who normally post in this forum. Most of them have already posted here at least once. (And I'm not sure if there's really that much to give feedback on.)

I changed the topic title-- maybe this will help people notice the topic. (The userbars might help as well. (I made mine a link to this topic by the way. Though I rarely post outside of the YI hacking forum, so I'm not sure how effective my link will be...))


A note-- In my experience, there are a lot of people who do not like the GBA version, mainly due to Yoshi's voice samples, and the instrument quality of the music. (I personally prefer the GBA version. I prefer Yoshi's GBA voice samples to the SNES sound effects. But the secret levels are what I really like about it. The better save system is nice as well.)

(This is why I was encouraging compatibility with the SNES version. More people prefer it.)


About the name, some people may be leaving it for you to choose a name, considering you're making the editor. (Any ideas? Or would you prefer to let others choose the name?)


The x3FE000+ range looks pretty safe to me. I would avoid the bytes that are close to the "image", though, as I'm not sure how large it is.

What are you thinking of doing with those bytes?

–=–=–=–=–=–=–
Alyssa's Unlikely Trap - Zeldara's Glitch City

Well, I might be planning to actually use those unused bytes instead of expanding the ROM, and one of the reasons is that it still has a valid ROM size. Those empty offsets are probably there just to make the ROM 4MB, and valid GBA sizes are probably base 2 (2x) sizes, so I want to maintain that.

The name -- you people have the full right to decide the name. I'm responsible for the editor itself, so you people have the advantage of naming it.


As I said before, ShyGuy Advance seems like a pretty good name.

--------------------
"Lip: A Fairy's Tale" project status: Slow (Visit the project thread here!)

Yes, you could say I like Osaka.
Originally posted by Yakov
I'll have to be honest with you people: does anyone even care about the editor (and by "anyone" I mean over π people)?! Because, honestly, there hasn't been much feedback. Hell, nobody even came to an agreement for the name!

Now, don't get me wrong, even though maybe mol-1 people care about this, I will continue to make the project. At least pretend to care about this, after all, C++ isn't the easiest thing to program for, you know!


No one is obligated to shower you with praise, what gave you that idea? It sounds like this is a chore to you and you are just doing it for praise. That's the worst motivation, do something because you actually like doing it.

More people may care when you have something genuine to show. Anyone can cobble together and interface, even a non-programmer. Show an implementation of actual editing, and even then the real interest is in the level editing. Projects like this pop up and die when the programmer realizes they can't follow through with the tougher bits, that's part of the 'meh' attitude that goes with new projects like this. Blind optimism sucks.

If you follow through with something decent then you'll get the attention you seem to crave, though that's an issue in itself. Goodluck anyways.
Also keep in mind there may be people who are silently watching along with interest who just don't feel like typing a response because they don't have anything relevant to say (e.g. me).

Anyway, I'd be interested in checking out this editor. Even though SMA3 is pretty much the same as the original YI, there are 6 additional levels I can work with, and the editor, so far, looks to improve on EggVine.
Pages: « 1 2 3 4 5 6 7 8 9 » Link
Forum Index - Non-SMW Hacking - Yoshi's Island Hacking - Super Mario Advance 3 hacking

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2021 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy
  • sm64romhacks