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

Cirras posted: (31st Dec 2016, 08:21 pm)

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.

That's plan, too! It should be something like ctrl+click to pick a tile. Also, playing with the palette, it looks like it would be really handy to have shrunken down versions of the graphics instead of the entire full-size graphics laid out.

I can see a pretty neat looking UI in my head, little thing in the corner showing the current layer, coords and shrunken down selected tile graphic, picking objects with ctrl+click, so holding ctrl should also work to transparent all the other layers, and ctrl+scroll should scroll between the different layers?

I really need to figure out how to get my own rendering embedded in these GUI windows though, kind of stuck on that right now.

Sausage posted: (1st Jan 2017, 09:00 am)

Cirras posted: (31st Dec 2016, 08:21 pm)

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.

That's plan, too! It should be something like ctrl+click to pick a tile. Also, playing with the palette, it looks like it would be really handy to have shrunken down versions of the graphics instead of the entire full-size graphics laid out.

I can see a pretty neat looking UI in my head, little thing in the corner showing the current layer, coords and shrunken down selected tile graphic, picking objects with ctrl+click, so holding ctrl should also work to transparent all the other layers, and ctrl+scroll should scroll between the different layers?

I really need to figure out how to get my own rendering embedded in these GUI windows though, kind of stuck on that right now.

That's a good concept! I assume the layer you're selecting would default to the layer that you're already working with in the palette.

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

Day 3/4 is posted on page 1!

A lot more words this time I think.

Would it be possible to tag certain items to combine them? Like Each separate piece of a house is tagged together so you can just drop the finished product? Like maybe let the user set like House 1 and go in and pick each item for down and right walls in order and then it lets you plop them down(Using like the last down wall as a reference for placement) each time you select house 1 again.  Also this could work as a cool save feature for making a generic house or map that you want to use over but change only a few things each time instead of having to preload each map you like you could just assign a name to it in a drop down window to repull it back up

Sausage posted: (30th Dec 2016, 06:28 pm)

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.

That's an exciting update! Nice work getting the layering all working.

In current EOmap, objects are one thing that are aligned slightly differently than in the client itself, which causes some unfortunate mistakes to occur in development scenarios at times. This is most notable when objects are being used in a close, interlocking way with walls.

I'd love to see the alignment of objects be reassessed in this new mapper.

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

Cirras posted: (2nd Jan 2017, 11:52 pm)

Sausage posted: (30th Dec 2016, 06:28 pm)

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.

That's an exciting update! Nice work getting the layering all working.

In current EOmap, objects are one thing that are aligned slightly differently than in the client itself, which causes some unfortunate mistakes to occur in development scenarios at times. This is most notable when objects are being used in a close, interlocking way with walls.

I'd love to see the alignment of objects be reassessed in this new mapper.

With walls, which is only problem I ever had with this stuff is because of the surrounding black space on the sprite sheets; so this type of thing can be fixed if given correct dimensions that vult-r has set out already within the GFX files (Not sure if there is any other problems with it, but this is what I found out by tinkering around with stuff). Although it would be cool to have it work exactly how the client handles it, because after all that's what you're going to be using it for.

All I really care for is that the palette remembers where you were when you're changing tabs. Once you got that, I'm a happy motherfucker.

---
"Nurd, you're like a fucking swiss army knife" - Necrosis

I have some ideas that you might consider :

• Ability to add new tiles/objects/etc. directly to the gfx files without using a resource tool ( like a drag and drop ? ) 
• A built in Map Screenshotter so we could picture the whole map to preview what it looks like  or just a zoom in and out feature would be nice.

Anyways, keep up the good work Sausage :) 

Staying accurate the EO client is much more important this time around since I want to use the map renderer for one. If it means hard-coding more things then whatever. I noticed some overlapping issues in EOMap vs the EO client when I was making my sinkholes that I want to rectify too.

I'm planning on an export to PNG option because it's a very small and easy addition. Zooming as well, for both the map and palette views.

Adding graphics through the editor sounds potentially doable, since I did that with the EE patcher, but that used Windows-specific APIs. I'm not sure I'd get around to doing it before adding pub editor features.

Also been busy with other things the last few days but I hope to get more done soon. ✌️

im really looking forward to seeing this in its final release

---
Insomniac:I like how in the lounges forum description sausage says "Bitches go crazy." and that's
exactly what you do!
Pixel artist | Mapping artist | Alternative artist | Heavenly Karma | oldbie | top 50  |
Attention whore | main player |

Looks nice, cant wait to use it. Keep up the great work with eoserv.

Sausage posted: (7th Jan 2017, 10:40 pm) since I did that with the EE patcher

Woahhhh you did Apollo's patcher? I knew that guy can't do anything alone!

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Hacker_Alex posted: (8th Jan 2017, 06:03 pm)

Sausage posted: (7th Jan 2017, 10:40 pm) since I did that with the EE patcher

Woahhhh you did Apollo's patcher? I knew that guy can't do anything alone!

Sausage's knowledge is well beyond anyone in this community, and at the time EE patcher was created I was probably a year or so into this project. The entire system requires a backend as well which is a pretty complicated deal even as a completed interface. But hey, if you know someone else that made one of these in this community just let us know. Don't worry, I'll wait. In the mean time, I will be working on a couple of projects that don't involve bumping a bunch of old posts on a weekly basis.

Moonie posted: (8th Jan 2017, 12:23 am)

im really looking forward to seeing this in its final release

I know. As someone who recently got back into mapping for fun this would be great for trying different approaches at mapping (time saver).

---
Something I do instead of sleeping

I admit this going to be an off-topic post, but it's better than an off-forum topic .

Wouldn't it be good to make a section for blogs next to "Home" "Download" "Dev" "Wiki" , etc , where people could post their eo-related (only eo-related please) projects and news about it.