A new project for WL4 ROM hacking and Level Editing

Here's One:
wario.jpg
 
You can share your final hack in the discord server, and we can upload your hack to a webpage full of WL4 hacks.
this is the site: Wario Land 4 Hack Vault
P.S. the address of the site will change, so pay attnetion to the discord server or the github repository of the website.
 
Thanks! But, Something VERY Weird Happened In The Editor. I Had Just Finished Up The Hall Of Crecent Moons 3rd Room,
But Now When I Open My Rom And Go Into The Level, There Is Just A Black Screen. Do You Know Whats Up With That?
 
Thanks! But, Something VERY Weird Happened In The Editor. I Had Just Finished Up The Hall Of Crecent Moons 3rd Room,
But Now When I Open My Rom And Go Into The Level, There Is Just A Black Screen. Do You Know Whats Up With That?
Do you have a bakcup of your rom? i mean the modified one. the editor is becoming more stable in the recent few months but we are still unsure if the editor will corrupt the rom or crash by itself during the editing. Send me your rom patch file in the discord (PM) and i can try to see what's wrong with the data in the rom and what need to be fixed in the editor. and tell me which version you were using when editing the level. You really should use the latest unofficial build i made in the discord server, they are more stable.
@MustangFan
 
i think you had better not posting the rom file here, but using bps file instead, make a patch file based on the vanilla rom for every hack, before Nintendo doing some legal actions. tho i have downloaded the modified rom already, xD. @MustangFan
And here is a manual way to fix your rom:
first, you need an hex editor
then open the rom with the hex editor and go to address 0x790158 (this is a hex, not decimal)
you will see this:
12469

then modify these 3 bytes into F4 FE 78 08 like this:
12470

and save the file then you can edit your rom on the editor again.
Since you did not told me which version of the editor you are using, and your editing details to cause the crash, so i cannot help you more about it.
 
Last edited:
Yeah, a BPS file is recommended here. Had to remove the ROM download above for legal reasons.
 
I'm not really into stuff like this, but can someone explain why ROM hacks are so controversial?

ROM hacks aren't controversial, but ROMs are.

People don't distribute the fulll ROM as one file because it contains copyrighted content (read, the entire original game + edits). Meanwhile patch files (which most ROM hackers distribute) merely contain the changes they made to said game, not the original copyrighted content.

It's like distributing a Mystery Science Theatre 3000 style commentary; if you distribute it along with the film, you'll need express permission from the studio who owns the film, whereas if you distribute the script separately, you don't.

Hence why full ROMs aren't posted here, but patch files are.
 
ROM hacks aren't controversial, but ROMs are.

People don't distribute the fulll ROM as one file because it contains copyrighted content (read, the entire original game + edits). Meanwhile patch files (which most ROM hackers distribute) merely contain the changes they made to said game, not the original copyrighted content.

It's like distributing a Mystery Science Theatre 3000 style commentary; if you distribute it along with the film, you'll need express permission from the studio who owns the film, whereas if you distribute the script separately, you don't.

Hence why full ROMs aren't posted here, but patch files are.

Ah, I get it now. I already knew it had something to do with the distribution of copyrighted material, but that's about all I knew of it.
 
