spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Auf mehrfachen Wunsch reanimiere ich hier das Tutorial und habe es noch leicht erweitert und aufgefrischt.
Viel Spass. Auch alle verfügbaren Links zum GBA und Tipps zum kleinen Freund sind hier enthalten..einfach durchlesen.

Updates (News):
NDS Homebrev News (1/200

Willkommen beim Nintendo DS. Das hier sind übrigens Dummies. Sie sind nicht nur gut um Farbe ins Spiel zu bringen sondern haben Bildschirme die genau 256*192 Pixel haben.




---------------------------------------------------------
Teil 1 : Die Hardware.
---------------------------------------------------------

Es ist wichtig zu wissen mit was man arbeitet um Resultate zu erzielen, und ein kleiner DS ist etwas anderes als ein Ghz-PC. Deswegen schauen wir uns zuerst mal grundlegende Unterschiede zwischen beiden an damit es später keine grösseren Probleme in der Verständigung gibt.

Zitat

Technische Daten des Nintendo DS:

- 2 semitransparente TFT Screens je 256*192 Pixel (RGB) bei 262.144 Farben
- Unterer Screen Touch Screen, beide mit Hintergrundlicht
- ARM946E-S (67MHz Takt) CPU
- Cache: 8 KB Instruction Cache, 4KB Data Cache
- TCM: 8KB Instruction, 4KB Data
- Co-Prozessor ARM7TDMI (33MHz Takt)
- Hauptspeicher 4MB
- ARM9/ARM7 Shared 32KB (16KB x 2)
- ARM7 Internal RAM 64KB
- VRAM 656KB
- 3D - Geometric Transformation Maximal 4 Millionen Vertex/Sekunde
- 3D - Polygon Rate - Maximal 120.000 Polygone/Sekunde
- 3D - Pixel Fillrate - Maximal 30 Millionen Pixel/Sekunde
- 2D - Hintergrund maximal 4 Layer (pro Screen)
- 2D - Maximal 128 Objekte (pro Screen)
- Alphachannel (1*pro Screen)
- 2 Lautsprecher (Stereo, Virtual Surround)
- 16 Kanäle Stereo ADPCM/PCM
- Eingabe Tasten Start, Select, A,B,X,Y,L und R
- Wireless 802.11 Protokoll (2,4GHZ)
- 2-16 Spieler/Chatter
- Distanz 10-30 Meter
- Multiplayer mit nur 1 Spielmodul möglich (per Download)

Damit sollte sich doch schon was anfangen lassen. Die wichtigsten Sachen habe ich schon mal fett geschrieben. Die sollte man aus dem "Stand" wissen. Denn im Moment ist noch nicht alles wichtig, ich will ja nicht das Ihr direkt in Panik geratet. Folgendes solltet Ihr allerdings von Anfang an beachten wenn Ihr vom PC auf den DS (oder andere Mobile) umsteigt. Merkt euch bitte die verschiedenen Begriffe wie ROM, ich beschreibe Sie jeweils bei der ersten Erwähnung.

Die meisten denken das ein DS wie alle Modul-Systeme keine Ladezeit hat. Das ist falsch. Wie Ihr seht besitzt auch ein DS Videoram und Arbeitsspeicher (Sound wird aus dem Ram oder vom Modul abgespielt), also muss auch ein DS vorm Starten des Programms die Daten an die richtigen Stellen schieben. Das geht allerdings im Vergleich zum PC schnell und bedarf höchstens einer Sekunde um den "V-Ram" (Videospeicher) und den Arbeitsspeicher zu füllen . Beide CPUs haben zwar direkten Zugriff auf das "Rom" (Read only memory/ nur lese Speicher= Modul), das Tempo reicht aber nicht zum schnellen verarbeiten. Die Daten des Programms (der Code) werden also zuvor "immer" ins Ram kopiert. Kleine Anmerkung: Die meisten Module (die DS Speicherkarten) besitzen einen kleinen wieder beschreibbaren Bereich (EEPROM), hier werden die Hi-Scores gespeichert, dazu mehr später. Da der Datentransfer so fix geht reicht eine kleine Spielpause (Enter World 2.4 ) um die Daten zu laden.

Der Touchscreen ist für viele PC Freunde was neues, läst sich aber genauso abfragen wie eine Maus. Allerdings gibt es 2 Fallen.

A) Eine Maus ist immer an irgendeiner aktiven Position, ein Touchscreen nicht unbedingt. Beim abfragen einer Position muss man also damit rechnen als Wert "0" zurückzukriegen und das dementsprechend abfangen.
B) Ein Touchscreen gibt nicht eine Pixelposition sondern einen Bereich zurück. Der kann beim DS zwischen 2 und 8 Pixel liegen. Fragt ihr also einen Pixel ab gibt es Frust. Immer Bereiche Abfragen die mindestens 2*2 (besser 4*4) Pixel gross sind. Benutzt der User den "Pen" (Stift) sind immer mindestens 2 Pixel aktiv.

2 Bildschirme hört sich schlimm an. Ist aber kein Problem. Um genau zu sein teilt Ihr dem DS nur mit in welchem Bildschirm die geladene Grafik aktiv ist. Also bei Palib (dazu später) halt B0 (unten) oder B1 (oben). Alternativ könnt Ihr die Bildschirme zu einem grossen zusammenfassen. Dann ist die Angabe überflüssig da Ihr einen virtuellen Screen von 256*384 Pixel habt. Damit wären wir bei der "Todeszone". Wie Ihr wisst sind beide Bildschirme nicht direkt zusammen gekleistert sondern haben einen gewissen Abstand. Wenn eine Figur aus dem unteren in den oberen läuft dauert es einen Moment in dem die Figur nicht sichtbar ist. Diesen Bereich nennt man Deathzone und ist meistens auf 48 Pixel definiert. Man kann diesen Bereich aber auch umdefinieren oder löschen (0 Pixel). Merken sollt Ihr euch im Moment nur nur das Ihr euer "Gameplay" eventuell anpassen müsst.

Dann gibt es noch jede Menge Goodies die ich nach und nach beleuchten werde. Als Beispiel eine Funktion die in "Echtzeit" Sprites flippt (umdreht). Nehmen wir an wir haben am PC eine Figur die nach links und rechts laufen kann. Wir brauchen dazu ein Bild wo Sie nach vorn guckt (keine Bewegung) und jeweils 8 nach links und nach rechts wo sie läuft (Animation). Das macht 17 Bilder mit (zb) 8kb = 136 kb. Zugeben etwas aufwendig aber schön anzusehen. Was am PC ein Witz wäre ......wisst Ihr noch wieviel Arbeitsspeicher der DS hat... . Ja, ich verstehe euren Schock *g*. Doch halt! Nochmal von vorn. Allerdings laden wir nur ein Standbild und 8 Bilder für rechts. Sonst nichts. Wenn wir nun nach links laufen sagen wir dem DS er soll die 8 rechten Bilder bitte umdrehen, und Voila, wir laufen nach links..und zwar in Echtzeit (nix vor berechnen, kein Speicherverbrauch). Meine Rechnung: 1+8 = 9 Bilder mit 8kb = 72kb! Bingo, und das war nur eins der Beispiel. Wenn eine Figur natürlich von links anders aussehen soll als von rechts, könnt Ihr das normale Prinzip anwenden. Ihr dürft aber nie vergessen das Konsolen "nur" zum zocken entwickelt werden. Sie haben viele Funktionen die darauf zugeschnitten sind. Wer also blind nach PC-Muster arbeitet verschenkt Resourcen und Arbeitszeit.

---------------------------------------------------------
Teil 2 : Gefahren/Legalität/Emulatoren.
---------------------------------------------------------

Nun mal die Abrexxes Märchenstunde. Klein David (Name frei erfunden) hatte Freude an seinem DS und fing an dafür zu programmieren. Leider fing er sich am PC durchs Internet einen DS Virus ein und zerstörte so seinen DS. Klein David weinte bitterlich da sein DS nun tot war.

Traurige Geschichte nicht wahr. In einer "Fachzeitschrift"! stand dazu zu lesen: "..kann ohne weiteres zutun die Firmware des DS manipuliert und das Gerät dadurch "zerstört" werden. Eine Garantie greift dann nicht." Wir stellen uns also natürlich die besorgte Frage, ist das Möglich? Die Antwort lautet NEIN!.

Jede Konsole besitzt wie ein PC ein BIOS (Basic Input Output System). Dieses hat einen wieder beschreibaren Speicher in dem die System Daten untergebracht sind. Zb welcher Hardware Bereich auf welchen Zugriff hat oder nicht, welche Hardware überhaupt zur Verfügung steht sowie Sicherheits Abfragen. Nur das BIOS selbst kann diesen Bereich zum überschreiben freigeben. Genau wie bei einem Motherboard des PCs ist dafür eine spezielle Software vom Hersteller nötig die man nur benutzen sollte wenn es unbedingt nötig ist. Hacker können sich bei verschiedenen Systemen ins BIOS einschmugeln und diesen verändern um zb Viren und Trojaner einzuschleusen oder dehren Ausführung erst möglich zu machen. Das Problem kennen wir bei der PSP. Deswegen kommen immer wieder neue "Firmware" Versionen der PSP die Lücken schliessen aber dadurch auch Fremdcode (Also unsere Progs) verbieten zu starten. Vergessen wir nicht das die PSP über einen Memorystick verfügt mit dem der User jede Menge Mp3s, Videos und anderes Zeug auf seine PSP laden kann. Alles potentielle Gefahren wenn die Firmware Löcher hat. Wenn ein Virus gar die Firmware zerstört ist die PSP hin. Sie kann nämlich nicht mal mehr mit den defekten Daten booten um sich selbst zu überschreiben. Eine Reparatur ist fällig. (Bioschip ausbauen und manual flashen plus Kosten da hier keine Garantie).

Bei einem DS wird nur leider die Schreibfunktion des BIOS nicht mit Strom versorgt. Damit das BIOS überhaupt beschrieben werden kann muss der DS aufgeschraubt werden und eine Lötverbindung gesetzt werden. Erst dann kann das BIOS beschrieben werden. Desweiteren hat der DS offiziell keine beschreibbaren Wechselspeicher (Sticks etc). Werden alle Module entfernt und der DS abgeschaltet.....ist der DS wieder im Urzustand. Die einzige Gefahr besteht wenn man permanent seine "Supercard" etc (später) im GBA Slot stecken hat und fleissig Original Module zockt. Ist dann ein Schädling an Board können die Spielstände zerstört werden da dieser Speicherbereich des Moduls beschreiben werden kann. Von hier aus kann er sich auch wieder auf andere SCs (Supercard) übertragen. Hier hilft nur das löschen aller befallenen Spielstände und löschen der Cards.

