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

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

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

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.