Ok, Du lachst. Möchtest Du ausführen wieso? Das was ich bislang von dem Spiel sah lässt sich problemfrei in Charsets implementieren. Und man hat dann immer noch die Sprites zur Verfügung um was zu polishen.
Also, bitte: Erläutere mir die unglaubliche Komplexität der Grafik von TT64.
trapthem64.de eröffnet
-
Vernunftmensch -
10. Juli 2015 um 00:30 -
Erledigt
Es gibt 71 Antworten in diesem Thema, welches 12.945 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Gut, also ´mal zur Abwechslung sachlich.
Es gibt zwei Grafikmodi, einen kleinen und einen großen. Im Kleinen läuft ECM nach Retrofan und im Großen läuft Multicolor, um ECM möglichst nahe zu kommen.
Damit ausgeschnittene kontinuierlich Pixel für Pixel fallen und dabei auch knapp untereinander fallen können bedarf es sehr vieler Softwaresprites, die dazu ständig aktualisiert werden. Um selbiges im Großen zu machen, fehlt allerdings CPU-Power.
Da man die Roboter verfolgen möchte, sind die beweglichen auf Sprites umgebaut. In einer Diskreten Version zuvor waren es wirklich reine Softwaresprites die von diskreten Zeitpunkt zu Zeitpunkt genau ein Feld sprangen. Bei den Sprites ist die Bewegung pixelweise mit der Zeit.
Da der C64er mit größeren Steinböcken Probleme hat, haben größere Steinblöcke die Eigenschaft, daß sie nach der Berechnung genau an der richtigen Stelle pixelgenau runtergesetzt werden. Dazu habe ich ein Minibetriebssystem großspurig gesagt mir ausgedacht mit Vorder- und Hintergrundprozessen.
Nach dem Fallen eines größeren Steinbocks wackelt der Bildschirm sinusartig. Je größer der Stein, um so mehr.
Und noch vieles mehr.... ...das ist alleine die Grafik........
Also ich finde, daß ich meine Sache gut mache und den richtigen Weg einschlage mit Gottes Hilfe.

-
Die Programmeirsprache sollte in der Regel nachrangig sein - entweder man kann aufkommende Probleme / Fragestellungen lösen oder eben man kann es nicht.
Das ABER folgt auf dem Fuße:
Auf dem C64, der (wie Du selbst ja schon festgestellt hast) einiges an Hardware-Limitierungen hat, ist es widersinnig ein Projekt dieser Größenordnung in C anzugehen und zu glauben der Compiler könne es 1:1 in den Rechner reinschieben.Ich hab den Source mal gesehen; jedenfalls eine ältere Version davon. Hier ist wirklich nicht C das Problem, sondern schlicht und einfach ein extremer Mangel an Programmiererfahrung. Wenn diese durch überbordenden Enthusiasmus und gesteigertes Durchhaltevermögen kompensiert werden soll, kommen halt solche Monsterprogramme dabei heraus.
-
- Offizieller Beitrag
Ich habe gerade den Beitrag 21:27 von Vernunftmensch freigeschaltet...
und klar ist, dass man Erfahrung nur mit Durchhaltevermögen erlangen kann. Und Erfahrungen in C werden vernuftig auf anderne Platformen sicher mehr nutzen als 8bit Assembler....

sl FXXs
-
Also ich finde, daß ich meine Sache gut mache und den richtigen Weg einschlage mit Gottes Hilfe.

