Eine optimierte Palette mit 16 Farben

Da Forumposts ab und an verschwinden und ich diesen Zusammenhang für sehr interessant befinde, eine Kopie hier in mein Blog von DawnBringer bei pixeljoint.com:

“So, dear friends, I have wasted some time lately with my obsession for
palettes. It’s been tackled before but I felt there was (and is?) more
work to be done with designing a great multi-purpose 16 color palette
(I’ll avoid any talk of “perfect” or “ultimate” as there simply isn’t
such a thing for a limited palette).

Property wish-list:
* Archetypical colors common in games/pixelart
* Real world colors (RGB-space brightness-axis “colorcigarr”)
* Good coverage of the spectrum
* Great coverage of the brightness range (a must for any useful palette)
* Max combinatory possibilities: Interpolations, simulations, dithers etc.
* …and if possible; colors that may work as subtle varitations: rust, dirt, textures.

But as with all small palettes, some things had to be sacrificed: This
palette is very weak in magentas (as that is a rarely used area). It
also lack much in turquoise – but at least they can be simulated by
combining the many blues & greens.

This is public version 1.0 (v9843.7 to me ;))

DawnBringer's 16 Col Palette v1.0
DawnBringer’s 16 Col Palette v1.0

Some notes:
* The dark register is dominated by blue/violett commonly found in shadows/dark waters etc.
* The lower-medium register has the weight on green and browns; found in vegetation, wood etc.
* The upper-medium register has much blues and orange/pink to handle skies, sand and skin.
* The bright register has the lone yellow and the effective pink &
cyan that  are complimentary colors that span around the spectrum and
can be mixed to a very good grey!
* Red is slightly violett – I wanted a red that contrasted the other
colors rather than being another shade of brown/orange. Still good
enough to use in some skin-shades I hope.

— Mockups omitted —-

Outstanding issues:
* The optimal(?) global brightness/contrast level…these can be
adjusted quite easily without affecting the internal relationships of
the colors very much – so if you have any feelings about this lemme
know.
* The dark register: is there a better combination/structure of colors here?

Comments & questions are welcome! :)Here’s the RGB-values:
20 12 28
68 36 52
48 52 109
78 74 78
133 76 48
52 101 36
208 70 72
117 113 97
89 125 206
210 125 44
133 149 161
109 170 44
210 170 153
109 194 202
218 212 94
222 238 214
And yeah…feel free to use this palette. ”

 

Ferner dazu eine Abbildung für The Gimp von user DarkUranium vom gleichen Forum:

GIMP Palette
Name: DawnBringer's 16 Color Palette
Columns: 8
#
 20  12  28    Dark1
 68  36  52    Dark2
 48  52 109    Dark3
 78  74  78    Dark4
133  76  48    Dark5
 52 101  36    Dark6
208  70  72    Dark7
117 113  97    Dark8
 89 125 206    Light1
210 125  44    Light2
133 149 161    Light3
109 170  44    Light4
210 170 153    Light5
109 194 202    Light6
218 212  94    Light7
222 238 214    Light8

Originalartikel unter: http://pixeljoint.com/forum/forum_posts.asp?TID=12795

Crosscompiling für Atari ST mit gcc und CMake

Mit dem richtigen CMake File kann man auch für den Atari ST komfortabel mit PC Tools entwickeln.

