RPTools.net

I think having gradient fog edges and flickering light are the two big eyecandy features I'd like to see... if we can keep 2D and do that I'll be elated

osman wrote:... as someone that spends most of his day writing shader code and doing light + shadow in 3D (for console games) ... yeah. It's probably way overkill, and it's going to be very hard to get things to be nearly as robust as they are in 2D. The layered 2D approach is much more tractable in a tool where people are making their own dungeons.

Neverwinter Nights 1.

Hawke wrote:I think having gradient fog edges and flickering light are the two big eyecandy features I'd like to see... if we can keep 2D and do that I'll be elated

Trevor had indicated in the distant past that animated GIF/PNG images were on his list of things for future implementation. However, that was a long time ago and those things may be lower on the list now!

I think animated GIFs should be one of the highest priority items for sheer eye candy reasons. Animations can really make a strong impact on first time viewers.

It would be nice to have animated gifs for campfires, pulsing starship engines, forcefields, etc.

Any idea if these would be able to be implemented on tokens? Imagine a top-down that subtly moves, like an idle figure in StarCraft or similar. Of course, animated gifs have transparency edge problems, but there's always a give and take.

If they get implemented at all, they should work for everything except perhaps a background image that is set when the map is created. But because the easiest way to create maps is to create a textured background and then put maps on top of that on the Background layer, it's possible that specifying a background image may go away. (I wouldn't be sad if it did.)

I don't have any experience, but it seems like http://animatedpng.com/ is the solution to the animated gif problems.

Hawke wrote:I don't have any experience, but it seems like http://animatedpng.com/ is the solution to the animated gif problems.

Like so:


(quick 'n' dirty with blender/gimp, don't crucify me because it's ugly)

-hC

Hawke wrote:I don't have any experience, but it seems like http://animatedpng.com/ is the solution to the animated gif problems.

The issue for MapTool is that a separate timer thread needs to run to do the animation. Most web browsers create a separate thread and fire of "time-expired" events periodically which the image renderer listens for. When such an event fires, the image renderer updates the animation (if appropriate).

MapTool needs such a thread and all images which are animated need to register with that thread. This isn't a big deal ordinarily, but there may be concurrency issues when an animated image is being updated at the same time as it's being moved or otherwise manipulated. (I'm not saying it *is* a problem, just that it *could be*. If all of the animation data were kept separately from the token data, then it probably wouldn't be a big deal at all except for synchronizing the animations between multiple clients. And I don't think I'd even attempt that, though. Not enough payoff.)

Nice thing about the APNG format is that it falls back nicely to PNG. Additional frames are stored as custom chunks which are ignored by the PNG spec, but the initial image is encoded as any other PNG. Should be able to just ignore those chunks when it's convenient.

-hC

That looks like a good idea, but my GIMP 2.2 doesn't support it (I'm downloading 2.6 to see if it's there). Otherwise, APNG seems the way to go.

Azhrei wrote:That looks like a good idea, but my GIMP 2.2 doesn't support it (I'm downloading 2.6 to see if it's there). Otherwise, APNG seems the way to go.

GIMP unfortunately has no plugins for it, and none seem to be under development. I was going to write one, but I figured someone else would. Guess not. >8)

There's an addon for Firefox that sticks them together, or you can use http://littlesvr.ca/apng/assembler/assembler.php. It's not that much a hassle, though a native plug-in would be nice to have.

-hC

That is very pretty. It's also huge.

That one animated fire is almost 900kb.

My incomplete Shadowfell cmpgn is only 12.5 megs for 12 maps.

So that one campfire is almost as large as a complete map.

Except not. I'm using the full poster maps from KotS at 50dpi (1500x1050) as jpg and they're all around 200-250kb.

Animation is a nice idea, but I fear for filesizes.

It depends on the compression used. Most animation formats used a delta difference between frames, storing only those changes. Then each frame is individually compressed. Formats like the MPEG series (1, 2, and 4) introduce optimizations to help prevent loss, such as B-frames which are essentially the entire frame -- not a diff. That helps resynchronize should some data be lost in a diff frame somewhere.

The more advanced formats try to predict what your eye is capable of seeing and optimizing that as well.

Perhaps a low-resolution MPEG2 or MPEG4 would be the way to go for a Java-based app? MPEG4 would have a lot of computational overhead but provide better compression than MPEG2. Of course, neither of them are "built in" to the Java image libraries...
Edit: It looks like that log fire is saved in 24-bit RGB. I'll bet that an 8-bit indexed image would be significantly smaller, but since my GIMP doesn't support it...

My primary interest in the 3d engine (tinkering with jME btw) is the speed of the hardware rendering.

Swing is OK fast, but it pales in comparison for speed and quality to hardware accelerated 3d engines. Being able to move the camera around is just gravy.

Animated tokens isn't hard, but will take some rework to the current rendering engine. I'm planning a major refactoring of that system for early 1.4 (hence my interest in 3d engines).