-
Es gibt zwei Grafikmodi, einen kleinen und einen großen. Im Kleinen läuft ECM nach Retrofan und im Großen läuft Multicolor, um ECM möglichst nahe zu kommen.
Aha, ich hab bisher nur den "kleinen" Modus zu sehen bekommen. In welchem/n Level(s) läuft denn der grosse? -
Sprites um die Blöcke fallen zu lassen?
Wie wäre es mit 4 Animationsschritten für die Sandblöcke, das gäbe auch eine weiche Bewegung und würde maximal 16 Chars benötigen.
Auch bei den Robotern denke ich dass es mit einer Handvoll Animationsschritten getan wäre. Da alles was ich bislang von dem Spiel sah mit maximal 4 oder 5 Texturen auskommt sollte da reichlich Platz für diese Animationsschritte im Charset sein. -
Zitat
Ich hab den Source mal gesehen; jedenfalls eine ältere Version davon. Hier ist wirklich nicht C das Problem, sondern schlicht und einfach ein extremer Mangel an Programmiererfahrung. Wenn diese durch überbordenden Enthusiasmus und gesteigertes Durchhaltevermögen kompensiert werden soll, kommen halt solche Monsterprogramme dabei heraus.
Das ist wirklich lange her. Damals war ich gerade mit der Diskreten Version fertig, bei der die Engine weitgehend in C geschrieben, kann das sein?
Mitlerweile programmiere ich lieber gleich in ASM.:) Ich schicke Dir ´mal eine neue Version.....
-
Softwaresprites, damit meine ich Chars. Ja, die werden immer relativ CPUeinfach bei mir bereitgestellt. Sicherlich könnte man das auch anders lösen, aber besser?
-
BladeRunner Deine Idee mit den Steinfallcharts erzwingt einen Charwechsel bei jeden Frame, das ist nicht "gut".
-
Ich hab den Source mal gesehen
Ich hab mir bloß den Assembler-Code eben mal angeschaut. Extrem undurchschaubar
. Ist das normal??Ich hab mir allerdings vorher noch nie aus C kompilierten Code angeguckt. Das kommt aber schon alles ziemlich skurril rüber.
Und sind das wirklich 36K an Code, die da werkeln? Krass.
VM: Wie schon mal geschrieben, mag ich das Spiel. Letztenendes kann es mir/uns egal sein, wie es geschrieben ist, wenn es ordentlich läuft.
Ein großer Fortschritt wäre schon mal, wenn "Leaving Cave" nicht jedesmal neu geladen werden würde.
Und noch eine Frage: Warum ist die Nachladerei so langsam? Oder passiert da schon was im Hintergrund??
-
BladeRunner Deine Idee mit den Steinfallcharts erzwingt einen Charwechsel bei jeden Frame, das ist nicht "gut".
Da es ja selten mehr als ein paar Dutzend Steine betreffen sollte sehe ich da kein Problem. Wenn die Karte ein passendes Flag-Bit erhält (Dieser Stein Fällt gerade) ist der Update-Aufwand gering. Noch besser ist ein Array mit den abzuarbeitenden Frames.
Alles rein spekulativ, zugegeben, aber machbar sollte es sein. -
Also ich finde, daß ich meine Sache gut mache und den richtigen Weg einschlage mit Gottes Hilfe.

Genau
aber überdenke auch die Hinweise von MacB,Cold,Bladerunner usw.
Haben ne Menge Ahnung/Erfahrung die Jungs.
-
aber überdenke auch die Hinweise von MacB,Cold,Bladerunner usw.
Er sagte bereits "mit Gottes Hilfe". AKA "die schickt der Himmel".
Gerade MacB wurde durch höhere Kräfte dazu geleitet seine Freizeit aufzuwenden um den einen oder anderen Bug zu melden.
Und damit öffnet sich der Weg aus dem Tal. -
Erfahrungen in C werden vernuftig auf anderne Platformen sicher mehr nutzen als 8bit Assembler...
Ketzer!
BTT: Wo bleibt das nächste Test-Image ohne I/O gewusel, mit skipbarem Speech Digi Part und halbwegs vernünftigen (zumindest in der Menuführung eindeutigen) Controls?
PS: Was Bladerunner sagte! = Was viele seit Jahren sagten, aber WIE du das nun bugfree kriegst, ob mit Inlinern oder Skateboard oder doch lieber zu Fuß per real ASM, ist am Ende ladde

-
Ich führe gerade einige Tests durch und habe aufgrund einiger Probleme auch TT64 dazu genommen.
Also auf meinem 250469 Board kann ich TT64 starten. Auch das Menü funktioniert mit Joystick.
Ich komme bis zum Ladescreen (siehe Bild).Bitte melde dich an, um diesen Anhang zu sehen.
Der blaue Ladebalken läuft sauber bis zum Ende durch, wechselt danach ins schwarz und läuft Zeichen für Zeichen weiter.
Gestartet über TC64.
-
@oob: Siehe mein Beitrag Bitte melde dich an, um diesen Link zu sehen.: Falsche Diskseite gestartet
! -
@oob: Siehe mein Beitrag Bitte melde dich an, um diesen Link zu sehen.: Falsche Diskseite gestartet
!

-
Boa Einmal mit Profis


-
Ich kenne allerdings sonst auch keine Programme, wo das funktioniert. Da ist TT schon etwas 'besonders'...

-