Doch die Viren fallen nicht vom Himmel sondern von Seiten mit illegalen original Spielen wo sie in die Roms eingebacken sind. Wer sich an die offiziellen Homebrev Seiten hält und nur hier runterläd ist zu 99% sicher. Viren fliegen hier Minuten nach dem Release der Dateien auf. In Foren werden bösartige Sits sofort entlarvt, womit wir beim Thema Legal/Illegal wären.

Ein grosses umstrittenes Thema das ich hier behandeln muss da ich hier Hardware vorstelle und erkläre die auch "illegal" verwendet werden kann. Zuerst zu den originalen Spielen die man sich als Roms runterladen kann. Dies ist immer illegal. Alle Rechte liegen bei Nintendo und den Herstellern. Nintendo gewährt auf die Hardware Garantie sowie Kulanz, der Spielerzeuger ebenso falls ein Produkt in der Zeit der gesetzlichen Gewährleistung nicht mehr funktioniert. Die Aussage "Ist ja nur eine Sicherheitscopie, ich hab das Original" ist ein Märchen. Auch dann ist der Download nicht legal da die Echtheitsabfrage in jedem Fall umgangen werden muss (PassMe). Auch beim GBA hat Nintendo die Rechte am Spielemodul. Jede Diskussion mit den Rechteinhabern ist im Zweifelsfall zwecklos. Das viele Hersteller bei sehr alter Software beide Augen zudrücken ändert daran auch nichst.

Was die Entwicklung ohne offzielle Dev-Kits angeht geht jeder eigene inoffizille Wege. Der offizielle ist immer NEIN. Das hat unter anderem den Grund alle Firmen mit offiziellen Kits und sich selbst vor Konkurrenz zu schützen. Die entgültige Freigabe eines Produkts liegt eh immer beim Hardwarehersteller (Qualitätskontrolle) damit der Markt nicht mit Müll überflutet wird wie das beim PC der Fall ist. Ausserdem verdient man noch an den Datenträgern mit.

Sony hat mit der Yaroze Playstation und seinem PS2 Linux-Kit schon bewiesen das es Homebrev freundlich ist. Bei der PSP wird aber geblockt wo es nur geht. Dies liegt aber wohl hauptsächlich daran das die PSP eine eierlegende Wollmilchsau mit wechselbaren beschreibbaren Medien ist (Stick). Jeder kann ohne Hardwaremittel loslegen und flashen was das Zeug hält. Leider haben die meisten Leute davon aber keine echte Ahnung und jede zerflashte PSP schädigt dem Namen "Sony". Insofern ist die Flucht nach vorn verständlich. Nintendo dagegen läuft mit heruntergezogener Kaputze durch die Gegend und läst viel durchgehen. Es ist also BigN durchaus nicht entgangen das auf GBA und DS immer wieder Homebrev durch einen Publisher den Weg zu einem offizielen Start findet, und da nicht zwangsweise mit weniger Erfolg. Das bedeutet für N viele Games und neue Ideen. Dafür scheint man in Japan schon mal ein Auge zu zudrücken wenn kritische Hardware verkauft wird. Insofern ist eh nur das übertragen der Daten auf die Originale Hardware ein Problem. Denn alle Dev-Kits der Scene beinhaltet keinen geschützten Code der Hersteller (Es werden ja auch nur die einzelnen Chips emuliert wie zb die ARM Cpus des DS). Wenn Nintendo also das ganze verbieten wollte bräuchte man nur die Hersteller der Flashsysteme zu belangen. Ohne Module keine übertragung und hier hat Nintendo alle Patente. Solange Ihr also eure Hardware nicht dazu missbraucht "geschützte" Software zu kopieren habt Ihr nichts zu befürchten.

Die Emus emulieren nur die Hardware und sind somit nicht illegal da hier nur eigener Code zum Einsatz kommt. Ein Ausnahme gibt es allerdings.
Man findet im Internet einen Emu der offiziell von Nintendo sein soll. Dies ist auch korrekt. Es handelt sich um den Emu der bei den ersten Dev-Kits dabei war damit die Entwickler Ihre Games auch testen konnten (die Hardware gab es ja noch nicht zu dem Zeitpunkt). Wer jetzt aber glaubt die goldene Kuh zu finden wird enttäuscht. Der Emu wird nicht weiterentwickelt und ist zum Teil komplett veraltet da der finale DS sich noch leicht veränderte. Sobald man also 3D bemüht oder nur speziellere Befehle an die Hardware ist schluss. Arbeiten ist so nicht möglich.
Denn Namen nenne ich nicht da weiterhin der EMU Eigentum von Nintendo ist und offiziel nicht freigegeben. Er ist vielmehr durch dunkle Kanäle ins Netz gerutscht.

Jetzt noch ein bissel Text, dann dürft Ihr auch mal ran.

Wie schon gesagt sind die Emulatoren nicht illegal. Das ist der Grund wieso euch ein Emu mit 2 schwarzen Bildschirmen begrüsst und nicht etwa mit dem DS Bootmenu beim einschalten. Damit würde man das Betriebssystem emulieren und das wäre illegal da die Rechte für die Software bei Nintendo liegen. Natürlich ist es möglich ein alternatives einzubinden, Sinn macht das aber keinen am PC. Es gibt zur Zeit 3 Emus die man alle haben sollte. Der Grund ist das die sich noch in der Entwicklung befinden und nicht ausgereift sind (Was auch die stark schwankenden Frameraten erklärt). So kann es sein das euer Code auf diesem aber nicht auf jenem läuft. Die Entwickler sind permanent bemüht Probleme zu beheben. Insofern ist es eine gute Idee sich auf den Seiten durchzulesen wo genau alle Probleme aufgeführt werden. Wichtig ist immer das es auf der "echten" Hardware läuft. Es kann also vorkommen das alle Emus streiken, der echte DS aber alles abspielt. Hier nicht verzweifeln sondern Ruhe bewahren, allerdings kommt dies immer seltener bis gar nicht mehr vor. Bevor Ihr aber durchdreht solltet Ihr immer diese Möglichkeit in Betracht ziehen (Gilt für alle Emus/Konsolen). Meistens geben die Leute von Demos auch an mit welchem Emu sie getestet haben und mit welcher Version desselben. GBA Freaks haben es da einfacher , mit VirtualBoyAdvance steht ein nahezu perfekter Emu zur Verfügung. In der GBA Szene gilt der VBA als defakto Standard.

http://vba.ngemu.com/