2020 May and June Progress Report
Thanks to Goldensunboy's great contribution, the new patch feature coming out with our newest beta-10 official build released in Github. for a long time, our dev branch cannot be PR to the master main branch since the patch feature code, the hardest part, cannot be done and make the editor stable, but now it is finally finished and function much better than we thought at first. I would like to show some detials about it.
Normally, when we want to manually apply some asm hack to a gba rom, we need to reverse engeneer the rom first, and find the part of the code we want to modified. Then if the new functionality we want the game engine have can be directly modified on the original code, we only need to modify several bytes of asm in the rom, if it is not like that, and we want some completely new things happen in the game, and the space which the original code occupies cannot hold the new code, then we have to inject a long jump in that part, to jump out from the original code part, to some new address of free big spaces, and we write our new code there. so gba will jump out from that place to the new address, and run our new code, then jump back to run the following original game code. in this way, we can modify some game code we want but keep the other things same as usual.
The most headache part of making an asm hack is you have to write asm by yourself, which is really ineffective, and everytime, if your code cannot run well, you have to modified your asm code, which makes the whole thing more headache. And because of the ineffective, it it almost impossible to program some big things like overhaul a sprites AI, or make a boss which is completely new in the future. So goldensunboy came up with this idea to make an auto-patcher for the editor, to make it possible to let people write code in C (you can still use asm) and auto-patch your code into the rom somewhere. to use this new feature, you need to download the GNU Embedded Toolchain for Arm by yourself.
During the time he implementing the new functionality, we feel it will be better to let users to customize the hook part, which will be injected into the original code to help jump out from the source code to excute the new code written by ourselves, so the size of the hook part can be size-flexible and you can do stack balancing and other things all by yourselves, and it can be used in multiple cases. We decided the format of the hook be one part of some hex which you need to hardcode by yourselves and can be different in different patches, then a pointer which the editor will generate when applying the patch, the third part is another part of some hex. You always need to input a Hook String for all of them, the pointer should be written with an escape character P. Also, the first part and the third part of the hook even the P can be non-necessary. So you can do something like replacing a pointer from a function pointer table, or apply several bytes of changes to the rom without jumping out to excute new code. You can even use some inline asm in your C code to get or set regesters and stacks, but this is compiler specified. Btw, all the patch address should be on the source code part, so you cannot apply a patch on another patch. And goldensunboy add identifiers check in the code file when loading them, so all the params in the dialog can be auto-loaded if there are some identifiers in the comment in the C code file. To use patches made by others, you even don't need to understand the detials of their code, and don't need to read their code file, you can directly apply it using the editor to some degree (if there is no conflict between patches).
Goldensunboy made it that all the patches you use the editor to inject into the rom removable. so it is flexible enough that you don't need to always develop the patch first, and apply them into the rom with hardcode address, then use the editor to edit other staff, so any corruption to the patch will currupt the rom. We don't have these problem. if you don't want some pathces anymore, you can remove it anytime you want.
It's a really exciting news that this finally came out, now we can dream about the future of wl4 hacks with all kinds of customized things, we reached a new stage in our community.
P.S. Goldensunboy said he will going to make some tutorials to help people making hacks and understand this feature soon, i think if you want to make your own patch, you still need to understand the reversen engeneering work on the rom we have done, and you need to be able to understand arm7 code and C programming language.
1592363795231.png

1592363836877.png
 
2020 July, August and September Progress Report
We are really gratitude to our beta testers in the discord server who help us testing all the new features we have added into the editor this year while exploring the posibility to try modifying every levels in the game. they help us keep thinking about the method to make those new features more user-friendly, and also help found a lot of bugs and problems we have made in the code so we can make the editor much more stable. About 3 months after the release of beta-10, we make the beta-11 and beta-12 builds, continuously trying our best to make the editor more stable before we are going to overhaul the base classes code and mess everything up again. the whole changelogs for beta-11 and 12 can be found here. (changelogs of future releases will squeeze down the previous changelogs)
So, beta-12 is the best choice for almost everyone, you only need to take care of some really old known issues in the github repository with a red bug tag, Besides all those bugfixes, there are a lot of small GUI tweaks and addings around in all kinds of editors, you can try to use those small but important new features to make your levels with more variations. and people in the server even found the method to modify some levels (especially Domino, Roulette levels) with the patch feature and event tiles. Now we are completely sure that you can edit every level in this game using the functionalities in the editor and even make your own level with new customized features.
Due to the NintendoGigaleak 2 (not all the source code, just a little, everything else are in some o files with debug symbols), we are able to look into the game engine and the reverse engeneering work becomes much easier. So in the near future, we will be able to make customized enemies, modify wario engine, use the 4 gba graphic layers more freely and flexibly ingame and making new cutscenes. everything will be possible using patch, you can write C patch to do everything.
Sorry for making this report so trivial, i am a bit lazy to point out the important update details in the new builds. i just did the necessary things in this report. Also i am going to hide the details of the base classes code overhaul so i have something to talk about next time. :wahlaughback:
 
2020 October, November and December Progress Report
We made a lot of progress in the past 3 months, and made beta-13 build recently, you can found that in the release page of our github repository. More bugs has been fixed and there are some new features too.
The first thing is i rewrite the enemies graphic data loading code and hardcode all the enemy oam data in the editor. oam data is a sprites rendering format used by the GBA engine, we use that to draw the enemies in the editor too. The reimplement of this part of code help us fix most of the enemies rendering problems remained for a long time. Now in the lastest build, you can open the door config dialog and see almost all the enemies are rendered correctly.
The second thing is we make sprites and spritesets be global singletons, so we finally implement the sprites editor:
1610677878463.png

