Sorry your browser is not supported!

With the included program, the idea is for the client(s) machine to send to the host program the running screen width, height and the computer number.

Unfortunately the host receives the X & Y width okay, but instead of the terminal number, it receives another copy of the X value.

I'm probably doing something wrong here, but what ?

I don't have to run your program. You are describing exactly what I see as well.

Nick you are doing nothing wrong.

One possible solution of many is to send all three in the same word.

I was thinking that too - might actually be easier in a CSV fixed-length string...

Nope, strings behave very poorly in multi.
Go with memblocks, map everything that you need to send per update into one. If you intend on dial-up internet use, you need to keep the memblock size down to a size that produces bandwidth use of no more than 32Kbps.

ah - okay...
I'll whack this into the bugs forum.

I've been assuming that it is not a DarkBASIC bug, but rather most likely DirectPlay behaviour.

What version of the compiler are you running?

P5

I think it is a bug, because all the data should arrive (got a 100Meg network so no data should be lost).

Why I asked, I was wondering if DX9 with it's underlying changes to DirectPlay had fixed this. Now we know. There's even less reason for me to "upgrade" to creating restricted binaries. DX9 multiplayer works identically to DarkBASIC Classic executables which run on Windows95!!!!!!

There's nothing much new in DirectPlay in DX9 - from the SDK :

New Features in DirectX Graphics
Vertex and pixel shaders now referred to by objects created by Component Object Model (COM) interfaces IDirect3DVShader9 and IDirect3DPShader9.
Vertex streams now created with a declaration.
Changes to vertex shaders and vertex stream declaration binding.
Added a limited form of flow control to version 2.0 vertex shaders.
Added a scissor test.
Added line antialiasing.
Added support for sphere map texture generation mode.
Added support for displacement maps.
Improved device enumeration support.
For more information, see What's New in DirectX Graphics or see each of the components.

New Features in DirectShow
Video Mixing Renderer Filter 9 (VMR-9). This new, redistributable rendering filter is similar in concept and design to the VMR that is available for Microsoft Windows® XP. The VMR-9 is more powerful than the original VMR (now called "VMR-7") because it is fully compatible with the DirectX 9.0 graphics capabilities and it offers improved support for deinterlacing and ProcAmp control (brightness, contrast, hue, and saturation).
New deinterlacing support in DirectX Video Acceleration.
New deinterlacing support in the digital video (DV) decoder filter.
New encoder application programming interface (API) specification: The Encoder API defines a standard, format-neutral way in which software or hardware encoders can communicate with applications and device drivers.
IGetCapabilitiesKey Interface is a new interface that filters can implement to enable applications to query for the filter's capabilities.
Enhancements to the GraphEdit utility.
The digital video disc (DVD) Graph Builder enables applications to use the VMR-9 through the IDvdGraphBuilder::RenderDvdVideoVolume method. The DVD Navigator now supports playback of audio during fast forward; users can now watch a movie at speeds higher than 1x without raising the pitch of the audio track, if the decoder supports this feature.
A new utility program called Profile Enumerator that displays information about Microsoft Windows Mediaâ„¢ system profiles installed on your computer. This program is located in (SDK root)\bin\DXUtils.
AVStream driver development and runtime support on all platforms prior to Windows XP has been improved for close functional parity with Windows XP.
New samples.
For more information, see What's New in DirectShow.

New Features in DirectInput
Version 9.0 primarily includes compatibility improvements for DirectInput. There are no API changes.

Note For important information about using IDirectInput8::ConfigureDevices within a Microsoft Direct3D® 9.0 environment, see the IDirectInput8::ConfigureDevices Remarks section.
New Features in DirectPlay
Version 9.0 features include the new interfaces IDirectPlay8ThreadPool and IDP8SimControl, a new service provider for network simulation, and functionality for Windows Powered Pocket PC 2002. For more information, see What's New in DirectPlay.

New Features in DirectSound
The Microsoft DirectSound® API has not been significantly revised for DirectX 9.0. However, many performance enhancements have been implemented. In addition, the following changes have been made.

The maximum frequency of sound buffers has been increased from 100 kHz to 200 kHz, where supported by the operating system. (These higher frequencies are not supported by DirectShow.)
Frequency and effects controls (DSBCAPS_CTRLFREQUENCY and DSBCAPS_CRTLFX) can now be combined on buffers. Combining these flags makes it possible to have Doppler shift on buffers with effects.
Audio formats described by the WAVEFORMATEXTENSIBLE structure are fully supported throughout DirectSound.
The standard effect DMOs can process audio data in WAVE_FORMAT_IEEE_FLOAT format.
The standard effects support parameter curves (when hosted outside of DirectSound) without having to call IMediaObjectInPlace:rocess on them repeatedly in very small increments.
New Features in DirectMusic
The Microsoft DirectMusic® API has not been significantly revised for DirectX 9.0. However, many performance enhancements have been made. The most significant of these is a new low-latency DirectSound sink, which enables DirectMusic to attain much quicker response when using audiopaths that play through the software synthesizer. A large library of DirectMusic styles has been added to the SDK, along with an application for auditioning them. In addition, two new tools have been made available in the \bin\DXUtils\AppWizard folder of the SDK installation:

DMToolWizard.awx is a wizard for creating DirectMusic tools.
AEDMOWiz.awx is a wizard for creating effect DMOs.

This is a very simple user error.

You may only send 1 message from each user at a time. When you send the next message the previous one is deleted.

In your source code you are sending three messages in a row.

The other computer is receiving this and interpreting, but by the time it has interpreted the data it has received the next packet of information.

You should combine your information into one sring or memblock as Heartbone has said, however it is not a bug in DBPro, it's a matter of learning how multiplayer works (within DBPro that is). Good luck.

Ah yes, I forgot that one.

One send per sync.

Shame - I'll have to re-do it... later...

..and it works pretty well now - only problem now is to get the other computers to detect the host computer...

Still a few problems left - with the modifed code, I find that the host only sends one x value out. I think I've got it on one message per sync.

The other thing is that IPX/SPX is used in preference over TCP/IP...

The strange thing is that it works okay when the host and client program are running on the same machine.