Mein erstes Spiel...

[yMoreT8]

Einem guten Rat folgend überlege ich welches Spiel ich nachprogrammiere. Man muss sich ja Ziele setzen, aber auch welche die man erreichen kann. Das ist für mich in diesem frühen Stadium nur schwer abzuschätzen, aber ich denke sowas wie Galaga/Galaxian wäre vielleicht für den Anfang besser als ein aufwändiger Scroller/Shooter?
So richtig reizen würde mich ja sowas wie Giana Sisters, das kenne ich vom C64, oder das ein oder andere Space-Shooter-Game vom CPC464. Aber vielleicht sollte ich lieber erstmal mit Pong anfangen?

[Dr. Irata]

Also 1. finde ich es echt super, wie du das angehst... kommt mir bekannt vor!!
Ich habe ja auch mit einem Shooter angefangen und das war eine super Idee, weil man da so viel lernt... Shooter ist auf jeden Fall schwieriger, als Nicht-Shooter

Galaxien/Galaga ... puh ... das würde ich mir vielleicht jetzt nach fast drei Jahren zutrauen. Ist natürlich machbar und du bekommst hier auf jeden Fall Hilfe auf alle Fragen!! Hau rein!!!!

[JoSch]

M.U.L.E.

[Mathy]

.
Hallo WiesoMehrTeeAcht

An Giana Sisters für den Atari 8 Bit wird schon seit einiger Zeit gearbeitet.

Tschüß

Mathy

[yMoreT8]

Ok, dann versuche ich mich mal an "Galaxian"

Mal analysieren was wir da haben:
1.) Starfield-Simulation im Hintergrund
2.) Das eigene Schiff (Player 1)
3.) Die gegnerischen Schiffe in der Formation ("Kanonenfutter")
4.) Die gegnerischen Schiffe als Jäger (Kamikaze und Gegenfeuer)
5.) Titel/Hintergrundmelodie
6.) Explosions-Animation, eigenes Schiff
7.) Explosions-Animation, gegnerisches Schiff
8.) Sound-Effekt, eigener Schuss
9.) Sound-Effekt, gegnerischer Schuss
10.) Sound-Effekt, Explosion Gegner
11.) Sound-Effekt, Explosion eigenes Schiff
12.) Level, Leben und High-Score Anzeige
13.) Schuss-Animation vom eigenen Schiff
14.) Schuss-Animationen der gegnerischen Schiffe

Vom DLIST-Aufbau her sieht das sehr nach erster Zeile im Text-Modus und der Rest im Graphik-Modus aus.

[yMoreT8]

Das eigene Schiff wäre wohl ein Sprite, aber wie macht man die Gegner sodass man diese pixelweise in der Formation und nahezu frei im Angriff bewegen kann? Nimmt man dafür Tiles, einen Character-Font oder Software-Sprites? Man braucht ja auch ne Kollisionserkennung usw.

Das Starfield wäre doch ein vertical-scroll bei dem oben in der obersten Zeile per Random ein paar Pixel in verschiedenen Helligkeitsstufen eingestellt und dann nach unten gescrollt würden? Mir fällt auf das die "Sterne" dabei immer mal flackern. Ob das gewollt war oder ein Nebeneffekt?
Ich rätsele wie man so einen Effekt im Hintergrund des Spielfeldes hin bekommen könnte, ohne dabei die Grafik zu beeinflussen?

[Dr. Irata]

könnte Antic 4 oder 5 sein...
Wahrscheinlich brauchst du Softwaresprites für die Gegner
Dein Player ist mehrfarbig... brauchst also mehrere Player zusammen
Kollisionserkennung habe ich bei Caverns of Eris mittels Hitboxen gemacht

[skr]

Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball

[Dietrich]

Ok, dann versuche ich mich mal an "Galaxian"
Vom DLIST-Aufbau her sieht das sehr nach erster Zeile im Text-Modus und der Rest im Graphik-Modus aus.

Man kann sich in Altirra 2.6 die Display-List eines laufenden Spiels ansehen: Einfach per F8 in Debugger gehen, in den Atari-Bildschirm klicken und dann bei gedrückter Shift-Taste Mauszeiger über eine Bildschirmzeile halten.
(Seltsamerweise geht das nicht in neueren Altirra-Versionen ?!?)

