Ich finde das schon ziemlich gut und beeindruckend.
Natürlich sieht das laufende Männchen nicht besonders smart animiert aus, aber insgesamt ein stimmiges Gesamtbild.
Da kann ich nicht verstehen, was es auszusetzen und zu maulen gibt.
Soweit ich weiß hat sich vor ihm noch keiner an ein derartige Konvertierung begeben.
Warten wir mal ab, was da noch kommt.
Grüße
Jive
Indy III für C64 - FAKE?
-
domspitze -
14. Oktober 2013 um 09:11 -
Erledigt
Es gibt 64 Antworten in diesem Thema, welches 21.787 mal aufgerufen wurde. Der letzte Beitrag (
-
-
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.
Nun, wenn es technisch so anspruchslos ist, warum gab denn dann jahrzentelang keinerlei Umsetzung? Es sieht verdammt gut aus, fast besser als das Original und so ist es mir vollkommen Wurst, mit was für einer Technik es umgesetzt wird. -
Nun, wenn es technisch so anspruchslos ist, warum gab denn dann jahrzentelang keinerlei Umsetzung?
Äh, hat er doch geschrieben.
Konvertierte Bilder sind eine Sache (und zwar die besagte anspruchlose).
Eine gute Game-Engine dazu ist eine komplett andere Sache. -
Also ich bin positiv überrascht, dass es bis dahin so gut aussieht. Es fehlt (wie man bei 4:30 deutlich sieht) die Skalierung des Hauptdarsteller-Sprites, aber sonst macht es auf mich einen guten Eindruck. Hut ab, Peitsche raus, hoffentlich wird ein komplettes Spiel draus!
-
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.
Da werden doch auch fast nur ein oder zwei (und lass es mehr sein, je nach dem) Sprites auf einem Bild bewegt und viel mehr ist nicht zu tun.
Ich denke vor allem dort bei den Originalen hätte man 500% Optimierungspotential in der Engine gehabt.Das hat man wahrscheinlich die (lahme, zu viel auf einmal denkende obwohl prinzipiell nicht nötig in jeder Sek. ;)) Engine mehr oder minder 1:1 für jedes System gleich gehalten und sich zudem einen S.. um Optimierungen auf die konvertierte Ziel-Hardware gekümmert.
-
Kann das Video nicht anschauen, da es ja für dieses Forum kein HTML5-Video-Plugin gibt.

Das Problem habe ich am Smartphone auch. Es müsste alternativ noch eine Link zum anklicken geben. -
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. -
- Offizieller Beitrag
Das Problem habe ich am Smartphone auch. Es müsste alternativ noch eine Link zum anklicken geben.
man könnte auch einfach den Link zweimal posten: einmal mit youtube Tag und einmal ohne...sl FXXS
-
Alle Jahre wieder ein Preview.
Bitte melde dich an, um diesen Link zu sehen.
Wer ist dieser Mensch, der da so still und heimlich an einer Umsetzung arbeitet oder sich soviel Mühe mit Fake- Videos gibt? -
- Offizieller Beitrag
Für ein "Fake" hat es aber schon sehr viel Content drin, der sogar gut aussieht und das eine oder andere Rätsel ist ja schon drin.
Nur das Indy-Sprite könnte man noch verbessern, wenn ich das mit Caren & co vergleiche. -
Ich denke nicht, dass es ein Fake ist.
Da programmiert aber vermutlich jemand die verschiedenen Ort einzeln mit konvertierter und nachbearbeiteter Grafik.
Im Ergebnis kann das durchaus nett werden. Eine fertige Engine zu programmieren ist sicherlich mehr Aufwand, aber dann 'nach hinten raus' natuerlich sinnvoller.
Die vermutete Herangehensweise wuerde auch die Laenge des Projektes und den Bedarf an haeufigerem Nachladen erklaeren.
Ich finde es bloss ein wenig schade, dass soviel Zeit in ein Spiel gesteckt wird, das es schon gibt. -
- Offizieller Beitrag
Ich finde es bloss ein wenig schade, dass soviel Zeit in ein Spiel gesteckt wird, das es schon gibt.
Wieso? Zum Lernen des "Handwerks" ist so eine Herangehensweise mal nicht schlecht für den Anfang.
So muss man sich nicht die Story und Rätsel, Mechaniken auch ausdenken.
Und für den C64 gibt es IFAIK Indy ja nicht. -
- Offizieller Beitrag
Also ich finde, dass es soweit schon richtig gut aussieht.
Wenn das Game soweit fertig ist, kann er ja noch den Feinschliff angehen.Und dass es das Spiel für andere Rechner schon gibt, ist für mich auch nicht schlimm. Indy III habe ich zwar mal auf dem Amiga angespielt, aber nicht bis zum Ende gespielt.
Wieder ein Grund weniger, den Amiga anzuwerfen
-
schade, dass soviel Zeit in ein Spiel gesteckt wird, das es schon gibt
Also da gibt es andere, echte Energie/Talentverschwendung, worüber man sich aufregen könnte (SEUCK z.B. hehehe).
Amiga hatte ich nie und will ich auch nie mit anfangen, am PC ist das damals auch an mir vorbeigegangen, und ich würde das definitiv lieber am C64 spielen als in der DOSBOX oder so.
-
- Offizieller Beitrag
Ich bin mal gespannt, ob er es je veröffentlichen wird.
Im Internet ist darüber leider nicht soviel zu finden und bisher hat er in youTube auch keine Kommentare zu Downloads, usw. gepostet...
-
Ist auf alle Fälle ein sehr spannendes Projekt.
Wäre jedenfalls interessant nochmal zu sehen, wie alte Klassiker auf C64 aussehen würden, die damals nicht mehr auf C64 erschienen sind, wie bspw. auch Monkey Island 1+2, wobei in Monkey Island 2 die Grafikqualität wahrscheinlich nicht einmal mehr annähernd mehr erreicht werden kann.
Aber das Indy3-Projekt zeigt ja auf beeindruckende Weise, was aus dieser Möhre noch rauszuholen ist.

-
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.
-
Bitte melde dich an, um diesen Link zu sehen. Da könnte sicher noch einiges gehen, wenn man die neuen Standards nutzt. Ladezeiten sind als Easyflash- Image kein Problem (siehe Prince of Persia) und als Nuvie wären doch sogar Intro-, Zwischen- und Endsequenzen möglich.
Ich finde es schon mal gut, das hier jemand einen anderen, wenn auch verschwenderischeren Weg geht. Aber das kann die Grafik auf ein höheres Niveau heben. Aus Charsets sieht es trotz allem immer so zusammengestückelt aus.
-
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.
Ich finde heutzutage sollte man da andere Masstäbe ansetzen.
Zumindest ich tue das. In Zeiten von SDFloppyemulationen ist es OK Siele mit vielen Disksund Ladevorgängen zu entwickeln.
Zumindest wäre das für mich jetzt keine Mienuspunk, wenn das Siel ansonsten toll ist. -
Das sieht wirklich sehr vielversprechend aus, bin gespannt ob das auch irgendwann mal fertig sein wird bzw. veröffentlicht wird.
-