🚀 go-pugleaf

franky@netmbx.UUCP (Frank Bergemann) writes:


>hallo !

>habe ein problem mit der fsel/Input/funktion ...
>da diese bei mir (MEGA ST1, TOS1.6) nach aufruf den alten
>bildschirm-inhalt nicht restauriert, muss ich vor dem
>aufruf den gesamten screen per memcpy in einen 3200-byte-buffer
>sichern und danach wieder holen.. leider stricke ich gerade
>an einer anwendung, die sehr speicherintensiv ist und ich habe
>keine lust 32 KB zu verschenken.... weiss jmdrat ?  es

#pragma FLAME_ON
memcpy ??? das gibt es ja wohl nicht mehr ! Das sind dann die Programme, die
auf OverScan, TT und sonstigem nicht leufen !!! Wenn schon, dann sauber ueber
VDI !!! und das sind auch nicht immer 32000 Bytes ... das kann erheblich
mehr werden!
#pragma FLAME_OFF

Das AES restauriert allerdings keine Bildschirminhalte (ausser bei
Pull-Down- Menues).  Das Problem tritt aber nicht nur mit der
FIleselect-Box auf, sondern auch dann, wenn andere Programme
(Accessories) eigene Fenster aufmachen - deren Bereich wird auch nicht
automatisch gepuffert.  Dafuer schickt einem das AES ja dann diese
wunderbaren redraw-messages, die einem genau sagen, welche Teile des
Bildschirms man neu zeichnen muss.  Geht ja auch am einfachsten - das
eigene Programm weiss schliesslich am besten, wie man die Daten neu
anzeigt.  Meistens geht das naemlich ohne die komplette Bitmap zu
puffern - und damit viel Speicherplatzsparender.
-------------------------------------------------------------------------------
Michael Schwingen, Ahornstrasse 36, W-5100 Aachen, Germany
michaels@messua.informatik.rwth-aachen.de
PLEASE KEEP MAIL FROM OUTSIDE GERMANY SHORT-I HAVE TO PAY FOR INCOMING MAIL

In article <michaels.682339502@rama> michaels@rama.informatik.rwth-aachen.de (Michael Schwingen) writes:
]
]#pragma FLAME_ON
]memcpy ??? das gibt es ja wohl nicht mehr ! Das sind dann die Programme, die
]auf OverScan, TT und sonstigem nicht leufen !!! Wenn schon, dann sauber ueber
]VDI !!! und das sind auch nicht immer 32000 Bytes ... das kann erheblich
]mehr werden!
]#pragma FLAME_OFF
]

ich denke, der TT hat die moeglichkeit, eine ST-aufloesung zu fahren ?
es ist nun mal so, dass mein programm sehr speicher und rechenintensiv ist, 
so dass der anwender dann selber von sich aus mit der empfohlenen 
aufloesung fahren wird, weil die eben ausreicht ... im augenblick ist 
alles auf die monochrom (640*400) aufloesung zugestrickt. ich selbst habe auch 
den (allerdings aelteren von hand umschaltbaren) overscan in einem meiner ST
aber bis auf eine graphische spielerei mit Lissajou-schen figuren nie 
selbst benutzt.... ich kann ja nicht, wenn ich eine anzahl von bedienelementen 
auf dem schirm plaziere, deren groesse fuer overscan auslegen und dann fuer
jemanden , der mit 640*400 arbeitet runterscalieren so dass alles unkenntlich
wird... oder den overscan-modus ausnutzen und mehr auf dem schirm bringen, was
andere dann nicht ausntzen koennen ..... 
Ausserdem bedeutet doch wohl eine variable bildschirmgroesse zu verwalten 
automat. einen nicht unbedeutenden mehraufwand an programmierung und 
dann auch Code, der speicher frisst , oder ?
naja... aber irgendwie reizt das schon, ne variable groesse im program zu 
haben .... mal sehen ... aber eigentlich wollte ich nicht 90% der zeit 
fuer programmierung verplempern, wenn's um ein hardware-produkt geht
(wird demnaechst hier "angepriesen")

gruss !!!
Frank 

