Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Urgent call for EXPERT assistance

Author
Message
The Wendigo
23
Years of Service
User Offline
Joined: 13th Sep 2002
Location: A hole near the base of a tree in the US
Posted: 16th Jul 2003 06:26
I can't remember if I tried this on multiple OSs or not, but I did make a small Multiplayer game a while back based on a simple sync that worked like this:



Ship speed a dramaticly varying speed ran identitcall. Both ships flew at the same speed to the floating point as i saw from Cruise speeds down to impulse.

System specs at the time was over a 10/100 ethernet lan running at 100

Comp1:
500Mhz
64mb RAM
GeForce II Mx
Win98

Comp2:
1.0 Ghz
128mb RAM
GeForce III Ti
either Win98 or WinXP

seemed to have perfect syncronization as I said. not sure what happened to the code, but I'm pretty sure I still have it somewhere so I can maybe dig it up sometime and do some more detailed tests on it. I might have missed your point though, but I'm assuming this for multiplayer sync.

Current Projects: Game Spawn 85%, mini BSP maker 50%, Height Mapper with many features 75%, Space Tactical (Like BC300AD) 15%.
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 16th Jul 2003 12:05
yeah my personal code for this is



all that does is return the current sync between the calls of the command GetTime ... which is fantastic for getting ping times and such and if you need multiple then use this version.



heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 16th Jul 2003 17:32 Edited at: 16th Jul 2003 17:40
TheWendigo I might have missed your point though, but I'm assuming this for multiplayer sync.

I have no problem with the sync. This is the problem.

Imagine this scenario (based on the code posted at the beginning of the thread) two networked computers both running identical code. One fires a shot.
On Win98 the shot takes 2.1 seconds to impact (300Mhz - 2Ghz boxes).
On Win XP the same shot takes 2.5 seconds to impact (1Ghz-2Ghz boxes).

If XP is the host the during synchronization the traveling missile will appear to jerk back during travel on the 98 box as it gets updates as to the actual position.

If 98 is the host the during synchronization the traveling missile will appear to jerk forward during travel on the XP box as it gets updates as to the actual position (according to the host).

--------------------------------
Now that I know from many tests that XP will always run slower than 98 in all situations I can program to compensate for it.

If someone can run the 6 program test suite that I developed on identical hardware with different OSes this can be verified.

We'll need two systems one WIndows98 with a P4 2GHZ processor and another a P4 2GHz processor with WindowsXP to check this.

I would not be surprised if
Windows 98 @ 500MHz = WIndows XP @ 1.8GHz
running Dark Basic Applications using Sync.

The more you see, the more you know.
The more you know, the more you see.
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 16th Jul 2003 19:45
Quote: "If 98 is the host the during synchronization the traveling missile will appear to jerk forward during travel on the XP box as it gets updates as to the actual position (according to the host)."


What!? - It won't because the host sends a message to the XP PC telling it that a bullet has been fired, the XP PC will then automatically create the bullet object and calculate the new co-ordinates of the bullet each frame - telling the XP PC where the bullet is each frame is unnecessary and will induce serious lag.

Lady Ice
23
Years of Service
User Offline
Joined: 15th Mar 2003
Location: Canada
Posted: 16th Jul 2003 21:50
Having worked with people in the game community I can attest to seeing issues such as this the primary fix for descrepencies in speed is done 1 of 2 ways or atleast these are the two ive most commonly seen used.

1st) client server architect this way is most popular and is used by Q3A and similar games even if it is peer to peer there is still a server process this allows the server to decide if person a shot person b and it relays the apropriate signals to the clients to show the end results.

2nd) peer to peer is what they call bounce back player a shoots data transmits to player b player b varievies if the player was hit and then displays correct response while sending back a positive hit message allowing player a to see the hit this way is less relaible and less used.

You can never have a perfect situation there is always going to be lag both network and system related that is why data is buffered.

Just my two cents

Leia

Princess Leia

SYSTEM: AMD 2.7Ghz, 1GIG DDR ram, 120GB HD, ATI Radeon 9700.
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 17th Jul 2003 05:24 Edited at: 17th Jul 2003 05:32
Rob K "What!? - It won't because the host sends a message to the XP PC telling it that a bullet has been fired, the XP PC will then automatically create the bullet object and calculate the new co-ordinates of the bullet each frame - telling the XP PC where the bullet is each frame is unnecessary and will induce serious lag."

Rob check this out, in my games the shooter can control the missile after launch.

