aaargh.. too many games to try!

I figured out that I could interpolate all the positions that I wanted to slice at and scale the polygon down integer intervals.

Then I bucket sorted all the vertices and was then able to figure out how to construct the individual strips by looking for pairs of lines that were closest to each other.

Uh.. what?!?!

So solve all the pin joints together in one batch, then all the distance joints, and so forth. And they'd better all be in contiguous memory.

Ah.. okay, that makes sense, thanks!

This doesn't really seem that hard to retro-fit, it's simply moving the functions/methods out of the child objects and into the parent, leaving the children as POD.

As a digression, I'm pretty sure that x += v*dt; v += a*dt; and v += a*dt; x += v*dt; are both semi-implicit Euler (you could move v += a*dt; from being the last thing to do before rendering to the first thing to do after rendering and nothing would change).

That never occurred to me, but you're right!! Weird.

I guess there might be a difference in situations where your acceleration/forces are a function of velocity and/or position (i.e springs rather than gravity)?

You're right.. well, it's not Euler anyway

Maybe I'm just brainwashed by OOP, but I've had a hard time trying to figure out how to apply this sort of idea to the majority of use cases in our code, which is "a bunch of different objects which support a given interface".

In such cases, the behaviour is uniform, but the data is mixed.

For instance, all PhysicsJoint objects have a Solve() function, but each has unique internal data: pin joints are described by a local position on each body, distance joints have an added distance parameter on top of that, directed distance joints have an axis direction on top of that, and the data for angle joints is completely dissimilar to the others.

Probably I'm just confused in my approach..

That said, I generally use second order Euler integration anyway. Assume that acceleration is constant over a frame, even when it's not:

Code:

v += a*dt;
p += v*dt - 0.5*a*dt*dt;

Because you're updating velocity first, then using the new velocity to update position, this is actually NSV/Semi-Implicit Euler: http://en.wikipedia.org/wiki/Semi-implicit_Euler_method

I think RK4 is pretty useless, it's much more complicated and it's questionable whether it behaves better than NSV. If you're using Euler steps, just swap the order so that velocity is updated first, and you're much better off with almost no work

I'm pretty sure it's not simply a matter of moving verts "down" (in worldspace? in screenspace?), since that would only handle the effect where the background rolls away from the user; the foreground also needs to "roll in".

The cylindrical mapping/deformation which was suggested seems like a better bet; if anyone implements any of these ideas I'd love to know what the actual solution is.

I haven't had time to try it, but I've always wanted to attempt doing *proper* line-of-sight/visibility in a roguelike setting.

Specifically, all of the grid-based methods seem to be approximations of the precise solution, which is beam-tracing (or whatever you call portal-based visibility/shadowing, where you intersect the view volume with portal regions and then use that to generate new volumes which you then further intersect, etc.).

This would give you an exact visibility polygon, and you could then decide whether cells which are only partially overlapping should be considered "lit" or not. Or you could implement variable shadowing and let them be partially lit.

raigan
p.s - if you need to cast rays for whatever reason, this is a Bresenham-like algorithm which will work perfectly: http://www.cs.yorku.ca/~amana/research/grid.pdf
p.p.s - people using Bresenham for anything other than what it was designed for -- rasterization of visually-uniform lines -- is a pet peeve

I can't find them right now, but I've definitely seen a couple demos of the Stam simulator running on GPU; I think probably they were from NVidia/ATI, and AFAICR came with source.

You could try emailing the author of Plasma Pong, I remember that having a fast+highish-rez simulation. http://www.plasmapong.com/

Possibly more productive than making the Stam method run faster would be to find ways to reduce the smoothing/damping/dissipation that happens, so that you can use a much lower resolution without losing as much detail. I'm afraid I don't have any good links for you, it's been too long since I looked into it.. but definitely there are a lot of papers dealing with similar-but-improved approaches.

SPH is also an option, as is Lattice-Boltzmann. Probably it depends what you want to use it for.

I can't find them right now, but I've definitely seen a couple demos of the Stam simulator running on GPU; I think probably they were from NVidia/ATI, and AFAICR came with source.

You could try emailing the author of Plasma Pong, I remember that having a fast+highish-rez simulation. http://www.plasmapong.com/

Possibly more productive than making the Stam method run faster would be to find ways to reduce the smoothing/damping/dissipation that happens, so that you can use a much lower resolution without losing as much detail. I'm afraid I don't have any good links for you, it's been too long since I looked into it.. but definitely there are a lot of papers dealing with similar-but-improved approaches.

Record yourself speaking, look at the spectrum over time in audacity or something, and synthesize it using tones and filtered noise. Go for it. 

I think that's called vocoding

