Die Form des Blog’s ist nun für die eigentliche Zielsetzung zu unübersichtlich geworden…darum zieht der Teil in die Projektecke unserer Homepage um: PSP-Homebrew-Projektecke.

Noch ist nicht der gesammte Kontekt transferiert…wenn dies abgeschlossen ist, wird dieser Blog hier “dicht” gemacht….

Texturen verwalten

Immer wieder , wenn wir 3D szenen auf der PSP darstellen wollen, werden wir die verschiedensten Texturen zum Einsatz bringen. Da macht es Sinn sich darüber Gedanken zu machen, wie wir diese am besten in unserer Homebrew verwalten. Die GU der PSP bringt hier “leider” keine Verwaltungsfunktionen mit. Darum werden wir hier eine sehr einfache Variante in Form einer Texterverwaltungsklasse selber erstellen. Ein paar Grundüberlegungen:
1. die Texturen sollen zunächst nur von PNG Bilddateien gelesen werden
2. ein und das selbe Bild soll als Textur nur einmal geladen werden
3. geladene Texturen sollen individuell wieder freigegeben werden können um Speicher zu sparen
4. die Texturen sollen ge-swizzled werden
5. die Klasse soll einfach erweiterbar sein, zBsp. um Laderoutinen für JPG oder andere Bildformate

Dies sind ein paar gute Rahmenbedingungen. Machen wir uns nun ans Werk. Wir erstellen eine neue Klasse mit dem Namen ClTextureMgr. Im Header definieren wir zunächst ein paar Beschränkungen, wie die maximale Größe einer Textur, die sich auf 512×512 Bildpunkte beschränkt (mehr kann die GU nicht verarbeiten). Zusätzlich eine Struktur, in der alle wichtigen Daten einer Textur die wir verwalten wollen abgelegt sind.

/*
 * TextureMgr.h
 */      

#ifndef TEXTUREMGR_H_
#define TEXTUREMGR_H_      

// Maximale größe einer Textur und anzahl Texturen die verwaltet werden sollen
#define TEX_MAX_WIDTH  (512)
#define TEX_MAX_HEIGHT (512)
#define MAX_TEX_COUNT  100      

/*
 * Definition einer Struktur die alle daten einer Textur enthält
 * die hier verwaltet werden soll
 */
typedef struct Texture{
	unsigned int id; //ID der Textur
	char*        name; //Name der Textur/Bilddatei
	int          type; //Typ der Textur - siehe GU_PSM* Enums
	int          width, height; //Breite und Höhe der Textur als Potenz von 2
	int          stride; //Pufferbreite für Zugriff auf Texturdaten als Potenz von 2
	bool         swizzled; //WAHR wenn Texturdaten ge-swizzled sind
	void*        data; //Zeiger auf die Bilddaten der Textur
}Texture;

Nun folgt die eigentliche Definition der Klasse. Sie wird als Singleton ausgeprägt und kann somit nicht direkt instanziiert werden. Dies vereinfacht die Verwaltungsaufgaben der Klasse. Es müssen also 2 statische Methoden zum holen und zum abräumen der Singleton-Instanz erzeugt werden. Alle weiteren Methoden werden dann Instanz basiert ausgeprägt. Die Definition sieht dann folgendermaßen aus.

class ClTextureMgr {
public:
	/*
	 * Statische Methoden für den Singleton Zugriff
	 */
	static ClTextureMgr* getInstance();
	static void freeInstance();     

	/*
	 * Laden einer Textur aus einer PNG Datei
	 */
	Texture* loadFromPNG(const char* filename);     

	/*
	 * Liefert die verwaltete Textur anhand der ID
	 */
	Texture* getTexture(unsigned int id);     

	/*
	 * Freigeben der Ressorcen für eine Textur
	 */
	void freeTexture(unsigned int id);     

protected:
	/*
	 * Texturdaten "swizzlen"
	 */
	void swizzle(unsigned char* out, unsigned char* in, unsigned int width, unsigned int height);
	/*
	 * Konstruktor ist protected um direkte Instanziierung zu verhindern
	 */
	ClTextureMgr();
	virtual ~ClTextureMgr();     

	/*
	 * es folgen die Member-Variablen zur Klasse
	 */
private:
	static ClTextureMgr* _instance; //die singleton Instanz
	int managedTextures; //Anzahl verwalteter Texturen
	Texture* textures;   //Liste aller verwalteten Texturen
};     

#endif /* TEXTUREMGR_H_ */

Kommen wir nun zur Implementierung der Klasse. Den Start bildet hier eine kleine - von der Klasse losgelöste - Hilfsroutine um von einer gegebenen Zahl die nächst höhere Zahl als Potenz von 2 zu bestimmen (das haben wir schonmal gesehen ). Daneben sind die statischen Methoden für die Verwendung der Klasse als Singleton implementiert.

/*
 * TextureMgr.cpp
 */    

//die notwendigen Includes
extern "C"{
#include <malloc.h>
#include <stdlib.h>
#include <png.h>
#include <psptypes.h>
#include <pspgu.h>
}    

#include "TextureMgr.h"    

/*
 * eine einfache Hilfsfunktion. Lokal und statisch...
 */
static int getNextPower2(int width)
{
	int b = width;
	int n;
	for (n = 0; b != 0; n++) b >>= 1;
	b = 1 << n;
	if (b == 2 * width) b >>= 1;
	return b;
}    

//Am Anfang ist die Singleton instanz nicht erzeugt
ClTextureMgr* ClTextureMgr::_instance = 0;    

ClTextureMgr::ClTextureMgr() {
	//der Konstruktor initialisiert die Datan
	this->managedTextures = 0;
	textures = (Texture*)malloc(MAX_TEX_COUNT*sizeof(Texture));    

}    

ClTextureMgr *ClTextureMgr::getInstance()
{
	if (!_instance) {
		_instance = new ClTextureMgr();
	}    

	return _instance;
}    

