MT 1.3b57 Progress

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

Post Reply
User avatar
Hawke
Great Wyrm
Posts: 2261
Joined: Sat Apr 21, 2007 12:12 am
Location: Albuquerque, NM
Contact:

Re: MT 1.3b57 Progress

Post by Hawke »

So sounds like you're thinking we'll still be a primarily 2D system but using the 3D acceleration we'll get mostly speed benefits? Also seems to me that there's probably a lot of cool built in stuff that would allow more dynamic lighting (colors, flickers, effects).

Disclaimer: I am ignorant ;)

User avatar
keithcurtis
Giant
Posts: 129
Joined: Fri Mar 02, 2007 3:18 am
Contact:

Re: MT 1.3b57 Progress

Post by keithcurtis »

Azhrei wrote: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...

It would seem to me that an 8-bit png would not be any better at supporting different levels of transparency than a GIF? I don't understand the nuts and bolts of file formats, but this appears to be the case with an 8 bit Photoshop PNG.

User avatar
Azhrei
Site Admin
Posts: 12057
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MT 1.3b57 Progress

Post by Azhrei »

keithcurtis wrote:
Azhrei wrote: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...

It would seem to me that an 8-bit png would not be any better at supporting different levels of transparency than a GIF? I don't understand the nuts and bolts of file formats, but this appears to be the case with an 8 bit Photoshop PNG.

I don't think that's correct. I think GIF allocated one entry in the index table for transparent pixels because GIF doesn't support 32-bit alpha values for each pixel. Keep reading...

Palmer had a concern about file size and rightly so -- I agree that ~1MB for an animated image is too much.

However, the image was stored in RGB 24-bit TrueColor. That means that each pixel on the screen is represented by a 3-byte red/green/blue value. (Technically they're not "bytes", because bytes are architecture-dependent. Which is why IP addresses are 4 octets and not 4 bytes.) Then there's also an 8-bit alpha value as well.

So suppose that 2 pixels in the image have the same value? It would take 8 bytes to represent them (4 bytes for each). And what if there are 1,000 pixels with the same value? Yep, 8000 bytes. So another format for PNGs exist which is called "indexed". There is more than one indexed mode, but the one we're interested in is where an 8-bit value is an index into a table. Each entry in the table is the 24-bit color and 8-bit alpha, just like in the previous paragraph. But now if that color appears 1,000 times in the image, it only requires 1,000 bytes. A savings of 8:1. This means that you can choose 256 colors out of a palette of 16.7 million colors (24 bits RGB) and 256 levels of transparency (8 bit alpha). If your image fits into those parameters and still looks good, it can save a huge amount of file space.

(This is where GIF was lacking. It had an index of 256 entries and one entry could be transparent. But it didn't support 32-bit values in the table, only 24-bit values. So individual colors could not have transparency information embedded into them. I think a later GIF format extended the transparency model a little, but it still doesn't compare to PNG.)

Note that changing the format of the image doesn't save any RAM at execution time, since the image must be expanded to match the depth the application is using. This is why changing your desktop to 16-bit color can (note I didn't say it will) speed up the graphics processing. Notice I said can and not will? That's because a lot of graphics drivers are optimized for 24-bit use because that's what all the hardware reviews will be testing, plus some optimizing for the mode that most games actually run in (it might be 16-bit color on Windows, but I don't know).

In any case, an 8:1 savings would knock that campfire down to less than 100K which, while still a bit large for me, is quite reasonable. Of course, that image is also 320x240, when a 100x100 campfire is probably fine, so right there we have a reduction of 7.68:1 in file size, not counting compression. That combines to about 60:1, bringing the file size down to 12.5K. (It likely would be larger than that, since a smaller data set would likely yield a lower compression, so maybe 15K?) I'd have to actually try it to determine how close my math is. And I'm not going to. ;)

User avatar
keithcurtis
Giant
Posts: 129
Joined: Fri Mar 02, 2007 3:18 am
Contact:

Re: MT 1.3b57 Progress

Post by keithcurtis »

