MT 1.3b57 Progress

[FdL]

Just to chip in my 2 cents, as cool as it might sound in theory, maptools in 3D is not such a good idea in practice. It adds nothing but pure eye candy, and it will bring a whole new level of complications, requirements and general trouble to the program, which in turn will still do the same stuff and have the same underlying problems.

[zEal]

It adds nothing but pure eye candy

Hardware rendering.

Even if MapTool used "3D" to replicate its existing 2D interface, it would still noticeably benefit from hardware rendering.

There seems to be a bit of cross communication when it comes to this subject; some people say "3D" and are simply referring to the rendering techniques, others mean full three dimensional representation of the map and tokens.

While the latter would be little more than eye candy, the former can not be dismissed so easily. Trevor also made it clear in a previous post in this thread that his primary interest in "3D" is in fact the former.

[trevor]

If you want the speed afforded by OpenGL (LWJGL) but you don't actually want all of the 3d stuff then another option is Slick2D its a library for 2d games and uses LWJGL. It offers Java2d like functionality as well as other non 3d stuff that jME offers (such as particle emitters etc).

Interesting, I didn't know about that one, I"ll check it out !

[Mrugnak]

There seems to be a bit of cross communication when it comes to this subject; some people say "3D" and are simply referring to the rendering techniques, others mean full three dimensional representation of the map and tokens.

My response to the first group is "say 'hardware rendering' please, I know it's 17 more letters but it prevents so much confusion..."

I'm 100% interested in hardware rendering support if we can figure it out without totally derailing development. We might want to maintain a software mode for backwards compatibility, and for folks whos hardware drivers hate everyone.

[Craig]

There seems to be a bit of cross communication when it comes to this subject; some people say "3D" and are simply referring to the rendering techniques, others mean full three dimensional representation of the map and tokens.

My response to the first group is "say 'hardware rendering' please, I know it's 17 more letters but it prevents so much confusion..."

If only avoiding confusion is so easy
In the case of using jME even if you get a 2d image at the end everything is represented in 3d (and you are rendering a 3d scene onto a 2d object which is positioned in a 3d world) so it really is 3d.

'hardware rendering' is also quite inaccurate. Hmm maybe 'possibly hardware assisted rendering' and the 'possibly' bit doesn't just depend on if you card supports the function or not

I'm 100% interested in hardware rendering support if we can figure it out without totally derailing development. We might want to maintain a software mode for backwards compatibility, and for folks whos hardware drivers hate everyone.

One of the advantages of using libraries that use OpenGL (and OpenGL is just a rendering library its not specific to just 3d) is the features if not implemented by the card are already emulated in software -- extensions aside. For 3d games this can be a little painful as you might suddenly get a slow down when trying to use some advanced feature on a certain card that you would of avoided if you knew, for the purposes of MapTool its not really an issue as even the really really really horrible integrated graphics cards -- yes I am pointing my finger at you Intel -- do the stuff that is likely to be used in MapTool well -- to an extent.

[trevor]

OK, I"ve checked out Slick2d and other similar libs.

It looks great for what it does, but I'm not getting warm fuzzies that it'll do what I need it to.

First off, the window size is fixed. I also can't see how to render to an offscreen image (there are a couple posts in there forums about this, but no response yet).

Also, it allows only one renderable surface (which simplifies the code, but isn't convenient for non-game uses).

[trevor]

UPDATE

Whew, been crazy IRL lately with baby and all.

But things are settling down again, getting back to schedule.

I've been tinkering with some technology for use in 1.4, with a focus on the overall UI layout. I'll post some tests at some point.

Time to hunker down and get 1.3 out though.

[Big_Mac]

UPDATE

Whew, been crazy IRL lately with baby and all.

But things are settling down again, getting back to schedule.

I've been tinkering with some technology for use in 1.4, with a focus on the overall UI layout. I'll post some tests at some point.

Time to hunker down and get 1.3 out though.

Thanks for the update!!!!

[Jector]

Speaking of which, what is used to make the UI? I'd be interested in making a couple skins so long as it's not horribly involved or uses very esoteric tools.

[zEal]

Speaking of which, what is used to make the UI? I'd be interested in making a couple skins so long as it's not horribly involved or uses very esoteric tools.

It uses TinyLAF for most of the it. I'm not sure if you can create actual 'skins', but it's very easy to modify colour themes; just run the tinylaf-1.3.04.jar that's in the lib folder.

The only things I've been unable to modify using that are the panel title bar colour, and some of the text(notably the Map Explorer).

[Jector]

Hmm... Well, I definitely wanted to be able to do more than that. I was hoping to be able to fiddle with some fun borders in fantasy and sci-fi themes. Ah well.

[Hawke]

Hmm... Well, I definitely wanted to be able to do more than that. I was hoping to be able to fiddle with some fun borders in fantasy and sci-fi themes. Ah well.

I always thought the statsheet (is that the proper term) would be a great place to start for skinning. While I primarily do fantasy games these days, I remember when it first debuted in the current form and how it'd be cool to have a sci-fi option.

[trevor]

I've been doing some tests in the UI rewrite such that it won't use the docking framework anymore. This will greatly increase the ability to skin the app. Although, my primary interest at present is getting rid of all unused space (that includes titlebar, borders, etc).

I'll post some screenies and a tech test after 1.3 is out

[Cweord]

I sense some Rippers skinning in my future

[heyes]

I've been doing some tests in the UI rewrite such that it won't use the docking framework anymore. This will greatly increase the ability to skin the app. Although, my primary interest at present is getting rid of all unused space (that includes titlebar, borders, etc).

I'll post some screenies and a tech test after 1.3 is out

Please keep docking as an available feature. Some of us have smaller screen acreage, and rely on the extra pixels that function gives us!