weiche Sprite-Ränder erzeugen

[remi_meier]

In meiner OpenGL Engine verschiebe ich einfach die s/t-Koordinaten und
verändere die Positionen der Vertices um ein Clipping einer Textur zu
'simulieren'. Sollte in PB (mit U/V-Koordinaten) auch möglich sein, was
aber bis jetzt wohl nur über PB-Internas möglich ist.
Frag mal Stefan ob er euch was zaubert

[ZeHa]

Ja ich habe auch mal mit einem Kumpel unter C++ eine OpenGL-SpriteEngine programmiert. Dort kann ich auch jedes beliebige Format (also auflösungsmäßig gesehen) reinladen und problemlos darstellen. Auch damals auf meiner TNT2.

Also irgendwie muß es gehen

Naja ich werd mich da echt noch ein wenig damit rumschlagen müssen. Solange hab ich ja auch noch meine normalen 2D-Sprites, um das Spiel weiterzuentwickeln. Ich wrappe das Anzeigen der Sprites sowieso schon, von daher ist die Umstellung auf 3D-Sprites dann hoffentlich ein Kinderspiel...

[remi_meier]

Ich sprach nicht davon, sondern wie man eine Textur clippen kann.
Wenn du jede beliebige Grösse als Textur laden kannst, dann machst
du das sicher mit gluBuild2DMipmaps_(). Dazu gibt es eine wichtige
Notiz in der MSDN:

If the dimensions of the input image are not powers of two, then the image is scaled so that both the width and height are powers of two before the mipmaps are generated.

Kannst du natürlich auch in PB für Sprite3Ds machen, aber es geht nicht
unbegrenzt, denn die Grafikkarte muss die Grösse auch noch unterstützen!

Aber wie gesagt, mir gings nur um das "Clippen" einer Textur.

[ZeHa]

Nein ich glaube das lief anders. Ist schon 'ne Weile her und ich kenn mich mit OpenGL auch nicht so besonders aus, aber die wurde dann glaub ich schon in einen quadratischen pot-Buffer geschrieben und hinterher dann geclippt. Also ich kann damit dann auch frei clippen, so wie unter PB mit ClipSprite().

Aber nochmal @ Kaeru, wie meintest Du das mit UseBuffer? Soll ich also für jede Figur, die auf meinem Bildschirm rumlaufen soll, einen eigenen Buffer erstellen, der quadratisch ist und in den dann immer die jeweilige Phase reingerendert wird?

[Kaeru Gaman]

ne..
du machst mir CreateSprite ein neues Sprite, das wird dann dein FrameSprite.
jetzt musst du das Bild aus deinem Frameset ja in das Sprite rüberbekommen.
dazu machst du UseBuffer(FrameSprite) und dann DisplaySprite(FrameSet,...)
eben mit den koordinaten, damit du den richtigen frame ausschneidest.
(und davor kannst du eben auch clippen)
das machst du für jeden frame, dann hast du eine reihe einzelsprites,
die du ohne probleme als tex für Sprite3D benutzen kannst.
...und das machst du eben direkt nach dem laden,
der einzelsprites-erzeuger braucht nur einmal zeit, nämlich dann, wenn du den level startest.
später im level nimmst du die einzelsprites zum displayn bzw. als texture.

[ZeHa]

Achso ja okay, also es ging jetzt hier nur um das bequeme clippen. Ich dachte jetzt, Du meintest auf das Problem der "vielen Spritenummern" hin bezogen. Aber letztendlich wird das ja nicht gelöst, sondern nur die Clipping-Frage. Okay verstanden

Naja für die Numerierung wird mir schon noch was einfallen. Habe auch bemerkt daß ich schon einige Sprites benutzt habe, die sehr hohe Nummern hatten (5stelliger Bereich), und da gab es auch keine Compiler-Meckereien. Das kam glaub nur bei Gadgets oder so.

[Kaeru Gaman]

mit den spritenummern musst du halt aufpassen, dass du möglichst wenig lücken lässt,
weil eine pointer-liste angelegt wird, genau wie für windows und gadgets.

lass diesen code mal laufen, und schau in die prozessliste, wieviel speicher er benötigt:

Code: Alles auswählen

InitSprite()
OpenWindow(0,0,0,400,200,"bla")
OpenWindowedScreen(WindowID(0),0,0,400,200,0,0,0)
CreateSprite(100000,100,100)
Repeat:Until WaitWindowEvent() = #PB_Event_CloseWindow

dann änder die spritenummer mal in 0, und lass nochmal laufen....

[ZeHa]

Naja okay, das ist schonmal gut zu wissen. Wobei natürlich 100.000 schon sehr hoch ist und der Unterschied bei ca. 2,5 MByte liegt - das dürfte also noch zu verkraften sein

Ich denk mal ich werd mir einen groben Überblick verschaffen, wie viele bewegliche Objekte das Spiel haben wird, dann werd ich genauer erkennen können, wie ich das einteilen muß. Die ganzen statischen Sachen wie Mauern usw. besitzen ja immer nur ein einziges Sprite. Denkbar wäre z.B. der Bereich $0000 bis $0FFF für statische Tiles (wäre also Platz für 4096), und ab dann eine Einteilung in die erwähnten Klassen, z.B. $1000 - $1FFF für Gegner usw. Somit wäre meine höchste Sprite-Nummer $FFFF, und die wird erst erreicht, wenn es tatsächlich 15 verschiedene Klassen von Objekten gibt und diese wiederum 16 verschiedene Ausführungen usw besitzt.


EDIT: Nochmal zu Deinem Beispiel. Ich habe gerade ein Sprite 10x geladen und immer #PB_Any benutzt. Dann kriege ich ja die Spritenummer zurück, das sind dann aber immer sehr große Zahlen - aber der Speicherverbrauch bleibt trotzdem relativ klein. Woran liegt das dann?

[Kaeru Gaman]

genau das is der gag.
du bekommst nämlich keine spritenummern zurück, sondern direkt das Handle,
und deswegen wird auch kein Handle-Table angelegt.

manche kollegen bevorzugen deshalb das einrichter per #PB_Any,
und hinterlegen die Handles in einem Array.
...wenn du sowieso mit einem array arbeiten willst,
kannst du dir den automatischen Handle-Table sparen.

[ZeHa]

Okay aber wenn ich ein Array benutze, hab ich ja auch wieder Speicherverschwendung... obwohl, natürlich kann ich dann die Einteilung ein wenig verbessern, also z.B. ein 4dimensionales Array benutzen, und die einzelnen Größen so auslegen, wie ich sie brauche. Ist eigentlich gar nicht so dumm

Eine Frage hätte ich noch zur Performance... in der Hilfe steht ja, daß 3D-Sprites langsamer sind, was aber heutzutage ja eigentlich nicht mehr stimmen sollte. Gibt es aber tatsächlich Grafikkarten, die ich schonmal ausklammern könnte? Mein Ziel ist eigentlich, daß es auf so vielen Rechnern wie möglich läuft, auch auf alten.
Hast Du (Kaeru) nicht zufällig noch 'ne alte Kiste rumstehen? Ich meinte das irgendwo gelesen zu haben. Wenn ja, könntest Du Dich evtl. bald als Beta-Tester zur Verfügung stellen