Azhrei wrote:
keithcurtis wrote:
Azhrei wrote: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...

It would seem to me that an 8-bit png would not be any better at supporting different levels of transparency than a GIF? I don't understand the nuts and bolts of file formats, but this appears to be the case with an 8 bit Photoshop PNG.

I don't think that's correct. I think GIF allocated one entry in the index table for transparent pixels because GIF doesn't support 32-bit alpha values for each pixel. Keep reading...
...
So suppose that 2 pixels in the image have the same value? It would take 8 bytes to represent them (4 bytes for each). And what if there are 1,000 pixels with the same value? Yep, 8000 bytes. So another format for PNGs exist which is called "indexed". There is more than one indexed mode, but the one we're interested in is where an 8-bit value is an index into a table. Each entry in the table is the 24-bit color and 8-bit alpha, just like in the previous paragraph. But now if that color appears 1,000 times in the image, it only requires 1,000 bytes. A savings of 8:1. This means that you can choose 256 colors out of a palette of 16.7 million colors (24 bits RGB) and 256 levels of transparency (8 bit alpha). If your image fits into those parameters and still looks good, it can save a huge amount of file space.

Be that as it may, this does not seem to be an option in Photoshop.

There are two options for PNG output: PNG8 and PNG24. PNG 8 only supports one level of transparency. Intermediate levels of transparency may be dithered or matted, but cannot retain multilevel transparency. You can select multiple colors in the palette to be transparent, but this is an on-off situation. Perhaps there is a way to do this, but it does not appear in the documentation (which directs you to use PNG24 for multilevel transparency) and several minutes of fiddling with the available options produces nothing.

Or am I misunderstanding what you are saying? Are you saying to use PNG24 but artificially constrain the color palette?

EDIT: After further research, it appears that it can be managed with Adobe Fireworks, or a number of third-party utilities. Interesting. Thanks for making me get off my butt and go looking.
Last edited by keithcurtis on Mon May 25, 2009 12:55 am, edited 1 time in total.

Cweord
Great Wyrm
Posts: 1343
Joined: Sun Aug 12, 2007 10:49 am
Location: Midsomer Norton, (Near Bath), UK
Contact:

Re: MT 1.3b57 Progress

Post by Cweord »

trevor wrote: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).



Am I right in thinking this would also help for extra layers and elevation?

We may not be using 3d visuals, but if the engine works in 3d wouldn't it help in calculating elevational light and topology (in both the true form and the VBL/LBL sense)

again like Hawke, i put in the disclaimer that I am ignorant, I may work with 3d graphics, but I know nothing about the back end.
Cweord

This message has been spell checked by Freudcheck - any mistakes are purley a figment of your imagination.
-------
My Tokens Directory
http://gallery.rptools.net/v/contrib/Cweord/Character_Tokens/

User avatar
hyperactiveChipmunk
Cave Troll
Posts: 99
Joined: Wed Apr 15, 2009 8:19 pm

Re: MT 1.3b57 Progress

Post by hyperactiveChipmunk »

keithcurtis wrote:Be that as it may, this does not seem to be an option in Photoshop.

There are two options for PNG output: PNG8 and PNG24. PNG 8 only supports one level of transparency. Intermediate levels of transparency may be dithered or matted, but cannot retain multilevel transparency. You can select multiple colors in the palette to be transparent, but this is an on-off situation. Perhaps there is a way to do this, but it does not appear in the documentation (which directs you to use PNG24 for multilevel transparency) and several minutes of fiddling with the available options produces nothing.

Or am I misunderstanding what you are saying? Are you saying to use PNG24 but artificially constrain the color palette?

EDIT: After further research, it appears that it can be managed with Adobe Fireworks, or a number of third-party utilities. Interesting. Thanks for making me get off my butt and go looking.



Az is correct; like I said, it was quick 'n' dirty. That's not even close to what it could be at minimum, it was merely to show what a nice animated png CAN look like, as opposed to the ugly .gif equivalent. Give me a few minutes and I'll whip up an optimized one for ya.

