some suggestions

[SgtH3nry3]

delerium10101 Wrote:Everything sounds like it wouldn\'t be much. It always sounds like it wouldn\'t be much. Imagine a single object that needs a whopping 64 *bytes* per second to keep the client completely up to date. Doesn\'t sound like much, does it? Let\'s drop this into the worst case scenario. We have 128 clients connected to the server, and this object must update on all of them. We just hit 8 kilobytes per second to handle that. For that one measly object. But oh you say, that isn\'t much, cable can still handle that. Righto, continuing with this example (I actually coded this object, but pulled networking support for this reason, makes life fun, but it still works) we have not one, but three hundred of these updating at once. Minimal estimate really. Now, we have a problem. 2.3 MB per second, just for that object type. Out of the question.

It takes far more than 64 bytes/sec to transmit the correct position of an object over the network. It actually takes 896 bytes/sec, per client. Networked ragdoll is out of the question. Networked rigid body is bad enough, and this is exactly why. But yes, it is absolutely necessary that rigid body calculations be sent over the network. It\'s amazing just how quickly client and server can start to disagree.

Too true, but exact location isn\'t that important.
Look at H&D2 for instance, the corpses lay on the same spot, but they always lay different on every other computer.

That isn\'t the point, the point is a dead body should lay at exactly the same position in spite of the way the corpse sit/stand/napping in the dirt or even hanging upside down.

Btw. 32 active bodies would make 64kb data.

delerium10101 Wrote:Moving on, vehicles: Yes, there is a suspension and inertial system going on here. It sucks, but it works, and doesn\'t kill network performance (as much as previous examples). There\'s even a traction system which lets you pull slides under certain conditions.

Sound cool

delerium10101 Wrote:Rigid body physics: Torque has its own rigid body solver. Again, it sucks, but it works, and doesn\'t kill network performance as much as ODE does. ODE has been successfully integrated into Torque, so long as its a single player game. There have been no playable networked ODE tests with Torque. Once you hit over ten moving objects, even if there\'s just one client, heavy lag kicks in and the whole thing goes to hell.

As a side note, if we do go with a 3rd party physics engine, it would be Novodex. Just wanted to make that clear.

Makes a very strong point.

delerium10101 Wrote:1.) Searching bodies: I don\'t see any reason why not. Certainly a better way to get ammo than running into the spinny shiny clip with sparkles flying around it. It\'s not like TTR was kid friendly to begin with anyways.

2.) Lens flare: No. Just no. End of story.

3.) Blood splat in face: Again no, as stated before. It\'s just worth reiterating.

4.) HDR: Well, ya. I just hope you have a card that can handle it. If not, we do have fallbacks that work pretty well, even on my lowly Rage 128 (Note: My computer(s) will not be supported by TTR, so my saying something works on my computer should not be taken as an indication that I meet minimum system requirements).

5.) Interaction with stuff: Um, ya. Sure, if you absolutely insist.

1.) Cool :tup:

2.) Thank God, I hate lens flare in games. Games shouldn\'t be cinematic.
Games are games, realistic games are realistic game, arcade games are arcade games.
A mix of them... well it TTR .

3.) God bless you I hate blood splats in your screens, too cinematic.

4.) atm. I have this 5200 Ultra but next year I\'ll have a X1800XT(PE) 512MB, maybe two of them!! :eek:

5.) W00h00!!!

delerium10101 Wrote:Keep the questions coming! Ideas from the community fuel development, unless we\'re in a bad mood and just say you\'re wrong.

Sure, I\'ll always have some suggestions for ya

Yours truly,
Henry.