Mail Archives: djgpp/1997/10/17/10:16:18
Doug Eleveld writes:
>I know that the DAT files can carry code because you can put compiled
>sprites into the DAT files.
Not quite: the compiled sprite objects are actually stored on disk as
regular bitmaps, and only translated into code when the datafile is read
into memory. That insulates the file format from any future changes to
the details of how the drawing code works, and would also allow the
files to be read and used on machines with different types of CPU. Raw
machine code is not a very portable or malleable format to work with :-)
>Now, isn't it possible to also put some mode changing code or driver
>code into a dat file and have some small kernal always in memory that
>takes the requests, searches for the right DAT file and driver and load
>that into memory? The memory footprint gets alot smaller and only the
>necessary stuff gets loaded.
I did at one point consider doing this, but decided that it wasn't worth
it. The libc DXE functions provide most of what would be required, but
they only support a single entry point to the loaded module, which isn't
nearly enough for most of the Allegro hardware drivers. Many of these
share a large number of common helper functions (eg. the VGA register
access routines, assorted DPMI calls, the _gfx_mode_set_helper()
function, DMA routines, interrupt handling module, CPU sample mixing
code, etc...) Splitting the drivers off from the rest of the lib would
require all this linkage to be done manually via tables of function
pointers, which would incur some extra performance overhead and make the
code a great deal less readable and harder to maintain. Plus, the actual
hardware drivers are generally very small compared to the amount of
helper code (just look how small something like s3.c is, or contrast the
size of the driver code in sb.c with the helper code in mixer.c, dma.c,
and irq.c). It wouldn't be practical to dynamically load all this helper
code, and I have a feeling that what you could gain by splitting off the
actual drivers would be more than countered by the extra complexity of
the loading and linking routines...
>P.S. Shawn, if you are reading this, the docs for the gui stuff doesn't
>seem to mention that if an d_xxx_proc returns D_WANTFOCUS from a
>MSG_LOSTFOCUS, that the focus will only be actually taken away if the
>destination object has retuned D_WANTFOCUS to it's MSG_WANTFOCUS. That
>means that if an object returns D_WANTFOCUS from a MSG_LOSTFOCUS, that
>the focus has to be forced away to another d_xxx_proc that wants the
>focus.
A good point: that should be documented. Will do...
--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
Beauty is a French phonetic corruption of a short cloth neck ornament.
- Raw text -