Die Tücken der Spieleportierung

Gestern habe ich wegen dem stürmisch schlechten Wetter, bei dem man ja kaum vor die Tür wollte, am Nachmittag ein wenig programmiert. Ziel sollte es sein, das alte Spiel Megadash, ursprünglich für den Atari ST in GFABASIC geschrieben, auf PC bzw den GP2X Wiz zu portieren.

Ansich ging das ganz gut, binnen 2 Stunden hatte ich die meisten notwendigen Teilmodule in C neugeschrieben, eine Umgebung mit Code::Blocks aufgesetzt, meine ParadizeLib eingebunden und generell auch zum Laufen gebracht.

Am Ende des vorigen Nachmittags hatte ich dann das Spiel mit allen Mechaniken am Laufen, wie die Steine fallen, etc. Nur das Timing habe ich irgendwie nicht 100% abgebildet bekommen. Stellen, die im Originalspiel zwar mit Tücken bestückt waren, aber spielbar waren, funktionieren in meinem Port irgendwie nicht mehr. Die Steine erschlagen den Spieler an Stellen, wo man im Originalspiel erfolgreich “um sein Leben” rennen konnte.

Ich habe verschiedene Timingparameter angepasst, aber keinen zufriedenenstellenden Zustand gefunden. Entweder ist es immer noch zu schwer, oder viel zu leicht und auch da nicht immer nachvollziehbar.

Mal sehen, ob der Fehler noch gefunden wird. Im Moment liegt es jedenfalls als begonnenes Projekt auf der Platte.

ParadizeLib – meine Abstraktionsschicht für die Abstraktionsschicht

Toller Titel, ich weiss ;)

Im Jahr 2009 habe ich mir ja eine Opensource Handheld, einen GP2X Wiz zugelegt. Natürlich wollte ich dafür auch programmieren. Mit Quadromania war auch irgendwann mein erstes Spiel in C fertig und auch schrittweise erweitert.

In Zuge dessen fiel mir dann auf, daß SDL nicht gleich SDL ist. Auch wenn man SDL benutzt, muss man leider gerade was Joystickabfrage angeht immer noch Softwareweichen vorsehen, je nach Target. Beim GP2X Wiz zum Beispiel ist der SDL Joystick zwar vorhanden, aber er bietet keinen Achsenevents, da er digital arbeitet. Also muss man im Code ummappen.

Irgendwann dachte ich dann über eine Abstraktionsschicht nach und die ParadizeLib war das Ergebnis. Hier wird grundlegendes Einstellen des Bildschirms über SDL, Einsammeln von Tastendrücken, Joystick und Mauseingabe auf plattformunabhängige Aufrufe gelegt. Das Benutzerprogramm benutzt nur die ParadizeLib, die dann sich danach richtet, ob für einen GP2X Wiz oder eben ein normales Linux compiliert wird.

Die ParadizeLib abstrahiert zum Beispiel einen Joystick mit 2 Achsen und bis zu 4 Tasten. Am PC kann das dann ein USB Gamepad sein, am GP2X Wiz ist es aber das Steuerkreuz und die zugehörigen Tasten.

Lange Rede, kurzer Sinn, das Projekt gammelte seit 2 Jahren auf meiner Platte rum, und ich dachte mir, bevor ich es vergesse, mache ich es lieber OpenSource und arbeite vielleicht daran ab und an weiter.

Ich habe hier eine kurze Seite eingerichtet, vgl. im Menu, aber das eigentlich Repository liegt bei Google Code und ist per Mercurial abrufbar. Die Projektseite lautet http://code.google.com/p/paradizelib/

Wer Spass daran hat, kann sich die Library ja mal ansehen und vielleicht weiter daran entwickeln. Ich stehe gerne für Diskussion zur Verfügung. Irgendwann schreibe ich auch hoffentlich mal ein Spiel, welches diese Library auch verwendet.

Vorerst kein USB Support für Mint mit Netusbee

Wie heute vom Treiberentwickler “Galvez” auf atari-forum.com bestätigt wurde, wird aktuell der Treiber für die USB Unterstützung der Netusbee im kommenden FreeMiNT 1-18 nicht weiterentwickelt.

Der aktuelle Treiber ist nur Alpha und funktioniert wohl nicht stabil genug. Treiber und eine Dokumentation des Problems wurden allerdings im Repository abgelegt, so daß irgendwann wohl mal eine Fortentwicklung stattfinden kann.

Diese Entwicklung ist natürlich bedauerlich, da sicherlich nicht nur ich eine Netusbee für den Atari geholt habe, um eben auch USB Unterstützung am Atari ST zu haben.

Ich für meinen Teil hoffe jedenfalls, daß die Entwicklung irgendwann fortgeführt wird. Grundlegend funktioniert es wohl auch, größere Datenpakete, z.B. beim Einsatz von USB Mass Storage Geräten machen aber wohl Probleme.

Google Reader …. eine Betrachtung

Seit einigen Wochen habe ich ja ein Android Tablet für unterwegs und abends am TV(jaja Bericht folgt noch). Natürlich lese ich darauf auch diverse und zahlreiche RSS-Feeds. Leider stellte ich ganz schnell fest, wenn man verschiedene Feedreader benutzt und diese die Feedlisten und vorallem die gelesenen Artikel nicht synchronisieren, dann wird das Ganze schnell unübersichtlich.

Ich habe etwas gezögert, dann aber schnell auf dem PC den bisherigen genutzten Lifearea abgesetzt und bin auf den webbasierten Google Reader umgestiegen. Eigentlich bin ich ja etwas vorsichtiger, was den Datenmoloch Google angeht, aber andererseits sind zumindest die von mir abonnierten Feeds sowieso ohne Login lesbar.

Das Webinterface ist ganz ok, allerdings benötigt es modernste HTML5 Technologie, um komplett zu funktionieren. Es geht auch ohne, aber halt nicht so gut. Dafür gibt es für Android eine entsprechende App und diese synchronisierte aonierte Feeds und vorallem die gelesenen Posts. Das bedeutet, wenn ich via PC einen Artikel über den Google Reader lese, dann sehe ich ihn auf dem Tablet nicht mehr als gelesen. So sieht man wirklich nur noch, was wirklich aktuell ist, ein Newsstream.

Kurz und knapp: der Google Reader gefällt mir, ich hoffe, nur daß noch mehr externe Clients ein Feature zur Synchronisierung bekommen. Neue Versionen von Lifearea können das zwar, abe rich habe eine solche nicht compiliert bekommen.

Auf jeden Fall sind RSS-Feeds ein Feature des Netz, welches ich nicht mehr missen möchte.

PS: Für Ataris gibt es noch keinen ordentlichen RSS-Reader ;)

Tortoise HG mit kdiff3 benutzen

Im Büro verwende ich seit über 2 Jahren kdiff3 als Tool um Sourcedateien zu vergleichen und zu mergen. Man kann kdiff3 auch relativ einfach für die Verwendung mit Mercurial konfigurieren. Dann kann man z.B. auch mit dem grafischen Aufsatz Tortoise HG sehr komfortabel vergleichen, mergen und Details betrachten.

Dazu muss in die Mercurialkonfiguration under $HOME/.hgrc eigentlich nur folgendes eingetragen werden:

[extensions]
hgext.extdiff =

[extdiff]
cmd.kdiff3 =

[merge-tools]
kdiff3.args = $base $local $other -o $output

Danach reicht es, im Tortoise HG entsprechend kdiff3 and Diff- und Mergetool auszuwählen.

Hail to the king, Baby!

Ich habe heute Duke Nukem Forever erfolgreich durchgezockt. Ich habe eine Spielzeit von 12,5 bis 13 Stunden gehabt und neige jetzt nicht dazu, das Spiel kurz zu nennen.

Mir hat es Spaß gemacht und ich werde es sicherlich auch noch auf höherer Schwierigkeitsstufe nochmal durchzocken.

Hail to the king, Baby! Und hoffentlich gibts nochmal einen Nachfolger ;)

stdint.h and stdbool.h for Keil C51

Interestingly, Keil C51 does not ship with C99 compliant stdint.h and stdbool.h header files.

But there is no need to dispair. The stdint.h from SDCC seems to work ok however I personally would not trust the pointer types and widths. However in a context of a 8051 MCU, I’d rather introduce my own data type for pointers anyway due to the different possible memory spaces. A generic pointer will have to carry section information that has to be evaluated at runtime. A special typed pointer won’t waste as many resources.

The stdbool.h from SDCC can be used as well. Just make sure to be Keil compatible and use the following definitions:

#define _Bool bit
#define BOOL bit
#define bool _Bool
#define __bool_true_false_are_defined 1

Janina, die fleissige Keksbäckerin

Weihnachtskekse 2011

Weihnachtskekse 2011

Noch mehr Weihnachtskekse 2011

Noch mehr Weihnachtskekse 2011

