fps expected for platform game

[swpalmer]

It is useless to draw frames more often then your monitor can refresh.  That means that FPS greater than your refresh rate are generally useless... the one exception is when you end up with a better physics simulation if you can go through more iterations of your game loop.  E.g. colliding objects don't penetrate as far, step size decreases which makes a difference for some algorithms...
Even then, you should not actually update the screen faster than the monitor refresh... since physically you can't it is a wasted operation.

[MGodehardt]

It is useless to draw frames more often then your monitor can refresh.  That means that FPS greater than your refresh rate are generally useless... the one exception is when you end up with a better physics simulation if you can go through more iterations of your game loop.  E.g. colliding objects don't penetrate as far, step size decreases which makes a difference for some algorithms...
Even then, you should not actually update the screen faster than the monitor refresh... since physically you can't it is a wasted operation.

hmm seems a lot of guys are new in the game business, ok ill explain what i mean.

U cant get a FPS greater than monitor refresh ( impossible in fullscreen ), maybe windowed mode needs a little tweak, but i speak about realtime games. ( for e.g. UO is a good example )

I am drawing 100 terrain tiles, around 500 additional images and all this rendering is done in about 5ms, now the VSync kicks in and waits for you.

Demos like 2ndReality have a render / game physics loop which has NO SLEEP AND NO SECONDARY THREADS ITS DONE IN ONE THREAD.

[whereisthemoney]

Hey mister,

were you replying to my post? Because i'm only using one thread. Plus do you even know what my code does?
btw if you ain't givin' personal details you can't claim you're anything OK? By your (ab)use of caps it seems like you're a 14 year old kid.

[size=4]DO NOT USE MULTIPLE THREADS IN GAMES[/size]

i agree to princec, ever thought about synch all variables between render and physics thread ? if u DO NOT SYNC EM your game will go berserk.

[size=4]DO NOT CUT FPS[/size]

why do u wanna cut off the fps rate ? let it flow, u want FPS based movement ? hmmm think about it.

do avatar movement based on time ( for e.g. you scroll screen by 1 ( or whatever you want ) every 50ms, its really easy to achieve this in ONE THREAD.

I wrote alot of stuff n games under DirectX and WE DO NOT CUT OFF FPS grrrrrrrr

DO NOT DRIVE ME CRAZY

Games published by our own members! Check 'em out!

[swpalmer]

U cant get a FPS greater than monitor refresh ( impossible in fullscreen ), maybe windowed mode needs a little tweak, but i speak about realtime games.

That's what I said.

...now the VSync kicks in and waits for you.

Good.. so you ARE limiting the frame rate with VSync & therefore throttling back the FPS to what makes sense for display.  You seem to be agreeing with everything I wrote, so I'm missing the point of your post.

Demos like 2ndReality have a render / game physics loop which has NO SLEEP AND NO SECONDARY THREADS ITS DONE IN ONE THREAD.

Waiting for VSync can be the same as a sleep().  Assuming that the vertical interrupt woke up your thread.  If you were busy-waiting, you could at least call Thread.yield() to be system friendly.

I must say that I see no problem with multiple threads in games.  As long as they are used properly.  And of course the style of game could easily mean that multiple threads will have little effect even when they aren't used optimally.. anything that isn't action-based for instance.  It most definitely not "wrong" to use threads in a strategy game - so the computer is thinking always in a background thread.

Of course this msg thread is talking about a platform game that is action based... but it is still possible to get away with using multiple threads.. and achieve good FPS.  In fact I would guess that even if you tried to be single threaded, the Java runtime will be using some other threads behind the scenes.  Run your game in a debugger to see how many threads are alive.  Sure, they won't all be active most of the time.. but that is fine.  There are things that make sense for action games to have background threads.. e.g. loading resources... where the background thread is only active for a small instance to initiate an IO operation to load level data for an adjacent sector or some such thing.  I think  there are multi-threading techniques that will work for action games.  You just have to know what you (and often the VM) are doing.
My background is programming realtime digital video and audio effects hardware for TV/film.  In that situation it is not acceptable to have effects, audio or video ever slip out of sync or skip a frame.. and yet I used > 20 threads... it works.  It all depends on the particular situation you have to deal with.

[MGodehardt]

Right it depends on the game u are writing.

But it tested multiple threads for my app and i had to sync variables ( otherwise bad things happen, this was also discussed earlier in this thread ) and the resulting FPS was 30% lower compared with my single thread app now.

I am doing a MMORPG with approx. 5000 online users ( living on multiple servers ), for my app i go with a single thread and i am fine. I am not forcing anyone to use no secondary thread.

But i see so many posts like "why is my app lagging' 'why does my app freeze for 1ms' 'how do i get smooth rendering' and so on.

For best results in RT apps like MMORPG ( massive is not 100 users ) use one thread for rendering and game mechanics.

[blahblahblahh]

I am doing a MMORPG with approx. 5000 online users ( living on multiple servers ), for my app i go with a single thread and i am fine.

Which one?

Incidentally, we use many many threads for our MMOG engine. To support 5000 users we'd probably have a total of 25-50, maybe 3 or 4 times that many. (but then again we'd probably have that spread out over several servers in the cluster )

Server design != single-player console-game development. In servers, threads are usually a very good thing. For instance, they let you easily tune and prioritise different parts of a pipeline in a context-dependent fashion (i.e. create dynamic - as opposed to static - prioritisation schemes).

IMHO it would be bending over backwards to run any serious MMOG on one thread (by "serious" I exclude e.g. single-player or small multiplayer games like chess where there are thousands of simultaneous games being served by a single server), and with no real benefit that I can see (overall). It's extremely difficult to maintain - and you HAVE to do synchronization anyway! Since you say you've got more than a single server, you absolutely must be handling synch issues betwixt servers...and even if you've only got one server, you'd have to work pretty hard to make sure there were no race-conditions between the clients and their interaction with the server (it can certainly be done, but why would you bother?).