void ClTextureMgr::freeInstance(){
	if (_instance){
		delete(_instance);
	}
}

Der nächste Schritt ist die Methode zum laden eines PNG Files als verwaltete Textur. Da bereits an vielen anderen Stellen das laden der PNG Datei beschrieben und auch als Code dargestellt wurde, und weil der original Code Teil des PSPSDK ist, werde ich diesen hier aussparen, wohl aber den für den Texturverwaltungsteil wichtigen Part zeigen.

Texture *ClTextureMgr::loadFromPNG(const char *filename){
	//Befor wir das File laden, prüfen ob es schon eine Textur
	//mit dem selben Namen gibt, wenn ja eben diese Textur zurück liefern
	for (short t=0;t<managedTextures;t++){
		if (textures[t].name){
			if (strncmp(filename, textures[t].name, strlen(filename))==0){
				return &textures[t];
			}
		}
	}
	//es ist wirklich eine neue Textur, also diese Laden und die Daten füllen
	managedTextures++;
	if (managedTextures >= MAX_TEX_COUNT) return NULL;   

	// get the pointer of the new texture data structure
	Texture* newTex = &textures[managedTextures-1];
	newTex->name = (char*)malloc(strlen(filename));
	strcpy(newTex->name, filename);   

/*********************************************************
 * hier erfolgt nun das Laden des PNG Files und das Ablegen der Daten im
 * Speicher für diese Textur, sollte hier ein Fehler passieren wird NULL zurück-
 * gegeben.
 *********************************************************/   

	//vorbereiten für die Rückgabe der Textur
	newTex->id = managedTextures;   

	newTex->swizzled = false;
	//veruche die Texturdaten zu swizzlen
	//Speicher für die neuen Daten besorgen
	void* swizzleData = malloc(sizeof(u32)*newTex->stride*newTex->height);
	if(swizzleData){
		swizzle((unsigned char*)swizzleData, (unsigned char*)newTex->data, newTex->stride*sizeof(u32), newTex->height);
		newTex->swizzled = true;
		//Speicher der originalen Daten freigeben
		free(newTex->data);
		newTex->data = swizzleData;
	} else
		newTex->swizzled = false;   

	return newTex;
}

Swizzle

Das nun schon oft erwähnte Wort bedeutet direkt übersetzt: Bauernfängerei bzw. mit dem Zusatz “Stick” bedeutet es Rührstab. Letzteres trifft hier eher zu. Die Daten der Textur sind im Normalfall ja in einem Datenpuffer ordentlich in Reihenfolge der Bildpunkte abgelegt. Des Swizzle-Verfahren rührt diese Bildpunkte so “durcheinander” dass die Daten nicht mehr so abgelegt sind wie sie auf dem Bildschirm zu sehen sind, sondern optimal von der GU zugegriffen werden können. Das ganze bringt einen großen Geschwindigkeitsgewinn beim Arbeiten mit Texturen.
Eine leicht lesbare - nicht auf Performance getrimmte - Swizzle-Routine wird in unserer Textur-Verwaltungsklasse verwendet:

void ClTextureMgr::swizzle(unsigned char* out, unsigned char* in, unsigned int width, unsigned int height)
{
   unsigned int i,j;
   unsigned int rowblocks = (width / 16);  

   for (j = 0; j < height; ++j)
   {
      for (i = 0; i < width; ++i)
      {
         unsigned int blockx = i / 16;
         unsigned int blocky = j / 8;  

         unsigned int x = (i - blockx*16);
         unsigned int y = (j - blocky*8);
         unsigned int block_index = blockx + ((blocky) * rowblocks);
         unsigned int block_address = block_index * 16 * 8;  

         out[block_address + x + y * 16] = in[i+j*width];
      }
   }
}

Abschließend und der Vollständigkeit halber die Methode um eine verwaltete Textur einer bestimmten ID zurückzuliefern, eine Textur freizugeben und den Klassendestruktor.

Texture *ClTextureMgr::getTexture(unsigned int id){
	//Prüfen das die ID auch valide ist
	if (id > managedTextures){
		return NULL;
	}  

	return &textures[id-1];
}  

void ClTextureMgr::freeTexture(unsigned int id){
	Texture* text = &textures[id-1];
	if (text){
		free(text->data);
		free(text->name);
		text->data = 0;
		text->name = 0;
	}
}  

ClTextureMgr::~ClTextureMgr() {
	//Allen reservierten Speicher freigeben
	for (int t=0;t<managedTextures;t++){
		if (textures[t].data) free(textures[t].data);
		if (textures[t].name) free(textures[t].name);
	}
	if (managedTextures)
		free(textures);
}

Schlagworte die hier oft in diesem Zusammenhang aufgeführt werden sind SOAR oder LOD. Was dies ist und welche Methodik zur Optimierung ich gefunden habe (im Internet) stelle ich in diesem Bereich vor. Neben der theoretischen Abhandlung werde ich dort auch meine Ideen für die PSP Implementierung bereitstellen (zur Zeit noch in Arbeit).

Unabhängig davon können aber die sich an diese Überlegungen anschließenden nächsten Schritte in unserer Landschaft (Textur, Bewegung etc.) umgesetzt werden.

Als Vorbereitung für diesen Teil legen wir zunächst ein neues Projekt mit dem Namen  GuLandscape in Eclipse an. Die ersten Schritte sind nun ein Makefile in diesem Projekt zu erstellen, eine Applikationsklasse zu definieren und die main.cpp zu erstellen. Doch nochmal langsam der Reihe nach.

1. Das Makefile:

TARGET = GuLandscape
OBJS = main.o GuLandscapeApp.o
INCDIR =
CFLAGS = -G0 -Wall -g
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)
BUILD_PRX = 1
LIBDIR =
LDFLAGS =
LIBS = -lstdc++ -lpsphbc -lpspgum -lpspgu -lpng -lz -lm
EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = Gu Landscape
PSP_LARGE_MEM=1
PSP_FW_VERSION=500
PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak

2. Die neue Applikationsklasse ClGuLandscapeApp:

*
* GuLandscapeApp.h
* Author: andreborrmann
*/

#ifndef GULANDSCAPEAPP_H_
#define GULANDSCAPEAPP_H_
#include <3dHomebrew.h>
class ClGuLandscapeApp : public Cl3dHomebrew {
public:
/*
* die Methoden zum erzeigen und aufräumen der Singleton Instanz der
* Applikationsklasse
*/
static ClGuLandscapeApp* getInstance();
static void releaseInstance();
/*
* Überladen der Initi-Routine
*/
bool init();
protected:
ClGuLandscapeApp();
virtual ~ClGuLandscapeApp();
/*
* Überladen der Render Methode
*/
void render();
static ClGuLandscapeApp* _instance;
};
#endif /* GULANDSCAPEAPP_H_ */

/*
* GuLandscapeApp.cpp
*/
extern “C”{
#include <pspgu.h>
}
#include “GuLandscapeApp.h”
ClGuLandscapeApp* ClGuLandscapeApp::_instance = 0;
ClGuLandscapeApp* ClGuLandscapeApp::getInstance(){
 if (!_instance){
  _instance = new ClGuLandscapeApp();
 }
 return _instance;
}
void ClGuLandscapeApp::releaseInstance(){
 if (_instance){
  delete(_instance);
  _instance = 0;
 }
}
bool ClGuLandscapeApp::init(){
//zuerst die Super-Methode
if (!Cl3dHomebrew::init()) return false;
//hier nun die eigene Initialisierung…
return true;
}
void ClGuLandscapeApp::render() {
}
ClGuLandscapeApp::ClGuLandscapeApp() {
}
ClGuLandscapeApp::~ClGuLandscapeApp() {
}

3. Die main.cpp

/*
* main.cpp
*/
extern “C”{
#include <pspkernel.h>
}
#include “GuLandscapeApp.h”
PSP_MODULE_INFO(”GU Landscape”, 0, 1, 1);
PSP_MAIN_THREAD_ATTR(PSP_THREAD_ATTR_USER);
PSP_HEAP_SIZE_KB(-1024);
int main(int argc, char* argv[])
{
ClGuLandscapeApp* myHomebrew = ClGuLandscapeApp::getInstance();
if (myHomebrew->init()){
myHomebrew->run();
myHomebrew->exit();
}
ClGuLandscapeApp::releaseInstance();
sceKernelExitGame();
return 0;
}

Das war nun das Rahmenwerk für unsere neue Homebrew. Nun schauen wir uns den Teil an indem wir aus einer in einer Höhenkarte abgelegten Landschaft eine 3 dimensionale virtuelle Welt erschaffen. Ähnlich wie beim Ansatz im Voxelspace gehen wir dabei davon aus dass die X und Y Werte des Bildes die Ausdehnung der Landschaft in Breite und Tiefe  und der Farbwert die Höhe beschreiben. Um unsere neue Homebrew möglichst übersichlich zu halten, werden wir die Umwandlung des 3D Terrains aus einer Höhenkarte und die Darstellung desselben in einer eigenen Klasse kapseln. Dadurch bleibt die Applikationsklasse klein und erweiterbar für weitere Funktionen die wir hier nach und nach - quasi Modular - Hinzufügen können.

Das Terrain

Für die Abbildung des Terrains legen wir eine  neue Klasse mit dem Namen ClGuTerrain an. Diese Klasse wird nicht von einer anderen Abgeleitet. Die Klasse soll folgendermaßen aufgebaut sein:
Im Konstruktor übergeben wir den Dateinamen (.png) der Höhenkarte die maximal 512×512 Bildpunkte groß sein darf. Hier werden die einzelnen Bildpunkte aus der Datei extrahiert und in einem Array mit ihren Eigenschaften abgelegt.
In einem zweiten Schritt werden aus diesen Punkten die von der GU verarbeitbaren Vertices erstellt und zu einer Vertexliste zusammengesetzt. Dabei werden wir nicht wie in unserem ersten Beispiel ein enzelnes Dreieck erstellen, sondern die Landschaft in viele viele Dreiecke aufteilen. Dabei wird ein (quadratischer) Bereich der virtuellen Landschaft der aus 4 benachbarten Punkten besteht durch genau 2 Dreiecke dargestellt - im Detail zeigen das die Bilder die etwas weiter unten zu sehen sind.

Die Definition der neuen Klasse:

/*
* GuTerrain.h Die Klasse kapselt die Beschreibung und Darstellung eines 3D Terrain
* basierend auf einer Hightmap PNG Datei
*/
#ifndef GUTERRAIN_H_
#define GUTERRAIN_H_
/*
* Struktur zur Definition eines Punktes im Terrain
*/
typedef struct TerrainPoint{
int x, y; // Koordinaten
int height; // Höhe des Punktes
int color; // Farbe des Punktes
}TerrainPoint;
/*
* Struktur zur Definition eines GU Vertexes
*/
typedef struct Vertex {
int color;
float x, y, z;
}Vertex;
class ClGuTerrain {
public:
/*
* Der Konstruktor erhält den Filenamen der Höhenkarte
* aud dessen Basis das 3D Terrain erzeugt
*/
ClGuTerrain(const char* heightMapFile);
virtual ~ClGuTerrain();
/*
* Render Methode für das Terrain
*/
void render();

protected:
int width, height; //Größe des Terrains
TerrainPoint* terrainPoints;
Vertex* mesh; //Das Vertex-Netz des Terrains
int vertexCount;
/*
* Generierung der GU Vertices für das Terrain
*/
void generateMesh();

/*
* Laderoutine die ein PNG lädt und die Bilddaten zurückliefert
* der benötigte speicher wird in der Methode reserviert
*/
bool loadPNG(const char* fileName, void** data);
/*
* Diverse Daten sollten der Einfachheit halber immer in größen einer Potenz von 2 abgelegt
* sein. Diese Methode liefert von einer Zahl die nächstgrößere potenz von 2 - also 2 hoch n
*/
int getPowerOf2(int value);
};
#endif /* GUTERRAIN_H_ */

Die Implementierung dieser Klasse zeige ich nun Schritt für Schritt. Die Methode zum laden des PNG Files bedarf nun keiner großen Eklärungen mehr, da wir das bereits bei der Voxellandscape benutzt haben. Der Konstruktor ruft zunächst diese Methode auf um das Bild zu laden und extrahiert die Bilddaten dann in die Liste der Terrain Punkte.

/*
* Die notwendigen Header Files
*/
extern “C”{
#include <stdio.h>
#include <png.h>
#include <malloc.h>
#include <psptypes.h>
#include <pspgum.h>
#include <pspgu.h>
}
#include “GuTerrain.h”
ClGuTerrain::ClGuTerrain(const char *heightMapFile){
//Laden des Höhenkartenbildes und die Punkte extrahieren
 int* altitude;
terrainPoints = 0; if (loadPNG(heightMapFile, (void**)&altitude)){
// Nun erzeugen wir die Punktinformationen welche die Landschaft aufspannen
  // diese werden später in ein GU 3d “Drahtgitternetz” (mesh) umgewandelt.
  this->terrainPoints = (TerrainPoint*)malloc(width*height*sizeof(TerrainPoint));
  for (int x=0;x<width;x++){
   for (int y=0;y<height;y++){
    terrainPoints[x+width*y].x = -width/2 + x; //das Terrain soll im virtuellen Raum zentral Platziert sein
    terrainPoints[x+width*y].y = -height/2 + y;
    terrainPoints[x+width*y].height = 255 & altitude[x+width*y];
    terrainPoints[x+width*y].color = altitude[x+width*y];
   }
  }
// den Speicher des Bildes freigeben, da er nun nicht mehr gebraucht wird.
  free(altitude);
// nun die Punkte in GU Vertices konvertieren
generateMesh();
 }
}

Der nächste Schritt wird nun die Generierung der sogenannten Mesh werden, also des “Drahtgitter” Modells wie man es vielleicht aus 3D Modellierungsprogrammen kennt. Im Grunde besteht dieses Drahtgitter wie schon erwähnt aus Dreiecken. Nun wird jedes Dreieck durch 3 Punkte definiert. Das bedeutet, dass wir bei einer Höhenkarte von 4×4 Punkten bereits 3×3 Quadrate von jeweils 2 Dreiecken mit jeweils 3 Punkten, also 18×3 - 54 Punkte für die Darstellung brauchen. Es gibt hier eine Optimierungsmöglichkeit die uns sowohl Speicherplatz beim Erzeugen der Mesh spart als auch Performancevorteile bringt. Es kommt ein sogenannter  Dreiecksstreifen (TriangleStripe) zum Einsatz. Dabei werden die Punkte so angeordnet, dass die ersten 3 Punkte ein vollständiges Dreieck definieren. Für jedes weitere Dreieck wird dann nur noch ein neuer Punkt gebraucht der dann mit den beiden zuletzt aufgeführten Punkten wieder ein Dreieck bildet.
Eine kleine Illustration:Es ist schön zu sehen dass für die 3 Dreiecke T1 bis T3 nun anstelle von 9 Punkten nur 5 benötigt werden. Um einen fortlaufenden Dreiecksstreifen zu erhalten müssen wir beim Wechsel in eine neue Zeile “unsichtbare” Dreiecke hinzufügen. Das ist in dem folgenden Bild mit den blauen Linien veranschaulicht. Die Zahlen repräsentieren die Vertexpunkte.

Dieses Verfahren werden wir nun bei der Erstellung der Vertexliste (Mesh) anwenden, auch wenn dieses offensichtlich noch einiges Optimierungspotential hat (da Punkte mehrfach/doppelt erzeugt werden):

void ClGuTerrain::generateMesh() {
// Erzeugen der Vertices für ein TriangleStripe
 // Dies wird von links nach rechts aufgebaut Zeile für Zeile
 // Das bedeutet, dass wir jeweils am Ende ein ganz ganz flaches (unsichtbares) Dreieck
// platzieren um den Wechsel in eine neue Zeile ohne Fehler zu ermöglichen.
// zuerst den Speicherbedarf für die Vertexe bestimmen und allokieren

 mesh=0;
 this->vertexCount = 2*(width+2)*height;
 mesh = (Vertex*)malloc(this->vertexCount*sizeof(Vertex));
 int vertex = 0;
 float scale = 0.5f;
 for (int y=0;y< height-1; y++){
  for (int x=0;x < width; x++){
// Die Vertices werden in der Zeile immer Paarweise erzeugt.
   mesh[vertex].x = terrainPoints[x+y*width].x*scale;
   mesh[vertex].z = terrainPoints[x+y*width].y*scale;
   mesh[vertex].y = (terrainPoints[x+y*width].height / 10.0f)- 20.0f;
   mesh[vertex].color = terrainPoints[x+y*width].color;
   vertex++;
  mesh[vertex].x = terrainPoints[x+(y+1)*width].x*scale;
   mesh[vertex].z = terrainPoints[x+(y+1)*width].y*scale;
   mesh[vertex].y = (terrainPoints[x+(y+1)*width].height / 10.0f)- 20.0f;
   mesh[vertex].color = terrainPoints[x+(y+1)*width].color;
   vertex++;
// sobald wir am rechten Rand angekommen sind müssen wir das “unsichtbare”
   // Dreieck erzeugt. Dazu wird der letzte Vertex und der 2. der ersten Zeile nochmal angehängt
// das ganze soll aber nicht in der letzten Zeile passieren…

   if (x == (width-1) && y < (height-2)){
    mesh[vertex].x = mesh[vertex-1].x;
    mesh[vertex].y = mesh[vertex-1].y;
    mesh[vertex].z = mesh[vertex-1].z;
    mesh[vertex].color = mesh[vertex-1].color;
    vertex++;
    mesh[vertex].x = terrainPoints[(y+1)*width].x*scale;
    mesh[vertex].z = terrainPoints[(y+1)*width].y*scale;
    mesh[vertex].y = (terrainPoints[(y+1)*width].height / 10.0f)- 20.0f;
    mesh[vertex].color = terrainPoints[(y+1)*width].color;
    vertex++;
   }
  }
 }
// Damit wir wissen wie viele Punkte unser Mesh wirklich hat merken wir uns hier die Anzahl
 this->vertexCount = vertex;
}

