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
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 04:08
Link
Uh-oh. I just discovered something else really really bad about Windows XP. Although possible, I doubt if this is a DarkBASIC issue.

It seems that Microsoft has changed something very fundamental.

Please run this short program and analyze it. What can be going on to cause this?

In DarkBASIC it's easy to keep a Cyrix 366Mhz Win98 and a Athlon 1.2 GHz Win 98SE system synchronized in multiplayer.

It is impossible to keep a Athlon 1.2 GHz Win 98SE tightly synchronized with a 1.8 GHz Celeron Windows XP.

I noticed that SLOT RACERS operated more slowly on a faster XP.
That code does not check the OS in any way, yet it runs slower on XP.
The code is designed to run at a constant rate no matter where it is executed.

Next I ran my LAN enabled COMMBAT between the 1.2G 98 and 1.8GHz XP systems. Synchronization problems were apparent. The XP always lags.
The program runs extremely well when using the aformentioned 366Mhz and 1200MHz Win98 systems linked over LAN or SERIAL connection.

Next I wrote the code below to verify what I have been seeing.

Experts one and all
(IanM, Drake, Mr. Bitmap, Rob K, Dark Glory, TDK-Man, cyberluke, Rob K and even Mr. Bamber)
Please examine this code and help me to understand what is happening. Please.

Right now it seems that any Win9X to WinXP real time multiplayer is a crap shoot at best, even over a high speed LAN. If my analysis is correct then for high speed multiplayer we'll need to run all XPs or all 9X systems to stay in sync.

Compile the atached source code on either DarkBASIC Professional or Classic it does not matter.

Win98 takes 2.176 seconds
WinXP takes about 2.564 seconds

The exact same code! What the heck is going on?

Do I have to check for XP and put a fart factor in the calculations?

Thanks in advance.
The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Dr DooMer
23
Years of Service
User Offline
Joined: 22nd Dec 2002
Location: United Kingdom
Posted: 14th Jul 2003 04:16
Link
I don't think it's just XP - I 'upgraded' from Win98SE to Win2000 which, although more stable (so far), managed to cut both DB and DBPro's framerates by about 1/3.

I can't shed a lot more insight into it, I'm afraid. However, I've heard rumors that DBPro will eventually be making use of DirectX 9. If the rumors turn out true, perhaps the speed problems, both local and networked, will be aleviated. Even then, don't hold your breath...

---------

See more at http://www.cross-bones.co.uk/emalice
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 04:27 Edited at: 14th Jul 2003 04:32
Link
I don't think that framerates have anything to do with this situation.

In the supplied code example the updates are programmed to occur every 33 ms.

Even a 200 MHz Pentium has enough horsepower to run this simple one small sprite test at 30 FPS.

This is something so fundamentally strange and problematic that probably a true Windows expert has to analyze this to explain the behaviour. I have tested this code on a 366 Cyrix Windows 98 OE w/32 MB RAM and a 32MB TNT2. The binary runs faster on that 366 MHz system than a 1.8 Ghz Celeron Windows XP w/256 MB RAM and a ATI Mobility Radeon?

It is not a hardware issue. It seems to be an OS issue.
Something is seriously wrong somewhere and I have no clue what.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Codger
23
Years of Service
User Offline
Joined: 23rd Nov 2002
Location:
Posted: 14th Jul 2003 04:45
Link
I added a "print screen fps" and got 29 fps isnt that what you are telling the program to runt at?

Windows XP PIII 650 Nvid Gforce 4

Back to top
Profile PM Email
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 14th Jul 2003 04:59
Link
I'll take a look at the code in a sec, but the first possibility is the accuracy of Timer(), which calls the WinAPI command GetTickCount() I believe. Perhaps it might be worth using IanM's Hi-resolution timer instead. The only OS difference is that there is different handling of processes and allocating of CPU time, I'm not sure that would make much difference though.

The machines you tested it on are running completely different hardware though, so no way can you put it down to the OS.

Also, the code here reports a slightly different time when first run, but it is consistant after that.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 05:24 Edited at: 14th Jul 2003 05:32
Link
I too thought the Timer() function was operating differently.
I have eliminated that possibility early in my testing.

The results settling down is probably due to data caching.

I expect the timer to register 65x33= 2145 ms.
Adding a few milliseconds of time to process the final output and the Windows98 result of 2176 is what you should expect from the test. The 2564 result indicates that XP has issues.

