Minigames-Contest

    Wenn du einfache Hitboxen haben möchtest, die sich nicht drehen oder sonstiges, dann nimm einfach ein Rechteck und überprüfe die Kollisionen.


    Ansonsten müsstest du entweder auf Pixelgenaue Kollision zurückgreifen (was sehr langsam ist) oder auf Überschneidung von Polygonen setzen.


    Hier mal die einfache Formel um zu prüfen ob ein Punkt in einem Polygon liegt. Das Theorem dahinter ist der Jordanscher Kurvensatz


    Java
    1. public static boolean isVectorInHitbox(Vector vector, Hitbox hitbox) {
    2. int nvert = hitbox.getPointCount();
    3. int i, j, count = 0;
    4. for (i = 0, j = nvert - 1; i < nvert; j = i++) {
    5. if (((hitbox.getPoint(i).getY() > vector.getY()) != (hitbox.getPoint(j).getY() > vector.getY())) && (vector.getX() < (hitbox.getPoint(j).getX() - hitbox.getPoint(i).getX()) * (vector.getY() - hitbox.getPoint(i).getY()) / (hitbox.getPoint(j).getY() - hitbox.getPoint(i).getY()) + hitbox.getPoint(i).getX())) {
    6. count++;
    7. }
    8. }
    9. return (count % 2 != 0);
    10. }


    Die HitBox ist eigentlich nur ein Container für eine Liste aus Punkten die ich mir gebastelt habe. Das coole dabei ist, das es eigentlich ziemlich schnell ist und vorallem kann man dadurch seine eigenen Hitboxen bauen.

    Einfach? :ugly:
    Ich hatte schon immer Probleme mit Mathetheoremen -.-' Muss ich mich mal durchfriemeln.

    Nachdem ich heute dann einen Tag drauf verschwendet habe herauszufinden dass die Tiledmaps zur Laufzeit nicht veränderbar sind (oder ich einfach nur blind bin) werde ich das Rendering der Welt wohl doch einfach selbst übernehmen, was den Vorteil hat dass ich theoretisch die gesammte Welt um-und bebaubar machen könnte, sofern ich dafür die Zeit hätte. Wobei ich erstmal 2 Tage dran sitzen werden eine eigene Engine zu bauen.

    Zitat

    Wobei ich erstmal 2 Tage dran sitzen werden eine eigene Engine zu bauen.


    Du Optimist :ugly: Wenn du wirklich alles schreiben willst, dann bist du bestimmt länger dran. Wenn du einen Hybrid machst, dann kommt das bestimmt halbwegs hin.


    Zitat

    Nachdem ich heute dann einen Tag drauf verschwendet habe herauszufinden dass die Tiledmaps zur Laufzeit nicht veränderbar sind


    Das finde ich etwas merkwürdig. Ich kenne zwar nicht das System von Slick, aber das wäre wirklich sehr merkwürdig und vorallem auch einschränkend...



    Anbei nochmal ein Bild von dem, was ich heute so geschafft habe. Es ist zwar bisher nur ein Test, aber Ich befürchte fast das es auf Städtebau hinausläuft..

    Ich bin mit dem Kern komplett fertig.


    Jetzt muss ich mir XML-Parser angucken. Zum Glück habe ich noch kein XML gelernt und Parser fand ich auch ganz schrecklich :ugly:


    Aber mit Slick komme ich gut zurecht. Nur heute hat es etwas gehangen und fast 7 Stunden gedauert, bis ich einen klickbaren Textbutton hatte :ugly:

    XML geht wirklich noch, da gibt es auch schon sehr praktische fertige Parser. Halte dich nur von JDom fern wenn dir dein RAM lieb ist :ugly: (für jeden Knoten ein Objekt)


    Hab jetzt auch mein Problem gelöst, ich speichere effektiv Subimages, was soviel heißt wie ich könnte genauso gut jede Menge einzelne Images speichern, aber naja ^^ Random Karte inklusive :ugly:


    Edit:
    Mit Druck der Taste e kann man nun das Feld auf dem man steht zwischen Gras und Gravel togglen. Hammer :ugly:

    Kleiner Tipp meinerseits, falls du es nicht sowieso schon machst. Erzeuge zu jeder Subtextur und Textur immer nur genau eine Intanz! Wenn du sie gedreht oder vergrössert darstellen willst, dann erzeuge dir keine neue und drehe sie, sondern erzeuge ein Objekt das diese Daten speichert.


    Anschliessend machst du folgendes:
    1. Matrix zum Mittelpunkt der Textur versetzen.
    2. Matrix drehen
    3. Matrix skalieren
    4. Textur malen


    Dadurch brauchst du nur eine Texturinstanz und kannst sie beliebig drehen/skalieren/verschieben.

    Ich habe für jede Textur exakt eine Instanz. Das ist eine Sache die bei Java irgendwie keiner versteht, man geht nicht hin und haut am besten in jeder Iteration neue, am besten anonyme, Objekte rein, die nach 2 Operationen fallen gelassen werden. Aber sich dann über Performance und Speicherverbrauch aufregen :ugly:


    Ich finds halt nur atm ein wenig Schade dass ich für jeden Teil der Texturen den ich einzeln zeichnen möchte ein subImg anlegen muss, und die Doku für die draw() Methoden extrem unzureichend (und teilweise wiedersprüchlich) ist.

    Geras schrieb:

    Ich finds halt nur atm ein wenig Schade dass ich für jeden Teil der Texturen den ich einzeln zeichnen möchte ein subImg anlegen muss, und die Doku für die draw() Methoden extrem unzureichend (und teilweise wiedersprüchlich) ist.


    Jain.. das ist nicht ganz korrekt. Das Problem liegt hier nämlich eher bei der Slicklibrary. Die Library ist erstmal so designed das sie nur Texturen mit Zweierpotenz laden kann und ausserdem, und das ist hier das Problem, arbeitet sie beim malen nicht mit Pixeln, sondern mit UV-Koordinaten (0..1). Eben dieser Umstand würde immerwieder eine Umrechnung zur Folge haben, wenn man nur bestimmte Ausschnitte zeichnen möchte (von Pixel in eine Zahl zwischen 0..1).


    Mit LWJGL gibt es allerdings noch eine andere Möglichkeit, die ich mir gebastelt habe. Ich habe den Slick-Texturloader genommen und an 2 oder 3 Stellen etwas geändert. Nun kann ich jede beliebige Größe laden und ausserdem werden meine Texturwerte in Pixeln angegeben und nicht mehr in 0..1


    Ich selbst nutze zwar auch das SubImage-System (kein Slick, sondern was eigenes), aber das hat Gründe die mit der Animation von Objekten zu tun hat. Rein theoretisch (naja und praktisch gehts auch) kann man jetzt einfach eine Funktion schreiben die folgendermaßen aussieht:



    Das würde einem genau das ermöglichen was du wolltest. Statt Texture_2D nutzt man dann nämlich GL_TEXTURE_RECTANGLE_ARB (org.lwjgl.opengl.ARBTextureRectangle.*).


    Wenn du willst kann ich dir mal die veränderten Textureloader von mir schicken. Du kannst weiterhin beide Systeme nutzen, da sie sich nicht gegenseitig ersetzen.



    So... nun zu meinen Ergebnissen... nachdem ich mich jetzt geschlagene 2 Tage mit verschiedenen Arten von ISO-Render-Methoden rumgeschlagen habe, um nur die Tiles zu rendern die wirklich zu sehen sind... hier mal ein Proof-Of-Concept vom Stand der Dinge. Mein größtes Problem ist jetzt eigentlich die Herstellung von Pixelart-Gebäuden und das füllen mit Content... alles andere funktioniert im Grunde schon :)