Benötigt werden

  1. Crosscompiler und -toolchain mit gcc und zugehörigen Tools für Atari ST (z.B. hier: http://vincent.riviere.free.fr/soft/m68k-atari-mint/)
  2. CMake (http://cmake.org/)
  3. IDE für das Host System (ich verwende CMake mit Ausgabe von Makefiles und einem Projekt für die Code::Blocks IDE unter Linux)

Eine einfache CMakeLists.txt sieht dann wie folgt aus:

#
# Experimental File to build a basic file with custom startup code and without MiNTLib
# Version 17.7.2014
#
cmake_minimum_required(VERSION 2.8)
# disable strange gcc assumptions
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")
# select Atari ST cross compiler
set(CMAKE_C_COMPILER m68k-atari-mint-gcc)
set(CMAKE_ASM_COMPILER m68k-atari-mint-as)
set(CMAKE_C_FLAGS "-m68000 -O3 -fomit-frame-pointer -Wall -mshort -nostdlib -std=c99")
set(CMAKE_EXE_LINKER_FLAGS  "${CMAKE_C_FLAGS} ${PROJECT_SOURCE_DIR}/startup.S" )
add_executable(stlow1.tos
 main.c
 )
#
# Experimental File to build a basic file with custom startup code and without MiNTLib
# Version 17.7.2014
#
cmake_minimum_required(VERSION 2.8)
# disable strange gcc assumptions
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS “”)
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS “”)
# select Atari ST cross compiler
set(CMAKE_C_COMPILER m68k-atari-mint-gcc)
set(CMAKE_ASM_COMPILER m68k-atari-mint-as)
set(CMAKE_C_FLAGS “-m68000 -O3 -fomit-frame-pointer -Wall -mshort -nostdlib -std=c99”)
set(CMAKE_EXE_LINKER_FLAGS  “${CMAKE_C_FLAGS} ${PROJECT_SOURCE_DIR}/startup.S” )
add_executable(stlow1.tos
main.c

Dabei ergeben sich folgende Eigenschaften:

  • Code für Atari ST mit 68000er ohne FPU
  • int ist short, d.h. 16.bit (aber statt int ist eh stdint.h zu verwenden)
  • MinTLib wird nicht verwendet (d.h. keine Standard C Libraryfunktionen, aber die TOS Bindings sind da und voll funktionsfähig, ausserdem wird das Binary schön klein)
  • eigener Startupcode (hier von Markus Fröschle geklaut und um den Initcode von Leonard/Oxygene ergänzt)

Letztere sind für mich als Spiele und Demoentwickler interessant, da ich nicht immer 70K unixoide Library  dazulinken möchte.
Die Compilerflags kann man natürlich ggfs für den  Atari Falcon 030 oder die Firebee passend modifizieren.

Fehlt nur noch ein passendes Projekt, der erzeugte Code mit reinem C ist übrigens nah dran an handgeschriebenem Assembler. Nur echte ST Codingcracks werden besseren Assemblercode schreiben können als das, was hier ein relativ aktueller gcc erzeugt.

Vielen Dank an Vincent Riviere für die Toolchain und Markus Fröschle für praktisches Knowhow, ohne die Mintlib kleine effiziente Executables für den ST zu erzeugen.

Ouya Konsole – ein erster Bericht

Ouya Mikroconsole
Ouya Mikroconsole

Längere Zeit kein Blogeintrag, es wird Zeit dies zu ändern.

Beim VSTBo vorige Woche hatten Janina und ich Gelegenheit, auf der Ouya Konsole von ZeHa mal probezuspielen. Ich fand die Idee einer Konsole unter Android schon immer recht reizvoll, zumal die Ouya eine für Entwickler offene Plattform darstellt.

Was ist eigentlich die Ouya? Die Ouya ist eine durch Crowdfunding finanzierte offene Spieleplattform auf Androidbasis, die nicht zuviel kosten soll. Der Launchpreis lag bei 99 US$. Grundsätzlich sind Softwaretitel für die Ouya frei herunterladbar zum ausprobieren und probespielen. Nach dem guten alten Sharewareprinzip können dann Features oder ganze Inhalte im Shop nachgekauft werden. (Mehr zur Ouya bei Wikipedia)

Das Gerät ist schön handlich, ein Würfel mit ca 8cm Kantenlänge. Angeschlossen wird die Konsole per HDMI, USB und Netzwerk stehen noch neben WLAN zur Verfügung. Eingeschaltet wird das Gerät auf Knopfdruck von oben. Die Konsole hat einen Lüfter, dieser ist hörbar, stört aber nicht. Der Stromverbrauch beträgt angeblich kaum mehr als 5 Watt im betrieb. Dies ist natürlich sehr schön.

Als Betriebssystem läuft Android 4.1 mit einer speziellen Ouyashell. Allermeistens bekommt der Benutzer Android nicht zusehen. Der Vorteil liegt darin, daß Spiele für Smartphones und Tablets so relativ einfach auf die Ouya portierbar sind und dadurch eine riesiges Softwareangebot entstehen könnte. (Stand heute is das leider noch nicht der Fall.)

USB Sticks können angeschlossen und benutzt werden, sofern diese mit FAT32 formatiert sind.

Die Controller liegen gut in der Hand, die Abdeckung zu den Batteriefächern sind etwas komisch und nicht leicht zu finden. Ähnlich den Controllern der XBox gibt es 2 analoge Sticks, ein D-Pad, 4 Feuertasten und 4 Schultertasten. Ouyaspezifisch gibt es ein kleines Touchpad und einen spezielle Ouyabutton, der Menüs aufruft. Angebunden werden die Controller kabellos per Bluetooth, leider dauert das Pairing manchmal etwas arg lange. Leuchtdioden zeigen an, ob der Controller aktiv ist und welche Nummer er hat.

Mir persönlich gefallen die Controller gut, sie liegen gut in der Hand, sind etwas größer als etwas Controller der Playstation und die Anzeige für das Pairing und die Controllernummer ist weniger klotzig als bei der Xbox. Leider klemmen die Tasten ab und an, wobei ich dort die Batteriefachabdeckungen im Verdacht habe.

Im Gegensatz zu herkömmlichen Konsolen gibt es keine Spiele mehr auf externen Speichermedien. Die Konsole wird über LAN oder WLAN mit dem Internet verbunden und anschließend Software aus dem Store heruntergeladen.

Um im Store Spiele installieren zu können, ist leider zwingend entweder eine Kreditkarte nötig, oder man kauft sich entsprechende Guthabenbons (z.B. bei www.game.co.uk, die auch Bezahlung per Paypal akzeptieren). Ich habe bislang zwar einen Code gekauft, aber musste noch nichts zwingend darüber bezahlen. Ein 10 oder 15$ Code reicht anfangs gut aus, Spiele kosten selten mehr als 1 oder 2$.

Spiele gibt es ca 200 von wechselnder Qualität. Darunter sind leider keine wirklich professionellen Titel. Wer solche sucht, macht um die Ouya lieber einen großen Bogen. Dafür gibt es jede Menge kleinerer sogenannter Indiegames, die kurzweilig sind und Spaß machen. Auch Retrospiele und eine gute Anzahl Emulatoren sind im Angebot.

Emulatoren gibt es für C64, MSX, Atari ST, Atari 2600, Sega Megadrive, NES, SNES, Gameboy und Gameboy Color, PC Engine, PSX und N64. Dadurch hat man zumindest auf einer kleinen Konsole am Fernseher geballten Konsolenpower, den man sonst erstmal aus dem Schrank schleppen muss. Alleine daher lohnt sich das Gerät sehr schnell!

Entwicklen kann man wohl für das Gerät entweder über diverse Frameworks, aber auch direkt in Java wie für Android üblich. Ausserdem gibt es wohl irgendwie einen Weg mit C und libSDL zu programmieren, mindestens der Emulator  atabee (Atari ST Emulator auf Basis von Hatari , yummy!) ist ein direkter Port vom PC in C mit libSDL.

Wie schon beim Wiz damals, reizt mich an der Plattform, potentiell selber dafür Spiele entwickeln zu können. Beim Wiz ist jaleider nicht mehr viel los, die Plattform ziemlich tot, aber eine kleine Konsole im Wohnzimmer ist natürlich etwas anderes.

Mein persönliches Fazit: Bei der Ouya ist viel Potential vorhanden, aber noch nicht ausgeschöpft, die vielen Emulatoren erlauben aber heute schon zumindest für Retrogamer wie mich ein sattes Spielvergnügen.

Mehr zur Ouya: http://ouya.tv/
Gutes Forum und News: http://ouya-gaming.de/

CMake Toolchaindefinition für GP2X Wiz

Ich hatte schon vor längerer Zeit eine Toolchaindefinition zur Verwendung des GP2X Wiz GNU Crosscompilers mit CMake geschrieben. Diese möchte ich natürlich öffentlich zugänglich machen.

Damit kann man Projekte, die CMake (Was ist CMake?) verwenden, einfacher für den GP2X Wiz übersetzen.

Verwendet wird die Toolchaindefinition mit CMake wie folgt:

cmake -DCMAKE_TOOLCHAIN_FILE=../Toolchain-GP2XWiz.cmake ..
cmake -DCMAKE_TOOLCHAIN_FILE=Toolchain-GP2XWiz.cmake <Pfad zur CMakeLists.txt>

Download

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.

Code::Blocks als IDE Alternative?

Code::Blocks
Code::Blocks

In den vergangenen Monaten und fast Jahren habe ich eigentlich Eclipse als IDE verwendet. Allerdings hatte ich schon öfters von der Alternative Code::Blocks gelesen und so habe ich diese IDE auch mal ausprobiert. Sie bietet eigentlich nur Vorteile, hat allerdings auch deutliche Einschränkungen. In Summe hat es mich aber schon überzeugt und fürs private Programmieren werde ich in Zukunft für C Projekte auf jeden Fall mit Code::Blocks arbeiten.

Vorteile nach erstem Ausprobieren der Version 8.02

  • in C++ geschrieben und damit deutlich flotter als Eclipse
  • Gute Unterstützung für C und C++
  • eigenes Buildsystem, d.h. Makefiles von Hand schreiben ist nicht mehr immer nötig
  • eingebaute Konfiguration für AVR und SDCC, inklusive Compilersettings
  • konfigurierbare Compiler, insbesonders GCC Derivate
  • schneller Editor
  • Crossplattform, Code::Blocks gibt es auch für Windows

Erkannte Nachteile

  • Vala wird nur über Custom makefiles unterstützt und kein Syntaxhighlighting dafür
  • Editorkomponente ist Scintilla und damit nicht direkt erweiterbar
  • naturgemäß kein so guter Support für Java wie etwa Eclipse
  • keine direkte SVN Integration (jedenfalls nicht unter Linux, für Windows gibt es wohl ein Plugin für TortoiseSVN)

Ich glaub in Summe muss jeder selber entscheiden, ich selbst bin so gut wie überzeugt, allein schon weil ich ja selber bevorzugt mit ANSI C arbeite und zumindest privat nicht alles über SVN ein- und auschecke.

Rocks

Rocks war 1997 war mein 2. komplettiertes Spiel für MSDOS und das erste Spiel, welches ich auf meinem damals neuen P166 PC programmiert habe.

Rocks v1.0 (MSDOS)
Rocks v1.0 (MSDOS)

Das Spiel ist ein einfacher Asteroids Clone und ziemlich schlecht. Programmiert wurde der Spaß mit QuickBasic 4.5 und der netten Toolbox von Lars Struß / StarLogic. Das Spiel läuft wie immer im MCGA Modus 13h und hat optionale Soundeffekte über Soundblaster. Wer mag kann einen analogen Joystick benutzen, aber Tastatursteuerung ist genauso gut möglich.

Trotzdem ist die ganze Sache insgesamt ziemlich dröge und ich stelle das Spiel hier nur aus rein nostalgischen Gründen vor.

Die Sharewarehinweise sind wie immer bitte geflissentlich zu ignorieren, es gab nie eine Vollversion!

Ferner konnte ich dieses Mal den Quellcode nicht wiederfinden, aber in Summe denke ich, da wird nix verpasst.

Download Rocks (120k selbstentpackendes Archiv)

DOS Quadraz

Mein erstes Spiel für MSDOS war 1996 DOS Quadraz. Da ich zu jenem Zeitpunkt noch am Acorn Archimedes A3000 (Was ist das für ein Rechner?) gearbeitet habe, ist das Spiel auf dem PC meiner älteren Schwester Elisabeth entstanden.

Inhaltlich haben wir hier eindeutig den Vorläufer zum jetzigen Quadromania vorliegen. Das Spiel läuft unter MSDOS mit MCGA Karte (Mode 13h) und geladenem Maustreiber.

DOS Quadraz (MSDOS)
DOS Quadraz v1.1 (MSDOS)

Sämtliche Hinweise auf den Sharewarestatus des Programms sind wie immer hinfällig. Es gab nie eine Vollversion mit den versprochenen Features und es wird nie eine geben. Auch ewaige Mailboxtelefonnummern sind leider nicht mehr gültig.

Das Programm wird hier nur aus historischen Gründen zum Download angeboten.

Download

Danke an Lars Struß / StarLogic und seine QuickBasic Toolbox, ohne die das Programm damals nicht so hübsch geworden wäre.