Page 7 of 8

Re: MapTool 1.4

Posted: Sat Feb 01, 2014 4:29 am
by Lee
@Jamz Will do :) As for features, I am interested in any cloud-based locations that are accessed through HTTP GET, POST etc. I believe you, and one other forum user mentioned having one each. Also, sometime down this year, let's talk about VBL.
KaylaKaze wrote: As for your posts, I'm not sure what to search for. You have over 800 posts so sifting through that would be a pain. :-P

So, since you've presumably been neck deep in the MT code recently and I haven't touched it much since 2007 or so (sadly, it hasn't really changed much since then), what are your thoughts on the difficulty of some of the features I threw out, primarily SQLite3 DB access (like an "executeQuery(db filename, query string)" command) and IRC based "Community" tab? I also had a couple of others I just recently thought of that are seemingly just minor things: loading macro code/HTML from a file (like an "include" to a macro), and making it so you don't select a token if you click on a transparent section of its image?
Here's the most recent, and relevant post about my work. I didn't bother adding it to my sig since something more detailed is coming soon.

I'll be uploading a short demo video soon featuring the SQL features I wrote. The feature's been done for a while now, but we're busy on a lot of stuff these days that it keeps getting relegated to the backburner. It's not on SQLite, however, but on H2, which has several advantages over SQLite that I liked. SQLite is in the mix, however, but used internally, and not accessible to users. IRC is in, that's all I can say for now. It's something we plan to discuss with the community interested in our project to round out the user experience. We don't want to implement all features that won't be used anyway; with that being said, it's functionally finished, but not the final user experience.

Regarding #include-like stuff, indirectly we help by providing several (safe) methods to access the file system, as part of providing alternate methods of managing data beyond the token system. I don't see the added value of creating a system that actually behaves like #include or Java's import, when a proper plug-in system is the target of forks and RPTools. onCampaignLoad should work for most cases, coupled with the new features.

Edit: To what purpose is the click-through transparency for? Not with the current system, and likely not with Swing; whether snapped-to-grid or unsnapped, the bounds are set with regard to each token image. It's just "easier" (I'm just imagining it in my head) with JavaFX. In order to accomplish what I think you want, an image object would need to be aware of either it's transparent or visible areas, and have mouse/touches pass through it if its transparent. Each image would need to be encased in a Node to have this nifty feature, which would be sub-optimal as compared to replicating one image over the Canvas.

Re: MapTool 1.4

Posted: Sat Feb 01, 2014 3:00 pm
by KaylaKaze
Lee wrote: Edit: To what purpose is the click-through transparency for? Not with the current system, and likely not with Swing; whether snapped-to-grid or unsnapped, the bounds are set with regard to each token image. It's just "easier" (I'm just imagining it in my head) with JavaFX. In order to accomplish what I think you want, an image object would need to be aware of either it's transparent or visible areas, and have mouse/touches pass through it if its transparent. Each image would need to be encased in a Node to have this nifty feature, which would be sub-optimal as compared to replicating one image over the Canvas.
Well, in our current D&D game, for example, we use top down view tokens. With weapons and whatnot, this often leads to the tokens hanging outside their block. Usually, it's just something like a weapon, so the token ends up being a lot of empty transparent place as the system makes a boundary box around the whole thing, which then makes it difficult to click on tokens next to it. I wrote system in JS while doing some experimentation a while back where I could overlay images (using an img tag) and click on ones below that you could see through the transparent section of the top layer by quickly copying the image to a canvas, getting the color value of the pixel that was clicked, checking the alpha on that pixel, and then, if it was transparent, make that layer not receive click notifications (and with some browsers, had to hide it) then resend the click event at that location (when I had to hide, I'd reshow immediately after the click event was sent and it'd be visually imperceptible).

Re: MapTool 1.4

Posted: Sat Feb 01, 2014 3:11 pm
by Lee
Ah, it is as I surmised. I won't close the door on the idea; I do have to say that there are factors within the current system that is dependent on the bounding box surrounding the image. Of course, you could say that it is a special context, only checked when clicking/touching the image, but I'll reserve looking at it until the new mapping system is visited. As much as possible, we would like to implement optimal practices like the replication I mentioned. Once that is in, there should be leeway to put in more expensive processes.

Re: MapTool 1.4

