Das deutsche QBasic- und FreeBASIC-Forum

[James1337]

Hallo QB Profis

Ich arbeite zur Zeit mit Fraktalen und habe dazu auch schon einiges an Code gefunden.
Das Problem ist allerdings, dass ich gar kein QBASIC-Programmierer bin
und mich erst seit heute mit dieser Sprache beschäftige.

Mittlerweile verstehe ich das Programm so weit, dass ich weis, an welche Speicheradressen es welche Werte schreibt.
Jedoch wäre es hilfreich, wenn jemand hier weis, wie QBASIC das intern verarbeitet,
sodass man diese Adressen irgendwie in Koordinaten umwandeln kann.
Denn dann könnte ich zum Beispiel die Funktion SetPixel aus GDI verwenden.

Schon mal danke im Voraus.
MfG, James

[Sebastian]

Hi James,

willkommen im Forum!

[James1337]

Tut mir leid, falls ich mich ungenau ausgedrückt habe.
Das Fraktal schreibt mit POKE (soweit ich diesen Befehl richtig verstanden habe) bestimmte Werte an bestimmte Adressen. Es geht mir nur darum, aus diesen Daten irgendwie die Koordinaten zu berechnen, an denen QBASIC dann letzten Endes zeichnet. Diese Umrechnung brauche ich, um den Code von QB in eine andere Sprache zu portieren, ich will also nicht GDI-Funktionen aus QB aufrufen.

Trotzdem danke für die schnelle Antwort.

[nemored]

Ohne Garantie auf Verwendbarkeit:
http://www.freebasic-portal.de/befehlsreferenz/interne-pixelformate-464.html erklärt ziemlich weit unten glaube ich auch das QB-Grafikpufferformat.
("Version 1 (veraltet)"; müsste identisch mit QB sein)
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Jojo]

Der Grafikspeicher ist linear Zeile für Zeile aufgebaut, d.h. um einen Pixel zu setzen läuft das über POKE y * bildschirmbreite + x, farbe, bzw um die Koordinate zurückzurechnen: y = adresse \ bildschirmbreite, x = adresse mod bildschirmbreite. Im SCREEN 13 wäre die bildschirmbreite z.B. 320.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[James1337]

@nemored, Jojo
Vielen Dank, das werde ich gleich mal versuchen.

[St_W]

Für die meisten Grafik-Modi findest du den Grafikspeicher and Offset &HA000 im Speicher gemappt.

Für Screen 13 wäre das z.B. dann:

[dreael]

Warum ist Windows unter anderem so erfolgreich geworden? Weil Treiber hardwarespezifische Details der Grafikkarte (beim Drucker, Soundkarte, Netzwerkkarte usw. genauso!) gegenüber der Anwendersoftware "verbergen" d.h. sinnvoll abstrahieren, so dass der Anwendungsprogrammierer auf einheitliche APIs zurückgreifen kann. FreeBasic profitiert logischerweise auch von dieser Abstrahierung, daher funktionieren SCREEN-Fähigkeiten auf jedem PC unabhängig, ob eine Grafikkarte von ATI, Nvidia oder sonst einem Hersteller drin läuft. Es muss lediglich der passende Grafiktreiber (Windows) bzw. X11-Server (Linux) installiert sein.

QBasic stammt dagegen noch aus einer Zeit vor dieser Abstrahierung mit Treibern, wie im MS-DOS-Zeitalter typisch. Damals war es beispielsweise üblich, dass Grafikkarten-Hersteller spezielle Treiber für Mainstream-Anwendungen wie AutoCAD, MS Word 5.0 usw. mitgeliefert hatten, weil die Anwendungsprogrammierer direkt auf die Hardware zurückgreifen mussten.

Zwar stellten die Grafikbefehle in QB und SCREEN an und für sich auch schon eine recht gute Abstrahierung der Grafikkarte dar, denn PSET, LINE, CIRCLE usw. sparten auf jeden Fall direktes Herumhantieren mit POKE wie seinerzeit beim Commodore 64 üblich. Ansonsten die direkt in Intel 8088-Assembler geschriebenen Programme arbeiteten natürlich wie auf dem C 64 und verwendeten das BIOS höchsten für den gewünschten Vidoemodus aktivieren, POKEten aber ihre Bitmap-Daten direkt in die Videokarte hinein (Pixel setzen und lesen sind im BIOS das Höchste der Gefüge). Der VESA-Standard versuchte dies übrigens für alle SuperVGA-Videomodi zu vereinheitlichen (Artikel), was aber aufgrund fehlerhafter VESA-BIOS-Implementierungen mehr schlecht als recht funktioniert hat.

Zum Fraktalprogramm zurück: Zum einen von mir ein paar Beispiele:

http://www.dreael.ch/Deutsch/Download/Apfelmaennchen.html

Ansonsten ist dies ein typischer Fall, einen alten (Legacy) Code in eine aktuelle Form zu bringen. Um Dir besser helfen zu können am besten diesen alten Code einmal hier ins Forum posten.
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[minx]

Guten tag!

Ich bin minx, und arbeite mit James an dem Projekt. Es ist nicht so, dass ich/wir uns mit dieser "veralteten" Sprache auseinander setzen wollen, wir wollen nur ein Programm in den (mächtigen) BASIC-Dialekt AutoIt (autoit.de) zu portieren.

