philazzi44 / dndcs Goto Github PK

Since our use case involves a touch screen & stylus, with only Left/Right click, zooming with the mouse wheel won't be useful. Need to think up a good way to zoom, and then implement.

One idea is to just have a 'zoom' button in the right-column, and that overrides the Scroll capabilities via right-click (click/drag up would zoom in, click/drag down would zoom out). Zooming altogether is a "do it once and it's done" so we end up not needing anything that's super easy to do.

The loading gif should be centered a little nicer.

Also, it's currently shown until the Map and Fog values are set, which will be misleading to the user because if it connects but hasn't gotten those values, it'll still show Loading.

It would be better to have multiple gifs...

Connecting (when the socket is being spun up)
Initializing (loading static content, and getting the first round of data from the server)
Waiting (waiting for map/fog)

EndTask on the server will cause the client to sit idle, not recognizing that the socket is closed. Normally, the server closes gracefully and sends an Exit message to the client.

What we can do is set up a Client to Server ping (or poll to check the socket itself, if it can tell us if it's open). If it is open, do nothing. If it's not open, we can prompt to reconnect (invoke the Reconnect Menu Option). If the Server is, in fact, gone, that reconnection will cause the client to quit.

Check out the Point Data we save and see how well it performs. It may make sense to save out a png of the fog rather than the list of points. It'll depend on what it looks like in real life.

Zoom capabilities are on the server are disabled for now. The map itself will zoom, but the fog revealing via mouse, Center Map, and other map-interactive functions need to have the math fixed to support it.

Note that the Mini Map issue would need the same kind of math fixes.

Since we can't focus the log (since we don't want to unfocus the picturebox ever), maybe a Copy All button should be added instead. It's also too tiny to be meaningful, so its format should be updated to put action at the start, so we know what was sent.

The alpha fog effect rendering ends up adding the effect outwards to the area that was selected. I can see this being bad for the DM who would only want to reveal a certain block and carefully highlights to exclude a 'secret passage' that might only have a thin wall. The fog effect will end up partly revealing the area beyond the selection, so the players will see more than they should.

If we tweaked the effect to instead apply the incremental alpha inwards, rather than outwards, we'll end up with a dimly lit interior wall rather than seeing over the wall.

Looking at the New Fog (red) polygon drawn on the server, the points link back to the initial point so it ends up not being exactly what the server was drawing.

When a menu item is chosen, some kind of idle animation should be done on it. Glow effect, underline, something!

Take initial Bitmap received and split into array of Texture2D as limited by XNA. I don't know the exact number, but probably safe to code it in a way that it can automatically split & stitch together images at draw time of an arbitrary 'Width by Height' in a config.

When drawing a fog area on the map, it gets saved in the "NewFog" variable. This NewFog bitmap is created as the full size of the map, but I'm not sure we need to bother with that.

We should change it to only be the size of the visible area to the server. They can't scroll or zoom while they're drawing this (or at least shouldn't, so confirm that and fix), then update the NewFog Painting to always render at (0,0) rather than at the translated location. This might get tricky with zooming involved...

The right-column of controls could use a minimap that at least shows where the current screen is viewing. Bonus points for being able to click/drag on the minimap to scroll the primary view.

Some error handling must be sucking up the error generated by the closing socket?

Fit to screen, max of a certain size maybe, but should def shrink as needed.

Click/mousemove events aren't doing anything

see http://stackoverflow.com/questions/6316503/how-to-get-continuous-mousemove-event-when-using-android-mobile-browser

The red area is a little more staggered than I feel it should be, considering we can easily scroll the map which should be causing the same number of repaints. That means something the Mouse Move event is doing when you're drawing a fog area is slowing things down.

Right now, when a Fog Image comes in, it's a black (fog) and white (revealed) map. We then iterate all the data to flip all white areas to be fully transparent.

We should look into updating the Server to send over the transparency (and set it up front).

If that isn't possible, then maybe look into how the Web Client can use the Fog coming in as a mask, where the 'white' ends up being the revealed area. See http://christianheilmann.com/2013/06/15/image-masking-with-html5-canvas/ for masking.

Allow the server to specify a list of items (click & open, or drag/drop a file? manually type it in?)

Client will receive the list of items and show them for players to write down on their sheets.

Servers "X"s out the item list and it vanishes from the client

Dependencies

• Items are saved on the device, rather than just written down. I think Dave currently writes them down on paper, so it'll end up being a burden to have to save them to the device or in a url somewhere.
• If we have a distinct file, any on-the-fly changes wouldn't be supported. Keyboard in the touch interface is limited/non-existent.

Flipped View has been disabled for now, and must be re-implemented in both Win Forms and Web Sockets mode.

Web Workers allow sharing ArrayBuffers (and maybe other data) in a way that basically moves the object into the other context (cannot share the object amongst two in the normal threading way.) This might be useful for when we have to draw the map bytes to a Map Image, or the Fog - anything else, it's probably not worth the extra complexity.

See : http://www.html5rocks.com/en/tutorials/workers/basics

Since SHIFT + Wheel is to scroll left/right, and CTRL + Wheel is to zoom in/out, the stopgap in place now to prevent accidental zooming is that you have to hit Enter/Click to commit the zoom, and Escape/Right Click to cancel it.

Simple idea is to just change the zoom key from LeftCtrl to RightCtrl, since our use case is normally LeftShift + Wheel to scrol..

Check to see why, and then queue up the messages to be threaded out.

When a Center Map action is received by the Client, it'd be cool to animate the translation to the point, rather than just a hard set. Eye candy is nice.

Since the socket connection appears to get severed sometimes, the client should support a "Reconnect" option that simply re-initializes the connection to the same server. Not elegant, but will work for us.

Add support for rotate 90, 180, 270 to client, so we don't have to fuss with Desktop resolution orientation if the TV orientation is wrong.

On zoom in or out, take current center map and set it again. Need to take map coordinates, not scroll pos.

There may be some left.

Change Easing to infer the previous duration percent and speed percent by omiting the value