I totally share the "more interested in computer-y sounding speech rather than high-quality" sentiment -- obviously the latter is a hard problem, but the former is found in some 64k (and sometimes 4k!!) demos, which is much more interesting since it suggests that it can be cheap and relatively simple to do.

I've found source to a synth used for a 4k demo.. sadly it appears to be in Amiga assembly!! http://ada.untergrund.net/forum/index.php?action=vthread&forum=4&topic=267

It depends how the dictionary is implemented, but if it's something like a hash map then that should be fine. AFAIK in C# the Dictionary object is hash-based.

You could also probably get away with an array of strings in alphabetical order and a binary search.

If you want auto-complete or other "neighborhood" type functionality then tries would seem to offer that, but if you just need "does this word exist, and if so can I have the object associated with it" then whatever's supported natively by the language is probably fine.

Then again, I'm quite lazy

(A quick Google turned this up, it might be useful: http://www.codeproject.com/KB/game/Anagrams2.aspx )

This is something I've always wanted to know more about, but I haven't found any great resources on the topic; simple speak-n-spell type speach happens a *lot* in the demoscene, so it seems like someone knows a good solution.. but they haven't written any tutorials

That looks awesome! I don't remember seeing it before, thanks

No, it's a more traditional platformer, it's just that all the creatures in the world are fully simulated articulated characters rather than simple boxes. So, the things walking in the videos would be "enemies" which the player interacts with.. possibly like Shadow of the Colossus? Can you tell it's still very early in development?

We do have some spin-off ideas in mind if we ever have time later, for robot-battle-arena/soda constructor type games; SC was definitely a big inspiration though, which pushed us to think about animation and physics.

I have to admit, I agree with Eskil about game designers. What do they actually create? Nothing -- their rules/systems need to be transformed into code first, and if they have no grasp of how this works then their ideas may be quite difficult to implement.

It's sort of the difference between an illustrator and an architect -- both know how to draw, but only the latter knows how to draw structures which will meet actual requirements in reality (i.e be structurally sound). If you just want a nice drawing then either is fine, but if your drawing is to ever become a reality you should strongly prefer the architect since they understand that the realm of pure concepts must be tempered with the realities of engineering.


Actually there are analogues to "designers" in other fields, in fact this happens more often than you'd think in other fields, many artists have "studio helpers" who do much of the painting, fashion designers have subordinates who do much of the actual designing so that the designer is in fact more of a director.

For instance AFAIK the later Chemical Brothers albums were made by them telling their engineer what they wanted (i.e "make the bass sound more growly") and him doing it. But in their case, they have lots of hands-on experience with synth programming so they're probably quite good at directing an engineer, since they know exactly how everything works.

This last point is *VERY* important though. If person X is making a painting by directing a helper who does the actual painting (as is the case with studio hands), it makes a HUGE difference if X knows how to paint or not. If they don't, then they'll be floundering when trying to communicate with the painter, because they won't be aware of the jargon, common techniques, etc.. they'll be clueless. If they do know how to paint, then they're much more effective at directing and communicating, for instance they can quickly sketch something in order to directly demonstrate what they mean, rather than having to communicate in a purely verbal/non-painting-based manner.

So obviously it would be better if designers knew how to program, because they would then be fully literate in terms of the task-space in which they're operating. And I suspect part of Eskil's problem is that it's not at all hard to learn basic programming, it's simply a more rigorous version of what they're already doing, i.e describing a system of rules and properties which interact. If you can explain to someone how to cook Kraft dinner, then congrats you know how to write an algorithm.. you just need to learn the 30 or so words necessary to encode this algorithm in a way computers can understand.

So, an alternate solution would be to teach non-programming designers how to program, even if only in a scripting language, rather than firing them.

Of course, being a programmer -- not a good one though, definitely more of a "designer who has learnt how to program" -- perhaps I'm biased. But that doesn't mean I'm not right

hey,
Mostly I stay in the technical section of the forums, but I figured posting here might make more sense.. please move this if it's better suited to a different forum, sorry for being such a noob!

Anyway: we've finally managed to get our game Robotology started (after a year of groundwork-laying), and have put up a couple videos showing some of our exciting adventures in the world of simulating robots. Just in case anyone here is interested, our blog has about 5 readers so I'm assuming most people haven't seen this yet

http://www.metanetsoftware.com/blog/?p=508
http://www.metanetsoftware.com/blog/?p=334

thanks,
raigan

OpenAL should have some filters built-in, this is from the API docs:

"Filter Objects
A filter object contains the information needed to set up a filter, i.e. the filter type (low-pass, high-pass, etc�), and values for each of the parameters that control the filter. Filter objects can be used to filter the direct path (dry signal) of a Source, or used to filter the send path (wet signal) to any of the Auxiliary Effect Slots."