Also wir haben ein Fenster, welches wie das BASIC Programm 320x240px groß ist. Die Zeichenfunktion mit dem Port von POKE ist jetzt schon umgesetzt, allerdings fehlt die Farbberechnung. Denn bei uns sind die Farbwerte anders formatiert (z.B. 0xFFFFFF).

Nun wird von dem orig. Programm die Farbe mit PALETTE gesetzt. Unbrauchbar, denn bei uns steht die Farbe einfach in einer Variable, z.B. "$Color".

Im Original:

[James1337]

Auch danke dafür St_W. Wir verwenden (zum Glück) SCREEN 13.
Es ist ja nett, dass ihr mit alle FreeBASIC ans Herz legt, aber (leider) ist der Code den wir portieren wollen mit QBASIC geschrieben, also kann ich da leider nicht viel machen.

Ich konnte durch eure Hilfe zumindest schon mal die POKE-Funktion in meine UDF implementieren.

Der Code sieht übrigens wie folgt aus (wobei uns Zeile 6 momentan noch Sorgen bereitet):

[dreael]

Ohne viel Kommentar:

http://beilagen.dreael.ch/QB/JAMES2.BAS

d.h. der POKE lässt sich durch ein PSET ziemlich problemlos eliminieren. Animationseffekt (hat allerdings nichts mit der Mandelbrotmenge zu tun!) läuft auch mit PSET eigentlich von der Performance her ohne Probleme (Test auf Pentium III/1 GHz mit QBasic 1.1 von MS-DOS 6.22).
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[St_W]

FreeBasic bietet ja eh einen QBASIC Kompatibilätsmodus, mit dem der meiste Code 1:1 übernommen werden kann. Problematisch ist nur hardwarenaher Code (wie z.B. der direkte zugriff auf den Grafikspeicher mit POKE, wie gerade eben besprochen), der geändert werden muss. In FreeBASIC kann man das jedoch in ähnlich einfacher weise mit direktem Speicherzugriff lösen oder mittels PSET, das um vielfache schneller ist als in QB.

Was ich eigentlich sagen wollte: Es empfiehlt sich - soweit ich weiß - ein

[James1337]

Danke, aber da ich POKE mittlerweile sowieso schon implementiert habe (und glaube, dass die Angaben von Jojo stimmen),
besteht für mich kein Grund es durch PSET zu ersetzen.
Und selbst wenn doch, da wir jetzt beide Funktionen verwenden könen, ist das egal.

Das Problem ist vielmehr die Funktionsweise/Portierung von PALETTE.

MfG, James

[St_W]

Ich hoffe ich bin nicht zu aufdringlich, aber PALETTE gibts genauso unter FreeBASIC

Edit: Sorry, hab beim überfliegen des Threads offenbar das eigentliche Vorhaben (AutoIt) überlesen.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken)

[Jojo]

PALETTE weist jeder der 256 indizierten farben (0-255) einen RGB-Wert zu - ganz ähnlich den 32-Bit-Farbcodes, die du bereits kennst. Allerdings ist die Präzision dafür in QB wesentlich niedriger - 6 bit pro Farbkanal statt 8.
PALETTE x, y weißt dann dem Paletteneintrag x den echten Farbwert y zu. Diesen müsste man so zurückrechnen können:
R = y mod 64 ' R-Anteil als Zahl zwischen 0 und 63
G = (y \ 256) mod 64 ' G-Anteil (dito)
B = (y \ 65536) mod 64 ' B-Anteil (dito)

256 und 65536 ist keine Tippfehler - denn die Farbanteile werden tatsächlich byteweise gespeichert, d.h. "zwischendrin" gibt es viele "nicht existierende" Farbcodes (64 ist z.B. kein zulässiger Farbcode).

St_W: Inzwischen sollte doch klar sein, dass er nicht mit FB arbeitet, oder? Und in FB (zumindest unter -lang fb) tut PALETTE nicht dasselbe wie in QB.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[James1337]

Merci beaucoup! Ich werde das sofort mal versuchen so umzusetzen.

[minx]

Danke Jojo!

Also müsste das mit unseren Farben so gehe:

Wenn:

[Jojo]

wenn dieser hex-befehl auch einstellige hexzahlen zu zwei stellen erweitert, sollte das so hinhauen, ja...
Es kommt jetzt nur noch auf die Implementierung an.
Ich würde die 256 Palette-Einträge zu Beginn in einem Array speichern (sozusagen den Palette-Befehl emulieren) und dann jeweils bei SetPixel dann den passenden Array-Eintrag abrufen.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[minx]

Jop. Hex() macht aus 0-255, 00-FF.

Das mit dem Array ist ne gute Idee, mal probieren...

[minx]

Hi nochmal. Ich wollte nochmal verkünden, das wir es jetzt hinbekommen haben!

Eine Frage habe ich aber noch. Ich besitze Qb4.5. Ich möchte per Kommandozeile eine Datei (.bas) kompilieren.

Ich kann mit BC.exe erfolgreich die OBJ Datei erzeugen, aber wie geht es dann weiter?

Vielen Dank!