Re: [AL] Winallegro in VC++ 6.0

[Todd R. <tri...@ai...>]

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