Leadwerks3D networking? What there is currently? What's planned for the future?

[Guest Red Ocktober]

@Brent...

DirectDraw is a wrapper for GDI.

 

i was just gonna ask you what you meant by this... glad you sorta corrected yourself...

 

i've forgotten more than i can remember about coding the windows gdi subsystem (circa Chicago), but from what i do remember... the gdi subsystem was around way before directx ever made it appearance... and, the gdi does a lot more than just draw things on the screen...

 

it's an interface that provides device independence for outputting graphics...

 

--Mike

[Flexman]

Popcorn out.

[Guest Red Ocktober]

no... no... no... hopefully not this time

 

--Mike

[Brent Taylor]

@Brent...

 

 

i was just gonna ask you what you meant by this... glad you sorta corrected yourself...

 

i've forgotten more than i can remember about coding the windows gdi subsystem (circa Chicago), but from what i do remember... the gdi subsystem was around way before directx ever made it appearance... and, the gdi does a lot more than just draw things on the screen...

 

it's an interface that provides device independence for outputting graphics...

 

--Mike

 

Err, I don't see an error in what I've said. DirectDraw was a wrapper for GDI. If a proper video card wasn't found it'd default to GDI for rendering. Simple as that.

[Flexman]

I go with whatever works, forget craft, elegance, politics. Whatever you need to get the job done.

 

Glad you got Raknet compiling GP. It might be commercial but it's free for the likes of us. Really it's just an event system around a wrapper, easy to change IF and WHEN you have a viable working alternative.

[Guest Red Ocktober]

@Brent...

Simple as that.

 

actually a lil too simple...

 

lemme refer you to a lil discussion i remember reading which is almost a word for word copy of the one we're having here... maybe the answer given by someone other than me might be more pallatable to you...

 

And isn''t DirectDraw, especially in windowed mode, a wrapper for the GDI?

 

I hope I''m wrong, since that would make my life a lot

easier. Since my game is using Direct3D to render blended

particles in a 2D environment.

 

quote:And isn''t DirectDraw, especially in windowed mode, a wrapper for the GDI?

 

NO, DirectDraw isn''t a wrapper for ANYTHING apart from the device driver for the video card. Most of GDI is actually software based rather than accelerated. There are parts of GDI which also talk direct to the video card driver. And DirectDraw has to be aware of what GDI is up to, but they''re not linked at all.

 

oh... here's the url, just in case you want to read it yourself...

http://www.gamedev.net/topic/138642-using-both-direct3d-and-directdraw-together/

 

from a discussion on GameDev...

 

--Mike

[Mumbles]

SDL_net does rely on SDL. Under windows that does include a dependancy on DirectX being installed.

 

Perhaps I was reading the documentation for the Linux version (although if that's the case, why haven't I found the doc for the Windows build? I mean, I use SDL for joystick handling!). I mean, SDL did start as a Linux library didn't it?

 

SDL_net relying on SDL... I didn't know that, but it equally sounds plausible. The only part I had a hard time believing was the SDL and Direct X bit. Although thinking about it, I think I remember you in the past telling me how it uses DirectInput for its joystick handling on Windows, hence why it has the silly triggers thing when using 360 controllers in Windows, but doesn't in Linux. Such that (off topic) I eventually programmed my controller class to use both SDL and XInput for joystick support (although, only one at a time per controller), just on the off chance that if a 360 controller was used in Windows, both the triggers would work correctly.

[Brent Taylor]

@Brent...

 

 

actually a lil too simple...

 

lemme refer you to a lil discussion i remember reading which is almost a word for word copy of the one we're having here... maybe the answer given by someone other than me might be more pallatable to you...

 

 

 

 

 

oh... here's the url, just in case you want to read it yourself...

http://www.gamedev.n...tdraw-together/

 

from a discussion on GameDev...

 

--Mike

 

Unfortunately this is a hard thing to argue as the documentation for DirectInput (DX7 and below) is pretty much non existant at this point. With the release of DirectX 8 DirectDraw was rewritten to run on top of (or as part of, as the details are a bit sketchy) Direct3D.

 

Keep in mind that the post you linked is back from 2003. DirectX 9 was released in 2002. The poster you quote is certainly correct, but we're talking about a feature that was depricated in years prior.

[Canardia]

I made one final test, and tried how fast AJAX is compared to WinSock TCP.

WinSock made 100 28 byte transfers between USA and FI in 12s, and AJAX took 26s.

[Guest Red Ocktober]

@Brent...

 

i am so impressed... not only at your ability to refuse to acknowledge a fact when you are confronted by one... but also at your deftness and skill in conjuring an argument in a futile attempt to validate your position...

 

i stand in awe...

 

 

i must ask two things though...

 

1 - do you actually believe any of what you're saying...

 