Der nun noch offene Teil befasst sich mit der Darstellung des Terrain. Dazu wird die render-Methode ausgeprägt. Die Darstellung der Dreiecke erfolgt mit der nun schon bekannten Funktion sceGumDrawArray. Dabei ist zu beachten, dass diese nur maximal 65535 Vertices verarbeiten kann. Darum müssen wir unser gesammtes Drahtgitter - sollte es aus mehr Punkten bestehen - in mehreren Häppchen übergeben. Der Einfachheithalber wählen wir hier Pakete von maximal 65000 Punkten.

void ClGuTerrain::render(){
 // Rendern des Terrains. Dabei nur bis zu 65k Vertices darstellen
 // andernfalls kann es zu Abstürzen kommen, da die GU nur bis zu 65535 Vertices
// auf einmal rendern kann

 int renderVertices;
 sceGumMatrixMode(GU_VIEW);
 sceGumLoadIdentity();
 sceGumMatrixMode(GU_MODEL);
 sceGumLoadIdentity();

 sceGuFrontFace(GU_CCW);

 renderVertices = vertexCount;
 Vertex* drawMesh = mesh;
 while (renderVertices>65000){
  sceGumDrawArray(GU_TRIANGLE_STRIP, GU_COLOR_8888 | GU_VERTEX_32BITF | GU_TRANSFORM_3D, 65000, 0, drawMesh);
  renderVertices-=65000;
  drawMesh+=65000;
 }

 if (renderVertices > 0){
  sceGumDrawArray(GU_TRIANGLE_STRIP, GU_COLOR_8888 | GU_VERTEX_32BITF | GU_TRANSFORM_3D, renderVertices, 0, drawMesh);
 }
}

Abschließend müssen noch der Destruktor und die Hilfsmethode mit “Leben” gefüllt werden. Da diese keiner weiteren Erklärung bedürfen (glaube ich) hier das Coding:

int ClGuTerrain::getPowerOf2(int value){
short c;
int temp;

temp = value;
c=0;
while ((temp >>= 1) > 0) c++;
temp = 1 << c+1;

if (temp >> 1 == value){
temp = value;
}

return temp;
}

ClGuTerrain::~ClGuTerrain() {

if (terrainPoints)
free(terrainPoints);
if (mesh)
free(mesh);
}

Die nächsten Schritte werden nun das Terrain in unserer Landscape Homebrew zur Verfügung stellen, es erzeugen und rendern. Dazu sind nur noch kleine Anpassungen notwendig. Zuerst muss das Makefile erweitert werden, so dass die Terrain-Klassen-Objektdatei erzeugt wird:

OBJS = main.o GuLandscapeApp.o GuTerrain.o

In der LandscapeApp-Klasse fügen wir in der Header Datei die neue Klassenheaderdatei hinzu und definieren ein Attribut das eine Referenz auf die Terrainklasse enthalten kann:

#include “GuTerrain.h”

