Programmierwettbewerb 2: Aaah a snake!

[KaPiTN]

Der interessanteste Punkt scheint mir dieser zu sein:

Spielfeld ist in seiner Größe im Spielbetrieb frei skalierbar

Dabei ist Vergrößern nur eine technische Aufgabe und erfordert keine Entscheidung.

Beim Verkleinern müßte man schon Regeln definieren. Läßt man einen z.B. Mindestspielraum oder erlaubt man z.B. Kontakt, wenn die Bewegungsrichtung es erlaubt?

In diesem Thread ist man frei, aber ansonsten ein schönes Beispiel für eine Entwickler-Arschkarte*. Unklare Vorgabe aber Verantwortung für die Lösung.

* keine Kritik am Thread

Hat jemand vor, dieses Problem zu bearbeiten? Lust auf Gedankenaustausch?

 

[Novgorod]

ich sehe den sinn darin nicht, das in-game machen zu können.. abgesehen davon, dass man eigentlich mit der schlange beschäftigt ist und keine zeit hat, die fenstergröße mit der maus umherzuziehen, bringt das auch fürs spiel nichts außer verwirrung.. man könnte das spiel pausieren und dann die größe ändern, aber dann kann man die größe auch genausogut vor dem spiel festlegen (per ini o.ä.).. zudem wäre jede art von vergleichbarkeit der highscores (challenge o.ä.) dahin..

die implementierung dürfte nicht schwer sein, auch fürs verkleinern, wenn man die regel aufstellt, dass alle gerade auf dem spielfeld angezeigten elemente in die neue spielfeldgröße reinpassen müssen - man kann also nicht beliebig verkleinern, sondern müsste ggf. die schlange erst wegbewegen oder ein futterfeld in einer entfernten ecke leeren.. alles andere wäre eh nicht möglich, weil man dann etweder sofort verloren hätte (schlange außerhalb des spielfelds) oder das nächste futterfeld unerreichbar außerhalb des spielfelds läge..

 

[drfuture]

@KaPiTN: Das ist schon Absicht - aber Cool das mal jemand soweit denkt ;P
Wenn ich exakte Vorgaben gemacht hätte gibt es so oder so die Diskussion um *sinnvoll oder anders eh viel Sinnvoller* ... Das Ziel der einzelnen Punkte war auch nicht Primär ein möglichst interessantes Spiel zu erschaffen - sondern Herausforderungen für die Entwicklung und deren Überlegung dahinter.
Wie du schon richtig Festgestellt hast dürfte vergrößern leichter als verkleinern sein. Wobei es dann noch immer darauf ankommt wie man seine Spiel-Struktur aufbaut und die Felder im Spiel kennzeichnet. Immerhin sollten die Punkte danach auch im neuen Spielbereich auftauchen - und eine Kollision erkannt werden etc. Das heißt mehr oder wenige "alles" muss Dynamisch definiert werden.
Gut mag evtl. so mancher so oder so schon so machen.... aber ja nicht zwingend jeder


@Novgorod:
Ginge ja auch z.B. den Wurm beim ändern der Größe zu pausieren + 3sec danach...
Oder Größenänderung nur im *pause* modus .... usw. Die Punkte sind ja nur Herausforderungen keine maximale Ausbaustufe ... siehe theSplit

 

[theSplit]

@KaPiTN:

Puh, gute Frage.... ich hatte den Punkt total ignoriert bisher - aber eine Idee zur Herangehensweise hätte ich doch schon.

Ist die Schlange am unteren recht Rand zum Beispiel bei 10x10 Feldern auf 8x 7y (ich gehe jetzt nur mal vom Kopf aus) - und das Spielfeld wird auf 20x20 vergrößert - wird die Schlange ebenfalls umpositioniert, auf 20-(10-8) = 18 auf X und 20-(10-7) = 17 in Y.

Wird das Fenster auf 5x5 verkleinert wird die Schlange auch entsprechend bewegt. Hier müsste die Rechnung nur umgestellt werden abs(5 - (10-8)) in X und das gleiche für Y.

So könnte nicht geschummelt werden wenn die Schlange/der Kopf sich am Rand/in einer Ecke befindet.

