Performance boost and multithreading

[TheoLogic]

LeadWerks has a great C implementation, you can get good looking results in a mum of time, but performance isn't what it should be.

 

What I would like to see:

- Support for lower specs

- Multithreading (MUST)

 

The problem is: having a good looking scene with gameplay at decent framerates is hard to get at this moment.

[Canardia]

Multithreading can be cores times faster, or cores times slower, depending on what you do. Usually it's faster when doing some non-memory intensive things on other cores, and slower when accessing memory on other cores.

 

A quaranteed benefit of multithreading would be to put disk I/O related stuff to another core, then it doesn't matter if they are a bit slower, since they don't block the main core anymore.

[L B]

Multithreading + OpenGL cannot theoretically be done. Although HDD I/O could be multitheaded, but it wouldn't boost much performance.

[Marleys Ghost]

LeadWerks has a great C implementation, you can get good looking results in a mum of time, but performance isn't what it should be.

 

What I would like to see:

- Support for lower specs

- Multithreading (MUST)

 

The problem is: having a good looking scene with gameplay at decent framerates is hard to get at this moment.

 

 

 

 

why lower specs? and as far as I am aware (and could be wrong) OGL isn't taylored for multi threading. So I am not sure how these two suggections would increase framerates?

[TylerH]

The physics, scene graph, etc. can be multi-threaded.

 

Why does everyone always just try to negate the request for multi-threading? Instead of thinking of places where it CAN be used...

[L B]

Because the physics and scene graph have a minor load on the CPU/GPU, therefore I think people (Josh) doesn't like the work for gain ratio.

[Josh]

There are still a few things I can do to improve performance with points lights especially. Multithreading won't actually make that much of a difference, because most of the bottlenecks occur on the GPU.

[TheoLogic]

Try using 20 character controllers doing their thing...

And a lot can be done with multi threading, I support TylerH's vision on this.

 

What would be really great is leadwerks adapting his specs for lower end computers...

[L B]

Try using 20 character controllers doing their thing...

And a lot can be done with multi threading, I support TylerH's vision on this.

 

What would be really great is leadwerks adapting his specs for lower end computers...

 

For the character controllers, I agree.

Although lower specifications support is quite impossible, since some of the basic shaders, i.e. query, require Shader Model 4.0 (unless I'm mistaken, that's what I recall from the previous forum).

[macklebee]

shader model 3.0 System Requirements

[Marcus]

I also have worries about the character controllers. I am hoping to at least support 32 players in fps game. Is it the character controller that is causing the primary issues? Would it be beneficial to have some sort of "light" controller that would be less weight over the network? I'm assuming the root of the problem is the way Newton reacts with the player controller.

[Marleys Ghost]

 

 

What would be really great is leadwerks adapting his specs for lower end computers...

 

 

 

What is the lowest spec you suggest and why?

[cocopino]

As long as the recommended card remains a 8800, I see no problems there. This has been a recommended card for over two years now for many games. FPS can never be too high though, so any improvement there using multithreading is welcome.

 

I also have worries about the character controllers. I am hoping to at least support 32 players in fps game. Is it the character controller that is causing the primary issues? Would it be beneficial to have some sort of "light" controller that would be less weight over the network? I'm assuming the root of the problem is the way Newton reacts with the player controller.

If you're talking about a multiplayer game, you won't have 32 players on the same computer so you won't need 32 controllers. You'll probably need each player to send his coordinates/rotation to a server, and the server on each update will return the coordinates/rotation of the 31 other players.

[Marcus]

If you're talking about a multiplayer game, you won't have 32 players on the same computer so you won't need 32 controllers. You'll probably need each player to send his coordinates/rotation to a server, and the server on each update will return the coordinates/rotation of the 31 other players.

 

I think you actually have the concept of a multiplayer gaming wrong. The players input gets sent to server which hosts ALL decision making, including all player controllers. The server updates/calculates the position of all controllers and then sends those positions to the client. Generally the client does nothing more than gather input, render the scene, play music, and transmit to and receive data from the server.

 

If you allow the clients to send the positional data to the server, you will have massive amounts of cheating. All decision making and validation has to take place on ther server.

[Canardia]

I think you both got multiplayer gaming wrong The player sends a force vector to the server, which then does the same on his own game, and sends the force vector to all other clients also. So if nobody moves for 5 minutes, no data is sent (as opposed as in bad network code, where the positions are sent in regular intervals, regardless if they have moved, or if they are moving with the same speed). Multiplayer gaming must also work offline, and support bad network lag. This is done by sending data less often, or not at all when its not needed or possible, however the gameplay of the players should not be affected for other things except the multiplayer aspect then.