In a XP-98 P2P LAN if the shooter is on 98, then his update signals had better update the missile on the XP box correctly. Understand?

This is not theory. This technique has worked very well for me over Win 98 P2P LANs, SERIAL direct connect, and TCP/IP over 48K dialup no less.

Lady Ice in DB multiplayer is usually implemented peer to peer.

In my designs one of the peers is designated the host.

Both system are well coordinated by timers but due to network transmission problems, often the communication is lost for a few moments (usually internet).

Instead of freezing the action, I hide the enemy so you can not shoot it if there is a data flow halt. Then when the data resumes the enemy position is updated. If during the halt any missiles are flying then their trajectories continue without any further modifications until the logical conclusion which is recorded. If there is a discrepancy after reconnect, the host is the master and the issue is resolved.

The more you see, the more you know.
The more you know, the more you see.
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Jul 2003 09:23
but heartbone look at how Ian rewrote your code... the point is the latency is caused because of how your calling and trying to use the timer()

and the latency really isn't that big, only a matter of 150-200ms which is roughly what an ISDN line would call back for anyways.
Quakes way of getting around it was ticking the loops until they reached the same as the latency.

i'll have to sleep first cause i've been up since like 4am coding almost non stop plus the modeling i did a s abreak, so i'm just completely knackered... but i'll see about putting up some simple server<->client code
my firewall prevent external stuff (found that out the hardway) but i think i have enough internal machines to test it properly.

heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 17th Jul 2003 09:35
Raven give me a break. Of course I understand the change that IanM made. After all it was only a change to one freakin' variable in one line. Hardly a rewrite. I have expressed my reservations about using that approach (local timers), but I have admitted that I can not think of a better way to make the XPig keep up with the demonstrated superior processing power available to Windows 98.

The more you see, the more you know.
The more you know, the more you see.
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 17th Jul 2003 15:24 Edited at: 17th Jul 2003 15:27
Quote: "in my games the shooter can control the missile after launch. "


But they can only control the direction or speed surely? - In which case you just need to send the direction when it is changed or the speed when it is changed to the client. There is no need to keep resending the position, as from the speed and direction, the client can calculate that automatically.

This is how it works in Unreal Tournament 2003 for example (where the redeemer rocket can be controlled after launch)

Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 17th Jul 2003 20:35
unfornately that would cause a jitter effect if your not running in sync with the server Rob.
Quake3 is a bloody good example of this whn your ping hits over 300.

there are many techniques to use though... personally i just find sending the update position calculate on both the server & client whilst adjusting the interpol to the current sync tends to work quite well

you can setup the independance with it too

heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 17th Jul 2003 21:31
Why I am so perturbed about this situation? Understand, running DarkBASIC real life situations at 30 FPS the excess XP OS bagagge results in over a 25% performance decrease. Maybe insufficient RAM is the culprit, I don't know yet, but at this time on my system it is a pig.

This is why is am upset. I had carefully designed my software to run on all machines in a consistant manner. I thought that I was doing it correctly. Using my timer() techniques I made sure that no matter how fast the processor was running, my programs would run the same for all users.

I never imagined in my wildest thoughts that M$ would ever put out a regressive OS from a performance standpoint.

My code ran well on all Win9X CPU speed 266Mhz to inifinty. Now with XP a 1.8GHz with 256MB system actually runs the software measurably slower than an 366Mhz Win98 machine with 32MB. Measurably slower.

Microsoft is bad news for computing. It always has been, it always will be.

The more you see, the more you know.
The more you know, the more you see.
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 17th Jul 2003 23:13
Quote: "unfornately that would cause a jitter effect if your not running in sync with the server Rob."


Raven - Quake3 has the best network code out there, but even it will struggle with 300ms delay. I've never been on a server recently with anyone having more than 200ms delay. Besides, Heartbone is talking about doing it over a network. Sending the absolute position would cause huge jitter all over the place. If you interpolate / curve the angles, you can bring jitter to a minimum, but there has to be a balance between smooth display and accuracy.

@Heartbone

You aren't doing it correctly. I seriously suggest that you go to www.gamedev.net and read up on the multiplayer articles. You'll learn a lot.

Besides, the FPS decrease only happens with your way of doing things. If you go to the Code Archives at www.blitzbasic.com, there is a good example of getting consistant speeds which is similar to your method, but actually works.

Login to post a reply

Server time is: 2026-07-21 12:50:53
Your offset time is: 2026-07-21 12:50:53