Die fleissige Bäckerin

Die fleissige Bäckerin

Heute nachmittag bekam ich von Janina eine relative kurze SMS. Demnach wollte sie noch ein paar Kekse backen. Als ich vorhin dann vom Büro heimkam, stellte ich fest, daß sie nicht bei einer Sorte stehen geblieben war.

Meine Freundin ist eine fleissige Keksbäckerin, wenn sie Zeit hat. Beim Abwasch bin ich nachher involviert, das ist klar. Probiert wird dann morgen vielleicht, lecker siehts ja aus :)

Kistenweise ZX Spectrum Tapes

Am Mittwoch bekam ich zum monatlichen VSTBo-Treffen von einem bekannten 2 Kartons voller ZX Spectrum Tapes geschenkt. Zunächst dachte ich, das wären Kopien, aber tatsächlich handelt es sich um Originale. Die meisten Spiele in den Kartons sind nicht unbedingt bekannt, oder wenn bekannt, dann nur für ZX Spectrum User.

Karton A mit ZX Spectrum Tapes

Karton A mit ZX Spectrum Tapes

Ich muss dann mal nach und nach probieren. Ich habe heute mittag ca 10 Titel mal ausprobiert und die meisten auch zum Laufen bekommen. Auf meinem +2A muss ich allerdings teilweise in den 48K Modus umschalten.

Mega Apocalypse hat auf dem +2A eine gute Musik, da der Rechner den AY8910 Soundchip eingebaut hat. Und dank eines kleinen Interfaces passen auch normale Joysticks an den Sinclair Port.

Karton B mit ZX Spectrum Tapes

Karton B mit ZX Spectrum Tapes

Mein dk-tronics Joystickinterface hat trotz Reinigung der Kontakte am Modul und am Spectrum selbst mit Isopropanol irgendwie nicht funktioniert. K.A. ob das am Spectrum oder am Interface liegt.

In jedem Falle Danke an Roland A. für die Kartons mit den Tapes. Bedingt durch die Ladezeiten von 2-5 Minuten pro Tape dauert es so seine Zeit, bis man die Sammlung durchgeprüft hat.

Command & Conquer: Alarmstufe Rot unter DOSBOX

Lange Jahre lang war ich schier am verzweifeln. Command & Conquer: Alarmstufe Rot wollte einfach unter neueren Windows Versionen nicht mehr laufen.

Ich hatte mir das Spiel irgendwann 1997 oder 1998 für damals 100DM in der Komplettbox mit den Erweiterungsdisks Gegenangriff und Vergeltungsschlag gekauft. Unter Windows XP oder gar einem 64bittigen Windows 7 wollte es nicht mehr.

Command & Conquer: Alarmstufe Rot Hauptmenu (MSDOS)

Command & Conquer: Alarmstufe Rot Hauptmenu (MSDOS)

Allerdings wurde parallel zur Windows Version auch immer eine für MSDOS mitausgeliefert. Nach einigen Zögern habe ich diese mal unter DOSBOX ausprobiert. Und siehe da, es läuft.

Das Spiel ist bei mir spielbar flüssig, CD-Musik und Videos funktionieren gut. IPX Netzwerk werde ich irgendwann nochmal ausprobieren.

Command & Conquer: Alarmstufe Rot in-game (MSDOS)

Command & Conquer: Alarmstufe Rot in-game (MSDOS)

Immerhin die Kampagnen und meine alten Maps gegen Computergegner funktionieren noch ganz ordentlich. Einziger Wermutstropfen ist die beschränkte Bildschirmauflösung. Während die Windows Version immerhin schon mit 640×400 oder 640×480 Pixeln lief, ist die DOS-Version auf 320×200 im Modus 13h limitiert.

Ein wichtiges Detail ist die Einbindung der Spiel-CD der im DOSBOX Emulator. Die CD muss mit “-t cdrom” gemountet werden und zusätzlich mit dem Volumelabel gekennzeichnet werden. Ggfs. muss auch die emulierte CPU etwas angepasst werden, der Installer mag angeblich direkt nicht. Ich hatte das Spiel erst unter Wine installiert, wo es wackelig lief und spiele jetzt einfach aus dem Verzeichnis heraus.

In meiner Konfigurationsdatei für DOSBOX steht eigentlich nebend er üblichen DOSBOX und PC-Konfig nur soviel drinn:

mount c /opt/wine-install/drive_c/WESTWOOD/ALARM
mount d /media/CD1 -t cdrom -label CD1
c:
ra.exe
exit