[VB] Programmeer/keuze dillemma

[Sponge]

Zoals jullie misschien weten, of misschien ook niet werk ik aan Quadrant Wars, wat een multiplayer spel is, online.

Hier werk ik al aan sinds 1998, en heb sinsdien vele malen code herschreven omdat de netwerk code (interpolatie, extrapolatie) gewoon niet deugde, verder ook verscheiden versies gehad (Direct3DRetained Mode, DirectDraw, Direct3D8, en nu DirectGraphics)

In principe is de multiplayer code nou gewoon goed, (denk ik), heb het met vele packetloss/ping simulaties getest, en het spel bleef toch meestal wel goed. Alles perfect!

Echter, nu komt @Home roet in het feestmaal gooien. Wat bleek naar de eerste tests eind augustus? Ik kon met niemand verbinden, en niemand met mij. Na lange discussies op Troubles@Home blijkt het dus een probleem te zijn met packets<=6 bytes. Ik heb na gevraagd bij Microsoft en het blijkt dus idd dat de derde stap van de DirectPlay8 handshake dus 5 bytes is. probleem!

Nou zijn we bij het volgende gekomen (citaat vergadering 17 oktober 2002)

@Home erkent het probleem. Het wordt veroorzaakt door de software in de kleine comcontrollers van Com21. Het probleem moet zich dan ook in alle kleine subnetten voordoen, dus ook in andere plaatsen dan Borne en Oldenzaal (bijv. Ook Kampen en Franeker). @Home heeft het probleem bij Com21 neergelegd, maar dit lijkt daar geen prioriteit te hebben.

Mja, dat schiet niet op.

Nu zit ik met een dillema.

- Ik kan wachten op DirectX9, daar bestaat het probleem niet in. Echter is het neit zeker dat VB6 met DX9 over weg kan.

- Terug gaan naar DirectPlay7, maar die code was zo verschrikkelijk dat het in DirecTPlay8 helemaal herschrevedn was voor meer dan 64 spelers/computer.

- Newerk code herschrijven dmv. een control, zoals SocketWrench, die minder werk zal zijn dan Winsock control. (of weet iemand redelijk vergelijkbare controls als DirectPlay8?)

Mja, totaal bestaat QW uit meer dan 30k regels code.. wordt heel wat uit pluizen om alle player arrays en netwerk ID's goed te krijgen.. aangezien alle player handling en sessie management nu wel geschreven moeten worden ipv. DirectPlay8 die dat doet.

- ADSL zien te krijgen wat vele malen trager is dan kabel, en eventueel snellere versie is veel duurder dan kabel.

- Gewoon wachten, doe ik toch al sinds eind augustus...

Of gewoon met een nieuw spel bezig.. ik wil het eigenlijk niet, ik wil QW nu toch zo graag af hebben na al die jaren, maar onderhand lijkt een nieuw spel me toch wel leuk tijdens het wachten, maare QW is gewoon m'n levenswerk onderhand. Ontelbare uren zitten erin.

Ik weet het echt niet meer, en ben ook redelijk radeloos...

[.oisyn]

Tja, kan me voorstellen dat je daar behoorlijk gefrustreerd van wordt... Persoonlijk zou ik proberen mijn frustraties bij Com21 neer te leggen, gewoon proberen de prioriteit van het probleem daar omhoog te werken. Schrijf bijvoorbeeld eens een brief, wie weet doen ze er wat aan.

Herschrijven van code is op zich een optie, maar met je code is niets mis (van wat ik uit je verhaal opmaak tenminste ), dus dat zou toch wel zonde zijn

[n0kn0k]

Als je al sinds 1998 bezig bent kun je toch nog wel even wachten op DirectX 9 Overigens is 8.2 ook uit atm, maybe dat die werkt. En Beta9 is natuurlijk uit

De game lijkt me iig leuk om te spelen

[whoami]

n0kn0k schreef op 11 november 2002 @ 08:45:
Als je al sinds 1998 bezig bent kun je toch nog wel even wachten op DirectX 9

Hij zegt niet dat hij niet wil wachten, de TS weet niet zeker of VB6 DX9 ondersteund.

[Verwijderd]

Tis vast heel dom hoor, maar als je minimaal 6 bytes nodig hebt gooi je er toch 6 bytes rommel bij?

[whoami]

Verwijderd schreef op 11 november 2002 @ 10:31:
Tis vast heel dom hoor, maar als je minimaal 6 bytes nodig hebt gooi je er toch 6 bytes rommel bij?

Ik denk niet dat dat zal werken. Dat handshake protocol zal dat pakketje dan niet gaan herkennen of accepteren, waardoor de handshake niet lukt.

[Verwijderd]

