spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Du kannst immer Integer nehmen, denn die Kollisionserkennung sollte mit dem Bild übereinstimmen und da sind auch keine Floats möglich.
Zumindest mein Monitor zeigt nur ganze Pixel an und erzeugt keine neuen Pixel zwischen den existierenden

Also kannst du mit Float arbeiten und die Ausgabe mit Kollisionserkennung in Integer verarbeiten.

Zitat von »"David Scherfgen"«

Es erinnert mich ein bisschen an "World of Goo". Sehr hübsch!
Edit: Oh, hat schon jemand geschrieben

War auch mein erster Gedanke.

Sehr schönes Spiel.

Zitat von »"fred2507"«

mit floats wäre die kollisionserkennung nicht mehr so effizient. das spiel läuft bei mir so wie es ist ohne lock mit 2500 fps. mit den floats sin es 1800.

Naja.. auf die 700 fps kann ich verzichten, mehr als 60 sehe ich sowieso nicht

Edit: Ich war mal so frei und habe es in meine Dropbox geladen.. rapidshare ist immer so umständlich
http://dl.getdropbox.com/u/346381/J_R_0.59.zip (fred2507, sag bescheid wenn du das nicht möchtest).

Zu deinen Performance gedanken. Ist zwar lobenswert, dass du das ständig im Kopf behältst, aber für dieses Spiel glaube ich dennoch, dasses absolut irrelevant ist. Durch die Art wie es aussieht und sich spielt, kann man zur Optimierung sehr viele annahmen machen, und das ganze WIRKLICH beschleunigen. Ich würd dann die Einbußen der Kollisionserkennung hinnehmen, und das ganze dann frametime-unabhängig machen....

Edit: Außer du hast vor jetzt massiv AI zu schreiben. Mit neuralen Netwerken und dergleichen...

Zitat von »"fred2507"«

hätte ich aber floats die ich für die kollisionsberechnungen auf einen integer bringen müsste, wäre das doch recht ungenau.

Falsch. Aus Sicht des Spielers ist es sogar genauer. Denn er will ja auch da Kollision angezeigt bekommen, wo er es auch sieht.

Der Spieler sieht ja deine Figur. Sagen wir mal sie besteht nur aus einem einzigen Pixel.
Dann befindet sie sich an dem Startpunkt. Jetzt bewegt sich der Spieler und durch die Frametime verschiebt sich der Pixel um 0.4 nach rechts.
Da es aber nur ein fester Raster an Pixeln gibt würdest du abrunden und an der gleichen Stelle darstellen wie vorher (passiert bei 2D eigentlich zwangsweise).
Also ist es für den Spieler doch nur logisch, dass die Kollisionserkennung dort berechnet, wo der Spieler die Figur auch sieht.

Angenommen der Spieler bewegt sich um 0.2 Punkte weiter (also insgesamt 0.6) würdest du die Figur auf dem nächsten Pixel anzeigen lassen (wieder zwangsweise durch den Monitor). Also schadet es nicht einen Pixel weiter die Kollision zu prüfen.

Sogesehen bleibt optisch alles wie bei deinen 60 Frames. Nur wenn sich die Figur mal 2 Pixel bewegt und der Spieler die 1800 Frames hat, sieht er auch den Zwischenschritt.

Das mit dem Performanceverlust ist schade aber ich finde das Spiel erhällt dadurch mehr Vor- als Nachteile. Eventuell kannst du durch die Anpassung an die Zeit auch deinen Bug los werden (du hast geschrieben es ruckelt verdammt wenn die Frames unter 60 liegen).

spiel läuft bei mir flüssig:

win 7 64bit
88er gts 320mb
4 gig ram
am2 athlon 64 x5200+ x2

mir gefällt das spiel auch sehr gut und auch das design. es ist ja noch nicht final, aber was man noch einbauen könnte, wären sounds, highscores (wie schnell man die levels durchgespielt hat z.b.), ein menü.

ansonsten mach weiter so