Article View: dnet.atari
Article #248Re: FSEL_INPUT
From: Michael Schwingen
Date: Thu, 22 Aug 1991 10:24
Date: Thu, 22 Aug 1991 10:24
52 lines
3496 bytes
3496 bytes
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
Technical Details
Message-ID:
<michaels.682856654@hathi>Path:
arc1-ca.pugleaf.net!gmdzi!unido!urmel!hathi!michaelsReferences:
<2550@netmbx.UUCP> <michaels.682339502@rama> <2559@netmbx.UUCP>Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit X-Google-Thread: 12bdcf,2c4e55db26d7f324 X-Google-Attributes: gid12bdcf,public X-Google-ArrivalTime: 1991-08-22 03:59:04 PST Path: arc1-ca.pugleaf.net!gmdzi!unido!urmel!hathi!michaels From: michaels@hathi.informatik.rwth-aachen.de (Michael Schwingen) Newsgroups: dnet.atari Subject: Re: FSEL_INPUT Message-ID: <michaels.682856654@hathi> Date: 22 Aug 91 10:24:14 GMT References: <2550@netmbx.UUCP> <michaels.682339502@rama> <2559@netmbx.UUCP> Sender: news@urmel.informatik.rwth-aachen.de (Newsfiles Owner) Distribution: dnet Organization: RBI - RWTH Aachen Lines: 52 Nntp-Posting-Host: hathi