Konzept für einen Vertical-Shooter

Moderator: Rockford

Antworten
Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

Hallo in die Runde!
Ich möchte mal ein konzeptionelles Thema hier gerne mit Euch diskutieren und von Erfahrungen profitieren bzw. meine eigenen weitergeben.
Mein primäres Ziel war es Assembler für den Atari 8-Bit zu lernen und dabei ein Spiel zu programmieren. Ich wollte ein anspruchsvolles Shooter Spiel machen und dabei sollte ein verticales Feinscrolling umgesetzt werden.

Als Konzept hatte ich mich (unwissend) für folgendes entschieden:
1. Graphics 0 mit aber 16 Farben. Auflösung 40x24.
2. Die Character (Auflösung 8x8) werden umdefiniert und damit baue ich die Landschaft.
3. Zwei Player nutze ich für das Raumschiff, 2 Missiles für die Schüsse, 2 weitere Missiles flansche ich noch für Blinklichter an das Raumschiff.

Welche Probleme habe ich bekommen?
1. Wenn ich die Character in Graphics 0 mehrfarbig mache und neu definiere, verliere ich alle Buchstaben. Außerdem habe ich nur eine relativ grobe Auflösung, die man für die Landschaft (wenn man es geschickt macht) noch relativ gut ertragen kann, aber spätestens für die Items in der Landschaft fehlt mir die feinere Abstufung. Und ich habe nicht genügend Player für die vielen Items!
2. Die ganze Player/Missile Programmierung kann echt ganz schön tricky sein. Eine Kollisionserkennung mit der Landschaft oder den Items ist ja echt toll, aber es ist echt nicht so einfach die genaue Lokalisation des getroffenen Items zu bekommen.
Auch das ganze Timing der Player/Missiles muss man fast zwingend im Interrupt programmieren - spätestens bei so Dingen wie Detektion der Kollision (im Interrupt) und Erstellung der Explosion samt Sound (im Hauptprogramm) bekommt man ein massives Timingproblem (daran arbeite ich gerade).
Warum Timingproblem? Weil der Assembler einfach zu schnell ist! Man stelle sich vor ein getroffenes Item soll mit Sound explodieren und in der animierten Explosionsphase scrollt der Bildschirm weiter ... wenn man die Explosionswolke in einer Phase programmiert, dann ist sie viel zu schnell weg - ich muss das vom Timing also in den Hauptcode so integrieren, daß die einzelnen Phasen mehrfach im Code ablaufen bis sie fertig sind....
Viele Probleme... wenn ich mir die ganzen alten Shooter anschaue mit den vielen Details und den vielen Items oder Schüssen und Aliengegnern usw. kann man nur mutmaßen, daß die so etwas komplett ohne Player/Missile programmiert haben müssen... und wahrscheinlich ist das auch so.

Ich werde dieses aktuelle Projekt aber so weiterführen und abschließen. Meine Gedanken drehen sich aber schon um folgende Ideen für "danach":
Hochauflösende Graphik mehrfarbig.
Dann entfällt die gesamte Systematik mit Grobscroll und Feinscroll - man braucht nur noch den Grobscroll, der ja dann automatisch fein ist.
Die Landschaft wird dann nicht durch Character erstellt, sondern man definiert im Speicher größere Landschaftsteile, die man wiederkehrend sinnvoll zusammenbaut. Auch des Raumschiff und die Items, evt. Gegner werden so gebaut und können dann ja automatisch mehrfarbig und deutlich detailgerechter erstellt werden. Für das Raumschiff und die Missiles programmiert man eine eigene Kollisionserkennung (einfach den Bildschirmspeicher um das Raumschiff auslesen).
Den Bildschirm scrollt man indem man einfach die Startadresse des Bildschirmes verschiebt, das hätte den Vorteil, das eine Animation am Ort des Speichers ablaufen kann (außer die bewegenden Teile - die muss man dann im Speicher verschieben).
Wie ist denn Eure Erfahrung so und sind meine Gedanken falsch und gehen in eine Sackgasse?? Oder befinde ich mich aktuell eher in einer Sackgasse (was sich gerade so anfühlt)?
Grüße
Peter

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

