Mode X und EGA Parrallax

  • Charaktere umranden geht ja relativ schnell.

    Ich mache mal ein Set fertig damit.... eventuell mache ich die Umrandung mit einer der noch freien Farben.

    Dann kann ich die Farbe wechseln wenn man mit dem Char interagiert oder ihn markiert.


    ich hab dann mal einen Zaun gemacht... die Tage mal ein paar Hühner oder Schweine Pixeln.

    Damit hier mal was mehr rum läuft.

    Der 386 wird sich freuen wenn mehr herum läuft... ...nicht.

  • ein wenig neuer Code ...wohooo!!!


    aber nur im Textur Editor.

    Ich wollte ja testweise alle Sprite Texturen mit einer Kontur versehen... dauert von Hand doch was lang.


    Also Code Schnibbel gemacht welcher den Rand eines Sprites erkennen kann und dann drum herum die Kontur automatisch zeichnet... 1x >K< drücken und die Textur ist fertig!

  • wieder was die Hühner laufen lassen...


    konnte es nicht lassen.

    ein huhn was nicht mit dem schnabel am hacken ist, is kapott!!


    und wenn man einmal dabei ist... Charakter auf Huhn geändert und Animationen testen.


    das mit den Hühnern nimmt der 386 irgendwie persönlich, 5 auf einmal + spieler...huhn oder kein huhn und der macht noch 7FPS beim scrollen / 10 bei Stillstand.

    Da die Hühner relativ klein sind könnte ich die routinen zum restaurieren des frames hierzu noch anpassen.

  • Da die Hühner relativ klein sind könnte ich die routinen zum restaurieren des frames hierzu noch anpassen.

    Wie machst du es denn momentan? Es gibt auch Algorithmen um minimale Bounding Boxen zu berechnen. Es könnte z.B. Sinn ergeben, wenn man nicht jedes Huhn einzeln restauriert, sondern wenn die eh dicht beieinander stehen eine etwas größere Bounding Box sichert und wiederherstellt. Das hängt aber davon ab wie nah beieinander die Tiere stehen. Speziell wenn es sogar Überlapp zwischen den Sprites gibt kann das sogar Zeit sparen.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Ich erstelle momentan ziemlich viele Texturen, weil das halt irgendwo die Grundlage ist um die Map zu erstellen.


    Und dann mache ich testweise Map Bereiche fertig und teste wie sie sich verhalten.


    Die Hühner, laufen jetzt auf einem in der Map eingegrenzten Bereich herum.



    > Random Richtung wählen

    > laufen

    > Random oder bei Hinderniss >> laufen unterbrechen / warten oder Richtung wechseln


    ich kann die Tage nochmal ein Demo hoch laden mit Maps und Texturen zum anschauen und testen.

  • Nein ich meine wie frischst du ein Bild auf? Wird ALLES neu gezeichnet oder nur das, was sich verändert hat? Wenn ersteres kannst du noch sehr viel Performance heben.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Momentan werden die Bereiche wo NPC stehen komplett aufgefrischt... hängt damit zusammen das ich noch keine Funktionen habe die prüfen ob sich NPC / Effekte überlagern, sonst würden Teilbereiche nicht korrekt wiederhergestellt werden.


    Da kann ich natürlich Leistung einsparen, da hast du vollkommen recht.

    Die Funktionen werde ich jetzt auch mal Zeitnah angehen!

  • Okay, aber du frischst nicht den GANZEN Bildschirm auf, nur die Stelle des Sprites? Das ist ja schon mal sehr gut.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Nur die stellen wo Sprites sind werden "restauriert".


    Bei den Effekt Sprites welche kleiner 32x32 Pixel sein können wird auch nur dieser Bereich neu dargestellt.


    Bei den Charakteren ist es aber so das diese noch als fix 32x32Pixel restauriert werden. eventuell lohnt es beim zeichnen zu prüfen welcher Bereich das kleinste mögliche Quadrat ist welches restauriert werden müsste.

  • Das ist noch Mode X oder? Da gibts bestimmt einen trade off durch das Umschalten der Planes versus der Anzahl der Sprites und der Größe der bearbeiteten Fläche.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Wieder ein wenig mit den Hühnern gespielt.


    Ich habe einiges umgeschrieben was das wiederherstellen des hintergrunds betrifft und das Setzen von Sprites.


    Im 1. versuch werden nur Frames neu gezeichnet welche sich verändert hatten seit dem letzten Frame, der Hintergrund wird auch nur dann neu gezeichnet.

    Das einzige Problem derzeit, wenn ein anderer Frame überlagert wird der Sprite leider auch "beschädigt"... das ganze kann man mit viel Rechnerei umgehen.

    je nach Bewegungsdrang der Hühner 9-35FPS ...schwankt leider etwas extrem.


    1 Huhn hat Appe Ecke!


    Variante 2 ist die etwas aufwändigere Variante.

    Der Vordergrund wird immer neu gezeichnet, hintergrund wird nur ersetzt wenn davor sich was verändert hatte.

    vorteil überschriebenes wird neu gezeichnet bei jedem Frame... also weniger Grafik Fehler.

    Hühner alle ganz, es kommt jedoch immer noch zu überschneidungen, auch wenn diese beim nächsten Frame behoben werden flackert also teilweise... hier müsste noch einiges umgebaut werden.

    FPS sind relativ konstant zwischen 11 - Maximal 15 FPS am schwanken im Testbereich.


    Leider kommt es im zusammenhang mit Mode-X und Scrolling zu einem weiteren Problem.

    Wenn der Speicherbereich gewechselt wird, wird ein Frame kopiert ...leider hat das den Effekt das somit ab und an der Frame Positions speicher der einzelnen Sprites innerhalb eines Frames nicht mehr stimmt und dann frames nicht korrekt gelöscht werden auf dem Bildschirm. Es können 4Pixel breite Fragmente von Sprites entstehen.


    Da der Aufbau mitlerweile ziemlich komplex ist, ist es etwas Zeitaufwändiger das ganze komplett ohne Fehler um zu bauen.

    Leider Steigert sich hierdurch auch der Rechenaufwand am onehin Rechenlastigsten Punkt nochmal.


    Unter dem alten Zeichen Modell arbeitet das Programm ungefähr mit



    Das alte Prinzip war komplett anders.

    Alles was sich bewegen könnte wird gezeichnet und es wird in einem Puffer hinterlegt wo was gezeichnet wurde.

    Beim Framewechsel wird der Hintergrund sofort wieder hergestellt und erst danach wird alles neu drüber gezeichnet.

    Vorteil, es gibt keine löschenden überschneidungen und es muss nicht viel geprüft werden.

    Mit diesem verfahren schwankte es kaum, aber mit ca. 11FPS war es auch nicht gerade schnell.

  • Ich hoffe du hast inzwischen ein Whiteboard oder ein Poster mit den wichtigsten Details deiner Algorithmen und Kopien aller Softwareversionen oder sogar eine Versionsverwaltung? Das Projekt ist inzwischen sehr umfangreich und komplex geworden :)


    PS: Wenn du mit weniger Entscheidungen und statt dessen optimiertem Neuzeichnen auch 11 FPS erreichst, kannst du der Lesbarkeit des Codes wegen gerne zunächst dabei bleiben und die anderen Optimierungs-Experimente archivieren, bis sich eine revolutionärere Idee findet, die ein besseres Verhältnis von Code-Aufwand zu FPS-Gewinn bietet. Durchaus ein spannendes Thema!

  • Ich habe ein paar grundlegende Dinge geändert heute im Code.


    Momentan können maximal 10NPC auf einer Map von 16x16 Kacheln verteilt werden. Im Spiel sind immer 4 dieser Maps im speicher geladen, das sind die 4 die dem aktuellen Bildschirmbereich am nächsten sind.

    Also 40 insgesamt sind immer geladen maximal!


    Der Spieler selber wurde komplett anders behandelt, er hatte separate Variable für seine Werte und Informationen und nutzte kaum gemeinsame Funktionen mit den "Restlichen".

    Ich habe heute alle Spieler Variablen entfernt und alles so umgeschrieben das der Spieler selber der 41. im Array der NPC ist.


    Somit konnte ich jede Menge Funktionen entfernen.


    Die Tasteneingaben ändern lediglich die Werte im NPC Speicher von NPC 41, was der Spieler ist.

    Wenn ich lust und laune habe kann ich einfach sagen ich Steuer jetzt NPC Nr.20 oder ich setze die Kamera welche immer dem Spieler folgt auf einen anderen NPC ...oder ich spiele einfach kurz einen anderen NPC.


    Es gibt 2 Kamera Modie. 1x Spieler immer in der Mitte und 1x Kamera schwenkt erst am Rand immer dem Spieler hinterher.



    Neuzeichnen muss ich auch noch anpassen, es werden zu viele Pixel neu gezeichner welche garnicht von einem Sprite benötigt werden.

    NPC die klein sind muss ich auch noch anders im speicher verwalten... hier werden unnötig 32x32 Pixel restauriert, während bei effekten schon nur minimalistisch restauriert wird.


    Whiteboard? ...ich schreibe wchtiges immer im Code hinter den Zeilen.


    Einzelne Bereiche sind ausgelagert in einzelnen Dateien, welche von mehreren Programmen verwendet werden.

    z.B.


    -XMS Speicher Verwaltung

    -Texturen laden / kopieren zwischen XMS und Datenträger...

    -Grafik Mode-X Funktionen >> Zeichnen / Text "Xprint" / Xrect / Xpset / latch copy Grafik Funktionen

    -Maus

    -Paletten für Farben / aufhellen abdunkeln ..

    -Mode-X Zeichensatz


    Es gibt über 100 gespeicherte Zwischenschritte seit den ersten experimenten mit Isometrischer Grafik und Mode-X mit Kachelweisem Scrollen etc... es braucht ja im grunde keinen speicher.

  • Spieler wie andere Sprites und NPC behandeln ist eine gute Idee und bietet spannende Möglichkeiten für flexible Abwechslung :) Bei Jill of the Jungle konnte man sich z.B. auch an bestimmten Stellen in andere Figuren verwandeln und bei anderen Spielen konnte man verschiedene Mitglieder eines kleinen Teams spielen. Oder der Spieler könnte absichtlich oder unabsichtlich mit einem NPC die Rollen tauschen durch Zauberei in deinem Spiel etc. :)


    Whiteboard war eher so gemeint, den gesamten Überblick über die Struktur auf einer Wand zu haben, ohne im Code herumblättern zu müssen, auch wenn der gut kommentiert ist. Big Picture, wörtlich genommen.

  • Im vergleich zu "neuen" Programmen ist der Code eigentlich ziemlich einfach gestrickt, die Schwierigkeit liegt eher darin mit so wenig wie möglich Rechenaufwand so viel wie möglich zu erreichen.


    wenn man Leerzeilen und Text abzieht besteht die Haupt Schleife aus 170 Zeilen, folgendes wird dort bearbeitet.





    -Interval Counter >> wenn abgelaufen >> Tasten abfragen + Palette Effekt aufrufen ...ansonsten alles andere abarbeiten und spezielle Eingaben ignorieren.

    -Sprites im Hintergrund Frame entfernen

    -sonstige Tastatur abfragen >> Menüs / FPS Anzeige / Tag Nacht umschalten / Spieler Interaktionen etc...

    -Spieler Bewegungen berechnen

    -Kamera Position berechnen

    -NPC / Effekte berechnen

    -Speicher Position des nächsten Frames errechnen ggf. Position im Speicher anpassen (Mode-X Scrollen ...etwas komplex, aber sehr sehr schnell)

    -Wenn nächste Frame außerhalb des gültigkeiten Bereichs liegt, wird ein neuer gültiger festgelegt und dort hin ein Frame kopiert mit Hilfe von "Mode-X latch copy". Das ganze ist alle 204 Pixel bei vertikalem Scrollen notwendig!

    -Sprites neu zeichnen >> Spieler, NPC (maximal 41) / Effekte (maximal 100)

    -Ränder nachzeichnen im Hintergrund

    -FPS zeigen / berechnen (falls Aktiviert)

    -FRAMEWECHSEL!!!

    -Ränder im neuen Hintergrund Frame nachzeichnen

  • Da Sprites anzeigen 1x pro Pixel gemacht werden muss, aber Sprites auswählen und positionieren nur 1x pro Sprite, wäre es von der Rechenzeit trotzdem akzeptabel, wenn die Hauptschleife z.B. für jeden Sprite einmal pro Frame eine getrennt implementierte Funktion aufruft, die das "Gehirn" der NPC darstellt etc. Auch da wären wieder lustige Sachen möglich, z.B. Hühnern und menschlichen Hintergrundfiguren den gleichen Charakter zu geben (also die gleiche Hirnfunktion aufrufen) wo es für die Aufgabe der Figur ausreicht ;)

  • ...momentan sind die Hühner genau so schlau wie die anderen NPC.


    es gibt im Grunde 2 Bewegungs-Modelle.


    1.

    NPC läuft relativ Random durch die Gegend.

    Man kann den Bereich durchsichtig umzäunen im Map Editor, damit die Hühner nicht irgendwann zu weit weg laufen!


    2.

    Feste Laufwege!

    Man erstellt auf der Map einen Laufbereich, der NPC läuft so lange in einer Richtung auf diesem Weg bis er am Ende angekommen ist, dann wird geprüft in welche andere Richtung es weiter geht. Wenn keine andere Richtung verfügbar ist, läuft er wieder zurück wo er her gekommen ist.



    Zusatz Option.


    NPC Golgen Modus!

    NPC's die dieses Merkmal gesetzt haben folgen dem Spieler wenn er sich dem NPC nähert, solange bis der Spieler wieder außer Range läuft.

    Oder man setzt sie an einer Ecke fest, Mauern umgehen können NPC's noch nicht "intelligent".

    Eventuell schreibe ich hierzu mal Routinen, es gibt im Netzt ein paar Beispiele wie man sowas berechnet.


    "Routen" NPC's finden auch nicht wieder zurück zu ihrer Route, die bleiben dann einfach stehen wo man sie abgehangen hatte, solange bis die Map neu geladen wird.


    Oder man drückt "R" Reset im Testspiel.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!