Mail Archives: djgpp/1997/05/26/15:37:19
George Foot (mert0407 AT sable DOT ox DOT ac DOT uk) writes:
> jon (quacci AT vera DOT com) wrote:
> Well, the linker doesn't link in the code from object files within
> libraries which are *completely* unused; but if you use any part of an
> object file the whole thing is linked in. So, if you initialise a
> component but do not use it, you'll still get the whole thing linked in.
Early versions of Allegro really bulked up exe size, until with version 2
or 2.1 or thereabouts Shawn rearranged the way it was divvied into modules.
> I don't recall whether the Allegro library builds itself with the -s
> option; if not, this would reduce the size of its code.
It should, but I don't know if it does... it doesn't seem like anyone much
would need the debugging info except Shawn, unless they were going to
*modify* it, in which case they could always recompile it...
> : Anyway, this isn't really discouraging, but I would like to read some
> : comments on this observation in this thread. Because I can't really
> : decide which lib to focus on- they are both great, and while Allegro
> : offers more "stuff", jlib offers more portability. Both appear to be
> : equally robust and speedy, and both have excellent documentation.
>
> When I moved to DJGPP, I initially did my own graphics, in a limited sort
> of way, by using the dos memory functions to put a 320x200 buffer onto the
> screen memory. Then I started playing with GRX in 640x480, which wasn't
> too bad. I looked at JLib and Allegro next, and chose Allegro because it
> seemed more accessible (and more highly recommended, even a year ago ;) ).
hm. I started out by using mode 13h and hand-written and hand-optimized
line and putpixel and blit functions... I wrote some decent stuff with
that. Then I migrated directly to Allegro. It's definitely nice to work
with 640x480x256 super-VGA, load and save picture files on disk in formats
recognized by other software, and autodetect chipsets. (Think what the
fractint guys could have done with allegro. Made a lot more optimized
fractal stuff, spending a lot less time on video logic...:) But wait until
ProtoMatter comes out...)
> : Actually, I hope it is always hard to choose our libs. We're all very,
> : _very_ lucky for the fantastic efforts of Shawn Hargreaves with
> : Allegro and Jon Griffiths with Jlib. Thanks, guys! (round of
> : applause!)
>
> Standing ovation, more like :)
Yeah. Have you seen the sources? Look at that stuff... assembly, video
hardware bit twiddling, figuring out the weird Mode X layering, file
compression on the fly... you name it. The guy's a wizard. I have maybe a
ten percent chance of reaching that level of wizarditude...in ten years.
In fact I think I'm going to spend part of the day (week...summer?)
looking at the source for allegro figuring out how it works. If I want to
make ProtoMatter as fast as Fractint I need some hands-on assembly
experience, and looking at the stuff is a starting place.
> : 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? Yes, there is a reason I'd like to! Anyway, all mouse functions
> : are, naturally, oriented toward screen movement... but is there a way
> : to access mouse x and y's out beyond screenwidth and screenheight? I
> : can think of work-arounds, but for all I know, you can have x and y's
> : beyond 65000- which would be plenty!
>
> You can adjust the mouse range, but this fails on some mouse drivers. If
> the library you are using supports reading mouse mickeys, you can do this
> and simulate the mouse movement yourself (the mickeys will tell you how
> far the mouse has moved since the last call). Allegro doesn't have this
> yet, I'm not sure about JLib. You can get around this by doing something
> like this (pseudo-Allegro code):
>
> On initialisation: position_mouse(screen_width/2,screen_heigth/2);
>
> Then make a function:
>
> void get_mouse_difference(int *x,int *y)
> {
> *x=mouse_x-screen_width/2;
> *y=mouse_y-screen_height/2;
> position_mouse(screen_width/2,screen_height/2);
> }
>
> Each call to get_mouse_difference will get the change since last time it
> was called. The above code isn't tested; I can't do that here. The
> position_mouse function may be called something else, as well.
> screen_width and screen_height should be set to the width and height of
> the screen (i.e. the mouse's range) although this isn't too important.
Thanks, this code might also make it possible to deal with the nasty
problem that the mouse pointer, even set to speed 1, crawls like a turtle
on a 640x480 or bigger screen. I don't suppose it would be safe to read
mouse_x, SCREEN_W, and the like, and call position_mouse inside a timer
interrupt, would it? (Shawn?)
--
.*. Where feelings are concerned, answers are rarely simple [GeneDeWeese]
-() < When I go to the theater, I always go straight to the "bag and mix"
`*' bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh
- Raw text -