Rob K because I get the identical correct test results with both older and newer hardware setups that are running Win98,
and I get bad results with newer hardware running WinXP
I think that the behaviour IS a function of OS.

Is it just my XP SP1 install that has this issue, or is it XP in general?

With my setups it sure seems like
(WinXP FPS)*1.152 = (Win9X FPS)

Codger the programs 33 ms update rate is approximately 29-30 FPS.

However XP appears to operate at a 15% performance penalty which translates to an effective 5 FPS decrease at 30 FPS.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
LuciferX
23
Years of Service
User Offline
Joined: 16th May 2003
Location: United States
Posted: 14th Jul 2003 07:06
Link
this is a strange issue if you are using the timer()

i certainly hope this does not turn out to be a bug

Do or do not, there is no try. -Yoda
Back to top
Profile PM Email Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 14th Jul 2003 17:45
Link
Timer just calls a windows API function, which would back up Heartbone's view that it is an OS issue. Like I said, try using IanM's Hi-Timer.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 18:38 Edited at: 14th Jul 2003 18:55
Link
OK Rob K I'll obtain and use the high resolution timer to make sure.

WHERE CAN I GET IT?

Can I assume that you have verified my test results on your system and it is not just a glitch on my single XP system?

Eliminating the interface code from the example snippet, the executed loop is quite simple:


HPOS= 0
START= Timer()
TDISP= START+ 33
Do
If Timer() > TDISP
Cls 0
TDISP= Timer()+ 33
HPOS= HPOS+ 10
Sprite 1,HPOS,260,1
If HPOS > 639
TTIME#= (Timer()- START)/1000.0
<snip>
End
Endif
Sync
Endif
Loop


Why in the world does this code run so much slower on my XP? (Moving that Cls 0 down one line after the delay timer variable assignment has no effect.)

Depending on how you look at it
on my computers the above code runs 17% faster on Win 98SE than WinXP,
or WinXP is 15% slower than Win98.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 19:20 Edited at: 14th Jul 2003 19:27
Link
OK folks this is a version with no sprites or clear screens.
Just a small looping timer program.
I can not believe that I am the first to detect this XP problem!

I know there are a few REAL Windows experts out there.
Help me understand.

DBP + WinXP = 2.564 sec bogus result
DBC + WinXP = 2.563 sec bogus result

DBP + Win98 = 2.176 sec correct result
DBC + Win98 = 2.188 sec correct result

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Jul 2003 19:29
Link
2.373 - WinXP Laptop
2.811 - WinMe Laptop
1.202 - WinXP Current Machine
0.760 - Win.Net Current Machine

i think it probably has more to do with your graphics cards, than anything else ... reason i say this is because if i put in my GeForce2 into my GeForce4 machine and ran the code it got
2.400 - WinXP
but my GeForce4 for 1.832 - WinXP

and i think .Net is alot faster cause i'm running it in 64bit mode

Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 19:35 Edited at: 14th Jul 2003 19:38
Link
Thanks raven I knew there was an expert or two out here.
Based on the last example which only does a Sync in the loop,
can we assume that the Sync command causes different looping behaviour based on the graphics cards even though there are no graphics commands issued?

If it is a function of graphics cards why does my E-Machine a
Cyrix 366MHz
Win98 OE w/32MB ram
TNT2 w/32MB
performs the test at the correct speed?

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 14th Jul 2003 19:48
Link
decided to tinker with it... the speed seems to have bugger all to do with the sync



its quite perculiar

Back to top
Profile PM Email Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 14th Jul 2003 19:50
Link
@heartbone

I never use the method you described to get constant speed, I always use a SCREEN FPS() based method. And that runs at the same speed on all PCs.

You can find the Hi-Timer plugin here:

http://www.realgametools.net/forums/index.php?board=28;action=display;threadid=13094


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 19:55 Edited at: 14th Jul 2003 20:05
Link
I even took the Sync command out of the main loop for the small test code.

DBC does not like it if you do this.
DBProfessional has no problem, the results:

XP = 2.564
98 = 2.176

So it's not the sync command in the loop.

Rob K my code actually runs based on the FPS but I limit it to 30. Guesss what 30FPS On Win98 = 36FPS on WinXP! (Or is it 30 on XP = 25 on 98?) With the exact same framerates, programs DO NOT operate at the same speed on different OSes! Multiplayer programmers beware. Rob K I actually detected this with a working multiplayer game that is FPS based.

