From: bret DOT logan AT yale DOT edu (Bret Logan) Newsgroups: comp.os.msdos.djgpp Subject: Re: Allegro question regarding .exe size Date: Tue, 27 May 1997 13:46:37 GMT Organization: Department of Computer Science, Yale University Lines: 72 Message-ID: <338ae544.4337592@news.cis.yale.edu> References: <3388b9c1 DOT 30672726 AT news DOT cis DOT yale DOT edu> NNTP-Posting-Host: caliper.ai.cs.yale.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Mon, 26 May 1997 19:13:16 +0100, Shawn Hargreaves wrote: >jon writes: >If executable size is really a concern, you might also wish to edit the >file graphics.c, find the list of available graphics drivers (near the >top of the file), and delete the ones that you aren't using. You'll >probably be able to cut the size down quite a bit by removing the mode-X >and Xtended drivers, as with those two gone all the planar drawing code >will be removed. Getting rid of all the SVGA drivers will also help a >bit, although in this case you will only be removing the driver code and >not the drawing routines as well (even if you are only using mode-X >resolutions, the linear drawing functions are needed for use with memory >bitmaps). Well, you've answered my question more than adequately- thanks so much. Truth is, now that I have an idea what is in there, and that it doesn't grow with code size, I probably am not going to concerm myself much more with it. And if I ever did really need to strip it down, I'd follow your excellent advice shown above. <...> >Re. whoever it was that mentioned stripping Allegro, that isn't relevant >for library code. You can't run strip on liballeg.a (if you do, the >linker is going to get upset because it needs a symbol table to know >which bit of code corresponds to each function!) but as long as you use >the -s flag when linking your program, or run strip on the resulting >executable, the Allegro symbols will get removed along with the ones >from your own code. The standard Allegro library is compiled without >debugging info: if anyone wants to be able to debug into the library >functions, set the environment variable DEBUGMODE=1 before compiling and >you'll get a non-optimised version with a full set of debug symbols... I am glad you addressed this- I was considering tinkering around with the makefile and rebuilding. >>Oh, and on a more general front- what do any of you suggest as the >>best way to move a mouse over an arbitrary-sized buffer (BITMAP) in >>RAM? <...> >You can use the set_mouse_range() function in Allegro, or int 0x33 with >ax=7 and ax=8 if you prefer to do it yourself, to tell the mouse driver >that you want the mouse to be able to extend past the edge of the >screen. This depends on the mouse driver handling big ranges properly, >though, and I'm not sure how safe that assumption is... > >Alternatively, you could keep polling the mouse, measuring how far it >has moved from the centre of the screen, and then resetting it back to >the middle (Allegro position_mouse() routine, or int 0x33 ax=4), so it >will be able to go on moving forever without hitting the edge of the >screen. This is prone to some loss of responsiveness, though, as every >time you reset the position the mouse driver loses whatever fractional >position information it has been accumulationg. Talk about support! You certainly do address your users' problems, and fast. I'll leave the above in for anybody who misses the post; I'm probably not the only guy who has wondered about such mouse uses. Thanks again, ever so much. >The ideal way to do it is to use mouse mickeys. which is quite easy and >will be supported by the next Allegro version, but I haven't quite >finished it yet :-) If you want to do it yourself, int 0x33 ax=11 should >give you all the info you need... Looking forward to it.