Posted: Mon Feb 03, 2014 12:05 am
by JamzTheMan
KaylaKaze wrote:
Lee wrote: Edit: To what purpose is the click-through transparency for? Not with the current system, and likely not with Swing; whether snapped-to-grid or unsnapped, the bounds are set with regard to each token image. It's just "easier" (I'm just imagining it in my head) with JavaFX. In order to accomplish what I think you want, an image object would need to be aware of either it's transparent or visible areas, and have mouse/touches pass through it if its transparent. Each image would need to be encased in a Node to have this nifty feature, which would be sub-optimal as compared to replicating one image over the Canvas.
Well, in our current D&D game, for example, we use top down view tokens. With weapons and whatnot, this often leads to the tokens hanging outside their block. Usually, it's just something like a weapon, so the token ends up being a lot of empty transparent place as the system makes a boundary box around the whole thing, which then makes it difficult to click on tokens next to it. I wrote system in JS while doing some experimentation a while back where I could overlay images (using an img tag) and click on ones below that you could see through the transparent section of the top layer by quickly copying the image to a canvas, getting the color value of the pixel that was clicked, checking the alpha on that pixel, and then, if it was transparent, make that layer not receive click notifications (and with some browsers, had to hide it) then resend the click event at that location (when I had to hide, I'd reshow immediately after the click event was sent and it'd be visually imperceptible).
FYI, I personally would instead change the code for bounding boxes. So if you edit a token to zoom it out, ie via the lower right hand token image next to handout, make it so the binding box stays conformed to the actual size of the token regardless, unless set to freesize vs the size of the image.

Just seems it should act this way in a grid restricted game.

Re: MapTool 1.4

Posted: Mon Feb 03, 2014 2:07 am
by Full Bleed
Lee wrote:Ah, it is as I surmised. I won't close the door on the idea; I do have to say that there are factors within the current system that is dependent on the bounding box surrounding the image. Of course, you could say that it is a special context, only checked when clicking/touching the image, but I'll reserve looking at it until the new mapping system is visited. As much as possible, we would like to implement optimal practices like the replication I mentioned. Once that is in, there should be leeway to put in more expensive processes.
Take a look at Battlegrounds RPG. With it you select an image by clicking on a visible pixel within the image, so there is no real "bounding box" to create the sort of issues that MT has. I followed the early development of BGRPG and MT (ultimately settling on using MT for my games) and I think token selection is still one of the areas that BGRPG has a distinct advantage.

Re: MapTool 1.4

Posted: Mon Feb 03, 2014 3:52 am
by Lee
@Jamz, FB, KaylaKaze
Thanks for the input. We're building this from the ground up, and everyone's aware that there're a lot of considerations. Sometime in the next 3 days, we'll have both the database demo, and a (simple) POC video for what we've been tinkering with, with regard to the map system.

Since it's at the latter end of our project plans/stretch goals, we haven't gone all in, but we've done a lot of research and practical reviews on possible technnologies. The POC uses one such avenue, but we won't go into the particulars, since we might end up using another. Ultimately, we'll be doing it the way we are comfortable with. I am aware of the last discussion that was had regarding what vision approach should be used.

Anyway, the POC displays a finite map as opposed to MT's current system of a boundless one. I'll be opening a thread discussing that soon, but I just didn't find much in the way of anyone implementing a practical use for an infinite map, apart from that cool zoom-in demo (I think we all saw that). I think a finite map that can be re-sized on the fly is more practical. In hindsight, it might have helped with performance problems associated with the vision system.

Just to reiterate how we want to execute development, the first phase of is tied very closely to how everyone knows MT; apart from making stuff easier to use, anyone familiar with MT won't have to learn a lot of new stuff. That's our nod to the current user base. Subsequent phases will be different, as everything might change under the hood, apart from macro script handling. It's very plastic right now.

Re: MapTool 1.4

Posted: Mon Feb 03, 2014 10:00 am
by aliasmask
I'm all for a finite map since it really isn't practical to build an infinite map memory-wise. Snap to grid get funky when X gets in to the millions with movement. The only think I would like to see is a center graphics feature in case I'm drawing an area map that's too close to the boundary. Then again, maybe the map area is so huge that won't be an issue. Generally speaking, I try to start the start area of a map at 0,0 so when switching to map for first time the intended area can be seen without zooming out and back again.

Re: MapTool 1.4

Posted: Mon Feb 03, 2014 10:22 am
by wolph42
aliasmask wrote:I'm all for a finite map since it really isn't practical to build an infinite map memory-wise. Snap to grid get funky when X gets in to the millions with movement. The only think I would like to see is a center graphics feature in case I'm drawing an area map that's too close to the boundary. Then again, maybe the map area is so huge that won't be an issue. Generally speaking, I try to start the start area of a map at 0,0 so when switching to map for first time the intended area can be seen without zooming out and back again.
also something I learned over the years...to start at 0,0.

@Lee: you say its would still be possible to change the boundary later on. In terms of memory and speed, lets say that someone wants to create the 'zoom movie' again, would the demand remain (roughly) the same in the current and your new system? (or would yours still be more efficient?).

I ask because one of my earlier projects was compiling all available map material into one map in maptool for Warhammer. That was a succes, but it means that you have 'global' scale and you are able to soom in upto 'token' scale (e.g. several building in a city.) In all its pretty cool, although the maps are demanding in resources making it a bit slow.

I have the campaign file available if you're interested.

Re: MapTool 1.4