The left side panel is used to edit tiles and palettes used by single enemy, you can import and export tiles and palettes and edit colors just like what you can do in the Tileset editor. The right side panel is used to configure spriteset. Editing the load table at the bottom of the panel to set the offset of specified sprites (and palette as well) to customize your spriteset. BTW, the game has some extra blank slots of spriteset you can used, so you don't always need to discard some used slots. The middle panel is used to design sprites. You can use some conbination of the tiles showed in the left panel and then set each of them with suitable parameters to make one frame of graphic, and the designer can generate the oam data of the graphic you design. it can be used to make custom sprites animation or even brand new enemies with the help of patch feature in the editor. It is really hard and time-consuming to customize enemies, but i think i will make a tutorial when i have time.
Goldensunboy spent several months overhauling the save engine and the patch engine to try make the patch engine to be able to do more things in the past few months, and he did it. before the overhaul, we even cannot write switch case or use const array in the C code. The switch case will be optimized using memcpy which we should provide the address to the linker using some function fomr ingame. the cmost array things need some gcc linker script so they can be correctly bind together with code and be patched into the rom. Both of them are hard work, but we did it, finally. Thanks a lot to Goldensunboy. Without supporting these features, it is impossible to write patches to customize new enemies. At least, now we make it possible.
Another new thing we have is the Credit Editor made by Kleyman:
1610679211608.png

You can type in letter in those cells and right click them to pop up a instant menu to configure their types. There are 2 types of letters, one-tile height and two-tile height. You can find how they are used differently in vanilla game.
There are a lot of bugfixes and functional tweaks in the past 3 months. they can be found in the changelog as usual. The editor has reached a period which can be used to make big project, most of the things should work. But we still suggest you to back up your modified rom every time you save changes to the rom. We can find and repro problems (if it happens) you found in the editor quickly, and you won't lose your progress a lot when making hack. Don't wait for the v1.0 build all the time, it is impossible that we can eliminate all bugs, and there are a lot of new ideas and things we need to implement. v1.0 will still need a lot of months to come out perhaps.
We will keep working on the editor and hope there will be more people start making Wario Land 4 levels.
 
The First Half of the Year 2021 Miniature Progress Report
In the first 3 months of this year, we did multiple fixes on the save engine and the patch engine. Since the patch engine got its version 2 release at the end of last year and the save engine got modified at the same time because of the dependency relation. we found a lot of severe bugs in the code. There are multiple bugs and it is really hard to find the real causes and figuring out the best way to fix them. so it cost a lot of time, and we made several small releases after beta-13, which shows how we struggled with the bugs at that time. The last release build you can find on github now is 0.13.5. it finally solved all the bugs we found in the save engine and the patch engine. Though it is not perfect, and we made more tweaks after that in our dev branch, at least that build is stable to use.
Then in April, June and July. besides more bug fixes. we add some trivial features (some of them are not perfect still) like Nintendo intro check when loading the rom so you won't load some rom cannot be edited by the editor; Tileset importing from another rom which can be used to help with hack projects cooperation by multiple people. This new feature is also useful to deal with another problem i will explain next.
3 months ago, beco found he run out of space in his hack which should be impossible on some normal hack. then Goldensunboy found it is caused by another new severe bug in the save engine. it was unable to invalidate old save data when you edit the same things and the editor try to replace old data with the new ones. (it is not how it works but easier to plain it like this) so there will be more and more useless data (we call it orphaned chunks) in the rom's free space and will gradually used up all the free space when you keep editing a rom more and more times when you are making some new WL4 hacks using the editor.
Currently, the bug itself has been fixed once it got found. And the hotfix builds can be found in the announcement channel of our discord server. But we still need to write some new features to remove those orphaned chunks then defragment the existing chunks or people cannot use some 3-rd party tools to edit other things they want to change like the music of levels. those tools sometimes need to find free space in the rom and import new data into it but their saving logic are imcompatible with our editor. (this is also why we always need to complete the work in the editor first then do the music changing work using some other tools). So in the last 3 months. we were working on 2 new features: chunk manager and hex editor. We hope these 2 new features will be able to let both our developers and also wl4 hacks creators be able to view and edit low level data and things, which can help find new save-engine bugs for our developers or manage data for hacks creators manually and visually.
The 2 new features are really hard to implement. We have made some progress but there are more things to do. On the other hand, me and Goldensunboy are either busy with our own things or unable to program due to circumstantial problems, the development speed is slowing down recently. that's all the reasons we don't have new releases in the past 3 months.
That's everything i want to talk about for now, and if you want to use the editor, better get the builds from our server but not the github release pages. we build-in more bugfixes there. Or, if you know how to build the editor, you can always build the lastest chunk_editor branch for the newest things.
 
