Tool: [Alpha] (MEH) Map Editor of Happiness

Gorrioncillo said:

So, soon or later it will be a DNS system, that's great but i prefer as soon as you can, please

Click to expand...

Don't rush him. Honestly, I'd rather have a functional, working map editor than a rushed DNS system.

This seems fantastic so far! Well done. :)

It would be nice to see a "tileset chooser", so we know while tileset is which, instead of picking a number and guessing which one it is. If this was added already, ignore this part. :P

a little question, is it possible to make the extended pokemons(using karate's GH3S) on the wild pokemon tab so their names would appear? a little tweaking of the ini, maybe?

Wow this is awesome :D!
When its ready to make hacks with. I Will swap it out with A-map

pengoy said:

a little question, is it possible to make the extended pokemons(using karate's GH3S) on the wild pokemon tab so their names would appear? a little tweaking of the ini, maybe?

Click to expand...

I was also wondering this, because if this could happen, it would make my life so much easier!

This tool looks really cool especially the connections tab, hope it gets completed soon

Alrighty, it's time for another weekly-ish update. To begin, things have been going rather slow due to school. I have however gotten a bit of work done, so let's get to it.

First order of business is a fix to a somewhat rare bug which caused the secondary tileset to not appear in the block picker. Basically for some reason in certain versions of Java on certain OS's, Java's graphical renderer could not render an image as large as the tileset I was trying to draw. If you had this bug prior and it's still having issues, just let me know and I'll try to find another possible fix.

Second item on our agenda is the addition of support for diegoisawesome's triple layer tile system, which allows you to have 3 layer tiles using certain behavior bytes. However, in it's current state it's just a visual implementation and there isn't an inserter available quite yet. Also, since the behavior byte editor isn't quite in there yet either, you can't actually set a tile to be a triple layered tile. My only issue with the current implementation of the triple layer tile system is that it's rather inefficient, requiring that you sacrifice an extra block just to have a triple tile. What I'd like to happen is have the ability to specifically choose which block to pull an additional layer from, which would easily compress the amount of space by removing the need to pull specifically from the next block.

Here's a good screenshot before and after the triple layer tiles:

Before:


After:

Small shoutout to GoGo for letting me test with his hack.

Also, the map screenshot function has been added, so you can use the File > Save Screenshot to PNG... option. By default the file menu formats it by it's bank, map, and the map name so that you know exactly where the screenshot came from. Obviously you can rename it whatever you want as well, but the default name adds an additional convenience to saving.

EDIT:
Small notice, but I have in fact created a successful triple layer tile hack for Fire Red which will eventually allow you to create a block with the bottom 2 layers and then select a block which contains your third layer. So if you need to have an object behind a tree, but you still need those two layers, you can use the triple layer tile hack to select an existing block which uses the tree in it's foreground.

There is however some bad news, since this hack utilizes about 10 unused bits in the behavior/bg bytes, Emerald (and maybe Ruby depending on if their system is somewhat sane ASM-wise) will be unable to use this hack. This is because RSE only allocates two bytes (one byte for behavior, one byte for bg) instead of the four that Fire Red has for behavior/background bytes. I believe there are only a total of 4 unused bits so I might be able to work out a system which lets you select a top layer from the first 16 blocks, but for now it will probably be using diego's system which will require two blocks for 3 layers.

Shiny Quagsire said:

EDIT:
Small notice, but I have in fact created a successful triple layer tile hack for Fire Red which will eventually allow you to create a block with the bottom 2 layers and then select a block which contains your third layer. So if you need to have an object behind a tree, but you still need those two layers, you can use the triple layer tile hack to select an existing block which uses the tree in it's foreground.

Click to expand...

This is great news, now I can finally put complex tiles into a map without taking up all the space in the tileset.

Wecanhazaphlanow? So is this only going to be firered and not ruby?

Wendle said:

Wecanhazaphlanow? So is this only going to be firered and not ruby?

Click to expand...

I'd say we're pretty much in the alpha stage now. And the 3-layer tile hack is Fire Red only for now due to the fact that only Fire Red has 4 bytes for block behaviors while Ruby and Emerald have just 2, which isn't nearly enough. I might find a way to get around this but for now it's only for Fire Red. And I don't have plans at all for supporting Leaf Green and Sapphire unless someone feels like porting the existing code.

Double posting because significance and stuff. If it's an issue to the mods, feel free to squish this in with my last post, although from previous updates it hasn't been an issue. That aside,

Triple-Layer tiles are officially implemented into MEH, complete with patching and block selection. Basically how it works is another, smaller box has been added in with the block editor:



If you click on it, you will be notified that you have entered triple selection mode. Basically what this means is that the left-hand block selection pane has been turned into an input zone, so whatever block you choose next inside it will be the block used for the triple-layer tiles. As soon as you click, the small block will change to hold that tile and all the blocks on the current map will also change. As of now there are no bugs, and existing block properties are retained. To disable a triple layer tile hack you can select block 0, which (hopefully...) is defaulted as being completely blank.

As of now there isn't a behavior byte editor, but that is coming next. It will allow you to, instead of providing a bunch of bytes, select specific properties of the block, ie block behaviors, block BG priority, if it's a wild data block (grass, surfing, etc), and other things, no byte editing requires. However, you will still be able to modify the core byte structure as you please via a textbox.

As usual, download is in the main post, because it is always pointing to the latest release. Feedback is welcome, and if there's anything you'd like me to work on next let me know because I finally have a whole summer to work on it. :)

Shiny Quagsire said:

Double posting because significance and stuff. If it's an issue to the mods, feel free to squish this in with my last post, although from previous updates it hasn't been an issue. That aside,

Triple-Layer tiles are officially implemented into MEH, complete with patching and block selection. Basically how it works is another, smaller box has been added in with the block editor:

If you click on it, you will be notified that you have entered triple selection mode. Basically what this means is that the left-hand block selection pane has been turned into an input zone, so whatever block you choose next inside it will be the block used for the triple-layer tiles. As soon as you click, the small block will change to hold that tile and all the blocks on the current map will also change. As of now there are no bugs, and existing block properties are retained. To disable a triple layer tile hack you can select block 0, which (hopefully...) is defaulted as being completely blank.

As of now there isn't a behavior byte editor, but that is coming next. It will allow you to, instead of providing a bunch of bytes, select specific properties of the block, ie block behaviors, block BG priority, if it's a wild data block (grass, surfing, etc), and other things, no byte editing requires. However, you will still be able to modify the core byte structure as you please via a textbox.

As usual, download is in the main post, because it is always pointing to the latest release. Feedback is welcome, and if there's anything you'd like me to work on next let me know because I finally have a whole summer to work on it. :)

