🚀 go-pugleaf

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