Probleme beim 3DObjekt überschreiben

Previous topic - Next topic

nabz32

Hallo, vor kurzem habe ich ein 4 Seitiges Modell in GLBasic erstellt.

Ich wollte das Modell beim Laden eines neuen Levels neu generieren,
da seine Größe und UV Daten abhängig von der Levelgröße sind.

Sobald ich versuche das Modell das erste mal zu überschreiben stürzt mein Programm ab
( Wenn ich das überschriebene Modell nicht ausgebe stürzt allerdings auch nichts ab ).
Debug sagt Exception Access violation.

Ich habe schon viele in GLBasic geschriebene 3D Objekte in meinem Code, die nach Zeiten überschrieben werden, aber das ging bis jetzt immer gut.

Hat jemand vieleicht ne Idee an was das liegen könnte ?

nabz32

Habe den Fehler gefunden,
habe das Objekt im frame davor eine Bump Map Textur 0 gegeben statt der üblichen -1 für keine Textur...

Anscheinend lässt GLBasic eine nicht existierende Bump Map Textur erstmal zu beim Befehl X_SETTEXTURE.
Treten nach dem drawen aber Änderungen an dem Objekt auf, kann das zum Absturz führen.

kanonet

Hmm, klingt irgendwie Unlogisch, sicher dass das der Grund ist? Gibt es dazu eventuell ein kurzes und ganz einfaches Testprogramm?
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

nabz32

#3
Hier ein Test dazu:

Code (glbasic) Select
run()

run()

FUNCTION run:
LOCAL exit%
SETCURRENTDIR("Media")
LOADSPRITE "bike.bmp" , 0
LOADBUMPTEXTURE "bike.bmp" , 1
loadBike(0)
loadBike(1)
WHILE NOT exit
//loadBike(0)
loadBike(1)
CLEARSCREEN RGB(0,0,0)
X_MAKE2D
PRINT "TEST",50,50,TRUE
X_MAKE3D 1 , 5000 , 45
X_CAMERA 0 , 0 , 0 , 0 , 0 , 400
X_MOVEMENT -150 , 0 , 400 // prepare Drawing Object 0
X_SETTEXTURE 0 , 1 // with bump map
X_DRAWOBJ 0 , 0
X_MOVEMENT 150 , 0 , 400 // prepare Drawing Object 1
X_SETTEXTURE 0 , -1 // without bump map
X_DRAWOBJ 1 , 0
SHOWSCREEN
WEND
ENDFUNCTION

FUNCTION loadBike: nr%
X_LOADOBJ "bikec.ddd",nr
ENDFUNCTION

Wenn man eine Textur als Bump Textur angibt und das Objekt danach wieder neu lädt, zerstört das in diesem kleinen Rahmen die Test Textausgabe.
Ohne überschreiben des Objektes keine Probleme mit Bump Textur.
Dabei ist es egal ob die Bump Textur geladen wurde oder es eine nicht existierende Bump-Texturnummer ist.
Es wirkt sich scheinbar nur auf die Textausgabe aus, Sprites werden noch normal dargestellt,
wenn man das loadbike(0) auskommentiert.


nabz32

#4
Anscheinend erlaubt einem GLBasic nur 3D Objekte ohne Bump Mapping außerhalb von X_MAKE3D darzustellen, lädt man die Objekte nach X_MAKE3D verhält sich die Textausgabe normal.

Dachte immer das Laden vor X_MAKE2D bzw. 3D wäre Sinnvoller, hatte auch ohne die Nutzung von Bump Maps nie Probleme gehabt mit dem Laden von Objekten vor dem XMAKE_3D.

kanonet

Ehrlich gesagt, verstehe ich dein Problem überhaupt nicht (bzw. dass, was ich zu verstehen meine, ergibt keinen Sinn). Dein Code-Beispiel funktioniert bei mir problemlos, egal ob ich die Zeile loadbike(0) ein- oder aus kommentiere, dass Ergebnis sieht immer gleich aus, die Schrift ist lesbar und von den Eingangs erwähnten Abstürzen ist auch nichts zu sehen.

Übrigens verwendet man X_MAKE2D üblicherweise, nachdem man mit allem 3D Zeugs fertig ist und nicht davor (sonst verdecken die 3D Objekte möglicherweise die 2D.

In den meisten Fällen sollte etwa ein Programm so aussehen:

Code (glbasic) Select
Objekte, Texturen, etc... laden
WHILE TRUE
input
spiellogig
texturen oder objekte manipulieren
X_MAKE3D
X_CAMERA
3D Zeug rendern
X_MAKE2D
2D Zeug rendern
SHOWSCREEN
WEND


Außerdem funktioniert eine bumpmap nicht ohne X_SPOT_LT (und macht auf Intel-Grafikkarten Probleme).
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Schranz0r

Bump brauch ein Licht das ist richtig, auch hat er mit der Aufteilung 3D und 2D recht.
Hat kanonet perfekt beschrieben im Pseudocode!
Sollte so schon fast in die Hilfe eingebaut werden!
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

kanonet

Gibt davon übrigens auch eine Langversion, bei der ich die Position praktisch aller X_-Befehle im Programmablauf beschreibe (manche können natürlich auch an anderer Stelle sinnvoll verwendet werden): www.glbasic.com/forum/index.php?topic=7948.msg66790#msg66790
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

nabz32

Also bei mir kommt der fehler noch, wenn ich das einkommentiere
Das man 2d vor 3d aufruft dürfte ja so ziemlich klar sein, war nur in dem testcode zu schnell reingeknall deswegen nicht drauf geachtet

nabz32

Ps auf der pandora muckt der code auch nicht auf.

kanonet

Hmm, möglicherweise eine Sache deines Grafiktreibers? Tritt nur ein Grafikfehler auf, oder stürzt es immer noch ab, wie im Eingangspost beschrieben? Kannst du mal einen Screenshot des Fehlerbilds posten?. Also mit meinem Modell+Texturen konnte ich den Fehler nicht nachvollziehen, aber du kannst natürlich auch gern noch mal nen gzipptes Testprojekt mit deinen Modell+Texturen senden (gern auch per PN), dann probiere ich das hier nochmal.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

nabz32

Sry, dass es so lange gedauert hat.

Hier mal der screenshot vom Fehler ( Die weißen verstreuten pixel sollten eigentlich der Text sein ):



(In diesem Beispiel stürzt es nicht ab, ein Absturz kommt dann wohl erst wenn man noch irgendwelchen anderen Befehle dazu ausführt, in meinem Spiel waren das einige ).

Habe auch das modell und die textur angehängt.

nabz32

#12
Edit:
Danke fürs beseitigen des Spams. :good:

Schranz0r

Hey, wurde beseitigt.
Danke für die Info :)
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard