Maintenance FacadeAWT

[Mike Kienenberger]

Name: AwtFacade
Summary: Subsystem to support drawing / viewing / manipulating Terasology in 2d graphics
Scope: Engine
Current Goal: Basic Dwarf-fortress-like interface to Terasology
Phase: Implementation
Curator: Mike Kienenberger (mkienenb)
Related: Headless Subsystem

Awt Facade currently supports NUI with some minor issues (no text input cursor, limited mesh drawing support). The block map draws (same way that Minimap works). Partial support for msteiger's City drawing code when zooming out to the point that a block is smaller than 2 pixels.

Fetch it with ./gradlew fetchFacadeAWT

Run it with ./gradlew awt

Controls:

• number-pad +(plus) ― zoom in
• number-pad - (minus) ― zoom out
• number-pad 9 ― shift viewpoint up
• number-pad 1 ― shift viewpoint down
• number-pad 4 ― shift viewpoint left
• number-pad 6 ― shift viewpoint right
• number-pad 8 ― shift viewpoint forward
• number-pad 2 ― shift viewpoint backward
• number-pad 0 ― toggle viewing axis between XZ (topdown), YZ, and XY

 

[synopia]

I dont really understand the purpose of this.

2d view of the world is nice, I did something similar for minecraft once. It is totally possible to render even big worlds in 2d using AWT/Swing. What I did for the minecraft architect, was to prerender chunks as awt images and reuse them.

But why to use AWT as an render subsystem and support NUI there? If you use AWT, you can just use AWT/Swing - its mature, stable, looks good and is fast. I would prefer a simplified Terasology facade, that starts a Swing application with all the Terasology engine runing but the renderer at all. So basically this is the headless mode + Swing UI to debug things.

If you want 2d top-down ingame graphics (which would be awesome), why not use normal NUI/Opengl? It could be a NUI screen which draws the tiles using the canvas renderer. Its even possible to just remove/replace the LwjglWorldRenderer - which runs terasology as usual but without costly 3d rendering (but you have the normal NUI to use).

Maybe I miss something important

 

[Mike Kienenberger]

Maybe I miss something important

Yes, you missed this:

http://forum.movingblocks.net/threads/headless-support.953/#post-9580

But why to use AWT as an render subsystem and support NUI there?

Assume that there existed a developer who wrote a really cool NUI tool -- let's call it a behavior tree editor -- and had no desire or time to support an alternate AWT interface. By using NUI, the editor works right out of the box. By using Swing, I would have to rewrite it myself.



The reverse is also true. If I write something for AWT and decide afterward that it would be great to have in regular Terasology, then it's automatically available. The same module works in both places.

 

[Cervator]

I think the Gradle task would have to be fetchFacadeAWT instead of fetchFacadeAwt - the repo is all upper case AWT

I can't delve into the technical pros and cons of GUI tech, that's why I throw badges at you guys, but I'm excited to see a 2D view after realizing how more and more it looks like DF, and am geeking out over the idea that you could have one player in 3D live in the same world as another using 2D

That also helps point out how the player as-is (counter-intuitively, perhaps) isn't necessarily an engine concept and opens the path toward other alternative views on the world like a passive observer able to move around, a pure map mode (think Dynmap), and heck maybe even a facade approach to local multiplayer (think quad split-screen on a TV with Terasology running on an OUYA)

 

[synopia]

I am still not convinced or still does not understand. I think, we are mixing two totally different things:

• Use AWT instead of LwjGL - this may be nice, although I dont see the use of it (besides having another rendering target to proof, it can be exchanged)
• A 2D top down viewer

For the second point, I sketched a little code to show, how it could be done using NUI. You can find it here: https://github.com/Terasology/Pathfinding/pull/4/files
The GridRenderer class is the important thing to look at.
I even disabled the ingame 3d rendering fully by replacing the RenderingSubsystemFactory with the Headless implementation. This way, you are starting a game like normal, but you dont see the 3d rendering (but the NUI). I think, it should be possible to set a NUI screen into background, so that is will be drawn instead of the 3d world.

Edit: You see this in the screenshot. Its a Light and Shadow world and I am standing in front of a house from Cities. Dont know, why there are some textures missing.

 

[Mike Kienenberger]

I am still not convinced or still does not understand. I think, we are mixing two totally different things:

• Use AWT instead of LwjGL - this may be nice, although I dont see the use of it (besides having another rendering target to proof, it can be exchanged)
• A 2D top down viewer

For the second point, I sketched a little code to show, how it could be done using NUI. You can find it here: https://github.com/Terasology/Pathfinding/pull/4/files
The GridRenderer class is the important thing to look at.

Edit: You see this in the screenshot. Its a Light and Shadow world and I am standing in front of a house from Cities. Dont know, why there are some textures missing.

If you had asked, I would have pointed you to the Minimap module, which already does this and more. But it was interesting to see how you approached the same problem.

 

[Immortius]

I would tend to agree with Synopia. Having a debug tool using AWT? Sure. I am unsure that NUI support is necessary but it gets you the behavior editor.

If this is supposed to be a legitimate way to actually play... not so much. I would suggest that should use lwjgl, or better yet build on the implementation agnostic mesh and nui support. This would provide accelerated 2D rendering.