AFAICS, Cas's argument for single-threading is that an exclusive single-player game can be statically scheduled with no loss of functionality, and at the benefit of making runtime characteristics entirely deterministic (although you do have to do some extra work if you want to *guarantee* determinism - you have to de-bounce your inputs etc, although this much determinism is rarely needed unless you need to do game recording and playback AFAIAA).

An MMOG is inherently non-deterministic from the outset, and you ALSO cannot afford to statically schedule - unless you happen to be a God (like me ). And even I wouldn't try to do that, even with a very very big paycheque - it could be years and years of pointless pain.

So...I'm intrigued as to why you are using a single thread (well, according to your own quote, you aren't - but lets assume you said "one thread per server") for an MMOG?

[princec]

Don't forget one of the main reasons to use a single thread is that graphics cards and drivers can only have one active hardware context and one threadside view of the graphics card state too folks.

Graphics context switch = total performance killer.

Cas

[blahblahblahh]

Don't forget one of the main reasons to use a single thread is that graphics cards and drivers can only have one active hardware context

<FX:...imagines a beautiful new world where Cas reveals all in an article, and puts it all into context, so nobody gets confused (and the world doesn't quickly char and blacken in a War of Flame). With a checklist at the end - because all games are different, and you can easily forget some of the reasons from project to project >

Or, to put it another way, "I'd never thought of that. Thanks! (I wonder how many others like that I'd not thought of either?)".

[Markus_Persson]

The wurm server right now only uses one thread per machine.


I'm guessing it will use three or four threads when it's done.

Thread 1: Loops over all NIO connections and reads and processes all (or some, if the client is spamming) waiting commands, and performs all game logics. (this will ensure that no client commands come in while an action is being evaluated)

Thread 2: AI planning. All actual actions are added to a queue for thread 1 to perform between reading all client commands, but this thread can do things like pathfinding and the more fuzzy term "planning".

Thread 3: Communicating with the other servers in the cluster. Again, all actual game actions are queued up for thread 1.

(possibly) thread 4: Database and file system interactions. Since these can be quite blocking, it would be nice to queue them up on this worker thread.


This is getting slightly off topic, but I'm fairly convinced there's very little benefit of using more threads than that, especially since we're using non-blocking io.

[blahblahblahh]

The wurm server right now only uses one thread per machine.

I'm guessing it will use three or four threads when it's done.
...
This is getting slightly off topic, but I'm fairly convinced there's very little benefit of using more threads than that, especially since we're using non-blocking io.

You're right it's off-topic, my fault - sorry . There is plenty of benefit of using more threads, although I'm not going to go into it here. SEDA is a very good example of what you can do with a lot more threads (nb: this is just one of several alternatives; we happen to be using a staged architecture too, which is a large part of the reason for our large number of threads. There are also other good arch's that mandate many threads.)

http://www.eecs.harvard.edu/~mdw/proj/seda/

(which is one of the links on this page:)

http://www.grexengine.com/sections/people/adam/gpg4/

(..and you may find some of the others particularly interesting/useful too)

PS I'm not saying you *mustn't* use only one thread in server dev, just that there's usually no benefit in deliberately forcing yourself to. If you don't need more than one, fine. But in single-player games, there is huge benefit to sticking to one thread even when you're tempted by the possibility of using an extra one or two here and there.

Games published by our own members! Check 'em out!

[MGodehardt]

We use Sun Servers Enterprise 450 and higher with multiple processors. (  on these servers currently 2000 to 5000 people are connected )

all servers are written in c++ and have a lot of threads.

only the client will have one single thread ( maybe one for the network but at the moment networking is not the problem ).

I will show and give hints when time is ready.

[Markus_Persson]

*shrug*

I don't really see the point of running multiple threads over the same nonblocking methods.

[blahblahblahh]

*shrug*

I don't really see the point of running multiple threads over the same nonblocking methods.

If that's in reply to my last post...did you read about SEDA? It should be fairly obvious what's going on.

[blahblahblahh]

We use Sun Servers Enterprise 450 and higher with multiple processors. (  on these servers currently 2000 to 5000 people are connected )

all servers are written in c++ and have a lot of threads.

only the client will have one single thread ( maybe one for the network but at the moment networking is not the problem ).

I will show and give hints when time is ready.

OK, I misunderstood you. The way you said:

"I am doing a MMORPG with approx. 5000 online users ( living on multiple servers ), for my app i go with a single thread and i am fine. I am not forcing anyone to use no secondary thread."

I assumed you meant that the MMOG parts of your game (which are the only bits which have 5000 users to cope with) were single-threaded.

I will show and give hints when time is ready.

You've no website / fansite / etc?

[Markus_Persson]

I'm not saying I'm right.

I just don't see The Point right now, and as usual, I assume that means the way I'm doing stuff now is Good Enough(tm).
It usually ends with me realizing how wrong I was, and how complicated the topic really was, though, so I've started to humble a bit.

[blahblahblahh]

I'm not saying I'm right.

I just don't see The Point right now, and as usual, I assume that means the way I'm doing stuff now is Good Enough(tm).
It usually ends with me realizing how wrong I was, and how complicated the topic really was, though, so I've started to humble a bit.

...and I'm not saying you're wrong (to not use multiple threads). But there are very obvious huge advantages to it. If there's some aspect of SEDA you don't understand, I found the resources pretty easy to follow, so I can try and explain...?

[Markus_Persson]

and I'm not saying you're wrong

Yeah, I know.


And I'd really appreciate a brief overview of the idea of SEDA, but perhaps in a new thread?