GUI is somewhat broken

[darkf]

Screenshot: http://i.imgur.com/h5Y4bnq.png

On an Intel integrated GPU.

Looks like some of the GUI elements are being placed wrong and the mouse cursor picks them in the wrong position.

[sheepandshepherd]

Strange, I haven't seen this bug before. Looks like the ImGui elements are being rendered higher than they should be (the sidebars have their positions at y=0), while mouse position and glScissor are correct. The issue could be the functions in ui.d that communicate between GLFW/OpenGL and ImGui, but I haven't found anything wrong yet (it works correctly for me).

To help narrow down where the bug is, I included the ImGui OpenGL examples and the ImGui D test in the latest release. If you can run those 3 tests, let me know if any of them also have this bug on your system.

Edit: Also, I accidentally broke the imgui_d_test.exe in the release by putting it in a separate folder. It needs cimgui.dll, so just put those two together again before running it.

[darkf]

All of the imgui examples seem to work fine ( http://i.imgur.com/mehNgG2.png ). I'd suspect it is indeed an issue in geotool then, (un)fortunately.

If you have any ideas, I'd be fine with testing.

(Unrelated / quick digression: I've ported portions of geotool's map rendering code into another language (not exactly one-to-one but close enough), would you be okay with me licensing this under a non-GPL license (probably MIT/Apache2 or even MPL) or rather stick with it?)

[sheepandshepherd]

Sure, I don't mind. I'll change it to MIT license with 778a50c. Out of curiosity, is it for an engine remake?

I'll keep looking for this UI bug and add some tests to the next 0.3.1 release.

[darkf]

Thanks so much @sheepandshepherd! That's incredibly helpful. ❤️

It is, actually! -- I figured it would be easy enough (at least compared to previous efforts of mine) since the game is not incredibly deep mechanic-wise and its scripting language literally consists of 5 operations. :)

I've got the part that I dreaded done -- map rendering -- thanks to your work. I now need objects (from the .ol), minifig units, AI, scripting and other mechanics like erosion/landslides/vehicles.

I wonder if you couldn't support the object layer in geotool via loading the .LWO/.Xs with assimp or similar...

[sheepandshepherd]

I'm glad it's found some use! I kinda miss working with old games like LRR, but the incompatible/unstable engines are a pain. LRR's a good choice for a remake, if you find a way around the ugliness of the mesh format and the big Lego.cfg file.

Anyway, this UI issue might be caused by the framebuffer being a different size than the window, something that wasn't accounted for by my UI code. It would explain why the UI in your screenshot is getting stretched out despite having correct coordinates. The original C++ ImGui implementation had a fix for this that I hadn't added yet. Does this update fix it for you?

Otherwise, the debug version now lists the GLFW and framebuffer sizes in the left sidebar - are they equal or different on your PC?

[darkf]

@lrr - Indeed, playing the game is a pain. I have a dedicated WinXP VM running in 640x480 to run the game, and I still have to deal with the game's bugs.

I'm not sure what I'll do for loading the LWO/LWS meshes/animations yet. I might either convert them (with blender or assimp or something) or just bite the bullet and write a loader (something I am inexperienced with -- I'm not really a 3D programmer!)

In more positive news, the remake is coming along nicely -- it's rough, but I can complete the first level by having units (denoted by yellow cubes :D) "drill" through walls (although this is rough: I don't change the heightmap. Say, would you happen to know more about how the heightmap should be changed with drilling, and how the duggmap affects things? What about drilling affecting adjacent tiles?) and collect ore in the toolstore.

I've written a NERPS script interpreter so it's actually executing the original bytecode, and that's working out really well so far. :) It's fun having the real game logic handle things instead of hardcoding it.

Really if you could share information on how NERPS works (the old RRU wiki has a few tidbits but most of it is untested), and the map format, how drilling and landslides/caveins/erosion/etc works, that would be fantastic.

---

No, the coordinates match up 1:1. But I may have found the issue: it works fine if I resize the window any time after starting it. It must be laying out to the wrong coordinates at first.

[sheepandshepherd]

The old wiki is mainly where I learned about the map formats.
Some of it depends on how your engine works, but here's a quick summary of how the heightmap works in general:

• The high values are for the north-west vertex of their grid square. So each grid square also uses highmap[x+1, y] for NE vertex, highmap[x+1, y+1] for SE vertex, and highmap[x, y+1] for SW vertex.
• A ground square (ground, water, power path, etc) has all 4 vertices exactly at the highmap levels.
• A solid square (solid rock, loose rock, etc) will have some of its vertices exactly 1 unit above the highmap level. Specifically, any vertex that doesn't have Ground in any of the 4 surrounding squares will get +1 height.
  (Unfortunately, selecting the right texture and UV coordinates for a square complicates things, which is why the Map.buildMesh function in geotool isn't that simple at all.)
• Most importantly, a square's height isn't modified when drilled; instead, drilling just changes the terrain type of the square to Ground.

Regardless of how you store the map data, I'd suggest having a function like Map.buildMesh(x, y) that just updates 1 tile's mesh. That way, when your RRs finish drilling a wall, you can set the terrain to Ground and call buildMesh on the tile and each of the 8 adjacent neighbors.

I don't know anything about NERPS, but there is a NPL tool that you could examine. The RRU forum can assist if you have any questions. I'll gladly contribute for map data and 3D stuff, for example.

---

Thanks for finding that window issue! I'll have to call the resize function once right before the main loop starts. Will add this to the next update.