PureBoard

Verfasst: **04.07.2008 22:33**

SpriteID=CreateSprite(#PB_Any...)

CreateSprite2D(SpriteID,SpriteID)

Fehlermeldung im Debugmodus:
ERROR: #Sprite3D object number is verry high (over 1000000), are you sure of that?

Kann ich diesen Fehler unterdrücken? Oder #PB_Any kleinere Zahlen erzeugen lassen?

Ich möchte nur einmal eine Variable speichern müssen.
Ich sehe auch nicht wirklich einen Sinn drin, dass ich aus einem Sprite mehr als nur ein 3D-Sprite machen kann. Denn die 3D-Sprites kann ich ja auch mit der gleichen ID öfter an verschiedene Stellen setzen.

Verfasst: **04.07.2008 22:41**

Das Problem ist, dass für alle IDs, die kleiner als deine via #PB_Any erzeugte ID sind (die ja eigentlich eine virtuelle Speicheradresse ist), Speicherplatz für 3D-Sprites reserviert werden würden.
Das kann nen ganzer Haufen Speicherplatz werden, von daher macht die Debuggermeldung auch Sinn.
Ohne Debugger würde es dennoch funktionieren, nur halt nen Sack voll Resourcen fressen.

Verfasst: **04.07.2008 22:46**

Code: Alles auswählen

SpriteID=CreateSprite(#PB_Any...)

Sprite3DID = CreateSprite3D(#PB_Any,SpriteID)

Verfasst: **04.07.2008 22:56**

...oder aber Enumerieren, das spart die "verhassten" Variablen gleich und man kann sie bequem doppelt verwenden.

Verfasst: **04.07.2008 23:02**

enumerierte konstanten kann man aber so schlecht in arrays packen und in schleifen ansprechen....

ich mach eh vieles mit arrays und schleifen für spritelisten...

Verfasst: **04.07.2008 23:08**

In Schleifen ansprechen geht doch wunderbar:

Code: Alles auswählen

Enumeration
	#Sprite_Bierwagen
	#Sprite_Holsten
	#Sprite_Bit
	#Sprite_Budvar
	#Sprite_Rothaus
	#Sprite_HeX0R_Normal
	#Sprite_HeX0R_Betrunken
	#Sprite_HeX0R_Voll
	#Sprite_H2erXfe0R_tiootal_vpolkl
EndEnumeration

For i = #Sprite_Bierwagen To #Sprite_H2erXfe0R_tiootal_vpolkl
	;Drink Beer...
Next i

Verfasst: **04.07.2008 23:15**

und als Array?

Code: Alles auswählen

Dim Position(#Sprite_H2erXfe0R_tiootal_vpolkl)
X = Position(#Sprite_Budvar)

das ist doch unfug, das führt die verwendung von konstanten ad absurdum.

Verfasst: **05.07.2008 00:11**

Kaeru Gaman hat geschrieben:SpriteID=CreateSprite(#PB_Any...)

Sprite3DID = CreateSprite3D(#PB_Any,SpriteID)

xaby hat geschrieben:Ich möchte nur einmal eine Variable speichern müssen.
Ich sehe auch nicht wirklich einen Sinn drin, dass ich aus einem Sprite mehr als nur ein 3D-Sprite machen kann. Denn die 3D-Sprites kann ich ja auch mit der gleichen ID öfter an verschiedene Stellen setzen.

So habe ich es ja vorher gemacht
http://www.purebasic.fr/german/viewtopic.php?t=17049

Aber es ist wie gesagt unsinnig zwei IDs zu verwenden, wenn ich je ein Sprite mit je einem Sprite3D verknüpfe.

HeXOR hat geschrieben: Das Problem ist, dass für alle IDs, die kleiner als deine via #PB_Any erzeugte ID sind (die ja eigentlich eine virtuelle Speicheradresse ist), Speicherplatz für 3D-Sprites reserviert werden würden.

Das möchte ich bezweifeln.

PB-Hilfe hat geschrieben:Erstellt ein 3D-Sprite '#Sprite3D' aus dem angegebenen 2D-Sprite '#Sprite'. Wenn #PB_Any als '#Sprite3D' Parameter verwendet wird, dann wird die Nummer des neuen 3D-Sprites als 'Ergebnis' zurückgegeben.

ImageGadgets und Images können doch auch die kleine #Nummer haben.
Nur dass bei dem Verweis auf das #Image im Gadget dann ImageID benutzt werden muss.

Es gibt aber kein Sprite3DID()-Befehl.

Ich bräuchte den Quatsch nicht machen, wenn ich von einem 3D-Sprite Rückschlüsse auf das Quell-Sprite2D ziehen könnte.

So wie bei einem ImageGadget() der Befehl GetGadgetState() ja das Handle des eigentlichen Bildes liefert.

Woher weiß denn PureBasic beim Aufruf von DisplaySprite3D(), welches Sprite2D nun als 3D-Sprite dargestellt wird?

Ich benötige einen Befehl: Sprite2DID(#Sprite3D)

Dann könnte ich auf die 2D-SpriteID verzichten und bräuchte nur noch die Sprite3D-ID speichern. Und wenn ich die 2D-SpriteID wissen möchte, um zum Beispiel auf meinem "3DSprite" zu zeichen (das aber nur auf das 2D-Quellsprite funktioniert) dann nutze ich halt Sprite2DID(#Sprite3D)

Wieso will ich das so "kompliziert" machen.

Ganz einfach, die Informationen müssen schon im Speicher liegen, und es wäre Unfug, diesen mit "dreifacher" Menge an IDs zu füllen als eigentlich nötig. Zumal ich dann auch immer gleich Strukturen brauche, statt einfach nur einen Longint.

Verfasst: **05.07.2008 00:24**

PureBasic Hilfe zu Sprite3D.pb

Etwas abgewandelt. Aber dieses Beispiel macht deutlich,
dass es wohl eher die Regel ist:

Sprite2DID=Sprite3DID zu nehmen.

CreateSprite3D(0,0) ; Als Beispiel angeführt
Ich hätte in dem Beispiel auch alle "1" auf "0" setzten können.
Den einzigen Sinn, den es gibt, ein 3DSprite mit einer anderen ID als der des 2DSprites zu versehen wäre, wenn man auf Rotate und Zoom bei einigen Sprites verzichten möchte und bei anderen es aber nutzt.

Code: Alles auswählen

;
; ------------------------------------------------------------
;
;   PureBasic - Sprite example file
;
;    (c) 2002 - Fantaisie Software
;
; ------------------------------------------------------------
;

If InitSprite() = 0 Or InitKeyboard() = 0
  MessageRequester("Error", "Can't open DirectX 7 Or later", 0)
  End
EndIf

If InitSprite3D() = 0
  MessageRequester("Error", "Direct3D system can't be initialized correctly", 0)
  End
EndIf

;
; Now, open a 640*480 - 16 bits (65000 colours) screen
;

If OpenScreen(640, 480, 16, "Sprite")

  ; Load our 16 bit sprite (which is a 24 bit picture in fact, as BMP doesn't support 16 bit format)
  ; 
  LoadSprite(0, "C:\F\PureBasic\2008-07\FLDGS\Heightmap.bmp", #PB_Sprite_Texture)
  CreateSprite3D(0, 0)
  CreateSprite3D(1, 0)
  CreateSprite3D(2, 0)
  
  Sprite3DQuality(1)
  
  TransparentSpriteColor(0, RGB(255, 0, 255)) ; Our pink is transparent :)

  Repeat
    
    ; Inverse the buffers (the back become the front (visible)... And we can do the rendering on the back)
    
    FlipBuffers()
    
    ClearScreen(RGB(0,50,128))
    
    ; Draw our sprite
    ;
    If Start3D()
    ; Zoom und Rotate eingefügt
    ; SpriteNummern auf eins gesetzt
      ZoomSprite3D(1, SpriteWidth(0), SpriteHeight(0))
      RotateSprite3D(1, 0, 0)
      DisplaySprite3D(1, 0, 30)
      DisplaySprite3D(1, x+100, 100, x)
      DisplaySprite3D(1, x*2, 100, x)

      ; Zoom..
      ;
      ZoomSprite3D(1, x, x)
      RotateSprite3D(1, x, 0)
      DisplaySprite3D  (1, 0, 100, x/2)
      DisplaySprite3D  (1, x*2, 100, x)
      DisplaySprite3D  (1, 0, 100, x/2)
      DisplaySprite3D  (1, x*2, 200+x, x)
      
      Stop3D()
    EndIf
    
    ExamineKeyboard()
    
    x+1
  Until x > 500 Or KeyboardPushed(#PB_Key_Escape)
  
Else
  MessageRequester("Error", "Can't open a 640*480 - 16 bit screen !", 0)
EndIf

End

Verfasst: **05.07.2008 00:39**

> Den einzigen Sinn, den es gibt, ein 3DSprite mit einer anderen ID als der des 2DSprites zu versehen wäre, wenn man auf Rotate und Zoom bei einigen Sprites verzichten möchte und bei anderen es aber nutzt.

exakt!
damit kann man dutzende gegner aus dem selben basissprite machen,
die sich alle unterschiedlich bewegen. nur als beispiel.

>> Das Problem ist, dass für alle IDs, die kleiner als deine via #PB_Any erzeugte ID sind (die ja eigentlich eine virtuelle Speicheradresse ist), Speicherplatz für 3D-Sprites reserviert werden würden.

> Das möchte ich bezweifeln.

nicht für die sprites, sondern für die objekthandles.
wenn man ein sprite, gadget, was auch immer erzeugt, legt PB eine Tabelle an,
die nach den PB-Nummern dieser objekte geordnet ist.
wenn ich also ein Sprite mit der nummer 1000 erzeuge, legt PB eine Tabelle mit 1000 einträgen an.
deswegen gibt es PB_Any, damit wird diese tabelle nicht angelegt.
der rückgabewert ist direkt das Handle, keine PB-Nummer.
bei über 10000 würde die tabelle etwas groß,
deswegen kann man dieses Handle auch nicht wie eine Nummer verwenden,
also meckert der Compiler das an.

wenn du unbedingt fixe nummern verwenden willst, dann verzichte eben auf #PB_Any,
und fang halt mit deinen Nummern bei 0 an, dann hältst du die Tabelle klein.

PureBoard

#PB_Any - Problem mit Debugger - halb(gelöst)

#PB_Any - Problem mit Debugger - halb(gelöst)