Bei Galaxian wird für die oben wartenden Gegner ANTIC-Modus E verwendet (2x1 Rasterpunkte große Pixel in 3 Farben) und ansonsten gibt es fast nur Leerzeilen (ANTIC $70). Die Sterne und herabstürzenden Gegner sind also offenbar Missiles und Player. Interessant!

galaxian.png (11.03 KiB) 706 mal betrachtet

[pps]

Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball

Ich bin mir sicher sowas schon damals am ATARI gespielt zu haben... War das "Hydra Ball"?

Ah, gefunden: Hyperball (bei Fandal)

[CharlieChaplin]

M.U.L.E.

Ich glaube das gibt es schon...
Wobei ich es noch nie gespielt habe.

[CharlieChaplin]

Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball

Ich bin mir sicher sowas schon damals am ATARI gespielt zu haben... War das "Hydra Ball"?

Ah, gefunden: Hyperball (bei Fandal)

Dies war mal ein Beitrag für die "Diskline" von PPP/W.Rätz, also kein wirklich kommerz. Spiel. Inzwischen sind die Disklines ja PD... Antist war u.a. S.Sölbrandt, bekannt von den Games "Die Zeitmaschine", "Die Zeitmaschine 2 - Die Rückkehr", "Die Zeitmaschine 3 - Die Außerirdischen", aber auch "Bright Eyes", "Crillion" und anderen Games.

[pps]

M.U.L.E.

Ich glaube das gibt es schon...
Wobei ich es noch nie gespielt habe.

Waaaaaas? Noch nie M.U.L.E gespielt?
Das geht ja mal garnicht!

[skr]

Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball

Ich bin mir sicher sowas schon damals am ATARI gespielt zu haben... War das "Hydra Ball"?

Ah, gefunden: Hyperball (bei Fandal)

Entweder es ist mir entfallen, oder ich habe es absichtlich vergessen, weil es sich zwar an Hypa-Ball orientiert, aber mehr auch nicht (gaaanz vorsichtig ausgedrückt ).

Dann sage ich mal (etwas unvorsichtiger) : Ich hätte gerne eine gute A8-Version davon.

[yMoreT8]

Ähm, seid mir nicht böse, aber gehört das hier hin in meinen Thread? Macht doch bitte einen eigenen auf, sonst wird dieser hier völlig unleserlich. Dankeschön

[yMoreT8]

Bei Galaxian wird für die oben wartenden Gegner ANTIC-Modus E verwendet (2x1 Rasterpunkte große Pixel in 3 Farben) und ansonsten gibt es fast nur Leerzeilen (ANTIC $70). Die Sterne und herabstürzenden Gegner sind also offenbar Missiles und Player.

Interessante Idee das reverse zu engineeren. Dabei kann man sicher auch so einiges lernen. Die Arcade-Version des Spieles bot etwas mehr Action, vor allem mehr als das schnöde Einzelfeuer.

Wie können die Sterne auch Missles sein? Davon hat man doch nur vier oder so? Auch meine ich das während des Spiels deutlich mehr Gegner herab kommen als Missles/Player verfügbar sind? Oder kann man Missles/Player mehrfach darstellen lassen?

[Dr. Irata]

Ich würde mir als allererstes überlegen mit welcher Auflösung und Art des Bildschirmes und mit welcher Speichergröße ich arbeiten will.
Alles hat da so seine Vor- und Nachteile beim A8.
Ich habe mir da also inzwischen eine Vorlage gemacht: 128 kB Antic4 - also arbeiten mit allen Banks. Da ist man echt am flexibelsten.
Falls man noch mehr Speicher braucht, kann da noch das ROM ausschalten und das RAM unter dem ROM nutzen, das bringt nachmals ca. 3kB. Dann braucht man aber ein eigenes abgespecktes OS.

Wie anfangen?? Ich würde wohl zunächst die 128bK Vorlage Antic 4 nehmen und dann als allererstes den Sternenhintergrund bauen. Dafür würde ich wohl zunächst die Technik der Softwaresprites erlernen, das wirst du bestimmt brauchen. Natürlich führen viele Wege nach Rom, du musst halt deinen eigenen wählen.
Galaxian als Startprojekt ist echt eine Herausforderung, wenn du das aber umgesetzt bekommst, kannst beherrscht du den Rechner überwiegend!

