From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-24 19:57:08
Hi!
On Sun, Nov 24, 2002 at 04:19:53AM +0100, groepaz wrote:
> that looks even less necessary to me now i've looked at it :) first of
> all i see no problem with having a tgi_modetable.s (or whatever it was
> :=)) for each target,
There *is* a tgi_modetable.s for each target.
> and second..mmh, wouldnt it be better to have a
> function that scans the drive for available drivers and builts that
> table at runtime?
No. Building such a table at runtime has a very high overhead, because the
drivers are in o65 format, which means that the information contained in there
is only available if loaded and relocated. In addition, many applications will
hardwire the resolution because a fixed screen layout leads to much shorter
and faster code. There are a few more reasons, not to do that. Why don't you
try to use the API as is, and *then* suggest changes?
> take some time though, or is there an easy lazy way to drop in some c
> code into those modules? :)
C code in a module has a high size overhead, because runtime and C functions
are not shared between the module and the main program. Besides that, the API
between the C layer and the graphics driver is designed with for asm, not C.
> or should i maybe go for adding some
> emulation stuff in the gfx kernal instead? (i guess that can be done
> with c code easier?)
The current emulation code will probably go, because it is always a lot slower
than native stuff in the driver, and - provided that the driver does not need
the emulation - because it is dead code.
> - one that takes a gfx mode, in order to convert it into a
> target-specific filename. like the tgi_modetable, but a simple routine
> that encodes the gfx-mode constants into a reasonable unique and
> descriptive name.
>
> - one that takes a filename, in order to load a matching driver or
> return failure.
>
> - one that takes a gfx mode, in order to load a matching driver or
> return failure. like the current one does, but built of the previous
> two functions.
Please have a look at the API - it is all there!
> - one that takes a filename, in order to return the drivers
> capabilities. this would be used by applications that support more
> than one driver and let the user select one interactivly. (programmer
> would have to scan the directory for *.tgi files and pass matching
> files to this function in order to built data for a menu or sth, and
> later load the driver by name)
I will definitely NOT add bloat to the API before it is even released. Using
arbitrary user selectable drivers did not even work in the old DOS days -
there were almost no programs using Borlands BGI interface that allowed the
user to load arbitrary drivers as he wished, and I have absolutely no reason
to believe that the reasons for this are no longer valid on platforms with
just 10% of the memory and 5% of the CPU power.
> oh and.... maybe the makefile in the samples dir should also copy the
> tgi driver(s) to the disc :o)
Thanks, I will add that.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-24 19:57:14 CET