I've been working on making updates to the facing as has been discussed on the forums. I'm also working on fixing the shape of the hexes, and will see about getting the snap to grid working for hexes while I'm at it.
I've also moved the Force Player View from CTRL V to CTRL F so that it no longer conflicts with paste token (CTRL V).
I've also started looking into and planning a rendering pipeline refactoring that will make layers easier to implement. It should also provide some performance improvements.
I'll probably make a release in the next couple days with the facing and hex updates so that you guys can take a look and help guide the development
MapTool 1.1 build 5 Development
Moderators: dorpond, trevor, Azhrei
-
trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
MapTool 1.1 build 5 Development
Dreaming of a 1.3 release
-
trevor
- Codeum Arcanum (RPTools Founder)
- Posts: 11311
- Joined: Mon Jan 09, 2006 4:16 pm
- Location: Austin, Tx
- Contact:
Warning: the following contains technical details that may likely bore you to tears. You have been warned.
To give an idea, one provided example image is 1600 x 2200. It's 1meg on disk, but it's a png, which is a compressed format, so once it's loaded into memory it's actually 16megs.
For performance reasons the original image has to be copied onto an image that has the same color space as your graphics display. That means I need two images of the same size at once during load. So the 1 meg file really needs almost 40megs to load. Ouch.
The image explorer has 3 concurrent image loading threads that load up the images whenever you select a directory. This is obviously bad when there are more than one large image in a directory and it tries to load three at a time .... kabooooom ! So I split out the image loader into two different groups, one thread to load large images, and two threads to load small images (as arbitrarily defined as 10k or smaller). I'm now able to view directories with many (10+) 1meg images and 20 small images without breaking, and still quite peppy.
Looking through the New Map code path to see if I can reduce the amount of redundant image data.
To give an idea, one provided example image is 1600 x 2200. It's 1meg on disk, but it's a png, which is a compressed format, so once it's loaded into memory it's actually 16megs.
For performance reasons the original image has to be copied onto an image that has the same color space as your graphics display. That means I need two images of the same size at once during load. So the 1 meg file really needs almost 40megs to load. Ouch.
The image explorer has 3 concurrent image loading threads that load up the images whenever you select a directory. This is obviously bad when there are more than one large image in a directory and it tries to load three at a time .... kabooooom ! So I split out the image loader into two different groups, one thread to load large images, and two threads to load small images (as arbitrarily defined as 10k or smaller). I'm now able to view directories with many (10+) 1meg images and 20 small images without breaking, and still quite peppy.
Looking through the New Map code path to see if I can reduce the amount of redundant image data.
Dreaming of a 1.3 release
