ist drawimage in einen imagebuffer zu langsam?

Übersicht

BlitzBasic

Beginners-Corner

	Spuckfunkel Betreff: ist drawimage in einen imagebuffer zu langsam?	Mi, Okt 06, 2004 18:19 Antworten mit Zitat
Hi, ich bin dabei ein Jump 'n run zu programmieren und handle die Kollisionsabfrage über ein image in das ich alle Hindernisse als einfarbige Flächen zeichne. Per readpixel test ich dann, ob der Spieler bespielsweise an eine Wand rennt. Das image mit den Hindernissen erstelle ich vor dem Gameloop, aber bewegliche Hindernisse (Gegner, Plattformen...) müssen da sie sich bewegen ja jedes Frame neu in den KollisionsBuffer (so nenn ich das) gezeichnet werden. Wenn ich per drawimage z.B. die Gegner in den Kollisionsbuffer zeichne, bremst das mein Spiel bereits nach 9 kleinen Gegner total aus. Wenn ich die Gegener in den Backbuffer zeichne (mach ich ja sowieso), kann ich über 150 zeichnen ohne das mein Spiel ausgebremst wird. Sind die Imagebuffer langsam? Gibt es eine möglichkeit sie in den Speicher der Grafikkarte zu schieben, oder sind sie da eh schon drin? Hat jemand ne andere LÖsung? danke schon mal im Voraus.

Spuckfunkel

Betreff: ist drawimage in einen imagebuffer zu langsam?

Mi, Okt 06, 2004 18:19
Antworten mit Zitat

Hi,
ich bin dabei ein Jump 'n run zu programmieren und handle die Kollisionsabfrage über ein image in das ich alle Hindernisse als einfarbige
Flächen zeichne. Per readpixel test ich dann, ob der Spieler bespielsweise an eine Wand rennt.

Das image mit den Hindernissen erstelle ich vor dem Gameloop, aber bewegliche Hindernisse (Gegner, Plattformen...) müssen da sie sich bewegen ja jedes Frame neu in den KollisionsBuffer (so nenn ich das) gezeichnet werden.

Wenn ich per drawimage z.B. die Gegner in den Kollisionsbuffer zeichne, bremst das mein Spiel bereits nach 9 kleinen Gegner total aus. Wenn ich die Gegener in den Backbuffer zeichne (mach ich ja sowieso), kann ich über 150 zeichnen ohne das mein Spiel ausgebremst wird.

Sind die Imagebuffer langsam? Gibt es eine möglichkeit sie in den Speicher der Grafikkarte zu schieben, oder sind sie da eh schon drin? Hat jemand ne andere LÖsung?

danke schon mal im Voraus.

	rambo256	Mi, Okt 06, 2004 18:36 Antworten mit Zitat
Schonmal was von Imagecollide gehört
Asus F53z Das Leben ist eine reine Konkatenation...

rambo256

Mi, Okt 06, 2004 18:36
Antworten mit Zitat

Schonmal was von Imagecollide gehört Question

Asus F53z

Das Leben ist eine reine Konkatenation...

	Edlothiol	Mi, Okt 06, 2004 19:30 Antworten mit Zitat
Eigentlich sollte das nicht so langsam sein, vielleicht liegts an dem ReadPixelFast. Zeig doch mal den Code.

Edlothiol

Mi, Okt 06, 2004 19:30
Antworten mit Zitat

Eigentlich sollte das nicht so langsam sein, vielleicht liegts an dem ReadPixelFast. Zeig doch mal den Code.

	IonPainter	Mi, Okt 06, 2004 20:41 Antworten mit Zitat
er sagt nichts von ReadPixelFast, Zitat: Per readpixel test ich dann, wär vielleicht mal ne überlegung wert, auch wenn der ansatz völlig falsch ist... http://www.blitzbase.de/befehl...elfast.htm

IonPainter

Mi, Okt 06, 2004 20:41
Antworten mit Zitat

er sagt nichts von ReadPixelFast, Zitat:

Per readpixel test ich dann,

wär vielleicht mal ne überlegung wert, auch wenn der ansatz völlig falsch ist...

