Methods for improving sand games

[madk]

I figure this can be a good place for discussion of development of
better systems for sand game management.

The Multithreading Theory:

While browsing some programming forums, I came across some
multithreading discussion, which gave me an idea - could it be
possible and/or practical to have several separate processes which
interact with each other only when necessary? The idea seems plausible
to me - Have physcis updated by one thread, reactions by another, user
input detected by another, and updating the screen yet another? The
processses would not be in sync with each other to allow maximum
efficiency, but would interact with each other just enough so that
each individual process can easily send and recieve data from the
other threads.



BTW thanks for the invite, and please note that I do not enjoy getting
emails from anyone who is not a close friend or family member. If you
wish to contact me privately, please use the PM feature at
fallingsandgame.com

[inferno]

Good point about multithreading, but the problem is this:
multithreading is difficult to pull off AND (worst of all) it can
cause dangerous memory fragmentation. Multithreading sounds great,
but in the end it just doesn't give that much of a boost (according to
theory). However, if simple integer manipulation is used to give
pseudo-multithreading (like BS2's timers) this can create unique
features for the user to manipulate via scripting.

[madk]

I'll have to throw together a demo sometime just to test this
possbility.

> > fallingsandgame.com- Hide quoted text -
>
> - Show quoted text -

[tehCheese]

I have no idea how to use multithreading in C++... do you inferno?
I've just never had to use it.

[inferno]

SDL has a branch that does multithreading.

[inferno]

Another idea: some sort of combination of the normal pixel and
particle-based engines. It wouldn't be very fast, but its
capabilities would be practically endless. There would be pixels
(elements), then particles (specialized elements including things like
parts of ragdolls and Multi-Pixel Objects that would be used for
collision detection). This isn't a priority, just an idea being
thrown out there.

[madk]

For multipixel objects, I've went over the issue may times, and only
one solution seems to present itself, tell me what you think.

Constraints.

For pixel games (QuickSand) this would be quite lmited as you qould
not be able to accurately rotate the multipixel object.
It's another story in particle based games, it seems. That should
actually not be very difficult.

> > > > > - Show quoted text -- Hide quoted text -

[tehCheese]

If you're going to have constraints, you might as well make an entire
physics engine. Which would be cool.

[madk]

Constraints are pretty much a definate for QuickSand once I get around
to it, so be looking forward to it.