I will begin my investigation using the plugin. I'll get back to you with the results.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 20:16
Link
Rob K the plugin is more than I expected. It'll be a while.

IanM's plugin looks great. Especially the peek and poke stuff.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 14th Jul 2003 20:42
Link
Rather than trying to get the same FPS on all PCs, aim for the same overall movement speed. That way a faster comp will have smoother movement, but the overall speed will be the same as on a slower comp.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
MushroomHead
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 14th Jul 2003 20:43 Edited at: 14th Jul 2003 20:45
Link
You will need to use a precision timer routine ... I think it's QueryPerformanceCounter or something. Windows GetTickCount is not very accurate but the high precision counter gives much accurate results. DBP's timer() routine is similar to the VB one.

Be warned though, not all machines support high precision timers from what I hear, any PC from 386 upwards is ok.
Back to top
Profile PM
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Jul 2003 20:53
Link
It's actually nothing to do with the OS.

Try this code instead - only 1 change here. Can you spot it?

Back to top
Profile PM Email Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 14th Jul 2003 21:12
Link
The TDISP=TDISP+33 line.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Jul 2003 21:25
Link
Yep

The thing being forgotten is that windows can pass control of the CPU to another process *at any time*. DBPro doesn't have any special privileges as far as windows is concerned.

Unless you take account of this (like the above changed line automatically does) your timing is always going to end up screwed
Back to top
Profile PM Email Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 14th Jul 2003 21:43
Link
I assumed that DBP had a higher process priority than normal but checking just now it appears not. Thanks Ian.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 23:14
Link
IanM I understand your "fix", it is wrong.

After you examine the code attached in the next message you'll understand why. To summarize though, if you bump TDISP by 33 in this case it seems to work. But in reality at the beginning of the loop, Timer() is not TDISP+1 as you would expect, but sometines up to TDISP+6! So setting TDISP to TDISP+33 is incorrect as the next display update will happen too soon!

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 14th Jul 2003 23:15 Edited at: 14th Jul 2003 23:17
Link
There is some weird interplay between DBPro compiler's Display settings and the OS and the Sync command.