-hC

User avatar
hyperactiveChipmunk
Cave Troll
Posts: 99
Joined: Wed Apr 15, 2009 8:19 pm

Re: MT 1.3b57 Progress

Post by hyperactiveChipmunk »

hyperactiveChipmunk wrote:
keithcurtis wrote:Be that as it may, this does not seem to be an option in Photoshop.

There are two options for PNG output: PNG8 and PNG24. PNG 8 only supports one level of transparency. Intermediate levels of transparency may be dithered or matted, but cannot retain multilevel transparency. You can select multiple colors in the palette to be transparent, but this is an on-off situation. Perhaps there is a way to do this, but it does not appear in the documentation (which directs you to use PNG24 for multilevel transparency) and several minutes of fiddling with the available options produces nothing.

Or am I misunderstanding what you are saying? Are you saying to use PNG24 but artificially constrain the color palette?

EDIT: After further research, it appears that it can be managed with Adobe Fireworks, or a number of third-party utilities. Interesting. Thanks for making me get off my butt and go looking.



Az is correct; like I said, it was quick 'n' dirty. That's not even close to what it could be at minimum, it was merely to show what a nice animated png CAN look like, as opposed to the ugly .gif equivalent. Give me a few minutes and I'll whip up an optimized one for ya.

-hC


Or not, because my ImageMagick-fu appears to be weak tonight. I should be in bed. >8P

zzzzzzzzzzzzzzz

-hC

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MT 1.3b57 Progress

Post by Craig »

Cweord wrote:
trevor wrote: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).



Am I right in thinking this would also help for extra layers and elevation?

Something like jME would help for elevation if using the 3d features which does involve internally representing things in 3d, even if the interface to add/create them only deals with 2d. Although it would make other things concerning rendering more difficult to do this way. (not the drawing you can just use glOrtho, but the representation).

Layers its much of a muchness as things on different layers aren't really at different "heights", trying to implement them that way would mean that they don't work correctly with lighting. Instead MapTool would use the layers to determine which objects are or aren't added to the scene graph.

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: MT 1.3b57 Progress

Post by Craig »

trevor wrote: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).


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).

User avatar
Orchard
Great Wyrm
Posts: 1852
Joined: Fri May 09, 2008 10:45 am
Location: Doylestown PA
Contact:

Re: MT 1.3b57 Progress

Post by Orchard »

keithcurtis wrote:
buncha stuff


EDIT: After further research, it appears that it can be managed with Adobe Fireworks, or a number of third-party utilities. Interesting. Thanks for making me get off my butt and go looking.


I'll be the FIRST to admit that I am NOT a graphic artist, but over the years I've found that if I want to do anything with .png format images, there are few programs that come close to what Adobe Fireworks offers as it's base package, let alone what various extensions can do. Photoshop has its uses, but the .png format seems to be an afterthought.

These days I use very little aside from Inkscape for my image creation needs, and I do extremely little image manipulation, so it's perfect for what I need. SVG has some killer capabilities. I love it.
0+0=1, for very unstable CPUs.

User avatar
Azhrei
Site Admin
Posts: 12057
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: MT 1.3b57 Progress

Post by Azhrei »

Orchard wrote:
keithcurtis wrote:EDIT: After further research, it appears that it can be managed with Adobe Fireworks, or a number of third-party utilities. Interesting. Thanks for making me get off my butt and go looking.


I'll be the FIRST to admit that I am NOT a graphic artist, but over the years I've found that if I want to do anything with .png format images, there are few programs that come close to what Adobe Fireworks offers as it's base package, let alone what various extensions can do. Photoshop has its uses, but the .png format seems to be an afterthought.

Thanks, Keith, for taking the time to look. As Orchard says, I'm certainly no graphic artist either. I know some of this stuff because I've written pixel decoders over the years, and while I don't do that any more I still dabble in trying to stay somewhat current. (Notice all the qualifiers at the end of that sentence?? ;))

These days I use very little aside from Inkscape for my image creation needs, and I do extremely little image manipulation, so it's perfect for what I need. SVG has some killer capabilities. I love it.

