aeongdk-developers — AeonGDK Developers

[aeDev] Hello out there!

[Nicholas D. <mas...@ho...>]

Hello :)

    I just "re-discovered" my Aeon e-mail folder. Whatever happened to =
our nice little project? About 10 months ago we just kind of stopped =
working on it. Unless one of you guys... Bob or Ben or Justin or =
Edward... have been secretly working on it, and it's now an extremely =
powerful multi-purpose game engine... who knows? I haven't done a CVS =
update in about a year :)

    It seemed to be going so well, too. I guess that it's safe to say =
that Aeon is basically dead. Maybe we could revive it sometime in the =
far future. Or maybe not. Whatever. What do you guys think? Yes? Not in =
your lifetime? Let me know.

    Thanks,
        Nick

Re: [aeDev] update

[Bob <oha...@vi...>]

Nick Davies wrote:
> Dependencies - the dependencies do not work because in the depend.d file,
> only relative filenames(ex: keyboard.o) are given instead of absolute
> names(ex: src/input/keyboard.o). This means that the makefile is, in effect,
> ignoring all the contents of this file! Needs to be fixed.

I'll take a look.

> Install - the problem the way that the dependency for this target is, every
> time we add a new directory the user will have to manually delete the
> COMP_DIR/include/aeon directory and then make install, which is not good.
> 
> Any ideas?

Allegro has a makefile target for each dirctory, with the build rule
being $(MKDIR) dir.

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

[aeDev] update

[Nick D. <mas...@ho...>]