... eine sehr schöne Auflösung bietet der Graphic-Modus 7 (in Basic) ... da hat man mit 4 Farben und unterschiedlichen Helligkeiten eine ganz gute Auflösung von zB 160x96 Pixel oder maximal 160x160 Pixel.
Wenn man nun einen Bildschirm mit 160x96 Pixel (also 15360) verschieben möchte (z.B.) um ein Pixel nach oben.... dann hat man ein recht feines scrolling und die komplette Pixelmöglichkeiten, die bei Charactern immer schwierig ist. Die Frage ist nur: schafft es die Assemblerroutine 15360 Pixel in guter Zeit um einen Pixel in eine Richtung zu verschieben??? Hat das mal jemand probiert??

Currock
Beiträge: 8
Registriert: 18.08.2021 17:31
Has thanked: 2 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Currock »

Soweit ich mich erinnere, ist es besser, die ganze Bitmap im Speicher fertig abzulegen und nur in der DisplayList den Start zu verschieben. Noch mehr Möglichkeiten hast Du, wenn Du Dir eine eigene DisplayList zusammenstellst, die Du dann nach Deinen Wünschen ändern kannst. Das müsste gerade bei einem Vertical-Scroller viel CPU-Zeit sparen.

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

So ähnlich mache ich das ja auch jetzt schon! Ich arbeite mit 2 Bildschirmbereichen und verschiebe im nicht sichtbaren Bildschirm alles um eine Zeile nach oben, wenn der ganze Prozess fertig ist, schalte ich ihn auf sichtbar um (indem ich den Eintrag in der Displaylist ändere) und
dann im sichtbaren Bereich kommt das Feinscrolling. Also Feinscrolling im sichtbaren Bildschirm, Grobscroll im unsichtbaren ...
Die Frage war ja nun, ob ich einfach eine höhere Auflösung nehme (beispielsweise eine Graphics 7 Bitmap) und das dann komplett (im unsichtbaren Bereich) um einen Pixel nach oben verschieben kann und es noch alles gut und zeitgerecht funktioniert... jetzt verschiebe ich ja "nur" 980 Elemente (Character) und im anderen Fall hätte ich z.B. mindestens ca. 15000 Elemente oder bei einer Auflösung von 320x160 maximal 51200 Pixel zu verschieben.. schafft das die CPU überhaupt in annehmbarer Zeit???

Ich werde das jetzt mal zeitnah in Assembler programmieren und testen und dann ausführlich berichten...

Eins ist dabei schon relativ klar: Im Moment berechne ich noch viel mit den Zeilen:

clc
lda var1
adc #40
sta var1
lda var1+1
adc #0
sta var1+1
....

die ganzen Berechnungen müssen raus, um Zeit zu sparen. Ich werde den einzelnen Zeilen feste Werte zuweisen, das wird enorm viel Zeit sparen, allerdings den Code länger machen, was aber egal ist.

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

... da hatte ich mich natürlich (zum Glück) verrechnet!!
Bei Graphics 7 (Antic D) habe ich ja nur eine Auflösung von 160x80 mit 4 Farben, wobei eine Zeile aus 40 x 8 Bit besteht - also muss ich "nur" 40 x 80 Elemente verschieben, was 3200 Elemente insgesamt ausmacht. Wir arbeiten dann allerdings im Scanline-Modus 2 - da muss ich mal sehen wie der scroll wirkt, denn er wird "leicht" ruckelig aussehen!
Scanline-Modus 1 wäre natürlich besser, aber bedeutet wieder mehr Speicherbedarf und Arbeitsbelastung ...

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