[DjayBee]

Wie können die Sterne auch Missles sein? Davon hat man doch nur vier oder so? Auch meine ich das während des Spiels deutlich mehr Gegner herab kommen als Missles/Player verfügbar sind? Oder kann man Missles/Player mehrfach darstellen lassen?

Die Player und Missiles sind keine quadratischen Sprites, wie auf anderen Systemen, sondern gehen über die volle Bildschirmhöhe. Mittels Display List Interrupts kannst du sie prinzipiell in jeder Bildschirmzweile an eine andere horizontale Position setzen und ihre Farbe ändern.
Player sind 8 Bit breit, Missiles 2 Bit. Ich schreibe bewusst Bit weil man sie zwei- oder vierfach breit anzeigen lassen kann.

Oben hat Dietrich geschrieben, dass es zwischen den Aliens und dem Schiff des Spielers nur leere Zeilen gibt. Somit müssen die Sterne und angreifenden Gegner Players und Missiles sein. ANTIC zeigt sonst nichts an.

Ich rate jetzt mal - und habe kurz auf den Screenshot oben geschaut - dass es je Bildschirmzeile immer maximal einen Stern gibt. Somit ist das höchstwahrscheinlich ein einzelnes Missile für alle Sterne.

Die angreigenden Gegner sind zweifarbig und nicht immer schön eine Zeile eine Farbe, die nächste eine andere. Somit müssen sie aus mindestens zwei Objekten bestehen. Eins ist auf alle Fälle ein Player. Die zweite Farbe ist meistens nur in einzelnen Pixeln enthalten. Hier könnte also eine Missile verwendet worden sein.
Zu klären ist nun noch, wieviele Angreifer horizontal nebeneinander auftauchen (können). Ich tippe mal auf zwei oder vier - je nachdem, ob die zweite Farbe ein Missile oder ein Player ist. Bei den Formationen sind es jeweils zwei nebeneinander und einer drüber, wozu dann, siehe oben, einfach einer der Player wiederverwendet wird.

Zu guter Letzt bleibt das Raumschiff des Spielers. Da wir inzwischen alle Players und Missiles verbraucht haben, ist das vermutlich ein Zeichensatzobjekt, das fein horizontal gescrollt wird. Bei Galaxian ist das ja kein Problem weil der Spieler keinerlei vertikale Bewegungsmöglichkeit hat.

[Dr. Irata]

wirklich gut analysiert… somit könnte der Sternenhimmel recht einfach gemacht werden! Ein Missile … der Inhalt rotiert nach unten, die xPositionen werden dann entsprechend in den einzelnen Bildschirmzeilen via DLI verändert

[yMoreT8]

Ich versuche mich gerade in die PM (Player/Missile) einzuarbeiten. Die Wirkungsweise scheint logisch, die PM sind quasi die HW-Sprites des A8. Mir ist es auch nach Durcharbeiten div. Tutorials und Videos gelungen einen super einfachen Player zu programmieren und diesen auf dem Bildschirm hin und her wandern zu lassen. Man hat also 4 Player und 4 Missiles, die unabhängig voneinander gesteuert werden können. Auch deren Z-Ebene ist steuerbar (Priority) und es gibt eine Kollisionserkennung.

Man legt also irgendwo im Speicher fest wo man den Shared-Memory (shared wg. DMA Zugriff vom ANTIC/GTIA) hat der die Grafik enthält. Ein Player ist 256 Bytes groß und belegt damit 8-Bit pro Scanline, welche somit maximal 256 Zeilen umfassen kann, also mehr als darstellbar ist. Die Position in diesem Bytestream legt dann die Y-Position des Sprites fest, sowie seine Größe nach oben/unten. Breiter als 8-Bit (max. 8 Pixel) können die Sprites also nicht sein, außer man nutzt zwei Player aneinander, oder legt die Ausdehnung der Player auf das Doppelte/Vierfache fest. Wie das dann alles mit Farben funktioniert weiß ich auch noch nicht.
Das alles ist auch erstmal komplett unabhängig vom gewählten ANTIC-Modus, da die Sprites wohl vom GTIA erzeugt werden?

So habe ich also einfach mal ein PMBASE eingestellt (übrigens ein Write-Only Register des ANTIC, d.H. man kann den geschriebenen Wert nicht mehr auslesen und muss ihn sich selbst irgendwo merken. Ich habe eine globale Variable namens "pb" im Programm dafür definiert. Keine Ahnung ob man das so macht oder nicht...). Die PMBASE ist ein 8-Bit Register, nimmt also nur das HI-Byte der Speicheradresse auf, somit also eine Page. Das wiederum erklärt warum die PMBASE nur auf Page-Boundary eingestellt werden kann:

Code: Alles auswählen

	; set PM base
	lda #$40
	sta PMBASE	; set page of PMBASE to $40 (equals memory address $4000)
	sta pb			; store page of PMBASE on global variable
	
	
pb	.byte $00

Laut Profibuch kann dieser Speicherbereich 1kb oder 2kb groß sein, je nachdem ob man feine (einfache) Vertikale Auflösung oder die doppelte wählt. Das ergibt sich dann wohl aus dieser Einstellung:

Code: Alles auswählen

	; set single line graphics for PM
	lda #%00111110
	sta SDMCTL

Somit sollte der Speicherbereich PMBASE bis PMBASE + $800 reserviert werden. Der 6502 hat keine Funktionen zum schützen von Speicher (was auch wohl der Grund ist das dort selbstmodifizierender Code funktioniert, mit moderneren CPUs ginge das so nicht.), also muss man selbst dafür sorgen das niemand anderes den PM-Speicher benutzt. Auch ist das erstmal nur eine Reservierung und man muss selbst dafür sorgen das der Speicherbereich initialisiert wird, sonst steht da womöglich irgendwelcher Datenmüll drin, der dann als Grafik interpretiert wird.

Dies habe ich mit einer Memory-Clear Funktion erreicht, welcher die gesamte PM erstmal auf $00 initialisiert. Auch das könnte/würde man sicher anders machen und gleich die Grafiken reinschreiben die man als Player/Missiles haben will?

Dann stelle ich die Priorität für player0, seine Farbe, Breite und X-Position ein:

Code: Alles auswählen

	; set same priority for all players
	lda #$01
	sta GPRIOR
	
	; set color for player 0
	lda #$e4	; = color * 16 + brightness
	sta PCOLR0
	
	; set initial Xpos of player 0
	lda #120
	sta HPOSP0
	
	; set width of player 0
	lda #$00	; 0=normal, 1=double, 3=quadruple
	sta SIZEP0

und zu guter Letzt aktiviere ich das ganze System:

Code: Alles auswählen

	; enable PM
	lda #$03
	sta GRACTL

Das bringt mir dann den player0 auf den Bildschirm und ich kann ihn durch Ändern von HPOSP0 (X-Position) horizontal auf dem Bildschirm verschieben.

Hierzu aber dann gleich einige Fragen und Bitten:
1.) Das verschieben sollte sicher irgendwie mit dem HSYNC/VSYNC synchronisiert werden, oder? Also in einem der dafür bereitgestellten Interrupts.
2.) Welche Maßeinheit hat das HPOSP0? Es ist ja ein Byte, kann also 0-255 haben, aber was bedeutet das für seine Position?
3.) Wie steuere ich die Y-Position des Sprites? Muss ich da die 256 Bytes im jeweiligen Speicherblock des Players rollieren?
4.) Wie kann ich, ganz einfach den Joystick (Tastatur-Emulation im Altirra) abfragen um die X/Y Postion damit zu steuern?

[Dr. Irata]

Hallöle!

zu 1): Du kannst das am besten wohl im VBI machen, dann ist das optimal und ohne ruckeln syncronisiert. Alternativ im Hauptprogramm, dann mit kleiner Wartescheife, die über den Taktzähler gesteuert wird
zu 2): schau mal hier, dazu habe ich einen Post eingestellt. viewtopic.php?f=7&t=715
zu 3): du musst tatsächlich die Bits entsprechend schreiben und löschen. Mein Player ist animiert und im VBI wird ständig mit einem Zähler Daten in den entsprechenden Player eingeschrieben. Die Daten habe ich in einer Tabelle abgelegt. Der Zähler steuert die Geschwindigkeit der Animation und die Reihenfolge. Mein Player hat als erstes und als letztes eine Leerzeile, so stellt man sicher, daß bei der Bewegung immer der obere oder untere Teil gelöscht wird. Kann man anders machen, schien mir aber so am einfachsten. Ich mache sogar 2 Leerzeilen über und unter den Playerdaten frei, das reduziert Fehler. Für die Bewegung des jeweiligen Players definiere ich zwei Variablen für die x- / und y-Position. Mit diesen Variablen rechne ich .
zu 4): Im Profibuch Seite 183 gibt es eine super Routine für die Joystickabfrage. Die packe ich auch immer in den VBI.