Eine Installation der einzelnen Emus ist nicht nötig. Am besten für jeden einen Unterordner anlegen und fertig. (Kenner machen das in den Stamm Ordner des devkitpro.

Meine aktuelle Hitliste Stand Juni 2007

1 - no$gba Perfekte Grafik +Sound (der einzige)
2 - DeSmume wegen scalierbarem Fenster + schnell
3 - iDeas schnell + Videos aber Schrott Interface

no$gba
+ Der wichtigste.
+ Emuliert die Hardware aber keine Firmware (also kein Bootmenü)erlaubt aber das einbinden der offiziellen BIOS/Firmware Roms für Test. (Weitere Infos bitte bei mir anfragen)
- Es gibt eine recht teure Debug-Version
- in 3D sehr Hardware hungrig
+ Komplette Audio Simulation / gute 3D Simulation
Im Anhang befindet sich eine fertig eingerichtete Version, im Ordner GAMES befindet sich ein Freeware Rom zu testen.
http://nocash.emubase.de/gba.htm
http://nocash.emubase.de/gbapics.htm <-Debug Version in Action (Bilder)

iDeas
Der neue Star am Himmel.
- Debugger mittelmässig
- kleiner Bug in 3D (wurde verbessert, aber nicht komplett behoben)
+ "Start your Engines" :lol:
+ Video capture
Perfect für die schnelle Nummer
http://spazioinwind.libero.it/linoma/ideas.html

DUALIS
+ Keine Firmware Möglichkeiten
+ Sehr gute 2D Emulation
- Mässiges 3D, nicht mehr up to date
- Audio sehr schlecht
+ Sehr gute Debug Funktionen für Tiles
http://dualis.1emulation.com/

DeSmuMe
+ Firmware wird teilweise emuliert (nicht ganz legal wegen kommerzieller Roms)
- Audio sehr schlecht (milde ausgedrückt)
- eher mittelmässiges Debug
+ Open Source
+ Sehr schnell
+ Skalierbares Fenster
+Unterstützung von USB Pads
- Böser Transparenz Bug bei 3D im Moment
http://desmume.org/?page_id=11 <--- Downloads

Alle anderen kann man getrost vergessen.

Beim folgenden Link von Hobby Projekten werdet Ihr bemerken das es verschiedene Endungen der Dateien gibt. Nämlich *.nds, *.ds.gba und *ds.sc. Dazu im nächsten Kapitel mehr. Für die Emus wird nur die *.nds Datei benötigt. (Beim GBA ist es immer *.gba , auch hier für Emus die normale *.gba laden). Wenn nur "ROM" dasteht ist es die *.nds.

Achja, DS Emus können keinen GBA Code ausführen. (ausser no$gba da Hybrid)

http://www.palib.info/wiki/doku.php?id=projects

Für die GBA Freunde mit VBA: http://www.gbadev.org/demos.php?listby=popularity

Jetzt entspannt erst mal ein paar Minuten.

---------------------------------------------------------
Teil 3 : Datentransfer.
---------------------------------------------------------

So schön Emus auch sind, so richtig kommt das (Oh ja) Gefühl erst wenn das ganze auf dem echten DS abläuft. Dazu benötigen wir Material um die Daten auf den DS zu bekommen. Dieses kann zwischen 80 bis 200 Euro (+X) liegen. Da die Preise hier schwanken informiert euch immer bei den entsprechenden Anbietern. Wie schon gesagt macht hier Nintendo zur Zeit beide Augen zu denn man kann davon ausgehen das bei den Angeboten das ein oder andere Patent zumindest "grosszügig" ausgelegt wird. Interessant ist allerdings das kein japanischer Anbieter dies offiziell verkauft. Dies ist aber nicht ungewöhnlich, man wills sich im Notfall halt nicht verscherzen, schlieslich sitzt der Boss in der Nachbarschaft. Und in Japan könnte man durchaus einem Händler verbieten Nintendo Produkte zu verkaufen. Schlecht fürs Geschäft. Bevor Ihr nun in Holland oder USA einkauft solltet Ihr euch in den Foren umgucken damit Ihr keinem Betrüger in die Hände fallt (Diese Regel gilt eigentlich für jeden Internetkauf auser Eyboah, hier kann jeder seine Reputation manipulieren wie er will *blub*).

Zuerst sollten wir wissen was passiert wenn der DS ein originales Spiel lädt. (Ja ich weis..bla ..Theorie..bla. Es ist aber später für Fehlersuche ungemein praktisch wenn man die ganze Therorie zumindest mal gelesehn hat..).

Beim starten des DS Spiels liest der DS vom DS Modul einen "Authorisierungscode". Dieser wird für jedes Spiel von Nintendo aud das Modul geschrieben. Besteht nun dieser Code die interne Prüfung werden die Daten des Spiels geladen. Ein GBA kennt diese Prüfung nicht sondern läd sofort. Blöderweise gibt es offiziel kein Lese/Schreibgeräte für die Module bei denen es sich um ein Nintendo eigene Produktion handelt (Naja es ist im Grunde eine modifizierte Flash *hust*). Zur Zeit haben diese bis zu 128MB Speicher. Es können aber auch grössere produziert werden (Das max weis ich nicht halte aber 1 bis 2GB für realistisch, vergessen wir nicht das die DS-Module sehr klein sind).Allerdings steigern grössere Karten auch den Preis für fertige Spiele oder mindern den Gewinn.

Ich erkläre hier nur die wichtigsten Systeme da sie ausgereift und weit verbreitet sind. Prinzipiell solltet Ihr darauf achten ob Ihr ein Slot1 oder ein Slot2 System erwerbt. Neu sind Slot1 Systeme die alles auf einer kleinen NDS Karte speichern. Einziger Nachteil, GBA geht damit im Moment nicht. Reine Slot2 Systeme mit PASS gelten als veraltet. Ausserdem solltet Ihr hier gucken ob das Teil bereits DLDI fähig ist. Dazu später mehr.
http://chishm.drunkencoders.com/DLDI/index.html

Finger weg von "Datel" Zeug. Die Dinger sind für kleine mp3 und Video spielereien gut und billig. Für Homebrew aber ungeeignet da nur Probleme.Lest da unbedingt imme was andere Anwender dazu sagen. In den Foren gibts immer wieder ausführliche Test von Members wenn neuer Stoff auf den Markt kommt

FlashMe. Die gefährlichste Methode. Der DS wird geöffnet um eine Lötbrücke einzufügen. Anschliessend wird die originale Firmware des DS durch eine modifizierte ersetzt die es erlaubt DS Coder direkt vom GBA-Modul zu laden. Anschliessend sollte die Brücke wieder entfernt werden um sich vor Viren zu schützen. Die neueren Versionen bieten einen Recovery Schutz mit dem man im Notfall die Firmware neu aufspielen kann selbst wenn diese zerstört wird. Da einige Versionen den WiFi Bereich überschreiben kann es hier je nach Version zu Problemen kommen. Nachteil: Zum Aufspielen der Soft braucht man trotzdem eine PassMe (siehe unten) Variante. Mittlerweile bitten Shops "fertige" Versionen des DS zum Aufpreis an. Die Garantie von Nintendo Europe ist dann freilich flöten, die muss dann der Händler übernehmen. Hier solltet Ihr euch "penibelst" über die aktuelle Version informieren. Geht es in die Hose, ist das reparieren teurer als ein neuer DS da der Chip ausgelötet werden muss. FlashMe gibts gratis im Internet.

WifiMe. Hier werden über das WiFi des Nintendo Daten übertragen. Leider funzt das nicht mit jedem WiFi sondern nur mit Geräten die spezielle Chips haben. Im Internet findet man Listen welche Karten, Geräte in Frage kommen. Damit ist aber leider noch nicht sicher das sich der Chip auch auf der Karte befindet die man bestellt (das kann ja ändern). Ausserdem funktioniert das nur mit älteren DS (Version 1 bis 3). Knackfrische und "Lite"s bleiben hier leider draussen. Aus Sicherheitsgründen hat Nintendo wohl hier reagiert. Da der DS nichts speichern kann, können auch nur maximal 4 MB übertragen werden (Hauptspeicher). Ist das Gerät aus, sind die Daten weg. Mein Rat, wenig Spass viel Stress...Finger weg. Ansonsten das www nach " WifiMe" befragen.
Achtung Test zu WiFi Fähigkeit:
- Nintendo einschalten mit Modul drin
- In den Pictochat A eintretten
- Modul entfernen
- Bildschirme keine Reaktion, grün oder blau = kompatibel
- Bildschirme gelb oder mangenta = nicht kompatibel

PASSME(2)/PassKey/MagicKey (ME heist übrigens nicht "My Emulation" sondern findet sich oft als Anhängsel bei Homebrev für den DS. Die Bedeutung ist mir aber grad entfallen). PassMe (und Klone) ist ein kleiner Würfel der vorn eine Zunge hat die wie ein DS Modul aussieht. Hinten befindet sich dann ein Slot für ein DS Modul. Hier muss man ein original Spiel einstecken. Wenn nun der DS ein Spiel laden soll und den Code abfragt, dann schicht PassMe den Code des Originalspiels. Ist der DS dann zufrieden teilt im PassMe mit das sich das Spiel aber nun nicht auf dem Modul befindet sondern im GBA Slot. Er sollte dann jetzt mal gefälligst da laden, und hier befindet sich dann ein GBA-Flash Modul (kommt noch)mit unserem DS Game. Praktisch nicht. Damit ist die Aufgabe für PassMe erledigt. Beim neuen PASSME2 (und Klone) steht dann auch noch was von 512MB/32MB (zb). Nun, gibt es zu PassMe auch noch ein Programm das man ebenfalls auf das GBA-Flash Modul schreiben kann. Wenn das gebootet wird kann man zb Spielstände von DS Modulen in dem kleinen Speicher sichern (kopieren), oder ganze *.nds Files in den grossen schrieben. Mit Hilfe der "Multiboot" Funktion hat man dann eine Art Menü wo man von mehreren Dateien eine starten kann. Sehr praktisch wenn man zb verschiedene Versionen eines Codes testen will. Der Entwickler kann so auch ältere Versionen seines Games einfach im PassMe stehen lassen und muss nicht immer alles löschen wenns auf der GBA-Flash mal wieder eng wird. Schaut euch auf jeden Fall an was das System kann und was Ihr wollt. Brauchen tut Ihr das nicht, alles nur Luxus. Ein GBA System braucht Ihr aber noch zwingend für DS (siehe unten). Achtung! Auch der alte PassMe (ohne 2) funzt nur auf Version 1 bis 3.

PassCard. Die neuste Methode. Statt eines PassMe habt Ihr nur ein normales DS-Modul was eingelegt wird und die selbe Funktion hat. Speicher hat die freilicht nicht (kommt noch). Sie ist aber äusserst praktisch da sie nicht hinten absteht sondern platzsparend ist. Auch hier braucht Ihr zwingend eine der beiden folgenden Lösungen um die Daten zu übertragen.

Kommen wir nun zu den beiden GBA Systemen auf dem sich später die Spiel Daten befinden die wir am PC übertragen. Somit hat jeder DS Entwickler auch automatisch immer die Hardware um den GBA zu programmieren! Wie bereits erwähnt ist das bei reinen Slot1 Systemen aber nicht mehr nötig, dafür kein GBA (zur Zeit).

GBA-Flash und Klone. Diese Karte hat genau die Form eines GBA Moduls und einen MiniUSB Stecker. Die Speicher reichen von 128kb bis mehrere GB. So gross wird zwar kein Spiel, aber wir haben ja Multiboot (Auch auf dem GBA gibts entsprechendes Prog für GBA Codefetzen). Wahnsinnige können sich ja mp3 und Videos draufknallen und mit entsprechenden Progs gucken (Alles geht wenn auch bei bescheidener Qualität). Alles andere sollte klar sein. USB rein, aufspielen, einstecken, fertig. Wer nur für GBA arbeitet brauch auch nur das. Allerdings verschwinden sie so langsam vom Markt und werden ersetzt durch:

NeoFlash /Supercard/ etc. Eigentlich das selbe, nur handelt es sich hier um einem Adapter für Compac-Flash oder (Mini) SD Karten (übliche Handelsware). Hier gibts Speicher in allen grössen. Wer sich für CF entscheidet sollte bedenken das diese hinten rausteht, das kann nerven. die anderen verschwinden ganz im Modul. Hier brauch man für sein Format natürlich am PC ein Schreib/Lesegerät. Auch hier ist der GBA Freak nur damit zufrieden und brauch sonst nichts mehr.

Mittlerweile gibt es sogar Systeme mit 4 GB und sonstiges Zeug. Der Sinn sei dahingestellt. Wer es braucht kann sich in den Foren auf dem laufenden halten. Wer (zb) Passcard und Neoflash braucht sollte beides zusammen im Bundle kaufen. Das wird billiger. Andere können die Firmware wieder herstellen (Falls man die Brücke gesetzt hat und mal Mist baut).

Erinnert Ihr euch noch an *.nds, *.ds.gba, *.gba.sc. Wenn Ihr das wollt (Makefile) spuckt der Compiler alle drei aus. Es handelt sich drei mal um das gleich Spiel mit der gleichen Grösse, nur sind die Datenblöcke anders organisiert. Einmal als normales DS-Modul (*.nds). Da wir aber kein DS Modul beschreiben können gibts noch das typisch GBA Modul (*.gba). Man brauch also immer nur die Datei jenachdem welches System man hat (und halt *.ds für die Emus). Damit ist auch das Geheimnis gelöst. Die SC Endung ist aber am aussterben da die meisten neuen mit fast allen Endungen umgehn können. Hier müsst Ihr "uptodate" bleiben, was aber kein Problem ist.

Neu ist hier das DLDI System. (Dynamically Linked Device Interface). Hiermit kann extren auf jeden NDS File ein Header "aufgedampft" werden der zu dem jeweiligen System kompatible ist und das nachladen und speichern von Daten erlaubt.
Der Programmierer brauch nur noch noch include "fat.h" eingeben und man ist mit allen Systemen aktuell, ist das nicht dufte.

Für Emus wie no$gba gibts auch ein DLDI File. Mehr dazu in den Foren. Das alls wird aber nur gebraucht wenn mit mehr als 4MB gearbeitet wird.

Hier nun ein paar fette Bilder der System zum schmöckern.

http://www.divineo.de/cgi-bin/div-de/search.html

Und ein seriöser Shop:

http://www.flashlinker-shop.com/

Alle diese Artikel findet man meistens in der Rubrik "Backup".

Hier: http://forum.gbadev.org/index.php gibst einen ganzen Bereich dazu. (DS Flash Equipment und extra für GBA). Dieses Forum ist der Hit, aber leider englisch.

-Und nicht vergessen, niemals an den Modulen manipulieren wenn der DS eingeschaltet ist.
-Niemals Software von dubiosen Seiten überspielen (Euren Scores und Nerven zuliebe)

Kleiner Hinweis: Für diesen Abschnitt gibts keine Gewähr da sich die Hardware andauernd ändert. Dies ist nur eine Beschreibung der gängigen Systeme. Bitte lest in den Shops und Foren die Infos aufmerksam durch.

---------------------------------------------------------
Teil 4 : Die Entwicklungsumgebung.
---------------------------------------------------------



Auch hier zuerst ein paar Sätze zur Warnung.

Wir sollten uns klar sein das man nicht "wild" updaten sollte wenn welche zur Verfügung stehen. Sonst kann es schnell sein das gar nichts mehr funktioniert. Ich bitte euch daher meine Tips zu beachten die ich euch hier gebe. Sie sind enorm wichtig und ersparen euch viel Stress. So manches Fenster und so mancher PC haben nur eine Chance wenn Ihr sie befolgt bis Ihr euch besser auskennt.

Der gemeinsame Nenner von Entwicklungsumgebungen, Emulatoren und Libs ist "immer" die originale Hardware (also der DS oder GBA). Wenn also der Code vom Compiler Version X nicht auf Emu Version Y läuft, dann ärgert nicht die Autoren. Jeder prüft nur ob es auf der ORIGINALEN HARDWARE funktioniert. Die Autoren der Emus und der Libs orientieren sich auch nur an DER ORIGINALEN HARDWARE. Langsam aber sicher werden jedoch alle kompatibler zum DS und damit auch untereinander. Der Autor von PAlib bevorzugt anscheinend den DUALIS Emu. Also sollte zu mindest mit dem kein Problem sein. Ich bevorzuge DeSmuSe. Jeder wie er will. Man sollte deswegen mindestens 2 Emus an Board haben.

Jetzt gehts endlich los, darauf hab Ihr gewartet.

Wir gehen auf die Seite: http://devkitpro.org/ und da in die Rubrik "Downloads und laden den "devkitPro windows installer" herunter (Eine kleine Datei). (GBAler laden hier auch Ihren aktuellsten getesteten VBA Emu!)

Wichig: Diese Datei (Merkt euch die Versionsnummer) kopieren wir uns in einen leeren Ornder mit der Bezeichnung "devkitProxxx". Nun starten wir das Teil und werden gefragt ob wir nur downloaden oder auch Installieren möchten. Wir entscheiden uns für "Download & Install". Alle Dateien werden nun in diesen Ordner geladen und wir haben immer die Original Files der Installation (Version).

Anschliessend kommt eine Abfrage was wir installieren wollen. Die Auswahl:

devkitARM: Dieses Häckchen müssen wir machen um für GBA/DS zu kompilieren.
devkitPPC: Wird nur benötigt für den Game Cube (euch überlassen).
devkitPSP: Wird nur benötigt um für die Sony Konsole zu kompilieren (euch überlassen).

Nach eurer Auswahl gehts automatisch los. Devkit wird sich in C:\devkitPro niederlassen und ich rate euch denn Ordner so zu belassen. Alle Zusatztools suchen nämlich zuerst in dem Ordner. Wenn Ihr einen anderen wählt dann bitte keine Leerstellen oder Umlaute in den Ordnernamen. Es wird auch immer automatisch die neuste Version von allem installiert, deswegen bewahren wir nachher die originalen Datein auf. Man weis nie.

Während der Download nun läuft hier weiter Infos. DevkitPro ist sozusagen das Packet an sich. Es wird nicht immer das ganze Packet geupdatet wenn was neues kommt. Oft werden auch nur spezielle Libs erneuert. Zb gibts dann ein update devkitARM. Das heist nichts anderes als das Ihr den Ordner C:\devkitPro\devkitARM einfach ersetzt mit dem Download. An dem Datum der Dateien erkennt Ihr immer das es wirklich eine neue Version ist. Davon abgesehen haben alle Teile eine eigene Versionsnummer. Wir kriegen jetzt aber eh das neusten.

Die Installation sollte komplet eigenständig ablaufen, wenns Probleme gibt hilft meisten nur (Zumindest jetzt beim ersten mal) auf einen FIX des Problems zu warten. Später machen wir noch ein Backup, nicht jetzt, aus gutem Grund. Zusätzlich habt Ihr noch eure Dateien vom Download. Wenn Ihr ein update ausführt ,solltet Ihr es nie aus dem vorherigen Ordner (Version) starten sondern einen neuen zum Download anlegen, sonst werden eure Files überschrieben.

Win2000 User sollten nun Ihre Pfade kontrolieren. Bei XP sollte es automatisch passieren.
http://devkitpro.org/setup.shtml

Nach der Installation habt Ihr streng genommen bereits eine komplette NDS/GBA Umgebung mit "Programmers NotePad" als Oberfläche. Später werdet Ihr sicher öfters PAlib und die NDSlibs benutzen, diese sind nämlich mächtiger als PAlib und Ihr habt mehr Möglichkeiten. Doch dieses Tut ist für Anfänger, trotzdem alle Links.

Neueinsteiger bitte überspringen
Ausserdem könnt Ihr devkitPro in folgende Umgebungen einbinden: Visual Studio6/ Ultra Edit/ Programmers Notepad 2/ Visual C++ Express).
http://devkitpro.org/faq.shtml

