Das deutsche QBasic- und FreeBASIC-Forum

[Felix]

Hallöle zusammen,

hab n Problem... Ich versuche gerade, in einer Shared Lybrarie in einem Sub was zu zeichnen und wenn ich dann das Programm ausführe dann zeigts mir nur schwarzen screen an... Hier mal die lybrarie:

[volta]

bib.bi

[Felix]

Erstmal danke für diene ANtwort,
aber irgendwie funktioniert die Sache doch nicht, ich schreib jetzt nochmal auf dwie ichs genau gemacht habe.... Es funktioniert ja bei allen Funktionen und Subs nur eben nicht beim ZEichnen...

Erstmal habe ich die .bas Datei die ich in .dll kompiliert habe

[AndT]

Gugst du unten?
_________________
Bis irgendwann...

[volta]

Hi,
jetzt wird es etwas kompliziert:
1. In einer statischen Lib kannst du die fbgfx-Anweisungen (Screen, Line etc) benutzen. Sie funktionieren auch nachher in der EXE.
2. In einer dynamischen Lib (dll) kannst du sie auch benutzen, sie kennen aber den Screen den du in deiner EXE bildest nicht. Dll und EXE bilden jede für sich eine eigene Instanz (~Fenster).

Der Vorschlag oben war für eine statische Lib ( fbc -lib bib.bas ) und funktioniert gut.

Der Fehler bei dir:
Auch in der BAS - Datei, die du zu einer Lib kompilierst, muss am Anfang die Sub deklariert werden (siehe oben bib.bas #Include "bib.bi").
In der Deklaration muss der Name der Lib und der Alias angegeben werden (Declare Sub zeichneSpielfeld Lib "bib" Alias "zeichneSpielfeld" () )
Aber auch mit diesen Änderungen funktioniert es in einer DLL nicht, nur in einer statischen Lib.
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater.

[AndT]

Eine Lösung:
Die ist Dll für die Grafikausgabe und das Programm gibt der DLL die Befehle
Lib (bib.bas) mit folgenden Code erstellen (-dll):

[volta]

@AndT
und das hast du wirklich ausprobiert ?
und nur mit -dll als Kompileroption die Dll erstellt ??
und das fbgfx-Fenster aus der Dll kannst du schließen ???


unter Windows ME funktioniert das Alles nicht!!!
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater.

[Jojo]

wahrscheinlich hat er es ohne -dll kompiliert und die .exe in .dll umbenannt und dann mit SHELL ausgeführt
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[Joseph]

Hallo,

ein möglicher Lösungsvorschlag für Dein Problem:
Du könntest an die Funktion in der DLL einen Grafik-Puffer übergeben, in den dann gezeichnet wird. Wenn die Funktion ihre Aufgaben erledigt hat und die Kontrolle an das aufrufende Programm zurückgibt, wird der Puffer zur Anzeige gebracht. Eine einfache, aber speicherfressende Variante wäre: Du erstellst mit IMAGECREATE ein Sprite in der Größe des Bildschirms, kopierst den vorhandenen Bildschirminhalt ins Sprite (falls dort schon Grafik vorhanden ist, die Du nicht überschreiben möchtest), übergibst das Sprite an die DLL, lässt dort auf das Sprite zeichnen und lässt dann vom Hauptprogramm das aktualisierte Sprite wieder anzeigen. Sieh Dir dazu in der Befehlsreferenz IMAGECREATE, IMAGEDESTROY, GET, PUT an und bei den Grafikbefehlen die Anweisungen wie man in einen externen Grafik-Puffer zeichnet. Noch wichtig: Die Grafikbefehle in der DLL müssen auf den verwendeten Bildschirm-Modus abgestimmt sein (Farbtiefe). Hoffe, es funzt.

[volta]

Hi Joseph, willkommen im Forum!

Leider ist dein Vorschlag keine Lösung für dieses Problem.
Auch ImageCreate gehört zu den fbgfx-Anweisungen, wird es im Hauptprogramm gebildet ist dies wieder eine andere Instanz und die fbgfx-Anweisungen aus der DLL können nicht damit arbeiten .
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater.

[Jojo]

na, immerhin kann man schön mit dem puffer auf direkter basis arbeiten... nur halt nicht mit den typsichen drawing primitives.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[AndT]

Also unter XP geht alles
_________________
Bis irgendwann...

[AndT]

kk
_________________
Bis irgendwann...

[Joseph]

Hallo,

hatte gestern leider kein FB zur Hand als ich den Vorschlag mit dem Grafikpuffer gemacht habe. Volta, Du hast völlig recht, da EXE und DLL zwei verschiedene Instanzen sind, hat die DLL keine Ahnung, welcher Bildschirmmodus aktiv ist und wohin mit den Grafikdaten.
Hier aber trotzdem eine funktionierende Schritt-für-Schritt-Anleitung, wie man eine DLL dazu bringt, mit den FB-internen Grafikbefehlen etwas auf den Bildschirm zu zeichnen, ob das aber praktisch Sinn macht, ist fraglich:
1. Grafikpuffer in ausreichender Größe anlegen, um den gesamten vorhandenen Bildschirminhalt zu sichern.
2. Bildschirminhalt mit GET im Grafikpuffer sichern.
3. WICHTIG! AUF SCREEN 0 GEHEN!
4. Die gewünschte Function/Sub in der DLL aufrufen und den Grafikpuffer übergeben.
5. WICHTIG! VOR BEGINN DER GRAFIKANWEISUNGEN IN DER FUNCTION/SUB DEN GEWÜNSCHTEN GRAFIK-BILDSCHIRMMODUS DEFINIEREN! (genau davon sollte man in DLLs eher die Finger lassen, hier ist es aber notwendig).
6. Grafikbefehle ausführen und in den Grafikpuffer zeichnen.
7. WICHTIG! VOR VERLASSEN DER DLL AUF SCREEN 0 GEHEN!
8. Zum Hauptprogramm zurückkehren.
9. WICHTIG! JETZT IM HAUPTPROGRAMM WIEDER DEN GEWÜNSCHTEN GRAFIK-BILDSCHIRMMODUS DEFINIEREN!
10. Mit PUT den modifizierten Grafikpuffer am Bildschirm anzeigen lassen.
Das generelle Problem dabei: Beim Umschalten zwischen SCREEN 0 und Grafikmodus flackert es logischerweise. Wenn das nur einmal am Anfang des Spiels geschieht, ist das sicher kein Problem, die Methode ist aber völlig ungeeignet, um während des Spiels den Bildschirm zu aktualisieren. Es geht also jetzt darum, einen Weg zu finden, wie man der DLL mitteilt, welcher Grafikmodus aktiv ist und wo im Bildschirmspeicher die FB-internen Grafikfunktionen die Pixel setzen sollen, ohne in der DLL vor Beginn der Grafikbefehle einen Screen-Modus angeben zu müssen. Das gleichzeitige Definieren eines neuen Screens in der DLL, ohne den bisher aktiven Screen mit SCREEN 0 zu deaktivieren, führt zu unvorhersehbarem Verhalten, da z.B. im Fenster-Modus zwei Screens übereinander liegen, einer davon ist völlig verpixelt, z.B. bei mir mit verzerrten Trümmern der Startleiste (der dahinter liegende Screen enthält aber die gewünschte Grafik) und kann nicht nur zum Absturz des Programms führen, sondern hat bei mir auch Spuren im Bildschirmspeicher hinterlassen, die erst beim nächsten Start des Rechners verschwunden sind. Bin schon neugierig, ob es dafür eine Lösung gibt.
Ansonsten gibt es nur die Alternative, wie Jojo geschrieben hat, direkt im Grafikpuffer die Farbwerte der Pixel zu ändern, das erfordert aber, dass man sich eigene Zeichenfunktionen definiert um die Position jedes Pixels im Datenvektor bestimmen und den Farbwert setzen zu können. In der QB-Monster-FAQ findet sich da z.B. die Anleitung, wie man eine Linie oder Kreis mit dem Bresenham-Algorithmus zeichnet. Auch eine Anleitung, wie man einen ausgleichenden 4-Punkte-Spline nach der de Casteljau-Methode (ist vom Ergebnis her praktisch identisch mit der Bezier-Methode) zeichnen kann, findet man dort. Wichtig dabei: Wenn man mit selbstgeschriebenen Zeichenfunktionen die Farbwerte der Pixel im Grafikpuffer ändert, gibt es kein komfortables, automatisches Clipping, man muss selber prüfen, ob man noch im erlaubten Zeichenbereich ist und den Farbwert setzen darf oder nicht, andernfalls greift man auf eine Speicherstelle ausserhalb des erlaubten Bereichs zu.

[Jojo]

...oder man malt auf der anderen seite des bildschirms weiter

naja, du hast ja grad schön gezeigt, wie aufwändig und zugleioch auch unnötig es ist, die DLL den krams machen zu lassen - wird ja dadurch schon viel langsamer und nützen tut diese methode auch nix.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[Joseph]

@Jojo,
hast Recht, aber zumindest konnte eine Möglichkeit gefunden werden, wie man eine DLL dazu bringt, was am Bildschirm zu zeichnen. Die Frage an sich war trotzdem interessant.
@Felix,
am besten, Du baust Deine Grafikanweisungen ins Hauptprogramm ein oder lagerst sie in eine statische Lib aus, die beim Kompilieren hinzugebunden wird. Die Variante mit der DLL hätte praktisch bestenfalls Sinn, wenn auch andere Programme darauf zugreifen sollen, aber auch dann würde das nur sinnvoll sein, wenn das von der Sub/Function erzeugte Bild je nach Spielsituation anders aussieht (es müssten dann Parameter übergeben werden, die das Aussehen des Bildes bestimmen). Soll z.B. immer nur das selbe Bild gezeichnet werden, könnte man das einmal erzeugen und als Bilddatei speichern, die dann bei Bedarf geladen wird.

[Jojo]

Praktische Anwendung gibt es durchaus für sowas, ja. Aber dann eher mit der direkten Manipulation des bildpuffers. Das hab ich so z.B. im Hotel-Manager gemacht, da ruft das etwas langsamere VB eine FB-Bibliothek auf, die rasend schnell einen übergebenen Bildpuffer durchwühlt.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[28398]

[Jojo]

...ist das jetzt was besonderes?
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.

[28398]