[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> - Get rid of (some) global variables and states. E.g. `text_mode()'
> could be an argument to `textout()' rather than a global variable. (I've
> never understood why background and foreground color should be treated
> differently in the API.) I don't know if it is worth the effort though.
I wholeheartedly agree. I'd be glad to help there :)
--
Vincent Penquerc'h
------_=_NextPart_001_01C1616E.CC17B500
Content-Type: text/html;
charset="windows-1252"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>RE: [AD] official beta (Re namespace again)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> > Why ? everything in alcompat.c can be defined out by </FONT>
<BR><FONT SIZE=2>> OLD_ALLEGRO_API,</FONT>
<BR><FONT SIZE=2>> > and thus not defining it would essentially link against an </FONT>
<BR><FONT SIZE=2>> empty file.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Do you mean:</FONT>
<BR><FONT SIZE=2>> (1) alcompat.c is in liballeg.a</FONT>
<BR><FONT SIZE=2>> (2) alcompat.c is in liballegcompat.a</FONT>
<BR><FONT SIZE=2>> (3) the user has to add alcompat.c to his project</FONT>
<BR><FONT SIZE=2>> ?</FONT>
</P>
<P><FONT SIZE=2>I mean (1).</FONT>
</P>
<P><FONT SIZE=2>> If (1) or (2), then #defining OLD_ALLEGRO_API in your own source file</FONT>
<BR><FONT SIZE=2>> has no effect on the library. If (3), then it still requires </FONT>
</P>
<P><FONT SIZE=2>Right. This would be a switch in allegro building, like, say, build the</FONT>
<BR><FONT SIZE=2>lib with support for this or that feature. But then, I see a counter</FONT>
<BR><FONT SIZE=2>argument there, which I had not thought of:</FONT>
</P>
<P><FONT SIZE=2>> This pretty much requires a new name for allegro.h and liballeg.a,</FONT>
<BR><FONT SIZE=2>> because people may want both 5.* and 4.0 installed at the same time.</FONT>
<BR><FONT SIZE=2>> What about allegro5.h and liball5.a ?</FONT>
</P>
<P><FONT SIZE=2>> > Ah yes. One wishes for references. We could possibly do something</FONT>
<BR><FONT SIZE=2>> > about that with those:</FONT>
<BR><FONT SIZE=2>> > </FONT>
<BR><FONT SIZE=2>> > int &allegro_mouse_x = mouse_x;</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> No, this only works in C++, not C.</FONT>
</P>
<P><FONT SIZE=2>Which is why I only wished :)</FONT>
</P>
<P><FONT SIZE=2>> Well, if we compile two libraries in any case, then what do </FONT>
<BR><FONT SIZE=2>> we gain over</FONT>
<BR><FONT SIZE=2>> having them in two separate distributions (4.0 vs. later), as </FONT>
<BR><FONT SIZE=2>> in Peter's</FONT>
<BR><FONT SIZE=2>> 2nd suggestion? This is practically the same as what you </FONT>
<BR><FONT SIZE=2>> propose, except</FONT>
<BR><FONT SIZE=2>> we don't need any compatibility header.</FONT>
</P>
<P><FONT SIZE=2>It kind of bothers me to have this fork, for no reason that compels me.</FONT>
<BR><FONT SIZE=2>Having a branch with unprefixed stuff that will have to be maintained</FONT>
<BR><FONT SIZE=2>(somehow), without a foreseable end. Merging patches from the HEAD might</FONT>
<BR><FONT SIZE=2>prove more and more troublesome as HEAD evolves, becoming a real burden.</FONT>
</P>
<P><FONT SIZE=2>> > I seem to not find this post. Can anyone forward it to me please ?</FONT>
<BR><FONT SIZE=2>> > I have answers to it, but not Peter's first one, I must have deleted</FONT>
<BR><FONT SIZE=2>> > it somehow (I only have "[AD] to prefix or not to prefix (sigh)")</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> OK, I'll forward it (so other people can stop forwarding it now :-).</FONT>
</P>
<P><FONT SIZE=2>Got it, cheers :)</FONT>
</P>
<P><FONT SIZE=2>From this original post:</FONT>
</P>
<P><FONT SIZE=2>> - Get rid of (some) global variables and states. E.g. `text_mode()'</FONT>
<BR><FONT SIZE=2>> could be an argument to `textout()' rather than a global variable. (I've</FONT>
<BR><FONT SIZE=2>> never understood why background and foreground color should be treated</FONT>
<BR><FONT SIZE=2>> differently in the API.) I don't know if it is worth the effort though.</FONT>
</P>
<P><FONT SIZE=2>I wholeheartedly agree. I'd be glad to help there :)</FONT>
</P>
<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Vincent Penquerc'h </FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C1616E.CC17B500--