Hallo Besucher, der Thread wurde 17k mal aufgerufen und enthält 36 Antworten

letzter Beitrag von Markie am

1. Frage: Highscoreanzeige realisieren

    Hallo Leute,


    ProjectX, dahinter verbergen sich Mac of Tugcs, Goldbug und ich (ThomBraxton). Wir wollen uns intensiver in die Programmierung in Assembler einarbeiten. Bei unseren gemeinsamen Treffen haben wir gemerkt, dass uns die wenigen Assemblerbefehle, die wir kennen, nicht wirklich und vor allem schnell genug weiter bringen. Wir haben das Gefühl, dass wir annähernd auf der Stelle treten!


    Gestern hatten wir per Assembler ein Sprite generiert und dieses auch per Pfeiltasten steuern können. (Toll!)
    Das war schon mal ein großer Fortschritt für uns! Danach wurde eine "Schussfunktion" als Sprite eingebaut, die anfangs so schnell war, dass man sie gar nicht sehen konnte. Also musste eine Verzögerungsschleife her, damit der Schuss langsamer und für unser Auge sichtbar wurde. Toll, lief! Doch bei einem Shooter sollte man seine Spielfigur nach Abfeuern einer Waffe ja weiter bewegen können, damit sie Angreifern ausweichen kann und BÄMMM! Da war es dann wieder! Das massive Brett vor dem Kopf!


    Wie kann man es erreichen, dass die Figur, während die Kugel aus der Pistole oder der Laserstrahl aus der Strahlenwaffe sich Richtung Horizont oder oberen Bildschirmrand bewegt, weiterhin selbst bewegen kann? (Grübel!) Das Programm muss also modularer aufgebaut werden! Doch wann kommt was und wie? (Hmmmm...)


    So fingen wir dann an, gezielt Brainstorming zu betreiben, um zu ermitteln, was wir von Euch PROFIS wissen möchten - und das ist nicht wenig! -, damit wir das Rad nicht mehrfach neu erfinden müssen. Der Doc hat uns zuliebe einen Unterordner für unsere gezielten Fragen angelegt! Nochmals vielen lieben Dank dafür!


    Und jetzt wollen wir mit unseren Fragen langsam einsteigen und hoffen, von Euch ganz viele Hinweise und Tipps bzw. Codebeispiele zum Einarbeiten zu erhalten, damit wir das dicke Brett vor unserem Kopf langsam entfernen können.


    Auf der letzten Bunkerparty hat mir Mac Bacon erklärt, wie man einen Highscore in Assembler realisieren kann, ohne Konvertierung von 16- oder 32-Bit in Dezimal zur Anzeige auf dem Monitor. Liegt wohl an meinem Alter, dass ich das nicht mehr so ganz zusammen bekomme, deshalb hier unsere erste Frage:



    1. Wie kann man in einem Assemblerprogramm einen Highscore-Zähler realisieren?


    Ich Danke Euch schon im Voraus!


    Liebe Grüße!
    ThomBraxton

    Eine Möglichkeit, die mir spontan so einfällt, wäre, die BCD-Codierung zu nehmen. Das sähe dann so aus:

    Code
    1. SED ; setze den BCD-Modus
    2. CLC ; Carry vor Addition löschen
    3. LDA score; unterste Scorebyte (Zehner und Einer)
    4. ADC #5 ; 5 Punkte dazuaddieren
    5. STA score
    6. LDA score + 1 ; oberes Scorebyte (Tausender und Hunderter)
    7. ADC #0
    8. STA score + 1
    9. CLD ; umschalten auf normalen binären Modus


    Um jetzt die einzelnen Ziffern zu erhalten, muß man nur noch die Nibble extrahieren:


    Das wäre so das Grundprinzip.

    Die Begrifflichkeit verwirrt mich- wollt ihr eine Punkteanzeige oder eine Liste mit High Scores?
    Im ersten Fall ist es idR am einfachsten den Bereich der den Score am Screen darstellt mit den Bidschirmcodes für "0" ($30) zu füllen und dann je nach vergebenen Punkten die passenden Stellen auf dem Bildschirm zu inkementieren. Wenn das Ergebnis keine Ziffer mehr ist (CMP), wird um 10 dekrementiert und die Ziffer links daneben um 1 erhöht usf.
    Spart einem komplexe Umrechnerei in Screencodes und noch dazu ein wenig Speicher, da der Bildschirm ja eh genutzt wird.

    Die einfachste Methode wär wohl n Array aus Ziffern für Score und zu addierende Punkte herzunehmen:


    Zur Ausgabe muss dann nur noch der Petscii- bzw. Screencodeoffset der Ziffer "0" zu jedem Digit addiert werden (beim Romzeichensatz reicht da ein ora #$30).

    Wenn ich den Eingangspost so lese, wäre mein Tipp aber eher: ihr solltet Euch erstmal mit der Funktionsweise von (Raster-) IRQ beschäftigen. Bei "Verzögerungsschleife" in Assembler rollen sich mir die Fußnägel hoch... ;)
    ... nicht, dass ich nicht anfangs auch sowas verzapft hätte :whistling:

    O.K., Silbertablett.


    Zunächst mal sollte die Fragestellung in vier Punkte unterteilt werden:


    1. Wie wird der Punktestand im Speicher abgelegt?
    2. Wie zähle ich neue Punkte zu einem bestehenden Punktestand hinzu?
    3. Wie stelle ich diesen Punktestand auf dem Bildschirm dar?
    4. Wie passe ich den Stand des Highscores gegebenfalls an? (Darstellung ergibt sich dann aus Frage/Lösung 3)


    zu 1.: Klassischerweise hat so eine Punkteanzeige 6 Stellen, mit führenden Nullen. Es werden zur Einfachheit 6 Bytes im Speicher abgelegt, in der Reihenfolge Hunderttausender, Zehntausender, Tausender, Hunderter, Zehner, Einer. Für den späteren Gebrauch ist nicht nur die laufende Punkteanzeige von Belang, benötigt werden weitere 6 Bytes, welche bei einem "Treffer" zum bisherigen Score addiert werden soll, sowie weitere 6 Bytes in denen der Highscore drinnen steht.


    In den 6 Bytes stehen die Werte 0-9 (also *nicht* PETSCII 48..57).


    Initialisiert wird das ganze mit:

    Code
    1. .init
    2. LDX #$06
    3. LDA #$00
    4. .init_00
    5. STA score-1,X
    6. STA add-1,X
    7. STA high-1,X
    8. DEX
    9. BNE init_00
    10. [...]

    Abweichend dazu kann evtl. im Highscore bereits ein größerer Wert, etwa "0","1","0","0","0","0" vorgegeben werden.


    zu 2.: Grundschulwissen. Man fängt mit dem hintersten Byte an, addiert den "Treffer" in add dazu und berücksichtigt den Übertrag. Dieser tritt immer dann auf, wenn die Stelle größer als 9 wird, und dann muß man 10 abziehen, bevor man speichert:


    zu 3.: Üblicherweise stehen die Ziffern im Bildschirmcode ab 48 ($30). Sie könnten aber auch woanders stehen, dann ist die Routine entsprechend anzupassen. Der Score wird also im den Bildschirm übertragen:

    Code
    1. .display
    2. LDX #$06
    3. CLC
    4. .display_00
    5. LDA score-1,X
    6. ADC #$30 ; für gewöhnlich gibt es hier keinen Übertrag, darum bleibt C=0(!)
    7. STA screen-1,X
    8. DEX
    9. BNE display_00
    10. [...]


    abschließend zu 4.: der Highscore soll immer dann angepaßt werden, wenn er kleiner als der Score ist. Entgegen der vorheriger Routinen fängt diese hier mit dem niedrigsten Byte, also der höchstwertigen Stelle an:


    Die Anzeige vom Highscore erfolgt dann mit einer Variante der Routine in 3.

    Hier noch meine Version (aber noch ohne Highscore):


    Start 4096 / Tasten "0"-"9" .

    Das o.g. Highscore-Saver Kit dient dazu die bereits im Speicher befindliche Rekordtabelle bei Spielstart zu laden und dann bei jedem neuen Rekord wieder abzuspeichern.


    BladeRunner hat die wahrscheinlich simpelste aber durchaus wirkungsvolle Methode schon geannt. Mit ihr sind dann bspw. auch 100'er oder 1.000'er Bonuspunkte möglich, in dem man einfach an der Stelle in die Routine reinspringt, wo eben die gewünschte Stelle inkrementiert werden soll.


    Wie Spider-J schon absolut richtig gesagt hatte, ist bei einem Spiel der (Raster-)IRQ von entscheidender Bedeutung. Verabschiedet euch vom evtl. gewohnten "Hauptschleifendenken" aus BASIC!


    Im Spiel ist der typische Aufbau normalerweise eine kleine Hauptschleife, die z.B. nur eine etwaige Tastatureinagbe auswertert (PAUSE/QUIT...) und sagen wir mal eine Art GAME OVER- oder NEXT LEVEL Flag abfragt.


    Joystick-/Tastaturabfrage, Sprites und Schüsse bewegen, Soundeffekte abspielen usw. ist alles was für den IRQ, der in Spielen nicht selten sehr viele Aufgaben erledigen muss. Also normalerweise genau anders rum wie bei einer Anwendung (BASIC Tool o.ä.).


    Mein Tipp: Plant von vornherein einen Rastzeilen-IRQ ein, erstens sind etwaige Bewegungen dann sehr geschmeidig und ruckelfrei, aber noch viel wichtiger - ihr habt die Grundlage für eine 100% funktionierende Kollisionsabfrage geschaffen. Lest euch bei Interesse die Anleitung zu folg. Kit durch und schaut euch die Beispiele an. Der CeVi liefert hervorragend alle Voraussetzungen für ein technisch professionelles Spiel, eure Aufgabe ist nun die Rezeptur für diese Zutaten. Mit dem Kit hättet ihr schon mal so eine Art Gerüst, dass ihr nach erfolgreichem Test erweitern und anpassen könnt. Viel Erfolg! ;)


    http://csdb.dk/release/?id=134517

    Zitat von DATA-LAND

    Im Spiel ist der typische Aufbau normalerweise eine kleine Hauptschleife, die z.B. nur eine etwaige Tastatureinagbe auswertert (PAUSE/QUIT...) und sagen wir mal eine Art GAME OVER- oder NEXT LEVEL Flag abfragt.


    Joystick-/Tastaturabfrage, Sprites und Schüsse bewegen, Soundeffekte abspielen usw. ist alles was für den IRQ, der in Spielen nicht selten sehr viele Aufgaben erledigen muss. Also normalerweise genau anders rum wie bei einer Anwendung (BASIC Tool o.ä.).


    <nervige_klugscheisserei_tut_mir_leid>
    Das muß nicht so sein. Beispiel Uridium Plus:

    </nervige_klugscheisserei_tut_mir_leid>

    @M.J.: Naja, wenn die Hauptschleife auf eine Rasterzeile oder den (Raster-)IRQ wartet um dann aktiv zu werden, kann es der IRQ ja gleich selber machen. Aber klar - machbar wär's. Der CeVi ist da sehr flexibel. ;)


    Aber nochmal kurz zum Verständnis oder geistigen Vorstellung der Arbeitsteilung:


    Wir haben in der von mir erwähnten Methode


    - eine Hauptschleife (fürs Grobe), oft im Warte-/Bereitschaftsmodus
    - den Interrupt als Arbeitstier für akurates Timing.


    Wenn es ein Raster-IRQ ist, lässt sich durch Ändern der Rahmenfarbe auch zuverlässig erkennen, wie lange die einzelnen Abschnitte sind und ob der IRQ schnell genug für einen Frame ist.


    Diese Arbeitsteilung in zeitlich nicht relevant und relevant vermischt sich in der von dir zitierten Methode irgendwie.

    @DATA-LAND
    Das kann man sicherlich so machen, keine Frage. Der Grund, warum sich einige Programmierer dann doch dagegen entschieden haben, liegt wohl darin, daß die IRQ-Routine dadurch sehr aufgebläht wird. Als Folge davon wird der Code schnell unübersichtlich, und man benötigt eine Unmenge von Flags, die die diversen Zustände des Spiels widerspiegeln. So besteht das Beispiel "Uridium" aus folgenden Zuständen:
    - Titelanzeige
    - Scrollende Highscoreanzeige
    - Feste Highscoreanzeige
    - Levelangabe
    - Start des Raumschiffs
    - Spielergesteuertes Raumschiff
    - Spieldemo
    - Pause
    - Landung
    - Wechsel zur Bonusrunde
    - Bonusrunde
    - Levelende (Zerstörung des feindlichen Raumschiffs)
    - Explosion des eigenen Raumschiffs
    - Game Over
    - Namenseintragung in die Highscoreliste
    Das sind (mindestens) 15 verschiedene Zustände mit jeweils anderer Anzeige (mit/ohne Scrollen, Hires/Multicolour) und teils völlig verschiedenen Routinen. Daraus einen einzigen Interrupt zu stricken, ergäbe ein ziemliches Chaos:


    So in etwa. Das ist nur eine schnell skizzierte Kurzversion. Das echte Spiel bräuchte wohl eine sehr lange Liste dieser andauernden Flag-Abfragen, wobei die Lesbarkeit und Wartbarkeit mit jedem neuen Flag weiter verringert wird. Dummerweise gibt es nämlich auch häufig noch viele Abhängigkeiten zwischen den Flags: Ist ein Flag gesetzt, muß man das andere nicht mehr abfragen. Oder doch? Oder wie?
    Also wird man dahin gehen, verschiedene IRQs zu verwenden je nach Anzeigetyp, also alles, was scrollt, in einen IRQ und der Rest in den anderen IRQ. Doch auch dann muß man wieder viele verschiedene Zustände abfragen: Soll nur gescrollt werden (Highscoreanzeige)? Sollen noch Feinde angezeigt werden (keine Feinde bei Levelende oder Landung)? etc. Und dann die Ausnahmen: Die Bonusrunde gehört zwar irgendwie zu den nichtscrollenden Anzeigen, verwendet aber eine Multicolouranzeige. Folglich muß man die dann auch wieder im IRQ setzen. usw. usf.
    Am Ende landet man dann so oder so bei der Aufteilung, wie ich sie vorher genannt habe. Denn anstelle vieler verschiedener Flags, die dann gehandhabt werden müssen, hat man so nur noch ein einziges: den Zeitzähler aus dem IRQ. Und das hat nebenbei auch noch den Vorteil, daß dieses Programm nicht so schnell aus dem Tritt gerät, wenn es dann doch mal länger dauert. Bei der IRQ-Version sollte man sicherheitshalber auch vorab testen, ob ein alter IRQ noch läuft, denn der IRQ ist ja nicht re-entrant. Also kommt nach dem Setzen der VIC-Register noch ein Extraflag hinzu, daß die weitere Ausführung des IRQ sperrt...
    Rein persönlich halte ich dieses System für eher konfus und fehleranfällig, und damit auch für Anfänger ungeeignet. Hinzu kommt, daß der C64 einer der wenigen Rechner ist, die über solch einen Raster-IRQ verfügen. Andere Rechner (wie der AppleII) haben auch ihre Ballerspiele gehabt, ganz ohne IRQ. Der Raster-IRQ ist gut dazu geeignet Splitscreens mit vielen Sprites zu basteln und das Spielgeschehen zur Erzeugung weicher Bewegungen sauber zu synchronisieren. Aber er ist für die Programmstrukturierung alles andere als zwingend notwendig und, wie gesagt, auf anderen Systemen nicht einmal vorhanden.


    BTT: Egal, ob es um die Ausgabe des Highscores geht oder Gegneranimation oder..., sollte man als Anfänger vier Dinge berücksichtigen:
    1.) So simpel wie möglich. Hauptsache, es funktioniert.
    2.) Nicht auf Geschwindigkeit achten. Assembler ist an sich schon schnell. Oftmals werden Routinen wie die Highscore-Ausgabe nur sehr selten durchlaufen. Ob da der eine oder andere Befehl länger braucht, ist zunächst völlig unwichtig. Hauptsache, es funktioniert.
    3.) Manchmal hilft es, sich ein Spiel vorzustellen wie einen interaktiven Zeichentrickfilm, bei dem in regelmäßigen Abständen (24 Bilder pro Sekunde beim Film, 50 Bilder pro Sekunde beim C64) ein Bild geknipst wird, wobei alle Figuren von Bild zu Bild leicht verändert werden müssen, um die Illusion einer Bewegung zu erzeugen.
    4.) Sich nicht entmutigen lassen, wenn es mal nicht so läuft, wie es sollte. Toll, daß Ihr gemeinsam den Schritt wagt, Assembler zu lernen. :hatsoff: Viel Spaß und Erfolg dabei!

    Noch eine kleine Abwandlung zum Code in Beitrag #9 mit linksbündigen Leerzeichen statt Nullen:


    @M.J. & Interessierte: In den meisten Aussagen herrscht Einigkeit und ich sprach anfangs ja auch von typisch und nicht zwingend. Typisch ist für eine Anwendung ein eher kurzer IRQ mit einer großen Hauptschleife, bei Spielen ist dies meist andersrum.


    Deine Darstellung von der Flagabfrage im IRQ und dem wiederholten Sprung zum Ende ist so leider nicht ganz richtig. Und manche der von dir genannten 15 Punkte haben in der IRQ Routine nix verloren. Richtig, die IRQ-Routine ist aufgebläht, aber die serielle Abarbeitung anders. Und statt wie in der Hauptschleife ständ mit JSR und RTS 12 Takte zu verbraten, benötigt der IRQ mit einem JMP nur 3 Takte. Die Flags/Register müssen in beiden Fällen abgefragt werden. Die Uridium Soubroutinen müssen ja schließlich wissen, ob sie aktiv werden dürfen oder nicht. Außerdem kann das Flag u.U. auch gleichzeitig als Zähler fungieren. Bsp.:


    IRQSTART (Kollisionsabfrage)
    LDA $D01E
    AND #%xxxxxxxx
    BEQ WEITER
    ... (Kollision!)


    WEITER
    LDX SFXFLAG
    BPL SOUND
    JMP SCNKEY


    SOUND (Melodie/Soundeffekt)
    X = möglicher Zähler (0...127)


    SCNKEY JSR $FF9F (Tastaturabfrage)
    ...


    Du sprachst aber nebenbei auch andere Dinge an, die ebenfalls sehr wichtig sind und die ich ergänzen möchte:


    - Von deinen letzten Punkte würde ich 1, 3 und 4 sofort unterschreiben
    - Jedes Programm/Spiel hat so seine Eigenheiten und Unterschiede, deshalb muss ein bestehendes Konzept vom Aufbau angepasst werden
    - Jeder Koder hat seinen eigenen Stil und seine eigene Struktur beim Aufbau
    - In dem Collisions R-IRQ Kit sprach ich auch davon sich den Bildschirmaufbau in Zeitlupe vorzustellen (ähnlich deinem Zeichentrickablauf, eine genaue Vorstellung ist hier sehr wichtig!)
    - Ich möchte davon abraten sich zuviel an fremden Kode festzubeißen - Prinzipen herausarbeiten, oder eine Problemlösung/Abfrage o.ä. abgucken alles kein Thema. Aber mein Rat wäre selber probieren, experiementieren und vergleichen. In jedem eigenen Projekt lauern natürlich auch so manche Bugs, aber daraus lernt man ja bekanntlich.
    - Nach den Aussagen des Threadautors könnte ich mir vorstellen, dass es womöglich das erste Spielprojekt ist. Mir dem erwähnten Kit hätte man bspw. ein überschaubares Gerüst, dann sollte aber immer mehr eigener Kode, eigene Ideen und eigene Techniken mit rein. Sprich es wäre schon mal ein Anfang damit man loslegen kann.


    Okay, ich möchte groß keine technischen Details mehr nennen, sondern mehr in Bildern sprechen. Denn da unterscheiden sich wohl etwas meine und M.J.'s Ansichten:


    Fakt ist wir haben nur eine CPU, die die ganze anfallende Arbeit machen muss und zwar seriell - also eins nach dem anderen.
    Auch baut unser Bildschirm (PAL 50 x, NTSC 60 x) pro Sekunde das Bild frisch auf, dass man sich wie einen Takt vorstellen kann. Auf diesem Takt sollte der IRQ basieren. In punkto Spritekollisionsregister ist akurates Arbeiten gefragt um Falschaussagen zu vermeiden!!! Das bedeutet zwangsläufig nicht zu früh, nicht zu spät, nicht zu oft, nicht zu selten die Register auslesen - bitte merken, sonst's wird's falsch! Commodore's Technik selber ist pixelgenau!


    Und ab jetzt gibt es nun unterschiedliche Herangehensweisen:


    M.J. hat seine bereits detailiert vorgestellt, ich hingegen sprach ja von "Arbeitsteilung".


    Es gibt wichtige Aufgaben und weniger wichtige. Wichtig sind auch zeitkritische, die mit dem Bildaufbau zu tun haben. Und wir müssen den "schlimmsten Fall" einplanen, soll heißen es kann passieren, das in einem Frame alles zum tragen kommt! Also los geht's - eine CPU, jeder Frame 50 Bilder pro Sekunde und mit Arbeitsteilung


    Als Bsp. nehmen wir das eingangs erwähnte Spiel mit Schüssen. Wo geballert wird knallt's und dann wird auch mal was getroffen, wofür es Punkte geben soll. Wahrscheinlich bewegt sich aus was!?


    Hauptschleife erledigt weniger wichtige, bzw. weniger zeitkritische Aufgaben:


    - Evtl. Tasteneingabe auswerten (PAUSE/QUIT?)
    - Spielzustände auswerten (GAME OVER, NEXT LEVEL...)
    - Auch die Punkteanzeige hat nicht oberste Priorität - sie und andere Dinge dürften durchaus mit einem Frame Verspätung abgearbeitet werden


    (Rasterzeilen-) IRQ - der eigentliche Spielablaufmacher (wie ich ebenfalls anfangs erwähnte, kann dieser sehr groß werden und alles muss nacheindander abgearbeitet werden, da wir nur einen Professor haben.


    Das Bild wird von oben nach unten aufgebaut - wo das eigentlich Bild zuende ist, also der untere Rahmen beginnt, startet nun der Raster-IRQ und erledigt immer pünktlich nach Prioritäten


    - Sprite Kollision - im positiven Fall am besten auch gleich die Urasche beseitigen (Datenblock des Geschosses auf transparent umschalten). Evtl. Soundeffekt auslösen oder Flag für "Player" stellen
    - Spritebewegungen (kann bspw. auch eine Kopierschleife sein, die zuvor berechnete Koordinaten nun endgültig in die VIC Register überträgt. Vorteil - die Berechnungen können am Ende des IRQ erledigt werden, nach den dringenderen Abläufen)
    - etwaige kleinere Zeichnsatzbewegungen
    - falls vorgesehen Screenscrolling (Der CeVi packt im Rahmenbereich nicht den ganzen Screen, also sich erst um die obere Hälfte kümmern und dann um die untere Hälfte, das verschafft einen kurzen Vorsprung!)
    - Jetzt die Dinge, die u.U. schon im sichtbaren Bereich geschehen. Z.B. Koordinatenneuberechnungen für Spritepositionen, die beim nächsten Intervall gesetzt werden.
    - Joystickauswertung. ...Feuerknopf? Schuss auslösen!
    - ...
    - Evtl. Melodie oder Miniplayer für Soundeffekte abspielen
    - Joystick-/Tastaturabfrage


    Nun kann man bei IRQ Start und IRQ Ende die Rahmenfarbe ändern und sieht - wenn wirklich alles im IRQ Vorgesehne tatsächlich abgerabeitet werden muss, wie lange das Intervall dauert. Die "Lücke" im Frame ist dann die Zeit für unsere Hauptschleife.


    Hoffe, dass ich mit dieser bildlichen Darstellung den Aufbau, bzw. Ablauf schildern konnte, ohne Verwirrung zu stiften.


    Aber wie gesagt - nehmt euch ein kleines Gerüst oder baut es selber und dann Stück für Stück mit eigenem Kode weiterentwickeln und experimentieren!


    Zitat von M. J.

    Viel Spaß und Erfolg dabei!

    Auch da sind wir uns wieder einig - viel Spaß und Erfolg mit dem eigenen Spiel! ;):beer:

    Zitat von DATA-LAND

    Typisch ist für eine Anwendung ein eher kurzer IRQ mit einer großen Hauptschleife, bei Spielen ist dies meist andersrum.

    Das mag für sehr simple Spiele gelten, bei denen die gesamte Logik locker innerhalb eines Frames fertiggerechnet hat, sobald das nicht mehr garantiert werden kann oder auch wenn sehr viele Unterbrechungen pro Frame benötigt werden (z.B. für einen Spritemultiplexer) ist das i.d.R. nicht mehr der Fall.

    Klar, aber die meisten Spiele sind ja simpel, sodass man den Ablauf in einen Frame bekommt, was dann ja auch schön und ruckelfrei aussieht. Mit Spritemultiplexer habe ich selber noch nichts zu tun gehabt, daher kann ich dazu nix sagen. Aber "Carrera F1" war z.B. so ein Projekt, für dessen Realisierung ich mir was völlig anderes überlegen musste, was total Spezielles. Aber bei dem von ThomBraxton geschilderten Spiel finde ich die beschriebene Arbeitsteilung via Raster-IRQ ideal, zumal sie nicht schwer umzusetzen ist.

    So wie ich es verstanden habe, werkelt das ProjectX-Team an ihrem Spieledebüt. Natürlich führen viele Wege nach Rom, aber am Anfang ist ein simples, aber zuverlässiges und bewährtes Konzept das Richtige denke ich. Und viele unserer Lieblinge sind ja einfache Spielideen, die schlicht aber korrekt umgesetzt wurden. Was dagegen frustet sind fehlerhafte Kollisionsabfragen, hakelige Steuerungen, träger oder ruckeliger Ablauf...


    Bin mir gar nicht sicher, ob unsere Beiträge von ThomBraxton & Co. überhaupt noch gelesen werden?