Was ich natürlich jetzt in die Logik nicht einbezogen haben, das der gesamte Schlangenkörper um X und Y verschoben wird von der aktuellen Position und was mit Schlangenteilen außerhalb des Spielfeldes passiert nach Verkleinerung... Vielleicht Punkteabzug für jedes Schlangenelement außerhalb des Spielfeldrandes, bei Bewegung bzw. vorab einmal kalkuliert?

Ansonsten wüßte ich kein geschicktes Vorgehen ohne den Spieler einzukesseln durch "aufrollen", "umrahmen" et cetera bzw. den Aufbau der Schlange zu verändern - was auch irgendwie zu sehr ins Spielgeschehen eingreifen würde, meiner Meinung nach.

 

[Novgorod]

@theSplit: es muss dennoch eine mindestgröße geben, denn auch mit verschieben (was ziemlich gepfuscht wäre) stößt die schlange irgendwann an einen rand.. futterfelder könnten ggf. einfach neu generiert werden, wenn sie nach verkleinerung außerhalb des spielfelds sind, aber die schlange irgendwie zu verändern beim verkleinern ist mega-pfusch - selbst verschieben geht eigentlich schon zu weit (und wenn überhaupt dann proportional und nicht nach abstand zu irgendeiner ecke)..

 

[theSplit]

@Novgorod
War ja auch nur eine Idee, dass es die beste Lösung für so ein Problem ist, habe ich nicht sagen wollen. Nur spontan würde ich es so lösen...

@all
Spielbares Komplettpaket für Windows ist nun zum Download verfügbar....

Ich habe gerade eine Version für Windows 64 bit kompiliert, das ganze Paket, zum los spielen, befindet sich im Gitlab Repository zum Download.
Link auf eine Seite von Gitlab wo "NGB Gitlab - NGB Snake theSplit v0.91 - 64bit.zip" gedownloaded werden kann

Darin enhalten ist eine Exe so wie sämliche DLLs/Libraries die benötigt werden um das Spiel zu starten, damit entfällt auch das man sich die Bibliotheken zum spielen (nicht kompilieren!) separat downloaden muß.

Vielleicht möchte jemand mal antesten und kann mir eventuell auch gleich Feedback geben ob alles wie gedacht funktioniert - ich hab es nur unter Windows 7 64bit getestet, ob der Code in dieser Form auch unter 32 bit funktioniert weiß ich nicht (habe darüber zu wenig Kenntnisse).
Aber auch so wünsche ich natürlich viel Spaß damit - Please note, this is not the final product and things are likely to change

Unter:
https://gitlab.com/ngb/NGB-Snake_theSplit/tree/master

finden sich neben den Informationen was in dem Paket ist auch eine kurze Beschreibung und eine MakeWin.txt wie man das Spiel mit Mingw unter Windows kompilieren kann (bzw. so wie es bei mir geklappt hat).
Wer schon getestet hat, sollte allerdings nochmal den Code downloaded, ich hab noch zwei Fehler in der Source korrigiert weil man sonst nicht hätte kompilieren können.

 

[drfuture]

Unter windows 10 funzt es - in einem 32bit OS kann eine für x64 Compilerte Anwendung nicht laufen.
Andersrum jedoch schon.... da du mit Überläufen oder Speichernutzung kein Problem haben solltest - solltest du es daher als 32bit Anwendung Compilieren

Sonst Funktioniert das Spiel erst mal sehr schön - war schon auf dem Screenshot Beeindruckt von der Graphik, finde vor allem die "echten" Ecken toll
Im Spiel selber finde ich nur irgendwie das ganze etwas ruckelig... k.a kommt mir irgendwie "gebremst" vor.

Und das allerbeste ... wenn man den Wurm gegen die Wand fahren lässt - und das Spiel dann so stehen lässt - frisst es *etwas* Ram... also zusehends mehr
Bin nach ca. 5min bei 800mb *fg*

 

[theSplit]

Erstmal danke für dein Feedback, gut zu wissen das es auch unter Windows 10 lauffähig ist

Und klasse wenn die Grafik anklang findet, ich bin mit dem Schlangenkopf noch nicht ganz zufrieden, der fast ein gesamtes Feld einnimmt, aber so richtig gut skalieren konnte ich das nicht in Gimp ohne das die Pixelstruktur kaputt geht... wollte den schmaler haben. Aber das ließe sich einfach machen in dem man die Bilder mit seinen eigenen im "gfx" Ordner austauscht. - Dazu ist kein Eingriff in den Code nötig.