I will say that the awt nui implementation has been a useful proof of concept for nui supporting multiple renderers.

It is untrue though that awt UI would be portable into regular Terasology though.

 

[Mike Kienenberger]

It is untrue though that awt UI would be portable into regular Terasology though.

I'm confused why you would say that.

It's already portable into regular Terasology.

The same NUI screens and components work in both systems identically (with the exception of drawing meshes).

The awt version has the exact same toolbar and the exact same minimap and the exact same console and the exact same f3 debugging, and so on.

If I write a new module using NUI screens or port an existing one like Minimap screens, it will work equally well under either Facade.

EDIT: maybe we are talking about two different things. For the AWT Facade, the "awt UI" *IS* NUI. If you mean using java.awt and java.swing objects [Edit: components, not objects] , then no, that's not portable, and it's not part of how the AWT Facade operates either.

 

[Cervator]

Uh .. at the risk of sounding foolish, if the AWT Facade isn't using java.awt, what does the AWT stand for?

 

[Mike Kienenberger]

AWT uses a java.awt.Window as a drawing canvas. Really it's an java.swing.JFrame but only because that allows you to easily handle the window close button in a Terasology-engine-compatible way So we're drawing things to an awt window rather than rendering them to openGL.

But no actual awt components (widgets) are used. This is what Synopia was saying -- if you're going to use awt, why not just use awt components? And again, that's because I chose to use NUI components.

I should have said Components rather than awt objects, and I'll go back and edit that.

 

[Josharias]

Also at the risk of sounding foolish... Does the AWT canvas allow using hardware that is not very compatible with opengl?

 

[Immortius]

Yes, it should allow that Josharias. But that isn't to say a 2D opengl based approach wouldn't be equally compatible, since it could drop down to much more primitive opengl.

I'm confused why you would say that.

I was misunderstanding your statement about writing something for AWT.

 

[Mike Kienenberger]

Does the AWT canvas allow using hardware that is not very compatible with opengl?

No, that's a great question and is a primary reason I created it. Part of the reason I am using AWT is that it runs better than Terasology on my laptop, which can frequently lag my laptop. In fact, an older version of linux on this same machine wouldn't run Terasology. I have another laptop that won't run Terasology at all. Strangely enough, that laptop is a year-older model of the same Dell 17R.

No hardware support beyond basic graphics is required for the AWT Facade. The AWT Facade will work with any hardware that supports java.awt + java.swing.JFrame. If there's a reason to do so, I could remove the JFrame dependency at some point. The AWT Facade should run on any java-enabled device with graphics.

This would provide accelerated 2D rendering.

If I understand the java documentation for BufferStrategy, java should already be providing accelerated device-specific 2D rendering, so long as the java implementation is aware of it. No idea if it's really doing something, but someone went through the effort of providing an API for it.

that isn't to say a 2D opengl based approach wouldn't be equally compatible, since it could drop down to much more primitive opengl.

If someone wanted to write a 2d-on-3d implementation using more primitive opengl, that should only require a modification of what I've already done so far, replacing the awt.renderer package. All of the work of determining what is or is not appropriate for a 2d environment has been done.

 

[Mike Kienenberger]

Regarding the issue with the UIScrollbar not working under windows.

Further investigation shows that the scroll bar is probably not the culprit. The scroller only becomes unable to receive events if the button to the left of it, (which has a hit region offset by several pixels to the right) is selected.

if I select a module name which is not right next to the scroller handle, then I'm able to use the scroller again. Let me know if this is not the behavior you are seeing. Apparently the problem lies somehow in the interaction region picked by a selected UIList element (I think that's the component -- haven't verified it yet). So the workaround is to click on a different item if the item is next to the scroller handle. UILIst items have three stages. Not selected, selected, and activated.

 

[Mike Kienenberger]

Fixed in master: Windows puts an additional border around the Frame. It wasn't being picked up by my conversion for mouse coordinates. I've rewritten the code, and greatly simplified how conversion of mouse coordinates is handled, and it's all working right on Windows now.

 

[msteiger]

Here is a screenshot of the latest version (including a bit of Photoshop-magic ) :

It's again the Cities world generator with seed "a". As of now, the visible part of the world is analyzed to extract the heightmap from it in every frame. This causes the framerate to drop to 3-4 FPS on my machine, but that can be improved.
Good work Mike Kienenberger!

 

[Mike Kienenberger]

I realized I hadn't posted any screenshots from this.

Here's a few. Most are from the flat world I'm using to test other stuff, but I threw in a couple of perlin screenshots as well.

Like most things, seeing it in action is far more revealing that looking at a few screenshots. I find it especially interesting to swap between the 3d and 2d views.

 

[Mike Kienenberger]

I have it functional again, although there's probably edge cases where it doesn't work. And msteiger's city code shows as an unused private method right now, so not sure how that got lost. And there's probably a lot more optimization needed. And maybe the toolbar is also missing...

 

[msteiger]

Good work! This has always been one of my favorite (sub-) projects.

 

[Mike Kienenberger]

Fixed the missing client-side toolbar (no client-side components were being loaded).
As far as I can tell, everything works great now.

@msteiger, feel free to add back in that city code I can't remember how renderCityWorld() was called.