atari-home.de - Foren
Software => Coding => Thema gestartet von: guest3744 am Di 08.09.2015, 11:55:51
-
Hallo, guten Tag.
Ich bin hier neu mit 67 Jahren und spiele seit kurzem mit dem MIST und dem Atari-ST-Core.
Meinen letzten ST hatte ich 1987....wurde dann wegen einem anderen (PC) verkauft.
Da ein FPGA einem Emulator überlegen ist wollte ich jetzt mit dem MIST die ST-Zeiten wiederholen.
Es ist schön damit zu spielen. Die Versuche mache ich jetzt aber auch nebenher mit dem STEEM, den ich neben dem MIST laufen habe.
Auch den Atari800 habe ich auf dem MIST laufen...steht dem Original nicht nach, da auch nebenher den Altirra-Emulator für schelle Testläufe von erstellten Programmen.
Ich spiele mit dem GFA-Basic 3.6. Dieses funktioniert wunderbar auch mit dem Compiler auf beiden Systemen fehlerfrei. Das freut mich umso mehr. Mein ST-Screen ist der SW-Hochauflösende.
- Wie kann ich mit dem GFA-Basic 2 Screens verwalten, auf dem 2. unsichtbar zeichnen während der 1. Screen sichtbar ist und dann umschalten auf sichtbar ?
- gibt es eine Assembler mit dem ich ST-ASM-Code compilieren kann auf dem PC als PRG und dann auf den ST laufen lassen ?
- Wo gibt es bitte eine deutsche Beschreibung als PDF für das GFA-Basic ?
Danke.
Gruss
-
Zur ersten Frage: Das ist aber nicht gerade saubere Programmierung... Das Programm läuft dann nur auf dem ST in Monochrom. Wer einen TT hat, muss den erst in ST-Hoch booten. Das macht keinen Spaß. Und wer eine Grafikkarte hat, hat völlig in die Röhre gebissen. Besser wäre es, gleich sauber zu programmieren und die GEM-Funktionen (VDI) zu verwenden. Es gab da ein schönes Buch im Hüthig-Verlag: "Vom Anfänger zum GEM-Profi", das ist für die Grafikprogrammierung unter GEM sehr zu empfehlen.
Was du vor hast, nennt sich "Verdeckt aufbauen". Sauber ist das nicht, aber irgendwo gabs mal Beispiel-Routinen dafür für GFA-Basic vom Autor von Sparrow-Text. (Deswegen läuft Sparrow-Text auf dem TT in anderen Auflösungen als ST-Hoch auch nicht. :( )
-
"Verdeckt aufbauen".
Das macht man um eine Flimmerfreie Bewegung zu erzeugen, umschalten zwischen 2 Screens.
Beim Atari800 klappt es ganz gut.
Gibt es so etwas in "GEM-Funktionen (VDI)" , die kann man ja auch in GFA-Basic benutzen.
Gruss
-
Du meinst sowas ...
'
' 2 Bildschirmbuffer anlegen
bild1%=MALLOC(32512) AND &HFF
bild2%=MALLOC(32512) AND &HFF
'
' Vertikalen Sync abwarten
VSYNC
'
' Bildschirm 1 sichtbar schalten (physbase). Auf Bild2 kann gemalt werden (logbase).
~XBIOS(5,VARPTR(bild2%),VARPTR(bild1%),-1)
'
DEFFILL 1,1,1
PBOX 20,20,200,200 !Eine kleine Box reinmalen
PAUSE 100 ! 2 Sekunden warten
'
VSYNC
~XBIOS(5,VARPTR(bild1%),VARPTR(bild2%),-1)
' Nun ist Bild 2 sichtbar (die eben gemalte box) und auf Bild 1 kann gemalt werden.
-
Hallo, danke für die Info.
Ich habe jetzt das Programm als LST in GFA-Basic 3.6 geladen.
Das schwarze Viereck ist sofort da..., eigentlich doch erst nach 2 Sekunden?
Habe getestet mit dem HATARI-EMU und auf dem MIST:
Danke.
Gruss
-
@laufkopf: Ja, so kann man das machen. Aber die Routine von J.Spatz war schöner. Zwei Prozeduren, eine um den verdeckten Screen einzurichten, eine zum umschalten, kann man aus deiner Befehlsfolge aber leicht ableiten. Optional nutzte die Routine auch noch Bitblit, um den Inhalt von Bild 1 nach Bild 2 zu kopieren, bevor man anfängt in Bild 2 zu malen. Sonst muss man ja in Bild 2 estmal alles von vorne malen, wenn man nur was ergänzen wollte. Was ich an deinem Code nicht verstehe, warum dann noch 2 Sekunden warten?
-
warum dann noch 2 Sekunden warten?
Ist wohl als Demo gedacht, nach 2 Sekunden wird der Screen erst sichtbar gemacht.
Darum fiel mir auf , das dieses Rechteck sofort beim starten des Programmes da war,
was nicht sein soll gemäß der Demo.
Gruss
-
Wo gibt es bitte die Routine :
Aber die Routine von J.Spatz war schöner.
Danke.
Gruss
-
vielleicht sind die gfa-eigenen routinen auch nicht so empfehlenswert. Oder erst eine eigene virtuelle vdi-workstation öffnen und nicht die gfa-eigene benutzen? Ich habe keinen ST zur Hand um das mal zu testen.
-
Hi 1ST1,
Zur ersten Frage: Das ist aber nicht gerade saubere Programmierung...
...Besser wäre es, gleich sauber zu programmieren und die GEM-Funktionen (VDI) zu verwenden.
Das VDI bietet aber keine Möglichkeit, zwischen "Bildschirmen" umzuschalten. Du könntest mit den VDI Copy Funktionen ein Fenster aktualisieren. Aber dann müßtest du zuerst eine Bitmap im Geräteunabhängigen Format aufbauen, ins Geräteabhängige transformieren und dann in das Fenster kopieren. Das kostet Zeit ist wahrscheinlich je nach Maschine als Flimmern sichtbar. Bei Spielen, die einen schnellen Bildaufbau benötigen, wird deshalb der Bildschirm auf einen anderen Grafispeicher umgeschaltet, wenn der fertig aufgebaut ist.
Tschüß
Michael
-
Das Umschalten zwischen zwei Bildschirmen ist nicht unbedingt "unsaubere Programmierung". Schließlich kriegt man das ganz und gar mit hochoffiziell dokumentierten XBIOS-Betriebssystemroutinen (Setscreen()) hin.
Das läuft auch in allen Auflösungen, wenn man sauber mit den passenden Grafikroutinen arbeitet. Siehe PD (Debugger von Pure-C), der verwaltet je einen eigenen Schirm für den Debugger und das zu debuggende Programm und läuft auch auf Grafikkarten (zumindest in der letzten Version).
-
Wo gibt es bitte die Routine :
Habe mal aufr meiner Platte gesucht, finde sie aber nicht.
-
Pageflip habe ich gefunden in GFA-Basic.
Es ist schon sehr schnell, wie die Page wechseln.
Ist aber noch nicht was ich suche.
' GFA BASIC Page-flipping Demonstration
' DIMension string array to hold screen images
Dim Screen$(1)
' Draw first screen
Cls
Circle 100, 110, 100
Deffill 1, 2, 9
Fill 100, 100
For J = 1 To 5
Print
Next J
Print Tab(4);"This is page one"
' Save image in Screen$(0)
Sget Screen$(0)
' Draw second screen
Cls
Print
Print Tab(4);"This is page two."
Box 5, 5, 300, 40
Deffill 1, 2, 16
Fill 100, 100
' Save image in Screen$(1)
Sget Screen$(1)
' Flip screens 50 times
For J = 1 To 50
Flip
Next J
' Flip at your leisure
X = 1
While X
Flip
Waitkey
If Key$ = Chr$(27) Then
X = 0
Endif
Wend
Edit
'
Procedure Flip
' Exchange these variables
Swap Screen$(0), Screen$(1)
' Display Screen$(0)
Sput Screen$(0)
Return
'
Procedure Waitkey
Key$ = ""
While Key$ = ""
Key$ = Inkey$
Wend
Return
-
'
orig%=XBIOS(2)
'
DIM s1|(32512)
DIM s2|(32512)
bild1%=V:s1|(0)+255 AND &HFFFFFF00
bild2%=V:s2|(0)+255 AND &HFFFFFF00
'
beschl&=3
geschw&=2
fahrt&=beschl&
x&=2
'
WHILE x&<620
VSYNC
~XBIOS(5,L:bild1%,L:bild2%,-1)
'
DEFFILL 0,1,1
PBOX x&-(2*geschw&),20,x&-(2*geschw&)+22,40
'
DEFFILL 1,1,1
PBOX x&,20,x&+20,40
x&=x&+geschw&
'
VSYNC
~XBIOS(5,L:bild2%,L:bild1%,-1)
'
DEFFILL 0,1,1
PBOX x&-(2*geschw&),20,x&-(2*geschw&)+22,40
'
DEFFILL 1,1,1
PBOX x&,20,x&+20,40
x&=x&+geschw&
'
DEC fahrt&
IF fahrt&=0
INC geschw&
fahrt&=beschl&
ENDIF
WEND
PAUSE 100
'
~XBIOS(5,L:orig%,L:orig%,-1)
'
EDIT
-
Hallo, guten Tag.
Danke für dein Demo mit dem 2 Screen..
Das läuft ja wirklich schnell im Interpreter und ist ohne flimmern
Wenn ich es Kompiliere, dann ist das Rechteck kaum zu sehen. Wo muss da jetzt bitte Vsync gesetzt werden ? Oder wo muss bitte etwas geändert werden , damit das Rechteck zu sehen ist, wenn die Geschwindigkeit so bleiben soll ?
Danke.
Gruss
-
Die VSYNC immer vor Screenwechsel einsetzen.
Ich habe selbst nur mit NoSTalgia getestet und da ist es deutlich, auch kompiliert, zu sehen.
Ich häng mein prg mal unten an. Einfach untitled.prg.pdf nach untitled.prg umbenennen.
-
hier noch n kurzer quicktime film (wieder pdf am ende entfernen)
-
Hallo, danke.
Habe die Bewegungswerte als Float genommen , jetzt ist es zu sehen auf dem MIST und STEEM.
Die Integerwerte sind wohl doch zu schnell wenn es compiliert wird.
Gruss
-
oder ne kleine wartepause vor dem umschalten einfügen. zb pause 5 oder so
-
Hallo, guten Tag.
Ich möchte bitte einmal die Screenanfangadresse herausfinden um sie für mich zu manipulieren.
Wie bekomme ich die bitte raus mit GFA-Basic?
Danke
Gruss
-
Physbase() (XBIOS(2))
-
Danke für den HInweiss.
Gruss
-
Beim direkten schreiben in den Bildschirm vielleicht vorher noch in den Supervisor wechseln.