Forum :: EOMap :: EOMap "Next Gen" Development Blog

First time trying something like this, I'll try post updates on the development process of the next version of EOMap. Probably lots of posting screenshots of stuff and complaining about bugs I can't work out.

In-development source code visible here: https://github.com/eoserv/eomap

Intro

EOMap "Next Gen" (which I'll refer to as just "EOMap" from now on) is a rewrite of the current version of EOMap. The old source code is quite a mess to work with, seems to crash a lot, and is full of Windows-specific code which makes it impossible for me to work on anymore. The aim of the rewrite is to replace the UI with "in-game" widgets, and hopefully write it in a way that it's not such a pain to add new features in the future, and release it as an open source project.

In the future it would be nice if I could expand it in to a general-purpose EO editing program (i.e. pub files).

Day 1

Basically took all of the code from my current EO client relating to graphics loading and rendering (though I soon end up completely gutting this and reusing almost none of it), with the goal of adding map rendering and editing features to it.

First step was to play with a GUI library I've been wanting to try called "dear imgui". It's a bit awkward to work with, but it looks alright! Should have enough flexibility to implement some nice npc/chest/warp editing GUIs. Hopefully I can figure out how to render the palette inside of a window so it can be moved about and resized.

Day 2

A map editor that can't render any maps isn't very useful.

Unfortunately my first attempt was plagued by a pain in the ass rendering problem:

After a few hours of trying to track that issue down, a perfect little Aeven house! ... almost:

Okay I'll just make some changes to the rendering system to support a depth buffer and... Oh no, Aeven is in ruins!:

A few minutes of banging my head against the wall and all was well again. But now I need to go through the process of making the tiles overlap properly, and hopefully tomorrow I can start implementing some mouse controls.

Performance is looking great so far. With the Aeven map open it's around 4ms/frame to render a full-screen 1920x1080 window on my PC.

Random blooper... Still a long way to go... And I probably need to clear the old map before I load in a new one.

Day 3/4

Happy new year and stuff. Biggest achievement of this post is the smallest of details: The objects on the maps now overlap correctly as far as I can tell.

To achieve this in the fastest way possible (making use of the depth buffer allows all tiles of the same type to be drawn in batches using the same texture atlas) I made somewhat creative use of the depth buffer as seen here: map_renderer.cpp.

The map is broken down in to major layers from bottom to top, with completely discrete depths to overlap each-other completely:

• Ground - spanning the depth range of (1.0, 0,9)
  
• Shadows - (0.9, 0,8)
• Objects and Walls - (0.8, 0.7)
  
• Overlay - (0.7, 0.6)

In order for tiles in the same group that should be visible in front of others according to their "distance from the camera" (in the isometric view, tiles with a higher x/y axis), each tile is drawn 0.0001 (four zeroes) units closer than the last. This puts, e.g., the trees further south of the building to render above the wall tiles of the house, and the trees north to be behind.

Some real magic comes in the form of the per-layer offset, where the depth of each tile is increased by just 0.00001 (five zeroes). This offset is small enough to give individual layers priority over others on the same square, but not big enough to affect the per-tile ordering. This would allow tweaking of the priority of individual layers which are part of the same layer group, on the same square, hopefully to match the official client when I get around to it.

Note that core map rendering is still not 100% completed: handling of black vs blank tiles and animations are still not implemented.

The next thing to work on was the palette rendering, admittedly trivial since it just reused the atlas texture packing code. I think these objects look weirdly nice laid out on here the way they are, though I think it would look better with scaled down individual tiles for easier scanning. The algorithm is slightly different from the original eomap, but the main difference here is the palette area is skinnier. The packing code seems fast enough that dynamically resizing the palette area should be possible without too much lag.

The next part sucked up an unholy amount of time: Trying to get the renderings I just made in to overlappable GUI windows instead of just painted on to the background.

The code right now is still very unstable, but as you can see, it works (though not transparent). Also requires a bug fix in Allegro to work as it is right now.

This will allow primarily for having multiple palette windows open, but having multiple maps open at once seems like an easy enough thing to allow. Other than that, it was a pre-requisite for being able to create any kind of custom window, including the future undo history and anything else like status displays or tool palettes.

Ideally I'd like to have a maximize button for the map view which would fill the background and dock a minimize button in to the menu bar.

Next up is the basic input controls: scrolling about and having a cursor. Still a lot of learning to do with relation to playing nice with the GUI library and getting the full range of inputs working. Right now left clicking anywhere on a window wants to drag it.

....

....

Sweet can't wait to see this working!

This is exciting!

As an aside, I've always been interested to see your work process, so this is great. Do keep up with the blogging.

EDIT:

"// TODO: Check if map is modified and warn before clobbering"

... I know a mapper or 12 who will be pleased by that, incidentally.

---
Want to learn to pixel?
Pixelsource.org

Possible feature? It would be nice if you could add something to have pre-generated houses plopped. Some of the halowdale houses are missing some walls to my knowledge, and/or are otherwise a pain in the ass to selectively piece them together.

TLDR: Puts all the walls of "X" preset with one corner starting on "X,Y". Then you could just edit out some walls and rebuild it if you so choose. Idk, bad at explaining.

Edit:

Cirras posted: (31st Dec 2016, 03:24 am)

This is exciting!

As an aside, I've always been interested to see your work process, so this is great. Do keep up with the blogging.

EDIT:

"// TODO: Check if map is modified and warn before clobbering"

... I know a mapper or 12 who will be pleased by that, incidentally.

I would be one of the 12 I presume =P

---
Former multi-server mapper.

Nice! I've been waiting for this and it's pretty cool to see you have a development blog/github.

Yeah, several editors like Tiled for example, have a feature where they can take tiles/graphics, put them together, and then save them in the editor for reuse and this would be super helpful. Especially when it comes to remaking houses and etc.

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

I didn't expect you'd be working on a new map editor this soon. Can't wait to see more progress, and really can't wait till the day it's all done.
Good luck on this, it looks like you're making good progress already.

I know it's been mentioned before, but I really hope you add an undo feature! :)

---
EO Resources/Guides: â—„ eobud.boards.net â–º

Undo and painting down groups of tiles are probably the two most requested features. I'm definitely hoping to include them in the future. Undo is more likely to happen first.

Probably already looked into it and but the command pattern lends itself to giving you undo functionality without much hassle. Not really sure if design patterns are that easily to implement in C++, however.

---
If money doesn't grow on trees, then why do banks have branches?

DanScott posted: (31st Dec 2016, 03:45 pm)

Probably already looked into it and but the command pattern lends itself to giving you undo functionality without much hassle. Not really sure if design patterns are that easily to implement in C++, however.

Design patterns are pretty universal.

Keeping entire copies of the map is very feasible though, given even 100 fully expanded copies of a map the size of hell would only take 40MB of RAM (vs the 200MB of graphics loaded), or 3-5MB if I stored them packed similar to the EMF files themselves. I'd just be worried about the potential for lag after every action if the process was too intricate, but creating command lists is possibly just as intricate. Wouldn't be too out of place when put next to stuff like the draw command buffer though (which is gutted and does next to nothing in EOMap :p).

I had something like the photoshop-style undo history in mind:

Sausage posted: (31st Dec 2016, 06:01 pm)

I had something like the photoshop-style undo history in mind:

Please. I can only get so erect.

Perhaps we could get an Eyedropper tool as well? This would greatly simplify a lot of quick changes to maps.

---
Want to learn to pixel?
Pixelsource.org