[Dr. Irata]

hier die Warteschleife, die CPU-Takt gesteuert ist:

Code: Alles auswählen

		.proc warte0
			
		lda RTCLOK+2
@   
		cmp RTCLOK+2
        	beq @-
        	rts
        	.endp 

[pps]

4.) Einfache Joystickabfrage.
Der ATARI beschreibt im VBI immer das Joystickregister. Also sollte diese Routine einfach regelmäßig aufgerufen werden.

Code: Alles auswählen

	.proc joytest	;ändert x und y Register
	ldy STICK0	;632 -> Schattenregister Joyport 0
	ldx t_joy,y	;im x Register haben wir entweder 0, oder eine Zahl, je nach Richtung
	rts
t_joy
	/*
	1-links
	2-rechts
	3-hoch
	4-runter
	*/
	dta b(0,0,0,0,0,0,0,2,0,0,0,1,0,4,3,0)
	.endp

Nur nach Rechts und Links abfragen, kann man dann auch mit 1 und 255 für Links und Rechts machen. Dann ist einfaches Verzweigen möglich:

Code: Alles auswählen

	jsr joytest
	bmi rechts
	bpl links

3.) y (also die Höhe des Sprites) muss, wie vermutet durch Kopieren innerhalb der 256 (bzw. 128) Bytes des Players/Missiles erfolgen.
2.) hposp0..3 ist die linke Position des 8 Sprite Pixel. Der "normale" Bildschirm beginnt hier bei Position 32 ($20).
1.) Wann Du das Sprite verschiebst, ist Dir überlassen. Man kann dies im VBI oder DLI rehct einfach machen, aber es geht auch direkt im Code außerhalb der Interrupts.

Bei zweizeiliger Auflösung nutzt die PM-Grafik nur je Player und für die Missiles 128 Bytes. Der Beginn nach PMBASE ist dann entsprechend anders.

[Dr. Irata]

... aus Tradition, wegen Übersichtlichkeit und Bequemlichkeit nutze ich nicht selten die mögliche If Then Anweisung bei MADS.
Die einfache If Then Anweisung ist dabei hinsichtlich Schnelligkeit und Codelänge der normalen Codierung gleichwertig, komplexere Dinge kann man auch gut machen, ist aber länger und langsam - das habe ich getestet!

Hier mal ein Beispiel, wie das aufgebaut ist:

Code: Alles auswählen

		#if .byte variable=#1
		.... code ...
		#end
		
		#if .byte variable1=variable2 .and .byte variable3=#12
		... code ...
		... rts / jmp ...  ; man kann hier auch direkt rausspringen
		#end

[Dr. Irata]

Hier meine Joystickroutine:

Code: Alles auswählen

		.proc joystick
		#if .byte stick0=#7		;nach rechts
		jsr rechts
		jmp @+
		#end
		#if .byte stick0=#6		;nach rechts oben
		jsr rechts
		jsr oben
		jmp @+
		#end
		
		#if .byte stick0=#10	;nach links oben
		jsr links
		jsr oben
		jmp @+
		#end
		#if .byte stick0=#11	;nach links
		jsr links
		jmp @+
		#end
		
		#if .byte stick0=#14	;nach oben
		jsr oben
		jmp @+
		#end
		
		#if .byte stick0=#13	;nach unten
		jsr unten
		jmp @+
		#end
		
		#if .byte stick0=#5		;nach rechts unten
		jsr rechts
		jsr unten
		jmp @+
		#end
		
		#if .byte stick0=#9	;nach links unten
		jsr links
		jsr unten
		jmp @+
		#end
		
		
@		
		rts
		.endp

[yMoreT8]

Danke für die vielen tollen Tipps! Ich glaube ich sollte mehr Zeit mit lesen verbringen und experimentieren.
Ich habe nun eine Joystick-Routine programmiert die mein Schiff nach links/und rechts bewegen soll:

Code: Alles auswählen

;----------------------------------------------------------------------
; Move ship using Joystick 0
;----------------------------------------------------------------------
	.proc moveShip
	ldx #0		; use joystick 0
	lda STICK0,x
	tay
	and #%00000100
	bne notLeft
	lda shipPosX
	cmp #$30	; leftmost spritepos (48)
	beq done
	clc
	sbc #1
	sta shipPosX
	sta HPOSP0
	jmp done
notLeft
	tya
	and #%00001000
	bne done
	lda shipPosX
	cmp #$c8	; Rightmost spirtepos (200)
	beq done
	clc
	adc #1
	sta shipPosX
	sta HPOSP0
done
	rts
	.endp moveShip

Die funktioniert grundsätzlich auch, jedoch ist das in Assembler alles so schnell das es faktisch nur links und rechts am Anschlag ist wenn man den Joystick kurz betätigt. Es muss also eine Art Bremse/Geschwindigkeit rein.

Überhaupt komme ich langsam an einen Punkt wo ich mir darüber Gedanken mache wie ich das Timing in einem Spiel steuern kann? Da sollen sich ja parallel mit unterschiedlicher Geschwindigkeit Dinge auf dem Bildschirm bewegen. Delays die einfach nur CPU-Zeit fressen sind ohnehin immer verpönt, also muss man eine Art real-time Ebene bauen. Ich stelle mir so eine Crontab vor in der ich angeben kann welche Routinen in welchen Zeitabständen aufgerufen werden. Diese Abstände geben dann die Geschwindigkeitsverhältnisse untereinander vor.

[Dr. Irata]

... entweder in den VBI stecken oder nimm die kleine Bremse, die ich dir gepostet habe

[yMoreT8]

... entweder in den VBI stecken oder nimm die kleine Bremse, die ich dir gepostet habe

Dazu ein paar Fragen. RTCLOK+2 ist ja das niederwertigste Byte des Registers. Das wird bei jedem VSYNC um 1 erhöht, also alle 1/50 Sekunden bzw. 20ms. Du machst im Code

Code: Alles auswählen

	lda RTCLOK+2
@	cmp RTCLOK+2
	beq @-

Du lädst den aktuellen Wert des Byte in den Akku und vergleichst dann den Akku wieder mit dem Wert. Ich nehme mal an das die CPU sehr viel schneller Code ausführt als sich der Wert in RTCLOK+2 ändert, also loopt das solange bis ein VSYNC kommt, richtig? Also entspricht dies einem Delay von 20ms. Und dann verstehe ich auch das eine Ausführung im VBI (Vertical-Blank-Interrupt) dasselbe bewirkt.

[Dr. Irata]

genau

[yMoreT8]

Prima, die X-Bewegung läuft nun mit Joystick und auch recht geschmeidig mit den 20ms Delay.
Ach, hat jemand eigentlich eine Erklärung dafür das der Scroll nach links fast doppelt so schnell läuft wie der Scroll nach rechts?

[DjayBee]

Ich nehme mal an das die CPU sehr viel schneller Code ausführt als sich der Wert in RTCLOK+2 ändert, also loopt das solange bis ein VSYNC kommt, richtig?
Also entspricht dies einem Delay von 20ms.

Mit dieser Methode verbrennst du halt extrem viel CPU Zeit, die du evtl. an anderer Stelle brauchen könntest.

Und dann verstehe ich auch das eine Ausführung im VBI (Vertical-Blank-Interrupt) dasselbe bewirkt.

Das ist aus obigem Grund die elegantere Lösung - so lange du im VBI genug Zyklen dafür übrig hast.

Alternative 1:
Im VBI nur die neue Position berechnen und sie in einer Speicherstelle ablegen.
Dein Hauptprogramm liest dann nur noch bei jedem Schleifen- bzw. Dispatcherdurchlauf diese Stelle aus und positioniert das Objekt entsprechend. Das kann ohne "Bremse" auch ein paar tausend Mal nacheinander passieren, ändert aber nichts weil bis zum nächsten VBI immer dieselbe Position angesteuert wird.

Alternative 2:
Im Hauptprogramm nicht die Zeit verbrennen, sondern einfach immer nur dann etwas tun, wenn es sinnvoll ist. Das kann dann ggf. auch nur jeden zweiten oder hundersten VBI aktiviert werden.