... ich habe mal eine Displaylist für ANTIC D (Graphics 7) erstellt und den Bildschirm schön bunt gefüllt.
Und dann habe ich eine kleine einfache nicht so rechenintensive Routine erstellt, um um nach oben zu scrollen.... das Ergebnis ist schon recht gut und die CPU schafft die 3200 "Bildpunkte" in guter Zeit. Auch der Feinscrolleffekt ist schon gut und ich denke das würde für einen Shooter gut ausreichen.
Alles passiert direkt im sichbaren Bereich und also flimmert und "pumpt" es natürlich. Als nächsten Schritt mache ich die Bewegung im unsichtbaren Bereich und schalte immer auf den anderen Bildschirm, wenn der komplette move abgeschlossen ist - dann müsste es ganz ruhig und sauber scrollen!!
Hier mal das erste Ergebnis:
IMG_4010.MOV
(787.18 KiB) 49-mal heruntergeladen

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

... ich habe das jetzt mal auf 2 umschaltbaren Bildschirmen programmiert - also der ganze Block wird in den unsichtbaren Bildschirm kopiert und dabei automatisch beim kopieren um eine Zeile nach oben kopiert, dann schalte ich auf sichtbar und dann wieder kopieren zurück auf Bildschirm 1 (jetzt unsichtbar) um eins nach oben und wieder sichtbar schalten.
Funktioniert gut, das scrolling finde ich fein genug, aber ich habe immer noch ein leichtes flackern... keine Ahnung warum...
IMG_4014.MOV
(1.17 MiB) 53-mal heruntergeladen

Currock
Beiträge: 8
Registriert: 18.08.2021 17:31
Has thanked: 2 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Currock »

Mag alles funktionieren, aber schau Dir mal die Display-List selbst an. Es sind sogar Funktionen für vertikales und horizontales Scrollen vorhanden. Dabei braucht kein Byte im Speicher verschoben werden, sondern es wird praktisch nur das Bildschirmfenster über den Bereich gelegt, der gezeigt werden soll.
Ich habs gestern mal in Basic gemacht, und da keine Bytes verschoben werden, passiert eben der Bildwechsel/scrolling augenblicklich, ohne Assembler anwendung.
Ich habe hier ein Buch, in dem es beschrieben ist: "Das Atari-Buch Band 2" vom Markt & Technik-Verlag. Sollte aber öfter zu finden sein, z.B. im De-Re-Atari, oder in Atari-intern oder Profibuch vom Data-Becker-Verlag. Manche davon sind inzwischen freigegeben und man findet sie auch zum Download. Hier im Abbuc-Mitgliederbereich sind eventuell auch Bücher/Texte zu dem Thema vorhanden.
Wenn Du mit Englisch klar kommst, hier ist noch eine Interessante Seite zum Thema Display-list, Interrupts und so weiter. So langsam komme ich auch wieder da hin, etwas mit dem XL zu machen, das System konnte man noch einigermassen überblicken.

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

Vielen Dank für die Nachricht, Currock - wenn du meine Post verfolgt hast, dann wirst du sehen, wie ich (ReturnToPhobos) in Assembler gerade programmiere. Hier habe ich ja sehr ausführlich über das Feinscrolling in Kombination mit dem Grobscrolling berichtet und mittlerweile ist dort schon recht viel implementiert - incl. Player/Missiles die hauptsächlich im VBI laufen.
Das Verticalscroll läuft sehr gut und flüssig. Dazu habe ich Graphics 0 genutzt - also eine Textdisplaylist erstellt - mit 40x23. Hier muss man fürs scrolling in der Displaylist mit feinscroll und grobscroll arbeiten. Das läuft sicherlich gut und flüssig und auch mit relativ wenig Speicherbedarf (980 bytes). Literatur dazu habe ich entweder online oder als Buch fast alles, was es gibt... und vieles davon gelesen.

