From: Todd R. <tri...@ai...> - 1998-10-31 18:51:25
|
I can compile winallegro just fine with VC++ 6.0 ... Just set it up to compile like you would with vc 5.0... ;) -Todd Michael Scrivo wrote: > > Has anyone tried this? Is there anything special you have to do to get it > to work? > > thanks, > Michael Scrivo >From <all...@ma...> Sat Oct 31 11:15:32 1998 Received: from ibd.dbio.ro [193.231.0.2] by mail.canvaslink.com with ESMTP (SMTPD32-4.06) id A79E72A0148; Sat, 31 Oct 1998 11:15:26 DT Received: from localhost (calin@localhost) by ibd.dbio.ro (8.8.8/8.8.8) with SMTP id SAA20823 for <al...@ma...>; Sat, 31 Oct 1998 18:20:14 +0200 (EET) (envelope-from ca...@ib...) Date: Sat, 31 Oct 1998 18:20:14 +0200 (EET) From: Calin Andrian <ca...@ib...> To: al...@ma... Subject: Re: [AL] New WIP In-Reply-To: <4UY...@ta...> Message-ID: <Pin...@ib...> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: all...@ma... Reply-To: al...@ma... X-UIDL: 905450713 Status: O Content-Length: 2173 Lines: 55 On Fri, 30 Oct 1998, Shawn Hargreaves wrote: > If you have time, that would be great. Otherwise I can do it myself, but > I'm not sure exactly when I will get around to that, and you probably > have a better understanding of what needs to be done... > OK, I'm on it. > > I think the way to do it is: 1. Split the scene rendering into a > > separate source - it's in polygon.c now. > > I agree, that's an important split. It might even be worth trying to get > the stock triangle() and polygon() functions in a different file to the > 3d versions, but that would be really nasty because there are so many > shared helper functions that both versions need to use. > This is easy. > > 2. scanline.s has grown too much - it is the biggest piece of source > > in Allegro. It should be split. > > For sure, that is a stupidly long file at the moment. Big asm sources > don't hurt in terms of compile time, but they are very confusing to > edit, plus the library distribution looks more impressive if we have > hundreds of tiny files rather than just one big one :-) > This is so difficult ! There are a lot of macros common to rendering modes, not to screen depths. After all, scanline.o is only 30k. And if I spilt it for different depths, it means nothing without a vtable-like mechanism to get rid of it at link time. I'd rather just #ifdef the routines. A serious release where size is so important uses anyway a stripped-down allegro by recompiling the library. > > 3. MMX problem: maybe the MMX routines should have their own asm > > source. > > Perhaps, although we could always just stick a #ifdef around them. What > can we use to detect the binutils version, though? GCC doesn't have a > define for that... > Don't know how to detect it. Maybe by running a test source from the makefile. If the mmx opcodes generate errors, change the defines (like autoconf does for UNIX flavors). > > 4. Now that both AMD and Cyrix are using the 3DNow! CPU extension > > maybe I could re-write the 3D-based versions > > That would indeed be cool, if you have the time to do it... > I just found the old routines I once wrote, so it will be easy. Calin Andrian |