Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

civguy

Heh, Sweeney's opinion on DirectPlay

This topic is 6507 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Meduzza:

Makes senses. But I still can''t see why it''s such a big problem .
AND you can make non-blocking sockets using fcntl() - I''m sure wether that works in Windows or not though, and non-blocking sockets are quite the CPU hogs. And then there''s select...and thus we have blocking sockets with timeout limits!

I''m working on a simple tcp/ip server right now and it''s going good so far. I just let the main process sit and listen() for new connections and spawn a new thread for every new connection it accepts.


quote:
Original post by ajoling

There''s a company that''s converting all the directX functions to Linux. And there are already Windows conversions for Linux. Compatibility doesn''t have to be a problem over a few months.




Um...What company? Transgaming? Well, they''re working on the multimedia part (DirectX) of Wine but there are still only what, 10 big titles (?) that will run under it - and even less can you expect a new game to run under it.

Windows conversions???
Wine?? If it''s wine you''re thinking about it''s an EMULATOR. And it''s not quite functional, yet.


"This album was written, recorded and edited at Gröndal, Stockholm in the year of 2000. At this point in time money still ruled the world. Capitalistic thoughts were wide spread. From the sky filled with the fumes of a billionarie''s cigar to the deepest abyss drenched in nuclear waste. A rich kid was a happy kid, oh..dirty, filthy times. Let this be a reminder."
- Fireside, taken from back of the Elite album

Share this post


Link to post
Share on other sites
Advertisement
Just to maintain correctness: The Wine people say that Wine is an "implementation of Windows un Unix systems". I still call it an emulator, but so what, it doesn''t matter.

Yes, Transgaming are writing DirectX libraries. But they will have huuuge problems with DirectPlay. Why? Because the DirectPlay protocol is closed. You just CAN''T write a DirectPlay implementation without reverse engineering its protocol via packet sniffing. And I wouldn''t be too surprised if Big Bad MS changed the DPlay protocol in the next version after someone successfully implemented it. This is no Linux-freak BS, they did the same thing with SMB (the Windows filesharing protocol). Therefore, DPlay cannot be considered portable.

cu,
Prefect

Resist Windows XP''s Invasive Production Activation Technology!
One line of sourcecode says more than a thousand words.

Share this post


Link to post
Share on other sites
I see a common thing going on between Sweeney and Carmack.

Carmack stated in 1996 (Or was it 1997?) that Direct3D was a piece of crap, and people still quote that. Now what Sweeney said is very recent. However, I don''t think that Sweeney has really used DirectPlay that much. Not to offend Sweeney, but we all know the quality of Unreal''s original network code -- and it used Winsock, so I wouldn''t take his input on DirectPlay very seriously.

Just because Sweeney is ''famous'' for Unreal Tournament doesn''t mean he''s god.

-Dan Smith
dans@3dgamedev.com

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
My thoughts on the Dplay vs Winsock debate.

If you use Dplay you will not only be locked in on the client side but also the server side to an all Windows network. You can write your game to be portable in 3d/2d/gui/sound even with DX, however this is impossible with Dplay. Dplays protocols are closed and proably propriaty, thus if you tried to reverse enginneer them it would proably violate the lisence agreement which comes with the DX libaries, and that means your implmenetation couldnt be used in any commerical applcation anyways. Someone tried to revese engineer the D3D protocols to make an OpenGL emulator which used D3D instead of OpenGL, they were shutdown by Microsoft, I dont see how reverse engineering the Dplay protocols would be any different.

The DX libaries were suppose to allow the programmer closer access to the hardware and a more consitent and efficent interface. Most of the DX libaries do follow this, however Dplay seems to be the exception. It''s features are more reliant upon the OS (asynchronous sockets, IOCompletion, and who knows what other propriatry hooks it has with Windows). Direct3D doesnt go through the GDI to perform its routines, etc.. I guess what im getting at is Dplay is more of a wrapper for the Win32 internet functions than any low level direct hardware interface which what the DX libaries are all about. It proably belongs more in with DirectShow in the DX media libaries.

Truthfully if they did write a Dplay which was more low level and nearer to the hardware it would be Winsock. No point in rewritting what already exist i suppose.

As shown by the evolution of D3D, Microsoft gets it right when they work on cleaning up the interface, and allowing the developers lower level access to the hardware than trying to do everthing (i.e. D3DRM) their way. I see Dplay as more like D3DRM, for people who need it, it can be useful, however most developers will opt with developing a more propriatry/stable network engine/interface.

