In the original screenshot the shadows seem much larger (i.e you'd need to extend the fins much more than you are currently), much more faint (i.e maybe only go from 0.3 to 0 alpha) and maybe not linear falloff (i.e try using a gradient texture with a faster-than-linear falloff, like exponential decay maybe?).

One advantage of using a texture would be that you can add rounded corners by using a circular gradient texture (and just use a strip along the middle of the circle for the straight edges); see this for some ideas http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html

Looks good though

sorry, I didn't mean for it to sound like that was our page -- we just implemented Jetro's idea, I'm not him!

Is all your level geometry rectangular? It looks that way from the mockup but I don't know if this is permanent or just temporary.

In this case, just generating "fin" geometry with a gradient texture around each rectangle is super-trivial. No need to worry about finding the outline of the shape, just generate fins around everything and draw them between the floor the walls so they'll only be visible on the floor. In corners this will create double-darkening but this is what ambient occlusion would also do.

Even in the case of general polygons, generating the fin geometry should be very straightforward. I'm not clear what your resistance to this approach is based on, as it seems to be the simplest, cheapest solution to me.

We're doing something very similar to this (for anti-aliasing as explained here http://jet.ro/2011/06/04/better-looking-anti-aliased-lines-with-simple-trick/) with our 2d game and it's working out well; after this thread I'm even thinking of trying this outline/drop shadow idea for one of our own games!

Yes, exactly, subdividing the mesh seems completely against the tile-based approach. Also this thread made me realize that I do not need a mesh at all, if the environment is 2D I can just render all the tiles onto one texture and then display this texture (together with the prerendered shadow overlay).
All in all I only need two textures for the static environment (and only two quads) - one that is rendered beneath the game objects (shadows and floor) and the other that is rendered above (walls).

There is an upper limit to how big a texture can be, and even a 2048x2048 texture is a pretty small level depending on the game.

Also, when it rotates the edges of shapes may look different/weird since you're sampling a texture rather than rasterizing the edges of polygons.

I guess it really depends on art style and specific game stuff like how large your levels are...

I guess I was thinking (a) most 2d games are fillrate limited, doing fullscreen pixel work isn't going to help this (b) it seems ridiculously wasteful to render the objects black then blur out when the geometry he needs is already explicitly defined.

I agree it probably doesn't matter as computers are fast, but it just seems like the wrong approach... fullscreen blurring is expensive even today.

It seems like a huge waste to use a pixelshader/blur if the walls/etc. are static. You could just generate quads along the edges with a gradient texture applied to create the shading, no?

Shouldn't the deformation of the joint be implicit in the state of the bodies? If you know the current position+orientation of the bodies, and you know the joint geometry relative to the bodies (constraint points and axes are typically defined in the local coordinate system of the bodies) then that should be enough, shouldn't it?

Sooo... has anyone benchmarked this in AS3 with vectors and arrays? I've always used a 1D Vector.<> since, when used as a virtual grid, it's indexed via a 2d->1d hash function anyway.

I'm not sure why there isn't a thread already for this, but anyway... it's this weekend!
http://www.tojam.ca/home/default.asp

Thanks! I didn't realize it was Buster (of Akuji fame).

I'm trying to track down yet another obscure 2000s-era freeware game, this time Kimaru:
http://www.homeoftheunderdogs.net/game.php?id=4085

It's in TIGdb, but sadly the link is broken (vector.co.jp is asking for an ftp name/pass):
http://db.tigsource.com/games/kimaru

Does anyone have a copy?

thanks,
Raigan

Just in case it helps, what you're doing seems very similar to splitting a concave polygon into convex pieces in a binary space partition tree.

Okay, after having played it: you REALLY need to try the Fire Emblem games! You'll love them.

One UI suggestion would be to enable all the usual Advance Wars-type info, i.e being able to mouse-over a unit to see its attack/move range, attack/defence strength, etc. But possibly this is one of those things you mentioned was impossible due to the engine.

2. I was rather disappointed to find out that unlike the melee units, archers can't move and fire in the same turn. I understand the balance reason, but maybe add a line of dialog to mention this in Battle #2?

Mentioning it can't hurt, but I think most players will assume that they can't move+attack in the same turn since that is the established convention in both Advance Wars and Fire Emblem.

The game is probably best described as like "Advance Wars meets JRPG". It's primarily a story-driven (what does that even mean?) tactical wargame, with lots of people stabbing each other with swords and shooting arrows at each other and so on.

This sounds almost exactly like the Fire Emblem games -- not a bad thing!

Does anyone know if they actually render the voxels directly, or if they were just used as a modelling tool and then baked to sprites for use in-game?

the plan was to have a platformer game where you build part of levels and then play them through. you'd get only limited stuff to place and multiple solutions for each level.

You should check out Farbs' Polychromatic Funk Monkey (bottom of the page)... very fun! http://farbs.org/games.html

I would ask the DF authors how they're doing it

Thanks... that makes sense!

Do you mean you should calculate the error as [distance between the edges of the shape] rather than [distance between centers minus combined radius]?

I'm assuming that this is wrong and I don't understand what you mean, because the above should be exactly equivalent; in order to calculate the position of the edges you would need to refer to the center positions, which means that both approaches end up being identical.

Example: imagine two objects in 1D, with objA at the origin and objB at some position along the +x axis:

Code:

center_based_penetration = [distance between centers] - [combined radius]
                         = posB - (radA + radB)

edge_based_penetration = vector from [right edge of objA] to [left edge of objB]
                       = (posB - radB) - radA
                       = posB - (radA + radB) //same as center_based_penetration

Sorry for being so slow... I feel like there's a good insight/tip here but I'm not grasping it

(So if you're resolving against the floor, subtract yourself out of the floor, don't rely on your collision depth value, because it will have errors in.)

Can you explain this part? I'm a bit confused