In article <2559@netmbx.UUCP> franky@netmbx.UUCP (Frank Bergemann) writes:

>In article <michaels.682339502@rama> michaels@rama.informatik.rwth-aachen.de (Michael Schwingen) writes:
>]
>]#pragma FLAME_ON
>]memcpy ??? das gibt es ja wohl nicht mehr ! Das sind dann die Programme, die
>]auf OverScan, TT und sonstigem nicht leufen !!! Wenn schon, dann sauber ueber
>]VDI !!! und das sind auch nicht immer 32000 Bytes ... das kann erheblich
>]mehr werden!
>]#pragma FLAME_OFF
>]

stimme ich voll zu.

>ich denke, der TT hat die moeglichkeit, eine ST-aufloesung zu fahren ?
 
und wie sieht es mit leuten aus, die ihren SM124 in den Schrank verbannt haben,
weil sie mittlerweile nen Matrxi M110 od. so haben. Der kann zwar auch ne
640*400 Emu, aber das bringts nur wenn sie sauber unterstuetzt wird. Ein
negativ Beispiel ist da UNITERM. Saemtlich Dialogboxen erscheinen auf
dem M110 nur die Hilfeseite landet auf dem SM124. Ausserdem weigert es
sich strikt unter der "grossen" Aufloesung was brauchbares auf den Screen
zu zaubern.

>es ist nun mal so, dass mein programm sehr speicher und rechenintensiv ist, 
>so dass der anwender dann selber von sich aus mit der empfohlenen 
>aufloesung fahren wird, weil die eben ausreicht ... im augenblick ist 

Was machste mit Usern, die in der gluecklichen Lage sind 12MB Ram zu haben ??
Willste die zwingen ne geringere Aufloesung zu nehmen, als machbar waere ??
Und das nur, weil du es im Programm so vorsiehst ?? 

>alles auf die monochrom (640*400) aufloesung zugestrickt. ich selbst habe auch 
>den (allerdings aelteren von hand umschaltbaren) overscan in einem meiner ST
>aber bis auf eine graphische spielerei mit Lissajou-schen figuren nie 
>selbst benutzt.... ich kann ja nicht, wenn ich eine anzahl von bedienelementen 
>auf dem schirm plaziere, deren groesse fuer overscan auslegen und dann fuer
>jemanden , der mit 640*400 arbeitet runterscalieren so dass alles unkenntlich
>wird... oder den overscan-modus ausnutzen und mehr auf dem schirm bringen, was
>andere dann nicht ausntzen koennen ..... 

Dann musst du halt mit mehreren layouten arbeiten, um fuer jede Aufloesung das
Optimale rauszuholen.

>Ausserdem bedeutet doch wohl eine variable bildschirmgroesse zu verwalten 
>automat. einen nicht unbedeutenden mehraufwand an programmierung und 
>dann auch Code, der speicher frisst , oder ?

sicherlich. Aber die Moeglichkeit eines Programmes immer das Optimale unter
einer Aufloesung zu bringen, traegt dann auch zu seinem Verbreitungsgrad
bei. Und die Zeiten wo der Programmierer der Guru war und der User sich
in sein Schicksal fuegen musste, sind eigentlich vorbei. Heutzutage muss
man sich intensiv darum bemuehen die Moeglichkeiten eines Programmes moeglich
einfach anzubieten. Und dazu gehoert nunmal auch die moeglichst
Aufloesungs- und Hardwareunabhaengige Programmierung.

>naja... aber irgendwie reizt das schon, ne variable groesse im program zu 
>haben .... mal sehen ... aber eigentlich wollte ich nicht 90% der zeit 
>fuer programmierung verplempern, wenn's um ein hardware-produkt geht
>(wird demnaechst hier "angepriesen")

Hardware ist immer easy :-)) Das Kruzifix liegt in der Software. Auch wenn
die Hardware noch so gut ist, aber die Software mies, dann ist auch das ganze
Produkt mies. Ausserdem ersparst du dir umfangreiche Nacharbeiten, weil dich
sicherlich User ansprechen werden, die es dann gerne anders haetten. Wenn
du dich dann von vorneherein auf deine Aufloesung versteift hast, stehst du
dann da, und kannst grosse Teile deines Prgs einfach in die Tonne werfen :-))

