Menu
▾
▴
isugamedev-devel
|
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: 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: 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: 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 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 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 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-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: 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: Chad A. <ae...@ae...> - 2002-01-17 01:04:52
|
> can we use our own com-like thing? Yeah, we could. COM is a Microsoft-defined ABI (you can write COM objects in VB and assembly and they will get along just fine because they know exactly how to communicate). So if we somehow guaranteed a COM-compatible ABI (or at least something similar), we'd be okay. > 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? I believe that all Windows compilers at least support an option for COM-compatible vtable layouts (it'd be suicide not to support COM), so I guess that'll work. |
|
From: Kevin M. <ke...@vr...> - 2002-01-17 01:12:00
|
so... inlined pseudo-COM is good... whew! I've always kind of had that in mind for DLL stuff anyway. since I like cross platform stuff, C++, and since I read the Box book (COM book), I've always assumed that we could write our own limited subset of COM... but have never tried it.. :) seems like the lightest weight, most expressive (C or C++ syntax), most portable option... does this meet both of our priorities? we still haven't settled on using std::io stuff or FILE, std::string stuff or char* I'm fine with whatever there, as long as the code doesn't get more brittle (like if we have to do lots of new and delete). NOTE: we can always move the proj from gamedev to a SF.net project. and the name isn't too permanent. I just wanted to get it up so people could use it if they wanted... Kevin On Wed, 16 Jan 2002, Chad Austin wrote: > > can we use our own com-like thing? > > Yeah, we could. COM is a Microsoft-defined ABI (you can write COM objects in VB > and assembly and they will get along just fine because they know exactly how to > communicate). So if we somehow guaranteed a COM-compatible ABI (or at least > something similar), we'd be okay. > > > 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? > > I believe that all Windows compilers at least support an option for > COM-compatible vtable layouts (it'd be suicide not to support COM), so I guess > that'll work. > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ 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-17 01:15:19
|
uh, ignore the word "inlined"... that didn't make sense. (inlined would work too though it could bloat the code you use it in) On Wed, 16 Jan 2002, Kevin Meinert wrote: > > so... inlined pseudo-COM is good... whew! I've always kind of had that in > mind for DLL stuff anyway. since I like cross platform stuff, C++, and > since I read the Box book (COM book), I've always assumed that we could write our > own limited subset of COM... but have never tried it.. :) seems like the > lightest weight, most expressive (C or C++ syntax), most portable > option... > > does this meet both of our priorities? > > we still haven't settled on using std::io stuff or FILE, std::string stuff or char* > > I'm fine with whatever there, as long as the code doesn't get more brittle > (like if we have to do lots of new and delete). > > NOTE: we can always move the proj from gamedev to a SF.net project. and > the name isn't too permanent. I just wanted to get it up so people could > use it if they wanted... > > > Kevin > > > On Wed, 16 Jan 2002, Chad Austin wrote: > > > > can we use our own com-like thing? > > > > Yeah, we could. COM is a Microsoft-defined ABI (you can write COM objects in VB > > and assembly and they will get along just fine because they know exactly how to > > communicate). So if we somehow guaranteed a COM-compatible ABI (or at least > > something similar), we'd be okay. > > > > > 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? > > > > I believe that all Windows compilers at least support an option for > > COM-compatible vtable layouts (it'd be suicide not to support COM), so I guess > > that'll work. > > > > -- @--@---@---@----@-----@------@------@-----@----@---@---@--@ 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 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 \|| \| \`__, ----------------------------------------------------------- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X