2 - and if you do, do you think that it will in any way change the plain and inarguable fact that DirectX is not a wrapper for the GDI...

 

 

 

 

--Mike

[Brent Taylor]

@Brent...

 

i am so impressed... not only at your ability to refuse to acknowledge a fact when you are confronted by one... but also at your deftness and skill in conjuring an argument in a futile attempt to validate your position...

 

i stand in awe...

 

 

i must ask two things though...

 

1 - do you actually believe any of what you're saying...

 

2 - and if you do, do you think that it will in any way change the plain and inarguable fact that DirectX is not a wrapper for the GDI...

 

 

 

 

--Mike

 

On the off chance that I just wasn't clear, let me rewrite part of my last post.

 

"Unfortunately this is a hard thing for me to argue as the documentation for DirectInput (DX7 and below) is pretty much non existant at this point."

 

Red, I understand you're still clearly upset about our little argument from the other day. However, do not attempt to belittle me at every opportunity. That would simply be childish.

 

I take no issue with being proven wrong, when it actually occurs. It's happened a number of times on these forums and I tend to be fairly graceful about it and I'm better for it. However, you have not shown any proof of this occuring in this instance and you've moved on to belittling me instead. I won't suffer a tantrum, Red.

[Canardia]

Another interesting test I made: it seems that with WinSock TCP it doens't matter even one millisecond, if you send 14 bytes or 114 bytes, while with AJAX it raises the time a few seconds.

 

Now I think I have all tests done, and can make a super fast network library. Apparently it needs a send queue, where it collects data for a packet before it sends it, to maximize the speed.

[Guest Red Ocktober]

@Brent...

DirectInput (DX7 and below) is pretty much non existant at this point."

wrong again... MSDN has all the DX7 docs archived... and i have the DX7 SDK disk, with all the docs... as do many others i'm sure...

 

Red, I understand you're still clearly upset about our little argument from the other day.

wrong on this as well... why would i get upset... i can take a spirited disagreement as well as anyone...

 

I take no issue with being proven wrong,

it seems that you do... but you shouldn't...

 

i'm not here to prove you wrong... it just seems as if you make statements that present an authoritative knowledge and experience on some matters, but in fact those statements are incorrect and based on misconceptions rather than fact... it's those statements that are wrong, and i would think that you might want to look further into what you are saying, to ascertain the actual facts behind it...

 

it's not about you... it's not about me... it's about what is fact... and what is not...

 

i'm wrong at least 10 times a day...

 

as far as this dx wrapper stuff is concerned... if the conclusions of others (who have more extensive background, experience, and knowledge on the subject) aren't enough, ask yourself the following...

 

why would directx(directdraw) wrap itself around an inherently slower api to do high speed rendering... which is the one main features of directx... high speed rendering...

 

from wikip...

Microsoft DirectX is a collection of application programming interfaces (APIs) for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms. Originally, the names of these APIs all began with Direct, such as Direct3D, DirectDraw,DirectMusic, DirectPlay, DirectSound, and so forth. The name DirectX was coined as shorthand term for all of these APIs

 

above you also suggest that the GDI is depricated... but in fact, the GDI apo is alive and well...

 

GDI+ is a C++ graphics toolkit for windows. Basically, its a c++ wrapper around gdi but with some additional features..

based on your (faulted) reasoning above, would you now conclude that DX is a wrapper for GDI+...

 

cmon man... think about it for a sec... take me out of the equation... take yourself out of the equation... and think about it... logically, objectively, and pragmatically...

 

 

--Mike

[Canardia]

Hey guys, do you know that only idiots talk about people, and intelligent people talk about what they said. I think Paulo Coelho said that.

So please don't use "you" or "me" in sentences, but only what they said and comment on that.

[Guest Red Ocktober]

shaddup... and get back to your winsock programming

 

--Mike

[Canardia]

See, you used the word "you" again. Learn to form intelligent sentences. See, I didn't say "you", but generalized it

[Brent Taylor]

wrong again... MSDN has all the DX7 docs archived... and i have the DX7 SDK disk, with all the docs... as do many others i'm sure...

I'd be greatful for a link to the old DirectX 7 documentation. I've found several links to it on the MSDN, all of which are dead.

 

It just seems as if you make statements that present an authoritative knowledge and experience on some matters, but in fact those statements are incorrect and based on misconceptions rather than fact... it's those statements that are wrong, and i would think that you might want to look further into what you are saying, to ascertain the actual facts behind it...

 

