Du verstehst da vielleicht was falsch. "String" bedeutet einfach nur "Zeichenfolge". Jeglicher Text liegt im Spiel in Stringform vor. Mit "Word-Wrap-Funktion" meinte ich die Funktion, die automatisch Zeilenabsätze vor einem Wort einfügt, um zu verhindern, dass es in der Mitte getrennt wird. Das hier sind also String-Funktionen, die eine Word-Wrap-Funktion enthalten. Mit meinem Post wollte ich nur ausdrücken, dass Word-Wrap-Funktionen ziemlich kompliziert zu programmieren sind und ich deshalb so lange gebraucht habe.

da hab ich wohl leicht was falsch verstanden, aber danke für die Aufklärung

Habe wieder eine kleinere Änderung am Programm vorgenommen. Damit ist es mir möglich, das Konsolenfenster zu verstecken. Gleichzeitig kann ich Fehlermeldungen nun über ein neues Windows-Fenster anzeigen lassen, was die Beschränkung auf ASCII-Zeichen aufhebt.

Sowohl Umlaute...


...als auch japanischer Text...


...funktionieren somit einwandfrei. Vorher waren Fehlermeldungen nur ein unlesbarer Zeichenbrei.

Penis heißt auf Japanisch NICHT penisu!

Das 2te Fenster war davor noch auf Deutsch. So leicht wird es nicht das zu verheimlichen RPG ^^

Google zufolge schon. Außerdem gibt es im Japanischen doch eh tausend Worte für alles.



Also komm, ich habe das innerhalb einer Minute editiert. Du kannst doch wohl nicht so schnell sein. 0_o

Doch ich habs genau gesehen und wollte schon schreiben das das nicht "schlitzaugisch" ist und hab es dann gelassen weil ich dachte das ich etwas falsch verstanden habe.

HURRA! Es geht langsam wieder voran. Habe jetzt die Anzeige von beliebig vielen Layers gecodet. Muss noch ein bisschen dran rumwerkeln, damit der Alpha-Blender funktioniert. Somit könnten 32-Bit-Bitmaps mit Transparenz angezeigt und somit ganz leicht Farb-Effekt angezeigt werden, die in etwa wie HDMA-Effekte aussehen. Normale Transparenz funktioniert schon. 32-Bit-Bitmaps haben aber den Vorteil, dass jeder Pixel seinen eigenen Transparenz-Wert hat.

Horny!

Geil!

Hey, hey, hey.

Sind Tilemaps und Interaktion schon drin oder ist der Boden nur ein einziges großes Bild?

Kollision ist noch nicht mit drin, ist aber schon anhand von Konzepten weitestgehend durchgedacht und wird als nächstes eingebaut. Was allerdings schon mit drin ist, ist Scrolling. Dabei kann man die Geschwindigkeit für jeden Layer beliebig einstellen. Außerdem kann man den Bildschirm an jeder beliebigen Stelle im Level positionieren, unabhängig von Waluigis Position. Das kann man später zum Beispiel für Level-Gimmicks nutzen. Hätte man zum Beispiel so einen Draufstell-Schalter wie in Zelda-Spielen, könnte man für ein paar Sekunden die Kamera auf eine geöffnete Tür oder sowas richten und dann wieder zu Waluigi zurückspringen. Nur mal als Beispiel. Es muss schlussendlich ja nicht genutzt werden, falls es nicht gebraucht wird.

Geil, es geht ja echt Vorran!
Gefällt mir wenn man Updates dazu liest =)

Nun auch mit Alpha-Kanal-Unterstützung!



Musste es lediglich als TGA statt als BMP speichern. Damit kann man jetzt, indem man einen Layer hinzufügt, ganz leicht solche Farbeffekte, die sehr an HDMA erinnern, erzeugen.

Wirklich sehr sehr toll, schon solche Fortschritte von Dir zu sehen!
Sieht meiner Meinung nach schon ziemlich gut aus.

pure epicness hehe weiter so das sieht sehr hammer aus

Kein neues Feature seit dem letzten Post, ich habe aber mal bisschen mit TGAs rumgespielt. Damit kann man schon ein paar wirklich schöne Sachen machen. Das hier würde gut zu irgendeiner Parallel-Dimension oder so passen. Außerdem habe ich mal zum Spaß Level 105 verwendet.

Meine größte Sorge bisher ist übrigens die Performance. Das Problem hier ist, dass Allegro.pas nunmal nicht komplett in Pascal geschrieben ist. Ich vermute, dass das die Sache schonmal etwas langsamer macht. Darüber hinaus weiß ich nicht, inwiefern Allegro.pas mit der Grafikkarte zusammenarbeit um, zum Beispiel, Hardwarebeschleunigung oder sowas zu nutzen.

