Beiträge von domspitze im Thema „Indy III für C64 - FAKE?“

    Also, ich war ja an anderer Stelle recht skeptisch. Aber er scheint echt was an der Engine gemacht zu haben. Die Katakomben sind gut gemacht und auch das Abdecken der Sprites hinter anderen Objekten hat er gut hinbekommen (siehe 7:37 min). Wenn er es jetzt schafft die anderen Räume aus den Previews umzubauen, kann es was werden. Skeptisch bleibe ich wegen dem Nachladen. Er arbeitet weiterhin mit konvertierten Grafiken. Das frisst viel Speicher. Also Nachladen. Es gibt einen Grund, warum MM und ZMK auf Charsets beruhen. Man müsste das Ganze mal mit echten Ladezeiten sehen.

    Immerhin bewegt sich die Spielfigur ruckelfrei. Habe nie verstanden, warum bei MI usw. die Bewegungen, selbst wenn nur die Spielfigur bewegt wird, derart stocken und so unregelmäßig 'mal mehr 'mal weniger, spätestens sobald vermeintlich mehr vor sich geht. Auf einem standard Amiga.


    Habe ich mich früher auch, bis ich mich ein wenig mit dem Code beschäftigt habe. Zumindest der C64 macht mehr als nur bloßes Spriteschupsen. Die Sprites liegen gepackt und auch nur in einer Richtung im Speicher. Erst wenn sie in einer Bewegung gebraucht werden, werden sie entpackt und gespiegelt. Dann wird der Mund einkopiert. Der liegt nur als wenige Bytes im Speicher. Das geschieht alles um Speicher und Disketten zu sparen.
    Weiter zeitintensiv ist es den Vordergrund aus den Sürites wieder rauszurechnen. Im Original wird der Vordergrund nicht mit weiteren Sprites wie hier gelöst, sondern über Chars. Das ist komplizierter, rechenintensiver, speichersparender und geht auf die Performance. Dafür ist es viel flexibler,
    Außerdem arbeiten MM und ZMK mit Doubelbuffering, um z.B. Charanimationen zu machen.
    Deshalb braucht der C64 soviel Zeit. Ich kratze hier nur an der Oberfläche. Was alles abgeht, weiß Enthuis, der sich sehr detailliert mit der MM Engine auseinandergesetzt hat!
    Was meine Erwartung einfach dämpft, ist dass der Programmierer von INDY 3 hier scheinbar die Engine nicht weiter macht, sondern nur immer neue Orte einfügt, die mit der bestehenden funktionieren. Das macht Spaß, ist aber die falsche Methode. Oft machst Du als Programmierer einen Masterraum, in dem alle Effekte funktionieren. Und wenn das richtig läuft, dann baust auf dieser Basis alles weitere.
    Z.B. eine Engine ohne Doubelbuffering wird ihm die Gestaltung der Katakomben kaum ermöglichen. Doubelbuffering hat aber Auswirkungen auf die gesamte Strukur des Programms.
    Ich will das Projekt nicht mies reden, sondern wünsche ihm Glück. Ich habe Indy 3 geliebt. Aber ich möchte deutlich machen, warum ich das Projekt sehr skeptisch sehe.

    Naja, es sind weiterhin nur mehr oder weniger schlecht oder gut konvertierte Bilder, auf denen eine Figur rumläuft. Das ist technisch nicht so anspruchsvoll. So ist z.B. nichts von den Katakomben zu sehen. Das bedeutet deutlich mehr programmtechnischen Aufwand. Statt mehr Bilder zu konvertieren müsste die Engine verbessert werden. Von daher sind meine Erwartungen weiter niedrig.

    Roland
    Das sehe ich ganz genauso. Es gibt Ecken im Spiel, die nicht so einfach zu lösen sein werden, z.B. die Tunnel in Venedig oder das Schloß.
    Mich hauts nicht gerade von den Socken. Klar sind die Hintergründe nett gepixelt, aber für eine halbwegs gelungene Umsetzung bedarf es mehr als Bitmap-laden und ein paar Sprites drauf herumlaufen lassen, die im Größenverhältnis nicht mal mit der Hintergrundgrafik übereinstimmen. Die Vorfreude hält sich ein wenig in Grenzen.

    Schaut euch mal das Video an:
    Bitte melde dich an, um dieses Medienelement zu sehen.

    Was haltet ihr davon? Die Hintergründe scheinen Bitmap zu sein. Einige wurden wohl einfach umgewandelt von der Bitte melde dich an, um diesen Link zu sehen.. Das erklärt, warum die Figuren im Größenverhältnis nicht zu den Hintergründen passen. Kein Scrolling.