All tests were run from a 1024x768 16-bit desktop,
All tests were run with this code.
The tic (`) comment was removed from the Sync command for the Sync tests.



WinXP Results (1.8 GHz Celeron):
------------------------------
Pro + WFS + No Sync 1.001
DBC + --- + No Sync 1.041
Pro + WFS + Sync 1.402
Pro + FSE + No Sync 1.943
DBC + --- + Sync 3.125
Pro + FSE + Sync 3.304

Win98 Results (1.2GHz Athlon operating at 900Mhz):
--------------------------------------------------
DBC + --- + No Sync 1.173
Pro + FSE + No Sync 1.175
Pro + FSE + Sync 2.337
DBC + --- + Sync 2.475
Pro + WFS + No Sync 8.754
Pro + WFS + Sync 19.375

Pro = DarkBASIC Professional executable
DBC = DarkBASIC Classic executable
WFS = Compiled in the Windowed Full Screen mode (compiler IDE default)
FSE = Compiled in the Full Screen Exclusive Mode @ 640x480

-------------------------------------------------------------------------------------

These results support what I originally detected using DBPro in FSE mode.

Bottom line is that I am starting to think that somewhere in my program's setup I must run a test like the code above and then based on the results, adjust variables to synchronize the code if running on a different OS than the one it was developed on.

Also doesn't it appear that it is a good idea to stay away from the Windowed Full Screen mode if the code is to run on Windows 98/ME?

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Jul 2003 23:47
Link
My 'fix' is right! Your expectations (of both windows and DBPro) are wrong.

As I said, DBPro does not own the system. Windows can bump control at any time to any other program in the system.

If that happens during one loop, that loop can take more than the 33ms you've alloted to it. To make that up, the next loop is alloted less.

Using the number you've suggested (+6), the second loop will only be allowed 27ms to complete. If it takes slightly more (say 2ms more for a total of 29ms) then next loop will still be penalised, but by a reduced amount (4ms). This state of affairs will continue until your loop catches up.

Have you tried the changed code? Every run, and I do mean *every* run takes precisely the same amount of time (2.113 seconds) to complete on my laptop, no matter what screen size or display mode I run it in. Wasn't that what you wanted?
Back to top
Profile PM Email Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Jul 2003 23:51
Link
Something I didn't make crystal clear:

I said windows can bump control to another program at any time - Well, this can happen between the time you test the timer and the time you get the new timer value.

This could be the reason that you are getting such varying results.
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 01:05 Edited at: 15th Jul 2003 01:52
Link
Have you tried the changed code? Every run, and I do mean *every* run takes precisely the same amount of time (2.113 seconds) to complete on my laptop, no matter what screen size or display mode I run it in. Wasn't that what you wanted?

Yes I do completely understand your change. Do you understand that such a simple loop should operate in a consistant manner independant of things like OS. Why should the exact same binary code execute in 3.3 seconds on faster Win XP systems and only 2.5 seconds on slower Win 98 systems?

I have made more test results. I swapped the video card in my desktop unit. I am surprised at the different results. This is another factor to consider. Apparently DBP is only to be used with certain video cards.

Even with up to date drivers it seems the SiS video system can't hack the Windowed Full screen mode! We are not talking lots of fancy graphics commmands here. Just a Sync and a Timer() call!

Note in these test results that the Windows XP in 256MB @ 1.8Ghz w/ATI Radeon and the Windows98OE in 32MB @ 0.366Ghz w/TNT2 perform the test about the same. Which is what I would expect since the code should not be doing anything fancy but waiting for the timer to expire.

You have the code and the results. Any other experts?

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 15th Jul 2003 01:18 Edited at: 15th Jul 2003 01:19
Link
@Heartbone

You should not rely on this method, it isn't a bug, it affects ALL programs and game engines (including those for HL / GTA, you name it). Instead you should use a SCREEN FPS() based method for consistant speed. Rather than updating the game only every so often, do less movement on faster PCs and more on slower ones, so that the overall speed is the same. What you are doing is similar to the SYNC RATE command, and we all know how innaccurate that is!

Why is XP slower? - The answer lies in the fact that the kernels of the two are radically different. The way that CPU time is allocated differ in both operating systems, and clearly Windows XP doesn't give quite as much CPU time to individual processes, making it a better OS for multitasking. Generally speaking, timers are worthless below 50ms.

The reason I haven't mentioned it before is because I expect it to happen, hence I don't use that method for speed control in my code.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 01:35 Edited at: 15th Jul 2003 01:39
Link
I understand and I do use that method when the machine is below 30 FPS. (I.e. On the slower machines things move more in each update.)

This example is simplified to illustrate the problem. The 33 value is actually calculated at 1000/FPS.

BUT I also limit the machines to 30 FPS since anything over that is waste. (Multiplayer over LAN)

How do I run software on these machines so
30 FPS (Win XP) = 30 FPS (Win9X)?

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 02:06
Link
If you don't have both compilers you can download the executables here.
The zip contains 6 executables.

onesec_NS.exe DBClassic - No sync
onesec_sync.exe DBClassic - Using Sync
onesec_FSE_NS.exe DBPro/full screen exclusive - No Sync
onesec_FSE_sync.exe DBPro/full screen exclusive - Using Sync
onesec_WFS_NS.exe DBPro/Windowed Full Screen - No Sync
onesec_WFS_sync.exe DBPro/Windowed Full Screen - Using Sync

They all contain the code below compiled with the indicated options.
When compiled using Sync, then the Sync command was uncommented in the source.


The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 15th Jul 2003 02:29
Link
@heartbone

It cannot be done reliably. Multiplayer games put messages on a stack I believe, so timing isn't too big an issue.

Just forget trying to force the FPS because it annoys users if you fix their FPS, and it is very difficult to enforce FPS.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 06:36 Edited at: 15th Jul 2003 06:44
Link
IanM after much thinking and plowing through the alternatives, I have to admit that I can not see a better and more general method to keep the processing synched across the platforms. I really do not like using a local variable for a timer counter. It is OK to use a local variable to hold values for timer testing, but using a local variable as a timer counter can lead to some serious infinite looping. Still I can not think of any other (simple) way to enforce synchronization, and I may be forced to go with your "fix" and hope for the best. As usual thanks for your input.

Rob K timing is everything. If I shoot at you and you move the split second before the bullet gets to you, we both had better see that is what happened. I don't wish to annoy the user with bogus visuals.

One thing is for certain from my investigations Windows XP has significantly lower processing speeds compared to Windows98 when processing DarkBASIC executables that call Sync. The XP environment seems to be a real processor pig. Using the same code and hardware Windows98 should greatly outperform WindowsXP when running any DB app. That's advanced Microsoft software in action!

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Great Knight
23
Years of Service
User Offline
Joined: 25th Feb 2003
Location:
Posted: 15th Jul 2003 07:19
Link
The protocals dont like each other. Thats can be one suggestion. After I install my IPX in my XP machine it takes a while to load network neighborhood. With my 98 one.

AMD Atherlon 2400+ XP, 380 DDr memeory, ATI Radeon 9000 64 DDR.

And a Katana.
Back to top
Profile PM
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 09:36
Link
Yeah I just installed IPX on my XP laptop last night and have subsequently noticed a slowdown in the network initialization with my 98SE desktop. But they still usually will find each other without any problems.

The Win 98 Explorer does tend to explode randomly after the two machines have disconnected.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Puffy
23
Years of Service
User Offline
Joined: 4th Sep 2002
Location: United States
Posted: 15th Jul 2003 10:02
Link
=\ I'm running Win2000 Pro... I don't seem to have many problems... besides runtime... but thats a win2000 thing... (runtime as in im hardly running at 1000fps -_-....)

EVERYONE LOVES THE PUFF!... =\
Back to top
Profile PM Email Website
Eric T
23
Years of Service
User Offline
Joined: 7th Apr 2003
Location: My location is where I am at this time.
Posted: 15th Jul 2003 10:20
Link
hmmm on my xp 933mhz p3 machine with matrox milleniuom g450 with sync i'm gettin 2.563 and no sync 2.614 and those are the averages calculated out, hm i never though ow sad this machine is.

Opinions are like a$$holes, Everybody has one.
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 10:22 Edited at: 15th Jul 2003 10:29
Link
Raven
2.373 - WinXP Laptop
2.811 - WinMe Laptop
1.202 - WinXP Current Machine
0.760 - Win.Net Current Machine

That test code that you executed was 64 loops of 33ms. 33ms at a minimum. The absolute fastest that it could execute is (64x33) 2.113 seconds.
That "WinXP current machine" that you have must be pretty special, and
how the heck can you trust anything that involves .net?

Obviously you are working on it for the money. But really now .76? Check that machine. If they allow you to.
On second thought perhaps you shouldn't... don't want to be a troublemaker.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 10:28
Link
yusuke200013 Yeah I saw that too for some runs on XP using the first test code. Running with syncs was faster than without! It depends on the compiler settings and I didn't bother to track which ones. Very strange.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 15th Jul 2003 11:29
Link
@Heartbone

Games like Half-Life and Quake3 manage quite happily and they don't force the user's FPS. The idea is that you put a message onto the message stack for a player and once a loop those messages are retrieved off the stack. Therefore if your player fires a bullet, your code sends a message to the other PC. The other PC then immediately shows a gun being fired, and it won't do that until it receives a message from the other player. There will be a small latency due to the network (about 30ms or so, > 100 over the net).

If you fire a bullet, and it reaches the client 30ms later, they are checking their messages 30+ times a second. Therefore their game will find the message and the player will get hit. They won't be able to move because the only time between the player firing and them getting hit is 30ms+(1000/30)ms. There is nothing you can do about that timespan, even if you wanted to.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
Jedive
23
Years of Service
User Offline
Joined: 24th Jan 2003
Location: Spain
Posted: 15th Jul 2003 15:13
Link
Win9x DirectX is not the same as Win2K/XP DX. AFAIK, the Win9x DX is better than the XP one.

== Jedive ==

Athlon 1600+, 512MB DDR, GeForce 4200 128MB DDR, WinXP Pro SP1 / DX9, Mandrake Linux 9
Back to top
Profile PM Email
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 15th Jul 2003 16:12
Link
Quote: "That test code that you executed was 64 loops of 33ms. 33ms at a minimum. The absolute fastest that it could execute is (64x33) 2.113 seconds."


my current machine is a -
Itainium IA-64 2.8Ghz running on a 256bit 450Mhz Bus
isn't particularly special, however it doesn't run 32bit specific operations the way it should.

64*(33*0.30)= what should be what was being receieved.
only Heartbones original version is pretty unstable, so it wouldn't return these values all the time - tack on the WinXPs use of the IA64 processor (outside of NTFS)
so you're talking closer to 64*(33*0.66)

its all to do with the pure calculations being done, i mean on my IA system the Timer just doesn't return the right time as it uses the Dx timer which is the windows timer ... can throw everything out of wack.

that aside though... the Win9x timer is different to the WinXP timer which would explain the difference in the calls.

Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 17:40
Link
Raven: Heartbones original version is pretty unstable
If you examine the code you will not find anything unstable in it. It is gut simple DB code.

Additionally machines from all over the world have run that simple code with consistant results, except for yours.

Maybe it's your bleeding edge computer that makes the code unstable?

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 15th Jul 2003 19:32
Link
@Raven

Most of us are not running 64bit processors. That detail is irrelevant.

Heartbone, please start listening, this "problem" will affects ALL applications running windows. That is why no commercial multiplayer game uses your method of speed regulation - it is stupid. Use a FPS based method instead of a TIMER() based one.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 15th Jul 2003 19:51 Edited at: 15th Jul 2003 19:53
Link
Rob K I have been listening ... reading and understanding.

Maybe my method is stupid as you assert, maybe not. We shall soon see. Thanks for your input. I will continue using Timer() based loops as it works very well from what I have seen on a very wide range of processors not just high end machines only.

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 15th Jul 2003 20:12
Link
And FPS based methods are used successfully on everything from my lowly 33Mhz Psion 5, to the latest 3Ghz PCs.

Your choice - I just reckon it may be problematic.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
Great Knight
23
Years of Service
User Offline
Joined: 25th Feb 2003
Location:
Posted: 15th Jul 2003 20:56
Link
You can alwasy try going to the properties of the program it self and changing its Compatibility to Windows 98. Thats a suggestion.

AMD Atherlon 2400+ XP, 380 DDr memeory, ATI Radeon 9000 64 DDR.

And a Katana.
Back to top
Profile PM
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 15th Jul 2003 21:13
Link
@Great_Knight / Jedive

DX is the same under Windows98 and WindowsXP - they work just as well. It would be pretty daft for MS to make a poorer / different version of DX for their newest OS.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
Shadow Robert
23
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 16th Jul 2003 01:31
Link
actually the more major instability is on my laptop... you run your first code the three times in a row on any system running XP you'll get 3 seperate results.

but knowing what a 64bit processor will cause for the timer and such in the future is important because over the next year everyone is going to be slowly weaned onto the new IA64 over the x86's

you know you could always use IanM's ASM plugin to create a quick realtime processor clock cycle calculator and run loops based on that... its how i do it in C++ cause i don't trust the microsoft timer, when i'm making demo's i use the nVidia one - never the microsoft one its just too unstable.

Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 16th Jul 2003 01:44 Edited at: 16th Jul 2003 01:44
Link
Great_Knight :You can alwasy try going to the properties of the program it self and changing its Compatibility to Windows 98. Thats a suggestion.
Been there done that. It does not work. That compatibility mode is a sham. It can not possibly work. To truly make XP Win9x compatible, you'd have to get rid of it.

Raven :actually the more major instability is on my laptop... you run your first code the three times in a row on any system running XP you'll get 3 seperate results.
Actually it's not just your laptop. Like you said "any system running XP". Inconsistant non-repeatible behaviour in an OS is not a good thing is it?

The more you see, the more you know.
The more you know, the more you see.
Back to top
Profile PM Website
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 16th Jul 2003 02:54 Edited at: 16th Jul 2003 03:01
Link
Quote: "Inconsistant non-repeatible behaviour in an OS is not a good thing is it?"

You are assuming that Windows 98 and Windows XP are pretty similar, which simply isn't true. XP is based on Windows NT, which is completely different to Windows 9x, just made to look similar as in they run similar shells. They are about as similar as Windows 9x and MacOS in terms of the kernel though.

I honestly cannot understand why you are so worried by this. It is not as if the performance of the app is affected. Surely given the massive difference between various PC setups, these changes are bound to occur. In which case you have to use a method which is not affected by such differences.

I also cannot see where your argument of visual inconsistency over a network comes from. If the client gets new messages once per loop, that could be say 30 times per second, a player won't be able to move anywhere between the message being sent and it arriving at the client, not unless your code induces heavy lag. Games like Half-Life and Quake3 can cope even when there is 200ms delay between send and receive (0.2s), I'm sure your game can cope with a few ms delay.


BLUE GUI Plugin: http://blue.robert-knight.net
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-21 17:39:12
Your offset time is: 2026-07-21 17:39:12