Code: Alles auswählen

	lda RTCLOK+2
	cmp saveRTCLOK
	beq NixZuTun

	sta saveRTCLOK
	
	; den Joystick abfragen oder was auch immer

NixZuTun

[Dr. Irata]

ganz genau weiß ich es nicht, auf jeden Fal musst du vor der Subtraktion (sbc) statt clc sec nehmen!

[pps]

So sollte es gehen - etwas kürzer und schneller - auch wenn schneller jetzt hier nicht nötig ist, aber wenn man später viel machen möchte ist jedes Häppchen wichtig.

Code: Alles auswählen

;----------------------------------------------------------------------
; Move ship using Joystick 0
;----------------------------------------------------------------------
	.proc moveShip
	lda STICK0
	tax
	and #%00000100
	bne notLeft
	ldy shipPosX
	cpy #$30	; leftmost spritepos (48)
	beq done
	dey
	sty shipPosX
	sty HPOSP0
	rts
notLeft
	txa
	and #%00001000
	bne done
	ldy shipPosX
	cpy #$c8	; Rightmost spirtepos (200)
	beq done
	iny
	sty shipPosX
	sty HPOSP0
done
	rts
	.endp moveShip

[yMoreT8]

ganz genau weiß ich es nicht, auf jeden Fal musst du vor der Subtraktion (sbc) statt clc sec nehmen!

AAARGH , ja, Du hast Recht, das war der Fehler! Danke!

Jetzt habe ich die Move-Routine in eine VBI gebaut. Den VBI löse ich in der DLIST im letzten JMP mit aus:

Code: Alles auswählen

dl_ant4  = 4 ; ANTIC mode 4 (TEXT, 40x24)
dl_blank = %01110000 ; 8 blank lines in background-color
dl_jmp   = %00000001 ; JMP
dl_vbi   = %01000000 ; VBI
dl_lms   = %01000000 ;

dlist	.byte dl_blank, dl_blank, dl_blank ; 24 blank scanlines on top
	.byte dl_lms | dl_ant4, <screen, >screen
:23	.byte dl_ant4
	.byte dl_jmp | dl_vbi, <dlist, >dlist

Den Vektor dazu programmiere ich im INIT meines Spiels als immediate (ich mache ja kein kritisches IO):

Code: Alles auswählen

	lda #6	;6=immediate, 7=deferred VBI
	ldx #>VBROUT
	ldy #<VBROUT
	jsr SETVBV

Die VBROUT (den Namen habe ich einfach mal aus dem Atari-Buch übernommen) sieht dann so aus:

Code: Alles auswählen

	.proc VBROUT
	jsr moveShip
	jmp SYSVBV
	.endp VBROUT

Die "moveShip" Subroutine macht dann die Joystickabfrage und Schiffsbewegungen, wenn nötig. Da der VBI ja nur alle 20ms beim VBLANK aufgerufen wird ist die Bewegung automatisch langsamer und zwar ohne CPU Zeit zu verbrennen. Wenn ich die Bewegung des Schiffes nicht mit ADC #1/SBC #1 mache sondern #2 oder #3, variiere ich die Geschwindigkeit. Das könnte später nochmal interessant werden um dem Spiel mehr Dynamik zu verleihen. Auch cool wäre eine Animation dabei (Schiff dreht sich leicht in die Bewegungsrichtung und zurück), sowie ein langsames anfahren und absenken der Bewegungsgeschwindigkeit. Das übersteigt aber gerade noch meine Möglichkeiten, führt mich aber wieder zu meinem o.g. Problem des Schedulers/Dispatchers und vermutlich Fließkomma-Arithmetik um sowas ordentlich zu berechnen, bzw. Daten-Tabellen in denen das vorberechnet wird. Aber das mache ich dann mal später...

Ich frage mich nur ob ich im INT-Handler nicht besser die NMIs ab und später wieder anschalten sollte? Bin mir noch nicht ganz sicher über die vielen Arten einen INT auszulösen und einen Handler dazu zu schreiben. Man müsste den VBI-Code, der sicher im laufe der Zeit wachsen wird, profilen um sicher zu stellen das dieser unter den maximal möglichen 4500 CPU-Taktzyklen bleibt die als Zeit zur Verfügung stehen?

Den Grundaufbau im Spiel sehe ich inzwischen in diese Blöcke unterteilt:
1.) Initialisierung und Defaults
2.) Main-Loop (Menüs/Highscore)
3.) VBI: Grafik aufbauen und bewegen. Kollisionserkennung, Spiellogik
4.) DLI: ? Weiss noch nicht was ich da machen soll/kann, vermutlich Farben ändern? Oder Scrolling?

Achja, Musik und Soundeffekte muss ich ja auch noch irgendwo mit einbauen.

[Dr. Irata]

Guten Morgen... viele Fragen, die Antworten werden sich erst mit der Zeit erschließen.
Hier im Forum gibt es ein paar richtig erfahrene Hasen, die für sich genau den richtigen Weg gefunden haben, wie man was macht beim A8 - jeder scheint da aber einen etwas anderen Stil zu entwickeln.
Grundsätzlich kann man ganz viel machen bei der kleinen Kiste - hätte ich übrigens am Anfang gar nicht so gedacht. Es gibt Limitationen, einige kann man etwas aushebeln, andere nicht.

Thema VBI: Ich habe am Anfang sehr viel Code in den VBI gepackt, dummerweise macht das dann irgendwann Probleme, wenn man ein Spiel für NTSC und PAL laufen lassen will. Mittlerweile versuche ich den Code dort möglichst schlank zu halten. Den VBI rufe ich am Anfang in der Initialisierungsphase auf und habe dann entsprechend eine eigene Proc für den VBI.
Thema DLI: Wo fängt man an??? Wenn du mit DLI´s arbeitest, musst du dir vorher genau überlegen, was du damit machen möchtest und wie du entsprechend die DL aufbaust. Ja, man kann dort sehr schön die Farben der einzelnen Zeilen ändern, man kann damit auch Multicolorsprites machen, ich steuer die Hintergrundmusik mit einem DLI... usw..

Thema CPU: Am Ende ist es fast egal wie und wo du was machst, die CPU hat eine begrenzte Kapazität / Rechenpower. Wenn weg dann weg. Ob du das im VBI verbrätst oder im Hauptprogramm ist fast egal. Die Befehle zB im VBI müssen abgearbeitet werden und das kostet Rechenpower. Im VBI macht man eigentlich immer die Aktionen, die kritisch für den Bildaufbau sind / Thema Vermeidung von flackern - oder so Sachen, die ständig kontinuierlich abgefragt werden müssen (Joystick) oder wo die Bewegung glatt laufen muss (Player).

Wozu brauchst du Fließkomma???

[yMoreT8]

So, ich habe die Joystick-Routine noch etwas angepasst, sodass man auch kombinierte Movements erkennt, also Links-Hoch, Rechts-Runter usw.
Dann habe ich ein vertikales Scrolling in Form eines Byte-Roll im PM-Player RAM gebaut, sodass ich mein Schiff auch vertikal bewegen kann. Hier müssten wir nochmal gemeinsam schauen ob ich das so richtig mache oder ob es dazu HW-Methoden gibt dies das vertikale Scrolling vereinfachen?

Am Ende habe ich nun mal ein Video erstellt als Demo wo ich derzeit stehe. Als "Sterne" habe ich einfach im ANTIC 4 den Bildschirm voll mit "." ASCII-Zeichen gemacht, das dient nur der Simulation. Im Video zeige ich wie ich mein Schiff schön smooth in alle Richtungen, auch vertikal bewegen kann.

Das mag für die Profis hier nur gäähn/laaangweilig erscheinen, aber für mich persönlich ist das schon ein riesiger Meilenstein

[Dr. Irata]

leider kann ich mit Mac keine AVI abspielen

[Dr. Irata]

hier mal ein kleines Beispiel meiner Schiffsanimation meines aktuelle Projektes...

IMG_7712.MOV

(1.45 MiB) 16-mal heruntergeladen

[Olix]

Also du legst ja wirklich ein beeindruckendes Tempo in deiner Lernkurve vor. Hut ab.

Wenn du so weiter machst könnte da schon ein neuer Beitrag für den nächsten ABBUC Software Wettbewerb entstehen.

Weiter so !

[Dr. Irata]

... das sehe ich genauso!! Noch ist genügend Zeit, allerdings ist Galaxian schon eine echte Herausvorderung!!