Das deutsche QBasic- und FreeBASIC-Forum

[Progger_X]

Hallo!

Ich habe mal wieder versucht, ein kleines Netzwerkspiel zu schreiben. Diesmal hab ich mal etwas leichteres versucht, so eine Art die Stämme oder so, bloß halt derzeitig für 2 Spieler.

Hier ist der Code:

[psygate]

ich hab jetzt das ding nciht genau gelesen... aber, ich hätte da was:

1. Hatst du eine sperre eingebaut, dass wenn man nicht genug gold für einen krieger hat, auch keinen mehr bauen kann?
2. Hast du eien Sperre eingebaut, dass die GOld-Werte nicht negativ werden können?

[Progger_X]

Jap, habe ich:

[MisterD]

das hatt ich auch mal.. so beim 340sten Inkey mit Inhalt ist mir mein Programm jedes mal einfach weggebrochen ohne das ich die chance hatte, irgendwelche Fehler abzufangen. Da is irgend ein Bug drin den man aber mal wieder nich genau loklisieren kann..
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[Progger_X]

Und wie kann ich das beseitigen?
(außer Maussteuerung)

[tilli]

Moin,

kleiner Tipp: (weis ich auch nur, weil ich es heute gelesen habe):

In der Referenz für Multikey steht:

[Michael712]

Oder man macht einen thread, in dem dann die ganze zeit inkey$ abgefragt wird. Denn ich bin mir nicht sicher, aber wenn man das in der hauptschleife hat, könnte dadurch das Programm dann nicht stehen bleiben, wenn man eine taste durchdrückt?

Michael
_________________

[Progger_X]

Das mache ich ja, den Tastaturpuffer mit INKEY$ leeren.

Wenn ich den jedoch in nem thread leere, dann hab ich ja nix mehr zum auslesen für MULTIKEY.

Ja, durch den code von Tilli würde das Programm so lange angehalten werden, bis keine Taste gedrückt wird.

Irgendwie muss es da eine andere Möglichkeit geben, den Tastaturpuffer zu leeren(ohne INKEY$)

[MisterD]

doch, das müsste auch in nem extra thread funktionieren, multikey ist ja eigentlich nicht von inkey abhängig sondern andersrum..
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[tilli]

Moin,

Ich weis nicht genau, wie die multikeyroutine eingebundenist, aber wenn sie parallel zum Tastaturpuffer arbeitet, was sie eigentlich müsste,wenn sie richtig eingearbeitet ist, wovon ich ausgehe, und das ist wieder so ein Bandwurmsatz ... DMD ...
Also: Wenn es so ist, wie ich vermute, dann ist die Tastaturpufferroutine(inkey$) parallel zu der Tastaturstaturroutine(multikey) angeordnet.
Multikey kann ja nur den aktuellen Status wiedergeben, wohingegen inkey$ wenn nötig 5 Stunden und mehr Zwischenspeichert, aber halt nur soviel wie in den Tastaturpuffer reingeht - könnte 256 Zeichen sein(würde etwa mit den 340 von MrD übereinstimmen, ist aber eine 2er Potenz und damit von Programmierern wahrscheinlicher gewählt).
Möglich auch, dass Windoof das erkennt und den Puffer autokratisch leert.

zudem steht es in der Anleitung (wer auch immer die ursprünglich verfasst hat.)
Ich würde es einfach mal ausprobieren - wenn es das nicht ist, kostet das sicherlich weniger Zeit, als wenn wir weiter diskutieren ... :

CU2
Tilli

[MisterD]

ne stimmt bestimmt ned überein. Das könnte zwar grob hinkommen, aber ich hab den tastaturpuffer erstens dauernd abgefragt, der lief in ner dauerschleife (Taste=nächtes Bild, 350 oder so gabs und um 340 rum is er immer abgeschissen. Er hat aber auch nicht bei jedem drücken weitergeschaltet sonder manche tasten verschluckt...). Also damit hat das mMn nichts zu tun.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra

[tilli]

Moin,

