next »

[BorisTheBrave]

I've never seen tearing in flash. Even in other peoples stuff. Perhaps it's more a bug in the player in some platforms?

[John Nesky]

This shows tearing pretty clearly on my Mac, inside Safari:
http://interactionartist.com/classic/gameloader.php?GAME_NAME=ShatterVoid

And I've seen Flex do some crazy stuff with screen updates too.

[Eraser]

This shows tearing pretty clearly on my Mac, inside Safari:
http://interactionartist.com/classic/gameloader.php?GAME_NAME=ShatterVoid

And I've seen Flex do some crazy stuff with screen updates too.

Doesn't seem to be tearing in Chrome/Win. That, or I'm thinking tearing is something completely different. (The blurring is intentional; I assume tearing is ~1/2 the image would be one color, the other half a different, in this example.)

[Hideous]

I have some slight tearing in that on Windows with Chrome, me.

[Core Xii]

I got multithreading to work on my first try. I don't understand why everyone is saying it's so difficult and uses that as an excuse to forgo proper scalability.

[bateleur]

I got multithreading to work on my first try. I don't understand why everyone is saying it's so difficult and uses that as an excuse to forgo proper scalability.

Multithreading is difficult because of synchronization. If the sync requirements of your app are trivial then there's no reason why it has to be hard in specific cases.

[TeaAndBiscuits]

Got my Lua console up and running meaning now it is going to be loads easier to tweak my settings at runtime Also means I can start work on the more interesting part of my game... WATER!!! Woooooooooooooooooooooooooooooo! 

[DantronLesotho]

I finally got homing missiles to work! It may be a petty thing, but I am super happy with the result!

[David Pittman]

After a few slow months of hobby development (aka extremely busy months at work), I've jumped back into my project with a vengeance, fixing a few long-standing bugs, writing a couple of Blender scripts to make level design easier, and figuring out how to do door collision in a non-hacky way.

Incidentally, who knew doors were so difficult to do right? I mean, they're just doors!  I still need to decide how I'm going make them work with AI navigation; AIs could just automatically open doors in their way, but if I ever want to make lockable doors, then I'll need to mark up the navmesh or something and make it find a different path.

[Core Xii]

Multithreading is difficult because of synchronization. If the sync requirements of your app are trivial then there's no reason why it has to be hard in specific cases.

Any standard game loop can easily be multithreaded by sectioning off the logic into discrete steps. For example pathfinding... Each thread only needs to read from the map data structure, so no synchronization is required. They write the resulting path in a data structure they pass back to the main thread.

Same for AI. To make decisions, entities only need to read the game world, not write into it, so you can just pass AI jobs to threads and let them think in parallel.

[BorisTheBrave]

You neglect to mention any phases that EDIT the game data (mainly the game-logic code). Clearly, that's going to be harder to paralize.

Also, you don't have massive amounts of multi threading if you have a game loop with discrete steps. You want to be working on AI for as long a period as possible because it is computationally expensive. Blocking it off while you do non-ai things is bad for performance.

But even so, games are very rarely going to break from the per-frame synchronization. Try to imagine a non-game program where this is no time at which everything "synchronizes", and they are all trying to edit the same data structures at the same time.

[Core Xii]

You neglect to mention any phases that EDIT the game data (mainly the game-logic code). Clearly, that's going to be harder to paralize.

You also neglected to mention any. Can't make an argument without providing a valid example.

Also, you don't have massive amounts of multi threading if you have a game loop with discrete steps. You want to be working on AI for as long a period as possible because it is computationally expensive. Blocking it off while you do non-ai things is bad for performance.

It's not bad for performance, just worse than your imagined 'ideal' parallelization. It's still better than no multithreading at all.

Processing the AI of every entity at once is obviously faster than sequentially one at a time. But you can't really do AI before you've done LOS, for instance. And you can't do physics before you've done AI, so I don't really see a way past this discretization.

I don't see a reason to, either. Say you've got 4 cores. There are a lot more entities than 4 that have AI in an average game. So all the threads will be working full-time anyway, regardless of how you section off the logic.

[BorisTheBrave]

I meant all game logic as an example of stuff needing to modify the data. You know, changing the position based on the current velocity, destroying objects that have been hit by bullets. Adding to the score. Physical interactions between bodies. I thought it was obvious enough to not go into detail.

Anyway, I think you might have missed my point. I'm not saying yours is a bad scheme, just that there are other schemes one might do that make multithreading hard, in order to eke a bit more out of performance, or to meet different requirements. Just because it is not hard in your app where you have little mutable shared state doesn't mean it is not hard in general.

I don't see a reason to, either. Say you've got 4 cores. There are a lot more entities than 4 that have AI in an average game. So all the threads will be working full-time anyway, regardless of how you section off the logic.

What? No. If you have discrete phases for each part of your game, and others are single-threaded and take 75% of each frame, then you are only using 4 cores for 25% of game time, and they are being underutilized the rest of the time. That's precisely why you need all your different jobs to be concurrent. Even if most of the phases are trivially paralizable, it's likely that it's the ones that aren't that quickly become the bottle neck.

Not to mention that AI isn't all that paralizable. Sure, you can write AIs that think for themselves only (like real life). But it might be better to share some calculations, such as path finding, or decision trees. Or for them to co-ordinate in actions, so they don't walk into each other, or act as if they are in platoons, etc.
Or what if you are writing chess, or an RTS? Now there aren't multiple individual AIs just a few big ones, and you must paralize inside their thought process.

[rfrank.nj]

I don't see a reason to, either. Say you've got 4 cores. There are a lot more entities than 4 that have AI in an average game. So all the threads will be working full-time anyway, regardless of how you section off the logic.

hahaha you don't make a thread for each unit that requires AI.  how many threads do you think you're going to have here?  you don't want to be creating threads constantly either.

try writing a thread pool to do some complex operation such as AI or pathfinding, then you'll realize how difficult multithreading is.

[Core Xii]

I meant all game logic as an example of stuff needing to modify the data. You know, changing the position based on the current velocity, destroying objects that have been hit by bullets. Adding to the score. Physical interactions between bodies. I thought it was obvious enough to not go into detail.

Changing the position based on the current velocity is a pretty damn trivial calculation. So is destroying objects. All you do is iterate over them once. The physics and collision detection are already parallel problems and handled in a previous phase. Adding to score? Are you serious?

Code:

score += points;

That wasn't so hard.

What? No. If you have discrete phases for each part of your game, and others are single-threaded and take 75% of each frame, then you are only using 4 cores for 25% of game time, and they are being underutilized the rest of the time.

The abovementioned tasks like destroying objects certainly do not take 75% of the game loop. It's collision detection, pathfinding, AI and rendering that take the most time.

Not to mention [...]

Some things are difficult to parallelize, yes. But it doesn't matter. You don't have to parallelize everything, that's not what multithreading is about. The point is to just parallelize enough to make up for the overhead, and you're already profiting.

hahaha you don't make a thread for each unit that requires AI.  how many threads do you think you're going to have here?  you don't want to be creating threads constantly either.

try writing a thread pool to do some complex operation such as AI or pathfinding, then you'll realize how difficult multithreading is.

I never said I was creating a thread per unit, That would be idiotic. I said I'm creating a job per unit, putting said jobs in a queue and letting the worker threads loose on them. Yes I'm using a thread pool, and it's easy.