Ich habe leider keine Quellen, wo ich mich erkundigen könnte. Die Library scheint nicht sehr verbreitet zu sein (um nicht zu sagen, dass wirklich niemand die nutzt). Habe im Internet nur einen gefunden, der damit gearbeitet hat und mir sagte, dass man, sofern das Spiel simpel bleibt, damit durchaus unproblematisch arbeiten könnte. Bei vielen Rotationen aber zum Beispiel könnte es durchaus schonmal Slowdowns geben, da Allegro.pas, so seine Worte, kein OpenGL nutze. Er hat alllerdings schon vor längerer Zeit damit gearbeitet und ich weiß nicht, was sich mittlerweile alles getan hat. Mittlerweile könnte, glaube ich, sogar schon OpenGL drin sein. Mir ist heute auch schon aufgefallen, dass bestimmte Transparenz-Blender die Framerate locker auf 50 runterdrücken können. Allerdings waren das Blender, die ich wohl eh niemals nutzen werde, da sich mir, bisher, der Sinn von ihnen noch nicht erschließt.

Insgesamt soll das Spiel ja, was Effekte und so angeht, sowieso recht simpel bleiben, deswegen hoffe ich mal, dass die Framerate, selbst wenn die ganzen Sprites und Kollisionen dazukommen, immer noch hoch bleibt. Solange sie bei mindestens 50 bleibt (momentan laufen bei mir problemlos 85), ist es OK, da das Spiel selbst auch nur auf 50 FPS läuft.

Ich habe im Internet noch eine weitere Game Library für Pascal gefunden, die scheinbar sehr viel weiter verbreitet ist (SDL). Sie ist komplett in Pascal geschrieben. Deshalb gehe ich auch davon aus, dass die moderner und schneller ist. Außerdem scheint sie sich, von der Programmierung her, nicht komplett von Allegro zu unterscheiden. Dadurch, dass sie in Pascal-geschrieben ist, ist sie auch Platform-unabhängig. Jedenfalls: Falls sich später herausstellen sollte, dass Allegro.pas tatsächlich zu langsam ist, könnte ich wahrscheinlich noch nach SDL porten und hätte somit ein Notfallkissen. Hoffe aber, dass das nicht nötig sein wird. Wäre wieder nur Zusatzaufwand, auf den ich keine Lust habe.

Hier mal eine Vorschau vom Tileset-Format:



Habe lange drüber nachgedacht, wie ich Tilemap-Layer schlussendlich realisieren werde, insbesondere im Bezug auf Animationen. Heute hatte ich dann endlich eine geniale Idee, die auch noch relativ leicht umzusetzbar sein dürfte. Die Hauptinnovation bei diesem Tileset lässt sich auf dem ersten Blick nicht erkennen, sondern erst, wenn man nahe ranzoomt. Dann erkennt man nämlich die schwarzen Punkte auf diesen gelben Linien, jeweils immer links von den Tiles. Über diese Punkte kann man direkt die Animationseinstellungen aus dem Tileset herauslesen.

Ich habe mich heute daran erinnert, dass Allegro eine Funktion namens "getpixel" hat, die einem, von einem beliebigen Pixel in einem Bitmap, den Farbwert liefert. Anschließend kann man daraus auch noch die Rot-, Grün- und Blau-Werte extrahieren. Diese Funktion werde ich mir zu Nutze machen. Ich habe geplant, dass man nachher über den Rot-Wert angeben kann, wie viele Tiles (-1) die Animation hat und über den Grün-Wert, nach wie vielen Frames das Tile zur nächsten Grafiken springen soll. Der Blau-Wert ist bisher noch ohne Funktion, wird aber evtl. nachher dafür genutzt, um anzugeben, in welches Tile sich bestimmte Tiles verwandeln sollen. So könnten sich zum Beispiel Fragezeichblöcke, unabhängig von der Position des braunen Blocks auf dem Tileset, immer in die richtige Grafik verwandeln. Bin mir da aber noch nicht sicher, denn meine Tilemaps sollen nachher 65536 verschiedene Tiles unterstützen, während der Blau-Wert nur bis 255 geht. Die Tilesets sind übrigens nach unten hin nicht beschränkt (bzw. nur durch das Limit von 65536 Tiles). Solange man immer nur 16 Tiles in eine Reihe packt und die Breiten- und Positionsvorgaben berücksichtigt, kann man beliebig große Tilesets verwenden.

Von der Programmierung her - aber das interssiert euch vielleicht eher weniger - werde ich, anders als anfangs geplant, wohl nicht die Layer bei Levelstart nur einmal komplett aufbauen lassen, sondern jede Frame neu und dafür nur den auf dem Bildschirm sichtbaren Teil. Durch dieses System werden Animatonen überhaupt erst möglich (oder sind zumindest sehr viel leichter und sparen Speicherplatz). Außerdem lassen sich so einzelne Tiles nachher leichter verändern (wenn man zum Beispiel Münzen sammelt oder einen Fragezeichenblock anspringt).

