LifeBar

[Lebostein]

3DSprites, naja... Warum kompliziert, wenns auch einfach geht. Warum nicht ganz simpel mit ClipSprite()?

Code: Alles auswählen

InitSprite()
InitKeyboard()

#LifeBar = 0

OpenScreen(800,600,16,"Hallo")
CreateSprite(#LifeBar, 20, 100)

energy = 100

Repeat

ExamineKeyboard()

ClearScreen(0,0,0)

;-----------------------------
UseBuffer(#LifeBar)
ClearScreen(255 - energy * 2.55, energy * 2.55, 0)
UseBuffer(#PB_Default)
ClipSprite(#LifeBar, 0, 0, 20, energy)
DisplaySprite(#LifeBar, 100, 300 - energy)
;-----------------------------

FlipBuffers()

If KeyboardPushed(#PB_Key_Up) And energy < 100: energy + 1: EndIf
If KeyboardPushed(#PB_Key_Down) And energy > 0: energy - 1: EndIf

Until KeyboardPushed(#PB_Key_Escape)

Oder wenn es nicht unbedingt auf die Geschwindigkeit ankommt, der einfache Weg über langsamen 2DDrawing-Befehle:

Code: Alles auswählen

InitSprite()
InitKeyboard()

OpenScreen(800,600,16,"Hallo")

energy = 100

Repeat

ExamineKeyboard()

ClearScreen(0,0,0)

;-----------------------------
StartDrawing(ScreenOutput())
Box(100, 300 - energy, 20, energy, RGB(255 - energy * 2.55, energy * 2.55, 0))
StopDrawing()
;-----------------------------

FlipBuffers()

If KeyboardPushed(#PB_Key_Up) And energy < 100: energy + 1: EndIf
If KeyboardPushed(#PB_Key_Down) And energy > 0: energy - 1: EndIf

Until KeyboardPushed(#PB_Key_Escape)

[Ynnus]

Oder wenn es nicht um Geschwindigkeit geht, der einfache Weg über 2DDrawing:

Das ist ja genau die Frage, ob das 2D-Drawing wirklich so flott ist. Ich hab da in Erinnerung, dass 2D-Drawing doch recht lahm ist. Noch dazu, wenn du das StartDrawing() Stop...() für jede Lifebar wiederholst. Dann geht's erst richtig in die Geschwindigkeit.

[Lebostein]

Das ist ja genau die Frage, ob das 2D-Drawing wirklich so flott ist. Ich hab da in Erinnerung, dass 2D-Drawing doch recht lahm ist. Noch dazu, wenn du das StartDrawing() Stop...() für jede Lifebar wiederholst. Dann geht's erst richtig in die Geschwindigkeit.

Meine ich ja, 2DDrawing ist langsam ([..wenn es NICHT um Geschwindigkeit geht..]), deshalb würde ich es lieber über Sprites machen. Und wenn man doch die 2DDrawing-Befehle verwendet, sollte man eh versuchen, alle Grafikausgaben in einen einzigen StartDrawing()-Stopdrawing() Block zu packen...

[Danilo]

Ich hab OpenGL bisher leider nur in Verbindung mit C/WinAPI verwendet, mit PB noch überhaupt nicht. Und dann eben durch WinAPI auch nicht Plattformabhängig.

Mit Glut und C/C++ kann man es schon komplett platform-
unabhängig machen, da Glut auch eine Funktion bietet um
ein Fenster zu öffnen.

Bei PB/Linux waren bisher nicht mal OpenGL-Imports dabei,
also hätte man die erst selbst machen müssen.
Weiß nicht ob sich das bei der letzten Beta geändert hat.
Die Probleme mit double floats und GL kennst Du ja schon,
da PB das nicht unterstützt.

EDIT: Spätestens wenn du > 100 Objekte mit Lifebar auf dem
Monitor hast, wird es umständlich, immer das ganze Sprite
neu mit der gewünschen Farbe zu übermalen.

Ah! Jetzt hab ich verstanden was Du willst.

Ich dachte eher an 1 - 3 'Lifebars' am Rand des Screens, so
daß man dort die Energie des Spielers sieht. Oder auch ein
Balken für Munition.
So wie bei alten 2D-Spielen, Jump&Runs, und bei RPGs zur
Anzeige der Energie Deines Spielers.

Du meinst hunderte Objekte die direkt neben dem Objekt
eine Mini-Statusbar haben.
Auch hier würde ich das zeichnen vorher auf ein Sprite machen,
und nicht zur Laufzeit. Zum Beispiel 1 Sprite wo sich 200 kleine
Farbbalken darauf befinden. Zum anzeigen wird einfach der
momentane EnergieStatus geclippt und das Sprite ausgeworfen.
Alle Manipulationen zur Laufzeit kosten Rechenpower.

Das was Du bei OpenGL meinst, die Farbmanipulationen zur
Laufzeit, das geht mit DX genauso.
Stefan hat dafür schonmal ein paar Funktionen gezeigt:
Primitives mit Direct3D7 zeichnen

Damit kannst Du auch schnell Farbverläufe darstellen. Halt nur
mit DX, also Windows.

Mit PureBasic, und dazu noch platformunabhängig, wird es nur
was mit einfachen Sprites und Clipping. Sprites wegen der
Geschwindigkeit, da das dauernde zeichnen zur Laufzeit sehr
rechenintensiv ist.

[Lebostein]

Auch hier würde ich das zeichnen vorher auf ein Sprite machen,
und nicht zur Laufzeit. Zum Beispiel 1 Sprite wo sich 200 kleine
Farbbalken darauf befinden. Zum anzeigen wird einfach der
momentane EnergieStatus geclippt und das Sprite ausgeworfen.
Alle Manipulationen zur Laufzeit kosten Rechenpower.

So ein Sprite könnte man sich ja bei Programmstart automatisch generieren lassen und dazu ganz simple 2DDrawing-Befehle verwenden, da es ja hier nicht auf die Geschwindigkeit ankommt...das scheint die beste Lösung zu sein