Es kann in der Tat etwas ruckeln am Anfang, weil nach jedem "Tick" eine 200 Millisekunden Verzögerung/Pause gemacht wird, sonst wäre das Spiel einfach zu schnell.
Je mehr Äpfel man frisst, desto kürzer wird diese Verzögerung allerdings. Dann muß man auch schneller reagieren, aber das steigert sich nur ganz langsam, ist aber ein Unterschied von fast 1/2 der Zeit am Ende.

Das Speicherproblem sollte so eigentlich nicht passieren... mhh, muß untersuchen..., normalerweise wird alles nach wie vor berechnet was zur Darstellung eines Frames/Ticks benötigt wird, außer das die Bewegung nicht mehr mit berechnet wird und die Counter/Timer nicht mehr weiterlaufen die die Spieldauer erhöhen bzw. Gegenstände platzieren lassen.

 

[drfuture]

Ja hab ja bis ca. 4000 Punkte gespielt

 

[Timon3]

@theSplit: So eine feste Verzögerung ist aber nicht gerade sauber. Berechne doch anhand der Systemzeit am Ende der Logik-Funktion, wie lange gewartet werden muss, dann hast du tatsächlich 200ms und nicht (200ms + Dauer(Funktion)).

 

[theSplit]

@GameChamp98:

Hmm.... gute Idee, klingt logisch. Wenn die Routine jetzt komplexer wäre und man das genaue Timing gewährleisten will macht das defintiv Sinn....

Edit:
Wie mir gerade noch einfällt, ich hab zur Berechnung der Spielzeit "wilden Code" geschrieben, hier könnte ich auch time.h Funktionen für verwenden... - Danke für den Hinweis - werde ich beides umsetzen.

@drfuture:

Da geht aber noch was - Aber das Spielfeld ist vielleicht auch etwas sehr groß geartet...

 

[Novgorod]

@theSplit: läuft problemlos auf win7 x64, aber wie schon gesagt wurde, wäre eine 32bit-version wesentlich kompatibler..

ansonsten ist abgesehen vom memory-leak (~1MB/s ) der einzige echte kritikpunkt das input-handling.. ich weiß nicht, ob du einen buffer benutzt und das abfragen in einen parallelen thread auslagerst (wie in meinem labview-beispiel), aber irgendwas läuft da krumm.. zum einen fühlt es sich so an, als gäbe es ein gewisses zeitfenster (innerhalb eines frames), wann man die eingaben machen muss und zum anderen geht da was schief, wenn man eine pfeiltaste drückt, während man eine andere gedrückt hält .. zum ausprobieren: halte z.b. "nach-oben" gedrückt und tippe dann "nach-rechts" - es passiert nichts.. erst beim zweiten mal "nach-rechts" antippen, biegt die schlange nach rechts ab.. und noch komischer: halte "nach-oben" für ca. 2 sekunden und drücke dann "nach-rechts" (gedrückt halten), während du noch "nach-oben" gedrückt hälst - es dauert ca. 3 frames, bis die schlange nach rechts abbiegt (geht natürlich auch mit allen anderen pfeiltasten-kombinationen).. selbst wenn man versucht zu vermeiden, dass mehrere tasten gleichzeitig gedrückt werden, macht das schnelle 180°-turns oder combos zur glückssache.. ich habe auch ausprobiert, die pfeiltasten so schnell nacheinander anzutippen, dass garantiert keine gleichzeitig gedrückt waren und trotzdem hat er eingaben verschluckt - das führt mich wieder zurück zum zeitfenster, es sieht nämlich so aus, dass nur eine eingabe pro frame erlaubt/ausgewertet wird und kein buffer o.ä. im hintergrund die eingaben sammelt, so dass das aktuelle frame immer die aktuellste eingabe bekommt (selbst wenn der buffer nur ein element hat)..

und noch eine kleinigkeit.. ich weiß nicht, ob das ein fehler in der kollisionsdetektion oder im rendering ist, aber wenn die schlange sich genau in den schwanz beißt, sieht es so aus:

wenn ich es richtig in erinnerung habe, ist das nur ein gfx-bug, d.h. nach der kollision läuft es noch ein frame weiter, deshalb ist das kopf-feld nicht mehr auf dem schwanz-feld..

 

[theSplit]

@Novgorod:

Also das du keine Richtungstasten parallel gedrückt halten kannst und ausführst, liegt daran das die Steuerung die erste Richtung die du drückst "einloggt" - danach sind in diesem Frame keine Bewegungen mehr für diesen Frame mehr möglich. Es geht also unterm Strich nichts verloren. Nur war das eine Designentscheidung um zu verhinden das der Spieler panisch seine Richtung korrigiert.

Man könnte es so machen das man den Kopf steuern kann wie will, aber das hätte im Umkehrschluß zur Folge das der Spieler zu schnell steuert und dann in der Schlange landet weil der nächste Frame noch nicht berechnet wurde, man greift also der restlichen Logik einen Schritt vor.

Weiteres Problem dabei, das läuft alles in einem Thread und nicht in zweien.

Nur habe ich auch gemerkt das es sich etwas träge anfühlt wenn man korrigieren will, aber das ist weil die Schlange nicht in Echtzeit kontrolliert wird - was ich mir vorstellen kann, es gibt ein 200 Millisekunden Delay/Verzögerung - das ist quasi ein "toter Winkel" in dem die Anwendung für diesen Millisekunden Bereich pausiert wird, damit das Spiel "normal" ablaufen kann - es ist aktuell keine Begrenzung auf Frames pro Sekunde oder änhliches implementiert.

Im Ablauf sieht das so aus:
1) Abfangen der Tastatur / Fenster Events in einer Schleife, aber nur der erste Input wird für die Steuerung gewertet (SDL2 übernimmt das Event Queueing für die Tasten/Events)
2) Bewegung der Schlange bzw. Erweiterung
3) Puffer für das Rendering von Spielfeld, Schlange, Items
4) Rendering
5) Pause von 200 Millisekungen (minimal 125 ms) (Wie die Steuerung in dieser Pause bearbeitet wird weiß ich nicht, das habe ich nicht getestet, ginge aber einfach das zu Überprüfen)
6) Zurück zu schritt 1)


Zum Screenshot, da hast du völlig recht, ich weiß aber auch schon wo das Problem liegt. Wie du richtig sagst wird hierbei ein Frame berechnet, aber die Reihenfolge ist unlogisch gesetzt...

Im Code ist die Kollisionserkennung in Zeile 516, diese feuert aber schon bevor die Schlange ihre Bewegung abgeschlossen hat. Es wird also zu früh abgefragt ob die Schlange sich beißt, noch bevor die anderen Teile (außer dem Kopf) bewegt/aktualisiert worden sind. Also mit andereren Worten - neue Kopf Position, aber veraltetes Schwanzsegment.


Bezüglich des Memory Leaks, unter Linux kann ich außer das SDL2 Memory leaked leider nichts feststellen, aber das kommt erst beim Shutdown obwohl alle Ressourcen entladen werden die das Spiel verwendet.

Mit was hast du die Memory Leaks unter Windows detektiert?

 

[Novgorod]

mit dem taskmanager .. man sieht ganz klar, dass der acquirierte RAM immer weiter anwächst.. das passiert auch während des spiels, nur langsamer (evtl. wegen der 200ms pausen?).. erst wenn die "all snapped" meldung kommt (spiel vorbei), wächst der RAM-bedarf mit ca. 1MB/s.. werden da evtl. die bitmaps bei jedem frame irgendwohin gebuffert und nie gelöscht?

zu den tasten: das mit dem parallelen drücken müsste trotzdem ein "bug" sein bzw. unerwünscht, weil die tasten-events eigentlich nur ausgelöst werden sollen, wenn eine taste gedrückt wird, also von "off" zu "on" wechselt ("onKeyDown" oder so) und nicht wenn eine taste ein paar frames zuvor gedrückt wurde und im neuen frame noch "on" ist.. in dem fall ist es ein falsch definiertes event, denn du willst ja nicht abfragen, welche tasten in diesem frame gerade "on" sind, sondern welche taste in diesem frame zuerst gedrückt wurde (d.h. von "off" zu "on" wechselt).. kannst du denn die tasten-events entsprechend filtern/anpassen?

