From: Shawn Hargreaves Newsgroups: comp.os.msdos.djgpp Subject: Re: Suggestion for Allegro... Date: Wed, 15 Oct 1997 23:39:34 +0100 Organization: None Distribution: world Message-ID: References: <3445339A DOT 7F98CE24 AT anest DOT azg DOT nl> NNTP-Posting-Host: talula.demon.co.uk MIME-Version: 1.0 Lines: 50 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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.