Click to expand...

Personally, I'd love to see a World Map editor! That would be so awesome!

I've tried the newest MEH and I have two issues:

1. At the end of the tileset MEH shows some garbled tiles whereas A-Map doesn't. Also you can still select tiles that don't exist.


2. The Triple-layered-tile works great though when I tried to apply the patch it appears like this so i can't actually see what I'm supposed to press (I got it to work though):


I'd love to see the ability to edit multiple blocks (top layer) at once (it would help importing big buildings etc).

slawter666 said:

I've tried the newest MEH and I have two issues:

1. At the end of the tileset MEH shows some garbled tiles whereas A-Map doesn't. Also you can still select tiles that don't exist.

Spoiler:

2. The Triple-layered-tile works great though when I tried to apply the patch it appears like this so i can't actually see what I'm supposed to press (I got it to work though):

I'd love to see the ability to edit multiple blocks (top layer) at once (it would help importing big buildings etc).

Click to expand...

The issue with the blocks isn't something that can be fixed easily at the current moment, mostly because of the fact that there's no in-ROM definition stating how large blocksets can be. So instead I decided to essentially overdraw more blocks than needed to ensure all blocks were visible in all maps. And I can fix the triple tile dialog easily, so thank for letting me know that the GUI there is slightly off. I didn't notice it under Linux simply because my font appears to be smaller than the Windows font.

And in regards to the ability to edit multiple blocks, I'll consider it. It might not get in though because of how I have things set up right now, but it may be possible after I clean up MEH's code a bit.

I'm loving this tool. I can't wait until it reaches a stable point so I can finally use this for hacking. I've got a question, though: Is it capable of inserting completely new map names/headers? I remember this was previously impossible with AdvanceMap.

PrimeEchoes said:

I'm loving this tool. I can't wait until it reaches a stable point so I can finally use this for hacking. I've got a question, though: Is it capable of inserting completely new map names/headers? I remember this was previously impossible with AdvanceMap.