Mein kleiner "break" was RTP angeht war ein ganz anderer Grund - bzw. etliche Gründe. Eine Landschaft für ein Spiel zu erstellen mit Textgraphic ist umständlich - die Kollisionen mit Landschaftseinheiten und die Aktion bei so einer Kollision in der Landschaft (zB eine Explosion eines Items die während der Explosion weiterscrollt und weiter animiert wird) ist umständlich und schwierig. Daher suche ich gerade auch für nachfolgende Projekte nach Alternativen... eine Bitmap scrollen zu lassen ist programmiertechnisch viel viel einfacher und alle nachfolgenden Aktionen ebenfalls - das scrollen habe ich ja bereits umgesetzt, das flackern liegt wohl daran, daß das Umschalten teilweise während des Bildschirmaufbaus passiert - das muss ich abfangen.
Ich plane das im Displaylistinterrupt zu programmieren - vielleicht bewege ich auch nur immer einzelne Teile des aktuellen Bildschirmes in den 2. unsichtbaren Bildschirm im VBI und schalte dann alles mittels DLI um... mal sehen wie es am besten geht.
Jedenfalls werde ich hier mal ein wenig experimentieren und ausprobieren. Wenn ich den optimalen Code habe, der tatsächlich flüssig eine hochaufgelöste Bitmap scollt, dann werde ich das hier komplett mit Anleitung posten, sodaß das jeder für sich nutzen kann.

Mein langfristiger Plan dieses Projektes ist folgender:
Ich kopiere nicht Zeile für Zeile von Bildschirm 1 in Bildschirm 2 und schalte am Ende um, sonder ich möchte den gesamten Bildschirm in variablen Clustern unterteilen. Eine Landschaft und die zugehörigen Items (z.B. ein Baum in der Landschaft) setzt sich dann aus Modulen zusammen, die eine bestimmte Größe haben (zB. 16x16 Bit). In Graphics 7 könnte man dann eine maximale 2x2Bit Auflösung mit 4 Farben erreichen was echt gut ist. Die einzelnen Cluster werden in einer Matrix gespeichert - diese Matrix ist veränderbar und also läßt sich jeder einzelne kleine Cluster von 16x16 ständig fast selbständig laufend animieren - während des scrolls.
Damit könnte man echt tolle Sachen machen...
Ob das alles funktioniert und ob das unsere kleiner Atari rechentechnisch hinbekommt wird man sehen ;-)

Currock
Beiträge: 8
Registriert: 18.08.2021 17:31
Has thanked: 2 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Currock »

Bekommen wir das dann auch mal zu sehen?

Und vor lauter Tippen habe ich oben den Link vergessen:
https://playermissile.com/dli_tutorial/

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

ja klar, ich stelle hier alles rein!
Alles in Assembler - allerdings programmiere ich derzeit in MAD-Assembler unter Eclipse/WUDSN

Das sieht dann so aus (Ausschnitt):

Code: Alles auswählen

			org $2000
			
			icl '../hardware.txt'
			icl '../header.txt'
			
        
dlist   		.byte 112,112,112,77,96,144
			.byte 13,13,13,13,13,13,13,13,13,13
			.byte 13,13,13,13,13,13,13,13,13,13
			.byte 13,13,13,13,13,13,13,13,13,13
			.byte 13,13,13,13,13,13,13,13,13,13
			.byte 13,13,13,13,13,13,13,13,13,13
			.byte 13,13,13,13,13,13,13,13,13,13
			.byte 13,13,13,13,13,13,13,13,13,13
			.byte 13,13,13,13,13,13,13,13,13
			.byte 66,96,159,2,2,2,65,162,143
			
			
			
			
			
			.proc main
			
main			jsr displaylist ;Subroutine Displaylist-Aufbau

start			mva #$60 var4 		;36960 Start Bildschirm1
			mva #$90 var4+1 


start1			clc
			ldx #1
			ldy #0
@			txa
			sta (var4),y
			inc var4
			bne @-
			inc var4+1
			inx
			
			cpx #14
			bne @-
			
			

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

