Future BASIC II 68K Mac-Versuche

  • Halli hallo :)


    Da ich momentan etwas mit Future BASIC II am 68k Mac experimentiere, bin ich auf ein kleines Problem gestossen: Wenn ein Fenster, welches mein Programm verwendet, überlappt wird, scheint das Refresh-Event irgendwie nicht immer zu reagieren. Beispiel: Ich lasse mir im Fenster ein Bild aus einer Ressource anzeigen - sobald das Refresh-Event auftritt, lasse ich das Bild einfach neu anzeigen.


    Wenn ich jetzt im Finder ein Laufwerk öffne und dieses Fenster dann über mein Programm-Window bewege, dann arbeitet der Refresh mal, und mal nicht. Hat jemand schon einmal mit FB II gearbeitet und hat einen Rat?

  • Ich kram diesen alten Beitrag einfach mal raus. Ich arbeite z. Zt. doch einmal an einem kleinen Game für den 68k-Mac. Es wird wohl auf eine Sokoban-Umsetzung hinauslaufen. Für die ersten Versuche reicht das erst einmal.


    Meine Ziele:
    - s/w Support (to do)
    - 16 col Support (to do)
    - 256 col Support (done)
    - System 6+7+8 (7+8 scheint es schonmal zu laufen)
    - 68000+
    - 100 Levels


    Einziger Schwachpunkt: Ich kriege das Window-Refresh nicht hin - also wenn ein anderes Programm "mein" Fenster überdeckt und dann verschoben wird, dann wird das Spielfeld nicht mehr gezeichnet - offenbar gibt es da mehr als ein Event, das dafür zuständig ist. Deswegen habe ich aus dem Fenster einfach einen Dialog "gestrickt". Das heißt zwar, man kann nur spielen oder eben das Programm beenden, aber immerhin kann so nichts mehr dazwischen funken :D


    Ich halte euch mal auf dem Laufenden :)

  • Ich glaube ich habe das Problem mit dem Window-Refresh gelöst. Aber ich lasse das Programm jetzt (erstmal) so wie es ist. Es ist nur möglich, dass ich die Grafik nochmal neu zeichne, da in 640x480 eigentlich fast zu klein (würde wohl eher was für 512x384 sein). Bei der GOS/286-Version (ebenfalls 640x480) habe ich die Grafik gleich groß gezeichnet und da sieht das irgendwie größer aus.... oder ich werde blind :grübel:

  • Gerne, sobald ich die neuen Grafiken eingebaut habe. Die sind jetzt wesentlich größer und besser erkennbar :) Im Laufe des Wochenendes - versprochen.

  • Ok, also die neuen Grafiken konnte ich nicht einbauen.... da habe ich mich vor lauter Motivation mit der Auflösung verrechnet. :motz::fp: Dafür habe ich jetzt das Programm nochmal umgestaltet. Nachher mache ich mal Screenshots. Leider ist der Aufbau des Spielfeldes extrem langsam - hier muss ich mir noch was einfallen lassen. Das erinnert mich an VB unter Windows 3.1 :D

  • Der Levelaufbau geht jetzt schneller. Dafür gibt's aber noch keinen Screenshot... Irgendwie ist meine SD-Karte weg, also habe ich die Screenshots vom LC III zum PPC via LocalTalk kopiert, dann auf eine (Mac-) CD gebrannt und.... genau, weder HFSExplorer noch MacDisk können mit der CD was anfangen - unter "Volume Info" werden zwar die File-Anzahl usw. angezeigt (wenn ich den B-Tree als Text speichere, sehe ich da auch alles), aber dennoch befinden sich angeblich 0 Files im Root. Der Mac wiederum findet alles korrekt... :huh:

  • Der würde es tatsächlich können - aber nur, wenn man bezahlt. Das tue ich aber nicht, da ich das Programm - außer für diesen einen Fall - nicht brauche ;)
    Ich lass mir was anderes einfallen.

  • So, hier die erste Version im Anhang als ZIP (gepackt am Mac).
    Das Spiel wurde getestet am LC III (System 7.5), LC I (System 7.0.1) und 6100-66 (OS 8).


    Folgende Hinweise:
    - Bei unter 16 Farben wird zur s/w-Grafik gewechselt,
    - bei 16 Farben zur 16-Farb-Grafik,
    - bei 256 Farben zur 256-Farb-Grafik,
    - bei allen anderen Modi wird auf s/w-Grafik zurück geschaltet


    Im nächsten Schritt wird das Programm noch weiter optimiert, um es schneller zu machen. Sobald ich die Assembler-Inline-Möglichkeit voll durchschaut habe, setze ich alle zeitkritischen Routinen in 68000-Assembler um. Ebenfalls könnte man ja weitere Level-Files erstellen bzw. einen Level-Editor. Mal schauen :)

  • Das ist ja komisch - zumindest wenn ich das ZIP von einem Mac zum anderen transportiere, gehts. :grübel:
    Ich dachte ein ZIP ist sicher wenn es in Richtung PC geht :(
    Hast Du mal MacZIP probiert? Gibts im Obstgarten und ist Shareware. Das habe ich zum Packen genommen. Ansonsten probiere ich heute mal eine andere Variante und nehme MacRAR oder so :) Wollte sowieso noch ein kleines Update machen.

  • So, die nächste Version wird nun (endlich) an einigen Stellen mit Maschinensprache optimiert. Wer sich ebenfalls für FBII interessiert und wissen möchte, wie man Assembler-code direkt (nicht als Inline) einfügt, der finde hier ein Beispiel:


    DIM S&(5000) : REM 5001 Felder (Long, 32 Bit) dimensionieren.


    REM Alle 5001 Felder löschen - schneller als mit FOR...NEXT
    REGISTER(A0)=VARPTR(S&(0))
    ` move.l #5000,d0
    `schleife:
    ` clr.l (a0)+
    ` dbra d0,schleife


    Natürlich kann man z. B. mit E&=REGISTER(xx) auch wieder ein Register auslesen lassen.


    Falls jemand wissen möchte, wie ein String im Speicher liegt: Byte 0 ist die Länge, danach folgt der eigentliche String.


    Ich habe einmal ein obiges Array genullt und im letzten Feld eine bestimmte Zahl hinterlegt. Anschließend habe ich diese Zahl suchen lassen - einmal mit FOR...IF...NEXT und das andere mal mit 68k-Assembler. Die Unterschiede sind fantastisch! :thumbup:


    Schade, dass hierzu keinerlei Info in der guten Hilfe zu finden ist. Deswegen war das einiges an Gefrickel (und Abstürzerei), vorallem bis ich das mit den Labels herausgefunden habe :D

  • Von Programmierung habe ich keinerlei Ahnung (ja, etwas vergessenes Pascal in der Schule - damals...), aber ich frage mich, ob Du Deine Rechner vernetzen könntest, um die Daten auszutauschen. FTP solltest Du mit allen hinbekommen. Kein Netzwerk zu haben, stelle ich mir unpraktisch vor. ;)

  • Die Macs hänge ich zur Not mit LocalTalk/AppleTalk zusammen. PC habe ich keinen - da transportiere ich die Daten wie z. B. oben beschrieben zum PC mit Internetzugang.