http://www.blitzbase.de/befehl...elfast.htm

	Spuckfunkel	Mi, Okt 06, 2004 23:25 Antworten mit Zitat
Also, readpixel ist nicht das Problem, da ich nur 5 readpixel pro Durchgang benutze. Ich finde Imagecollide etwas umständlich, da ich ja für jedes Objekt in dem Level testen müsste, ob es mit dem Spieler kollidiert. Früher unter DOS habe ich in C Spiele programmiert, und da hat man die Kollisionsabfrage oft auf meine Art gelöst. Man erstellt ein zweites "unsichtbares" Abbild des Levels, in dem ALLE Objekte als Farbflächen dargestellt werden. Man muss dann nur testen, ob und welche Farbe sich an der Spielerposition befindet. Befindet sich an der Spielerposition z.B. die Farbe Grün bedeutet das, dass der Spieler an etwas tödliches wie Feuer oder Stachel gestossen ist (war nur nen Beispiel). Ok, ist ja nun auch nicht das Problem. Ich mag diese Art Kollisionsabfrage nur lieber. Hier nun ein Auszug (genau der, der Probleme macht) aus meinem Code. Code: [AUSKLAPPEN] [EINKLAPPEN] SetBuffer ImageBuffer(coll_bild) Color 0,0,0 For i = 0 To 9 If Plattform(i)\active = 1 Then Rect Plattform(i)\x#,Plattform(i)\y#,64,10,1 endif Next SetBuffer BackBuffer() So braucht ein Durchgang meines Hauptloops 24ms! Wenn ich die erste Zeile (Setbuffer Imagebuffer...) weglasse, so das in den Backbuffer (ist vorher aktiv) anstatt in das coll_Bild gezeichnet wird, benötigt ein Durchgang nur 8ms und die benötigt er auch wenn ich die 9 Rechtecke überhaupt nicht zeichne. Ich verstehe absolut nicht, warum das zeichnen in den Imagebuffer so viel rechenzeit verbraucht, wo das zeichnen in den Backbuffer ja überhaupt keine messbare rechenzeit für sich in anspruch nimmt. Hat jemand ne Ahnung warum das so ist, und was man machen könnte?

Spuckfunkel

Mi, Okt 06, 2004 23:25
Antworten mit Zitat

Also, readpixel ist nicht das Problem, da ich nur 5 readpixel pro Durchgang benutze.

Ich finde Imagecollide etwas umständlich, da ich ja für jedes Objekt in dem Level testen müsste, ob es mit dem Spieler kollidiert. Früher unter DOS habe ich in C Spiele programmiert, und da hat man die Kollisionsabfrage oft auf meine Art gelöst.
Man erstellt ein zweites "unsichtbares" Abbild des Levels, in dem ALLE Objekte als Farbflächen dargestellt werden. Man muss dann nur testen, ob und welche Farbe sich an der Spielerposition befindet. Befindet sich an der Spielerposition z.B. die Farbe Grün bedeutet das, dass der Spieler an etwas tödliches wie Feuer oder Stachel gestossen ist (war nur nen Beispiel).
Ok, ist ja nun auch nicht das Problem. Ich mag diese Art Kollisionsabfrage nur lieber.

Hier nun ein Auszug (genau der, der Probleme macht) aus meinem Code.
Code: [AUSKLAPPEN]

SetBuffer ImageBuffer(coll_bild)
Color 0,0,0
For i = 0 To 9
If Plattform(i)\active = 1 Then
Rect Plattform(i)\x#,Plattform(i)\y#,64,10,1
endif
Next
SetBuffer BackBuffer()

So braucht ein Durchgang meines Hauptloops 24ms!
Wenn ich die erste Zeile (Setbuffer Imagebuffer...) weglasse, so das in den Backbuffer (ist vorher aktiv) anstatt in das coll_Bild gezeichnet wird, benötigt ein Durchgang nur 8ms und die benötigt er auch wenn ich die 9 Rechtecke überhaupt nicht zeichne.