And I have no issue with being proven wrong in those instances. However, I find it interesting that you portray this as a common event. This is why I think you're still upset about the events from our previous argument. I'm certainly wrong on ocassion (it's healthy), it's not often however. It's very rare that I'll argue a point without some sort of documentation to back me up.

 

if the conclusions of others aren't enough ...

And that "conclusion" would have much more validity as an authority on the subject if DirectX 9 was not already in common use at the point of his post. In regaurds to DirectX 8 and 9 he's absolutely correct.

why would directx(directdraw) wrap itself around an inherently slower api to do high speed rendering... which is the one main features of directx... high speed rendering...

This I would think would be fairly obvious. Remember, I said it defaults to GDI if a proper video card is not found. It's a fallback.

 

Hence why I said:

Ok, I'm partly mistaken here. DirectDraw (as in for DirectX 7, not higher) uses GDI by default unless a supported video card is found.

Also note me pointing out my mistake. Just for good measure.

 

cmon man... think about it for a sec... take me out of the equation... take yourself out of the equation... and think about it... logically, objectively, and pragmatically...

I think I've presented a fairly logical argument here. As I said, this is unfortunately very difficult for me to argue seeing as I can't find the DirectX 7 documentation anywhere. If you happen to have a link handy, by all means send it my way (and to be clear, I'm not putting the search on you. I'm looking for it as well).

 

EDIT:

@Everyone else

My bad. It's pretty clear we're hijacking the thread here.

[Guest Red Ocktober]

I think I've presented a fairly logical argument here

there is no logic to anything you've said so far... Among the important properties that logical systems can have:

• Consistency, which means that no theorem of the system contradicts another.^[12]
  
• Validity, which means that the system's rules of proof will never allow a false inference from true premises. A logical system has the property of soundness when the logical system has the property of validity and only uses premises that prove true (or, in the case of axioms, are true by definition).^[12]
  
• Completeness, of a logical system, which means that if a formula is true, it can be proven (if it is true, it is a theorem of the system).
  
• Soundness, the term soundness has multiple separate meanings, which creates a bit of confusion throughout the literature. Most commonly, soundness refers to logical systems, which means that if some formula can be proven in a system, then it is true in the relevant model/structure (if A is a theorem, it is true). This is the converse of completeness. A distinct, peripheral use of soundness refers to arguments, which means that the premises of a valid argument are true in the actual world.
  
• 
  

(quoted)

 

As I said, this is unfortunately very difficult for me to argue seeing as I can't find the DirectX 7 documentation anywhere.

yet you still continue to argue... most illogical...

 

If you happen to have a link handy, by all means send it my way

 

if you're really interested...

 

3D Game Programming With C++. by John De Goes... It's a pretty big intro to DX7 game programming.

Sams Teach Yourself DirectX 7 in 24 Hours (Teach Yourself Hours) free ebook download http://www.freebookspot.es/Comments.aspx?Element_ID=240273

 

 

--Mike

[Mumbles]

Now I think I have all tests done, and can make a super fast network library. Apparently it needs a send queue, where it collects data for a packet before it sends it, to maximize the speed.

 

That's the default for winsock TCP sockets...

 

If you want to disable that, and send instantly:

 

 

BOOL bOptVal = TRUE;
int bOptLen = sizeof(BOOL);
int iResult = setsockopt(/*Your socket handle*/,IPPROTO_TCP,TCP_NODELAY,(char *)&bOptVal,bOptLen);

 

pinched straight out of the MSDN...

 

I presume those silly capitalised BOOL and TRUE are defined in winsock2.h. However intellisense seems to be having one of those days for me where it doesn't want to tell me

[Brent Taylor]

there is no logic to anything you've said so far...

So there is no logic to GDI being used as a fallback renderer? Keeping in mind it's the only thing I've been arguing about. And you haven't shown any proof otherwise.

 

Among the important properties that logical systems can have:

• Consistency, which means that no theorem of the system contradicts another.^[12]
  
• Validity, which means that the system's rules of proof will never allow a false inference from true premises. A logical system has the property of soundness when the logical system has the property of validity and only uses premises that prove true (or, in the case of axioms, are true by definition).^[12]
  
• Completeness, of a logical system, which means that if a formula is true, it can be proven (if it is true, it is a theorem of the system).
  
• Soundness, the term soundness has multiple separate meanings, which creates a bit of confusion throughout the literature. Most commonly, soundness refers to logical systems, which means that if some formula can be proven in a system, then it is true in the relevant model/structure (if A is a theorem, it is true). This is the converse of completeness. A distinct, peripheral use of soundness refers to arguments, which means that the premises of a valid argument are true in the actual world.
  

 

Uh, great. With the exception of not being able to find the proof (seeing as the DX7 documentation is nowhere to be found), I'd say I fit that definition just fine. In either case, rather than explain why I'm being illogical you seem bound and determined to simply belittle me.

 

yet you still continue to argue... most illogical...

Until proven that I'm wrong, I see no real reason to stop. Why would I? Peer pressure? That wouldn't be logical.

 

if you're really interested...

 

<link ommitted by BTaylor>

I'm sure that's great information on using DirectX 7. I'm interested in it's implementation. That is not the DirectX 7 documentation. (I'm also pretty against piracy in general.)

 

As a side note: Linking a piracy site on here is probably not a good idea.

 

EDIT: Honestly, I give up. This is a meaningless argument. I can't argue my point as I can't find the documentation. All that is being accomplished is allowing Red to attack my character despite not having any proof or documentation himself. In addition we've hijacked a thread on a completely different topic.

 

If I can find the DX7 documentation somewhere, I'll add one last post on the subject indicating whether I was right or wrong. Otherwise, I'll stay on topic.

[Canardia]

That's the default for winsock TCP sockets...

 

If you want to disable that, and send instantly:

 

 

BOOL bOptVal = TRUE;
int bOptLen = sizeof(BOOL);
int iResult = setsockopt(/*Your socket handle*/,IPPROTO_TCP,TCP_NODELAY,(char *)&bOptVal,bOptLen);

 

pinched straight out of the MSDN...

 

I presume those silly capitalised BOOL and TRUE are defined in winsock2.h. However intellisense seems to be having one of those days for me where it doesn't want to tell me

How do you send packets so that they go into the packet queue? From my tests, each message was delivered at once when I did

retval = send(conn_socket,Buffer,strlen(Buffer),0);

[Mumbles]

The return val of send() doesn't mean the data has been transmitted, it just means that the receiver is able to receive it. send() only returns an error if (for example) you try to send data, but the receiver station has hard closed on you.

 

Check what recv() is receiving, it may be mixing several packets together. That's the sort of thing Nagle does...

[Canardia]

That doens't explain why I can send 14 bytes or 114 bytes with send(), and get not a millisecond difference in transfer speed. It would mean, that I have to manage when I call the send() function, after I have a big enough string to send (or binary data).

 

Obviously, it's not very effective to send small packets, because each sending takes FPS, and it would be much more efficient to send larger packets, since the FPS drop is the same.

 

Or lets look at it the other way around: if send() was doing packet queing, then it would show much faster speed with 14 byte strings than with 114 byte strings, because the total amount of data transferred is much bigger. That means send() does not really do the packet queing right, if it does it at all, because if it did it right, then there would a huge time difference in sending the total amount of data from 100 repeated send() commands.

[Brent Taylor]

That doens't explain why I can send 14 bytes or 114 bytes with send(), and get not a millisecond difference in transfer speed. It would mean, that I have to manage when I call the send() function, after I have a big enough string to send (or binary data).

 

Obviously, it's not very effective to send small packets, because each sending takes FPS, and it would be much more efficient to send larger packets, since the FPS drop is the same.

 

I haven't actually taken the time to actually time any of this so excuse what may be ignorance on my part. We send data pretty quick these days, especially when sending via localhost. Is it possible you're just sending too little information to actually measure a time difference? It's possible the queue is just empty before the next bit of data is loaded and sent along to the queue.

 

In addition, how are you timing this exactly? Post code if you could.

[Mumbles]

That doens't explain why I can send 14 bytes or 114 bytes with send(), and get not a millisecond difference in transfer speed. It would mean, that I have to manage when I call the send() function, after I have a big enough string to send (or binary data).

 

Never do that for games. No client wants to be kept hanging around waiting for physics updates, simply because "there's less overheads if we wait 100 milliseconds for a few more updates". Send them instantly or else your client side synchronisation will be horrible.

 

 

If you're employing the same idea I am, "full" physics updates go via TCP, and they must arrive timely. They're sent only once a second, so any going missing would be a disaster - I might increase it to 2 per second. But delta updates for dead reckoning instead go via UDP, and it's not a serious showstopped if one arrives late (or never at all).

 

 

For everything but games, yes, wait for data to reduce the overheads, but for games, ignore it and send instantly.

 

 

Obviously, it's not very effective to send small packets, because each sending takes FPS, and it would be much more efficient to send larger packets, since the FPS drop is the same.

 

It would be a good idea to place the networking in its own thread - possibly more than one thread even. For a server, I'd say a minimum of one thread per client

 

 

As for sending data, the RTT is all that's really important. You don't need to know how quickly 100 MB transfers from the sender station to its receiver. But if it's taking 200 milliseconds for absolutely any packet to be received, in a game that ticks 25 times a second, the data is 5 ticks out of date by the time the client receives it. So if the server overrides any predicted physics, there could be 5 ticks worth to recalculate, which a player has a good chance of visibly seeing, and it negatively affecting their playability.

 

On the other hand, someone who has a ping of 30 could completely catch up and be synchronised with the server, resulting in any server enforced correction being barely noticeable at all...