Menu
▾
▴
isugamedev-devel — all discussion
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(27) |
Nov
(3) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(71) |
Feb
(27) |
Mar
(17) |
Apr
(18) |
May
(2) |
Jun
(11) |
Jul
(2) |
Aug
|
Sep
|
Oct
(11) |
Nov
(12) |
Dec
|
| 2003 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(2) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
| 2004 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Chad A. <ae...@ae...> - 2002-01-17 01:02:14
|
> so a c interface on top of a c++ code base is a problem? No, that's not a problem. (? what do you mean?) As long the cross-DLL calls are C, we're okay. > Can we put a COM interface on top of a C++ interface? Sure. > I'd rather support an XPCOM interface than a C one... XPCOM is one of those huge dependencies that I'd like to stay away from. > it would be nice to post binaries that work for everyone no matter what... > i still think it is important to have a nice interface (opject oriented). > > can you think of a compromise? Sure. Completely inline classes in the header work just fine. Look at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/audiere/audiere/audiere.h?rev=1.7&content-type=text/vnd.viewcvs-markup I think it's pretty clear that we have different priorities for this library. I'd rather not duplicate effort, but maybe that'd be easier. |
|
From: Chad A. <ae...@ae...> - 2002-01-17 00:56:20
|
> 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) |
|
From: Chad A. <ae...@ae...> - 2002-01-17 00:53:15
|
> 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 |
|
From: Kevin M. <ke...@vr...> - 2002-01-16 23:55:23
|
can we use our own com-like thing?
as i understand COM, all you need is:
- abstract interface
- implementations for that interface
- factory to give you those implementations
- keep the interface the same (don't change it or you'll break bin
compatibility)
this would (hopefully?) let us keep a small foot print, and not depend on
outside libs (like xpcom, or COM), and avoid the nasty C style OO
interface that we'd need to convert to.
I know this works with VC++, but will it port to other compilers?
kevin
On Wed, 16 Jan 2002, Chad Austin wrote:
> > I'd prefer a c API that wraps the C++ one, does it really matter? the C
> > api would be the one to avoid IMHO, so why build around it? besides,
> > dllexport will export C++, so it isn't a big deal. if you need image
> > plugins, I would write C wrappers that allow you to search for the C
> > symbols for the load method. Otherwise, why not C++?
>
> As I've said before, it is a big deal because there is no standard C++ ABI
> (except for the ia64 one, which isn't even really relevant yet). "What does
> that mean?" It means if I create a DLL in VC++, it won't work in gcc or Borland
> C++ or any other compiler with a different way of representing objects. "So?
> Everybody uses VC++ anyway." True, but what if VS .NET has a different ABI (I
> haven't tested this, but it's a possibility. gcc 3.0 and 2.9x have different
> the vtable layouts) and people start upgrading? Programs that are using the DLL
> will just start crashing. Also, VC++ has different allocators for debug and
> release builds. If a release build does something like ...
>
> Object* object = CreateObject(); // object factory implemented in debug DLL
> delete object;
>
> ... you're almost assured a crash.
>
> I guess my point is, Microsoft enforces two ABIs in Windows: C and COM. We
> should comply with at least one of them. (preferably C, as it's simpler)
>
> The way Audiere keeps a solid internal design *and* a nice external C++ API is
> on the inside having things like:
>
> ADR_CONTEXT ADR_CALL AdrCreateContext() {
> return (ADR_CALL)(new InternalContext);
> }
>
> ...
>
> ADR_STREAM ADR_CALL AdrOpenStream(ADR_CONTEXT c, const char* filename) {
> Context* context = (ADR_CONTEXT)c;
> return (ADR_STREAM)(context->openStream(filename));
> }
>
> and on the outside:
>
> inline Context* CreateContext() {
> ADR_CONTEXT c = AdrCreateContext();
> return (c ? new Context(c) : 0);
> };
>
> class Context {
> private:
> Context(ADR_CONTEXT c) : m_c(c) { }
> public:
> ~Context() { AdrDestroyContext(m_c); }
> Stream* openStream(const char* filename) {
> ADR_STREAM s = AdrOpenStream(m_c, filename);
> return (s ? new Stream(s) : 0);
> }
> }
>
> > PNG is good. JPG is bad (lossy) but good at compression (nice) I'd avoid
> > it so that the game looks good, but if you want to make a tiny little
> > demo it might be good to have. PCX is good.
>
> JPEG isn't bad. It just has a different usage domain. Photographic PNGs are
> HUGE, and high-quality JPEGs are very useful for prerendered backgrounds and
> such.
>
> > a separate SF project for it? I'm ok with that. are we sure there isn't
> > ANYTHING else out there? The strong points of my lib is the C++ I
> > think...
>
> You'd really think there would be other libs, but the only major one I've seen
> is openil (devil), and it doesn't impress me at all. I spent a lot of time
> looking on SourceForge and freshmeat, and haven't found much. I guess there's
> FreeImage, but it's too... Win32... (there is a Linux port, but it doesn't use
> autoconf/automake and thus requires makefile tweaking... ewww)
>
> I guess there are a lot of image libraries, but none that satisfy all of the
> requirements I have.
>
> > I think I do simple conversions already which can be migrated from the
> > Image class to a util lib. simple as in 24 to 32bit and vice versa.
>
> Sounds good to me.
>
> Just a little related note:
>
> libpng is a pain in the ass because if you just want to load any PNG image into
> an RGBA buffer, you have to explicitly handle each bit depth and every possible
> transparency setting (transparent palette entries, palette entries with alpha,
> separate alpha buffers, etc.). libmg can load PNGs too, but handles that for
> you. You specify the format you want your image data in, and that's what it
> delivers.
>
> _______________________________________________
> 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 \|| \| \`__,
-----------------------------------------------------------
|
|
From: Kevin M. <ke...@vr...> - 2002-01-16 23:34:58
|
so a c interface on top of a c++ code base is a problem?
Can we put a COM interface on top of a C++ interface?
I'd rather support an XPCOM interface than a C one...
it would be nice to post binaries that work for everyone no matter what...
i still think it is important to have a nice interface (opject oriented).
can you think of a compromise?
kevin
On Wed, 16 Jan 2002, Chad Austin wrote:
> > I'd prefer a c API that wraps the C++ one, does it really matter? the C
> > api would be the one to avoid IMHO, so why build around it? besides,
> > dllexport will export C++, so it isn't a big deal. if you need image
> > plugins, I would write C wrappers that allow you to search for the C
> > symbols for the load method. Otherwise, why not C++?
>
> As I've said before, it is a big deal because there is no standard C++ ABI
> (except for the ia64 one, which isn't even really relevant yet). "What does
> that mean?" It means if I create a DLL in VC++, it won't work in gcc or Borland
> C++ or any other compiler with a different way of representing objects. "So?
> Everybody uses VC++ anyway." True, but what if VS .NET has a different ABI (I
> haven't tested this, but it's a possibility. gcc 3.0 and 2.9x have different
> the vtable layouts) and people start upgrading? Programs that are using the DLL
> will just start crashing. Also, VC++ has different allocators for debug and
> release builds. If a release build does something like ...
>
> Object* object = CreateObject(); // object factory implemented in debug DLL
> delete object;
>
> ... you're almost assured a crash.
>
> I guess my point is, Microsoft enforces two ABIs in Windows: C and COM. We
> should comply with at least one of them. (preferably C, as it's simpler)
>
> The way Audiere keeps a solid internal design *and* a nice external C++ API is
> on the inside having things like:
>
> ADR_CONTEXT ADR_CALL AdrCreateContext() {
> return (ADR_CALL)(new InternalContext);
> }
>
> ...
>
> ADR_STREAM ADR_CALL AdrOpenStream(ADR_CONTEXT c, const char* filename) {
> Context* context = (ADR_CONTEXT)c;
> return (ADR_STREAM)(context->openStream(filename));
> }
>
> and on the outside:
>
> inline Context* CreateContext() {
> ADR_CONTEXT c = AdrCreateContext();
> return (c ? new Context(c) : 0);
> };
>
> class Context {
> private:
> Context(ADR_CONTEXT c) : m_c(c) { }
> public:
> ~Context() { AdrDestroyContext(m_c); }
> Stream* openStream(const char* filename) {
> ADR_STREAM s = AdrOpenStream(m_c, filename);
> return (s ? new Stream(s) : 0);
> }
> }
>
> > PNG is good. JPG is bad (lossy) but good at compression (nice) I'd avoid
> > it so that the game looks good, but if you want to make a tiny little
> > demo it might be good to have. PCX is good.
>
> JPEG isn't bad. It just has a different usage domain. Photographic PNGs are
> HUGE, and high-quality JPEGs are very useful for prerendered backgrounds and
> such.
>
> > a separate SF project for it? I'm ok with that. are we sure there isn't
> > ANYTHING else out there? The strong points of my lib is the C++ I
> > think...
>
> You'd really think there would be other libs, but the only major one I've seen
> is openil (devil), and it doesn't impress me at all. I spent a lot of time
> looking on SourceForge and freshmeat, and haven't found much. I guess there's
> FreeImage, but it's too... Win32... (there is a Linux port, but it doesn't use
> autoconf/automake and thus requires makefile tweaking... ewww)
>
> I guess there are a lot of image libraries, but none that satisfy all of the
> requirements I have.
>
> > I think I do simple conversions already which can be migrated from the
> > Image class to a util lib. simple as in 24 to 32bit and vice versa.
>
> Sounds good to me.
>
> Just a little related note:
>
> libpng is a pain in the ass because if you just want to load any PNG image into
> an RGBA buffer, you have to explicitly handle each bit depth and every possible
> transparency setting (transparent palette entries, palette entries with alpha,
> separate alpha buffers, etc.). libmg can load PNGs too, but handles that for
> you. You specify the format you want your image data in, and that's what it
> delivers.
>
> _______________________________________________
> 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 \|| \| \`__,
-----------------------------------------------------------
|
|
From: Chad A. <ae...@ae...> - 2002-01-16 23:24:15
|
> I'd prefer a c API that wraps the C++ one, does it really matter? the C
> api would be the one to avoid IMHO, so why build around it? besides,
> dllexport will export C++, so it isn't a big deal. if you need image
> plugins, I would write C wrappers that allow you to search for the C
> symbols for the load method. Otherwise, why not C++?
As I've said before, it is a big deal because there is no standard C++ ABI
(except for the ia64 one, which isn't even really relevant yet). "What does
that mean?" It means if I create a DLL in VC++, it won't work in gcc or Borland
C++ or any other compiler with a different way of representing objects. "So?
Everybody uses VC++ anyway." True, but what if VS .NET has a different ABI (I
haven't tested this, but it's a possibility. gcc 3.0 and 2.9x have different
the vtable layouts) and people start upgrading? Programs that are using the DLL
will just start crashing. Also, VC++ has different allocators for debug and
release builds. If a release build does something like ...
Object* object = CreateObject(); // object factory implemented in debug DLL
delete object;
... you're almost assured a crash.
I guess my point is, Microsoft enforces two ABIs in Windows: C and COM. We
should comply with at least one of them. (preferably C, as it's simpler)
The way Audiere keeps a solid internal design *and* a nice external C++ API is
on the inside having things like:
ADR_CONTEXT ADR_CALL AdrCreateContext() {
return (ADR_CALL)(new InternalContext);
}
...
ADR_STREAM ADR_CALL AdrOpenStream(ADR_CONTEXT c, const char* filename) {
Context* context = (ADR_CONTEXT)c;
return (ADR_STREAM)(context->openStream(filename));
}
and on the outside:
inline Context* CreateContext() {
ADR_CONTEXT c = AdrCreateContext();
return (c ? new Context(c) : 0);
};
class Context {
private:
Context(ADR_CONTEXT c) : m_c(c) { }
public:
~Context() { AdrDestroyContext(m_c); }
Stream* openStream(const char* filename) {
ADR_STREAM s = AdrOpenStream(m_c, filename);
return (s ? new Stream(s) : 0);
}
}
> PNG is good. JPG is bad (lossy) but good at compression (nice) I'd avoid
> it so that the game looks good, but if you want to make a tiny little
> demo it might be good to have. PCX is good.
JPEG isn't bad. It just has a different usage domain. Photographic PNGs are
HUGE, and high-quality JPEGs are very useful for prerendered backgrounds and
such.
> a separate SF project for it? I'm ok with that. are we sure there isn't
> ANYTHING else out there? The strong points of my lib is the C++ I
> think...
You'd really think there would be other libs, but the only major one I've seen
is openil (devil), and it doesn't impress me at all. I spent a lot of time
looking on SourceForge and freshmeat, and haven't found much. I guess there's
FreeImage, but it's too... Win32... (there is a Linux port, but it doesn't use
autoconf/automake and thus requires makefile tweaking... ewww)
I guess there are a lot of image libraries, but none that satisfy all of the
requirements I have.
> I think I do simple conversions already which can be migrated from the
> Image class to a util lib. simple as in 24 to 32bit and vice versa.
Sounds good to me.
Just a little related note:
libpng is a pain in the ass because if you just want to load any PNG image into
an RGBA buffer, you have to explicitly handle each bit depth and every possible
transparency setting (transparent palette entries, palette entries with alpha,
separate alpha buffers, etc.). libmg can load PNGs too, but handles that for
you. You specify the format you want your image data in, and that's what it
delivers.
|
|
From: Kevin M. <ke...@vr...> - 2002-01-16 22:14:33
|
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 \|| \| \`__, ----------------------------------------------------------- |
|
From: Ben S. <bs...@vr...> - 2002-01-16 22:12:29
|
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 > > > > |
|
From: Kevin M. <ke...@vr...> - 2002-01-16 20:54:15
|
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 \|| \| \`__, ----------------------------------------------------------- |
|
From: Kevin M. <ke...@vr...> - 2002-01-16 20:43:17
|
the deployment stuff is good. win32, vc6, unix is all good and should be done. docs... yes I'd prefer a c API that wraps the C++ one, does it really matter? the C api would be the one to avoid IMHO, so why build around it? besides, dllexport will export C++, so it isn't a big deal. if you need image plugins, I would write C wrappers that allow you to search for the C symbols for the load method. Otherwise, why not C++? PNG is good. JPG is bad (lossy) but good at compression (nice) I'd avoid it so that the game looks good, but if you want to make a tiny little demo it might be good to have. PCX is good. so.. basically we'd need to add JPG to my lib any creative names? pixmi, pixmai, imagi, simpix (simple pix), simimg, smplimg, simg, simage, etc... I like the first 3... a separate SF project for it? I'm ok with that. are we sure there isn't ANYTHING else out there? The strong points of my lib is the C++ I think... I like the idea of the util lib. I've wated to do a fractal generator lib as well, but never had the time. :) I think I do simple conversions already which can be migrated from the Image class to a util lib. simple as in 24 to 32bit and vice versa. kevin On Wed, 16 Jan 2002, Chad Austin wrote: > Good. I didn't want to reinvent the wheel. What I *do* want is: > > - proper Win32 distribution with header files, VC6 import libraries, DLLs > - portability (of course) > - proper |./configure && make| UNIX distribution (autoconf/automake 'make dist') > - documentation! (of course) > - C API for DLL boundary communication > - completely inlined C++ API that calls the C API > - support for at least PNG, JPEG, and PCX (but more is better here) > - decent (creative) name :) > - SourceForge project so it's managed in a standard way > - a (possibly separate) utility library that would let us do smooth scaling, > generalized transforms, format conversions (it'd be nice to always have > everything in 32-bit color RGBA) > > > Here's why I wasn't using the ones that already exist: > > IMO, OpenIL is deployed all wrong. They don't use autoconf/automake, and > several functions in the API are either empty stubs or are missing > functionality. SDL_Image depends on SDL. Some of the other small ones are > simply not big enough. > > > > ouch. check out the one i've already written. :) (see tank in CVS for a > > few files in my image lib). > > > > let me know if you want it to have more. currently it supports SGI, TGA, > > PCX, BMP, formats (read and write) > > > > It can also read PNG, and write to a .cpp file an image into static vars.. > > > > I was planning on checking it in soon, but currently it is only called > > "Image". so it could have a better name. > > ---- > > > see this link for an older version: > > > > http://www.vrac.iastate.edu/~kevn/pub/Image-0.9.2.src.tar.gz > > ---- > > > Alternatively isn't there a few general image libs already available? > > probably don't want to reinvent the wheel. I wrote mine because at the > > time (3-4 years back) there wasn't a good sgi loader, and there certainly > > wasn't any good C++ loaders... I don't care if we find something > > different than mine if it's better. > > > > someone want to research the available libs, and make notes about how to > > load and access the image data? > > > > for example my lib works like this: > > > > Image image; > > TgaImport imp; > > imp.import( "filename.tga", image ); > > > > then to access the data: > > void *data = image.data() > > int width = image.width(); > > int height = image.height(); > > int channels = image.channels(); > > int bpp = image.bpp(); // bits per pixel > > > > void* pixel = image.pixel( x, y ); // access an individual pixel > > > > the Image class data format is what OpenGL needs passed to it. I think I > > also used it with direct X once as well... > > _______________________________________________ > 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 \|| \| \`__, ----------------------------------------------------------- |
|
From: Chad A. <ae...@ae...> - 2002-01-16 20:30:12
|
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) |
|
From: Chad A. <ae...@ae...> - 2002-01-16 20:14:10
|
Good. I didn't want to reinvent the wheel. What I *do* want is: - proper Win32 distribution with header files, VC6 import libraries, DLLs - portability (of course) - proper |./configure && make| UNIX distribution (autoconf/automake 'make dist') - documentation! (of course) - C API for DLL boundary communication - completely inlined C++ API that calls the C API - support for at least PNG, JPEG, and PCX (but more is better here) - decent (creative) name :) - SourceForge project so it's managed in a standard way - a (possibly separate) utility library that would let us do smooth scaling, generalized transforms, format conversions (it'd be nice to always have everything in 32-bit color RGBA) Here's why I wasn't using the ones that already exist: IMO, OpenIL is deployed all wrong. They don't use autoconf/automake, and several functions in the API are either empty stubs or are missing functionality. SDL_Image depends on SDL. Some of the other small ones are simply not big enough. > ouch. check out the one i've already written. :) (see tank in CVS for a > few files in my image lib). > > let me know if you want it to have more. currently it supports SGI, TGA, > PCX, BMP, formats (read and write) > > It can also read PNG, and write to a .cpp file an image into static vars.. > > I was planning on checking it in soon, but currently it is only called > "Image". so it could have a better name. ---- > see this link for an older version: > > http://www.vrac.iastate.edu/~kevn/pub/Image-0.9.2.src.tar.gz ---- > Alternatively isn't there a few general image libs already available? > probably don't want to reinvent the wheel. I wrote mine because at the > time (3-4 years back) there wasn't a good sgi loader, and there certainly > wasn't any good C++ loaders... I don't care if we find something > different than mine if it's better. > > someone want to research the available libs, and make notes about how to > load and access the image data? > > for example my lib works like this: > > Image image; > TgaImport imp; > imp.import( "filename.tga", image ); > > then to access the data: > void *data = image.data() > int width = image.width(); > int height = image.height(); > int channels = image.channels(); > int bpp = image.bpp(); // bits per pixel > > void* pixel = image.pixel( x, y ); // access an individual pixel > > the Image class data format is what OpenGL needs passed to it. I think I > also used it with direct X once as well... |
|
From: Kevin M. <ke...@vr...> - 2002-01-16 17:02:22
|
Alternatively isn't there a few general image libs already available? probably don't want to reinvent the wheel. I wrote mine because at the time (3-4 years back) there wasn't a good sgi loader, and there certainly wasn't any good C++ loaders... I don't care if we find something different than mine if it's better. someone want to research the available libs, and make notes about how to load and access the image data? for example my lib works like this: Image image; TgaImport imp; imp.import( "filename.tga", image ); then to access the data: void *data = image.data() int width = image.width(); int height = image.height(); int channels = image.channels(); int bpp = image.bpp(); // bits per pixel void* pixel = image.pixel( x, y ); // access an individual pixel the Image class data format is what OpenGL needs passed to it. I think I also used it with direct X once as well... Kevin On Wed, 16 Jan 2002, Chad Austin wrote: > I'm about to start a general-purpose image I/O library for the gamedev > club and a few personal projects I'm working on. (It'll also make > Sphere's footprint a little smaller.) Anybody have any naming > suggestions? > > _______________________________________________ > 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 \|| \| \`__, ----------------------------------------------------------- |
|
From: Kevin M. <ke...@vr...> - 2002-01-16 16:54:18
|
see this link for an older version: http://www.vrac.iastate.edu/~kevn/pub/Image-0.9.2.src.tar.gz Kevin On Wed, 16 Jan 2002, Kevin Meinert wrote: > > ouch. check out the one i've already written. :) (see tank in CVS for a > few files in my image lib). > > let me know if you want it to have more. currently it supports SGI, TGA, > PCX, BMP, formats (read and write) > > It can also read PNG, and write to a .cpp file an image into static vars.. > > I was planning on checking it in soon, but currently it is only called > "Image". so it could have a better name. > > Kevin > > On Wed, 16 Jan 2002, Chad Austin wrote: > > > I'm about to start a general-purpose image I/O library for the gamedev > > club and a few personal projects I'm working on. (It'll also make > > Sphere's footprint a little smaller.) Anybody have any naming > > suggestions? > > > > _______________________________________________ > > 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 \|| \| \`__, ----------------------------------------------------------- |
|
From: Kevin M. <ke...@vr...> - 2002-01-16 16:51:11
|
ouch. check out the one i've already written. :) (see tank in CVS for a few files in my image lib). let me know if you want it to have more. currently it supports SGI, TGA, PCX, BMP, formats (read and write) It can also read PNG, and write to a .cpp file an image into static vars.. I was planning on checking it in soon, but currently it is only called "Image". so it could have a better name. Kevin On Wed, 16 Jan 2002, Chad Austin wrote: > I'm about to start a general-purpose image I/O library for the gamedev > club and a few personal projects I'm working on. (It'll also make > Sphere's footprint a little smaller.) Anybody have any naming > suggestions? > > _______________________________________________ > 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 \|| \| \`__, ----------------------------------------------------------- |
|
From: Chad A. <ae...@ae...> - 2002-01-16 15:59:49
|
I'm about to start a general-purpose image I/O library for the gamedev club and a few personal projects I'm working on. (It'll also make Sphere's footprint a little smaller.) Anybody have any naming suggestions? |
|
From: Chad A. <ae...@ae...> - 2002-01-12 10:14:58
|
[snip] > is that more clear? would that work well, or is my lack of knowledge of > scripting going to doom that design to failure? Yeah, that makes sense. Your definition of 'scripting engine' simply included more than mine did. The functionality you want can be implemented in terms of what I wanted, so we're all good. |
|
From: Ben S. <bs...@vr...> - 2002-01-11 17:08:43
|
> Eh? I'm confused by your statement "I don't think it's worth our time writing bindings". How else > will we get scriptability? [snip] i guess what i meant by not wanting to write bindings is that at the meeting where you talked about scripting you said that writing the bindings was not easy or fun. so i figure if we can find LGPL code out there that does most of the work for us, we can reuse it and refactor it a bit to get it to work with scribe. i figured that would be a better use of our time than trying to write the language bindings from scratch. > How do you call a function if it isn't defined? If you have native functions that you want to > reflect into a particular scripting language, you have to tell it that those functions exist. [snip] i guess i wasn't very clear. i see two ends of a scripting engine. first you've got the libraries you want to load that contains code in some arbitrary language you want to execute. second you've got your application (probably in C++) in which you want to implement a soft architecture where you can execute dynamically loaded code in said libraries. so i see all the libraries being in some predefined directory. when the scripting engine loads, it would load all the DLLs in that directory and call some initialization function. the libraries themselves would register/define what functions/classes they define in some sort of registry in the scripting engine. on the other side, my application starts up and loads the scripting engine. the engine loads and inits all the libraries containing the code i want to execute. then my application asks the scripting engine to execute some function. the scripting engine would look up the function and try to execute it if it found it and otherwise fail. is that more clear? would that work well, or is my lack of knowledge of scripting going to doom that design to failure? ----- Ben Scott President ISU Game Developers Club Treasurer ISU Ballroom Dance Company bs...@ia... On Fri, 11 Jan 2002, Chad Austin wrote: > > well i guess i'd rather have a more lightweight system. however, i don't > > particularly think it's worth our time writing bindings for various > > languages. however ... if you think we can do it with some fancy template > > meta-programming or reuse existing code out there that does binding to > > various languages, then i say go for it. > > Eh? I'm confused by your statement "I don't think it's worth our time writing bindings". How else > will we get scriptability? > > > now, i'm not familiar with doing scripting, but i would probably want to > > use the scripting engine along the following lines (ignoring error > > condidions): > > > > ScriptEngineFactory* factory = ScriptEngineFactory::getInstance(); > > IScriptEngine* se = factory->create( "python" ); > > se->execute( "myPythonFunction()" ); > > > > my point above is that i wouldn't necesarily want to have to define my > > functions before i can call them. i would hope that the scripting engine > > would be smart enough to be able to call the correct python function > > without me having to define it first. perhaps it would be up to the > > particular scripting engine to define the functions. > > How do you call a function if it isn't defined? If you have native functions that you want to > reflect into a particular scripting language, you have to tell it that those functions exist. > > > or better yet, maybe we could dynamically load "plugins" that define > > functions in an arbitrary language. when loaded, they would register the > > funtions/classes they provide with the apropriate scripting engine. then > > when i use the scripting engine using code similar to above. > > This requires features of a full component system, afaik. For example, being able to understand > interfaces at run-time. > > > please, check in your ideas and UML diagrams ... i'd love to take a look > > at them and comment on them! > > I'll do that. isugamedev/lib/scribe > > _______________________________________________ > ISUGameDev-devel mailing list > ISU...@li... > https://lists.sourceforge.net/lists/listinfo/isugamedev-devel > |
|
From: Chad A. <ae...@ae...> - 2002-01-11 15:58:12
|
> well i guess i'd rather have a more lightweight system. however, i don't > particularly think it's worth our time writing bindings for various > languages. however ... if you think we can do it with some fancy template > meta-programming or reuse existing code out there that does binding to > various languages, then i say go for it. Eh? I'm confused by your statement "I don't think it's worth our time writing bindings". How else will we get scriptability? > now, i'm not familiar with doing scripting, but i would probably want to > use the scripting engine along the following lines (ignoring error > condidions): > > ScriptEngineFactory* factory = ScriptEngineFactory::getInstance(); > IScriptEngine* se = factory->create( "python" ); > se->execute( "myPythonFunction()" ); > > my point above is that i wouldn't necesarily want to have to define my > functions before i can call them. i would hope that the scripting engine > would be smart enough to be able to call the correct python function > without me having to define it first. perhaps it would be up to the > particular scripting engine to define the functions. How do you call a function if it isn't defined? If you have native functions that you want to reflect into a particular scripting language, you have to tell it that those functions exist. > or better yet, maybe we could dynamically load "plugins" that define > functions in an arbitrary language. when loaded, they would register the > funtions/classes they provide with the apropriate scripting engine. then > when i use the scripting engine using code similar to above. This requires features of a full component system, afaik. For example, being able to understand interfaces at run-time. > please, check in your ideas and UML diagrams ... i'd love to take a look > at them and comment on them! I'll do that. isugamedev/lib/scribe |
|
From: Ben S. <bs...@vr...> - 2002-01-09 22:41:02
|
well i guess i'd rather have a more lightweight system. however, i don't
particularly think it's worth our time writing bindings for various
languages. however ... if you think we can do it with some fancy template
meta-programming or reuse existing code out there that does binding to
various languages, then i say go for it.
now, i'm not familiar with doing scripting, but i would probably want to
use the scripting engine along the following lines (ignoring error
condidions):
ScriptEngineFactory* factory = ScriptEngineFactory::getInstance();
IScriptEngine* se = factory->create( "python" );
se->execute( "myPythonFunction()" );
my point above is that i wouldn't necesarily want to have to define my
functions before i can call them. i would hope that the scripting engine
would be smart enough to be able to call the correct python function
without me having to define it first. perhaps it would be up to the
particular scripting engine to define the functions.
or better yet, maybe we could dynamically load "plugins" that define
functions in an arbitrary language. when loaded, they would register the
funtions/classes they provide with the apropriate scripting engine. then
when i use the scripting engine using code similar to above.
as for a CVS module, here are some ideas:
- grok
- sanskrit
- scribe
- ogre
- chickenscratch
- chicken
- pig
- orc
- goblin
code review process ... i'd say that's up to the module owner.
please, check in your ideas and UML diagrams ... i'd love to take a look
at them and comment on them!
cheers,
-----
Ben Scott
President ISU Game Developers Club
Treasurer ISU Ballroom Dance Company
bs...@ia...
On Wed, 9 Jan 2002, Chad Austin wrote:
> The issue here is whether it should be a full component system or something of a smaller magnitude.
> If you want a full component system, there really isn't a reason not to use CORBA or XPCOM. On the
> other hand, I'd love to make something a little more lightweight. It'd be nice to have some sort of
> automation in interacting with scripting languages, so a game could do something like:
>
> void someFunction() {
> }
>
> IScriptEngine* se = CreateScriptEngine("python");
> if (!se) {
> error();
> }
>
> se->defineFunction("someFunction", someFunction);
> se->defineMethod("someMethod", &C::someMethod); // or whatever that syntax is
>
> and then:
>
> se->execute("someFunction()"); // you pass in a script
>
> whoa, I just realized you could use typelists to automate script bindings... that's cool o_o
> Maybe that's what boost.org's automated python bindings do.
>
> I do have a rough idea of a design, come to think of it. Should I make a new module in CVS? What
> should it be called?
>
>
> I wouldn't really know how to design the interface without seeing example usage though. I just
> finished reading Martin Fowler's Refactoring (good book, btw), and I've moved away from doing lots
> of up-front design. We'll see if this is a temporary or lasting effect on my coding style.
>
>
> Are we going to have some sort of code review process for module owners? If I were a module owner,
> I'd like to at least look at all code that's going in.
>
>
> > after your talk about scripting languages and embedding them in a game,
> > i would really love to take part in building a module that would be
> > easily embedded in a game that would handle the loading of components
> > regardless of the language they were written in. i think that would be
> > really useful for all of the games in development for the club. i thought
> > since you're the smart/knowledgable guy on this scripting stuff that
> > perhaps i could get you to spearhead an effort to make such a module. i
> > figured you could perhaps take care of the overall design and then task
> > code monkeys like myself with work to get it implemented.
>
> _______________________________________________
> ISUGameDev-devel mailing list
> ISU...@li...
> https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
>
|
|
From: Chad A. <ae...@ae...> - 2002-01-09 14:06:59
|
The issue here is whether it should be a full component system or something of a smaller magnitude.
If you want a full component system, there really isn't a reason not to use CORBA or XPCOM. On the
other hand, I'd love to make something a little more lightweight. It'd be nice to have some sort of
automation in interacting with scripting languages, so a game could do something like:
void someFunction() {
}
IScriptEngine* se = CreateScriptEngine("python");
if (!se) {
error();
}
se->defineFunction("someFunction", someFunction);
se->defineMethod("someMethod", &C::someMethod); // or whatever that syntax is
and then:
se->execute("someFunction()"); // you pass in a script
whoa, I just realized you could use typelists to automate script bindings... that's cool o_o
Maybe that's what boost.org's automated python bindings do.
I do have a rough idea of a design, come to think of it. Should I make a new module in CVS? What
should it be called?
I wouldn't really know how to design the interface without seeing example usage though. I just
finished reading Martin Fowler's Refactoring (good book, btw), and I've moved away from doing lots
of up-front design. We'll see if this is a temporary or lasting effect on my coding style.
Are we going to have some sort of code review process for module owners? If I were a module owner,
I'd like to at least look at all code that's going in.
> after your talk about scripting languages and embedding them in a game,
> i would really love to take part in building a module that would be
> easily embedded in a game that would handle the loading of components
> regardless of the language they were written in. i think that would be
> really useful for all of the games in development for the club. i thought
> since you're the smart/knowledgable guy on this scripting stuff that
> perhaps i could get you to spearhead an effort to make such a module. i
> figured you could perhaps take care of the overall design and then task
> code monkeys like myself with work to get it implemented.
|
|
From: Kevin M. <ke...@vr...> - 2002-01-05 15:26:09
|
we should look into this to use in the club. anyone interested in checking it out? Cal3D: Skeletal animation lib in graphics independant c++. Includes 3ds max exporter: http://cal3d.sourceforge.net/ @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
|
From: Kevin M. <ke...@vr...> - 2001-12-28 05:41:44
|
Just a couple of good links to share... Was searching online for a good iostream reference, and I think I found one... http://www.cplusplus.com/ref/iostream/ It looks like these are the newer Standard C++ versions too (i.e. in the std namespace)... Also, don't forget the invaluable STL reference by SGI: http://www.sgi.com/tech/stl/stl_index.html I use the STL site many times a week. It is really useful to put these in your netscape "personal toolbar folder" (NOTE: don't write your own string and linked list classes... use STL, it's good, it's tested, it's used by many) @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
|
From: Kevin M. <ke...@vr...> - 2001-12-17 04:47:15
|
Just installed latest RedHat 7.2 and the Ximian desktop... It came with "Dia" diagram editor... Looks like it has UML symbols. Might be a cool thing to communicate your ideas about your game engine designs to each other. Unfortunately it doesn't do reverse engineering of existing code, nor does it generate code from the diagrams... something I haven't seen in any free tool yet... :\ @--@---@---@----@-----@------@------@-----@----@---@---@--@ Kevin Meinert __ _ __ http://www.vrac.iastate.edu/~kevn \ || \| \ / ` Virtual Reality Applications Center \ ||.-'|--\ Howe Hall, Iowa State University, Ames Iowa \|| \| \`__, ----------------------------------------------------------- |
|
From: Chad A. <ae...@ae...> - 2001-12-14 21:15:10
|
I just set up a WikiWikiWeb for the club at http://isugamedev.sourceforge.net/cgi-bin/wiki.pl?GameDevWiki In particular, we'd like to get your feedback on the club this last semester. Did you enjoy it? What would you change? See http://isugamedev.sourceforge.net/cgi-bin/wiki.pl?ClubFeedback for details. -- Chad Austin http://aegisknight.org/ |
2 messages has been excluded from this view by a project administrator.