... nach den ganzen Wirren um die JHV habe ich mich jetzt mal ganz intensiv damit beschäftigt, das scrolling bitmap zu optimieren.
Ich wollte das komplett in den VBI reinpacken und somit komplette Flackerfreiheit erhalten... da steigt der Rechner aber leider aus, da der Gesamtzyklus im VBI erwartungsgemäß zu lang war. Daher habe ich das aufgesplittet und den ganzen Bildschirm immer in 256 Bit Portionen im VBI kopiert und nach 32000 umgeschaltet... geht, aber zu langsam! So jedenfalls geht es nicht.
In der Summe habe ich den Programmcode etwas optimiert und nun läuft es gut! Fast flackerfrei!! Der erste Ansatz mit grobscroll und feinscroll ist auch nicht 100% ig flackerfrei.
Also habe ich mein Hauptprogramm mal soweit umgebaut, daß ich keine Gr.0 nutze, sondern die Gr. 7 Bitmap... hat m.E. für später deutliche Vorteile und läuft ganz gut....

... hier also erstmal Pause und ich mache bei meinem Projekt ReturnToPhobos weiter...

Benutzeravatar
LarsImNetz
Beiträge: 19
Registriert: 24.08.2021 18:27
Has thanked: 7 times
Been thanked: 6 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von LarsImNetz »

Hi,
nur mal als Tipp von mir, beim horizontal-Shooter Oxygene-Be halte ich das gesamte große Schiff im Speicher.
Der Scrollbereich des Schiffes umfasst 512 x 17 Bytes in Antic Mode 4 (4 Farben, 8 Zeilen) und belegt 8,5kb RAM ab $D800, dahinter liegen dann noch die 1,5kb für die Player Missiles.
Man kann langsam bis schnell über das Schiff fliegen. Da der Atari per HSCROL Register das weiche Scrolling unterstützt geht das buttereweich. Die Assembler-Routine muss nur die gewünschte Position berechnen.
Animationen, die auf dem Schiff stattfinden gibt es nicht. Allerdings ändere ich einige Bereiche, wenn man die Jets auf dem Schiff abballert, wird ein Krater gezeigt. Einfach die 9 Bytes die ein Jets belegt durch etwas anderes ersetzen.
Wollte ich aber noch Animationen darstellen, bräuchte ich nur das entsprechende Font-Zeichen zu ändern, der Atari Antic macht dann den Rest.
BTW: Die paar Sterne im Hintergrund setze ich in Abhängigkeit von der aktuellen Position und nur wenn dort kein Schiff ist. Im Zeichensatz ändere ich noch die 2 Bytes für den Stern, sodass es aussieht als stünde der Stern fix. Ist mir leider nicht perfekt gelungen, die Sterne ruckelt leicht.

Und noch etwas: Ich habe ein paar Tests/Assembler-Sourcen geschrieben, wie viel Bytes der Atari pro 1/50s setzen kann. Über 3300 Bytes bin ich nicht gekommen. Der macht dann aber nichts anderes mehr. Das ist für einen Scroller der auf hochauflösender Grafik arbeitet vielleicht etwas wenig. Zudem frisst ein hochauflösender Screen (Graphics 7, 8, 15) einfach zu viel Speicher.
Desweiteren gibt es noch etliche Atari 8bit Nutzer überm großen Teich die Dein Spiel dann bei sich auch gerne sehen würden und dann hast Du es plötzlich mit 60 Bildern/s zu tun und damit nur noch ca. 2400 Bytes pro 1/60s die sich bewegen lassen.
Das sollte man immer im Hinterkopf behalten.
Also meine Empfehlung, Zeichensatzgrafik und dann jede Menge andere Tricks. Man kann auch mehrere Zeichensätze nutzen. Umschalten per DLI. etc.

JM2C
Lars

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

... ich kreise die ganze Zeit noch an einem Problem, sonst würde ich ja das Scrolling auch anders (einfacher) durchführen. Vielleicht kann mir ja jemand da einen Tip geben:

