Dein Spiel ist auch nicht kaputt. Kollisionserkennung macht, was sie soll. Ich meinte lediglich die Abstände zwischen dem Männchen und den Fensterrändern.Das kann ich so nicht nachvollziehen. Das "Männchen" ist 13*23 px groß und wird auch so in alle Himmelsrichtung korrekt von der Kollisionserkennung erfasst.
Beim Fall (oder sonst) steht das "Männchen" auch korrekt auf dem Boden und versinkt nicht.
Dies ist nur beim Jump nötig: player\y = bottom - player\h - 1 ;Figur steht nun bündig auf dem Boden (1px Abstand)
Man kann (beim Sprung) auch (fast) immer sehen was unter einem ist. ????
- Der Abstand zwischen männchen und linkem Fensterrand ist viel größer als der zum rechten Fenster.
- Das Männchen ist zu tief platziert. Wenn du hochspringst, wandert da Sprungziel manchmal aus dem sichtbaren Bereich heraus.
Das Männchen soll nur, wie es ist, ein wenig höher und horizontal mittig platziert werden.
Physikalisch korrekt wäre es:Das ist gewöhnungsbedürftig, aber so schlecht finde ich das Sprungverhalten gar nicht.
Ich denke aber über ein dynamischeres (physikalisch besseres) Sprungverhalten nach.
1. Die Sprungbeschleunigung nimmt zuerst schnell zu (der Absprung mit dem Fuß), bis sie einen gewissen Wert erreicht hat (Je höher dieser ist, desto höher der Sprung).
2. Die Sprungbeschleunigung nimmt stetig ab, bis der Scheitelpunkt erreicht ist (Beschleunigung=0, das Männchen steht "ganz oben")
3. Die Sprungbeschleunigung geht weiter in den negativen Bereich; das Männchen fällt wieder.... Aber auch nur bis zu einem bestimmten Wert (ausprobieren, bis es realistisch wirkt)
4. Solange fallen lassen, bis der Boden erreicht ist (sobald er kollidiert ist, auf Bodenlevel setzen -> Sprungvorgang beendet, ggf. Aufprallsound abspielen.)
Stößt sich das Männchen während dem Sprung den Kopf, wird das Vorzeichen der Beschleunigung von + auf - gewechselt und der Fallvorgang wird eingeleitet.
Ich habe getestet, was du zum Download angeboten hast (https://workupload.com/file/XT78mNE). Vermutlich hast du zwischenzeitig ein Update eingespielt.Also hier scheinst du die alte Version zu meinen. Bei der "aktuellen Version" existiert so ein Verhalten nicht. Es gibt ein "Ammo" von 5 Bällen, die mit einem "Reload-Timer" verknüpft sind.
Dass das geht, ist mir klar. Das sollte aber nicht über Code-Änderungen gemacht werden müssen. Besser wäre eine entsprechende Option im Spiel.Ach das ist doch ganz niedlich für die Auflösung. Du kannst aber auch Großbild nehmen: Kommentiere mal "OpenWindowedScreen(...)" aus und "OpenScreen(...)" ein.
Die schöne Variante: Alt-GR + Return bei laufendem Spiel
Die dennoch akzeptable, einfachere Variante: Optionsauswahl speichern und zum Neustart des Spiels auffordern.
Ich habe mir deinen Source gar nicht angesehen, sondern getestet, wie es ist.
Hier noch ein paar Nachzügler:
- Ich kann mich nicht mehr bewegen, wenn ich auf einem der sich bewegenen Steinen stehe und geschossen habe.
- Die Hintergrundmusik klingt nach Blech. Es bringt nichts, eine schrottige MP3 in OGG mit hoher Bitrate zu verwandeln (oder du hast einen Schrott-Encoder für die OGG-Datei benutzt). OGGs sind normalerweise spätestens ab 128kbps ohne hörbare Verzerrungen
Ich habe mir mal den Code angesehen:
Code: Alles auswählen
If InitEngine3D()
InitSprite()
EndIf
InitMouse()
InitKeyboard()
InitSound()
Den großen if-Block in Tb_plotFrame() kann man auch eleganter lösen. So, wie du es mit der X-Koordinate machst, kannst du auch die Y-Koordinate behandeln
Die Tastatureingaben laufen um ein Frame versetzt. Die Abfrage sollte vor dem Rendern der Welt kommen und nicht zwischen Rendern und FlipBuffers().
Warum greifst du auf die Maus zu, wenn du sie doch nicht benutzt?