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

[Canardia]

Yes, to maximize speed via data queing, multithreading is a must, so I will implement that too. POSIX threads are great, especially when using MUTEX. I don't think games need that often data updates, I mean not like 60 times per second. A one second interval should be just fine even for the fastest actions games (I just imagined a massive FPS combat scene, where players move around and shoot at eachother, everything moves all the time, but every 1 second things are updated, if there is even a need to update, because non-changing directions and speed don't need any data to send), since the movements are done with MoveEntity/PointEntity commands anyway, which implements interpolation.

 

My real concern is the amount of players. With a smart packet queing it should be possible to have thousands of players on a indie server (just a normal tower PC connected to 8/3 landline ADSL).

 

Just imagine a stable and constant 1s heartbeat of the earth. You have a LOT of time to collect differential data to send, and the action will never seem laggy, because it beats hard with that 1s interval. Forever, and ever.

[Guest Red Ocktober]

@Brent...

So there is no logic to GDI being used as a fallback renderer?

the question is itself absurd...

what you should be asking is... "So there is no logic in me asserting that because GDI being is used as a fallback renderer it supports my assertion that DirectX is a wrapper for the GDI?"...

 

that's a coherent question that i could answer...

and the answer is no... just like me and other more knowledgeable people have said...

 

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.

no... don't... please don't... stop following me around in search of some sorta self validation... i really could care less what you believe...

 

and i'm suddenly finding Metatron's posts a lot more interesting than yours... so, please... go away...

 

please...

 

let the discussion get back on topic...

 

 

 

--Mike

[Brent Taylor]

A one second interval should be just fine even for the fastest actions games, since the movements are done with MoveEntity/PointEntity commands anyway, which implements interpolation.

Keep in mind, this would make a lot of games fairly unplayable. In an FPS, one second is enough time to circle around a player and shoot him from behind. If all clients are potentially one second behind you're going to have very frustrated players.

[Mumbles]

stop following me around in search of some sorta self validation...

 

 

Wait a minute, you followed him into this thread...

[Canardia]

Well, game design is about optimizing things. That particular situation could be optimized by sending more frequent packets in close combat, or implement a game logic which prevents from exploiting the network heartbeat. For example god would kill a player who is jumping and running around for no apparent reason. I wish they had that in WoW

[Brent Taylor]

For example god would kill a player who is jumping and running around for no apparent reason.

 

Those poor Quake players... =P

[Guest Red Ocktober]

you're absolutely correct Mumbles...

 

actually, i was following the thread with great interest, but had nothing of consequence to contribute...

as i was just getting ready to ask a question, i stumbled onto Brent's statement...

 

i should've known better than to take exception with anything he says...

 

you are absolutely right...

 

--Mike

[Josh]

Please be polite to each other. Our community is awesome, let's keep it that way.

[Brent Taylor]

Woohoo! Found the DX 7 documentation. Anyone interested can find it here: http://dl.dropbox.co...ads/dx7docs.exe

 

Here's a few choice bits from the DirectX 7 documentation on the subject.

It first hints at software emulation here (found on the Architectural Overview for DirectDraw):

As with other DirectX components, DirectDraw uses the hardware to its greatest possible advantage, and provides software emulation for most features when hardware support is unavailable.

 

And for information on the HEL (Hardware Emulation Layer) (found on the Software Emulation page):

When the hardware does not support a feature through the hardware abstraction layer (HAL), DirectDraw attempts to emulate it. This emulated functionality is provided through the hardware emulation layer (HEL). The HEL presents its capabilities to DirectDraw just as the HAL would. And, as with the HAL, applications never work directly with the HEL. The result is transparent support for almost all major features, regardless of whether a given feature is supported by hardware or through the HEL.

 

Still a little vague and doesn't mention GDI. This chart however is relatively clear (found on the System Integration page):

 

So there you have it. If a proper video card is not found, it did in fact drop down to GDI for rendering.

[Pixel Perfect]

I found this guys if its of any interest:

 

http://msdn.microsoft.com/en-us/library/windows/hardware/ff553819(v=vs.85).aspx

 

GDI automatically enables DirectDraw when the display driver is initialized. To provide better interaction between DirectDraw and the graphics DDI portion of the driver, a driver that also supports the DirectDraw DDI can implement or call the following functions:

 

DrvDeriveSurface

A driver-implemented function that wraps a GDI driver surface around a DirectDraw driver surface, allowing any GDI drawing to DirectDraw video memory or AGP surfaces to be hardware accelerated (rather than being drawn in software via the DIB engine). Typically, if the driver already supports off-screen device bitmaps, this function should require only a few additional lines of code.

[Brent Taylor]

I found this guys if its of any interest:

 

http://msdn.microsof...9(v=vs.85).aspx

 

