faster way to do that

Performance Tuning
#21

I once read a quote that goes something like:

[quote]Begining programmers think programming is hard.
Average programmers think programming is easy.
Good programers know programming is hard.
[/quote]
I think I saw it in the book Code Complete but I couldn’t find it to make sure I got it right.

Anyway, the point is that as we pass though different stages of understanding of something we have different views of the subject. To a beginier, programming may well be greek, he doesn’t understand it. An average programer can make his program do what he wants and works in the situations he can think of to test it in. An expert understands the process and can see the possible problems that he himself may never experience.

I’m not a thread expert but I think there is a lot of oversimplification of threads going on in this discussion thread. If you don’t have a complete understanding of all the nuances of threads, someday they will lead to obsure problems.

EgonOlsen: To at least somewhat answer your question, the collection of input, be it from the player or the network, need to be done with threads. The thing is these “input threads” should never directly touch the state of you game. The “main game loop” asks each of these input threads via a queue if they have new input at the start of a iteration. This way everything is consistant when you render a frame or calculate a npc’s next move.

[quote]you simply can’t jump out of the recursion of the AI calculations just to render half the image and then return.
[/quote]
(the bold is my edit)
This is why AIs tend to be written so they execute iterativly. Have you ever looked at the A-Star and asked “why does it only consider the spaces around the unit? Why not just figure out to my destination and be smarter about pathing?” The reason is in a game we need these cheap little steps that won’t interupt the flow of game play as the computer does the number crunching.

Now you could use threads and wait() and notifyAll() at the right points and let many things run in parellel but it’s very easy to make mistakes.

#22

Of course not…how dumb do you think i am? I’m not asking this question because i don’t have a clue about how to use threads, i wanted a know why people here around hate them with a passion.

Exactly what i’m doing…

You mean i should rewrite the AI to build the decision tree in an iterative manner and then do what? Put an “engine.renderIfXMillisecondsHaveBeenElapsed();” every now and then? This uglyfies code and is not longer good OO IMHO. I would do it that way or similar if it would fail with threads. But it doesn’t and that’s exactly my point. I wouldn’t put every car in cknoll’s example into a single thread, but maybe i would put all cars in one and the rendering in another (albeit it isn’t really required in this case, so i may not doing it). The “car-thread” would execute the game-logic and the renderer will render the current state. I’m NOT talking that each and every AI component has to be put into threads…but that it’s very usefull for some kind of games like the applet above (somewhere…).

Edit: About the “cheap little steps”…i’m talking about a board game here, not about something like AOE…more like chess. So the requirements are totally different.

#23

Argh! What a can of worms.

Threads goes right back to O/S fundamentals. I’m being told to use threads “in case” someone’s got a multiprocessor system. They don’t, nearly no-one has a multiprocessor system. Yes, I do. No, it’s not a gaming machine any more, it’s a server. My iPaq didn’t even have O/S level threads, they were green. Etc.

And fundamentally your graphics card only has one thread context, so you’d be pretty crazy to try writing to it in different threads as the performance will be killed stone dead. As mine is under XP when it tries to do all these stupid fancy effects everywhere.

What games programmers need is not threads it’s fibers (sic). Fibers behave consistently on every system, and that’s what you need in games programming. I’m not talking about writing servers and raytracers here! This is a games programming forum! Threads are not generally useful for compute crunching; although cache coherency and such is helped along by hardware these days in the general case you’ve got only one processor and you’re much better off designing algorithms for client machines optimised for that case. Java might get all clever with a JIT but it can’t optimise the O/S and hardware for you when you write a two-thread task that tries to execute effeciently on a uniprocessor machine.

If people want to know how to write games they should know this:

Design with one Thread in mind, and use only that Thread to do all input, computation, and rendering.

And that’s genuinely the best advice you can give anyone. It’s so simple it beggars belief that people are so persistently trying to make life difficult for themselves and others, coming up with ever more fantastic and complex ways of achieving the same result, only less consistently.

Unfortunately fibers are not exposed in Java so you need to figure out a way to do time-slice sheduling. There was an excellent article on Gamasutra I think which dealt with how they achieved this on PS2. It’s not trivial but games programming has never been trivial; it’s probably the hardest discipline there is, and a hacked shortcut like threads won’t save you.

The terrain demo’s not as bad an example as you’d think, as it’s very likely that a game doing serious graphics will be graphics-bound anyway. That’s the kind of multiprocessing games programmers need to understand: how to keep a graphics processor busy whilst you’re thinking about what to feed it - and that is indeed what happens with OpenGL, for example, almost without you thinking about it.

Cas :slight_smile:

#24

Ok, i give up. I’ll continue to use the “hacked shortcut” that threads are in situations where i find it applicable while i’m waiting for your chess program that allows the user to rotate the board while the AI is processing the decision tree and all that in one thread. Have fun and happy new year…may it be multi- or single-threaded.

#25

'sfunny you should say that, because that’s exactly how XAP works, minus A*…

…and my new year looks like being multithreaded, because I’ve got to do some tedious consultancy work for The Man to pay the sodding mortgage. Trouble is, that thread never seems to pre-empt XAP and get executed…

Cas :slight_smile:

#26

After figuring out what XAP is, i can only say that

a defender clone != a chess program

I was talking about AI that may take seconds to make a move, not milliseconds…but that doesn’t matter because i’ve already given up on this topic. I just had to add this one thing… ::slight_smile:

#27

I’m as green as it gets with game programming… so I’m just lurking and enjoying the discussion regarding threads. Can’t say how they fit into games yet, I can see some valid points being said here - and I don’t think people are necessarily disagreeing, just talking about different situations.

I will say that in doing distributed Jini stuff threads are my friend:) But after classloading they’re generally one of the most misunderstood bits of programming.

Anyway, I hope anyone doesn’t think this thread has been too off topic or useless. I’ve found it very interesting.

Regards,

Bill