Ferner werde ich "Grafik-Tilemaps" und "Kollisions-Tilemaps" trennen, sodass jeder Grafik jedes beliebige Verhalten zugeteilt werden kann. Das verbraucht zwar dann mehr Speicherplatz, aber ich denke 4 Bytes pro Tile sind im heutigen Zeitalter auch nicht nenneswert. Könnte sogar noch mehr belegen und dann das Limit von 65536 Tiles springen, allerdings sind das jawohl schon mehr Tiles als im ganzen Spiel jemals gleichzeitig benötigt werden. Ein Beispiel, für was das nützlich sein könnte: Man könnte Powerups in beliebigen Blöcken verstecken, könnte Lava mit Wasser-Eigenschaften machen und ähnliches. Für das alles müsste man nicht - wie zur Zeit mit Lunar Magic - immer erst lästig über Map16 neue Blöcke mit speziellem Verhalten zusammenbauen.

Ich denke, das war's erstmal. Bisher alles noch nicht programmiert, aber Planung ist ja bekanntlich das A und O und erstmal durchgeplant lässt sich das relativ schnell umsetzen. Muss nur noch versuchen, das möglichst Speicherplatz-sparend zu programmieren. Hoffe auch, dass dieses "jede Frame neu aufbauen" nicht zu Performance-lastig wird. Habe meine Sorgen bezüglich der Performance ja schon im letzten Post angesprochen. Jedenfalls sollte es in den nächsten Tagen ein neues Update geben. Vielleicht mal wieder eine Binary, in der dann die Karten ingame mit Animation und allem drum und dran bestaunt werden können.

Das hört sich mit den Animationen ja komplizierter an als man zunächst denkt...
Aber finde es sehr gut das du eine Lösung gefunden hast =)

OK, bezüglich Performance-Verlust brauche ich mir wohl definitiv keine Sorgen zu machen. Habe mal auf die Schnelle eine Sprite-Anzeige gecodet. Selbst bei 30 rotierten, skalierten, transparenten Sprites gleichzeitig auf dem Bildschirm ging bei mir die Framerate nicht runter und es ist eh unwahrscheinlich, dass man so viele Sprites gleichzeitig und unter solchen Bedingungen anzeigen lassen muss. Der Spielcode selbst sollte sich auf die FPS, auch wenn er am Ende relativ komplex werden könnte, fast gar nicht auswirken. Deshalb kann ich wohl guten Gewissens weiterhin Allegro.pas verwenden.

Wird mal Zeit für ein kleines Statusupdate.

Da ich im Großen und Ganzen die Level- und Spriteanzeige im Spiel ja fertig habe, wollte ich mich an Physik und Kollision ranmachen. Darauf hatte ich erstmal überhaupt keine Lust, weil mir auch einfach Konzepte und Erfahrung für sowas fehlten. Dann ist mir aber eingefallen, dass ich das auch gar nicht brauche, denn ich konnte ja ganz einfach - wie schon für die Spiel-Engine - eine externe Library dafür verwenden. Also habe ich etwas das Internet durchforstet und mit "Chipmunk Physics" eine leistungsfähige Physik-Library gefunden, die auch eine Pascal-Einbindung hat. Habe auch schon damit rumexperimentiert und sie ist tatsächlich sehr leicht zu nutzen und bietet sehr viele Funktionen.

Nun habe ich aber ein ganz anderes Problem. Das Problem ist ganz einfach, dass Pascal nun schon so verdammt alt ist. Man muss es einfach sehen, wie es ist. So sehr mir Pascal auch gefällt, ist die Sprache mittlerweile veraltet bzw. gibt es ganz einfach neuere und leistungsfähigere. Mein Hauptproblem ist aber viel mehr, dass dadurch, dass Pascal heute nicht mehr so beliebt ist, wie damals, der Support dafür auch relativ gering ist. Zwar gibt es Allegro- und Chipmunk Einbindungen für Pascal, aber die haben eben keinen so großen Support, wie die Hauptversionen und liegen deshalb auch schon wieder weit zurück. Langsam habe ich die Schnauze einfach voll, denn ständig scheint es so, als gäbe es für andere Sprachen (insbesondere C-Sprachen) mehr und bessere Alternativen, was auch verständlich ist, da bei einer höheren Beliebtheit auch Updates wahrscheinlicher sind und es insgesamt mehr Libraries gibt, die einen bestimmten Zweck erfüllen. Deswegen habe ich mir vorgenommen, mir jetzt doch mal C/C++-Programmierung anzueignen und mein Projekt zu portieren. Ich weiß noch nicht, ob daraus etwas wird, da ich den Versuch schonmal aus Motivationsmangel aufgegeben habe, aber ich werde mich jetzt einfach mal reinhängen und falls sich herausstellt, dass daraus wieder nichts wird, habe ich ja immer noch das Projekt in seiner jetzigen Form. Falls hingegen alles so hinhaut, werden wir auf jeden Fall davon profitieren. Durch neuere Versionen der Libraries erhalten wir höhere Performance, mehr Funktionen, mehr Formate, möglicherweise Kompatibilität für mehrere Betriebssysteme und außerdem Code in einer Sprache, die viel verbreiteter ist.

Ich halte euch weiterhin auf dem Laufenden.