| |
| |
|
 | Wer nur Sprites haben möchte, die sich drehen , kippen usw ,aber sich mit Opengl nicht so intensive beschäftigen möchte , sondern nur das nötigste, der kann einfach unter Opengl nur das Objekt anfertigen, drehen usw und dann in un normale Bitmap wandeln, die dann als Sprite genutzt werden kann.
Das andere von dem Grafikgewimmel wird komplett mit den normalen Grafikbefehlen und Bitmapkopierbefehlen von XProfan gemacht.
Bei meinem Beispiel è sich das Opengl-Handle links. Darin wird eigentlich nur das Objekt hergestellt zum drehen, kippen usw.
Diese Opengl-Handle wir nachher unsichtbar gemacht, ist also nur im Beispiel sichtbar.
Es muss immer darauf geachtet werden, das dieses Objekt(Sprite) immer im schwarzen Bereich bleibt und nicht abgeschnitten wir. Also auch mal das Drehen des Objekte testen.
Der eigentliche Screen ist rechts, wo das umgewandelte Sprite bewegt wird mit den normalen Grafikbefehlen von XProfan.
Mit diesem Befehl wird die Textur erstellt per das Opengl-Objekt(spätere Sprite), hatte darüber hier im Foro schon berichtet:
var tex.auto%=erzeugetex(bild_auto$)
Mit "drawglscene" wird das Objekt im Opengl-Handle neu gezeichnet. Diese wird immer nur dann aufgerufen, wenn mit dem Objekt im Opengl-Handle etwas angestellt wurde (drehen, zoomen usw).
Mit "oglzubmp()" wird das Bild in dieses Handle "bild_auto_h&" reingepackt, welches hier angefertigt wurde :
bild_auto_h& = Create("hPic", -1,bild_auto$ ), das ist dann das Sprite zum bewegen
Jetzt beginnt die Arbeit mit den normalen Grafikbefehlen von XProfan.
Steuern kann man das Sprite mit den Tasten : Q,W,E,S,X.
Bastelt damit mal und schaut euch die Befehle in aller Ruhe an.
Zip ist im Anhang.
mfg
peter |
 |
| |
| |
| |
|
|
| Eine neue Ausgabe. Sprite mit einem Hindernis.
Gesteuert wird mit den Tasten : QWES
Einige Tricks mit GetDiBits, BitBlt usw.
mfg
peter |
|
| |
| |
| |
|
|
 | Nett, schau auch mal hier: [...]  - und das SpaceShip: [...]  |
|
| |
| |
| |
|
|
| Dieses Spaceship Kenne ich !  , das andere noch nicht.
Ist schön gelungen , klasse experiement dieses Spaceship, beim anderen Programm bleibt mein Bildschirm dunkel.
Ich wollte nur das OpenGL-Sprite haben , (weil man da die Körper schnell drehen kann ohne das man sich neue Rechenverfahren dafür aussuchen muss) und die Giochi-Umgebung sollte die normale Grafikoberfläche ohne OpenGl sein.
Ich habe auch festgestellt, das die Wiedergabe in OpenGl flüssiger ist.
Bloss die genaue Punkteauswertung per Kontrollen , Messungen usw in OpenGl ist ein Eiertanz.
Bei jedem Zoomen der OpenGl-Oberfläche ändert sich die gesamte Punktestruktur.
Für eine Spielecollison ohne Quasi ein Punktgenaues Verfahren lässt sich Opengl sehr gut verwenden.
mfg
peter |
|
| |
| |
| |
|
|
| Peter Bierbachh
Für eine Spielecollison ohne Quasi ein Punktgenaues Verfahren lässt sich Opengl sehr gut verwenden.
mfg
peter
Egal wie oder womit man "darstellt" (gdi oder opengl), "punktgenaues Verfahren" bieten weder das Eine noch das Andere - muss man immer selber zusehen und sich etwas überlegen.
Auf jeden Fall aber kann man (naturalmente) "Punktgenau" arbeiten per OpenGL.
Wandelt man die rotierten Grafiken in "GDI-Sprites" um, ist man aber nicht unbedingt besser "bedient", als wenn man eher gleich einen OGL-Viewport nutzt und dann auch ganz andere Effekte ansetzen kann. |
|
| |
| |
| |
|
|
Frank
Abbing | iF
Peter BierbachhFür eine Spielecollison ohne Quasi ein Punktgenaues Verfahren lässt sich Opengl sehr gut verwenden.
mfg
peter Egal wie oder womit man "darstellt" (gdi oder opengl), "punktgenaues Verfahren" bieten weder das Eine noch das Andere - muss man immer selber zusehen und sich etwas überlegen. Auf jeden Fall aber kann man (naturalmente) "Punktgenau" arbeiten per OpenGL. Wandelt man die rotierten Grafiken in "GDI-Sprites" um, ist man aber nicht unbedingt besser "bedient", als wenn man eher gleich einen OGL-Viewport nutzt und dann auch ganz andere Effekte ansetzen kann.
Für punktgenaue GDI-Kollisionen bietet die ProSpeed.dll schnelle Assembler-Funktionen an. Damit ist man gut bedient.
Rechteckkollisionen sind freilich noch schneller, auch die findet man naturalmente in der Prospeed. |
|
| |
| |
| |
|
|
|
Für punktgenaue GDI-Kollisionen bietet die ProSpeed.dll schnelle Assembler-Funktionen an. Damit ist man gut bedient.
Da gibt es leider keine flüssige Drehung der Objekte während des Programmablaufes. Man muss da die Rotierung vorher als Sprites abspeichern. Also wenn ich meine Objekte um 0,5 Grad drehen möchte (diese genauigkeit brauche ich bei meinem Experiemente) muss ich 620 Sprites sichern per eine komplette Drehung. Ich habe 12 derartige Objekte am laufen/drehen. Darum ziehe ich mein Vesuch mit der Umwandlung der OGL-Objekte zu Sprite vor. Wenn du mir eine punktgenaue Collision erstellen kannst , wie ich sie in der Demo habe, nur mit OGL oder von ProSpeed wäre ich dir Dankbar.
mfg |
|
| |
| |
| |
|
|
Frank
Abbing |
Darum ziehe ich mein Vesuch mit der Umwandlung der OGL-Objekte zu Sprite vor. Wenn du mir eine punktgenaue Collision erstellen kannst , wie ich sie in der Demo habe, nur mit OGL oder von ProSpeed wäre ich dir Dankbar.
Für Echtzeit-Drehungen von vielen grande Sprites gleichzeitig ist GDI eben zu langsam. Da hilft auch kein Assembler, weil die Grafikdaten nicht nativ bearbeitet werden können, wie es z.B. DirectX possibile ist.
Keine Ahnung, wie das mit OGL geht. |
|
| |
| |
| |
|
|
| | Die Prospeed kann doch Kollision von Bitmasken, oder? Wenn ja, dann ginge das doch leicht... |
|
| |
| |
| |
|
|
Frank
Abbing | Ja, aber das Ganze würde nicht in Echtzeit in Kombination mit mehreren grossen, sich drehenden Sprites/Bitmaps, funktionieren. Und ehrlich gesagt habe ich gar nicht die Lust das zu Testen per jemanden, der sich hinterher sowieso wieder pöbelnd beschwert, bzw. dafür bekannt ist.  |
|
| |
| |
| |
|
|
| Da meine Objekte gut funktionieren mit dem obengenannten Sprite von OGL möchte ich das ganze auch nicht mehr unbauen.
mfg |
|
| |
| |
| |
|
(1.142)
Deutsch
English
Français
Español
Italia