Mein Programm soll nun mit Gr. 7 laufen, hat also eine relativ hohe Auflösung. Ein gesamter Bildschirm beansprucht dabei schon 3200 Byte im Speicher. Die Landschaft werde ich aber zusammenbauen, da sich die Baustücke wiederholen und auch deutlich größer werden können, geschickt zusammengebaut sehen sie fein aus. So könnte ich also ca. 200 Byte für eine komplette Bildschirmfüllung nur brauchen. Wenn ich scrollen lasse, dann ist eine gute Geschwindigkeit ca. 5s pro Bildschirm. Wenn ich jetzt also zum Beispiel ca. 15 Minuten durchsrollen lassen möchte wo sich die Landschaft ständig ändert, dann brauche ich also ca. 12x15x200 Byte = 36 KB für die Landschaft... so weit alles gut! Mit diesem Ansatz schreibe ich also immer die neuen Daten in die letzte Zeile und packe die gesamten 3200 Byte um eine Zeile hoch und scrolle somit. Viel Arbeit für die kleine CPU, geht aber. Ein wenig ruckelt es, aber geht. Leider befürchte ich, daß der CPU dann für weitere Dinge die Luft ausgeht....
Charaktergraphik wie in meinem ersten Ansatz geht und löst das Problem, schafft aber andere Probleme mit der Farbauflösung im Detail, der schwierigen Zusammenarbeit mit den PM usw.
Clever erscheint der Ansatz einfach den Bildschirm mit Änderung der Vektoren für den Anfang des Bildschirmes quasi in Nullzeit jeweils zu ändern so, daß quasi der sichtbare Bildschirm über den Speicher geschoben wird. Tolle Methode aber: Dann bekomme ich ja wieder ein Speicherproblem, da ja dann die komplette "unkomprimierte" Landschaft im Speicher steht - also 3200 Byte pro Bildschirm. Ich bekomme dann nur im Vergleich 36000:3200x5= 55 Sekunden Scrollzeit - statt 15 Minuten. Das erscheint mir deutlich zu wenig.

Mein einzig erkennbarer Ausweg wäre folgender: Ich investiere 9,6 KB für einen durchzuscrollenden Bildschirmbereich also 3 komplette ganz flüssig scrollende Bildschirme - Scrollzeit ca. 15 Sekunden und packe nach den 15s den gesamten sichtbaren Bereich wieder an den Anfang incl. Verbiegung des Startvektors - hier entsteht dann wohl ein kleiner Ruckler wegen des Zeitverlustes - vielleicht kann man das mit irgendeiner Aktion kaschieren... und dann gehts weiter.

Oder gibt es eine noch bessere Lösung für mein "kleines" Problem??
Gruß
Peter

Benutzeravatar
Kveldulfur
Beiträge: 198
Registriert: 17.08.2021 02:32
Has thanked: 61 times
Been thanked: 21 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Kveldulfur »

Hallo Peter!

Dein erster Ansatz war Graphics 0 zu nutzen mit einem GITA-Modus. Dadurch hast Du 40x24 Bytes = 960 Bytes gehabt, aber eine Auflösung von 80x192.

Nun nutzt Du Graphics 7 mit einer Auflösung von 160x96 Pixel bei 3840 Bytes.

Warum nutzt Du nicht den Antic Textmode 4? Das ergibt eine Auflösung von 160x192 Pixel bei 4 Farben, da aber ein Zeichensatz wieder als Darstellung genutzt wird, verbraucht es nur 960 Bytes.
Du kannst auch den Textmode 5 nutzen, der 160x96 Pixel bei 4 Farben ergibt aber nur 480 Bytes an Speicherplatz benötigt.

Das Bauen von Grafik aus einem Zeichensatz heraus, ist eine einfache Lösung. Man kann Zeichen des Zeichensatz im VBI regelmäßig überschreiben und so sogar Animation erzeugen.

Ich denke, dass wäre der einfachste Weg...

Grüße
Janko
Antik_4.png
Antik_4.png (6.53 KiB) 1585 mal betrachtet
Antik_5.png
Antik_5.png (7.46 KiB) 1585 mal betrachtet

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

Hallo Janko,
danke für die Antwort.... bevor ich also weitermache und viel komplizierten Code schreibe, der dann doch nicht gut funktioniert für meine Zwecke, werde ich mal mit beiden Antic-Textmodi experimentieren und schauen, ob das für meine Zwecke besser ist.
Immerhin hat der Textmodus den Vorteil, daß ich das ganze Fein-/Grobscrol-Gedöns ja schon implementiert habe und gut nutzen kann... und klar, mit dem VBI könnte ich dann auch wie du es geschrieben hast Animationen reinbringen.
Bei meinem ersten Ansatz mit Gr.0 hatte ich halt deutlich mehr Farben zunächst (die so gar nicht zwingend brauche), war aber dann beschränkt, daß ich einen Charakter letztlich nur in 2x4 Bit differenzieren konnte. Ich brauche aber mind. 4x2 besser 8x1 Bit, um eine bessere und feinere Darstellung der Items hinzubekommen...
Ich probiere das mal aus! Viele Wege führen nach Rom und am Ende ist jeder Weg interessant und spannend!
Gruß
Peter

Benutzeravatar
Irgendwer
Beiträge: 22
Registriert: 25.08.2021 19:05
Has thanked: 9 times
Been thanked: 9 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Irgendwer »

Prodehl hat geschrieben:
20.12.2021 17:09
Oder gibt es eine noch bessere Lösung für mein "kleines" Problem??

Anstatt den gesamten Bildschirmspeicher zu kopieren (40 Bytes pro Zeile), kannst Du auch nur die Display-List anpassen bzw. die LMS-Adresse(n) von ihr.

Ausgangszustand:

1 x Mode D + LMS Screen
...
(weitere Zeilen im Mode D)
...


Eine Zeile nach oben:

1 x Mode D + LMS Screen+40
...
(weitere Zeilen im Mode D)
...
Letzte Zeile, Mode D + LMS Screen (für die Du den Inhalt aktualisiert hast)


die letzte Zeile wandert dann jeweils pro Frame nach oben (vorletzte, vorvorletzte etc.) bis zur ersten und das Spiel beginnt von vorne...

Viel Erfolg!

Benutzeravatar
Prodehl
Beiträge: 280
Registriert: 24.08.2021 14:40
Has thanked: 14 times
Been thanked: 52 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Prodehl »

ICH TROTTEL ......

Gestern habe ich mich ganz intensiv mit den Farbregistern beschäftigt und dort einiges "durchdrungen"... mir ist dabei aufgefallen, daß ich in Gr. 7 irgendwie nur 2 Farben halbwegs vernünftig setzen konnte... dabei habe ich festgestellt, daß wenn man in den Colorregistern nichts definiert setzt, der Rechner alles auf die gleiche eine Farbe setzt, die ich definiert hatte... ich glaube ich hatte nur Color2 angesprochen.... wenn ich dann alle Colorregister mit unterschiedlichen Werten belege, dann komme ich natürlich auch auf die 4 Farben! Und jetzt versuchte ich auf eure Empfehlung hin meinen alten Ansatz von Gr. 2 Antic (Gr.0 Basic) auf Gr. 4 Antic umzustellen in der Displaylist - aber - das hatte ich im Programm schon längst getan - mehr unwissend. Mein alter Ansatz läuft schon die ganze Zeit auf Antic 4!!! Warum konnte ich dann die 4 verschiedenen Farben nicht richtig in einem Charakter nutzen und warum konnte ich die 8 Bits in der Auflösung nur als 2x4 ansprechen?? Ich hatte die Colorregister nicht verschieden gesetzt, also hat er alles auf eine oder max. 2 Farben dargestellt ... oh Mann...
Jetzt nachdem ich alle Colorregister anspreche gehts natürlich!!
Oh je...

Benutzeravatar
Kveldulfur
Beiträge: 198
Registriert: 17.08.2021 02:32
Has thanked: 61 times
Been thanked: 21 times
Kontaktdaten:

Re: Konzept für einen Vertical-Shooter

Beitrag von Kveldulfur »

Wenn man im Antic-Mode 4 ein Zeichen invertiert (Bit 7 setzt), dann bekommt man eine 5. Farbe.
Allerdings kann man dann Farbe 3 in dem Zeichen nicht nutzen... also immer nur 4 Farben pro Zeichen.
Antik_4.png
Antik_4.png (1.01 KiB) 1547 mal betrachtet
Ich denke, damit kann man sicherlich schon etwas anfangen.

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast