Sidescroll Shooter / Map aus Polygonen / Kollosion & Texturen (SDL)

[oggs_the_progger]

Hy, ich möchte einen einfachen Sidescrollshooter programmieren

meine Map besteht aus vielen Polygonen wie bei http://www.soldat.pl

Jedoch habe ich keine Ahnung wie ich keine Ahnung wie ich die Texturen auf die einzellnen Polygone bringen soll, hat da jemand eine Idee ????

Ich weis zwar ungefähr wie ich die Kollosionsabfrage mache jedoch möchte ich wissen wie ihr das angehen würdet

THX für JEDEN noch so kleinen Tipp

[hellihjb]

erstmal levelgrafik mit software deiner wahl malen.
grosse teile dieser bitmap werden leer sein, darum in tiles sinnvoller groesse zerlegen (64x64?).
entsprechende polygone fuer alle nicht-leeren tiles anlegen.
groessere texturen (512x512?) anlegen (damit man nicht fuer jedes polygon die aktive textur umschlaten muss) und mit (raeumlich sinnvoll benachbarten) tiles fuellen.
die koordinaten eines tiles innerhalb einer textur den polygonen als textur-koordinaten zuordnen.
die polygone so sortieren, dass alle polygone mit der gleichen textur in einem rutsch gerendert werden koennen.
je nach art des scrollings (horizontal/vertikal/beides) kann man dann leicht herausfinden, welche texturen daten beinhalten die aktuell auf dem bildschirm sichtbar sind und entsprechend alle zugehoerigen polygone zeichnen.
anhand der scroll-richtung kann man dann auch leicht vorhersehen, welche level-grafiken als naechstes benoetigt werden und dynamisch zur grafikkarte uebertragen.
bzgl der kollisionsabfrage kann man leicht herausfinden, in welchem polygon man sich gerade befindet und pruefen ob in dessen textur pixel gesetzt sind, die eine kollision ausloesen wuerden.

[oggs_the_progger]

würdet ihr eher eine kollision über die farbe eines pixels oder über die koordinaten der polygone vorziehen ???

[oggs_the_progger]

was meinst du mit tiles das versteh ich nicht

i hab alle meine schönen dreiecke auf dem schirm
in diese dreiecke möchte ich bitmaps füllen wozu also die tiles

erklär das bitte

THX

[TGGC]

oggs_the_progger schrieb:

würdet ihr eher eine kollision über die farbe eines pixels oder über die koordinaten der polygone vorziehen ???

Über die Koordinaten selbstverständlich!

Bye, TGGC (Das Eine, welches ist.)

[hellihjb]

was meinst du mit tiles das versteh ich nicht
i hab alle meine schönen dreiecke auf dem schirm
in diese dreiecke möchte ich bitmaps füllen wozu also die tiles
erklär das bitte

ich versuch's mal...
normalerweise koenntest du ja die ganze levelgrafik in eine riesige textur laden und mit einem grossen polygon, das man fuer scrolling einfach verschiebt, auf den bildschirm bringen (waere dann also rein zweidimensional).
die groesse eines levels waere dabei allerdings durch die maximale groesse einer textur (2048 oder 4096 pixel) beschraenkt, sodass man die zu scrollende bitmap sowieso in mehrere texturen/polygone zerteilen muesste. wenn man auf diese weise sehr grosse level handhaben moechte, kommt man auch schnell in die situation, dass die ganze map gar nicht in den grafikspeicher passt.
ausserdem habe ich mich an einem screenshot von "soldat" orientiert, bei dem die vordergrund-grafik ein 2d-terrain, also sozusagen den boden, darstellt. im falle eines tals waeren dann grosse teile der grafik (eben alles ueber dem boden) leer, was einerseits darauf hinweist, dass man diesen bereich nicht zeichnen muss, und andererseits der teil der level-grafik auch nicht im grafikspeicher rumlungern muss.
deshalb war mein (wenig ueberdachter) vorschlag, die map in ein raster aus kleineren bloecke zu zerlegen und entsprechend dieses rasters polygone/quads zu erzeugen auf denen man jeweils den entsprechenden block als textur benutzt.
beinhaltet ein block der level-map keine grafik (bzw ist komplett durchsichtig), kann man den entsprechend verwerfen und benoetigt an der stelle auch kein polygon.
die "rasterung" des levels kann entweder mit fester oder dynamischer (zb quadtree) groesse geschehen. genauso muessen die polygone nicht an einem rein zweidimensionalen grid ausgerichtet sein, sondern koennten auch tiefeninformationen (woher auch immer) erhalten, um die grafik plastischer darzustellen...
dieses konzept der zerlegung in bloecke nutzte man (aus mangel an speicher) zb gerne auf alten konsolen um scrollende hintergruende darzustellen. die bloecke hiessen dort eben "tiles", zu deutsch "kacheln", wobei der ganze hintergrund aus kacheln fester groesse (8x8/16x16) bestand und jeder kachel eine aus 256 moeglichen kachel-grafiken zugewiesen werden konnte - aehnlich einem zeichensatzes im textmodus.
heutzutage benutzt man eben polygone um die einzelnen bloecke/kacheln zu zeichnen, weil die hardware dafuer optimiert ist (was natuerlich zusaetzliche moeglichkeiten bietet die man nicht ausser acht sollte).
nun wuerde es aber keinen sinn machen, jeden teilblock als eigenstaendige textur auf der grafikkarte zu halten, weil das bedeuten wuerde, fuer jedes zu zeichnende polygon die textur umzuschlaten, was bedeutend performance kostet.
stattdessen arrangiert man besser viele dieser bloecke innerhalb einer groesseren textur und weist dem polygon auf dem sich ein block befindet einfach die entsprechenden koordinaten des block innerhalb der groesseren textur zu.
was die kollision angeht, sollte man natuerlich so viel wie moeglich anhand der eckpunkte der entsprechenden polygone entscheiden, aber man wird im fall eines reinen 2d-games manchmal nicht drumherum kommen, einen pixel-genauen test vornehmen zu muessen (zb kann ein tile nicht komplett gefuellt sein). in bezug auf die tiles kann man jedoch leicht einige flags ablegen, die zb angeben ob ein geschoss das auf einer seite auf ein polygon trifft und auf einer anderen seite das polygon wieder verlassen wuerde, ueberhaupt irgend etwas treffen kann. ebenso koennte man entlang der level-map eine oder mehrere reihen von "boden-linien" erzeugen auf den objekte im level stehen, bzw runter fallen wenn sie eine linie verlassen...
aber das ist natuerlich nur eine moeglichkeit von vielen und am ende solltest du am besten wissen, was fuer dein spiel am sinnvollsten ist.