Well... I've just added mouse functions to Aeon, and now only the driver
files(src/drivers/allegro/*.cpp) will include allegro.h, so that the user's
programs will not be cluttered by all the things defined in allegro.h (if
they want allegro-specific functions, they could include allegro.h)

Here are a few immediate problems that need to be corrected soon:

Dependencies - the dependencies do not work because in the depend.d file,
only relative filenames(ex: keyboard.o) are given instead of absolute
names(ex: src/input/keyboard.o). This means that the makefile is, in effect,
ignoring all the contents of this file! Needs to be fixed.
Install - the problem the way that the dependency for this target is, every
time we add a new directory the user will have to manually delete the
COMP_DIR/include/aeon directory and then make install, which is not good.

Any ideas?

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] aeColor_t issue

[Bob <oha...@vi...>]

Nick Davies wrote:
> 
> Before I start: I just remembered that your -Iinclude thing will not work
> for files in the include/ directory. It is fine for files in the src/
> directory but for those in include/ it won't work.

That's what I was affraid of. It shouldn't matter much though - relative
include paths are cleaner IMO.

> I'm going to change that
> soon... and for now let's just make aeColor_t a long until we write that
> small program.

Ok.

> 
> Also... I noticed that aeColor is basically a set of static functions, and
> there would not be a single reason to actually declare an instance of that
> class. I think we should put the aeColor functions into a namespace, because
> it's the same syntax anyway, and namespaces are more flexible.

Right.

[snip]
> Sounds good. But seriously, isn't 'long' virtually guaranteed(99.9% of the
> time) to be 32 bits?

The same way that Intel makes most Intel-compatible chips :-P

[snip]
> > Works. However, we'd have to delete the whole compdir include tree this
> > everytime we add a new directory.
> 
> How very true. I'll try to think of something different... how does allegro
> do it?

It has a makefile target for every directory. This isn't a problem for
Allegro since it only has one or two directories to worry about, unlike
Aeon.


--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] aeColor_t issue

[Nick D. <mas...@ho...>]

Before I start: I just remembered that your -Iinclude thing will not work
for files in the include/ directory. It is fine for files in the src/
directory but for those in include/ it won't work. I'm going to change that
soon... and for now let's just make aeColor_t a long until we write that
small program.

Also... I noticed that aeColor is basically a set of static functions, and
there would not be a single reason to actually declare an instance of that
class. I think we should put the aeColor functions into a namespace, because
it's the same syntax anyway, and namespaces are more flexible.

> > > At worst, we can just change the type of aeColor_t and not have to go
> > > again through the source and change all the uint32_t...
> >
> > There's got to be another way... couldn't we use chars for each channel
or
> > something?
>
> And 8/15/16bpp? That wouldn't work right.

You're right.

> > There has to be at least one way for choosing the size of your int's on
> > every compiler. We could just make a types.h file, like you said, detect
the
> > compiler, and go from there, couldn't we?
>
> Yes of course. Then we'd just have aeon.h include type.h, which would be
> created by the makefile and be compiler specific.
> We can have a small program that detects the compiler (using #defines),
> and writes the file as it knows (for example, Mingw can be automatically
> detected as having uint32_t if stdtype.h exists, etc). We could also add
> an autodetection mode based on sizeof() for those compilers that we
> don't know.

Sounds good. But seriously, isn't 'long' virtually guaranteed(99.9% of the
time) to be 32 bits?

> > Also, I just updated the makefile so that make install won't try to
> > re-create the directories if they already exist, but you will have to
delete
> > the compdir/include/Aeon/ directory manually before running the new make
> > install for the first time.
>
> Works. However, we'd have to delete the whole compdir include tree this
> everytime we add a new directory.

How very true. I'll try to think of something different... how does allegro
do it?

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] aeColor_t issue

[Bob <oha...@vi...>]

Nick Davies wrote:
[snip]
> > At worst, we can just change the type of aeColor_t and not have to go
> > again through the source and change all the uint32_t...
> 
> There's got to be another way... couldn't we use chars for each channel or
> something?

And 8/15/16bpp? That wouldn't work right.

> There has to be at least one way for choosing the size of your int's on
> every compiler. We could just make a types.h file, like you said, detect the
> compiler, and go from there, couldn't we?

Yes of course. Then we'd just have aeon.h include type.h, which would be
created by the makefile and be compiler specific.
We can have a small program that detects the compiler (using #defines),
and writes the file as it knows (for example, Mingw can be automatically
detected as having uint32_t if stdtype.h exists, etc). We could also add
an autodetection mode based on sizeof() for those compilers that we
don't know.

> Also, I just updated the makefile so that make install won't try to
> re-create the directories if they already exist, but you will have to delete
> the compdir/include/Aeon/ directory manually before running the new make
> install for the first time.

Works. However, we'd have to delete the whole compdir include tree this
everytime we add a new directory.

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] aeColor_t issue

[Nick D. <mas...@ho...>]

> Yes, but we want it to be exactly 4 bytes long. So what I propose is a
> system like Allegro's mmxtest, where the makefile would determine what
> is there and create a header file for us. Otherwise, we'll end up with
> padding. In 32bpp mode, Allegro takes up sizeof(long) for each pixel, so
> in 64 bit, it would waste half the space.
>
> At worst, we can just change the type of aeColor_t and not have to go
> again through the source and change all the uint32_t...

There's got to be another way... couldn't we use chars for each channel or
something?

There has to be at least one way for choosing the size of your int's on
every compiler. We could just make a types.h file, like you said, detect the
compiler, and go from there, couldn't we?

Also, I just updated the makefile so that make install won't try to
re-create the directories if they already exist, but you will have to delete
the compdir/include/Aeon/ directory manually before running the new make
install for the first time.

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] aeColor_t issue

[Bob <oha...@vi...>]

Nick Davies wrote:
> 
> I thought I'd start a new thread... I mean hey, why not? ;)
> 
> What if uint32_t was replaced by long(since uint32_t isn't really standard,
> or highly implemented anyway)? Isn't long guaranteed to be at least four
> bytes long?

Yes, but we want it to be exactly 4 bytes long. So what I propose is a
system like Allegro's mmxtest, where the makefile would determine what
is there and create a header file for us. Otherwise, we'll end up with
padding. In 32bpp mode, Allegro takes up sizeof(long) for each pixel, so
in 64 bit, it would waste half the space.

At worst, we can just change the type of aeColor_t and not have to go
again through the source and change all the uint32_t...

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

> [snip]
> > That's true.
> > Oh right, about that... uint32_t isn't declared on my system. In fact,
> > neither is stdint.h. I don't think I have an old compiler... what
compiler
> > are you using?
>
> Mingw32.
> G:\home\aeon\>gcc -v
> Reading specs from g:\mingw32\lib\gcc-lib\mingw32\2.95.2\specs
> gcc driver version 2.95.2 19991024 (release) executing gcc version
> 2.95.2-mingw
> snapshot 20010329
>
> Those type defines are supposed to be C9X standard. I'll add a types.h
> in aeon/include/ which will define it's own if they're not defined.

Hmm...
C:\prog>gcc -v
Reading specs from
C:\MINGW32\BIN\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\specs
gcc version 2.95.2 19991024 (release)

I guess you have a newer 'snapshot'.

Also, if you're going to include <stdint.h> make sure to put that in aeon.h
instead of just in color.h .
--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Bob <oha...@vi...>]

Nick Davies wrote:
[snip]
> But, seriously, I think we should keep everything where it is right now, and
> just add -Iinclude to the path, because I see now that it would work. 

Ok ok. I'll try compiliing stuff outside the aeon tree to see if the
paths are correct.

[snip]
> That's true.
> Oh right, about that... uint32_t isn't declared on my system. In fact,
> neither is stdint.h. I don't think I have an old compiler... what compiler
> are you using?

Mingw32. 
G:\home\aeon\>gcc -v
Reading specs from g:\mingw32\lib\gcc-lib\mingw32\2.95.2\specs
gcc driver version 2.95.2 19991024 (release) executing gcc version
2.95.2-mingw
snapshot 20010329

Those type defines are supposed to be C9X standard. I'll add a types.h
in aeon/include/ which will define it's own if they're not defined.

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

[aeDev] aeColor_t issue

[Nick D. <mas...@ho...>]

I thought I'd start a new thread... I mean hey, why not? ;)

What if uint32_t was replaced by long(since uint32_t isn't really standard,
or highly implemented anyway)? Isn't long guaranteed to be at least four
bytes long?

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

> There are too many interdependencies I think.

There are no more interdependencies than necessary, in my opinion.

> Ok, here's the new (propsed) structure:
> aeon/include/  (has aeon.h)
> aeon/include/aeon/ (rest of headers)
>
> Then this could be installed in:
>
> compdir/include/aeon.h
> compdir/include/aeon/rest_of_headers
>
> And in Aeon source files, we'd have:
>
> #include "aeon/graphics/driver/allegro/graphics.h"
>

Nope, it would be "aeon/drivers/allegro/graphics.h"

> instead of the current:
>
> #include "../../../include/graphics/driver/allegro/graphics.h"

Nope, it's "../../../include/drivers/allegro/graphics.h"

> Ok, how's this: we get rid of the graphics + input subdirs. We put those
> files in their parent.
>
> We'd then have:
>
> #include "aeon/driver/allegro/graphics.h"
> and
> #include "aeon/graphics.h"
>
> Much cleaner.
>
> There shouldn't be any comflicts either, since the input code shouldn't
> have iles with the same name as graphics, and vice versa.

The only one I can think of is "keyboard" having both a musical and input
device sense. But that's nit-picking a little ;)

But, seriously, I think we should keep everything where it is right now, and
just add -Iinclude to the path, because I see now that it would work. I
don't want to go through another move... besides, the folders help keep the
different components of Aeon nicely separated.

> > Oh alright, when you put it that way... why not just make it uint32_t
> > instead of aeColor_t then? I was never a big fan of all those glFloat
and
> > glUInt stuff in OpenGL... but then again, it might make everything more
> > clear.
>
> In case we every change the color type. We'd then just need to change
> the definition of aeColor_t (for 64bit screen modes let's say) and not
> uint32_t (thankfully) - going through a 10000 line source code trying to
> figure out if this particular uint32_t needs to be changed or not is not
> fun.

That's true.
Oh right, about that... uint32_t isn't declared on my system. In fact,
neither is stdint.h. I don't think I have an old compiler... what compiler
are you using?

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

> > Not to complain, of course... anyway, I fixed the small error.
>
> Argh! You fixed it wrong :-P  I re-fixed it.

Umm.. [childish voice]nuh-uh YOU were the one who fixed it wrong and I have
a bulletproof vest and your lasers can't go through it because it's made of
mirrors that are made out of diamond... hey... I SHOT YOU FIRST so YOU're
the one who's dead!!![/childish voice]

Heh... I used to do that all the time as a wee child... anyway, back to
business.

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Bob <oha...@vi...>]

Nick Davies wrote:
> 
> Big problem!!!!!!
> Since you declare COMP_DIR to be MINGDIR in makevars.mgw, that means that if
> someone has neither COMP_DIR or MINGDIR defined (like me) ends up having
> COMP_DIR defined as nothing, which, of course, is a disaster, for some
> reason.

Ok, that's because the COMP_DIR testing is done at the wrong place. It's
fixed now.


> Also, I've never been the type of person to trust deltree /y, ever.

I was desperate. You're right, I'll get rid of it, it's too insecure.

> Not to complain, of course... anyway, I fixed the small error.

Argh! You fixed it wrong :-P  I re-fixed it.

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

> Big problem!!!!!!
> Since you declare COMP_DIR to be MINGDIR in makevars.mgw, that means that
if
> someone has neither COMP_DIR or MINGDIR defined (like me) ends up having
> COMP_DIR defined as nothing, which, of course, is a disaster, for some
> reason. Also, I've never been the type of person to trust deltree /y,
ever.

Not to complain, of course... anyway, I fixed the small error.

I like posting :)

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Bob <oha...@vi...>]

Nick Davies wrote:
[snip]
> 
> Hmm... I don't like it. That could cause conflicts of some sort... 

If it does, than it's an organisational error from our part - we
shouldn't have src/graphics.h and include/graphics.h (for example).

> and
> doesn't that mean that anyone who compiles a program with "aeon.h" in it
> will have to add -Iinclude to their commandline for their program to work?

No! That's only for building the library. Oh, I see what you mean - aeon
installs its headers in compdir/include/aeon... We're going to have to
do the same for aeon itself: have include/aeon/stuff, the same way
Allegro does it. There are too many interdependencies I think. If I
remove the -Iinclude flag, then programs externally built will have path
problems (urgh).

Ok, here's the new (propsed) structure:
aeon/include/  (has aeon.h)
aeon/include/aeon/ (rest of headers)

Then this could be installed in:

compdir/include/aeon.h
compdir/include/aeon/rest_of_headers

And in Aeon source files, we'd have:

#include "aeon/graphics/driver/allegro/graphics.h"

instead of the current:

#include "../../../include/graphics/driver/allegro/graphics.h"

Yuk - it's not that much better either...
Ok, how's this: we get rid of the graphics + input subdirs. We put those
files in their parent.

We'd then have:

#include "aeon/driver/allegro/graphics.h"
and
#include "aeon/graphics.h"

Much cleaner.

There shouldn't be any comflicts either, since the input code shouldn't
have iles with the same name as graphics, and vice versa.


> Oh alright, when you put it that way... why not just make it uint32_t
> instead of aeColor_t then? I was never a big fan of all those glFloat and
> glUInt stuff in OpenGL... but then again, it might make everything more
> clear.

In case we every change the color type. We'd then just need to change
the definition of aeColor_t (for 64bit screen modes let's say) and not
uint32_t (thankfully) - going through a 10000 line source code trying to
figure out if this particular uint32_t needs to be changed or not is not
fun.

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

Big problem!!!!!!
Since you declare COMP_DIR to be MINGDIR in makevars.mgw, that means that if
someone has neither COMP_DIR or MINGDIR defined (like me) ends up having
COMP_DIR defined as nothing, which, of course, is a disaster, for some
reason. Also, I've never been the type of person to trust deltree /y, ever.

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

> > Hold on... I've just read your last message again ;)
> >
> > First, thanks for kicking out the bugs in the makfiles(I didn't know
there
> > were bugs, except maybe with make install and the fact that the
libraries
> > are always compiled, even if they're up to date, which I will fix if you
> > haven't already).
>
> These are the two I haven't fixed yet.

Ok, I'll check them out.

> >
> > Second, what is the -Iinclude thing you've added to the command line
for?
>
> It adds the include directory in the search path for #include. So now we
> can just do #include "drivers/graphics.h" instead of #include
> "../../include/drivers/graphics.h"

Hmm... I don't like it. That could cause conflicts of some sort... and
doesn't that mean that anyone who compiles a program with "aeon.h" in it
will have to add -Iinclude to their commandline for their program to work?

> > There are two things you should(in my opinion) change:
> >
> > color.cpp should go in the src/graphics/ directory, and color.h should
go in
> > the include/graphics/ directory (you have color.cpp in the src/
directory
> > now, that is meant only for files that should be compiled with every
version
> > of the library(i.e. you wouldn't want aeColor if you were only using the
> > input or sound portions of Aeon))
>
> Sure thing.
>
> > Also, I think you should just have aeColor be called aeColor, instead of
> > aeColor_t. The _t is usually just for standard C/C++ libraries, and
although
> > it would be nice if Aeon became part of standard C++, I don't think it's
> > gonna happen ;)
>
>
> aeColor is a class. aeColor_t is synonymous with uint32_t - it's the
> return type for colors.

Oh alright, when you put it that way... why not just make it uint32_t
instead of aeColor_t then? I was never a big fan of all those glFloat and
glUInt stuff in OpenGL... but then again, it might make everything more
clear.

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Bob <oha...@vi...>]

Nick Davies wrote:
> 
> Hold on... I've just read your last message again ;)
> 
> First, thanks for kicking out the bugs in the makfiles(I didn't know there
> were bugs, except maybe with make install and the fact that the libraries
> are always compiled, even if they're up to date, which I will fix if you
> haven't already).

Oh yeah, forgot to say. I made the makefiles a little smarter - they try
to guess what COMP_DIR is ($(DJDIR) or $(MINGDIR)).
[snip]

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

> Ok, I've done that (defined AE_SORUCE in color.cpp), and I get a
> compiled lib. However, I now get this error while compiling the test
> program:
>
> g++ -s -O2 -Wall -Werror tests/aeontest.cpp -o tests/aeontest.exe
> -Iinclude -lae
> on -lalleg -laeon -lstdc++

First of all, you could simplify that command line by removing the
second -laeon and -lstdc++ (g++ automatically links with lstdc++ for you)

> J:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccuYaaaa.o(.text+0x21c):aeontest.cpp:
> undefin
> ed reference to `aeColor::RGBp(unsigned char, unsigned char, unsigned
> char)'
>
> (repeat 4 times)
>
> Removing the 'inline' keywords from the class definition fixed it. But
> it makes aeColor slower.

That's probably because you put aeColor::RGBp() in color.cpp. When you have
an inline function, the compiler treats it just like a macro function with
type checking, so you'll have to put aeColor::RGBp in color.h so that the
compiler will see it when aeontest.cpp is being compiled.

> Note: I've fixed a lot of bugs in the makefiles related to
> Mingw32+Win2k. There's only one left though: make install doesn't work -
> it bombs out with an error because the directory that it tries to create
> already exists. I tried inserting a deltree command, but it doesn't do
> its job for some reason...

Dude... under Win98, 'directory already exists' is not considered an
error... you could probably fix that by making the directory a dependency of
make install. I'll try to go do that now.

> I commited my changes.

Yay!

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Bob <oha...@vi...>]

Nick Davies wrote:
> 
> Hold on... I've just read your last message again ;)
> 
> First, thanks for kicking out the bugs in the makfiles(I didn't know there
> were bugs, except maybe with make install and the fact that the libraries
> are always compiled, even if they're up to date, which I will fix if you
> haven't already).

These are the two I haven't fixed yet.

> 
> Second, what is the -Iinclude thing you've added to the command line for?

It adds the include directory in the search path for #include. So now we
can just do #include "drivers/graphics.h" instead of #include
"../../include/drivers/graphics.h"

> There are two things you should(in my opinion) change:
> 
> color.cpp should go in the src/graphics/ directory, and color.h should go in
> the include/graphics/ directory (you have color.cpp in the src/ directory
> now, that is meant only for files that should be compiled with every version
> of the library(i.e. you wouldn't want aeColor if you were only using the
> input or sound portions of Aeon))

Sure thing.

> Also, I think you should just have aeColor be called aeColor, instead of
> aeColor_t. The _t is usually just for standard C/C++ libraries, and although
> it would be nice if Aeon became part of standard C++, I don't think it's
> gonna happen ;)


aeColor is a class. aeColor_t is synonymous with uint32_t - it's the
return type for colors.

> And, when it is used for standard libraries, the _t prefix
> usually signifies that the type has no member functions(which is why clock_t
> has a _t but vector, list, etc. do not)
> 
> Also, be sure to put a declaration of aeColor in the include/classes.h file.

Check.


--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] Error while compiling

[Bob <oha...@vi...>]

Nick Davies wrote:
> 
> Gasp!
> 
> Seriously, this error is easily fixed:
> 
> Since you've no doubt declared AE_SOURCE at the top of colour.h, this means
> that no other class headers will be included in tha tfile(AE_SOURCE is
> basically just a way to keep each file from having too many dependencies).
> This means that, although 'aeGraphicsDriver* aeGraphics' is declared in
> aeon.h, the compiler does not know what an aeGraphicsDriver is when you're
> compiling colour.cpp. In short, you have to include the aeGraphicsDriver
> header file in colour.h. If you do this, the file should be compiled without
> a hitch.

Ok, I've done that (defined AE_SORUCE in color.cpp), and I get a
compiled lib. However, I now get this error while compiling the test
program:

g++ -s -O2 -Wall -Werror tests/aeontest.cpp -o tests/aeontest.exe
-Iinclude -lae
on -lalleg -laeon -lstdc++
J:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccuYaaaa.o(.text+0x21c):aeontest.cpp:
undefin
ed reference to `aeColor::RGBp(unsigned char, unsigned char, unsigned
char)'

(repeat 4 times)

Removing the 'inline' keywords from the class definition fixed it. But
it makes aeColor slower.


Note: I've fixed a lot of bugs in the makefiles related to
Mingw32+Win2k. There's only one left though: make install doesn't work -
it bombs out with an error because the directory that it tries to create
already exists. I tried inserting a deltree command, but it doesn't do
its job for some reason...

I commited my changes.

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

Hold on... I've just read your last message again ;)

First, thanks for kicking out the bugs in the makfiles(I didn't know there
were bugs, except maybe with make install and the fact that the libraries
are always compiled, even if they're up to date, which I will fix if you
haven't already).

Second, what is the -Iinclude thing you've added to the command line for?

There are two things you should(in my opinion) change:

color.cpp should go in the src/graphics/ directory, and color.h should go in
the include/graphics/ directory (you have color.cpp in the src/ directory
now, that is meant only for files that should be compiled with every version
of the library(i.e. you wouldn't want aeColor if you were only using the
input or sound portions of Aeon))

Also, I think you should just have aeColor be called aeColor, instead of
aeColor_t. The _t is usually just for standard C/C++ libraries, and although
it would be nice if Aeon became part of standard C++, I don't think it's
gonna happen ;) And, when it is used for standard libraries, the _t prefix
usually signifies that the type has no member functions(which is why clock_t
has a _t but vector, list, etc. do not)

Also, be sure to put a declaration of aeColor in the include/classes.h file.

Thanks.

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

Re: [aeDev] Error while compiling

[Nick D. <mas...@ho...>]

Gasp!

Seriously, this error is easily fixed:

Since you've no doubt declared AE_SOURCE at the top of colour.h, this means
that no other class headers will be included in tha tfile(AE_SOURCE is
basically just a way to keep each file from having too many dependencies).
This means that, although 'aeGraphicsDriver* aeGraphics' is declared in
aeon.h, the compiler does not know what an aeGraphicsDriver is when you're
compiling colour.cpp. In short, you have to include the aeGraphicsDriver
header file in colour.h. If you do this, the file should be compiled without
a hitch.


One other thing... I just remembered that all the aeon files that were
recently moved from src/ to include/ still have their inclusion guards as
'#define AEON_SRC_GRAPHICS_LINE2P_H' and the like. We'll have to replace the
'SRC' with 'INCLUDE', if just for the sake of clarity. I think I'll go do
that right now... and, Bob, if aeColor's inclusion guard is not already like
that, you should change it, too.

Sorry if this e-mail is unclear... my engrish is suffewing at the momen ;)

--
~Nick (MasterGoodbytes)
e-mail:    mas...@ho...
website: http://www.binarysurge.com/

[aeDev] Error while compiling

[Bob <oha...@vi...>]

I've changed just about every file when adding the color class
(including the makefiles, with some bugs kicked out). But now, I'm
getting weird compilation errors:

g++ -c -s -O2 -Wall -Werror src/color.cpp -o obj/mingw32/color.o
-Iinclude
In file included from include/drivers/../drivers.h:21,
                 from include/drivers/../aeon.h:34,
                 from include/drivers/graphics.h:10,
                 from src/color.cpp:1:
include/drivers/../drivers/allegro/graphics.h:24: base class
`aeGraphicsDriver'
has incomplete type

And class aeGraphicsDriver is:

class aeGraphicsDriver : public aeDriver
{
protected:
    int color_bits[NumColorComponents];    // const defined in color.h
    int color_shift[NumColorComponents];
    aeColor_t color_mask[NumColorComponents];

public:
    aeGraphicsDriver            ()  {}
    virtual ~aeGraphicsDriver   ()  {}

    virtual bool    Install     ()  { return false; }
    virtual bool    Remove      ()  { return false; }

    virtual bool    SetScreenMode   (int Width, int Height, int ColDepth
= 8)   { return false; }

    virtual void    RenderPoint2p   (int X, int Y, aeColor_t C)   {}
    virtual void    RenderLine2p    (int X1, int Y1, int X2, int Y2,
aeColor_t C) {}
    virtual void    RenderRect2p    (int X1, int Y1, int X2, int Y2,
aeColor_t C) {}
    virtual void    RenderCircle2p  (int X, int Y, int R, aeColor_t C)
{}
    
    int GetColorShift(int c)         { return color_shift[c]; }
    int GetColorBits(int c)          { return color_bits[c];  }
    aeColor_t GetColorMask(int c)    { return color_mask[c];  }
};

--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/