Hier das dazugehöhrige Lernzeug für C/C++ Fortgeschrittene:

http://devkitpro.sourceforge.net/devkitProWiki/ Wiki (zur Zeit Offline wegen Umbau)
http://www.double.co.nz/nintendo_ds/ Tutorial
http://devkitpro.org/links.shtml Viele LinksDS/GBA/etc)
Im Ordner C:\devkitPro\Examples gibts dann jede Menge Beispiele für DS und GBA.
Im 8ten Teil gibt es noch mehr Links zu der ndslib und anderen libs, die nun folgenden Teile drehen sich eher um ndslib/palib da gut für Einsteiger geeignet.
Neueinsteiger überspringen Ende

DS Entwickler überspringen
Nun zum GBA. Er wird hier zwar nicht behandelt doch dafür habe ich eine überraschung für euch. Ein komplettes nie veröffentlichtes Buch (444 Seiten!) zur programmierung des GBA. Viel Spass. Hier alle Links zum GBA:

http://www.jharbour.com Komplettes Buch ( rechte unter GBA/weiter unten).
http://www.gbadev.org/index.php DIE Seite zum GBA mit Forum und allem.
http://www.ngine.de/ Der Name verrät was es ist.
http://www.nocturnal-central.com/ Komplette kommerzielle Entwicklungsumgebung.
http://www.console-dev.de/visualham.html Der Standard: HAM/HEL (sehr verbreitet).
http://hel.console-dev.de/docs/
DS Entwickler überspringen Ende

Wir machen nun weiter mit PAlib:
Achtung! Es kann immer mal sein das eine aktuelle PALIB Version nicht mit der aktuellsten DEVKITPRO Version zusammen arbeitet. Lest daher im Notfall im Forum von PALIB nach welche Versionen die User dort als letzte stabile Kombination nutzen. Ausser diesem Grund wurde die letzte sichere ndslib auch in den Download von palib gepackt. Diese Wird aber natürlich dann bei einem Update von DEVKITPRO überschrieben, achtet also bitte darauf.

http://www.palib.com/

Hier laden wir uns unter "Download Palib" den "Installer" runter (PAGfx brauchen wir nicht, ist drin). Diese Datei schaffen wir dann in unseren Download-Ordner wo schon devkitPro schlummert und führen die EXE aus. Palib fragt nun nach dem Ordner und gibt auch brav schon c:\devkitpro an. Nachdem alles fertig ist und "Paused" zu lesen ist machen wir die Konsole zu und fertig. Palib enhällt übringens eine eigene lib.nds. Dies ist nur um sicherzugehen das die vorhanden lib version mit palib übereinstimmt. Ansonsten könnte es Probleme geben.

Vor den restlichen Informationen will ich euch nicht länger auf die Folter spannen. Wir gehen testen.

- Rein in den Ordner c:\devkitPro\PAlib\vham\vham.exe (Ein guter Zeitpunkt sich einen Shortcut auf den Desktop zu ziehen!)

Nun sehen wir unsere vorläufige Umgebung (später wird der ein oder andere wechseln da sie sehr spartanisch ist, ich aber Liebe das *g*)

- Wir gehen auf "File" und "Open Projekt" (nicht "open").

- Nun gehen wir auf C:\devkitPro\PAlibExamples\text\helloworld und finden project.vhw. Diese "VisualHAM Projektdatei" öffnen wir.

-Wir sehen nun links eine "MakeFile". Sie sagt dem Linker und Compiler wie und was er wo machen soll. Gerade diese make ist komplett komentiert, schaut sie euch bei Gelegenheit genauer an. Im Moment könnt Ihr die als "Muster" für eure eigenen Projekte nutzen.

- Wir interesssieren uns für den Code und kommen jetzt zum spannensten Moment. Wird es funktionieren? Werden wir eine DS Datei erhalten?

- Wir gehen auf "Projekt" dann "Execute Target" und "Build" (Faule drücken einfach F5).

Wenn jetzt unten folgendes steht:

Dann habt Ihr es geschafft.