Je zou natuurlijk vb.net kunnen gebruiken (als je dat wil natuurlijk). Die kan wel samen met directX9 werken. Maar ja, dan moet je een (iets) andere taal leren en stukken herschrijven

[Squall-sX]

Zoiets zuigt natuurlijk extra fel. Dan stop je vier jaar van je leven in een programma, en dan beslist een Internetprovider en microsoft dat het ineens niet gaat. Moet een harde klap zijn.

Zelf een handshake protocol schrijven is zeker ook uit de boze? Tis een hoop werk, maar als het werkt heb je misschien meer controle over de zaak.

[CyberSnooP]

Ik meen dat er een bepaalde patch was voor DirectPlay, was dat niet 8.2a oid? Misschien is het nuttig om eens te bekijken of bij MS te informeren of die het probleem hebben opgelost. Het lijkt me duidelijk dat jij niet de enige bent met dit probleem dus moet er, vooral bij bedrijven waarvoor dat nog belangrijker is, een oplossing bedacht zijn

[Sponge]

Bedankt voor de replies

Zelf een handshake maken is totaal geen probleem, echter DirectPlay zal toch ook zelf moeten handshaken, dus zelf een handshake maken betekend in principe al de netcode herschrijven. Trouwens DirectPlay is zeer gevoelig als het om bytes meer/minder gaat, zelfs in game gewoon, als je een byte meer gaat lezen dan er eigenlijk is, dan krijg je echt een feest... (of singles ipv. long uit de ontvangen bytearray "trekken")

Ik zal citeren wat iemand van Microsoft vertelde:

That's an interesting discovery regarding the @home routers. If they are
dropping packets of 5 bytes or less, then this would be a problem with the
initial connect handshake, where the third leg is only 4 bytes (the first
two are a bit larger). This problem is solved if *both* sides are running
DirectX9, as the third leg will be 8 bytes long. I should also point out
that there is still a problem if an application sends a 1 byte reliable
message. Since the DirectPlay protocol header is typically 4 bytes, this
will not get through the router, nor will re-tries of this message, which
will eventually cause DirectPlay to determine that the link has gone down.

Hope this helps,

En VS.NET is toch echt zeer anders dan VB6 als het om DirectX e.d. gaat, de huidige code porten zal een zeer lang durige taak zijn...

Ik heb eens gekeken naar die SocketWrench control (die freeware is), en ik zie dat die bytearrays kan versturen, precies zoals er bij DirectPlay gedaan wordt. Eventueel scheelt dat weer een stuk, echter moet de "gaurenteed UDP" en grouping, en ook nog packet prioriteiten geregeld worden, iets waar ik niet echt direct op zit te wachten...

Ik zal overigens nog kijken naar DX8.2, heb sowieso al 8.0a, en 8.1, en ook nog 7 SDK op m'n pc staan. (DirectX7 heeft het probleem niet, maar die DirectPlay7 code is zo verschrikkelijk slecht...)

[Adion]

Ik zou gewoon wachten op DX9, ik denk niet dat dat echt een probleem gaat zijn, en volgens mij gaat het even goed werken in vb als DX8 (tenzij microsoft totaal geen moeite meer in vb6 wil steken, maar dat denk ik niet, toch niet als het enkel gaat om een type library)

[kvdveer]

Misschien is het mogelijk een tunneling connectie op te zetten? een tunnelheader is iets van 4 bytes, dus dat zou het probleem op moeten lossen.
(ik ben niet op de hoogte van de internals van DPlay)

[Sponge]

Unfortunately, there's nothing we (or you) can do to increase the size of
the initial handshake packets without breaking interop. However, if both
sides are running DirectPlay8 in DirectX9.0, then as I said below, the third
leg in the handshake will be 8 bytes, and this problem should go away.

Misschien ben ik dan toch nog gered

[Knutselsmurf]

Misschien een domme vraag van mij, maar het lijkt me dat packets<=6 bytes gewoon toegestaan zijn volgens specificatie. (TCP/IP?). Als het Com21-modem niet volgens deze specificatie werkt, waarom wordt deze hardware dan goedgekeurd? Of wordt er niet gekeken of hardware wel aan de specificaties voldoet?

[Sponge]

IS het ook, er zit echter een defect in de COM21-controllers voor middel grote steden.. en die fout is bekend.

[n0kn0k]

41.6C.6D.61.72 schreef op 13 november 2002 @ 15:27:
[...]


Misschien ben ik dan toch nog gered

En al geprobeerd ? Wel met de 9.0 beta dan

[-DarkShadow-]

VB6 kan zeker wel met DX9 om, maar vb.net is er voor geoptimaliseerd en VB6 wordt waarschijnlijk niet ondersteund in de SDK. Gebruik java! (VB6 werkt wel 3x sneller)