I just want to say that the work you both are doing on this editor is really fantastic. I've been playing Wario Land 4: Parallel World, and it made me excited to play Wario Land again. Keep up the great work! I hope even more people will be inspired to create some fun and creative Wario Land 4 levels.
 
  • Friendly
Reactions: 607
2021 July to 2022 June Progress Report
After the suspending of the chunk manager and hex editor feature , our devs just hung new feature developing for almost a year. it is so regular for our devs to be not active for a period of time. During that time. i just did some bugfixes here and there. then add some small features when i have a little bit of free time and motivation. so i never got a chance to post something new here.
At Feb, 2022, i think i finished my work on a journal paper and wanted to turn back to this project again. so we made a new release build at that time and i wanted to work on some new stuff. then several weeks later my paper got rejected. then i had to resume working on the research and paper things. then the paper just kept being rejected and i have to keep working on it. it feels like shit. Researches is never some good experience for most people i think. okay, no more venting crap. let's talk about the new feature i am working on recently.
A lot of people complains from time to time that our editor is unable to change layer3 in Rooms. now in a period when the AI art generation model like disco diffusion (dd), pixel art diffusion (PAD) keep poping up on the research field and we are able to use google collab to generate our own art by AIs. I kind of want to use AI to generate some good pic and put it into the layer3. i also want to use AI to generate completely new Tileset for me to make completely new Tileset. then i start to try those AI models by myself. Then i found, the first idea can work but i need to implement some new feature to support importing graphics into layer 3. the second one cannot be done using the current AI, or at least there is no engineering method to do that conveniently. Then, i started implementing a Graphic Manager to save palettes, tiles and mapping data used by graphics into entries. so people can using graphic and managing those 3 types of data in one place.
1655554995701.png

the Graphic Manager will seek through all the existing layer 3 from all the Rooms in all Levels on the first run. when you save it, you can change layer 3 pic in any Room. Due to the game's data managing logic, you need to change background tile8x8 set in the Tileset Editor, then change the tile mapping of layer 3 in Room Config Dialog, to modify the layer 3 pic used by a Room. You can import palette, Tile data and mapping data from vanilla ROM. if you want to use some custom pic, you can also import data into all those 3 panels. the logic to import them is similar to how the Tileset Editor work.
Another thing i want to talk about is the palette. you can only import background type entry at the moment. at first, i thought all background pic only use one palette, and its index should be always 0xF. then after i trying to load all the layer 3 pic into the Graphic Manager. i found the palette used by background pic is not always 0xF. what's worse, i found sometimes layer pics use multiple palettes and those palettes just scattered around whch can appear in any place in the whole palette ram. So, my previous design of palette metadata in the graphic entry cannot work for all of those layer 3 pics. so you can find several entries like the one above in the pic cannot load correctly. I am not going to overhaul the backend things for them, as long as most of the other entries look correct. Since those bad entries won't cause logical problems in the WL4Editor, i don't need to remove them from the whole generation list. You can always remove them by your own manually if you want. Also if you want to import custom graphic, i made it that you can only use 1 palette for an entry for now.
In the Tileset Editor, the background tile import logic will check if the palette(s) used by entries are not used in the foreground Tile16 set to decide if it can replace the palettes when replacing background tiles. i think this can force users to pay attention to palette using, and their foreground Tile16 set won't get changed suddenly when replacing background tiles for Tileset and changing layer 3 for Rooms.
the new Graphic Manager has been developing for almost one month. it is getting stabler and i put the least things i want into it. So new official release will be built soon. After that, i will add some other features into the Graphic Manager and relative Editors to make it more flexiable and also give it more potential.
I am not going to mention the other things about the new Graphic Manager or small new features here. you can explore by yourself when we make new release, Or you can join our discord server and get beta-tester role to try it by yourself now.
 
Back
Top