| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
bio
Mini JLI'ler
Anmeldedatum: 21.01.2005
Beiträge: 6
Medaillen: Keine
|
 Verfasst am: 04.03.2005, 16:35 Titel: Tileengine realisieren |
 |
|
hallo 
Ich würde gerne eine simple Tileengine programmieren und meine Sprites darauf bewegen können ... Hab mir schon einige Gedanken gemacht wie man bei so einem Vorhaben vorgehen könnte, habe jedoch keine Lösung gefunden  Das Problem meinerseits ist, dass ich allgemein nicht weiß wie ich es lösen könnte ...
- Welche Möglichkeiten gibt es denn, eine Tileengine zu realisieren ?
- Wie kann ich es bewerkstelligen, dass sich mein Sprite stets im Zentrum befindet und sich die "Spielwelt" nach dem Sprite richtet ?
hoffe auf Antworten ...
mfg. bionicman |
|
| Nach oben |
|
 |
FH
Super JLI'ler
Alter: 36
Anmeldedatum: 16.10.2004
Beiträge: 438
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 16:38 Titel: |
|
|
Da gibts das ein oder andere Renderstate von DX...
Aber: Was soll die Tileengine genau machen? Und: Soll es Tiles, oder Sprites behandeln?
Noch was: Gehört das nicht ins DX/OpenGL???
Gruß
FH
_________________
goto work, send your kids to school
follow fashion, act normal
walk on the pavement, watch T.V.
save for your old age, obey the law
Repeat after me: I am free |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 17:00 Titel: Re: Tileengine realisieren |
|
|
| bio hat Folgendes geschrieben: | | Ich würde gerne eine simple Tileengine programmieren und meine Sprites darauf bewegen können ... Hab mir schon einige Gedanken gemacht wie man bei so einem Vorhaben vorgehen könnte, habe jedoch keine Lösung gefunden Das Problem meinerseits ist, dass ich allgemein nicht weiß wie ich es lösen könnte ... |
Also es gibt da Möglichkeiten wie Sand am Meer und Heiße Weiber auf diese Welt 
Eine sehr einfache Möglichkeit ist ein 2D Array!
Eine sehr einfache Möglichkeit ist folgendes Beispiel:
| CPP: | unsigned char map[3][5]; // unsigned char geht von 0 bis 255, also platz für 255 tile-IDs
map[0][0] = 1;
map[0][1] = 1;
map[0][2] = 255;
map[0][3] = 1;
map[0][4] = 1;
map[1][0] = 1;
map[1][1] = 0;
map[1][2] = 255;
map[1][3] = 0;
map[1][4] = 1;
map[2][0] = 0;
map[2][1] = 0;
map[2][2] = 255;
map[2][3] = 0;
map[2][4] = 0;
// [...]
// paar konstanten:
const int tile_width = 32;
const int tile_height = 32;
// paar variabeln:
int worldmove_x = 0;
int worldmove_y = 32;
// Blitten oder Rendern
for (unsigned int y=0; y<3; ++y)
{
for (unsigned int x=0; x<5; ++x)
{
blitTileByID (worldmove_x + x*tile_width, worldmove_y + y*tile_height, map[y][x]);
}
} |
Das erzeugt ein "Pfeilähnliches Terrain". Ich benutz das auch und eigentlich ganz ausreichend.
| bio hat Folgendes geschrieben: | | - Welche Möglichkeiten gibt es denn, eine Tileengine zu realisieren ? |
Siehe oben Ist die Gängiste und auch die Beste für sowas
| bio hat Folgendes geschrieben: | | - Wie kann ich es bewerkstelligen, dass sich mein Sprite stets im Zentrum befindet und sich die "Spielwelt" nach dem Sprite richtet ? |
Siehe oben, wenn du worldmove_x bzw. worldmove_y veränderst, veränderst du die verschiebung der Welt die geblittet werden soll. Dein Sprite darfst Du darin wohl nicht miteinbeziehen (ist ja auch logisch, die Welt hat sich zu bewegen nicht Dein Sprite!)
Wenn das klappt, solltest Du Dir gedanken machen über speedzuwachs sowie Culling, die von Direct3D gestellten RHW-Vertices, solltest Du die Finger von lassen, genau so wie beim locken der Vertexbuffer zur laufzeit! Ebenfalls solltest Du nicht jedes Tile auf seine Sichtbarkeit testen!
Bei einem 3x5 Terrain wie hier wären das schon 15 if-abfragen, bei einem 500x500 Terrain was ebenfalls noch sehr klein ist sind das schon 250.000 und das geht richtig auf die CPU und nicht mehr auf die GPU
Auch hier gibt es viele Ansätze dieses Speedproblem zu lösen, aber sowas macht man nicht mit Bäumen (Wir wollen ja nicht mit Atomraketen auf Spatzen ballern ^^), sondern eher mit einem Page/Patch System oder einem sehr präziseren Verfahren. Aber dazu viel später in anderen Posts
Ich hoffe ich konnte Dir etwas weiterhelfen
- Patrick
edit:
FH
Renderstates für Tiles? Ich bitte Dich
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
| Nach oben |
|
|
Beni5
Super JLI'ler
Alter: 36
Anmeldedatum: 12.11.2003
Beiträge: 310
Wohnort: Switzerland
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 17:08 Titel: |
|
|
Hm schonmal mit Notizblock und viel Geduld probiert? Ich hab's so gemacht 
Also.
Warscheinlich willst du auch noch die Tiles scrollen können?
Du machst am besten 2 for schleifen(x und y). Diese lesen dann die map aus einem 2 dimensionalen Array und zeichnet die Tiles. Zudem muss die "Kameraposition" berücksichtigt werden, darum müssen wir
| CPP: | int Map[32][32];
RECT Clip;
RECT MapPos;
int TileSize = 32;
D3DXVECTOR2 vCam;
for(int y=0; y < (SCR_HEIGHT+40)/40; y++)
{
for(int x=0; x < (SCR_WIDTH+40)/40; x++)
{
// Hier schneiden wir ein Teil aus einer Bitmap aus
Clip.left = Map[x+vCam.x/TileSize][y+vCam.y/TileSize]*TileSize;
Clip.right = Clip.left+TileSize;
Clip.top = 0;
Clip.bottom = TileSize;
MapPos.left = x*TileSize;
MapPos.right = MapPos.left+TileSize;
MapPos.top = y*TileSize;
MapPos.bottom = MapPos.top+TileSize;
m_lpD3DDevice->StretchRect(m_lpTiles,
&Clip,
m_lpBackBuffer,
&MapPos,
D3DTEXF_NONE);
}
}
|
Das sieht dann aber eher Ruckartig aus, aber ist mal gut um das Ganze zu verstehen. Ich schlage dir vor das mal umzuschreiben und schauen ob es funkzt.?
Das er sich stehts im Zentrum befindet ist kein Problem. Du verschiebst eigentlich nicht den Spieler sondern die Tiles! Also zeichnest du den Spieler einfach immer in die Mitte des Screens und mit den Pfeiltastenwerten verschiebst du sozusagen den Boden unter seinen Füssen
Zuletzt bearbeitet von Beni5 am 04.03.2005, 17:11, insgesamt einmal bearbeitet |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
|
| Nach oben |
|
|
Beni5
Super JLI'ler
Alter: 36
Anmeldedatum: 12.11.2003
Beiträge: 310
Wohnort: Switzerland
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 17:14 Titel: |
|
|
Patrick
Ungeschlagener Master of Spam |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
|
| Nach oben |
|
|
Beni5
Super JLI'ler
Alter: 36
Anmeldedatum: 12.11.2003
Beiträge: 310
Wohnort: Switzerland
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 17:28 Titel: |
|
|
| Aber vielleicht kann der Vornehme Herr auch sagen was genau die FPS so niedrig macht? |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 17:32 Titel: |
|
|
Aber sicher
| CPP: | m_lpD3DDevice->StretchRect(m_lpTiles,
&Clip,
m_lpBackBuffer,
&MapPos,
D3DTEXF_NONE); |
Du skalierst die Surface m_lpTiles, auch wenn die Größe perfekt zugeschnitten ist. Nebenbei: Direct3D Surfaces sind die Lamsten die es gibt, da ist selbst die GDI schneller.
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
| Nach oben |
|
|
bio
Mini JLI'ler
Anmeldedatum: 21.01.2005
Beiträge: 6
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 18:17 Titel: |
|
|
@ patrick:
hab mir deinen Quelltext genau angeschaut und auch verstanden (man stelle sich vor *gg*) ... jedoch weiß ich nicht genau was die Funktion blitTileByID beinhalten soll ...
auf jeden fall schon mal danke für die antworten ... das grundprinzip leuchtet mir jetzt ein
mfg. |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 18:23 Titel: |
|
|
bio
ganz einfach:
1. parameter ist X koordinate
2. parameter ist Y koordiante
und 3. Parameter ist die zu rendernde TileNummer
wie Du das nun implementierst ist Dir überlassen
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
| Nach oben |
|
|
GreveN
JLI Master
Alter: 38
Anmeldedatum: 08.01.2004
Beiträge: 901
Wohnort: Sachsen - Dresden
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 20:35 Titel: |
|
|
Weil wir grad beim Thema sind. ^^
Ich überleg schon seit Tagen, wie man am besten (schnell, Speicher schonend) eine möglichst große Tilemap anlegt und rendert.
Da die Tiles ja alle die selbe Größe haben, wäre es doch eigentlich sinnvoll ein VBO mit den Vertexdaten in der Karte anzulegen und dieses eine VBO zum rendern aller Tiles zu verwenden, indem man die Objekt Matrix einfach immer wieder um 'TileSize' verschiebt. Das wäre zwar bestimmt nicht ganz so flott wie für jedes Tile VBO + IndexBuffer, aber würde eben den VRAM nicht zumüllen. Für die Textur Koordinaten hab ich mir überlegt den User etwas in seiner Freiheit einzuschränken indem ich ihn die verwendeten 'Tilesets" spezifizieren lasse... ein Tileset beinhaltet bspw. 30x40 Tiles der Größe 16x16 (Standard RPG-Maker Sets), anhand dieser Werte kann man die Koordinaten für jedes Tile in einem Set dieser Art 'vorberechnen'. Diese Koordinaten wollte ich jeweils in eigenen VBO's speichern und in einen IndexBuffer einfügen... Gerendert wird folgendermaßen: Objekt Matrix verschieben, Vertex VBO rendern, mit IndexBuffer Texturkoordinaten ermittlen und aktuelle Textur auf die Vertices klatschen...
Culling wollte ich am liebsten über nen Quadtree realisieren (jaja, ich schieße gerne mit Kanonen nach Spatzen xD )...
Haltet ihr das so für realisierbar bzw. sinnvoll?
Achja, wollte das ganze in OGL umsetzen, hab mir sagen lassen, das es in D3D nicht geht, da sich Daten nicht so einfach auf die Karte laden lassen, in OGL gehts problemlos...
[Edit: ] Könnte auch die Texturmatrix immer verschieben, dann würde es sich mit den Texturkoordinaten genau wie mit den Vertexdaten verhalten... |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
| Verfasst am: 04.03.2005, 21:03 Titel: |
|
|
GreveN
Zu der Texturmatrix weißt Du ja: Wenn Du Tilesets benutzt und Kachelst kannst Du damit nichts machen! Nichtmal in OpenGL!
Und zum Rest: Probier es aus und merke das es nicht geht, wenns geht hast Du mir was neues beigebracht, und das schafft net jeder Aber Praxis ist was anderes als Theorie!
topic
Ich hab ein Sample hochgeladen, basierend auf meinem Tutorialcode:
http://83.246.114.104/patrick/trash/tileengine.zip
Steuerung ist wie im Tutorial:
- Beenden mit ESCPAE
- Moduswechsel mit F1
- Pfeiltasten, Terrain im Sichtbarkeitsbereich bewegen.
Hinzugefügte Dateien sind world/tiles.h sowie die dazugehörige source-datei.
In world::tiles wird für jedes Tile in der Textur 1 Vertexbuffer mit 4 vertices erstellt für schnelles rendern (RHW + Lock/Unlock ist bei sowas zu lamarschig, deshalb: Was man hat, das hat man!).
Auf meiner Radeon 9000 Normal schafft das Programm 750 FPS im Vollbild, also ganz Ordentlich! Wäre das mit RHW vertices und lock/unlock gäbs 120 FPS. Deshalb den kleinen Vertexbufferoverhead, der eigentlich nicht weiter interessant sein sollte.
Um die Tiles zu sehen Leertaste drücken im Menü oder dort auf "New Game" klicken.
- Patrick, der hofft einigen geholfen zu haben.
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
| Nach oben |
|
|
HomeLess_PunkDrummer
JLI Master Trainee
Alter: 36
Anmeldedatum: 28.11.2004
Beiträge: 583
Wohnort: Alter Joghurtbecher an der A4
Medaillen: Keine
|
| Verfasst am: 05.03.2005, 19:55 Titel: |
|
|
btw, was soll die rhw-Dingense so lame machen?
_________________
"Was die Götter angeht, so ist es mir unmöglich, zu wissen, ob sie existieren oder nicht, noch, was ihre Gestalt sei. Die Kräfte, die mich hindern, es zu wissen, sind zahlreich, und auch ist die Frage verworren und das menschliche Leben kurz." |
|
| Nach oben |
|
|
Patrick
Dark JLI Master
Anmeldedatum: 25.10.2004
Beiträge: 1895
Wohnort: Düren
Medaillen: Keine
|
| Verfasst am: 05.03.2005, 20:02 Titel: |
|
|
Um ein RHW zu positionieren muss mans Locken. Wenn dann noch die Weltverschiebung dazu kommt und das bei ca. 400 Tiles pro Bildschirmscene heult Deine Grafikkarte und Dein Bus zwischen AGP-Slot und GPU fängt an zu qualmen
Das wäre so wenn man ne Fette Oma von 250Kgramm in einen Smart stopfen will Das klappt nicht sehr gut und dauert laaaaaange.
Bei untransformierten Vertices ist das etwas einfacher:
1x Projektions und Viewmatrix erstellen
1x Textur setzen
und den vorbereiteten VertexBuffer für das jeweilige der auf der GraKa ist nehmen, transformieren und rendern
Nebenbei gibt es noch den wunderbaren Vorteil: Rotation und Skalierung! Das kannste mit RHWs knicken Und das locken entfällt!
Kurz: Ordentlich Speed da alles vorberechnet ist, viel mehr Features, kein lock/unlock zur Laufzeit uvm.
Reicht doch oder? 
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ] |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Medaillen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