Nun drücken wir F7 (oder "Projekt" dann "Execute Target" und "Build and Run in DeSmuMe".

Und sehen einen Emu mit unserem Programm. (Ihr könnt auch gern den Text im Code ändern und noch mal F7 drücken).

STOP!!! hiergeblieben, wir sind noch nicht fertig!

Nun machen wir alles wieder zu.

Wir kopieren den gesamten "PAlib Examples" Ordner zu unseren Downloads.
Ausserdem machen wir eine Kopie des gesamten devkitPro Ordners dazu.

So haben wir einen Ornder zum sichern in dem alle Daten für eine funktionierende Umgebung drin sind. Die Examples falls wir unsere beim üben zerstöhren. Den Ordner falls ein Update in der Katastrophe endet. Und "diesen" Ornder fassen wir ausser zu reparaturen nie mehr an.

VHAM ist übrigens auch einer der beliebtesten für den GBA. Er wurde geschrieben für die HAM lib die zusammen mit der HEL lib höchstes Ansehen unter den Entwicklern hat.

Auch DeSmuMe ist bei PAlib schon dabei wie Ihr seht. Aktuelle Versionen könnt Ihr direkt in den Ordner kopieren wenn welche erscheinen. (devkitpro/PAlib/Emulators) Benutzt Ihr einen anderen einfach die *.nds Datei mit diesem laden.

Für die 3D Beispiel müsst Ihr zuerst eine Manipulation vornehmen (siehe später). Unter PAlib\tools findet Ihr Programme die später erklärt werden. Die Beispiele sind teilweise alt, wenn also etwas nicht 100% im Emu läuft heist das nicht das eure Konfiguration schlecht ist.

Eure Projekte solltet Ihr auserhalb des Ordners speichern, so sind Updates kein Problem (wenns nicht klappt alles neu reinkopieren aus eurer Kopie des devkitPro.

Solltet Ihr beim compilieren das lesen:

Dann hat euer Pfad Leerstellen. Also bitte vermeiden. (Also nicht c:\Mein Teil\Projekte)

Hier alle Links zu PAlib:
Wiki: http://www.palib.info/wiki/doku.php?id=homepage
Auf diesem Tut baut eine Menge meines Tuts auf, also die perfekte Ergänzung.
Forum: http://www.palib.com -->Forum

und der ganze Rest:
http://www.dsdev.org/index.php oder http://www.gbadev.org/index.php das gleiche, Forum ist Pflicht
http://forum.gbadev.org/index.php

Und jetzt schaut euch ruhig um.

Wer VC++ Express als IDE benutzen will oder andere findet sowohl bei devkitpro sowie bei palib Anleitungen hierzu.

*Paris Hilton Edition


---------------------------------------------------------
Teil 5 : Goodies und Media Formate.
---------------------------------------------------------


Natürlich wäre es schön wenn der NDS mal eben mit PNG,BMP,WAV und MP3 umgehen könnte und streng genommen könnte man ja die Formate intern konvertieren. Schliesslich gibt es mp3 Player für den DS. Das Problem wäre allerdings das Speicherplatz und Rechenpower verschwendet wird, was bei Spielen anders als bei einem Player ein Problem ist. Anders als ein PC kann der DS ja dann nicht eben mal das Umgewandelte zwischenspeichern mangels Platz. Da bliebe nur Echtzeit und Streamen. Bei einem mp3 Player kein Thema aber der Tod jedes Spiels mangels Geschwindigkeit. Die Formate des DS sind aber schnell erzeugt und haben grosse Vorteile wie wir gleich sehen werden.

Vorsicht Falle. Reden wir mal wieder über Ey.boah. Hier bitten Händler "günstige" Mp3 Player für Gba/Ds an. Hier handelt es sich aber meistens um steinalte "Supercards" mit einer noch älternen 128MB Speicherkarte auf die ein kleiner Freewareplayer geschrieben wurde.(Die gibts gratis im www) Echte mp3 Player haben einen zusätzlichen Decoderchip an Bord, erst so sind mp3s mit bis zu satten 320 kbs und mpg4 Videos möglich. Die Konsole streamt dann nur das bereits decodierte Signal auf den Bildschirm. Das alte Zeug was Ihr hier überteuert ersteigern werdet, habt Ihr automatisch besser und grösser wenn Ihr euch bei einem korrekten Händler eindeckt. Also Finger weg!

Profis können übrigens locker mit der ARM9 Cpu mp3 decoden, aber dann bleibt für Games keine Power meh übrig.

Davor schauen wir uns aber auf die Schnelle ein paar Goodies des DS an, die Ihr schon mit PAlib testen könnt.

Datum und Zeit abfragen. Bei PAlib nur 2 Zeilen:

Die Variablen dazu werden bei jedem Frame abgedated und beschreiben denn Tag (1-31), Monat (1-12), Jahr (00-99), Stunde (0-23), Minuten (0-59) und Sekunden (0-59). Also nichts schweres. Wer AM/PM will muss die Stunden mit +12 (-12) umrechnen.

Bildschirmbeleuchtung mit Tastenabfrage.

Fragen?

User info. Wollt Ihr euren Spieler mit seinem Namen begrüssen, oder gleich in der richtigen Sprache. Das Menu farblich an sein Vorliebe anpassen oder im am Geburtstag gratulieren? Kein Problem. Dafür gibts PA_UserInfo. Die Variablen davon:
PA_UserInfo.Name (der Name),
PA_UserInfo.BdayDay (Geburtstag),
PA_UserInfo.BdayMonth (Geburtsmonat),
PA_UserInfo.Language (Sprache,0=japanisch/1=englisch/2=französisch/3=deutsch/etc),
PA_UserInfo.Message (Der Text der eingegeben wurde),
PA_UserInfo.AlarmHour (Stunde des Alarm),
PA_UserInfo.AlarmMinute (Minute des Alarms) sowie
PA_UserInfo.Color (Die Farbe des Menüs).

Ein Code Beispiel dazu gibts in PAlibExamples/Other. Damit kann man schon mal viel anfangen.

Das Microfon und WiFi können auch korrekt eingebunden werden. Ihr seht auch in der Wiki zu Palib nur etwa 10% von dem was alles möglich ist. Auf Palic.com gibts die gesamte Referenz der Befehle in den DOC Sektionen. (Englisch/Französisch).

Viele Spiele des DS Pausen automatisch wenn der DS geschlossen wird ohne Ihn auszuschalten. Klappt man wieder auf kann man weiterzocken. Ihr wollte das auch? Kein Problem.

PA_CheckLid() prüft den Schlieskontakt und hält alles an wenn der DS geschlossen ist. Wenn nicht gibts den Wert (1) zurück. Schmeist diesen Befehl vor PA_WaitForVBL(), VBL kommt im Anschluss. Ein Beispiel findet Ihr PAlibExamples/Other/CheckLid. Die Emulatoren ignorieren diesen Befehl oder stürzen ab da sie nicht geschlossen werden können. Sicherlich wird es aber irgendwann möglich sein dies am Emu zu emulieren. Sollten sie abstürtzen dann klammert das aus bis zum Transfer auf den echten DS.

Natürlich soll auch ein DS immer mit gleichem Tempo laufen. Das sind normalerweise 60 Fps (Bilder pro Sekunde). Damit das auch so ist haben wir die VBL Routine von PAlib. Natürlich kann diese intern manipuliert werden für Experimente. Standard ist aber 60 fps (Was man auch nutzen sollte). Hier das Grundprinzip.



Soweit mal ein paar Goodies. Kommen wir jetzt zu den Grafik und Soundformaten. Alte Amiga Hasen werden jetzt Augen machen. Erinnern wir uns an den Amiga 500. Er hatte damals bereits grossartige Grafik und Sound Möglichkeiten aber wie der DS in der normalen Ausführung nur wenig (512kb) Speicher. Die meisten rüsteten denn zwar auf 1MB auf, doch das war immer noch nicht viel. Deswegen wegen wurden auf dem Amiga platzsparende Formate entwickelt um auf kleinstem Raum beste Resultate zu erziehlen. Wenn also den älteren ab jetzt Formate und Zahlen bekannt vorkommen, dann liegt das daran das Programme wie DeluxePaint, Photonpaint, Protracker, Octamed genau die gleichen Formate benutzen. Wer also einen fähigen Amiga hat kann sich freuen, er hat alle Programme bereits im Haus. (Wer hätte gedacht das meine fast 3000 Protrackersamples noch mal zu ehren kommen? Alles feinste Ware ohne umwandeln und nichst *freu*). Aber der Reihen nach.

Soundformate und Programme

Der DS kennt nur ein Format: RAW (etwas wie wav und sehr gut für alle Geräusche uns Samples). Und einen fetten MOD Player hat PAlib schon eingebaut. Auch MODS (Musikmodule) verwenden intern RAW als Sampleformat. Da der DS also im normalen nur mit RAW arbeitet müssen wir WAV/OGG etc umwandeln. Doch dafür gibt es ein fantastisches kostenloses Programm namens "Switch":

http://www.nch.com.au/switch

Switch hat den Vorteil das man komplete Ordner "ontheFly" umwandeln kann ohne langes gefummel. Nach dem Start sollte man sofort bei FILE->Launch->WavePAD starten. Dieses ist ebenfalls gratis und wird nachgeladen und installiert.Das Programm WavePad ist quasi direkt eingebunden und erlaubt das manipulieren der Samples. Wenn Ihr zb Echo in der Musik wollt, könnt Ihr den direkt in die einzelnen Samples reinmischen und auf Stereo umwandeln etc. Was will man mehr. Die anderen Progs sind nicht nötig. Mit den beiden seit Ihr in der Soundfrage bestens ausgerüstet.

Audacity zb kann das aber auch alles, für genau diesen Zweck ist es aber zu umständlich. Wer trotzdem drauf besteht kanns also benutzen:

http://audacity.sourceforge.net/

Wenn Ihr nun umwandelt sollte das Format also RAW lauten. Wichtig ist das Ihr 8 bit signed benutzt. Mono oder Stereo ist euch überlassen. Auch könnt Ihr mehr als nur 11025 benutzen. 22050 ergibt zb hervorragende Resultate (Amiga/Protracker? *g*). Für euer Spiel später rate ich euch abzuwägen was an Grafik nötig ist und für den Sound übrig bleibt. Für kleine "Schuss-Samples" etc reicht 11025/Mono völlig aus. Das abspielen unserer Samples:


Nichts schwieriges. (Getestet auf DUALIS, was das heist solltet Ihr bereits wissen)

Achtung: Bevor Ihr jetzt die Sau rauslast und jede Menge Samples in einem Prog abspielt solltet Ihr folgendes wissen. Im Moment "backen" wir alle Sound und Grafiken direkt in den ausführbaren Programm Code (include). Das hat zur Folge das die *.nds nicht grösser sein darf als 4MB (Arbeitsspeicher). Ein Fiasko wäre die folge. Was uns also fehlt ist ein FILESYSTEM mit dem wir die Daten an den compilierten Code "anhängen" und nur bei Bedarf vom Modul "nachladen". Das kommt später. Im Moment also immer brav unter 4MB bleiben.

Kommen wir zur Musik. Mods (Module) sind Files wo im "Kopf" steht welches Sample wann abgespielt wird. Hinter diesem "Header" hängen die Samples dann praktischerweise alle dran.
Das Format stammt ebenfalls vom Amiga und die internen Samples der MODs sind ebenfalls im RAW Format. PAlib verfügt über einen Player der diese Mods abspielen kann. Wie man diese Mods selber macht ist ein eigenes Thema. Hier aber ein kostenloses Programm:

http://www.modplug.com/

Wer fertige benutzen will kann sich hier umsehen. am besten benutzt man alte 4 oder 8 kanalige Amiga/Protracker/Octamed Mods. Die gehen immer und es gibt reichlich davon:

http://www.modarchive.com/

Die Kenner packen den Amiga aus (ProTracker 4ch/Octamed 8ch). Es gibt übrigens auch legale Wege einen Amiga zu emulieren .

Der DS hat 16 Soundkanäle, sobald man den ModPlayer initialisiert werden 8 Kanäle davon reserviert. Die anderen 8 sind dann für Geräusche. Ihr könnt mit dem Modplug auch 12 oder 16 Kanäle nutzen, habt aber dann weniger für Geräusche übrig. In der Regel ist man mit 8/8 gut bedient. In einem Menü zb könnt Ihr aber Vollgas geben. . Wir schauen uns den Code an:

Fast zu einfach nicht wahr!

Grafikformate und Programme

Geben wir es zu, wir sind fette Grafiken gewöhnt, Echtfarben und riesige Auflösungen. Damit ist jetzt Schluss! Wer DS Spiele kennt weis das diese trotzdem fantastisch Aussehen und klein sind da der Grakaspeicher ja begrentzt ist. Hier also der Weg wie wir eine gute Ausbeute des Speichers erziehlen.

Zuerst müssen wir uns dran gewöhnen das eine Grafik aus 2! Dateien besteht. Aus einer Daten Datei und einer Palette. In einer normalen PC Grafik sind alle Inforamtionen enthalten, Auflösung, Pixelpositionen, Farben. Da eine PC Grafik bis zu 16 Millionen Farben haben kann macht das die Datei schon recht gross.

Bei einer DS Grafik ist auch alles inklusive, nur weis der DS nicht "welche" Farben es sind. Die stehen nämlich in der "meinBild.pal" Datei. Das Prinzip:

Nehmen wir an wir haben eine Palette mit 4 Farben (also nur 4 zur Auswahl), nämlich Rot, Blau, Grün und Gelb. Dann würde in der *.pal datei nur stehen das Wert 0 Rot ist, Wert 1 blau etc.
Nun haben wir eine Grafik von 2*2 Pixel. Da wir ja nur 4 Farben benutzen können wird die Tabelle der Farben natürlich sehr klein. Nämlich nur 4 Möglichkeiten anstatt 16 Millionen. Der Speicher bedarf schrumpft dann natürlich gigantisch da für jede Farbe ein (RGB)Wert angegeben werden muss. In unserem Fall halt nur 4.
Nun machen wir die beiden oberen Pixel Rot, die untern beiden Blau. Unsere meinegrafik.dat sieht dann so aus(vereinfacht):

Die meinBild.pal:


Da der DS 16 und 256 Farben Paletten unterstützt ist der Speichergewinn gigantisch. Doch machen wir weiter. Wenn nun das ganze geladen wird haben wir einen Würfel der oben rot ist und unten blau. Genaue Beobachter könnten nun böse gucken. "Was labert Abrexxes da! Eine 2 Farben Palette hätte gereicht, das ist auch Verschwendung!"
Das stimmt. aber wiso sollte ich die Palette nur für ein Bild benutzen. . Mein nächtes bild sieht so aus.

Na? Ich kann die Palette für alle Grakiken benutzen und spare dadurch noch mal enorm. Beispiel: Ich habe eine 256er Palette mit grünen, braunen und grauen Farben. Ich kann nun daraus einen kompletten Wald machen aus Bäumen, Sträuchern etc. Die Farben für das ganze werden nur 1! mal geladen. Doch wir sind immer noch nicht fertig. Stellen wir uns vor es wird Nacht. Alle Grafiken nochmal dunkler malen? Nix, wir nehmen nochmal alle Grafiken und wechseln nur die Palette. Ist das nichts? Natürlich kann der DS mehr als 256 Farben gleichzeitig darstellen. deswegen dürfen wir mehrere Paletten gleichzeitig nutzen (siehe unten).

Der DS kann aber nicht nur 16 oder 256 Farben nutzen sondern auch 16bit Grafiken. Dann ist die Farbe aber wieder in der Datei selbst und das ganze brauch enorm Speicher. Hier eine kleine übersicht:

16 Farben: Wird beim GBA viel benutzt, auf dem DS quasi gar nicht. Der Gba kann bis zu 16 Paletten gleichzeitig benutzen.

256 Farben: Hier kann der GBA nur jeweils eine benutzen. Der DS bringst auf 16 pro Screen also 32 insgesamt. Das macht 4096 Farben gleichzeitig pro Screen wenn nur 256er Paletten benutzt werden. (HAM-Modus Amiga)

16bit: Gba gar nicht. DS ein Vollbild pro Screen oder Sprites. Bei Sprites wird aber Speicher verschwendet. Bei Vollbild (Background) bricht das Tempo ein. Vollbild 16bit eignet sich zum Beispiel aber gut als Background für Menüs etc. Die maximale Grösse beträgt übrigens immer 1024*1024 (scrollen). Mehr verdaut der DS nicht. (Ausser wenn Ihr Tiles benutzt)

Wie wandeln wir Grafiken um? Dafür bringt PA_lib ein schönes Program namens "PAGfx". Es erledigt sozusagen alles für uns. Sprites, Backgrounds, Tiles, Maps etc. Wir finden es im Ordner Pa_Lib/Tools. Hier finden wir 4 Dateien. PAGfx.exe ist für Consolenfreaks, alles kann auch über Console ausgeführt, automatisiert, werden. Alle anderen haben mit PAGCFrontend.exe eine Oberfläche die aber das NET.Framework voraussetzt was Ihr bei Microsoft laden könnt wenn Ihr es nicht habt. Ihr habt links 4 Transparenz Farben zur Verfügung. Am besten ist wohl Magenta.

Wenn Ihr nun Grafiken habt die im PNG oder BMP abgespeichert sind UND 256 Farben haben könnt Ihr die unter Sprites hinzufügen. Ich nehme mal mario.png. es ist eine 32*64 grosse Grafik mit 256 Farben. Die Palette dazu heist 0815.pal. (Das ist für die umwandlung nicht wichtig, aber vielleicht will ich die Palette später noch mal in mein Grafikprogramm laden um andere Objekte zu erzeugen! In der PNG Datei sind die Farben ja drin.) Nun sage ich "Save and Convert". Ich erhalte folgende Files:

mario.c (alle Grafikdaten von Mario)
0815.palette.c (die Palette)
all_gfx.c
all_gfx.h (In diesen beiden stehen nachher alle Grafiken die zum Projekt gehöhren. Wir brauchen also nur die zu laden.

Genauso fügen wir alle Grafiken in unser Programm und zum schluss kriegen wir ein fertiges Paket mit allen Daten. Praktisch! Doch wir haben noch mehr, nämlich Tiles. Wer beim Begriff "Map" anfängt zu weinen, keine Angst das macht unser Helfer. Wir nehmen uns nur ein Tileset das eine 256 Farben Palette nutzt und puzzeln im Grafikprogramm alles zusammen. Dann ändern wir hier noch was, da noch was und speichern unser grosse Grafik. In unserem Programm sagen wir nur welche Grösse die Tiles haben die wir benutzt haben (oder wollen) und dann geht PAGfx hin und schnippelt die Grafik auseinander, optimiert, und legt die Map an. Wir laden mal wieder nur all_gfx.h(c).

In der Ini Datei können wir uns übrigens immer schon alle Schritte ansehen und manipulieren.

Damit vorerst genug, nun zu den Grafikprogrammen. Egal welches Ihr benutzt es muss folgendes können:
-256 Farben unterstützung
-Paletten laden, manipulieren und speichern
-Kompatibles Format (und andere).
-Pixelgenaues arbeiten

Einige kriegen jetzt schon wieder feuchte Hände und suchen den alten Amiga *g*. Ja, DeluxePaint usw haben genau das. Wer am PC los legt sollte sich nach älteren Grafikprogs umgucken, es gibt viele die dem entsprechen und kostenlos sind. Es gibt aber auch ein "perfektes", Pro Motion:

http://www.cosmigo.com/promotion/

Dieses Programm ist speziel auf unsere mobilen Freunde abgestimmt. Zum schnuppern (Paletten und soweiter) könnt Ihr euch die Demo laden (Nicht die Lite, da fehlen so schöne Sachen wie Animation). Selbst wenn euch das Prog zu teuer ist wisst Ihr anschliesend was Ihr braucht. Das Vorbild dieses Programms ist übrigens "DeluxePaint" (Oh Wunder *g*).

Natürlich gibt es auch im Internet bereits jede Menge Grafikmaterial, wer Tiles (Chipsets/Charsets) sucht wird hier fündig (Meistens im 16*16 format, also optimal für die kleinen DS und GBA Konsolen). Achtet bitte immer auf die Rechte die an den Files bestehen (Gilt für alles was Ihr runterladet):

http://rpg2000.4players.de/
http://www.rpg2kevolution.rhymeland-pfalz.com/Site/index.php
http://reinerstileset.4players.de/

Auch Soundeffekte sind unter den ersten beiden zu finden.

Wenn Ihr grosse Grafiken für den DS aufbereitet (Backgrounds etc) solltet Ihr entweder 8*8 oder 16*16 wählen. Wenn Ihr zb grosse einfarbige Flächen habt (Blauer Himmel) dann bringt 8*8 grosse Ersparnisse. Hier macht übung den Meister. Bei Tiles solltet Ihr natürlich immer die Tilegrösse angeben die Ihr auch tatsächlich verwendet habt. Kollisionen könnt Ihr direkt am Layer prüfen, effektiver und schneller ist es aber einen extra Layer anzulegen auf dem Ihr nur in einer Farbe alle Hindernisse andeutet. Das Geheimnis liegt darin denn Layer zwar abzufragen (Kollision) ihn aber "nicht" anzuzeigen.

So Leute. Ich habe in den ersten Teilen versucht so viel Info wie möglich rein zu packen. Sowohl über Hard wie Software. Was die Software angeht wird es jetzt Zeit dass Ihr euch mit dem PAlib Tutorial anfreundet. Es ist vorbild für einen grossen Teil der Zeilen die Ihr bis jetzt gelesen habt. Obwohl das ganze in englisch ist braucht Ihr es nicht mehr zu fürchten. Das meiste habt Ihr jetzt schon gelesen anderes kommt gleich. Im Original kommen dann noch jede Menge übersichtlicher Code und viel Grafiken und Tabellen dazu. Zb müste ich jetzt fast 12 Seiten über Sprites übersetzen. (Zoom, Flip, Rotage, Aplhablend etc). Der Code des Autors und seine kurzen Erklärungen sind aber so ausführlich das ich nur Teile übersetzt habe die schwieriger sind. Wer des englischen mächtig ist kann eh das meiste was jetzt noch kommt direkt nachlesen. Also ran an den Speck. Damit Ihr eine übersicht habt was ich schon beschrieben habe und was nicht mache ich einen kleinen Index:

http://www.palib.info/wiki/doku.php?id=homepage

DAY1: Installieren und Kompilieren. (Bei mir erst Teil 4 da noch Hardware bei mir drin ist)

DAY2: C lernen. (Wer lange nicht mehr drin war kann hier mal drüberfliegen, alle anderen sollten sich das ganze reinziehen. Es werden auch viele Tips zum DS gegeben. Ansonsten kommen gleich noch Links zu "C")

DAY3 Input Output (Alles über Screen, Stift Textausgabe Tasten etc, muss ich nicht erklären, ein Blick auf den Code spricht Bände)

DAY4 Sprites (Wie Ihr mit den Programen umgeht und das Prinzip habe ich erklärt, der restliche Code ist nicht schwerer als beim Sound.

DAY5 Backgrounds (Das selbe in Blau mit Tabellen,Limitierungen und Beispielen)

DAY6 Mathematisches (Zufallszahlen, Schwerkraft usw. Sollte den meisten nicht unbekannt sein, hier gibts den Code dazu)

DAY7 Sound (Habe ich komplett in diesem Teil erwähnt)

DAY8 Hardware (Das sind die Googies aus diesem Teil, ebenfalls komplett)

DAY9 File System (Bei mir der nächste Teil 6)

DAY10 3D (Kleiner Blick auf 3D, denkt daran das Ihr für das Beispiel in der PA_Config.h USE_3D definieren müsst.

DAY11 Video Funktion (Mini Tut mit Programmlink und Codezeile zum einbinden von Videos)

DAY12 Gibst zu diesem Zeitpunkt noch nicht.

DAY13 Plattform Spiel (Sehr gutes Mario Klon Tut)

Hier noch ein paar Links zu C. für komplette Neulinge:

Kauftip für alle die bei 0 Anfangen:
http://www.amazon.de/gp/product/3827265703/302-2601921-2020818?v=glance&n=299956

Guter Online Kurs:
http://www.fh-augsburg.de/informatik/vorlesungen/c_cplus/tutorial/cyris/
oder
http://www.tutorials.at/

Schaut euch auch alle Codes genau an. INT zb ist Geschichte. Wir benutzen u8 oder s16 anstatt INT. Das bedeutet unsigned8bit / signed16bit. So reservieren wir immer nur soviel Speicherplatz wie wir brauchen. Zb ist u8 Variable, eine int Variable die (unsigned8bit) den Wert von 0-255 annehmen kann.
Desweiteren ist der DS eine 32bit Maschine. Auf dieser enspricht ein signed32Bit Integer (s32) dem Datentyp "Long". Denn können wir uns also sparen etc etc....

Natürlich gibts hier noch Tonnen zu sachen über GIF 3D Texturen etc, aber das sprenngt dieses Tutorial.

Soweit dieser Teil.

---------------------------------------------------------
Teil 6 : File System.
---------------------------------------------------------


Es gibt eine Lösung namens DLDI/FATLIB . Diese wurde inzwischen in Devkitpro integiert.

Um davon zu profitieren müsst Ihr nur "fat.h" einbinden und Ihr könnt loslegen. Alles dazu :

http://forum.gbadev.org/viewtopic.php?t=10289
DLDI siehe oben.

Hier aber noch der alte Text mit PAFS der sich trotzdem noch immer gut für kleine Experimente eignet ohne komplexe DLDI Header.

Im Moment compillieren wir alles inclusive Grafiken und Sound. Das ist so als würden wir am PC eine *exe bilden in der alles drin ist (also keine weiteren Files). Somit ist für den DS alles als ausführbarer Code deklariert, und denn muss der DS nun mal komplet beim laden in den Ram schieben. Was wir brauchen ist also ein Filesystem das es uns erlaubt die grossen Dateien (Grafik/Sound) aufs Modul zu packen und bei Bedarf zu laden. Das geht im Moment nur zum Teil.
Mit dem Hilfsmittel PAFS können wir eine PAFS.GBA.DS herstellen die alle Daten enthält und mit dem Code zusammen auf das Rom geflasht wird. Leider klappt das aber nur mit Daten die nicht in Echtzeit dargestellt werden müssen. Wir können also keine 16MB Grafikdaten ablegen.

Der einzige Vorteil im Moment ist das wir nur den Code kompilieren müssen (schneller) und das PAFS Packet in den Speicher laden, und zwar komplett. Dadurch haben wir aber auch wieder unsere 4MB Grenze. Auch können so andere User Daten verändern oder einfügen ohne das wir den ganzen Quellcode preisgeben. (Modplayer/Bildbetrachter etc).

Zur Zeit wird daran gearbeitet diesen Umstand zu beheben. Wer trotzdem schon mal reinschnuppern will der sollte sich DAY 9 der Palib Wiki ansehen. Ansonsten warten wir ab bis PAFS optimiert wurde oder eventuel eine neue lib verfügbar wird die sich darum kümmert. Ich werde das ganze dann hier beleuchten. Zusammen mit 3D ist das im Moment das Hauptziel der Macher.

http://www.palib.info/wiki/doku.php?id=day9

Emulatoren kommen übrigens nur mit PAFS klar wenn es in den RAM geladen wurde.
Ausserdem gibt PAFS beim auslesen der Dateien einen POINTER zurück. Die einzelnen Files müssen anschliessend über diese geöffnet werden! Denk daran.

Trotzdem solltet Ihr nicht entmutigt sein das 4MB sind eine ganze Menge. In den Zeiten des Amiga hatten solche Hammer Games wie Turrican III gerade mal ca 1,6MB. Wenn Ihr erst mal mit den DS Formaten arbeitet werdet Ihr sehen wieviel 4MB sein können und Abhilfe kommt sicher bald.

---------------------------------------------------------
Teil 7 : Tips und Tricks
---------------------------------------------------------


Hier nun noch Infos quer durchs Feld sowie Tips und Tricks.

DS und DS Lite.

Der DS Lite ist nur eine verbesserte Version des "alten" DS.
- Er ist leichter (218 statt 275g).
- Kleiner (133*74*22 statt 149*85*29 (BxHxT)).
- Das Micro ist in der Mitte statt ganz unten.
- Start und Select sind rechts unten statt rechts oben.
- Die Helligkeit des Bildschirm ist im Menü regelbar (4 Stufen).
- Die Bildschirme sind heller und schärfer.
- GBA Module stehen beim neuen etwas hervor statt ganz zu verschwinden.

Für den Programmierer ändert sich nichts. Die Hardware und die Power ist die gleiche. Hier gibt es keinen Unterschied.

Firmware

Es gibt im Moment 5 Versionen der Firmware. Ein Updaten ist nicht nötig. Um die Firmware zu flashen muss im inneren des DS ein Kontakt (Lötbrücke) hergestellt werden. Diese solltet Ihr nach dem Test (nur mit original Spiel !!!) auch wieder entfernen um euren DS vor bösartigen Angriffen zu schützen.

Updates

Wie öfters erwähnt wird fleisig an 3D und Filesystem gearbeitet, haltet euch immer auf dem laufenden was updates angeht. Installiert diese aber wie gesagt nicht "blind" sondern wartet immer bis von all euren Utensilien (kompatibele) Versione erschienen sind. Was 3D angeht gibt es bereits Fortschritte.

Module:

Dank findiger Werbeleute haben wir heute gigantische 1024 Mbit Module! Bleiben wir logisch, teilen wir denn Blödsinn durch 8 und sagen 128 Mbyte (MB). Zugegeben ein dicker Sticker auf der Verpackung "Gigantische 1024Mbit Modul" wirkt besser als ein kümmerliches " 128Mb Modul". Wir sollten froh sein das Sie nicht in 1/4 Bit rechnen. ("Dieses Spiel hat gigantische 16384 1/16tel Bit *g*)

Beim DS sind gängige Modul grössen 8/16/32/64/128MB (Beim GBA 8/16/32). Natürlich kostet jedes Modul auch in der Herstellung einen anderen Preis. Sollte euer Game also 32.5 MB haben, überlegt ob Ihr nicht vielleicht eine Grafik weglassen könnt und ein billigeres 32MB Modul benutzt, anstatt ein 64er. Sollte später interesse eines Produzenten bestehen ist das von Vorteil. (Weniger Kosten, höherer Gewinn) Solltet Ihr ein Game von 4,1MB haben und im Freeware-Bereich veröffentlichen, dann schaft es auch unter 4MB. So können Leute die mit WiFi übertragung arbeiten es auch zocken (4MB Limit). Zwar ist WiFi für den Entwickler nicht unbedingt beste Wahl, es gibt aber noch viele andere Nutzer die mit WiFi arbeiten.
GBA und DS haben nebenbei keine Regionalcodes.

Release.

Ich weise darauf hin das beim NDS nur Projekte durch Nintendo abgesegnet werden die mit dem offiziellen SDK erstellt wurden. Das bedeutet das euer Game vom Publisher (wenn er interesse hat) nur als Prototyp angesehen wird. Das "neuschreiben" des ganzen auf dem offiziellen SDK ist unvermeidlich. Mehr Info gibt es von mir nicht, nur damit Ihr vorgewarnt seit.

Solltet Ihr die Idee eures Lebens haben und mit "einer fertigen Beta" zu einem Publisher Kontakt aufnehmen gibt es Features die euer Programm haben sollte oder sogar muss damit die Nintendo Qualitätskontrolle auch happy ist. Hier die mir bekannten und empfohlenen:

- Da der DS nicht wie der GBA einen Schalter für das Licht hat sollte es im Menü eine Möglichkeit geben dieses ein und abzuschalten.
- Ein Spiel sollte zu "jedem" Zeitpunkt eine "Pause" ermöglichen.
- Beim schliessen des DS sollte das Programm in den Standby Modus schalten.
- Der Spieler sollte zu jedem Zeitpunkt in das Menü kommen (eventuell kombinieren mit Pause).
- Die Menüs sollten für den Touchscreen über grosse Schaltflächen verfügen (Zwingt den User nicht den PEN zu ziehen um Minihäckchen zu machen wenn nicht unbedingt nötig).
- Vor jeder schwerwiegenden änderung im Menu eine Sicherheitsfrage einbauen.
- Auch nachträglich das ändern der Sprache ermöglichen.
- Denn Spieler bei WiFi nachfragen ob er dies auch sicher wünscht.
- Wird nur auf einem Bildschirm aktiv gespielt, dem Spieler eine Auswahl erlauben ob er das Spielfeld oben oder unten haben will.
- Dem Spieler erlauben einzelne Soundausgaben getrennt abzuschalten (Musik/Geräusche/Sonstiges).

Alle diese Sachen sind leicht umzusetzten, baut Sie also lieber sofort ein als später im ganzen Code zu wühlen und schlimmstenfalls zum umbauen gezwungen werdet.

Release 2.

Publisher sind nicht von Natur aus bösartig sondern inverstieren viel Geld in Projekte (gezwungen) und sind daher immer vorsichtig. Hier ein paar kleine Tips zur Pflege und Haltung von Publishern.

- Wenn Ihr an dem Punkt seit an dem Ihr glaubt das euer Spiel was grösseres werden könnte verteilt nicht wie wild komplette Betas im Internet. Mach deine Test im kleinen (nicht öffentlichen) Kreis. Sonst ist der P. nicht happy wenn schon alles im Internet rumsteht.

- Macht keine Rundmails eures Spiels sondern schickt es nur an "einen" P. Diese Leute sind nämlich auch untereinander gut informiert. Haben alle das gleiche auf dem Schreibtisch rumliegen füllen Sie sich verar*.
Erst wenn einer kein Interesse zeigt geht zum nächsten. Lasst Ihnen auch Zeit zum antworten, das geht nicht im 24 Stunden-Rytmus.

- Schickt euer Spiel auf CD-Rom in allen Formaten (*ds *gba.ds incl funktionierendem Emu), sowie mit 3 Infoblättern. (Euer Vorstellungsbrief mit angebrachtem Respekt, eine kleine Beschreibung des Spiels mit Anweisung und ein Blatt mit schönsten Screenshots). Das Spiel sollte zu dem Zeitpunkt fertig sein, nicht etwa ein 1 Level Game (So könnts mal aussehen).

- Solltet Ihr Grafiken oder Musik verwenden wo das Urheberrecht nicht einwandfrei geklärt ist weist "sofort" darauf hin. Das ist kein Beinbruch, muss aber dem P. bekannt sein damit er reagieren kann und den Mangel beheben wenn er Interesse hat. Er kann so auch besser abschätzen was noch investiert werden muss.

- Wenn der P. interess hat, wird er in den meisten Fällen noch Wünsche haben. Zwar könnt Ihr dann mit dem P. diskutieren, letztendlich hat er aber immer Recht. Auch könnte es sein das er noch einen Grafiker hinzuzieht um die Grafik zu optimieren. Bevor Ihr dann etwas unterschreibt mit einem Abgabedatum solltet Ihr ehrlich zu euch selbst sein und abwägen ob Ihr die änderungen auch in der Zeit realisieren könnt. Damit der P. nicht mit längeren harten Gegenständen bei euch auftaucht solltet Ihr diese Angaben dann auch einhalten.

- Ist alles zur Zufriedenheit kommt für den Publisher das grosse Geld ausgeben. Cover, Dokumentation etc müssen produziert werden. Das Game muss ins Nintendo Testcenter wo es geprüft wird. Das kostet alles Geld auch wenn das Spiel von eurer Seite aus "quasi" fertig ausgeliefert wurde. Natürlich will der P. dieses Geld zuerst wieder einnehmen. Seit also bei eurer Vorstellung des Gewinns für euch realistisch.

- Sei immer ehrlich und korrekt. Klopf auch nicht direkt bei EA an sondern zuerst bei kleineren Studios. (Auch Nintendo selbst produziert wie Ihr sicher wisst).

- Sobald Ihr was unterschrieben sollt, lest es aufmerksam und genau. Nehmt euch am besten ein paar Stunden Zeit um drüber nachzudenken.

Praxis:

Zockt so viele Games wie möglich am DS um Erfahrungen zu Sammeln wie man Menüs organisiert, animationen darstellt, die Musik einbindet etc etc, macht euch ruhig Notizen was bei den einzelnen Games euch gefallen hat und was weniger. So kriegt Ihr auch ein Gefühl für die Möglichkeiten das DS und wie Ihr sie am besten ausnutzt. Schaut euch im Internet Screenshots der neuen Games an und studiert die Grafiken. Auch hier kommt so manche Idee.

http://www.nintendo-europe.com/NOE/de/DE/games/index.jsp

Dokumentation:

Druckt euch ruhig das ein oder andere aus. Ein Ordner mit wichigen Infos ist manchmal praktischer als im Internet rumzuwühlen und eine gute Bett-Lektüre.

Linux:

Ja, auch der Pinguin hat inzwischen seinen Weg auf den DS gefunden, alle Infos hier:

http://dslinux.org/
http://www.henrys.de/daniel/linux/base.htm

Möglichkeiten:

Hier ein schneller überblick was im Moment möglich ist laut Stand der Entwicklungswerkzeuge:

C/C++ Programmierung : JA
Touchscreen einbinden: JA
DualScreen ansteuern: JA
Microfon einbinden: JA
Userinfos einbinden: JA
Tasten einbinden: JA (alle)
Direktes Ansteuern der Hardware: JA (aber noch keine 100%)
Zugriff auf Speichermanagment: JA
Schreibzugriff auf Module: JA
Filesystem einbinden: JA
Hardwareunterstützung 2D: JA
Hardwareunterstützung 3D: JA
Sound einbinden: JA
Musik einbinden: JA
Hilfswerkzeuge 2D verfügbar: JA
Hilfswerkzeuge 3D verfügbar: JAIN (in Arbeit/3ds vorhanden)
Systemauslastung: JA (100%)

Wer 3D machen will sollte einen Blick in den Devkitpro Ordner werfen. Hier liegen die Nehe Tuts zu opneGL komplett im NDS Format vor. übrigens ist anders als behauptet sehr wohl auf beiden Bildschirmen des DS 3D möglich. Die FPS geht dann aber von 60 runter auf 30. Wer mal hinter die Scheibe gucken will, hier alle Daten.

Achtung! Hardcore! Nicht unter 1.2 Promille angucken.
http://nocash.emubase.de/gbatek.htm

---------------------------------------------------------
Teil 8 : Das Ende?
---------------------------------------------------------

So, ich habe nun versucht euch einen überblick über alles zu verschaffen. Wäre das hier ein "Kompendium" wäre es die ZIP Version davon. Damit will ich sagen das es noch viel zu den einzelnen Themen zu wissen gibt. Ich kann euch nicht alles erklären (Auch ich bin erst seit kurzem beim DS), ich hoffe aber das ich euch so zumindest den "Sprung ins kalte Wasser" ersparen konnte. Ihr habt nun schon jede Menge Hintergrundwissen rund um DS (und ein wenig GBA) und solltet euch in der harten Welt zurechtfinden. Ich wünsche euch auf jeden Fall viel Erfolg und freue mich auf eure Ideen.

Fragen hierzu könnt Ihr normal im Forum stellen unter den Betreffen Themen. Vieles ist beim NDS und GBA nicht anders als beim PC. Ein Quadrat hat auch auf dem DS 4 Ecken. Sollte es grössere Neuigkeiten geben erweitere ich dieses Tut und gebe euch bescheid.

Zuletzt noch meinen Dank an alle Entwickler die sich um den DS kümmern und uns die ganzen Werkzeuge zur Verfügung stellen, ("Dreams can come true") und allen Mitgliedern des Forums die mich mit Lob zum weiterschreiben animiert haben. (Thanks Leute)

cu

==============================================
Zusatz: Weitere Emus in Vham.

Zuerst legen wir uns zb für DUALIS einen Ornder inAlib/Emulators/Dualis an und kopieren denn emu hier rein. (Es ist wichtig den Unterornder anzulegen, also nicht einfach in Emu reinschmeisen.

Um Dualis von Vham ohne ROM zu starten öffnen wir die Datei : vham/config/tools.ini und fügen dies hinzu:

Für F8 könnt Ihr nun noch zb "Shortcut" auf 119 einstellen

Um zu compilieren und zu starten:vham/config/targets.ini

Auch hier könnt Ihr noch einen "Shortcut" einsetzen

Jetzt findet Ihr "External Tools"-->Launch Dualis und "Projekt-->Execute Target"-->Build an run in Dualis.
Alternativ lasst Ihr "make" weg um nur mit dem aktuellen Rom zu starten (Run in Dualis). Auf diesem Weg könnt Ihr alle emus (auch Gba) einbinden. Gbaler müssen natürlich die Pfade Ihres Vham benutzen und den richtigen Launcher angeben.

==============================================
Und noch mehr Links!

N3D 3D Hardware Layer : http://n3d.console-dev.de/docs/main.html (direkte Schnittstelle zu ndslib)
Drunkencoder payk : http://www.payk.drunkencoders.com/ (Interessante Projekte)
Kleevahs Homepage : http://www.zawiarr.com/NDS/ (mod gefällig?)
NDS Welt : http://www.ndswelt.com/ (immer mal coole Infos)
La france : http://www.dev-fr.org/ (da sind Sie!)
Ndslibverzweifler? : http://www.double.co.nz/nintendo_ds/ (Tutorials)
Formatgeil? : http://www.bottledlight.com/ds/index.php/Main/HomePage (noch mehr specs)

==============================================
Nein, ich korrigierr keine Schreibfehler !