Danke! Das gute ist, durch glAlphaFunc(GL_GREATER, 0.1); sieht man das gar nicht, man hat also ca 256-(256*0.1)=230 verschiedene Werte, die man für Eigenschaften nehmen kann.

Wo ich gar nicht dran gedacht hab: im Projekt sind meine Tools-Funktionen drin, die logischerweise keiner hat. Aber eigentlich gings mir auch mehr um das Prinzip an sich. Ich hab jetzt übrigens schon eine neue Architektur. Das weitere Leben diese Projektes wird man hier bestaunen können:
http://underbyte.ath.cx:230/worms.html

Übrigens danke für die Idee, ich hab schon lange überlegt, was ich mal proggen könnte! (Ich hatte vor Jahren mal nen Lemmigs-Klon angefangen, aber der war zu langsam. Allerdings auch ohne Quadtree.)

_________________
Gott sei Dank bin ich Atheist!

dann kannst du uns ja seelischen beistand leisten ^^ probleme stellen sich bei mir bei den pixelkollisionen und dem laufen auf ungeradem untergrund, man muss ja einen normal vektor finden der der steigung entspricht und den man dann mit der geschwindigkeit multipliziert. bei so pixelkram hab ich leider überhaupt keinen plan ^^

Würde ich gar nicht mal unbedingt sagen, dass man einen Vektor braucht. Ich würde bloß versichen, die Figur zu versetzen und gucken obs geht. Das dann im Rahmen der "Kletterfähigkeiten" der Figur, und schon (sollte) es gehen.

Zur Kollisionsüberprüfung teste ich grade, ob ein Brue-Force Überprüfen der Bounding Box der Figur ausreichend schnell machbar ist. Praktischerweise kann man den Aplhankanal als Kollisionsmaske nehmen. Bei 30 Lemmingen mit 30*15 sind das 9000 Überprüfungen, das sollte drin sein.

UPDATE:Ohne Kollisionsprüfung: 450 FPS, mit=480FPS ! Also irgendwo im "Messrauschen".
Außerdem hab ich eine neue Techdemo hochgeladen, jetzt ordentlich mit Klassen programmiert.

_________________
Gott sei Dank bin ich Atheist!

Nur wenn man die Map als eine große Textur macht, kommt schnell an die Hardware Grenzen, was tun ?

Hab auch noch nen älteres Projekt dass aus einer schwarz-weiß karte ähnlich wie der worm-editor eine bunte karte erstellt. Die Beispieltexturen sind leider unansehlich, da ich damals Texturen aus einem Spiel extrahiert habe, die ich natürlich nicht veröffentlichen kann.
http://thewinner.th.funpic.de/landscapegenerator.rar

danke, mir fehlt aber die unit: winnercommands.pas

Hab zwar die Winnercommands freie main.pas ins archiev integriert, jedoch im falschen Verzeichnis^^
Also entweder die main.pas aus dem übergeordneten verzeichnis ins Gelände Verzeichnis kopieren, oder erneut downloaden.

da stimmt immer noch was mit der dateiensuche net, die funktion heißt anders und erwartet andere parameter Oo

@Martok: mach doch hier mit: http://www.delphi-forum.de/topic_62944.html

OK, hab mich angehängt.
Edit: bin im Boot!

_________________
Gott sei Dank bin ich Atheist!

Da ich im anderen Forum nicht registriert bin, gebe ich meine Kommentare zu eurem Lemmings hier ab.

Zum einen rate ich vom pixelbasierten Ansatz ab, es sei denn ihr wollt gerade diese Herrausforderung.
Denn bei Lemmings bringt das vom Spielgefühl kaum Vorteile und auch ein paar Nachteile (Treppen legen etc).
Vom Programmieren her ist es jedoch sehr viel aufwändiger, und wahrscheinlich auch deutlich Langsamer in der Ausführung. Zudem frisst ein hochauflösendes Level in 32bit doch leicht Arbeitsspeicher (z.B. 5*5 Bildschirme=100MB).

Daher rate ich dazu einem Tile/Block basierten Verfahren bei dem ein Block 16x16 Pixel groß ist, und ein Lemming 2x4 Blöcke groß ist. So lässt sich die "Physik" relativ schnell implementieren.

Falls ihr Netzwerk implementieren wollt, müsst ihr euch noch in der Planungsphase genau überlegen wie es funktionieren soll. Nachträgliches hinzufügen von Netztwerkfähigkeit ist sehr schwer (siehe Anno1503).

Zudem steht ihr vor der Frage ob ihr das ganze Frameratenunabhängig implementieren wollt, was bei einem Blockbasierten Spiel nicht ganz einfach ist. Das könntet ihr beispielsweise so lösen(hab das damals bei meinem Loderunner so gemacht):
Man weiß wie viel Millisekunden(ms) seit dem letzen Frame vergangen sind. Zusätzlich speichert jeder Lemming wie viele ms seine aktuelle Aktion noch dauert, und wie viele ms sie insgesamt dauert.

Lemming.DoMove:


Lemming.DoDraw:


(Aus dem Gedächtnis, können Bug drin sein)

bei letzterem sehe ich irgendwie nicht wo da ein problem sein soll ? das komplette projekt ist auf timebased movement ausgelegt, dazu gehören sämtliche bewegungen, zeitbestimmungen und animationen.

und das problem mit den großen texturen ist auch net so gravierend, da dort letztenendes ziemlich viel durch den alphakanal wegfällt. wir konnten bereits bei texturen um die 640*480 beobachten, dass der alphakanal eine menge ausmacht und die hintergrundgrafik wird eben gestreckt gezeichnet, dafür würde eine 512*512 oder 256*256 textur ausreichen

und die kollisionsabfrage läuft ohne jegliche frameeinbußen, da viel arbeit schon beim laden der map gemacht wird.
(alpha kanäle der lemmings speichern, boundingboxes erstellen, ...)

Der Landschaftsgenerator sollte jetzt funktionieren.
Und wie ihr um die 100MB Ram fürs Level rumkommen wollt, ist mir auch net ganz klar. So wie ich die Lemmingslevel in Erinnerung habe sind die schon einige Bildschirme groß. Und da ihr das Level ja Pixelgenau modellieren wollt, braucht ihr für jeden Pixel halt 32 Bit. Wenn ihr das Level dagegen streckt, geht doch der Vorteil eurer hohen Auflösung verloren.

es fallen aber doch die pixel weg, deren alpha $00 ist

vielleicht finden wir auch irgendwie ein möglichkeit wie mit dem landschaftsgenerator nur 3 texturen oder so zu benötigen und die geschickt aufs bild zu zeichnen


wie ist das bei spielen, die zb gigantische hintergründe haben ? directx ?

Bist du dir sicher, dass die im RAM/VRAM auch wegfallen?