Add experimental libgdx based renderer

[thelsing]

Requirements for Contributing a Bug Fix or Enhancement

This adds the experimantal libgdx based renderer.

Features:

• support of animated gifs as tokens
• support of webm as tokens

Known issues:

• textures don't work as color for drawing (upstream lib can't do this currently)
• fow is always revealed on movement
• thelsing/maptool#120

Differences to current renderer:

• labels placed on map are zoomed

Additional notes:

• I moved the border in lib to maptools dir where the other borders already where
• I added opensans as a front because the default libgdx font look not quite nice. Only only the regular ttf is currently needed. Do we want to add only this one file or all?
• gdx-video could support much more formats (everything that mplayer can play I think) but we would have to compile our own version. The current gdx-video snapshot doen't contain much format because of possible patent issues. IMO we should just enable everything. But we would have to build it ourself and put the package somewhere. Building is to complicated for jitpack.

Identify the Bug or Feature request

#1781

Description of the Change

This adds a different renderer for zones. Both renderers can be switched at runtime.

Possible Drawbacks

If not enabled there should be no impact on MT. If some opengl libs fail to load MT fails to start. I tested on windows and macos but not linux yet.

Release Notes

Add an experimental libgdx based map renderer to support animated tokens.

---

This change is 

[thelsing]

The renderer currently reimplements the current renderer, but keeps the same structure. Maybe we should take the change to refactor it much more. Suggestions are welcome.

BTW. The numbers on the map are: FPS (left), draw calls (right)

[cwisniew]

There seems to be something odd happening on my system when dropping tokens

[cwisniew]

Also at certain zoom levels the screen goes completely blank except for the token selection border (there are 3 tokens on this map)

[kwvanderlinde]

I haven't taken a look at any of the code changes yet, but I have done some basic testing so far and have found a few issues with the gdx renderer:

1. Enabling Fog of War and turning off the grid makes the screen goes black.
2. Enabling Fog of War and turning on the grid makes the screen go black when zoomed out ~25% or more. At some zoom levels past this point, renderering suddently starts working again.
3. After creating a new map, can no longer zoom on any maps. Turning the gdx renderer on and off resolves the issue.
4. After creating or opening a campaign, can no longer zoom on any maps. Turning the gdx renderer on and off resolves the issue.

[thelsing]

The offsets seem to be caused by screen scaling with HDPI screen. As @kwvanderlinde commented, it seems to start on linux 🎉

[cwisniew]

m as tokens

Differences to current renderer:

• textures don't work as color for drawing (upstream lib can't do this currently)

There are enough people that use textured drawings for parts of/features on their map that this feature is really important

• fow is always revealed on movement

We will need all the options we currently have

• labels placed on map are zoomed

This is fine, I am not sure in my mind if they are right size or should be scaled a little, but I am sure people will give us feedback about it and let us know :)

[thelsing]

• textures don't work as color for drawing (upstream lib can't do this currently)

There are enough people that use textured drawings for parts of/features on their map that this feature is really important

• fow is always revealed on movement

We will need all the options we currently have

I know. The list was more for known issues. I changed the text to reflect that.

[thelsing]

I don't know if this needs to incorporate later changes or not but there are several methods in this PR that are public vs private/protected in develop with out an apparent need to do so.

There shouldn't be any unneeded changes to those. Currently most of these "model" classes draw themself. So certain properties could stay private. The gdx renderer need access to those stuff too in order to draw them. I could also add the gdx drawing code to those classes but I think they would get quite messy. I think it would be better to split them up into the "data" part and the drawing part for the swing drawing code too (some time in the future).

The terrain modifiers is also non final vs develop with out any reason I can see (so may also be a change in develop).

This is from a classical java serialisation issue and was fixed in a differnt PR.

[cwisniew]

I was able to cajole someone into testing the libGDX on apple silicon (M1 Mac). It worked but nothing lined up, dropping tokens always dropped them somewhere other than where his mouse was (some times off screen even), hover was in wrong place, generally couldn't select tokens (this may be down to mouse pointer differences).

Other comments, they had to deselect/select the libGDX button to get things to work quite a bit (similar to another comment above). They also thought the libgdx button was a logo not a button. Its probably worth creating a experimental features menu/submenu and moving it here, this would probably be helpful long term as we can get users used to where they should see experimental features if we plan to do more in the future

[thelsing]

I pushed some fixes:

• offset and sizes on hdpi screen should be correct now
• black map at certain zoom level was fixed. There is still an issue at very low or very high zoom levels. I use a perspective camera to be able to add 3d models later. The map is at height 0, the camera at height z looking at the map. The near of the view frustum ist 0.1 * z and the far is 1.1 * z. The screen goes black when 0.1 * z == z or 1.1 * z == z in float. IMO the zoom values where this happens is well beyound practical use.

Next I will be looking into the issues of @kwvanderlinde and implement the light rendering changes.

The logo button is more a development/testing helper to switch quickly between both renderers. I didn't think much how users would enable the renderer.

I think the target users for the experimental renderer are users that follow discord or read the release notes. Those users would read about the libgdx button. We could also enable the renderer with a macro or a preference setting. Or we add a preference for showing the libgdx button.

[thelsing]

Found the backbuffer issue. Will fix fow now.

[cwisniew]

@thelsing I noticed that the latest LibGDX release now supports LWJGL3, which has improvements for the latest versions of Java and a setting/inclusion so that it no longer requires MacOS programs to be started on the main thread. It's probably worth upgrading to this and using the default backend instead of the unsupported JOGL back end (unless other reasons hold it back?)

[thelsing]

@cwisniew Problem with lwjgl3 is that there is currently no way to integrate it into swing or jfx. See libgdx/libgdx#6190 and libgdx/libgdx#6247. There is not that much code in the jogl backend and its easy so switch to some other backend in the future if necessary so it think it's fine to use the jogl backend for now.

[thelsing]

Closing for now.

[FullBleed]

NOOOOOOOOOOOO!!!!!!

[thelsing]

It's not dead yet. But I'll wait until there are no more changed to the light system.