The problem with a lot of info on DirectDraw is that most of it pertains to DirectDraw under DirectX 8 and higher. With the release of DirectX 8, DirectDraw was completely rewritten to run on top of Direct3D. In addition, a lot of other systems ended up being written to take advantage of DirectDraw under XP with the release of DirectX 9 (which is what your snippet is refering to I believe).

 

The whole argument was about DirectDraw before the rewrite.

[Canardia]

OpenGL is better than DirectX, case closed.

[Guest Red Ocktober]

thx Pixel...

at least now the discussion of dx being a wrapper for the gdi can be based on fact, and hopefully those interested can see that this is simply not true...

 

now read the following slowly and try to understand what it is saying...

 

DrvDeriveSurface

A driver-implemented function that wraps a GDI driver surface around a DirectDraw driver surface, allowing any GDI drawing to DirectDraw video memory or AGP surfaces to be hardware accelerated (rather than being drawn in software via the DIB engine). Typically, if the driver already supports off-screen device bitmaps, this function should require only a few additional lines of code.

ok... if you have some difficulty with that, this may help

 

The DrvDeriveSurface function derives a GDI surface from the specified DirectDraw surface.

Syntax

 

 

HBITMAP DrvDeriveSurface(

DD_DIRECTDRAW_GLOBAL *pDirectDraw,

DD_SURFACE_LOCAL *pSurface

);

Parameters

pDirectDraw

Pointer to a DD_DIRECTDRAW_GLOBAL structure that describes the DirectDraw object. pSurface

Pointer to a DD_SURFACE_LOCAL structure that describes the DirectDraw surface around which to wrap a GDI surface.

Return value

 

DrvDeriveSurface returns a handle to the derived GDI surface upon success. It returns NULL if the call fails or if the driver cannot accelerate GDI drawing to the specified DirectDraw surface.

Remarks

 

DrvDeriveSurface allows the driver to create a GDI surface wrapped around a DirectDraw video memory or AGP surface object in order to allow accelerated GDI drawing to the surface. If the driver does not hook this call, all GDI drawing to DirectDraw surfaces is done in software using the DIB engine.

 

 

ok... not wanting to confuse the issue with the facts, i'll ask you... what do you conclude from this bit off information...

 

 

 

 

 

--Mike

[Brent Taylor]