tut mir leid, dass es nicht funktioniert.
Mir kam da noach eine Idee - bezüglich der Verbindungen - die sind hoffentlich geschlossen, nachdem sie geöffnet wurden (ich kann das aus dem Code jetzt nicht so genau herauslesen)... Ich kam drauf, weil auch das eventuell einen Puffer an möglichen geöffneten Verbindungen füllen könnte, der dann überläuft ... allerdings ist das jetzt eher im Bereich Spekulation unterzubringen, da ich mich mit sowas bisher nicht beschäftigt habe.(die "sock = ..." Zeile steht kommentiert als 'TCP-Verbindung öffnen - ein Schließen sehe ich aber nicht)

Was mir am Code Auffällt, ist, dass ide Variablen nicht zwangsläufig zwischengespeichert werden, bzw die Variablenadressen nicht eindeutig sein müssen.(es sei denn da gibt es wieder irgendeien Schalter für)
->
Ich würde mal versuchen die Variablen - speziell jene der sub "connect"- entweder extern shared oder static zu definieren - ansonsten ist es prinzipiell möglich, dass sie sich vom Speicherplatz her überlagern - was dann passieren kann weis sicherlich nicht einmal der big Papa in Rom

Aber bitte nicht böse sein, wenn es das nicht ist ...

CU2
Tilli

------------
never give up

[Progger_X]

Das ist es mit sicherheit nicht, denn der Code stürzt auch ohne Netzwerk part ab:

[Eastler_dart]

Hm. Heißes Thema habt Ihr hier

Auch wenn ich mit den Multikey-Befehl nicht benutze,
- oder vielleicht auch grad deswegen -,
hab ich dein Listing mal an mein FreeBasic 0.14 Win
verfüttert.

hihi, jetzt weiß ich endlich, wie die in "die Stämme" hochzählen.
Hatte mir noch nie Gedanken drüber gemacht.

Aber jetzt mal im Ernst, was mir so auffällt:

paar mal Goldmine gebaut, mich ans Prog gewöhnt,
dann mitgerechnet.
Uaahhhh, der rechnet ja falsch!
hat über 1000 Einheiten Gold, will fünfhundertungrad
um die Miene auszubauen und hat danach nur noch
n paar einzelne Goldeinheiten. Puhh. Eigentlich
sollten so um die 500 noch da sein.

Listing Buchstabe für Buchstabe kontrolliert.
kein Fehler fällt auf.

Logischer Ablauf gecheckt: aha, das könnts sein:
es wird erst die Mine gebaut und danach
das neueste Ergebnis angezeigt.
hm.
Also die beiden Befehle
GOSUB tasten und GOSUB bildschirm in der Reihenfolge
getauscht. Also erst Ergebnis Anzeigen, und wenn das dann
auf dem Monitor steht, nach ner Taste fragen.

Neu Compiliert und wieder testen.
Wieder so n durcheinander, manchmal stimmts einfach
net, wenn man nachrechnet. Geht aber alles auch so
schnell mit dem Weiterzählen des Goldbestandes.

Den Zeitfaktor rausgehauen und durch manuelles
Space-Drücken per Inkey$ ersetzt.
Nun bleibt Goldbestand stehen, bis ich Space drücke.
Dann wars zu erkennen:
Nix Rechenfehler, sondern DOPPELFUNKTION.
Bei zu lang gedrückter "1" (millisekunden) und genügend Goldbestand
hat das Prog gleich 2 mal die Mine erweitert!

So. Weiterdenken.
Diesen Umstand wirst du ja deinen Prog-Nutzern nicht
zumunten wollen. Hm.
Gibt ja dazu 2 Wege.
1) Bleib bei Multikey und fang dahinter per

[Progger_X]

Hi!

Danke, du hast mir schon sehr geholfen. Ich dachte immer, das INKEY$ den Tastaturspeicher vollständig leert.

Problem bei diesem Code

[Eastler_dart]

Hm. Da hab ich mich aber nu wieder weit ausm Fenster gelehnt

wollte schon immer mal wissen, was Ihr mit thread bzw threadcontrol meint, soll heißen, hab keine Ahnung davon.

Aber das ganze erscheint mir dann auch viel zu kompliziert, falls überhaupt eine "simple" Lösung in Threads vorgesehen ist.

Eine Lösung mit wirklich Über-/Durch- blick find ich nur in ner Zählschleife, die nach z.B.500 Tastenanschlägen in einem Stück aus dem Puffer geleert, ne Fehler-/Warn- meldung ausgibt oder aber in dein gewünschtes sicheres Datensenden verzweigt.