zu den parallelen threads: ich hatte das ganz am anfang auch alles in einem thread sequentiell (erst tasten abfragen, dann schlange zeichnen usw.) und die steuerung war kacke.. daher habe ich alles was mit UI zu tun hat (tasten, klicks, werte eingeben) in einen parallelen thread ausgelagert - probier mein beispiel aus und sieh den unterschied .. vom spieldesign her ist es nur vorteilhaft, wenn der spieler "panisch" die eingaben ändern kann, weil das maximale reaktivität garantiert.. in deinem ablaufschema entfiele dann punkt 1 und in punkt 2 schaut das programm beim bewegen der schlange in den input-buffer, was gerade der letzte tastendruck war und ändert dann die richtung der schlange - und das geschieht natürlich nur einmal pro frame zu einem bestimmten zeitpunkt.. bis zu diesem zeitpunkt kann man seine eingabe aber noch ändern - darum kümmert sich ein paralleler thread, der die events abfängt/filtert und den input-buffer mit der zuletzt gedrückten taste füttert (FIFO-buffer/queue mit z.b. nur einem element; ich hab ihn glaub ich 2 oder 3 elemente groß gemacht für coole combos ).. die hauptschleife, die die schlange zeichnet, kriegt von all dem nichts mit, sondern liest nur den aktuellsten tastendruck aus dem buffer.. da der parallele thread um ein vielfaches schneller laufen kann (schnelles polling oder eben "beliebig" schnell event-gesteuert), bekommt man trotz geringer framerate der schlange eine extrem gute zeitauflösung für die eingaben hin.. ich weiß natürlich nicht, wieviel aufwand das ist, parallele schleifen in C zu implementieren (in labview ist das mehr oder weniger trivial)..

 

[theSplit]

Morgen,

vielen Dank für euer Feedback. Ich hab gestern Nacht das meiste der Vorschläge umgesetzt.

Changelog Auszug 30.09.2015:

Spoiler

[src=text]30.09.2015
- Moved snake head collission detection to check after all snake parts have
been calculated (THX Novgorod for reporting)

- Added check if a direction key was still pressed in new frame, ignoring the
direction key if current making the snake much more responsive
(THX Novgorod for suggestion)

- Resolved high memory allocation coming from UI which was the result of dynamically
created textures from surfaces which were not freed and surfaces beeing not
released properly even so becoming newly assigned
(THX DrFuture and Novgorod for reporting)

- Playtime is now calculated using time.h time functions instead of calculation
(THX gamechamp98 for the feedback)

- Minor code cleanups and corrections regarding to ressource freeing[/src]

Einzig allein die Idee, die Wartezeit für den nächsten Frame auf 200 ms - "CodeTime" zu berechnen ist noch nicht enthalten.

Die Steuerung wurde aber, dank des Feedbacks hier, verbessert.

Die neue EXE (Update) kann zusätzlich zu der Basis Version in den Builds heruntergeladen werden.
Diese finden sich hier:
https://gitlab.com/ngb/NGB-Snake_theSplit/tree/master/builds

@Novgorod
Deinen Denkanstoß habe ich mal weiter verfolgt. Es war schon so das ein Tastendruck die Steuerung für andere Tasten gesperrt hat, allerdings hat der Keydown mehrmals gefeuert - jetzt ist es so, ist die Richtung Links eingetippt und die Schlange steuert links, wird die Tastensperre nicht mehr aktiviert.

Damit kannst du jetzt auch eine Taste gedrückt halten und dennoch mit einer anderen umsteuern wenn sie einen "Keydown" auslöst - ein Keyup zu verwenden macht hierbei wirklich keinen Sinn weil die Schleife selbst mit 200 ms Verzögerung für jeden Frame viel zu schnell läuft.

Das ganze in separate Threads auszulagern halte ich aber für nicht sinnvoll, das wäre für den Anwendungsfall einfach ein Overkill und zumal queued SDL mehrere Events in seiner EventQueue transportiert wovon die erste andere Richtung genutzt wird. Das ganze passiert innerhalb von Bruchteilen von Millisekunden.

 

[Novgorod]

viel besser
dass pro frame nur die erste tasteneingabe genommen wird und alle späteren geblockt werden, verhindert aber immernoch schnelle kombos, sondern man muss seine eingaben genau mit den frames timen - könnte man auch als gewolltes "feature" (bzw. challenge) verstehen, ich bin's nur halt gewohnt, dass zumindest 2 eingaben pro frame erlaubt sind, von denen die erste direkt im frame ausgeführt und die zweite in den nächsten frame "mitgenommen" wird.. ich wüsste allerdings auch nicht, wie man das "simpel" (also ohne parallelen UI-thread) lösen könnte..

 

