JLI Spieleprogrammierung

[ProC++]

Hallo erstmal

Ich habe folgende Probleme, und hoffe, dass mir jemand bei der Lösung helfen kann.
1.) Ich habe mir eine Klasse erstellt, in der ein SpriteObjekt erzeugt wird. Und dieses gebe ich natürlich im Destruktor wieder frei mit

[Fallen]

Hi,

wegen deinem Release() Problem:

Du müsstest etwas mehr Code liefern wenn es recht ist, vermuten kann ich aber dennoch schonmal:

- Das Sprite Objekt wurde schon frei gegeben und zerstört.
- Das SpriteObjekt wurde nie erstellt aber m_lpSprite zeigt auf etwas (Datenmüll)

2) Dein Weg der Kollisionserkennung ist schon aufgrund der enormen leistung verkehrt Es sei denn du hast es schon ordentlich optimiert (nur relevanten Bereich locken, etc.)

Aber auch hier bräuchte ich etwas mehr Code, so kann ich nicht sagen was du falsch machst, da es beim Locken eine ganze Menge zu beachten gibt.

3) ich arbeite schon seit einigen Jahren mit DirectX und kenne bisher auch nur BeginScene/EndScene aus den Kopf Ein bissl übertrieben aber ich persönlich habe entweder so etwas wie intelliSense was mir mögliche Funktionen direkt im Code anzeigt oder eben die DX Dokumentation offen. Die Doku allein deswegen schon weil man dort vieles nachlesen kann/muss.

mfg Mark
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[ProC++]

Moin!

Naja, ich lade ja die Textur auf mein SpriteObjekt, und bekomme das dann beim kompilieren auch angezeigt...also auf Datenmüll zeigt es dann nicht, oder?
Eigentlich wird das Objekt ganz simpel in meiner Init() Funktion:

[Fallen]

Interessant wäre es dann zu wissen wo genau denn deine Klasse frei gegeben wird, vor oder erst nach dem zerstören des Devices?

Ansonsten wüsste ich spontan nicht wo das Problem auftritt. Allerdings arbeite ich mit D3DXSprite nicht mehr :/

Wegen der Kollision: Möglicherweise könnte das ok sein, bin mir nicht sicher wie es beim Readonly abläuft, da aber keine Daten wieder hochgeladen werden müssen könnte die performance ganz ok sein. Probleme mit der performance bringt es allerdings wenn du viele Überprüfungen hast und dort jedesmal Lock/Unlock benutzt, das kostet leider Zeit.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[ProC++]

Vielen dank übrigens überhaupt für die schnelle Antwort vorhin!
hmm,wie stell ich denn am besten fest, in welcher Reiehnfolge die Objekte wieder freigegeben werden?
Die Draw-Funktion der Klasse wird nur zwischen den BeginScene- und EndScene-Aufrufen ausgeführt. und sonst garnicht.
erzeugt wurde das Klasse-Objekt ja erst nachdem ich das Device erzeugt habe, und mein Fenster wird mit der "DestroyWindow(HWND)"Methode geschlossen.
Werden dabei nicht die Devices von innen nach außen freigegeben...also
dass was als letztes erzeugt wurde, wird zuerst freigegeben?
Oder lieg ich da ganz falsch mit meiner Vorstellung?
mfg Timo

[Fallen]

Wenn du mit new und delete arbeitest bleibt das dir selbst überlassen und wenn es auf die Reihenfolge der freigabe ankommt würde ich auch darauf setzen um das etwas besser steuern zu können. Wie es ohne pointerspass abläuft weiss ich jetzt leider nicht.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[ProC++]

Du meinst sicherlich mit new eine Instanz der Klasse anzulegen in Form von

[Fallen]

Das er beim erzeugen einer Instanz mit new Abstürtzt ist in der Tat recht seltsam, kannst du nicht einfach mal den ganzen Code posten?

Wegen dem Locken, managed texturen sind lockbar, wieso es genau nicht bei dir geht kann ich jetzt nicht sagen, stürtzt er da ab, oder sowas?

