From:	ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Z-buffering for Allegro (long)
Date:	12 Sep 1997 21:41:44 GMT
Organization:	The National Capital FreeNet
Lines:	22
Message-ID:	<5vccuo$6ht@freenet-news.carleton.ca>
References:	<34145012 DOT D39BD118 AT xs4all DOT nl> <hiPrcABThHG0EwOz AT talula DOT demon DOT co DOT uk>
Reply-To:	ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host:	freenet3.carleton.ca
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Shawn Hargreaves (Shawn AT talula DOT demon DOT co DOT uk) writes:

[Interesting discussions of allegro's growing pains snipped]

I suspect the need now is for Allegro to go OO. Yep, Object-oriented, C++.
Then, requiring module-developers not to touch private functions or alter
base classes (but allowing them to derive classes and use them) while you
keep the interfaces of the base classes unchanged, merely deriving new
classes for certain situations, will take care of any problems with
syncing or implementation-dependent code being emitted.

Not to mention, some things like the graphics Vtable and the dialog_proc's
are pretty object-oriented already, and would lose their awkwardness if
they became, respectively, virtual functions of a Video class whose
subclasses are interfaces to specific drivers, and virtual functions of
dialog_object classes.
--
    .*.  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 -