isugamedev-devel

[isugamedev-devel] imagelib

[Chad A. <ae...@ae...>]

Kevin, what license is your code under?

Also, I forgot something I'd like out of the library:
- small footprint (doesn't need to be excessively small, but I don't use the
standard C++ library in Windows for this reason, as it incurs a dependency on
msvcp60.dll)
- as few dependencies as possible in the core library (libmng (which subsumes
libpng, zlib, and jpeglib) is okay, but something like DirectX or OpenGL isn't)

Re: [isugamedev-devel] imagelib

[Kevin M. <ke...@vr...>]

why does it matter if we link against ms DLLs?  just because M$ is dumb, 
why should we be?  the DLL is easily available, and I think can be 
distributed with the games we make.

standard C++ is perfectly valid, and is a good thing 
to use.   We could convert what I've got over to use read(), open(), and 
close(), but yuk.  It doesn't matter a lot to me, but... shouldn't std:: 
be inlined?  maybe not the iostreams, huh?  I still don't like using 
non-C++ just because of M$ dumbness with their DLLs.  Seems like we're 
screwing the elegant-ness of our code just to avoid some restriction their 
compiler imposes on us.  do they have a static version of that DLL?  that 
could solve it maybe.

I agree with you, few depends is exactly what I was going for.  but I 
don't take that literally.  I take it to mean only few _third_party_ 
depends.  

my philosohy is, if it comes with the compiler, you can always distribute 
it with the code, no big deal, if it annoys you, choose a different 
compiler.. :)  otherwise, avoid other 3rd party libs as much as possible.  
my PCX, SGI, BMP, TGA loaders are all stand-alone.  the PNG one I wrote 
needs zlib only...


kevin

On Wed, 16 Jan 2002, Chad Austin wrote:

> Kevin, what license is your code under?
> 
> Also, I forgot something I'd like out of the library:
> - small footprint (doesn't need to be excessively small, but I don't use the
> standard C++ library in Windows for this reason, as it incurs a dependency on
> msvcp60.dll)
> - as few dependencies as possible in the core library (libmng (which subsumes
> libpng, zlib, and jpeglib) is okay, but something like DirectX or OpenGL isn't)
> 
> _______________________________________________
> ISUGameDev-devel mailing list
> ISU...@li...
> https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
> 

-- 
@--@---@---@----@-----@------@------@-----@----@---@---@--@
Kevin Meinert                                  __  _   __  
http://www.vrac.iastate.edu/~kevn         \  ||  \| \ /  ` 
Virtual Reality Applications Center        \ ||.-'|--\\    
Howe Hall, Iowa State University, Ames Iowa \||  \|   \`__,
-----------------------------------------------------------

Re: [isugamedev-devel] imagelib

[Ben S. <bs...@vr...>]

i would tend to agree. most uses of the image loading library would 
probably be through C++. thus we'd want to make sure that the library was 
well design from the standpoint of using it through C++.

however, i also agree that the image lib should probably be 
distributed/used as a DLL which i believe is why chad wants a C api. 
regardless we will need a C api to access the code in the library, but we 
could do it as just one simple call to get a class and write the 
application code using interfaces ... ie:

// assume getImageMgr is in the DLL and is really being called using a 
// function pointer obtained through GetProcAddr(..)
ImageManager* mgr = getImageMgr();
Image myImg;
mgr->load( "myimage.pcx", img );

cheers,
-----
Ben Scott
President ISU Game Developers Club
Treasurer ISU Ballroom Dance Company
bs...@ia...



On Wed, 16 Jan 2002, Kevin Meinert wrote:

> 
> why does it matter if we link against ms DLLs?  just because M$ is dumb, 
> why should we be?  the DLL is easily available, and I think can be 
> distributed with the games we make.
> 
> standard C++ is perfectly valid, and is a good thing 
> to use.   We could convert what I've got over to use read(), open(), and 
> close(), but yuk.  It doesn't matter a lot to me, but... shouldn't std:: 
> be inlined?  maybe not the iostreams, huh?  I still don't like using 
> non-C++ just because of M$ dumbness with their DLLs.  Seems like we're 
> screwing the elegant-ness of our code just to avoid some restriction their 
> compiler imposes on us.  do they have a static version of that DLL?  that 
> could solve it maybe.
> 
> I agree with you, few depends is exactly what I was going for.  but I 
> don't take that literally.  I take it to mean only few _third_party_ 
> depends.  
> 
> my philosohy is, if it comes with the compiler, you can always distribute 
> it with the code, no big deal, if it annoys you, choose a different 
> compiler.. :)  otherwise, avoid other 3rd party libs as much as possible.  
> my PCX, SGI, BMP, TGA loaders are all stand-alone.  the PNG one I wrote 
> needs zlib only...
> 
> 
> kevin
> 
> On Wed, 16 Jan 2002, Chad Austin wrote:
> 
> > Kevin, what license is your code under?
> > 
> > Also, I forgot something I'd like out of the library:
> > - small footprint (doesn't need to be excessively small, but I don't use the
> > standard C++ library in Windows for this reason, as it incurs a dependency on
> > msvcp60.dll)
> > - as few dependencies as possible in the core library (libmng (which subsumes
> > libpng, zlib, and jpeglib) is okay, but something like DirectX or OpenGL isn't)
> > 
> > _______________________________________________
> > ISUGameDev-devel mailing list
> > ISU...@li...
> > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
> > 
> 
> 

Re: [isugamedev-devel] imagelib

[Kevin M. <ke...@vr...>]

that's what i had in mind.  thanks for illustrating it so well, ben. :)

On Wed, 16 Jan 2002, Ben Scott wrote:

> i would tend to agree. most uses of the image loading library would 
> probably be through C++. thus we'd want to make sure that the library was 
> well design from the standpoint of using it through C++.
> 
> however, i also agree that the image lib should probably be 
> distributed/used as a DLL which i believe is why chad wants a C api. 
> regardless we will need a C api to access the code in the library, but we 
> could do it as just one simple call to get a class and write the 
> application code using interfaces ... ie:
> 
> // assume getImageMgr is in the DLL and is really being called using a 
> // function pointer obtained through GetProcAddr(..)
> ImageManager* mgr = getImageMgr();
> Image myImg;
> mgr->load( "myimage.pcx", img );
> 
> cheers,
> -----
> Ben Scott
> President ISU Game Developers Club
> Treasurer ISU Ballroom Dance Company
> bs...@ia...
> 
> 
> 
> On Wed, 16 Jan 2002, Kevin Meinert wrote:
> 
> > 
> > why does it matter if we link against ms DLLs?  just because M$ is dumb, 
> > why should we be?  the DLL is easily available, and I think can be 
> > distributed with the games we make.
> > 
> > standard C++ is perfectly valid, and is a good thing 
> > to use.   We could convert what I've got over to use read(), open(), and 
> > close(), but yuk.  It doesn't matter a lot to me, but... shouldn't std:: 
> > be inlined?  maybe not the iostreams, huh?  I still don't like using 
> > non-C++ just because of M$ dumbness with their DLLs.  Seems like we're 
> > screwing the elegant-ness of our code just to avoid some restriction their 
> > compiler imposes on us.  do they have a static version of that DLL?  that 
> > could solve it maybe.
> > 
> > I agree with you, few depends is exactly what I was going for.  but I 
> > don't take that literally.  I take it to mean only few _third_party_ 
> > depends.  
> > 
> > my philosohy is, if it comes with the compiler, you can always distribute 
> > it with the code, no big deal, if it annoys you, choose a different 
> > compiler.. :)  otherwise, avoid other 3rd party libs as much as possible.  
> > my PCX, SGI, BMP, TGA loaders are all stand-alone.  the PNG one I wrote 
> > needs zlib only...
> > 
> > 
> > kevin
> > 
> > On Wed, 16 Jan 2002, Chad Austin wrote:
> > 
> > > Kevin, what license is your code under?
> > > 
> > > Also, I forgot something I'd like out of the library:
> > > - small footprint (doesn't need to be excessively small, but I don't use the
> > > standard C++ library in Windows for this reason, as it incurs a dependency on
> > > msvcp60.dll)
> > > - as few dependencies as possible in the core library (libmng (which subsumes
> > > libpng, zlib, and jpeglib) is okay, but something like DirectX or OpenGL isn't)
> > > 
> > > _______________________________________________
> > > ISUGameDev-devel mailing list
> > > ISU...@li...
> > > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
> > > 
> > 
> > 
> 
> 
> _______________________________________________
> ISUGameDev-devel mailing list
> ISU...@li...
> https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
> 

-- 
@--@---@---@----@-----@------@------@-----@----@---@---@--@
Kevin Meinert                                  __  _   __  
http://www.vrac.iastate.edu/~kevn         \  ||  \| \ /  ` 
Virtual Reality Applications Center        \ ||.-'|--\\    
Howe Hall, Iowa State University, Ames Iowa \||  \|   \`__,
-----------------------------------------------------------

Re: [isugamedev-devel] imagelib

[Chad A. <ae...@ae...>]

> i would tend to agree. most uses of the image loading library would
> probably be through C++. thus we'd want to make sure that the library was
> well design from the standpoint of using it through C++.
> 
> however, i also agree that the image lib should probably be
> distributed/used as a DLL which i believe is why chad wants a C api.
> regardless we will need a C api to access the code in the library, but we
> could do it as just one simple call to get a class and write the
> application code using interfaces ... ie:
> 
> // assume getImageMgr is in the DLL and is really being called using a
> // function pointer obtained through GetProcAddr(..)
> ImageManager* mgr = getImageMgr();
> Image myImg;
> mgr->load( "myimage.pcx", img );

Ack.  You can't do this because an ABI doesn't just specify name mangling
semantics.  The vtable in different compilers has different layouts.  There are
also issues like exception handling, C++ object calling convention (do all Win32
compilers pass |this| in |eax|?).

(sorry I'm so backed up on these e-mails, I've been pretty busy tonight)

Re: [isugamedev-devel] imagelib

[Chad A. <ae...@ae...>]

> why does it matter if we link against ms DLLs?  just because M$ is dumb,
> why should we be?  the DLL is easily available, and I think can be
> distributed with the games we make.

It's not on Win95 machines by default, and therefore adds to the footprint of
the library.  For gamedev purposes, I wouldn't mind shipping the MS C++ runtime
as well, but I think it's rather pretentious to make a 200k DLL depend on the
400k msvcp60.dll for a few simple things like strings and vectors which can
easily be done without.

The way I usually temporarily go about this is defining library::string and
library::list and library::vector classes that are as close to source-compatible
with the standard C++ library as possible until the runtime support is better,
at which point I'll just typedef the std:: classes.

> standard C++ is perfectly valid, and is a good thing
> to use.   We could convert what I've got over to use read(), open(), and
> close(), but yuk.  It doesn't matter a lot to me, but... shouldn't std::
> be inlined?  maybe not the iostreams, huh?  I still don't like using
> non-C++ just because of M$ dumbness with their DLLs.  Seems like we're
> screwing the elegant-ness of our code just to avoid some restriction their
> compiler imposes on us.  do they have a static version of that DLL?  that
> could solve it maybe.

VC++ strings aren't 100% inlined either.  You can do static builds, but you
can't statically link to libc++ and dynamically to libc at the same time.  :(  I
agree, it does suck, but a lot of thing sucks and sometimes it's worth it to
work around them.  And ideally, you should have already abstracted out I/O so
you can support UTF-8 and whatnot in Windows.  ;)

> I agree with you, few depends is exactly what I was going for.  but I
> don't take that literally.  I take it to mean only few _third_party_
> depends.

Okay.  Either way, it's pretty easy to get away with not using std::string and
std::vector, especially when the benefits are there.

> my philosohy is, if it comes with the compiler, you can always distribute
> it with the code, no big deal, if it annoys you, choose a different
> compiler.. :)  otherwise, avoid other 3rd party libs as much as possible.
> my PCX, SGI, BMP, TGA loaders are all stand-alone.  the PNG one I wrote
> needs zlib only...

If that's your philosophy, that's fine by me.  :)  But I don't go by that
philosophy.  ;)  There are other things to take into account, and DLL/download
size (unfortunately) is one of them.

At least I don't follow the Mozilla C++ coding rules! 
http://www.mozilla.org/hacking/portable-cpp.html

[isugamedev-devel] re[6]: imagelib

[Kevin M. <ke...@vr...>]

> The way I usually temporarily go about this is defining library::string and
> library::list and library::vector classes that are as close to source-compatible

you write your own?  yuk...  i think code reuse is more important than lib 
size.  these really should be inlined.  i guess we 
could use stlport instead, but that might not be good either (whole new 
set of problems).


200k dll depending on a 400k dll isn't bad or pretentious.  more of my 
philosophy:  size doesn't matter, functionality does.  I think it's really 
powerful if a lib gives you an easy interface with as little code to 
maintain as possible.  this usually means more code behind the scenes, 
which I think is ok, and explains the 200k/400k thing as totally ok. 

I think it is especially ok when you're only adding on an extra 400k, 
400k is small if you consider that you're getting well tested code 
that you don't have to personally maintain.  I'd rather invest 
my time into the game, and not into string, vector, list code. :(

kevin


On Wed, 16 Jan 2002, Chad Austin wrote:

> > why does it matter if we link against ms DLLs?  just because M$ is dumb,
> > why should we be?  the DLL is easily available, and I think can be
> > distributed with the games we make.
> 
> It's not on Win95 machines by default, and therefore adds to the footprint of
> the library.  For gamedev purposes, I wouldn't mind shipping the MS C++ runtime
> as well, but I think it's rather pretentious to make a 200k DLL depend on the
> 400k msvcp60.dll for a few simple things like strings and vectors which can
> easily be done without.
> 
> The way I usually temporarily go about this is defining library::string and
> library::list and library::vector classes that are as close to source-compatible
> with the standard C++ library as possible until the runtime support is better,
> at which point I'll just typedef the std:: classes.
> 
> > standard C++ is perfectly valid, and is a good thing
> > to use.   We could convert what I've got over to use read(), open(), and
> > close(), but yuk.  It doesn't matter a lot to me, but... shouldn't std::
> > be inlined?  maybe not the iostreams, huh?  I still don't like using
> > non-C++ just because of M$ dumbness with their DLLs.  Seems like we're
> > screwing the elegant-ness of our code just to avoid some restriction their
> > compiler imposes on us.  do they have a static version of that DLL?  that
> > could solve it maybe.
> 
> VC++ strings aren't 100% inlined either.  You can do static builds, but you
> can't statically link to libc++ and dynamically to libc at the same time.  :(  I
> agree, it does suck, but a lot of thing sucks and sometimes it's worth it to
> work around them.  And ideally, you should have already abstracted out I/O so
> you can support UTF-8 and whatnot in Windows.  ;)
> 
> > I agree with you, few depends is exactly what I was going for.  but I
> > don't take that literally.  I take it to mean only few _third_party_
> > depends.
> 
> Okay.  Either way, it's pretty easy to get away with not using std::string and
> std::vector, especially when the benefits are there.
> 
> > my philosohy is, if it comes with the compiler, you can always distribute
> > it with the code, no big deal, if it annoys you, choose a different
> > compiler.. :)  otherwise, avoid other 3rd party libs as much as possible.
> > my PCX, SGI, BMP, TGA loaders are all stand-alone.  the PNG one I wrote
> > needs zlib only...
> 
> If that's your philosophy, that's fine by me.  :)  But I don't go by that
> philosophy.  ;)  There are other things to take into account, and DLL/download
> size (unfortunately) is one of them.
> 
> At least I don't follow the Mozilla C++ coding rules! 
> http://www.mozilla.org/hacking/portable-cpp.html
> 
> _______________________________________________
> ISUGameDev-devel mailing list
> ISU...@li...
> https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
> 

-- 
@--@---@---@----@-----@------@------@-----@----@---@---@--@
Kevin Meinert                                  __  _   __  
http://www.vrac.iastate.edu/~kevn         \  ||  \| \ /  ` 
Virtual Reality Applications Center        \ ||.-'|--\\    
Howe Hall, Iowa State University, Ames Iowa \||  \|   \`__,
-----------------------------------------------------------