Posted: Mon Feb 03, 2014 7:15 pm
by Lee
@A.M. I'll take note of that. We'll definitely cross that bridge as the most important aspect is presenting a comfortable design experience, where no detail is too small.

@wolph Even if we just use the same rendering techniques as what we have now (i.e. scale, clip, fill), things will definitely be faster as the process will go through hardware instead of old Java2D. There are really a lot of approaches to making a map system. We're tinkering with several right now. The demo will feature familiar approaches found in 1.3. What to expect are:
  • Fog - I'm quite happy with this experiment. Stepping away from the 1.3 code, and doing it here, helped me correct my path computation for unsnapped fog clearing. I'll submit a patch for 1.3 when I have the time.
  • Lighting effects
  • The new token image model
  • Animation API
  • Isometric map potential
  • Panning, zooming/scaling
It's a POC, so set your expectations to the minimum :lol: We didn't do snapping-to-grid, and VBL, as we have different ideas on getting these done, both of which would need time to code.

Edit: I'll ask for that map when the time comes :)

Re: MapTool 1.4

Posted: Thu Feb 06, 2014 3:59 pm
by JamzTheMan
Sounds like cool stuff! I'm exitited to see where you went with the lighting effects. I started recently looking into some websites that touched on 2D lighting and looked for an easy way to add a fade affect. It turned out to be a little much to take on for now with the current system.

I wasn't really concerned with Isometric view UNTIL 2 months ago when I downloaded Shadowrun Returns. FYI. if you download this game for the PC, ALL there artwork is in png form in a series of folders under artwork. Some really nice stuff in there! And of course, since the game has it's own editor, there are other map/art packs from the community. If we got just an isometric grid, that would rock.

As for VBL, I'm thinking Ray Tracing really does seem to be the way to go. I came across this blog and even the Javascript version of the code seems to work better than MT. If properly coded, MT should be able to hand a lot more VBL and light sources than it currently does, and in real time.

http://www.redblobgames.com/articles/visibility/

Re: MapTool 1.4

Posted: Thu Feb 06, 2014 5:32 pm
by Virenerus
Very cool article. You are right, mt should have a faster vision engine. And I also like the idea to use the shadowrun returns images. The game looked really good.
Would love to see these implemented somewhen^^

Re: MapTool 1.4

Posted: Thu Feb 06, 2014 6:51 pm
by Lee
@Jamz For great assets, I suggest Blood Brothers and Blood Battalion from Mobage, moreso for the latter, though they halted development as it didn't profit as much as the former. But the art is topnotch, and I've been meaning to collect the cached images, but I'm just too busy these days :lol:

Don't expect too much for the demo :lol:, it's more or less a play on what's possible on the tech we chose to make the demo. We're still in process of reviewing tech and accumulating agnostic code. That part of the project is at the latter stages of our plans.

With regard to lighting, the demo just shows ambient lighting, and light diffusion from a source, none of the particles/pixels from the light source interact directly with portions of the fog. We ran the ambient light on a threaded system we plan to use to simulate time; this same system will be the basis for customizable clocks and calendars in campaigns.

The demo is on a map generated using an isometric tile, with an isometric actor. Unfortunately, the actor is not fully 3D, so it rotates like a paper mini/doll. We're pretty proud of something we dabbled on for a day :lol: I won't spoil the rest of the "surprise". I'll upload it sometime later; I just have to make sure the video comes out nice.

Good article, BTW, ray tracing was the preference of username, IIRC. We're testing everything, actually. The likeliest outcome is an amalgamation of techniques based on what our team deems as a right combination of performance and aesthetics.

We're more concerned with coming up with the right model for maps. VBL and lighting come later since a well defined base makes writing the interplay between map objects and the vision-related systems, a lot easier.

Re: MapTool 1.4

Posted: Sat Feb 08, 2014 3:29 pm
by Bhoritz
@Lee: I would like to add a point for being able to reach through transparent pixels.
My use of Maptool is certainly a little unusual, but what I am now developing for isometric use of Maptool would certainly benefit from the capacity to be able to select through transparency.
As you can see here, the figures I am making have a lot of transparent areas and bits sticking out:

Image

The problem would be the semi transparent pixels (the shadow), which shouldn't be selectable (I think).

Re: MapTool 1.4

Posted: Sat Feb 08, 2014 7:37 pm
by Lee
@Bhoritz When put like that, it now is very clear. It shouldn't be hard to do, though there are several ways to do this. We'll work out what's best. Thanks for the input, and that iso art really looks nice!

Re: MapTool 1.4

Posted: Sun Feb 09, 2014 12:35 am
by Full Bleed
Lee wrote:@Bhoritz When put like that, it now is very clear. It shouldn't be hard to do, though there are several ways to do this. We'll work out what's best. Thanks for the input, and that iso art really looks nice!
I've been pushing for non-selectable transparent pixels for many year in MT... and with isometric, it is darn near a necessity.

So if you do pull this off, I will be very happy. :)