Alles gleichzeitig...
-
hallo..
habe mich bisher noch nich so tief mit der grafikprogrammierung auseinandergesetzt..
ich möchte aber gerne wissen, wie (nehmen wir zunächst ein einfaches 2D-Jump&run spiel) die Programmierer Bewegungen von mehreren Sprites gleichzeitig programmieren, also das grundprinzp das dahinter steckt.1. Also ich wüsste locker wie ich eine bewegung eines einzelnen Sprites mache..
- Sprite aufmalen
- Bildschirm löschen
- Sprite um einen Pixel weiter aufmalen
- Bildschirm löschen
usw.
(wenn das ganze mit hintergrund sein soll, würde ich den hintergrund in nen buffer rein machen und den fuer "bildschirm löschen" verwenden)2. Wie geht das bei mehreren Sprites ?
also mir fallen 2 möglichkeiten ein:
a)
- 1.Sprite aufmalen
- 2.Sprite aufmalen
- Bildschirm löschen
- 1.Sprite um einen Pixel versetzt aufmalen
- 2.Sprite um einen Pixel versetzt aufmalen
- Bildschrim löschen
usw.
das wäre ne große schleife, die ständig nachguckt, ob es was zu bewegen gibt
(bussy loop)
wobei für jeden Sprite ne feste route einprogrammiert wurde..
die schleife würde dann in der route nachgucken.b)
jedes objekt(sprite) bekommt einen extra thread
mit CreateThread() z.b.
(siehe windows oberfläche mit den fenstern)
(wäre mir aber eher unsympatisch und umständlich)Waren meine Überlegungen richtig ? sowohl zu 1. als auch 2.
was stimmt bei 2. ? a oder b, oder gar keins ?wie geht es bei opengl ? ähnlich ? genauso ?
mfg
haMMer
-
Hammer schrieb:
b)
jedes objekt(sprite) bekommt einen extra thread
mit CreateThread() z.b.
(siehe windows oberfläche mit den fenstern)
(wäre mir aber eher unsympatisch und umständlich)DAS wäre absoluter Wahnsinn!!!!!
Hammer schrieb:
wie geht es bei opengl ? ähnlich ? genauso ?
Das Prinzip hat nichts mit der Grafik-Lib zu tun!
-
Sgt. Nukem schrieb:
Hammer schrieb:
b)
jedes objekt(sprite) bekommt einen extra thread
mit CreateThread() z.b.
(siehe windows oberfläche mit den fenstern)
(wäre mir aber eher unsympatisch und umständlich)DAS wäre absoluter Wahnsinn!!!!!
Stell dir mal vor, du hast ein paar hundert Sprites. So viele threads gehen gar nicht.
Nein im ernst. Ich glaube du solltest mal ein Tut über den allg. Aufbau eines Spiels lesen oder ein Buch drüber besorgen.
-
ok, habs ja jetz kapiert dass threads in dem falle unsinn sind...
aber was ist mit dem rest ?
gut, ein ausführliches tut werd ich schon durcharbeiten müssen, das is richtig..
weil früher oder später komm ich dann zu nem punkt, wo dann alles zu umfangreich wird und mir ohne grundkenntnisse der überblick fehlt ...sagen wirs so, ich will jetz gar net so arg auf opengl eingehen..
aber nehmen wir mal SDL ausm 2d bereich.
ich hab mal vor kurzem damit angefangen und was die standard sdl lib betrifft gibts da soweit ich weiss keine feste funktionen für animation und bewegungen von objekten. wenn ich eine bitmap z.b. von a nach b bewegen lassen will muss ich dass selber von hand programmieren. und da sind wir schon wieder beim thema..ob ich jetz die SDL lib verwende oder ich in assembler im lowlevelmodus in einer standard VESA auflösung eine animation machen will, kommt eigentlich vom denkprozess das gleiche raus finde ich. (wobei ich letzteres eigentlich vorhab)
ich möchte jetz nur wissen ob ich mit meinem vorigem verfahren (also jetz NICHT das mit den threads) total daneben gelegen bin oder ob es schon der richtige denkansatz war.. siehe 1. und 2.a
danke
-
Pseudocode schrieb:
Hauptschleife
{
Berechne FrameRate;
Werte Inputs aus;
Berechne Spiellogik;
Zeichne;
}