If you need its features, and are short on the expereience or time, Dplay is a good route. Just hope Microsoft intends to support it in their future DX versions. If you want to learn about the how and whys behind Dplay, writting your own perhaps simpler Win32 wrapper might be enlightening, but as from reading this board, it isn''t an easy task.

-ddn

Share this post


Link to post
Share on other sites
I think that, if you really want to get to the max of your Networking protocoll you''ll need access to the UDP layer.. this means not using DPlay, cause it''s on top of UDP.

The thing is that you can tune you package far more and save a few bytes. btw, how much is the DPlay overhead to provide a save protocoll? I need exactly 2 extra bytes for my protocol that''s using UDP.

Another point is that DPlay, cause it''s sooo reliable, will always try to get every package, so it could be that it''ll try forever to get a package that got lost.. This might sound ok, but sometimes you don''t need to get every package.... think of sprectating in Quake.. how much does a spectator care if he sees a player changing his weapon. (well he does, but you know what I mean, I hope *g*)..

ok, that''s it,
thx,
cya,
Phil

Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states

Share this post


Link to post
Share on other sites
The was a rumor (from one the DP8 programers) that they were considering making the DP specifications public - so that servers could be made for other OSs... I didn''t really believe it, but there''s a shot it hell they actually will.

You should already know something about free-threading and asyncronous sockets before you take on DP8. Creating a thread for each socket in blocking mode is easy. Creating a windows-message-pump-marshaled single-threaded apartment asycn socket program is still pretty easy. Creating a thread-pool based free-threaded socket program is more difficult - but it has the greatest performance/features of all the models. And DP8 uses that model.

Then there''s the packet-selectable reliable UDP, which is nice to have. Also packet prioritizing, which is nice.


Portable code isn''t high performance code. The BSD style sockets are supported on everything now-a-days, but it''s not an ideal method to make the most of a M$ OS server. I''m not sure if an event-based async-socket is available on linux or other OSes...

I thought DP8 was a huge pain-in-the-ass to setup. But''s it''s working well for me now. The difficulty to create servers for other OSes does bother me though. I plan to continue with DP for now, and if our project gets to the point that we want a Linux server, and the DP information hasn''t gone public - then we''ll make our own packet-streamer and two implementations (windows & linux).

Magmai Kai Holmlor
- The disgruntled & disillusioned

Share this post


Link to post
Share on other sites
After reading this entire thread, I noticed that everyone seemed intent that DirectPlay was just a wrapper around Winsock. DirectPlay is a lot more than just a Winsock wrapper. It provides abstract access to IPX, modem, serial and direct cable connections as well as TCP/IP with no visible difference to the application. The application does not care what piece of hardware is being used to carry the communication. DirectPlay also offers a lot more services than just communication over many different providers. It has lobby services, groups and host migration to name a few. Sure these could be implemented in your Winsock-based network system, but you would be spending a great deal of time, money and resources re-inventing the wheel.

Implementing DirectPlay may restrict you to using Windows, but that is not such a bad thing, especially in the case of Windows 2000. Linux is over-hyped.


Steve ''Sly'' Williams  Code Monkey  Krome Studios

Share this post


Link to post
Share on other sites
quote:
It provides abstract access to IPX, modem, serial and direct cable connections as well as TCP/IP with no visible difference to the application.


I believe WinSock does too !

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yeah winsock2 does the device independence for Dplay, and Dplay hooks into existing win32 functions which provide other capablilites (HTTP streams, FTP, security etc..) Though i may be wrong about that.

-ddn

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster

Yeah winsock2 does the device independence for Dplay, and Dplay hooks into existing win32 functions which provide other capablilites (HTTP streams, FTP, security etc..) Though i may be wrong about that.

-ddn




In fact, Winsock2 doesn''t do the device independence for DirectPlay. Winsock2 isn''t supported on legacy OS''s like Win95, and therefore can''t be relied upon. The service providers do the device abstraction for the DirectPlay core layer.

Also, DPlay doesn''t hook into the other the existing WinInet functionality for HTTP streams, FTP, security, etc. In fact, DPlay8 doesn''t support HTTP streams, FTP, or security, etc.

Share this post


Link to post
Share on other sites

This topic is 6507 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!