class ClGuLandscapeApp : public Cl3dHomebrew {
 ……

protected:

ClGuTerrain* terrain;

Die Implementierung der Applikationsklasse wird nun noch in der Init, der Render und Exit Methode angepasst:

bool ClGuLandscapeApp::init(){
if (!Cl3dHomebrew::init()) return false;

terrain = new ClGuTerrain(”altitude.png”);
if (!terrain) return false;
}

void ClGuLandscapeApp::render() {
if (terrain) terrain->render();
}

void ClGuLandscapeApp::exit(){
if (terrain)
delete(terrain);
}

Das Ergebnis

Wenn alles glatt geht, dann sollte das Ergebnis auf dem PSP Screen so aus sehen:

Die in der PspHbc Bibliothek enthaltenen Header Files entpackt ihr am besten in euer PSPSDK Verzeichnis C:\pspsdk\psp\sdk\include das Lib-File kommt dann in das Verzeichnis C:\pspsdk\psp\sdk\lib dadurch wird die Nutzung in eigenen Projekten stark vereinfacht.

Nun aber los. Wie schon bei unserer ersten “normalen” Homebrew beginnt alles mit dem erstellen einer neuen Klasse. Diese wird nun von der 3DHomebrew-Basisklasse abgeleitet. Unsere Beispiel Homebrew soll den Namen HbcGuSample tragen. Die Klasse heißt dann treffender Weise: ClHbcGuSampleApp

/*
 * HbcGuSampleApp.h
 * Beispiel Implementierung der GU Homebrew Basisklasse
 */
#ifndef HBCGUSAMPLEAPP_H_
#define HBCGUSAMPLEAPP_H_
#include <3dHomebrew.h>
class ClHbcGuSampleApp : public Cl3dHomebrew {
public:
static ClHbcGuSampleApp* getInstance();
static void releaseInstance();
// Redefiniren der Render Methode um sie mit eigender Logik zu füllen
void render();protected: ClHbcGuSampleApp();
virtual ~ClHbcGuSampleApp();
static ClHbcGuSampleApp* _instance;
};
#endif /* HBCGUSAMPLEAPP_H_ */

Nachdem die neue Klasse nun definiert ist, können wir diese implementieren. Dabei ist der erste Teil der Implementierung recht einfach - glaube ich - da wir nur eine singleton Instanz erzeugen und diese zurück liefern. Die GU initializeirung bleibt unverändert.

/*
* HbcGuSampleApp.cpp
*
*/
extern “C”{
#include<pspgu.h>
#include<pspgum.h>
}
#include “HbcGuSampleApp.h”
ClHbcGuSampleApp* ClHbcGuSampleApp::_instance = 0;
// liefert singleton Instaz
ClHbcGuSampleApp *ClHbcGuSampleApp::getInstance(){
if(!_instance){
_instance = new ClHbcGuSampleApp();
}
return _instance;
}
//baut die singleton Instanz wieder ab und gibt Resourcen frei
void ClHbcGuSampleApp::releaseInstance(){
if (_instance) {
delete(_instance);
_instance = 0;
}
}

Der für die Klasse generierte Constructor und Destructor bleiben unberührt bzw. leer. Der nun “spannende” Teil befindet sich in der render Methode. Hier wollen wir unser erstes Objekt im virtuellen Raum definieren.

Wichtig:Definitionen von Objekten, Bewegungen und Objektrelationen im 3 dimensionalen Raum nutzen Vektoren und Matrizen. Wer also keinerlei Grundkenntnisse auf diesem Gebiet mitbringt sollte sich diese aneignen befor er hier weiter macht. Wikipedia ist eine gute Addresse um sich diesbezüglich aufzuschlauen. Oftmals helfen einem bei der Veranschaulichung auch ein paar Bleistifte (als Vektoren) und ein Tisch aus.

Das Dreieck

Das Dreick wird durch 3 Punkte im virtuellen Raum beschrieben. Diese Punkte erhalten zusätzlich zu ihrer Position noch einen Farbwert, so dass die Fläche die von dem Dreieck umspannt wird entsprechend ausgefüllt wird. Dabei verwenden wir hier für jeden Punkt einen anderen Farbwert um einen netten Farbverlauf zu erzeugen.

void ClHbcGuSampleApp::render(){
// Definition einer Struktur die einen 3D-Punkt beschreibt
typedef struct Vertex {
int color;
float x, y, z;
}Vertex;
//Speicher für 3 Punkte reservieren
//dieser Speicher ist dabei nur temporär und nur innerhalb der aktuellen GU Liste gültig
Vertex* triangle = (Vertex*)sceGuGetMemory(sizeof(Vertex)*3);
//Daten für die Punkte
triangle[0].x = -4.0f;
triangle[0].y = -2.0f;
triangle[0].z = -10.0f;
triangle[0].color = 0xff0000ff;triangle[1].x = 0.0f;
triangle[1].y = 2.0f;
triangle[1].z = -10.0f;
triangle[1].color = 0xffff0000;triangle[2].x = 4.0f;
triangle[2].y = -2.0f;
triangle[2].z = -10.0f;
triangle[2].color = 0xff00ff00;

Als nächsten Schritt wollen wir dieses Dreieck auch zeichnen. Zuerst leeren wir den Bildschirm mit einer von schwarz verschiedenen Farbe (schwarz macht’s die Basisklasse). Dadurch kann mann schneller erkennen ob hier was “gezeichnet” wird oder nicht, da ggfl. schwarz auf schwarz gezeichnete Objekte nicht sichtbar wären…
Nachdem wir den Bildschirm nochmals geleert haben müssen wir die Projektion der GU festlegen. Dafür legen wir für den aktuellen View und für das Objektmodell eine Einheitsmatrix fest. Dies bedeutet, dass weder unsere Kamera, noch unser Objekt im Raum manipuliert werden. Sie werden so dargestellt wie wir sie im Raum platziert haben. Mit der Model-Matrix wären wir z.Bsp. in der Lage das Objekt im Raum zu bewegen oder zu rotieren, ohne die ursprüngliche Definition der Punkte zu verändern. Doch das beleuchten wir zu einem späteren Zeitpunkt.

Doch nun zum Code:

//den Bildschirm mit einer eigenen Farbe leeren, anders als in 3DHomebrew
sceGuClearColor(0xff442222);
sceGuClear(GU_COLOR_BUFFER_BIT);// Festlegen der View und Model Matrix als Einheitsmatrix
sceGumMatrixMode(GU_VIEW);
sceGumLoadIdentity();
sceGumMatrixMode(GU_MODEL);
sceGumLoadIdentity();//damit die Farbwerte beim Füllen des Dreiecks verlaufen “smooth” (weiche/fortlaufende) Schattierung aktivieren
sceGuShadeModel(GU_SMOOTH);
//Das Dreieck kommt ganz ohne Texturen aus…also deaktivieren
sceGuDisable(GU_TEXTURE_2D);
// hier wird das Dreieck dann tatsächlich auf den Bildschirm gebracht, oder
// besser in den Zeichenpuffer der beim nächsten wechsel zwischen Display- und Zeichenpuffer
// sichtbar wird
sceGumDrawArray(GU_TRIANGLES, GU_TRANSFORM_3D | GU_VERTEX_32BITF | GU_COLOR_8888, 3, 0, triangle);
}

Ganz zum Schluss - bevor wir dieses Beispiel nun erstellen können müssen wir in unserem Makefile noch einige Bibliotheken aufnehmen, damit wir die GU Funktionen auch nutzen können. Im Detail sieht dieses dann folgendermaßen aus:

TARGET = hbcGuSample
OBJS = main.o HbcGuSampleApp.o
INCDIR =
CFLAGS = -G0 -Wall -g
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)
BUILD_PRX = 1
LIBDIR =
LDFLAGS =
LIBS = -lstdc++ -lpsphbc -lpspgum -lpspgu -lpng -lz -lm
EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = HBC Gu Sample
PSP_LARGE_MEM=1
PSP_FW_VERSION=500
PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak

Wenn nun die Erstellung dieses Beispiels glatt gelaufen ist, dann sollte das ganze auf der PSP so aussehen:

Da die Grundlegende Homebrew Einrichtung (mit den Callbacks etc) bereits in einer Klasse zusammengefasst ist, werden wir diese einfach ableiten und eine neue Klasse Cl3dHomebrew erstellen:

#include “Homebrew.h”
class Cl3dHomebrew : public ClHomebrew
{
protected:
Cl3dHomebrew();
virtual ~Cl3dHomebrew();
};

Die Initialiserung wird ebenfalls in der init-Methode stattfinden die wir nun neu ausprägen.

class Cl3dHomwbrew : public ClHomebrew
{
public:
/*
 * Die initialisierung der GU Homebrew.
 */
bool init();
/*
 * Hier werden alle Aufräumarbeiten vor’m verlassen der
 * Homebrew platziert.
 */
void exit();

Die Implementierung der Klasse und der Initialisierung greift dabei die Überlegungen auf dieser Seite auf. Darum werde ich den gesammten Quellcode nicht nochmals hier rein stellen, sondern nur Ausschnittsweise andeuten. Zusätzlich notwendige Includes sind die pspgu.h und die pspgum.h:

extern “C” {
#include <pspgu.h>
#include <pspgum.h>
}
#include “3dHomebrew.h”
static unsigned int __attribute__((aligned(16))) list[262144];
bool Cl3dHomebrew::init(){
//zuerst die Superklassen Methode rufen
if (!ClHomebrew::init()) return false;
//nun die eigene Initialisierung der GU
sceGuInit();
…….
//abschließen der GU Liste führt zur sofortigen Abarbeitung
//in diesem Falle, da wir die Liste mit GU_DIRECT gestartet haben
sceGuFinish();
sceGuSync(0,0);
//Aktiviere die Anzeige der GU auf dem realen Bildschirm
sceGuDisplay(GU_TRUE);
return true;
}
void Cl3dHomebrew::exit(){
//GU beenden
sceGuTerm();
//Superklassen Methode am Schluss
ClHomebrew::exit();
}

Nun ist der Punkt erreicht, an dem wir unsere erste GU Homebrew beginnen können. Um den Einstieg nun möglichst einfach zu gestalten, habe ich die bis hier beschriebenen Basisklassen und Vorbereitungen mal in einer Bibliothek zusammen gefasst. Zusammen mit den Header-Files könnt Ihr diese in Euer PSPSDK einbinden und schon loslegen, ohne die ganzen Quellcodes hier abschreiben zu müssen.

Die Bibliothek PspHbc bietet dabei die Basis-Homebrewklasse, eine 2D Grafik-Basisklasse, so wie sie bei der Voxellandschaft zum Einsatz kam, und die nun neue 3D-GU Basisklasse.

Wie Ihr diese Bibliothek für Eure eigenen Projekte einsetzt um eigene Homebrews zu schreiben zeige ich am Beispiel einer kleinen 3D Homebrew in Kürze…
Die Dokumentation der Header-Files in dem Paket sind auf English - aber da hier alles auf deutsch erklärt wurde, sollte das kein Problem darstellen.

Der Vorteil der GU ist, dass diese eine sehr leistungsstarke Einheit ist, die quasi parallel zur CPU arbeitet und einen optimierten Datenbus zur Grafikausgabe und zu bestimmten Hauptspeicherbereichen hat. Wer sich schon mit verschieden 3D Spielen auf dem PC auseinander gesetzt hat weiß vielleicht, dass Hardwarebeschleunigung in einer Grafikkarte bei der Berechnung der Grafik gegenüber der reinen CPU enorme Vorteile und Performancegewinn bietet und uns dadurch auch auf der PSP vermutlich einige Türen öffnen wird.

Der “Haken” an der ganzen Sache ? Nun - wir müssen uns wieder durch ein wenig staubige Theorie quälen um zu verstehen, was wir machen müssen um mit der GU zu arbeiten und erste Resultate zu erzielen….

Damit dieser Teil der ersten Betrachtung der GU und weitere Erkenntnisse nicht in der Blog-Geschichte untergehen, platziere ich das ganze auf einer separaten Seite…

Die Recherche in einigen Foren bringt mich dann zu dem Entschluss die Voxel in ihrem Space liegen zu lassen und sich mal ein wenig mit den 3D Grafikmöglichkeiten der PSP zu beschäftigen, denn diese Hardware ist ja - wie wir von vielen Spielen wissen - in der Lage sehr schöne Welten zum Vorschein zu bringen. Da wollen wir doch mal schauen, ob da auch was für unser Projekt dabei ist.

Es macht sich ein wenig vorsichtiger Enthusiasmus breit

class ClHomebrew {
….
protected:
/*
* in welchen Puffer soll gezeichnet werden ?
*/
bool pg_drawframe;
/*
* ermitteln des adresse des zeichen Puffers
*/
unsigned char* pgGetVramAddr();

Die Implementierung für diese Methode sieht dann so aus:

unsigned char *ClHomebrew::pgGetVramAddr(){
if (pg_drawframe)
return VRAM_TOP + FRAMESIZE;
else
return VRAM_TOP;
}

Zusätzlich müssen wir den neuen Zeichenpuffer auch beim setzen der Bildpunkte berücksichtigen. Darum sieht die Methode setPixel nun wie folgt aus:

void ClHomebrew::setPixel(int x, int y, int color){
//Zeiger auf das zu zeichnende Pixel berechnen
unsigned char* screen = pgGetVramAddr()+x*PIXEL_SIZE+y*LINE_SIZE*PIXEL_SIZE;
//Farbe setzen
u32* s;
s = (u32*)screen;
*s = color;
}

Im nächsten Schritt überarbeiten wir nun den Mainthread unserer Voxelklasse. Dort holen wir uns erstmal die Adresse des Zeichenpuffers und setzen dort alle Daten auf 0 (also schwarz). Danach wird die Voxellandschaft gezeichnet und dann wird der Puffer dargestellt. Am Schluss folgt das setzen des Flags, dass wir nun in den 2. Puffer zeichnen wollen. Ggfl. müssen wir folgende Includes in unsere Voxelklasse mit aufnehmen:<stdlib.h> und <pspdisplay.h>

void ClPspVoxel::mainthread(){
unsigned char* drawBuffer;
drawBuffer = pgGetVramAddr();
//leer räumen des Bildschirms
memset(drawBuffer, 0, FRAMESIZE);
//Zeichnen
render();
//nun teilen wir der PSP mit, welches unser Zeichenpuffer ist der nun gezeigt werden soll
sceDisplaySetFrameBuf(drawBuffer, LINE_SIZE, PSP_DISPLAY_PIXEL_FORMAT_8888, PSP_DISPLAY_SETBUF_IMMEDIATE );
//Flip des schalters welcher Puffer gefüllt wird
pg_drawframe = pg_drawframe?false:true;
//nach jedem Zeichnungsvorgang darauf warten dass die PSP das Bild
//komplett ausgegeben hat
sceDisplayWaitVblankStart();
}

Erstmal die Farbe

Für die Farbe auf der Landschaft brauchen wir eine Textur die die Landschaft farblich darstellt, da die Höhenkarte ja nur Grau-Werte - eben für die Höhe enthält. Ich verwende für die Höhenkarte eine passende Textur die von den Dimensionen die selben Maße hat (512×512) und wie folgt aussieht:

Die Textur müssen wir natürlich auch laden um diese benutzen zu können. Dazu werden wir die Methode, welche uns eine PNG Datei bereits in den Höhenkartenspeicher lädt erweitern und den Speicherplatz dynamisch zuweisen anstelle ein festes array zu definieren.

Die erweiterungen in der Klassendefinition:

class ClPspVoxel : public Cl2dHomebrew {
….
protected:
….
//neuer Parameter zur Aufnahme der gelesenen Daten
bool loadMap(const char* filename, unsigned int* data);
….
//Höhenkarte nun als Zeiger für dynamische Speicher Reservierung
//unsigned int mapData[512][512]; //Höhenwerte der Karte
unsigned int* mapData;
unsigned int* texture;

Die Anpassungen in der Implentierung der Lademethode sehen dann wie folgt aus:

/*
* Laden der Bilddaten aus PNG-File in Datenpuffer
* dazu wird die Vorlage aus der SDK graphics.c genutzt
* der Einfachheit halber gehen wir von Daten 512×512 punkten aus
*/
bool ClPspVoxel::loadMap(const char* filename, unsigned int* data) {
….
//Zeile nun Punkt für Punkt durchgehen und die Farbe in den Puffer übertragen
for (x = 0; x < width; x++) {
u32 color = line[x];
//neuer Zugriff auf den Datenpuffer in linearer Form ->zeile*maxBreite + spalte
//mapData[y][x] = color;
data[y*512 + x] = color;
}

Für die Anpassung der Initialisierungsmethode bei der wir nun den Speicher für die Höhenkarte und die Texture reservieren müssen wir noch das zusätzliche Include malloc.h einbinden.Der Code hierfür sieht dann so aus:

bool ClPspVoxel::init(){
…..
//Speicher für die Höhenkarte
mapData = (unsigned int*)malloc(sizeof(unsigned int)*512*512);
//Höhenkarte laden
loadMap(”altitude.png”, mapData);
//speicher für die Textur
texture = (unsigned int*)malloc(sizeof(unsigned int)*512*512);
loadMap(”landscape.png”, texture);

Um den dynamisch reservierten Speicher wieder freizugeben, wenn er nicht mehr gebraucht wird - das ist ganz wichtig! - platzieren wir folgende zeilen in den Klassendestruktor:

free(mapData);
free(texture);

Um die Textur nun bei der Darstellung der Landschaft zu berücksichtigen müssen wir nur geringe Anpassungen in der render Methode vornehmen um auch die neue Art auf die Daten zuzugreifen zu berücksichtigen:

void ClPspVoxel::render() {
….
//Höhe des Voxel
altitude = mapData[voxelY*512 + voxelX]; //mapData[voxelY][voxelX];
//die Farbe dieses Voxel aus der textur lesen
unsigned int color = texture[voxelY*512 + voxelX];
……
// Punkt im Bildschirm
//setPixel(pixelX, pixelY, altitude);
setPixel(pixelX, pixelY, color);

Das Ergebnis sieht schon ganz ordentlich aus:

void ClPspVoxel::render() {
….
//nach dem rendern fragen wir das pad ab.
//wurde der Analog-Stick bewegt ?
SceCtrlData pad;
sceCtrlPeekBufferPositive(&pad, 1);
//die ausrichtung des analog sticks ist
//0 ganz links, 255 ganz rechts
//0 ganz oben und 255 ganz unten.
//für eine Bewegung brauchen wir -x bis +x für links rechts
//und -y bis + y
short moveX, moveY;
moveX = pad.Lx - 127;
moveY = 127 - pad.Ly;
nbsp;
//da wir uns nicht im vollen “Auschlag” des Stix bewegen wollen, sondern
//maximal um 4 Pixel pro durchlauf verringern wir die Werte entsprechend
moveX >>= 5;
moveY >>= 5;
posY+=moveY;
posX+=moveX;
}

Schweben
Nun wollen wir noch über unsere Landschaft “schweben”. Dazu müssen wir die render Methode nur geringfügig anpassen. Bis jetzt ist die Höhe des Betrachters immer fest vorgegeben gewesen. Nun wird diese aber aus der Höhe des Punktes berechnet über dem sich der Betrachter gerade befindet.Zusätzlich bauen wir nach dem zeichnen der Bildpunkte in einer Spalte noch eine Sicherheitsabfrage ein, die verhindert, dass der Strahl weiter verfolgt wird, wenn der Bildschirm schon bis oben hin voll-”gemalt” wurde…

void ClPspVoxel::render() {
…..
rayZ = 81 + (mapData[(posY&511)*512 + (posX&511)] & 255); //384;
….
}while (rayZ < currentAltitude);
}
// wenn der Bildschirm am oberen Rand erreicht ist, brauchen
//wir den strahl nicht weiter verfolgen…
if (pixelY <= 1) break;

Viel Spaß bei den ersten “Flugversuchen”