Allgemein bei solchen problemen würde ich empfehlen Breakpoints (F5) zu setzen und dann ein Debug Build auszuführen, hält das Programm dann an den Breakpoints kannst du da schön untersuchen wo das Problem genau löst indem du Werte untersuchst oder einfach nur weitersteppst (F10/F11).
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[ProC++]

Uppps, ist mir jetzt ein bisschen unangenehm. Die Klasse lies sich mit new nicht anlegen, da ich die ganzen Variablen-Initialisierungen testweise aus dem Konstruktor genommen hatte. Ich weiss nicht wie ich bei Win32 Anwendungen einen Debug Buid erstellen kann...hatte alles bei Konsolen-Projekten nach der Buch-Anleitung eingestellt, aber bei Win-Projekten sind diese Einstellungen weg. Und sowieso weiss ich nicht wie das mit den Symbol-Files gehen soll. Darum muss ich verdächtigen Code immer auskommentieren um Problemen auf die Spur zu kommen . aber das ist ja hier ein bisschen ab vom Thema.

Zum Locken - er stürzt nicht ab und gar nichts... nur werden die Farben nicht aus der Textur gelesen....hatte zu Testzwecken eine Funktion erstellt, die als Rückgabewert die Farbe an XY-Spielerposition hatte und habe mir eine kleine Surface mit dieser Farbe erstellt...allerdings war dieses Surface an jeder Position des Spielers im Spiel weiß - wie die voreingestellte BG Color mit der verglichen wird.


Das Sprite-RELEASE Problem ist jedenfalls behoben dafür schonmal vielen Dank.
MfG,
Timo

[Fallen]

Du könntest den Rückgabewert von LockRect mal überprüfen, ganz simpel zB so:

[ProC++]

Hallo!
Puh, ich hab nun noch ein wenig rumprobiert, allerdings ohne nennenswerten Erfolg. Meine Leveltextur hat ja eine ganz andere Auflösung, als das Spiel....so musste ich casten wie ein wilder. Habe zum Ausprobieren das Flag bei LockRect auf D3DLOCK_DISCARD gestellt, und alle Pixel an XY osition knallrot gefärbt. Das hat nun auch wunderbar funktioniert, und jetzt bin ich mir sicher, dass die Pixel an der gewünschten Position gelesen werden (wenn sie es denn richtig würden). Dadurch, dass ich die entsprechenden Pixel eingefärbt hae, und dass mir dass auch im Spiel angezeigt wurde, gehe ich doch davon aus, dass die Textur im richtigen Pool angelegt wurde. Aber da ich nich so die Ahnung habe, wie andere in diesem Forum poste ich einfach nochmal den Code.
1.) Anlegen der Textur:

[ProC++]

Okay, bitte schlag mich nicht.... .....
Problem erkannt, Problem gebannt^^. Ich habe ja in der D3DXCreateTextureFromFileEx() Methode den untransparenten weißen Hintergrund mit dem ColorKey auf transparentes Schwarz gesetzt. Natürlich dachte ich, dass wenn ich die Pixel der Textur lese, ich die Originalfarben(also weiss) erhalte. Falsch gedacht, ich habe die Vergleichsfarbe jetzt auf transparentes Schwarz gesetzt und siehe da - es funktioniert.
Allerdings hapert es jetzt an der Implementierung der Spring-Funktion. Aber das bekomme ich hoffentlich bald in den Griff. Aber falls zufällig jemand eine intelligent gelöste Spring- Funktion zur Hand hat, hätte ich nichts dagegen wenn diese hier gepostet würde, hrhr. Also vielen Dank ersteinmal für deine kompetente Hilfe Fallen.
Mit freundlichen Grüßen,
Timo

[Fallen]

Springfunktion? Glaube das gabs im Forum schon einige male:

Beim Tastendruck und Bodenkontakt:
Y-Bewegungsgeschwindigkeit auf Sprunggeschwindigkeit setzen

Beim Updaten der Objekte:
Y-Bewegungsgeschwindigkeit um Gravitationskonstante verringern
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."