Doesn't mention ASCII, so maybe this isn't the right one, but here's my guess:
http://roguebasin.roguelikedevelopment.org/index.php?title=Comparative_study_of_field_of_view_algorithms_for_2D_grid_based_worlds#Gameplay_study

And a more verbose pdf version: http://roguecentral.org/libtcod/fov/fov.pdf

I've generally found Flash's Number to be fucking horrendous at even the most basic math. Fucking up simple things such as just removing 0.1 from a value that was an integer to start with.

Are you telling me it's a platform thing?

Yeah, as others have pointed out this is just a fundamental problem with how floats work -- there are some numbers that look normal in decimal that can't be exactly represented in floats (e.g 0.9 turns into 0.89999998). AFAIK this is no different than how the result of (10/3) isn't exactly representable as a decimal (with a finite number of digits anyway).

Here's an online tool I found that lets you see how any given decimal will be represented in single and double-precision floating point: http://babbage.cs.qc.edu/IEEE-754/Decimal.html

If you have a replay system that's based on recording player input (so that "viewing" a replay is really re-simulating the whole game, with pre-recorded input being fed to the game in place of the keyboard's current state), then you can store replay data with each highscore.

You could then write a "spider" which scans over all non-verified highscores, loads+runs the replays, and compares them with the submitted score -- if they match, the score is verified, otherwise it's deleted.

This seems like it would be "perfect"/unhackable, but it relies on a deterministic simulation where replay data from any computer can be used on any other computer. Also, it's still somewhat hackable in that players *could* theoretically use external tools to make "Tool-Assisted Speedrun" replay data. At that point I'd be willing to give them a highscore though, they've earned it

Awesome tutorial!

500k objects?!?

@jotapeh: I definitely want to try an iso-style world with smooth/vector art sometime, but this project has to be bitmap-based for a few reasons.

@Chromanoid: Actually, I'm using the flood-fill approach specifically to avoid having to explicitly form polygonal data (i.e CCW list of verts). This is because Flash can't draw polygons with holes, and I need to draw lots of polygons with holes which are procedurally placed, so to draw them as actual polygons (which would require adding edges to join the hole contours with the outside contour, making sure the edges don't cross other holes, etc) seemed like a lot more work than just drawing the polygon edges and floodfilling

Woo, it's working! Thanks again; it does seem pretty stupid that I have to hand-plot pixels when there's a powerful drawing API built in.. curse you, Adobe!

Of course, generating the test graphics was the easy part..

Wow, thanks! I'm just sitting down to pull apart the world-drawing code right now

I guess Adobe/MM assumed that people would be using high quality most of the time and wouldn't care about pixel accuracy when drawing lines

I am using bitmapData, I should have mentioned; basically I'm generating a bunch of iso-style sprites by drawing lines into a bitmap then flood-filling.

Of course, when there are gaps in the corners between lines the flood-filling breaks, and even when that doesn't happen nothing is the perfect straight-diagonal that you see in pixel-art.. there are ugly places where the line shifts down by a pixel.

@Chevy: if you drew a rhombus out of four such lines, could you guarantee that the corners all met? If so then that could be a pretty good option.. I was just trying to get something simple+fast working.

Since I only need lines at 45deg angles I can probably get away with something much simpler than Bresenham.. but this is turning into much more work than I thought

Thanks.

I'm having some problems while drawing lines via Actionscript; the result is meant to look like pixel art, so I've turned off anti-aliasing, however this is causing some graphical glitches where things are rounded incorrectly.

Examples of the errors I'm seeing are e.g a polygon defined by a chain of points connected by lines has holes at the corners (i.e empty gaps between where one line ends and the next starts), or 45deg lines having a slight "shift" partway along their length rather than being a perfect chain of diagonally-adjacent pixels.

I can't seem to find anything via Google on how to get pixel-perfect aliased line drawing working in Flash, and no matter what I try (shifting coordinates by half a pixel, etc) nothing works.

Does anyone have any advice/experience with this sort of thing?

This might be of interest (I don't think it's ever been completed though): http://playtechs.blogspot.com/2009/03/square-based-turn-based-rigid-body.html

I think you probably don't really need a "simulation", the movement of objects might be better of being modeled using logical statements about how they should behave in each particular case rather than something more akin to a physics simulation.

For instance, this isometric room example: http://bannalia.blogspot.com/2008/02/isometric-room.html

If you look at the source code you'll see that object movement is described procedurally, for instance (AFAICR) gravity is simply a case of moving objects downward if there isn't anything below them, and pushing whatever's below downward otherwise.

The way that pushing/simulation works in that room is actually pretty smart, it can handle stacks/etc. without any actual "physics".
   

and classes have a Person and then class specific stuff in them
...
It gets a little messy here, cause you need some weird way of doing component or entity inheritance which I thought the point of components was to get rid of stuff like this.

I agree with others that this isn't actually a problem, since you would have some sort of tool/mechanism to generate the data for you (e.g the Person would be an "archetype" to use Scott Bilas' terminology). Although I agree that in this case you're back to having a hierarchy, the idea is that the hierarchy exists only as a data description (i.e you could manually add boots data to each type, a hierarchical description that is used to automatically inject boots data is merely a convenience ) and the actual runtime data is all "flat".