[L B]

I think you both got multiplayer gaming wrong The player sends a force vector to the server, which then does the same on his own game, and sends the force vector to all other clients also. So if nobody moves for 5 minutes, no data is sent (as opposed as in bad network code, where the positions are sent in regular intervals, regardless if they have moved). Multiplayer gaming must also work offline, and support bad network lag. This is done by sending data less often, or not at all when its not needed or possible, however the gameplay of the players should not be affected for other things except the multiplayer aspect then.

 

Good call. Let's hope curving doesn't mess this up too much. Will start networking sometime this month for my game.

[cocopino]

If you allow the clients to send the positional data to the server, you will have massive amounts of cheating. All decision making and validation has to take place on ther server.

The server always should have the final word, eg: People who travel too fast or make impossible shots should be banned. When using 32 controllers you will inevitably encounter differences between players, and then what?

 

Multiplayer gaming must also work offline, and support bad network lag. This is done by sending data less often, or not at all when its not needed or possible, however the gameplay of the players should not be affected for other things except the multiplayer aspect then.

Multiplayer gaming must indeed support lag. But I never said/meant to say that a static player should be sending data to the server. Vectors can indeed be sent, many other things as well. However, I disagree the server should send data less often. IMO, the server should send MORE often because you'll be using the UDP protocol and don't know whether players received the data package.

[L B]

The server always should have the final word, eg: People who travel too fast or make impossible shots should be banned. When using 32 controllers you will inevitably encounter differences between players, and then what?

 

 

Multiplayer gaming must indeed support lag. But I never said/meant to say that a static player should be sending data to the server. Vectors can indeed be sent, many other things as well. However, I disagree the server should send data less often. IMO, the server should send MORE often because you'll be using the UDP protocol and don't know whether players received the data package.

 

So basically you're saying: "Send the data a couple of times, just in case it doesn't get there."

[Marcus]

So basically you're saying: "Send the data a couple of times, just in case it doesn't get there."

 

I think he is more hinting at connection and connectionless protocols. It is important to remember that UDP is connectionless and makes no guarantee of packet arrival or their arrival order.

[Niosop]

Not in the protocol itself, but there's plenty of libraries that use UDP and implement their own layer on top that adds acknowledgement, packet ordering and guaranteed delivery.

[macklebee]

Not in the protocol itself, but there's plenty of libraries that use UDP and implement their own layer on top that adds acknowledgement, packet ordering and guaranteed delivery.

 

like Netwerks...

 

Networking in Leadwerks Engine is based on the enet library. The fast UDP protocol is used as a base, but packets are correctly ordered or sent with a "reliable" flag for important data. Although the UDP protocol is "connectionless", the Leadwerks networking library automatically initializes and maintains network "connections"

[Marcus]

Not in the protocol itself, but there's plenty of libraries that use UDP and implement their own layer on top that adds acknowledgement, packet ordering and guaranteed delivery.

 

I wonder if it wouldn't be just be efficient at that point to just use standard UDP. I should look at RakNet to see what they are doing.

[TheoLogic]

shader model 3.0 System Requirements

 

To write a good looking playable game you need the Recommended Requirements, and hope they do the trick...

 

To explain myself a bit better: On lower specs I want my game to look like source (old version, be4 L4D) mods, with same framerates. How higher the specs, how better I want the game to look without loosing some framerate.

This is used in professional engines like GameBryo, ...

 

At this moment on mu NVidia 7950 GTX, and intel centrino duo the editor is slow as hell, taking 1 minute to change scene (even if I lower render options), so how do you want me to write some game code without that be speeded up? If I update 20 charactercontrollers (AI) I get 1 FPS, or 2 on a good day...

Not talking about deployment! You can't deploy this to lower end specs, different systems have different artefacts, ...

So for me it's quite simpel: fix bugs and optimize.

[cocopino]

Couldn't this be a driver problem, that NVidia isn't updating your card any more?

Your card should be better than my NVidia 9600M GT, but that runs the Editor just fine...

[Canardia]

GeForce 7 drivers are still actively updated:

GeForce/ION Driver Release 195

Version: 195.62 WHQL

Release Date: 2009.11.26

Operating System: Windows XP

Language: English (U.S.)

File Size: 88.5 MB

However, Win7 makes OpenGL run around 20% slower than XP, so if you have a slow graphics card, you should use Windows XP.

I have a GeForce 5 card (570M) on my laptop, and LE runs just fine with it. But I think GeForce 5 was kinda like GeForce 8800 - a high end card of its time. 3-4 year old high end cards still beat new low end cards of today