H
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.