I also agree that such a system is probably overkill much of the time; I have yet to see a simple/reasonable explanation of how you should approach things like shared data (e.g entity position) that isn't stupidly convoluted, there seem to be lots of generic messages floating all over the place when direct function calls would do just as well.

then can i divide a non tiley environment into tiles? if so how can i implement in flash say for example?

The algorithms you listed (A* and Dijkstra) are applied to a graph, so you need a graph to run them on. A grid (of tiles) is just a specific type of graph, where each tile is a node and each node is connected to four other nodes (i.e adjacent tiles in the graph).

For a non-tile-based world there are other possible approaches to representing the environment as a graph, some of which might be better (e.g more useful, simpler, sparser, more compact, etc.) than a grid of tiles; "waypoint graph" or (increasingly popular) "navigation mesh" are two other types of graph which are commonly used to represent the gameworld for AI/pathfinding that you might want to google for.

Yeah but, humm, for 60 bucks i'd rather buy a good programming book I'll try to stick to free and freely available solutions! Thanks tho.

Leaving aside the issue of whether or not the GPG books are "good programming books", you could just go to the bookstore and read that one chapter.

Alternately you could just use a square grid.. it's good enough for Chess and Advance Wars

There's a really great overview of this problem in Game Programming Gems #7, Article 1.5, "For Bees and Gamers: How to Handle Hexagonal Tiles". I had read all the online resources about dealing with hex grids and nothing clicked until I read the GPG article.

Thanks again everyone for the help!

Here's what we have right now, which seems to be working -- things rotate/zoom around the center of the screen. Let me know if there are any mistakes, I'm definitely an OpenGL noob

Code:

//offset is the screenspace vector from the top-left corner to the center of the screen
//pos is the camera position in worldspace
//degrees is the camera orientation in worldspace
//scale is the screenspace length of a unit vector in worldspace
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glTranslatef(offset_x, offset_y,0);
glRotatef(-degrees, 0, 0, 1);
glScalef(scale, scale, 1);
glTranslatef(-pos_x, -pos_y, 0);

I wasted a lot of time trying to find a bug in our screenspace<->worldspace transformation code, before realizing that for some really stupid reason OpenGL uses degrees instead of radians.. WTF!

Thanks for the fast feedback! Looks like modelview wins it

I have a scene made up of a bunch of worldspace polygons, and I'd like to be able to pan/zoom my camera around the scene. Also in case you can't tell, I have very little experience with OpenGL

AFAICT, there are two ways to realize pan+zoom: using a non-identity GL_MODELVIEW matrix so that the scene is transformed relative to the camera, or using glOrtho() to change the view volume (i.e moving and scaling it around in the world).

My question is: what are the differences between the two approaches? Are there any best practices, strengths/weaknesses with either approach, etc? What is everyone else doing?

Sorry if this is a stupid question!

Then render the texture with a shader

You should be able to do this without shaders as well, via alpha-test.