Keine Ahnung, ob das was bringt:
Kannst Du damit anstatt der DosBoc eventuell Swat pausieren und wieder weiter laufen lassen?
Ich kenne mich mit der DosBox unter Windows nicht wirklich aus. Verträgt Swat es, wenn man die Cycles auf einen sehr niedrigen Wert setzt? Ist dann quasi nicht angehalten, einfach nur auf sehr langsam (Sparflamme).
Das ist ein guter Input. Genau die Art von Hinweisen, welche ich als sehr wertvoll erachte. In meinem Fall habe ich das Glück, dass keine solchen Ressourcen im Einsatz sein sollten. Und wenn, dann prüfe ich wenn möglich auf Null.
Aber ich behalte mir das einmal im Hinterkopf. Bin ja immer noch in der Phase Design & Analyse...
Herzlichen Dank für Eure Experten-Input!
Das mit dem TimerHandle auf Null setzen, habe ich in der Stop-Funktion jeweils gemacht. Die Abfrage auf Null mit Return am Anfang ist jetzt auch eingebaut. Somit können eventuell nachfolgende Events die Methode zwar noch aufrufen, es sollte aber nichts mehr passieren.
Also, bei mir ist GeoBibel und GeosBibel nicht das Selbe... Auf jeden Fall freue ich mich über alle produktiven Aktivitäten 
C'est le ton qui fait la musique 
Bei der Verwendung eines kontinuierlichen Timers sind mir noch ein paar Überlegungen durch den Kopf, welche ich gerne bestätigt habe. Folgender Code startet den Timer:
g.ns.timerHandle = TimerStart(TIMER_EVENT_CONTINUAL, oself, <N_TICKS>, MSG_LAD_PLAY_EXEC, <N_TICKS>, &g.ns.timerId);Dabei wird alle <N_TICKS die Message MSG_LAD_PLAY_EXEC gesendet. Empfänger ist die Prozess-Klasse (process). Das Timer-Handle und -ID werden global gespeichert.
- Gehe ich richtig der Annahme, dass man einen kontinuierlichen Timer wenn möglich immer in der von ihm aufgerufenen Methode terminieren soll?
- Wenn die Ausführung der aufgerufenen Methode länger dauert, als das Timer-Intervall, sammeln sich die Messages in der Message-Queue des Objekts an? Wenn ja, muss man diese Queue leeren, wenn man den Timer stoppt. Gibt es hierzu einen spezifischen Befehl, der nur die entsprechenden Messages löscht?
Ja, genau. Ich bin am Zusammentragen der Strukturen. So wie es aussieht, sind 3 Punktgrössen das maximum bei Bitmap-Fonts. Mein Plan war da, 6 oder mehr in einen eigenen Font zu verpacken...
PS: GeoDump kann die Fonts auch dekodieren.
Du hast die Diskussion nicht abgewürgt. Ich wollte selber noch ein paar andere Punkte angehen und war / bin gerade auch noch mit einigen privaten Themen beschäftigt.
Grundsätzlich möchte ich einmal versuchen, das Format der Bitmap-Fonts zu verstehen. Das Zauberwort hierzu heisst wohl "BSWF". Das ist aber etwas, wo ich doch ein etwas grösseres Zeitfenster zum Dranbleiben brauche.
Hallo Rainer
Gerne werde ich Dir über die Architektur erzählen. Das könnten wir sicher in bei Johannes am Treffen durchgehen. Ursprünglich wollte ich den aktuellen Code ja nur "übersetzbar" machen... Aber da ich früher schon einmal eine Version mit grösserem Text auf eine Anfrage erstellte und der Wunsch vom Vollbild noch umsetzen wollte, ist es dann doch einiges mehr geworden. Habe definitiv nicht mit so vielen Stunden gerechnet. Aber es ist ja auch immer ein Weiterkommen. Und von dem her die Odysee eine Reise wert
Ok, das ist zwar schade, aber muss ich wohl akzeptieren. Ich möchte ja möglichst nicht immer allles neu zeichnen...
Im Moment kann man zwischen 9, 12 und 14 Punkt umschalten. Geht alles super zur Laufzeit. Aber mit den wahnwitzigen VESA-Auflösungen, welche ins GEOS einzug gehalten haben, wird das Ganze dann wieder ziemlich klein 
Am Besten sieht es aktuell mit EGA aus, wenn man die DOSBOX / DOSEmu2 in den Vollbildmodus umschaltet 
Da bleibt dann aktuell nur der Weg, ein Reverse-Engineering der Bitmaps-Fonts zu versuchen und da weitere Grössen einzubauen. So bis etwa 36 Punkt wären aktuell von nöten. Wenn Falk dann aber 4k bringt, müssten es 72 Punkt sein... und dann kommt irgendwann noch 8k und wer weiss sonst noch was wie 3D und HBI 
Natürlich wäre der da noch der Ansatz, all die skalierten Zeichen Off-Screen vorzuhalten und per BitBlt einzublenden 
Sicherlich nicht etwas für so mal schnell zwischendurch.
Werde mich in dem Fall erst einmal um die Bereinigung / Abschluss des bestehenden Codes und der Hilfe kümmern. Bin trotzdem immer Dankbar für Input, man hat zumindest etwas dazugelernt
Wunderbar, das ist genau so, wie ich es mir vorgestellt habe
Einzig muss sich dann noch zeigen, welchen Einfluss das auf die Performance hat. Ich lösche und zeichne ja immer nur die einzelnen Zeichen, welche sich auch verändert haben. Das sind im Extremfall ca. 15 Zeichen alle 3 oder 4 Ticks (20 oder 15 Hz). Ziel wäre es, wenn das Programm sicher auch noch auf einem GlobalPC oder GeoBook sauber laufen würde. Die ursprüngliche Versionhat so 2% CPU-Last auf dem GlobalPC (100MHz) erzeugt. Die neuere wird sicher etwas langsamer sein.
Vielen Dank nochmals!
Habe mich für die MSG_VIS_GET_BOUNDS enschieden, da der Code ja nicht andauernd aufgerufen werden sollte.
Frage mich bald, was schlimmer sein wird, das Jüngste Gericht oder der Review meines Codes...
Hallo Rainer
Ich habe es direkt über pself->VI_bounds.R_xxx versucht und der Compiler hazt dann reklamiert, dass mein GenPrimary keine solche Instanz besitzt.
Heisst das, ich muss in einer GenClass immer ein ObjDerefVis() verwenden, wenn ich auf die VisClass-Instanzen deren zugreifen will? Das war ir so nicht bewusst
Ansonsten habe ich mich daran erinnert, dass ich in R-BASIC z.B. im Canvas Objekt (Generic) VIS_DRAW überscheibe ohne @callsuper (geht, wenn man keinje Children hat) und dort einfach GrFillRect() auf die Bounds ausführe, um den Hintergrund zu füllen.
Hallo Rainer
Auf die MSG_VIS_DRAW vom GenPrimary wäre ich jetzt nicht wirklich von alleine gekommen. Super Idee und es funktioniert! Einzig konnte ich noch nicht ermitteln, wo das GenPrimary seine Bounds speichert. Es scheint keine VI_bounds zu haben und beim Abgrasen der Doku habe ich auch nichts verwertbares gefunden . In meinem Fall nehme ich jetzt einfach die Bildschirmauflösung und muss in der Breite und Höhe noch jeweils 2 Pixel dazu geben. Aber dann ist es perfekt
Andreas
All right, muss mich dann mal wieder eingehender mit R-Basic befassen
So, ich stelle schon mal mein voraussichtlich letztes Thema zur Diskussion.
Im GeoLadder verwende ich die Bitmap-Schriftart BISON. Diese Schriftart hat in meinen Augen genau 3 Punktgrössen, die passend sind. Das wäre 9.0, 12.0 und 14.0. Alle anderen Punktgrössen ergeben nicht so Terminal-typische Zeichen.
Ich habe einmal mit der Skalierung der GenView herumgespielt. Dabei sah es für mich so aus, als wenn ich Schrift mit 12.0 Punkten bei einem Skalierungsfaktor von 2.0 zeichne, die Zeichen dann mit der Punktgrösse 24.0 und entsprechend unschön angezeigt werden. Grundsätzlich ist das ja richtig. Aber in meinem Fall nicht passend.
Rainer hat mir ja schon einmal empfohlen, in eine Bitmap zu zeichnen. Wäre das eventuell die Lösung? Wenn ich diese Bitmap dann ganzzahlig skaliere, dann sollten auch die Zeichen weiter anständig aussehen. Einfach etwas pixliger, was nicht so schlimm wäre im Gegensatz zu den skalierten Punktgrössen.
Mir ist aber noch nicht definitiv klar, was nun PIL_GEODE überhaupt genau meint. In der Doku ist das meiner Meinung nach zuwenig ausführlich beschrieben. Alle Fenster, welche die Geode als "owner" hat?
Danke Rainer, Deine Inputs sind immer sehr wertvoll für mich!
Das View wird noch grösser werden, hoffentlich Das ist die letzte Herausforderung in meinem Katalog... Es spielt sich auch angenehmer, wenn keine ablenkenden GUI-Elemente zu sehen sind. Und darum möchte ich den ganzen Hintergrund des GenPrimary auch in die Farbe des GenView.
Ohne den MemLock hat es bei mir zum Teil den Mauszeiger nicht ersetzt. Mit dem Memlock funktioniert es zuverlässig. Weiss nicht, ob das mit dem @record und dem Senden der Message darüber zusammenhängt.
Den Mausbereich einzuschränken ist sehr böse 
Muss sich noch ein bisschen setzen...
Bezüglich Mauszeiger wollte ich diesen zuerst nur für die Geode ausblenden. Leider bekomme ich das mit WinGeodeSetPtrImage(GeodeGetProcessHandle(), @FullPointer); nicht hin. Systemweit geht es mit:
MemLock(OptrToHandle(@FullPointer));
evt = @record GenClass::MSG_GEN_SYSTEM_SET_PTR_IMAGE(@FullPointer, PIL_SYSTEM);
@call oself::MSG_GEN_CALL_SYSTEM(evt);
MemUnlock(OptrToHandle(@FullPointer));Die Konstante PIL_GEODE soll man ja laut Doku nicht verwenden (ging auch nicht).
Eventuell verstehe ich hier "GEODE" falsch...
Weiter durfte ich noch lernen, dass man in der Close-Methode der Anwendung nicht mehr den Maximized-Zustand vom Primary ermitteln kann. Scheint zu spät dafür zu sein. Aber einfach "unconditionally" die Nachricht MSG_GEN_DISPLAY_SET_NOT_MAXIMIZED ans GenPrimary zu senden funktioniert. Da setze ich den System-Mauszeiger jeweils wieder zurück. Ansonsten hat man nach dem Beenden der Anwendung im Maximized-Zustand plötzlich den falschen (bei mir unsichtbaren) Mauszeiger...
Ich glaube VarDataxx() ist etwas schneller. Das dürfte bei dir keine messbaren Vorteile bringen. Ich nutze sie aber lieber.
1. Keine Ahnung. Du hast ja auch noch ein View, dass einen Hintergrund macht, oder? Da würde ich ansetzen.
2. Gar keine Ahnung.
3. Hatten wir das nicht schon? Transparenter Mauszeiger?Gruß
Rainer
Zu 1.: Die GenView ist mittig im GenPrimary und nicht auf das Vollbild skaliert, siehe Cyan farbiger Bereich im Screenshot
Zu 3.: Wir hatten das bei der GenView. Da verwende ich die Methode MSG_GEN_VIEW_SET_PTR_IMAGE() welche auch tadellos funktioniert. Es geht mir darum, im Maximized-Modus den Mauszeiger auch asserhalb der View zu verstecken. Hier wäre wohl die Methode MSG_GEN_SYSTEM_SET_PTR_IMAGE() zu verwenden.