I would conclude that DirectDraw under DirectX 8 and higher do not have a GDI backend. Then again, you already know for a fact that I said this before this whole argument. Afterall, in the initial post that you replied to that started this whole argument I had already said this.

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. At the time it was written as a completely seperate library (at a time where the 3DFX Voodoo cards were the most common around, most of which didn't support DirectX).

Later versions of DirectX rewrote DirectDraw as a wrapper around Direct3D. The latest SDK doesn't include DirectDraw at all.

 

However, as the DirectX 7 documentation has proven, it did in fact drop down to GDI if a suitable video card was not found. Must we go on?

 

EDIT: As indicated a few posts down from here, that is documentation for Win2k's XDDM driver so Dx7 is potentially used. This however is not the case for Win95 and Win98.

[Canardia]

Guys, you can easily solve all the problems with DirectX by just downloading the Debian 6.0.5 DVD, putting it in your PC drive, and suddenly your PC hardware actually works! Everything what Microsoft has done is BAD, very bad, except WinSock, which is also cross-platform. They kinda made a "mistake" by making something good.

 

I bet the developer of WinSock was fired long time ago, because I think the employment policy in Microsoft is something like this: Never make anything good or useful, only make bad, slow, buggy and bloated programs (hey, that's why we invented C# and SharePoint in first place), because that's where we get the money from, since each "bug report" costs the customers 500€. Then we fix it, but of course not for everyone, since we want the money from all other customers too.

[Pixel Perfect]

The problem with a lot of info on DirectDraw is that most of it pertains to DirectDraw under DirectX 8 and higher. With the release of DirectX 8, DirectDraw was completely rewritten to run on top of Direct3D. In addition, a lot of other systems ended up being written to take advantage of DirectDraw under XP with the release of DirectX 9 (which is what your snippet is refering to I believe).

 

The whole argument was about DirectDraw before the rewrite.

Well I suspect the article is referencing DirectX7 as the page is a reference page for the Windows 2000 display driver model and Windows 2000 shipped with DirectX7 not 9 which was much later. I just thought it was interesting that it appears that GDI could wrap around Direct Draw too and take advantage of the hardware acceleration. DirectX8 appeared late in 2000 so it's still possible this refers to that and the later rebuild as you point out.

[Brent Taylor]

Well I suspect the article is referencing DirectX7 as the page is a reference page for the Windows 2000 display driver model and Windows 2000 shipped with DirectX7 not 9 which was much later. I just thought it was interesting that it appears that GDI could wrap around Direct Draw too and take advantage of the hardware acceleration. DirectX8 appeared late in 2000 so it's still possible this refers to that and the later rebuild as you point out.

 

I stand corrected! This is the 2k XDDM driver. My mistake entirely.

 

However the DirectX 7 documentation does pretty clearly indicate GDI as a backend. That said, I see no reason that GDI couldn't use DirectDraw as a backend if a proper video card is found. Though that much is just guesswork on my part. It wouldn't surprise me if there is a mention of this in Windows Internals somewhere.

 

In addition, that's the 2k XDDM driver. DirectX 7 ran on Windows 95, 98 and 2k. It's very possible it's a 2k specific change.

[Guest Red Ocktober]

However, as the DirectX 7 documentation has proven, it did in fact drop down to GDI if a suitable video card was not found.

show me anywhere in these docs where directx7 does this...

 

god... it's like pulling teeth...

 

--Mike

[Canardia]

I'm going to complain to Josh soon, all talk about DirectX should be banned from this forum. It's ****, no need to discuss

[Brent Taylor]

show me anywhere in these docs where directx7 does this...

 

god... it's like pulling teeth...

 

--Mike

 

Considering the rapid posting in this thread, I think you probably just missed the post.

You can find it: Here

 

And I'll repost it here for convenience:

Woohoo! Found the DX 7 documentation. Anyone interested can find it here: http://dl.dropbox.co...ads/dx7docs.exe

 

Here's a few choice bits from the DirectX 7 documentation on the subject.

It first hints at software emulation here (found on the Architectural Overview for DirectDraw):

As with other DirectX components, DirectDraw uses the hardware to its greatest possible advantage, and provides software emulation for most features when hardware support is unavailable.

 

And for information on the HEL (Hardware Emulation Layer) (found on the Software Emulation page):

When the hardware does not support a feature through the hardware abstraction layer (HAL), DirectDraw attempts to emulate it. This emulated functionality is provided through the hardware emulation layer (HEL). The HEL presents its capabilities to DirectDraw just as the HAL would. And, as with the HAL, applications never work directly with the HEL. The result is transparent support for almost all major features, regardless of whether a given feature is supported by hardware or through the HEL.

 

Still a little vague and doesn't mention GDI. This chart however is relatively clear (found on the System Integration page):

 

So there you have it. If a proper video card is not found, it did in fact drop down to GDI for rendering.

[Guest Red Ocktober]

LOL @ Loomuja...

 

@Brent

read the thing doggone it... for god sake, it's right in front of you...

When the hardware does not support a feature through the hardware abstraction layer (HAL), DirectDraw attempts to emulate it. This emulated functionality is provided through the hardware emulation layer (HEL). The HEL presents its capabilities to DirectDraw just as the HAL would. And, as with the HAL, applications never work directly with the HEL.

 

 

 

 

--Mike

[Brent Taylor]

LOL @ Loomuja...

 

@Brent

read the thing doggone it... for god sake, it's right in front of you...

 

--Mike

I did. It's pretty clear. It drops to the HEL for any feature the HAL can't support. I'm not sure what else we're supposed to get out of that man.

[Guest Red Ocktober]

It's pretty clear. It drops to the HEL for any feature the HAL can't support.

 

there ya go... finallly...

 

now, how do you figure this translates to the the assumption that GDI is a fallback for DX...

 

 

--Mike

[Brent Taylor]

there ya go... finallly...

 

now, how do you figure this translates to the the assumption that GDI is a fallback for DX...

 

 

--Mike

 

That isn't what I said. I said that GDI is a fallback for DirectDraw, not DirectX. In fact I've never indicated otherwise at any point. The HEL (Hardware Emulation Layer) emulates most if not all features of a video card in software (Windows' software drawing API is GDI).

 

You've just admitted that DirectDraw drops the the HEL if a proper video card isn't found.

[Guest Red Ocktober]

that's exactly what you said...

 

on page 3...

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.

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.

 

 

Dx7 era Windows might run on a system with a minimal card, using the GDI to draw the various windows elements... but It won't run a directx7 game on that same system... dx7 wouldn't automatically fall back to anything and run...

 

Reversii and the card game that came with windows back then aren't dx7 games... no DX7 graphics are capable without a capable gpu... period... it doesn't fall back and magically run through the GDI, the HEL, or the HAL... DX7 is not a wrapper for the GDI...

 

You've just admitted that DirectDraw drops the the HEL if a proper video card isn't found.

i didn't admit anything... i didn't have to... its written in plain english in the docs for me, and everyone else to see...

 

it's a fact...

 

now how does that support anything you're try to assert about the GDI being a fallback for DX... or DX being a wrapper for the GDI...

 

if you had ever written a dx program you'd understand these things that i am patiently trying to explain to you, instead of trying to assert something that is not true as fact... i was writing dx apps when the first dx sdk came out... what you're saying is just not true... no matter how you try to spin it...

 

 

--Mike