Hab die Grundlagen dazu mal mit einem kleinen FreeBasic-Programm getestet:

[Eastler_dart]

Ganz vergessen.

Alles gesagte gilt bei Windows-98SE

Teste das Prog gleich noch unter Linux. Weiß ja nicht, ob du für mehrere Plattformen oder nur für Windows programmierst.

Auch kommt jetzt der Verdacht auf, daß unter WinME oder XP oder NT diese Verhältnisse doch abweichen könnten.

Hallo große weite Welt da draußen! Aufruf
Testet mal alle dieses kleine Programm und gebt eure Erfahrungen hier an. Ist für unzählig viele Fälle bestimmt interessant zu wissen, ob so ein Tastaturpufferleerer (? blödes Wort) überall und immer läuft.

Bis dahin, Euer Eastler
_________________
Kaum macht mans richtig, schon geht's

[Progger_X]

Also.

Der langsamste Anzunehmende PC hat 100 Mhz und 32 MB-R bzw. 133 Mhz und 16 MB-R. Auf denen sollte es auch funktionieren.

Auf meinem Porsche Rechner kommt immer 1. Aber wenn ich das richtig nachvollzogen hab, hieße das, dass bei mir der Fehler nicht auftreten sollte. Tut er aber, deshalb denk ich eher, das es was mit dem Programm zu tun hat. Ich hab WindowsXP.

Was ich mit threadcontrol mein...MisterD meinte, man bräuchte das irgendwie, damit die Threads beendet werden.

Ich muss jetzt erstmal offline, weil mein Vater ins Internet will. Ich werd das derweil mal auf den langsameren Rechnern testen.

[tilli]

Moin Ihr beides,

zum Thema Tastaturpuffer: der wird von Windoof beliefert(oder Xni-/-ux) - naja zumindest vom BS halt. Das Betriebssystem bekommt von der Tastatur nur gesagt, was gerade gedrückt ist - nicht mehr - und es muss demnach getimed sein.
Im BS ist eine Zeitvariable(einstellbar? War zumindest mal so ... ), die den Anfang von automatischen Widerholen angibt und eine für die Wiederholgeschwindigkeit. Dasgleiche kann man auch im Bios bewundern - ob das BS das dierekt macht oder vom Bios holt, ist nicht definiert(gibt wohl beides). Da von Threads die Rede war und DOS keine hat, gehe ich mal nicht von DOS aus -> BS.

Es dann eine Verzögerung von ca. 100-300 ms und in Folge ein weitere von - nun einstellbar, aber (Szenario) mehr als 80 Zeichen (eine Normzeile) pro Sekund werden es sicher nicht sein. Gehen wir "worst case" von 100 aus. Daraus ergibt sich 10 ms Zeit von Buchstabe zu Buchstabe. bei 200 MHz(ich habe noch`n 33MHzer MIT COPROZESSOR (dx) - der Läuft auch gut - zumindest hat er das vor 2 Jahren getan ) hätte der Rechner etwa mindestens "wieder worst case" 25 MHz für das Programm über(im Schnitt) - das Bedeutet 250 schritte zum Leeren einer Taste - das sollte eigentlich hinkommen.
Wer Spielen will kann ja das System ein wenig auslasten und was im Hintergrund Laufen lassen (z.B. eine DVD in eine MPG4 CD Wandeln oder so ) dann käme man vielleicht auf mehr Tasten.

Eventuell kann man Ihn ein wenig Überlisten und Ihm eine Reihe verschiedener Tasten hintereinander geben (einmal von Q bis Ü auf der Tastatur)

Aber mal im Ernst - ein schnellerer Rechner sollte niemals nie die tastraturgeschwindigkeit Erhöhen (bei 2000MHz dann etwa 10 zeilen pro Sekunde? )

zum Leeren des Tastaturpuffers geht auch ein :

[Progger_X]

Hi.

Tilli:
Das soll also der Code sein, um die Tasten abzufragen, und dann soll man das in nen thread packen?
Ich seh da keine Veränderung zum vorherigen code, wenn schon müsste man den Tastaturpuffer da drin leeren, und das würde ja zum gleichen Problem führen.

eastler:
Ich habe dein programm getestet, aber sowohl auf 2.8 ghz WinXP, 600 Mhz Win98 SE und 133 Mhz Win98 SE kam 1 raus. Welche FB Version hast du?