Ergebnis 1 bis 20 von 116

Thema: Alles auf dem Maker ist möglich

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Ja, exakt das Skript meine ich.
    Leider habe ich es auch nicht mehr in meinem Skriptordner.
    Ich könnte mich aufregen das ich das gelöscht habe.

    Als alternative Referenz kann ich das hier bieten.
    Ist ein Megaman J&R Pixelmovement Skript von Zeph. Auch sehr gut
    meiner Meinung nach.

    Gelenkt wird mit den Pfeiltasten, mit Numpad 0 kann man schießen und Numpad ,/Entf wird gesprungen.

  2. #2
    Man könnte ihn ja mal fragen, ob er es noch hat^^

    @Script, gefällt mir schon mal sehr gut^^

  3. #3
    Ja, Lachsens Script würde mich auch interessieren, nachdem ich mir den Thread da mal durchgelesen habe =D

    @ Skript von Zeph: Stimmt, da haben wir ja nen Pixelmovement-beispiel...
    Nur: Warum sollte man es sich mit Pixelmovement so komplieziert machen, wenn es mit Tilemovement genauso "flüssig" aussieht? Das Script beinhaltet eher nur einen komplizierteren Weg, der nicht mehr als dasselbe bringt... Wenn Geschwindigkeitsunterschiede ins Spiel kommen (beim Sprung, fallen, etc.), dann würde es damit schon wieder ganz anders aussehen... (aber das ist wirklich alles andere als mal eben schnell gemacht ^^').

    greetz!
    elsen =)

  4. #4
    lol

    Bitte, mit eventmovment, bekommst NIE, NIE so ein gutes Pixelmovment hin.
    Ich glaube da fehlt dir die Erfahrung oder, denn Pixelmovement ist mit Tiles schlecht möglich.

    das wird ein, wie schon gesagt wurde -.- Up/down(Left/Right), was völlig daneben aussieht und meißt total kantig zu spielen ist, da es sich eben nur auf Tiles bewegt, und nich so flexibel wie ein Bild ist.

  5. #5
    Zitat Zitat
    denn Pixelmovement ist mit Tiles schlecht möglich.
    Hat ja niemand behauptet, vor allem, da es nicht geht xD

    Ich habe mich auf das Script bezogen und dort spielt es sich nicht sehr anders als meins, mit Tilemovement.. Sicher gibt es Unterschiede, aber die heben sich dort nicht zu sehr raus.
    Springen läuft vllt ein wenig flüssiger dort, aber eben nur ein wenig, weswegen ich nicht so einen großen Aufwand für Pixelmovement betreiben würde.
    Zweck und Nutzen stehen da eindeutig im falschen Verhältnis zueinander!
    [EDIT]Die wirklich flüssigen Seitwärtsbewegungen (sowohl beim Laufen, als auch beim Springen), die du mit Sicherheit meinst, sind natürlich nicht mit Tilemovement möglich, aber auch auf die war meine "Verhältnisaussage" bezogen... vllt ist nur nicht angekommen, dass ich mich auf die Gravitation bezogen habe![/EDIT]^^

    greetz!
    elsen =)

    Geändert von elsen (03.11.2008 um 16:24 Uhr)

  6. #6
    Naja, ich denke das man schon einen deutlichen Unterschied bemerkt.
    Auf Tilemovement wird es dir unmöglich sein eine Bewegung zu setzen die unter 16 Pixel ist. Genau so schaut es bei den kontrollierbaren Sprüngen aus. Du kannst hier immerhin kurz oder lang springen. Bei einem Tilemovement wärst du wieder an die Kästchen gebunden.

    Wenn du also ein Tilemovement im Vergleich heranziehst ist es schon ein ziemlicher Unterschied. Zudem Zeph ja auch nur die Basis hergestellt hat. Und diese Basis ist schon einem Tilemovement klar überlegen. Restliche Erweiterungen sind dann auch nur eine Frage der Zeit.

  7. #7
    Zitat Zitat
    denn Pixelmovement ist mit Tiles schlecht möglich.
    Kommt auf die Dimensionen des CharSets an. 16x16 funktioniert rein theoretisch auch flüßig.

  8. #8
    Zitat Zitat von makenshi
    Auf Tilemovement wird es dir unmöglich sein eine Bewegung zu setzen die unter 16 Pixel ist. Genau so schaut es bei den kontrollierbaren Sprüngen aus. Du kannst hier immerhin kurz oder lang springen. Bei einem Tilemovement wärst du wieder an die Kästchen gebunden.
    mh.. Technisch wird man wohl weiterhin an die Terrain IDs gebunden sein, welche ja den Kästchenabstand haben (ja, faszinierend nicht?^^) aber es stimmt schon, damit hat man halt eine Grafisch angenehmere Lösung....

  9. #9
    Zitat Zitat von elsen Beitrag anzeigen
    mh.. Technisch wird man wohl weiterhin an die Terrain IDs gebunden sein, welche ja den Kästchenabstand haben (ja, faszinierend nicht?^^) aber es stimmt schon, damit hat man halt eine Grafisch angenehmere Lösung....
    Japp, nur ist das ja relativ wurscht. Das bezieht sich dann ja lediglich auf ein Kästchen Terrain. Die Bewegungsfreiheit des Charakters ist dann trotzdem von diesen losgelöst. Oder wolltest du auf etwas anderes hinaus?

    @Phno
    Japp. Bei der Demo vom Tastenpatch ist ein imo recht gutes "tilebasiertes" Movement. Afaik war es jedenfalls "tilebasiert". Man merkt jedoch auch bei einem entsprechenden Charset das man sich nicht pixelweise bewegt.

  10. #10
    Zitat Zitat von makenshi Beitrag anzeigen
    Oder wolltest du auf etwas anderes hinaus?
    Also mit dem Post oben wollte ich lediglich auf die Gravitation aus, weil das ja vorher im Gespräch war (1-2 Seiten vorher) und als es dann um das Pixelmovementscript ging, hab ich mich ganz frech darauf bezogen (es ging halt darum, dass man eine "realistische" Gravitation (á la schneller Absprung, langsamer werdend, schneller werdendes Fallen) zustande bekommt).
    Ich denke, nun sollte es keine Missverständnisse mehr geben

    greetz!
    elsen =)

  11. #11
    Wie sieht das eigentlich mit der Kollisionsabfrage aus? Terrain-ID wurde hier genannt, aber das würde ja heißen, dass sie immer noch tile-basiert wäre. Lässt sich damit ein vernünftiges Jump'n Run machen? Ein Standardelement von denen sind ja z.B. sich vertikal bewegende Plattformen, für die man eine möglichst genaue Kollisionsabfrage benötigt. Schräger Untergrund würde mit einer tile-basierten Kollisionsabfrage auch nicht funktionieren.

  12. #12
    Pixelgenaue Kollision ist ohne Hacks/Patches/whatever leider nicht möglich.

  13. #13
    Zitat Zitat von Kelven
    Schräger Untergrund würde mit einer tile-basierten Kollisionsabfrage auch nicht funktionieren.
    Mh, im Prinzip funktioniert das doch auch genau, wie alle anderen Kollisionen. Man müsste es nur Grafisch richtig Darstellen! (nicht, dass der Held mit einem Fuß IM Boden steht und mit dem anderen halb in der Luft^^).

    Zum Thema vertikal bewegende Plattformen würde ich aneinandergereihte Events nehmen, mit der Plattformgrafik (oder auf diesen ein Picture anzeigen lassen) und dann nicht per Tile ID sondern per Event ID die Kollision abfragen!
    Ist jetzt zwar nicht Pixelgenau, die Genauigkeit der Kollision sollte den Umständen entsprechend jedoch passend sein.^^

    greetz!
    elsen =)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •