🚀 go-pugleaf

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 !