Ich verstehe absolut nicht, warum das zeichnen in den Imagebuffer so viel rechenzeit verbraucht, wo das zeichnen in den Backbuffer ja überhaupt keine messbare rechenzeit für sich in anspruch nimmt.

Hat jemand ne Ahnung warum das so ist, und was man machen könnte?

Zuletzt bearbeitet von Spuckfunkel am Do, Okt 07, 2004 14:45, insgesamt 2-mal bearbeitet

	regaa	Do, Okt 07, 2004 8:17 Antworten mit Zitat
du solltest setbuffer nach möglichkeit nicht in realtime verwenden, könntest ja das bild vorher einzeichen, also per setbuffer imagebuffer, danach direkt setbuffer backbuffer setzen und dann dieses bild immer nur drawen aufm backbuffer() und am ende ganz normal flipen.
UltraMixer Professional 3 - Download QB,HTML,CSS,JS,PHP,SQL,>>B2D,B3D,BP,BlitzMax,C,C++,Java,C#,VB6 , C#, VB.Net

regaa

Do, Okt 07, 2004 8:17
Antworten mit Zitat

du solltest setbuffer nach möglichkeit nicht in realtime verwenden, könntest ja das bild vorher einzeichen, also per setbuffer imagebuffer, danach direkt setbuffer backbuffer setzen und dann dieses bild immer nur drawen aufm backbuffer() und am ende ganz normal flipen.

UltraMixer Professional 3 - Download
QB,HTML,CSS,JS,PHP,SQL,>>B2D,B3D,BP,BlitzMax,C,C++,Java,C#,VB6 , C#, VB.Net

	Bms	Do, Okt 07, 2004 14:00 Antworten mit Zitat
die color würd ich außerhalb der for schleife setzen. du setzt sie 10x, obwohl du das nur 1x machen musst. (vielleicht bringts ne ms )
Reblonce (Jump + Run + Shoot - Game; 20 Levels): Download

Bms

Do, Okt 07, 2004 14:00
Antworten mit Zitat

die color würd ich außerhalb der for schleife setzen. du setzt sie 10x, obwohl du das nur 1x machen musst. (vielleicht bringts ne ms Very Happy

)

Reblonce (Jump + Run + Shoot - Game; 20 Levels): Download

	Spuckfunkel	Do, Okt 07, 2004 14:41 Antworten mit Zitat
Habe gerade selber die Lösung zu meinem Problem gefunden (nach 10h rumtesten, puh!). Es lag an zwei Imagecollide die ich noch in meinem Loop hatte (als ich anfing das Spiel zu proggen habe ich noch mit imagecollide gearbeitet). Irgendwie frisst es super viel Rechenzeit (rund 15ms für ein Imagecollide!!!!), wenn man eins der Bilder, die nach Kollision getestet werden in dem gleichen Frame vorher verändert hat (also etwas reingezeichnet hat). Warum auch immer!? Hat jemand schon einmal etwas ähnliches beobachtet? Ich habe diese Imagecollides nun jedenfalls komplett aus meinem Spiel geschmissen und nun läuft es einwandfrei (und vor allem schnell).

Spuckfunkel

Do, Okt 07, 2004 14:41
Antworten mit Zitat

Habe gerade selber die Lösung zu meinem Problem gefunden (nach 10h rumtesten, puh!).

Es lag an zwei Imagecollide die ich noch in meinem Loop hatte (als ich anfing das Spiel zu proggen habe ich noch mit imagecollide gearbeitet).
Irgendwie frisst es super viel Rechenzeit (rund 15ms für ein Imagecollide!!!!), wenn man eins der Bilder, die nach Kollision getestet werden in dem gleichen Frame vorher verändert hat (also etwas reingezeichnet hat).

Warum auch immer!?
Hat jemand schon einmal etwas ähnliches beobachtet?

Ich habe diese Imagecollides nun jedenfalls komplett aus meinem Spiel geschmissen und nun läuft es einwandfrei (und vor allem schnell). Shocked

Übersicht

BlitzBasic

Beginners-Corner

Nach Oben

BlitzBasic Portal

ist drawimage in einen imagebuffer zu langsam?

Betreff: ist drawimage in einen imagebuffer zu langsam?