>gruss !!!
>Frank 

Gruss
  
    Marvin

--
  _ _ _                     |   Christian Bode, Aachen, FRG
 ' ) ) )              ,     |   marvin@tornado.GUN.de
  / / / __  __  . .  , __   |   bode@cip-s01.informatik.rwth-aachen.de
 / ' (_(_/_/ (_(__)_/_/ /   |   Voice:+49 241 557707  Box: +49 241 558292 (24h)
----------------------------+--------------------------------------------------
            Don't ask me ! It only would depress me !

franky@netmbx.UUCP (Frank Bergemann) writes:

>In article <michaels.682339502@rama> michaels@rama.informatik.rwth-aachen.de (Michael Schwingen) writes:
>]
>]#pragma FLAME_ON
>]memcpy ??? das gibt es ja wohl nicht mehr ! Das sind dann die Programme, die
>]auf OverScan, TT und sonstigem nicht leufen !!! Wenn schon, dann sauber ueber
>]VDI !!! und das sind auch nicht immer 32000 Bytes ... das kann erheblich
>]mehr werden!
>]#pragma FLAME_OFF
>]

>ich denke, der TT hat die moeglichkeit, eine ST-aufloesung zu fahren ?
Das ist ja wohl keine Loesung!

>es ist nun mal so, dass mein programm sehr speicher und rechenintensiv ist,
>so dass der anwender dann selber von sich aus mit der empfohlenen
>aufloesung fahren wird, weil die eben ausreicht ... im augenblick ist
>alles auf die monochrom (640*400) aufloesung zugestrickt. ich selbst habe auch
>den (allerdings aelteren von hand umschaltbaren) overscan in einem meiner ST
>aber bis auf eine graphische spielerei mit Lissajou-schen figuren nie
>selbst benutzt.... ich kann ja nicht, wenn ich eine anzahl von bedienelementen
>auf dem schirm plaziere, deren groesse fuer overscan auslegen und dann fuer
>jemanden , der mit 640*400 arbeitet runterscalieren so dass alles unkenntlich
>wird... oder den overscan-modus ausnutzen und mehr auf dem schirm bringen, was
>andere dann nicht ausntzen koennen .....
ganz einfach: die Dialogboxen fuer 640*400 auslegen - aber im restlichen
Programm den Platz auf dem Bildschirm bei Fenstern etc.  ausnutzen.

>Ausserdem bedeutet doch wohl eine variable bildschirmgroesse zu verwalten
>automat. einen nicht unbedeutenden mehraufwand an programmierung und
>dann auch Code, der speicher frisst , oder ?
Nicht unbedingt.  Ob man jetzt mit festen Werten fuer die Aufloesung
arbeitet oder an der Stelle auf die entsprechenden Variablen zugreift,
die man vorher einmal initialisiert hat, ist nicht der Mehraufwand.
Selbst wenn das Programm die hoehere Aufloesung nicht ausnutzt, sollte
es wenigstens *laufen*!

>naja... aber irgendwie reizt das schon, ne variable groesse im program zu
>haben .... mal sehen ... aber eigentlich wollte ich nicht 90% der zeit
>fuer programmierung verplempern, wenn's um ein hardware-produkt geht
>(wird demnaechst hier "angepriesen")
Gerade die Leute, die sich Hardwareerweiterungen einbauen, haben mit
hoeherer Wahrscheinlichkeit schon andere derartige Sachen im Rechner -
z.B.  Overscan, Matrix-Bildschirmkarten etc.. Und Overscan ist die
einfachste und billigste Methode zu ueberpruefen, ob ein Programm auch
mit anderen Bildschirmen klarkommt.

-------------------------------------------------------------------------------
Michael Schwingen, Ahornstrasse 36, W-5100 Aachen, Germany
michaels@messua.informatik.rwth-aachen.de
PLEASE KEEP MAIL FROM OUTSIDE GERMANY SHORT-I HAVE TO PAY FOR INCOMING MAIL