For what it's worth, I think both of these approaches are just special cases of Dijkstra's algorithm.

I don't think there's a particularly meaningful comparison, though I'd be interested to hear counter-points.

These fill approaches are just visiting each node, there's no computation of path distance (as opposed to Euclidean distance for the shading), and the edges have a very fixed implicit structure.  Unless I'm missing something, the runtime is O(V), less than Djikstra even after you account for the fixed edges to potentially drop that to O(V*log(V)) from O(E+V*log(V)).  That qualitative difference implies they're doing something very different.  On the practical side, Djikstra visits all of the nodes and computes all shortest paths, whereas basically the whole point of the recursive shadowcasting is to efficiently not visit non-visible nodes as defined by the shadows.

One extension of the flood-fill approach that incorporates some notion of line of sight, rather than just spilling around corners, is generally called recursive shadowcasting.  One way to look at it is that it's efficiently raycasting out from the source.  It's actually a really neat algorithm, and works well, with several tuneable parameters.  There are some notes on RogueBasin about it, and I have a little writeup and simple code here:

http://www.rocketshipgames.com/blogs/tjkopena/2014/07/recursive-shadowcasting/

I think this could be applied fairly readily to the OP's task.  In my demo I modify a tile layer of shadows above everything else in the 2D world, but presumably you could darken or otherwise change the view of a floor mesh and any geometry in the tile to render its visibility.  A simple distance calculation for visible tiles would let you fade things out if desired.

Demo from my writeup, displaying a 3 state map (completely unseen/seen but not currently visible/currently visible):

The sprites aren't mine, but kind of a neat GIF playing around with recursive shadowcasting:



Code is at the link above, for what it's worth.

If you are calculating distances you need calculate a Math.sqrt.

Only if the visible area is a sphere, not a cube - or is that what you meant?

You don't need a square root to check distance, just square the threshold distance and compare against that.

Today I made another demo of some recent developments in my library:



This is showing objects, bounds, and a tilemap interacting through the basic arcade physics components.  The green and grey chunks are an autotiled grid map, not objects in the same sense as the falling red boxes.

Still looking real sweet.  If you're giving yourself some leeway from the original art, I would minimize or remove the horizontal lines on the walls.  Combined with the vertical lines of the tile boundaries, they look more like stacks of boxes than walls.  If trying to stay very faithful to the original art then you're stuck, but otherwise though these look great, the earlier blank walls actually read better as "walls" rather than "stacked stuff."

What if they weren't symmetric?  One claw facing down from the version on top, and the viewer-facing one from the other?  That might provide more indication that they're not guns, though I don't actually think that's a huge problem given their color.

These are the actual miniatures that came with the game: http://3.bp.blogspot.com/_804hr-DG6uc/S-eYXWscD7I/AAAAAAAAAxA/06FhB4EeB3s/s400/Genestealer_Sample.jpg original they are not painted and dark purple.

One of the bits of 40k background is that the Tyranid faction, which the Genestealers are part of, is broken up into hive fleets comprising different strains, Hive Fleets Behemoth, Leviathan, and Kraken being the main ones.  Each of them has their own associated color scheme.  Space Crusade predates a lot of that fluff and was retconned into it as the Tyranid faction developed---AFAIK it's not really settled which, if any, hive fleet they're supposed to be from---but that's the game world support for all the different colors of Genestealers floating around.

The hunched over Genestealer is definitely way better.  The other one is maybe more faithful to very early Genestealers and Hybrids, but I think the hunched over one is actually much more identifiable as the modern Genestealer models, in addition to just being a better sprite.  Much more menacing & readable as a close combat enemy.  Maybe slim the shoulders just a tad so it reads a bit less of bulky and a bit more of insanely fast?

It's definitely worth burning a color to make the Genestealer face purple.  Anything else is just going to lose a ton of recognizability.

Awesome stuff.

As a big 40k fan, these little guys look super awesome.  Just in time for the new Space Marines codex coming out this weekend!

Today the simple physics engine for a new version of my library RocketHaxe is starting to look credible:



They're still quivering and sinking into each other a bit more than I like, but I'm not sure how much more I can account for that in the simple 1-pass impulse reaction model being used.  My hope is it's workable enough for typical platformers, shooters, and such where objects aren't generally stacking up so much.

Other demos as I go along have been posted to my blog.

hmm yeah i dont quite know what you mean, anyone else think that? i tried softening the angle at the top of the fez which may be an improvement, what do you think?



Uploaded with ImageShack.us

I had a similar issue.  Quickly scanning through the thread, I actually though the image had a problem loading because it looked cut off.  I think the top of the hat is too perfect (it's completely straight), so it reads funny.  Maybe it needs some perspective?

An update, better or worse?

For what it's worth I like this one a lot more.  The darker blue makes the whole thing thing a lot more muted and drab.  This jumps out at me a lot more.

The individual rooms look pretty great, but the animation doesn't quite work yet.  Similar to what others said, I think you need to show the roof and/or floor(s) rotating to make it really clear what's happening.  Right now the rooms just look like they're sliding past on a conveyor belt or something, not rotating around.

With that rotation, you're going to have to do some sort of distortion, pinching the sides of the rooms as they enter and exit.  If you really want to explore that, you should look up the projections that happen in stitching together panorama images and then code either that or something that mimics the look.  It's not super difficult to do the actual code.

That said, you can probably achieve a lot of that with the other approach you mentioned, photographing a papercraft scene and then stitching them into a panorama.

Other than that I also strongly suggest against using .dep and .rpm unless you are open-sourcing your game. Linux users often do not trust (and with a reason) system/installer packages from alternate sources.

Using them also creates a hassle for people running distributions built on other package managers, e.g., Arch.

I recently put together a simple but pretty reasonable game in Haxe/NME.

The one real problem I've had is that the sound support is not very uniform across platforms.  It pretty much works as expected in Flash.  In native Linux there are a couple gotchas.  In Android it currently requires a lot of manual workarounds.  I'm still working on resolving these sound issues to finish the port to Android.

Overall though I really love it and recommend the combo.  I probably wouldn't bet a huge budget production on it, but for personal or small projects I think it's more than mature enough.

For what it's worth, all of the core engine I developed for that game is available as open source.