[theSplit]

Guten Morgen

@Novgorod:

Schön zu hören das es dir nun besser gefällt und danke fürs testen

Um dich etwas zu beruhigen, wenn ich SDLs Event Queue richtig verstehe, werden die Tastendrücke auch während des Renderings + Verzögerung auf einen Stapel der Events gelegt - also alles was ans Fenster gesendet wird an User Input.

Dieser Stapel wird dann nacheinander abgearbeitet noch bevor der nächste Frame berechnet wird und da hab ich es derzeit so das die erste "andere" Richtungstaste zählt. - Es wäre also nicht so das ein Tastendruck verlorengeht, es können beliebig viele Tasten gedrückt werden - nur habe ich es darauf beschränkt das die erste "andere Richtungstaste" zählt die weder die aktuelle Richtung noch die entgegengesetzte ist, um sich nicht selbst zu beißen durch eine 180 Grad Drehung.

 

[Novgorod]

ok, dann läuft diese event queue ja offenbar schon in einem parallelen thread .. kannst du dann nicht einfach pro frame das älteste event (FIFO-mäßig) aus dieser queue entfernen bzw. als richtungswechsel verarbeiten und alle anderen events drin lassen, die dann vom nächsten frame (bzw. frames) verarbeitet werden? natürlich sollte dieser tasten-event-buffer nicht beliebig lang werden, so dass die nächsten 100 frames automatisch ablaufen - dazu kann man sicherlich eine maximale buffergröße einstellen (2-3 elemente sind sinnvoll)..

 

[theSplit]

Also ich glaube das was du gerade vorschlägst würde das ganze unnötig verkomplizieren.

Das Spiel lebt ja davon das die Eingaben dann erfolgen wenn Sie gemacht werden sollen und gerade eben nicht von einem Stapel abgearbeitet werden - so könntest du eine Kombo wie "Links Oben Link Unten" einprogrammieren und müsstest dann nur darauf warten das die Schlange das ausführt. Auch wäre die Frage wie dann neue Eingaben verarbeitet werden sollen? Du hast ne Queue von X Eingaben, und willst mittendrin deine Meinung ändern - geht aber nicht mehr weil deine Queue noch für Y viele Eingaben vorgepuffert ist.

Das ganze wird jetzt noch schlimmer wenn du eine Taste gedrückt hälst (links), eine andere Richtung als die aktuelle einschlägst (oben) aber die Taste links nicht losgelassen hättest, sobald die neue Richtung auf dem Stapel "oben" auf den Stapel kommt könnte man die Taste Links auch "wieder" zählen - nur war das jetzt beabsichtigt oder doch einfach nur eine Fehleingabe. Und mit der Batch an Richtungsänderungen könntest du nicht mal reagieren um entgegenzusteuern.

Es sei den man gibt den Tastenanschlägen ein Zeitfenster in dem sie wirken, das wäre allerdings für den Spieler etwas mißverständlich, weil man dann immer rätseln müsste, wird das jetzt noch ausgeführt oder nicht? Und wenn du dann gegensteuerst, war das beabsichtigt und soll das die aktive Richtung ändern oder die gewählte Queue erst ausgeführt werden?

Ich hoffe ich hab die Problematik gut genug beschrieben, die meiner Meinung nach damit auftritt, wenn man einen Befehlspuffer aufbaut.

 

[Novgorod]

das mit dem gedrückt halten ist kein problem - es kommen ja nur "key-down" events in den buffer.. ansonsten ist es eben eine sache der präferenz bzw. challenge.. wenigstens 2 buffer-elemente sind nötig, um unkompliziert schnelle 180°-turns zu machen, die ohne den buffer zur glückssache werden (ja, das kann auch gewollt sein, ist dann ein anderer "flavor").. wenn man es schafft innerhalb eines einzigen frames 10 mal seine meinung zu ändern, dann sollte sogar das für den buffer kein problem sein - er hält nur die letzten 2-3 eingaben und ältere eingaben werden rausgeschmissen, bevor der nächste frame sie abarbeitet (FIFO).. wenn ich noch ein update meiner version machen sollte, dann mache ich die buffergröße per ini-file anpasspar (1 bis n elemente), dann kann man schauen wie sich das aufs spiel auswirkt..