Click to expand...

As of now, no, although I recall setting up the structure for it a while back. The main issue (similar to the issue with blocks) is that there's no way to tell how many there are to be loaded. However, unlike the blocks where I just loaded more than needs be, I told it exactly how many per bank to load. A-Map does a similar system. The only solution will come when I implement per-hack settings, which will allow hackers to specifically limit and tune things according to their hack.

On another note,

I'm making a Day/Night system which will be implemented with MEH and compatible with A-Map. The difference? More control.

Allow me to explain how this new Day/Night system will work. With most Day/Night systems, you have your normal palettes that you edit and mess with, and when you apply the Day/Night system no extra work is needed to achieve different colors at day and night. In other words, it uses filters, where parts of each color are taken out at the expense of customization, color tuning, and heavy CPU usage. With this system, based on the system used in diegoisawesome's CrystalDust (and Shining Opal as well), you will have four separate palettes for each time of day, and perhaps optionally, more. While this consumes more space in the ROM, the space difference is barely marginal and the benefits are huge. As seen above, glowing windows are a possibility, since you don't have filters rushing to quickly filter out certain colors. Morning, night, and evening palettes will no longer murder your eyes, and you can fine tune the colors to your liking, making hacks using this Day/Night system more diverse and interesting, especially when combined with time-based Pokemon which can add a whole new element to RTC enabled hacks besides aesthetics. And best of all, the current implementation allows compatability with A-Map, with A-Map defaulting to the daytime palette while the other palettes are viewable in MEH.

In addition to those benefits, this D/N system will feature compatability between Emerald, and Fire Red, and (maybe) Ruby with Ruby and Emerald using the existing RTC instead of completely disregarding it and using the system date/time. This means that the time you set on the clock actually matters now, another benefit inspired by CrystalDust.

A few issues with this system, however, have to do with the palettes. Obviously, setting each and every palette to your liking, while being quite powerful and useful, can be a bit of a headache, and repointing and expanding existing palettes is no fun at all. So to remedy this, when you switch to the new Day/Night system, all existing palettes will automatically be converted to the new system, and a dialog will allow you to edit the color settings for each time zone across all maps. Specific colors can be adjusted on a per-tileset basis, which will allow you to configure each color individually.

Another issue is overworlds, and I have yet to come up with a good idea to solve this. There are actually two ways we can remedy this. The first, and easiest way, is a hybrid system where all map tiles use their own palettes, updating appropriately with time, and a filter system for overworlds and other particles. This will make overworld editing easier at the cost of the overworlds either looking out of place or other adverse effects. The other option is to do the same thing we did for maps, where we extend the palettes for each time zone and use MEH to automagically D/Nify them. If there's any particular way you'd like to have this happen, let me know. I'm leaning towards a hybrid system, but I might change my mind if there's enough support for a nonfiltered system for this new D/N system.

EDIT: Here's an example of what you could potentially do with this system:

I whipped up a small bit of code in MEH to blend in some nighttime colors, and then I tuned them to add the glowing windows. Looks quite nice.

WOW a new DNS is awesome

And it sounds like by not using filters, this dns system wont break compatibility with flashcarts and the real gba? Thatd be awesome if it didn't

GOLDstandard said:

WOW a new DNS is awesome

And it sounds like by not using filters, this dns system wont break compatibility with flashcarts and the real gba? Thatd be awesome if it didn't

Click to expand...

That is correct, it will maintain compatibility quite easily. Although I wasn't aware that most DNS systems broke under flash cartridges, good to know.

So the windows lighten up will be automically put up if we enable the DNS system or do we have to manually assign it? I'm kinda confused on this sorry.

CosmicBlazer said:

So the windows lighten up will be automically put up if we enable the DNS system or do we have to manually assign it? I'm kinda confused on this sorry.

Click to expand...

Basically the premise of this D/N system is that you can specifically control your palettes for each time of day. So, after applying a filter using the dialog that will be added, you can go into each individual palette and tune things up. In this case, I modified the windows to use a separate palette which will glow at night (the existing one is used by ponds, so directly changing that one would cause ponds to glow yellow). You can also specifically select the color of tinting to use, which will result in better tones, which can be as soft or as harsh as you'd like.