Agreed! I really want to find some time to play around with SVG and javascript because I've got some web site ideas. Of course, the poor saps who still use IE would be left in the dark without an SVG plugin (they would literally be "left in the dark" because I'd make my background black ;)).

There's just sooo much cool stuff going on out there and IE is nowhere near it. MS must be :oops:. Or if they're not, they should be. ;)

User avatar
keithcurtis
Giant
Posts: 129
Joined: Fri Mar 02, 2007 3:18 am
Contact:

Re: MT 1.3b57 Progress

Post by keithcurtis »

Azhrei wrote:
Orchard wrote:These days I use very little aside from Inkscape for my image creation needs, and I do extremely little image manipulation, so it's perfect for what I need. SVG has some killer capabilities. I love it.

Agreed! I really want to find some time to play around with SVG and javascript because I've got some web site ideas. Of course, the poor saps who still use IE would be left in the dark without an SVG plugin (they would literally be "left in the dark" because I'd make my background black ;)).

There's just sooo much cool stuff going on out there and IE is nowhere near it. MS must be :oops:. Or if they're not, they should be. ;)

I use SVG occasionally for my Play by Post game. It's pretty cool to do a map of the area around the city and have them be able to drill down to see the tavern they are sitting in. (Of course, that's the only part that's detailed. I'm not that crazy.)

User avatar
Orchard
Great Wyrm
Posts: 1852
Joined: Fri May 09, 2008 10:45 am
Location: Doylestown PA
Contact:

Re: MT 1.3b57 Progress

Post by Orchard »

keithcurtis wrote:
Azhrei wrote:
Orchard wrote:These days I use very little aside from Inkscape for my image creation needs, and I do extremely little image manipulation, so it's perfect for what I need. SVG has some killer capabilities. I love it.

Agreed! I really want to find some time to play around with SVG and javascript because I've got some web site ideas. Of course, the poor saps who still use IE would be left in the dark without an SVG plugin (they would literally be "left in the dark" because I'd make my background black ;)).

There's just sooo much cool stuff going on out there and IE is nowhere near it. MS must be :oops:. Or if they're not, they should be. ;)

I use SVG occasionally for my Play by Post game. It's pretty cool to do a map of the area around the city and have them be able to drill down to see the tavern they are sitting in. (Of course, that's the only part that's detailed. I'm not that crazy.)


Yeah, but like I said, SVG has a lot to recommend it as opposed to other formats...not least of all file size. SVGZ (the compressed format) is incredibly tight, and looks just as good at 128x128 as at 1024x1024 (or just as bad, depending on the artist!), while those 'other' formats all too often require substantial reworking to look decent when resized. And the ability to write svg on the fly via javascript is a huge advantage as well. I've toyed with php scripts that write dynamic svg, and it's a powerful thing. I'm not as good with javascript as with php, but it's a similar principle. The downside is that there is a certain browser that doesn't support svg very well (anyone have the scoop on svg in IE8?). First it was poor .png support, now it's poor .svg support. Ech.
0+0=1, for very unstable CPUs.

User avatar
Orchard
Great Wyrm
Posts: 1852
Joined: Fri May 09, 2008 10:45 am
Location: Doylestown PA
Contact:

Re: MT 1.3b57 Progress

Post by Orchard »

I know this is the b57 thread, but since SVG is mentioned...

the inkscape .47 about screen contest is underway (and almost over!).

All screens must be designed IN inkscape and the svg file must be provided. No post-processing is allowed either.

Here's one of my favorites:
http://johanengelen.deviantart.com/art/ ... -123585893

For more information go to: www.inkscape.org
0+0=1, for very unstable CPUs.

Elorebaen
Dragon
Posts: 365
Joined: Sat Dec 22, 2007 5:37 pm

Re: MT 1.3b57 Progress

Post by Elorebaen »

Just curious if the issue with clear panel on the global window is going to be resolved in this build?

Thanks.

Post Reply

Return to “Developer Notes”