glt-devel Mailing List for GLT OpenGL C++ Toolkit
C++ class library for programming interactive 3D graphics with OpenGL
Status: Abandoned
Brought to you by:
nigels
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
(15) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Jacques G. <jac...@ho...> - 2004-12-26 05:59:36
|
Hi Nigel. Finally I'm finished with uni. It has been hectic as I also got a research scholarship during term2. Parallel Differential Evolution for Aircraft FEM inverse Hooke's law solving, what was I thinking... Anyhow, I have finally got some free time over Xmas and decided to sit down and fiddle with GLT. I have committed some stuff to make sure it compiles for me, nothing major. It would be good if you had a look just to make sure all is fine. I like the move to start using FreeImage. It seems like a good lib. Xmas was great for me, I hope it was good for you too. Have fun in Texas and watch out for gun toting maniacs (Bush supporters ...) Cheers, Jacques. |
From: Nigel S. <ni...@ni...> - 2004-07-06 00:12:46
|
Hi! Nice to hear from you again. I was starting to wonder if I'd eventually need to dig into that BMP stuff again, but I've had plenty on the go, and spring and summer have provided alternatives! You can add your own test harness for BMP in src/program/test - I'm just not sure where any test bmp files should live... Can we eliminate the bmp_P.h/.cpp files, (move it into bmp.cpp)?? How far are from BMP encoding? Compression support? Nigel > I have finished semester 1 and I just had a look at the bmp code, which after 4 > moths looks pretty amateurish, so I submitted some fixes and stuff. > It is about time we get it out of development and into testing. > Could you (Nigel) please make a C++ stub file in the tree somewhere for > bmp testing, I don't quite feel comfortable rearanging build order etc. > Then I can just make a test harness for the bmp code. Does that sound good? > > Cheers, Jacques. |
From: Jaques G. de r. <S20...@st...> - 2004-07-05 03:57:31
|
Hi, It has been a while. School has been very busy, I had no idea FSDS would ha= ve such a high workload. I have also helped my friend from Aerospace out = with his thesis (converting from Matlab to C++). Further Tamara and I jus= t moved into our new place. Yippie, no more living with the inlaws. (Don'= t get me wrong they are wonderful people, it's just hard when someone is = always looking over the shoulder so to speak.) I have finished semester 1 and I just had a look at the bmp code, which aft= er 4 moths looks pretty amateurish, so I submitted some fixes and stuff. It is about time we get it out of development and into testing. Could you (= Nigel) please make a C++ stub file in the tree somewhere for bmp testing,= I don't quite feel comfortable rearanging build order etc. Then I can ju= st make a test harness for the bmp code. Does that sound good? Cheers, Jacques. |
From: Jacques G. <jac...@ho...> - 2004-04-01 12:53:23
|
>From: Nigel Stewart <ni...@ni...> >To: glt...@li... >Subject: Re: [Glt-devel] GLT and .bmp >Date: Sun, 21 Mar 2004 15:48:07 -0500 > I have been very busy with uni so sorry for the long wait for a reply. > >>Done that as well but as above. Also there is a need for a loop if you >>template without specialisations. > > Oh, I see now. I really think the endian conversion should > be moved outside of these routines. writeToBuffer is very > clumsy looking. > I'll see if I can get around the size checking somehow. Maybe some template trickery will fix it. >A few other issues/comments: > >(1) I did a lot of reformatting to bring it into GLT style. > Take advantage of the colourised CVS diff to see these > changes: > >http://cvs.sourceforge.net/viewcvs.py/glt/glt/src/misc/?sortby=date#dirlist > >(2) > // Get a pointer to the input byte buffer. > const byte *inputBuffer = reinterpret_cast<const byte*>(data.data()); > > if (!(bitmap.loadFromBuffer(inputBuffer))) > { > gltWarning("Unsupported BMP variant."); > return false; > } > Yeah, thanks it helps getting the style right. > -> Can we have the loadFromBuffer accept a std::string directly, > rather than inflict the complication on the client code? > Yepp it should be little more than copy/paste. Could it be a string& though, because according to Strostrup string copies aren't always shallow. He indicates that it is up to the C++ implementation to decide. I haven't checked what gcc and VC++ do but I just thought that it is best to be on the safe side. >(3) > uint16 bpp = bitmap.getBpp(); > uint32 imageSize = bitmap.getImageSize(); > uint32 bufferSize = 0; > > switch (bpp) > { > /* Not yet supported > case 1: bufferSize = (imageSize+7)/8; break; > case 4: bufferSize = (imageSize+1)/2; break; > */ > case 8: bufferSize = imageSize; break; > case 16: bufferSize = imageSize*2; break; > case 24: bufferSize = imageSize*3; break; > } > > -> Can we shift this housekeeping into BitmapFile? > Yeah sure. >(4) > image.resize(bufferSize); > > // flip the colors internally > bitmap.convertRGBtoBGR(); > > // make a pointer for output > byte *outputBuffer = (byte*)(image.data()); > > //copy it over and voila > memcpy(outputBuffer, bitmap.getImageData(), bufferSize); > > //we are done > > -> Can we put the output to std::string in BitmapFile as well? > As above, except & is a given here. I'll see what I can do about all this. I might have made a new commit by the end of next week, but there is a lot of assignments due soon and my girlfriends 21:st, so work on GLT is going to slow down for a short bit. I just checked the stats for GLT, March is almost the best month ever for GLT, this sounds promising for the future. What is the release plan for rc4? Have a good weekend and enjoy the coming spring. Cheers, Jacques. > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Glt-devel mailing list >Glt...@li... >https://lists.sourceforge.net/lists/listinfo/glt-devel _________________________________________________________________ Find love today with ninemsn personals. Click here: http://ninemsn.match.com |
From: Nigel S. <ni...@ni...> - 2004-03-21 20:45:30
|
> Done that as well but as above. Also there is a need for a loop if you > template without specialisations. Oh, I see now. I really think the endian conversion should be moved outside of these routines. writeToBuffer is very clumsy looking. A few other issues/comments: (1) I did a lot of reformatting to bring it into GLT style. Take advantage of the colourised CVS diff to see these changes: http://cvs.sourceforge.net/viewcvs.py/glt/glt/src/misc/?sortby=date#dirlist (2) // Get a pointer to the input byte buffer. const byte *inputBuffer = reinterpret_cast<const byte*>(data.data()); if (!(bitmap.loadFromBuffer(inputBuffer))) { gltWarning("Unsupported BMP variant."); return false; } -> Can we have the loadFromBuffer accept a std::string directly, rather than inflict the complication on the client code? (3) uint16 bpp = bitmap.getBpp(); uint32 imageSize = bitmap.getImageSize(); uint32 bufferSize = 0; switch (bpp) { /* Not yet supported case 1: bufferSize = (imageSize+7)/8; break; case 4: bufferSize = (imageSize+1)/2; break; */ case 8: bufferSize = imageSize; break; case 16: bufferSize = imageSize*2; break; case 24: bufferSize = imageSize*3; break; } -> Can we shift this housekeeping into BitmapFile? (4) image.resize(bufferSize); // flip the colors internally bitmap.convertRGBtoBGR(); // make a pointer for output byte *outputBuffer = (byte*)(image.data()); //copy it over and voila memcpy(outputBuffer, bitmap.getImageData(), bufferSize); //we are done -> Can we put the output to std::string in BitmapFile as well? |
From: Jacques G. <jac...@ho...> - 2004-03-21 10:53:58
|
OK, back from camping. Bug fixing is at hand. >From: Nigel Stewart <ni...@ni...> >To: glt...@li... >Subject: Re: [Glt-devel] GLT and .bmp >Date: Tue, 16 Mar 2004 22:38:33 -0500 > >- Always use UPPER_CASE for macros, never to be > confused with lower_case variables. > Misunderstanding on my part. You wrote in an earlier email ifdef bmp.cpp . I just glanced through the email, not knowing exactly what you wanted and I decided a good middle ground would be #ifdef bmp_P. It takes some time to figure out your style, and I don't want to make assumptions. I thought that lower case defines for optionals might have been some weird Australian style. >- Why readUint16FromBuffer and readUint32FromBuffer > and not a templated version? > >template<class T> >T readBuffer(const byte **pos) >{ > const T *tmp = reinterpret_cast<const T *>(*pos); > *pos += sizeof(T); > return *tmp; >} > Sure but I am confused as to why. Do you want to promote them up in the API ? Templating it doesn't make it faster to code since readUint16FromBuffer -> readFromBuffer<uint16>. It is only instanced twice in bmp_P.cpp so the benefits of debugging a single function are minimal (only three lines of code as well). >template<class T> >void writeBuffer(byte **pos, const T &val) >{ > T *tmp = reinterpret_cast<T *>(*pos); > *tmp = val; > *pos += sizeof(T); >} > Done that as well but as above. Also there is a need for a loop if you template without specialisations. >- Still getting compile errors: > >Compiling bmp.cpp > In function `bool decodeBMP(uint32&, uint32&, std::string&, >const std::string&)': > 67: error: invalid conversion from `const char*' to `const >byte*' > 69: error: base operand of `->' has non-pointer type >`BitmapFile' > 78: error: base operand of `->' has non-pointer type >`BitmapFile' > 79: error: base operand of `->' has non-pointer type >`BitmapFile' > 81: error: base operand of `->' has non-pointer type >`BitmapFile' > 82: error: base operand of `->' has non-pointer type >`BitmapFile' > 109: error: base operand of `->' has non-pointer type >`BitmapFile' > 112: error: invalid conversion from `const char*' to `byte*' > 115: error: base operand of `->' has non-pointer type >`BitmapFile' > In function `bool encodeBMP(std::string&, unsigned int, >unsigned int, const std::string&)': > 261: error: invalid conversion from `const char*' to `const >byte*' > 264: error: base operand of `->' has non-pointer type >`BitmapFile' > 265: error: base operand of `->' has non-pointer type >`BitmapFile' > 269: error: base operand of `->' has non-pointer type >`BitmapFile' > 276: error: base operand of `->' has non-pointer type >`BitmapFile' > 301: error: passing `const std::string' as `this' argument of >`void std::basic_string<_CharT, _Traits, _Alloc>::resize(typename >_Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, >_Alloc = std::allocator<char>]' discards qualifiers > 303: error: invalid conversion from `const char*' to `byte*' > 305: error: base operand of `->' has non-pointer type >`BitmapFile' > 307: error: base operand of `->' has non-pointer type >`BitmapFile' > I forgot to define BMP_P Fixed now. >Jacques Gasselin wrote: >>>>>- Does this compile with gcc? >>>It does for me. MDK 9.2, gcc3.2, glibc2.3 >>> >>> I'm on Mandrake 10 with gcc 3.3.2. >>> I'll look more closely at the errors >>> after work today. > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Glt-devel mailing list >Glt...@li... >https://lists.sourceforge.net/lists/listinfo/glt-devel _________________________________________________________________ Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to http://join.msn.com/?pgmarket=en-au&page=hotmail/es2 |
From: Nigel S. <ni...@ni...> - 2004-03-17 03:41:08
|
> I just worry that very few people will want to use the BMP RLE option > because it is not very good. True. But for the sake of being complete - nice to have. Essential for import, in particular. Nigel |
From: Nigel S. <ni...@ni...> - 2004-03-17 03:37:01
|
- Always use UPPER_CASE for macros, never to be confused with lower_case variables. - Why readUint16FromBuffer and readUint32FromBuffer and not a templated version? template<class T> T readBuffer(const byte **pos) { const T *tmp = reinterpret_cast<const T *>(*pos); *pos += sizeof(T); return *tmp; } template<class T> void writeBuffer(byte **pos, const T &val) { T *tmp = reinterpret_cast<T *>(*pos); *tmp = val; *pos += sizeof(T); } - Still getting compile errors: Compiling bmp.cpp In function `bool decodeBMP(uint32&, uint32&, std::string&, const std::string&)': 67: error: invalid conversion from `const char*' to `const byte*' 69: error: base operand of `->' has non-pointer type `BitmapFile' 78: error: base operand of `->' has non-pointer type `BitmapFile' 79: error: base operand of `->' has non-pointer type `BitmapFile' 81: error: base operand of `->' has non-pointer type `BitmapFile' 82: error: base operand of `->' has non-pointer type `BitmapFile' 109: error: base operand of `->' has non-pointer type `BitmapFile' 112: error: invalid conversion from `const char*' to `byte*' 115: error: base operand of `->' has non-pointer type `BitmapFile' In function `bool encodeBMP(std::string&, unsigned int, unsigned int, const std::string&)': 261: error: invalid conversion from `const char*' to `const byte*' 264: error: base operand of `->' has non-pointer type `BitmapFile' 265: error: base operand of `->' has non-pointer type `BitmapFile' 269: error: base operand of `->' has non-pointer type `BitmapFile' 276: error: base operand of `->' has non-pointer type `BitmapFile' 301: error: passing `const std::string' as `this' argument of `void std::basic_string<_CharT, _Traits, _Alloc>::resize(typename _Alloc::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]' discards qualifiers 303: error: invalid conversion from `const char*' to `byte*' 305: error: base operand of `->' has non-pointer type `BitmapFile' 307: error: base operand of `->' has non-pointer type `BitmapFile' Jacques Gasselin wrote: >>>> - Does this compile with gcc? >> It does for me. MDK 9.2, gcc3.2, glibc2.3 >> >> I'm on Mandrake 10 with gcc 3.3.2. >> I'll look more closely at the errors >> after work today. |
From: Nigel S. <ni...@ni...> - 2004-03-17 03:25:04
|
Yes, I have this problem too: $gcc --version gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk) It appears that gcc have made a release of their compiler that can't compile their own std library in pedantic mode. I'd be content to roll a Makefile.config into CVS without pedantic until gcc do another release or two. Nigel > This is the log from src/misc/string.cpp > Alot of other files give the same error. > > In file included from /usr/include/math.h:362, > from /usr/include/c++/3.3.1/cmath:51, > from /usr/include/c++/3.3.1/bits/locale_facets.tcc:41, > from /usr/include/c++/3.3.1/locale:47, > from /usr/include/c++/3.3.1/bits/ostream.tcc:37, > from /usr/include/c++/3.3.1/ostream:535, > from /usr/include/c++/3.3.1/iostream:45, > from string.cpp:57: > /usr/include/bits/mathinline.h: In function `long double __expm1l(long > double)': > /usr/include/bits/mathinline.h:385: error: ISO C++ forbids omitting the > middle term of > a ?: expression > /usr/include/bits/mathinline.h: In function `double expm1(double)': > /usr/include/bits/mathinline.h:536: error: ISO C++ forbids omitting the > middle term of > a ?: expression ... |
From: Jacques G. <jac...@ho...> - 2004-03-17 03:15:33
|
Nigel This is the log from src/misc/string.cpp Alot of other files give the same error. In file included from /usr/include/math.h:362, from /usr/include/c++/3.3.1/cmath:51, from /usr/include/c++/3.3.1/bits/locale_facets.tcc:41, from /usr/include/c++/3.3.1/locale:47, from /usr/include/c++/3.3.1/bits/ostream.tcc:37, from /usr/include/c++/3.3.1/ostream:535, from /usr/include/c++/3.3.1/iostream:45, from string.cpp:57: /usr/include/bits/mathinline.h: In function `long double __expm1l(long double)': /usr/include/bits/mathinline.h:385: error: ISO C++ forbids omitting the middle term of a ?: expression /usr/include/bits/mathinline.h: In function `double expm1(double)': /usr/include/bits/mathinline.h:536: error: ISO C++ forbids omitting the middle term of a ?: expression /usr/include/bits/mathinline.h: In function `float expm1f(float)': /usr/include/bits/mathinline.h:536: error: ISO C++ forbids omitting the middle term of a ?: expression /usr/include/bits/mathinline.h: In function `long double expm1l(long double)': /usr/include/bits/mathinline.h:536: error: ISO C++ forbids omitting the middle term of a ?: expression How do I fix this ? Removing -pedantic from CXXFLAGS obviously removes the warnings but that means that my Makefile is different from the CVS and I will thus overwrite if I commit this. Do you think this is an error or just -pedantic being paranoid ? Jacques. _________________________________________________________________ Protect your inbox from harmful viruses with new ninemsn Premium. Go to http://ninemsn.com.au/premium/landing.asp?banner=emailtag&referrer=hotmail |
From: Jacques G. <jac...@ho...> - 2004-03-17 03:04:33
|
>>>- Does this compile with gcc? >> >>It does for me. MDK 9.2, gcc3.2, glibc2.3 > > I'm on Mandrake 10 with gcc 3.3.2. > I'll look more closely at the errors > after work today. > I must have been half asleep when I tried to compile it. It had plenty of little errors. Sorry but I commited it all very late at night. These have all been corrected now.... :). >>>- Lack of const for member functions >>Easily fixed > > Some could be static as well. > >>Yes, but I'll leave the endian fixing up to you. >>Do we care about middle endian, a la PDP ? > > Is there OpenGL for PDP? :-) > I'm sure some crazy person has tried. :-). >>>- #include <cstdlib> >>> #include <cstdio> >>> #include <cstring> >> >> >>?? > > There are typos - > >#include <ctdlib> >#include <ctdio> >#include <ctring> > Fixed. >>>- Please #ifdef bmp.cpp so that your implementation >>> is disabled by default and remove _P.cpp from >>> Makefile - GLT is now basically broken in CVS. >> >> >>I'll #ifdef them. >>I didn't know it broke the make process, but I'll remove it. On my box it >>works just fine. >>What is wrong with it? Are there unresolved symbols in libglt from it ?? Sorry again. I think I might be a somnprogramist. > > It could simply be gcc 3.3.2, but until it's all tested on > Linux, Win32, Cygwin and Mingw32, better not to expose it. > >>Yeah it is looking more uniform. We'll get there in the end. >>I'll add compression support soon. We will need to change the API for GLT >>0.9 to cope with saving to compressed bmp.... unless we add a default bool >>at the end of the encodeBMP. >> >>encodeBMP (..., bool compress = false); >> >>that should leave old code intact whilst exposing the compression option. > >No need to extend the API, compressed output should be the default. > >Nigel > I just worry that very few people will want to use the BMP RLE option because it is not very good. > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Glt-devel mailing list >Glt...@li... >https://lists.sourceforge.net/lists/listinfo/glt-devel _________________________________________________________________ Get Extra Storage in 10MB, 25MB, 50MB and 100MB options now! Go to http://join.msn.com/?pgmarket=en-au&page=hotmail/es2 |
From: Nigel S. <ni...@ni...> - 2004-03-16 12:08:42
|
>> - Does this compile with gcc? > > It does for me. MDK 9.2, gcc3.2, glibc2.3 I'm on Mandrake 10 with gcc 3.3.2. I'll look more closely at the errors after work today. >> - Lack of const for member functions > Easily fixed Some could be static as well. > Yes, but I'll leave the endian fixing up to you. > Do we care about middle endian, a la PDP ? Is there OpenGL for PDP? :-) >> - #include <cstdlib> >> #include <cstdio> >> #include <cstring> > > > ?? There are typos - #include <ctdlib> #include <ctdio> #include <ctring> >> - Please #ifdef bmp.cpp so that your implementation >> is disabled by default and remove _P.cpp from >> Makefile - GLT is now basically broken in CVS. > > > I'll #ifdef them. > I didn't know it broke the make process, but I'll remove it. On my box > it works just fine. > What is wrong with it? Are there unresolved symbols in libglt from it ?? It could simply be gcc 3.3.2, but until it's all tested on Linux, Win32, Cygwin and Mingw32, better not to expose it. > Yeah it is looking more uniform. We'll get there in the end. > I'll add compression support soon. We will need to change the API for > GLT 0.9 to cope with saving to compressed bmp.... unless we add a > default bool at the end of the encodeBMP. > > encodeBMP (..., bool compress = false); > > that should leave old code intact whilst exposing the compression option. No need to extend the API, compressed output should be the default. Nigel |
From: Jacques G. <jac...@ho...> - 2004-03-16 07:46:54
|
>Hi Jaques, > >A couple of issues with the current BMP CVS: > >- Tabs are four spaces, not three OK. >- Does this compile with gcc? It does for me. MDK 9.2, gcc3.2, glibc2.3 >- Lack of const for member functions Easily fixed >- Try this for tider buffer read/write: > >template<class T> >T readBuffer(const byte **pos) >{ > const T *tmp = reinterpret_cast<const T *>(*pos); > *pos += sizeof(T); > return *tmp; >} > >template<class T> >void writeBuffer(byte **pos, const T &val) >{ > T *tmp = reinterpret_cast<T *>(*pos); > *tmp = val; > *pos += sizeof(T); >} > >- It looks like we may need to extend endian > routines to convert from local to big or > small endian, as needed. Yes, but I'll leave the endian fixing up to you. Do we care about middle endian, a la PDP ? > >- Return a bool for true/false rather than 0/1 Sorry, got left in the conversion from C. > >- Would rather see _P files migrated into > bmp.cpp OK, I'll put it in and remove it from the Makefile and cvs. > >- Any need to dynamically allocate BitmapFile > rather than on the stack? Remnant style from when BitmapFile had FileHeader and InfoHeader on stack instead of heap. I often got stack overflows when dealing with many of them. I'll change it. > >- Constructor initialisers should be in > the form > > A::A() > : _foo(0), > _bar(1) > { > } > OK. >- Constructor initialiser should be correctly > ordered. > >- if( fileType != BMP_FILE_ID ) -> > if (fileType!=BMP_FILE_ID) Fine. > >- #include <cstdlib> > #include <cstdio> > #include <cstring> ?? > >- Please #ifdef bmp.cpp so that your implementation > is disabled by default and remove _P.cpp from > Makefile - GLT is now basically broken in CVS. I'll #ifdef them. I didn't know it broke the make process, but I'll remove it. On my box it works just fine. What is wrong with it? Are there unresolved symbols in libglt from it ?? > >But overall, it does seem to be taking form! >Is there going to be support for compressed >BMP? > >Nigel > Yeah it is looking more uniform. We'll get there in the end. I'll add compression support soon. We will need to change the API for GLT 0.9 to cope with saving to compressed bmp.... unless we add a default bool at the end of the encodeBMP. encodeBMP (..., bool compress = false); that should leave old code intact whilst exposing the compression option. Jacques. > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Glt-devel mailing list >Glt...@li... >https://lists.sourceforge.net/lists/listinfo/glt-devel _________________________________________________________________ You could be a genius! Find out by taking the IQ Test 2003. $5.50 (incl GST). Click here: http://sites.ninemsn.com.au/minisite/testaustralia/ |
From: Nigel S. <ni...@ni...> - 2004-03-16 03:09:27
|
Hi Jaques, A couple of issues with the current BMP CVS: - Tabs are four spaces, not three - Does this compile with gcc? - Lack of const for member functions - Try this for tider buffer read/write: template<class T> T readBuffer(const byte **pos) { const T *tmp = reinterpret_cast<const T *>(*pos); *pos += sizeof(T); return *tmp; } template<class T> void writeBuffer(byte **pos, const T &val) { T *tmp = reinterpret_cast<T *>(*pos); *tmp = val; *pos += sizeof(T); } - It looks like we may need to extend endian routines to convert from local to big or small endian, as needed. - Return a bool for true/false rather than 0/1 - Would rather see _P files migrated into bmp.cpp - Any need to dynamically allocate BitmapFile rather than on the stack? - Constructor initialisers should be in the form A::A() : _foo(0), _bar(1) { } - Constructor initialiser should be correctly ordered. - if( fileType != BMP_FILE_ID ) -> if (fileType!=BMP_FILE_ID) - #include <cstdlib> #include <cstdio> #include <cstring> - Please #ifdef bmp.cpp so that your implementation is disabled by default and remove _P.cpp from Makefile - GLT is now basically broken in CVS. But overall, it does seem to be taking form! Is there going to be support for compressed BMP? Nigel |
From: Jacques G. <jac...@ho...> - 2004-03-15 11:31:41
|
After a few hours of work I hooked in the new code into the makefile and bmp.cpp . It compiles fine on my computer, MDK 9.2 . Now we need to write some tests and see if the code holds up. Jacques. _________________________________________________________________ We've 100s of NEW questions! Play Millionaire online to win $$$$. Click here http://sites.ninemsn.com.au/minisite/millionaire/default.asp |
From: Jacques G. <jac...@ho...> - 2004-03-13 17:05:06
|
I'm aiming at supporting as much of the BMP file format as possible, so that includes the BMP version of PackBits as well. In short, Yes. I'll commit an iteration of the changes tonight. So keep checking to see how it looks. Jacques. >Jacques, > >Looking forward to the next rev! > >Are we aiming here for full BMP support, including >compressed formats? > >Nigel > >>OK, I'll remove redundant code. I'll keep bmp_P.h submerged in bmp.cpp >>until we are satisfied with the quality of the code in bmp_P*, then we can >>just merge it in to the file. > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Glt-devel mailing list >Glt...@li... >https://lists.sourceforge.net/lists/listinfo/glt-devel _________________________________________________________________ What's your house worth? Click here to find out: http://www.ninemsn.realestate.com.au |
From: Nigel S. <ni...@ni...> - 2004-03-13 15:28:34
|
Jacques, Looking forward to the next rev! Are we aiming here for full BMP support, including compressed formats? Nigel > OK, I'll remove redundant code. I'll keep bmp_P.h submerged in bmp.cpp > until we are satisfied with the quality of the code in bmp_P*, then we > can just merge it in to the file. |
From: Jacques G. <jac...@ho...> - 2004-03-13 12:13:48
|
Response to discussion Re: bmp code >Some issues with BMP code: >- This is a C++ library, not C I gathered as much, there should be no probs to fix that. >- use new and delete, not malloc and free As above >- Granularity of bmp_C.c is too fine, too many funcs Yeah, that is more a remnant of debugging. >- Standard C++ headers, not ANSI C: I agree. >#include <stdlib.h> -> <cstdlib> >#include <stdio.h> -> <cstdio> >#include <string.h> -> <cstring> >- GLT has byte, int32, uint32 but no dword_t or byte_t byte_t -> byte, word_t -> uint16, dword_t -> uint32 ?? >http://www.nigels.com/glt/doc/glt_2config_8h.html >- No need to handle files, we deal with memory buffers >- Endian routines already provided by misc/endian.h >- All BMP related code should be in bmp.cpp (modularity) >- Internal functions should be static to bmp.cpp scope >- Generalised functions in image.h should be used where possible The idea with the _P suffix is to imply that it is included only in the .cpp . I like keeping the byte moving away from the structure of the file type, purely to make it easier to debug. I suggest we keep them separate ( bmp.cpp and bmp_P.cpp ) until we are sure bmp_P.cpp is bug free, and then merge them. What do you think? >- There should no need for any additional interface in image.h Absolutely, that would break the API ! And that is a big no no. /*! \brief Decode image data from BMP \ingroup Misc \param width Width of BMP \param height Height of BMP \param image Destination RGB buffer \param data Source data buffer \todo Windows BMP import limited to RGB images */ bool decodeBMP(uint32 &width,uint32 &height,std::string &image,const std::string &data); /*! \brief Encode image data as RGB Windows BMP \ingroup Misc \param data BMP output buffer \param width Image width \param height Image height \param image Input image buffer \todo Not yet implemented */ bool encodeBMP(std::string &data,const uint32 width,const uint32 height,const std::string &image); >> Anyway, I just commited four files to GLT. bmp_P.c/h and >>image_helper.c/h I just >>wanted you to check them out and see if you >>think the coding style and all the other >>stuff is along GLT lines. >I think the style is still fairly far away, but we can get there over a >couple of iterations, if you're willing and able to migrate >and/or extend the existing bmp.cpp interface and implementation. Sure thing. >>I would like to make sure the methods in image_helper follow the same >>method as >>you. Hope you don't mind the files being straight C? If >>everything is OK I will integrate >>the files with GLT. >Convert to C++. It's a C++ library - C++ is better than C in many ways. >I have the patience to do tidy C++ abstractions, not the patience to deal >with (generally) messey C API's. :-) Yepp. >> It took me a while to convert most of the functions to use buffers >>instead of files but >>I have been testing them and I can't find any >>bugs.... so far. >Ok, but lets eliminate the FILE * based code. And keep in mind that all the >stuff in bmp_P.h either needs to be >submerged in bmp.cpp or removed. OK, I'll remove redundant code. I'll keep bmp_P.h submerged in bmp.cpp until we are satisfied with the quality of the code in bmp_P*, then we can just merge it in to the file. Cheers, Jacques. _________________________________________________________________ We've 100s of NEW questions! Play Millionaire online to win $$$$. Click here http://sites.ninemsn.com.au/minisite/millionaire/default.asp |
From: Nigel S. <ni...@ni...> - 2002-01-21 22:40:07
|
> Hi! > > > g++ -Wall -I/usr/local/include -I/usr/local/glt/src -o MainWindow.o > > main.o -lGL -lGLU -lglut -L/usr/local/glt/lib -lglt -lglui -lglutm > > -L/usr/X11R6/lib -lXmu -lXext -lXi -lX11 > > Try putting -lglutm before -lglt since there is a dependency there. > GL and GLU should be after glut, and glui should be before glut. > You can check that the symbols are in the libglt.a file: > > $ objdump -t /usr/local/glt/lib/libglt.a | grep GltFrameBuffer -- Nigel Stewart (ni...@ni...) http://www.nigels.com/ |
From: Achim <ac...@vf...> - 2002-01-18 16:56:11
|
Hi! I'm getting lots of linker errors (unresolved symbols) when using the following command line: g++ -Wall -I/usr/local/include -I/usr/local/glt/src -o MainWindow.o main.o -lGL -lGLU -lglut -L/usr/local/glt/lib -lglt -lglui -lglutm -L/usr/X11R6/lib -lXmu -lXext -lXi -lX11 ld complains about missing references to GltFrameBuffer and GltViewport. What did I do wrong? All glt libraries are in /usr/local/glt/lib and I think I'm linking all of them. Any suggestions? Thanks Achim |
From: Nigel S. <ni...@ni...> - 2001-12-05 13:37:23
|
Welcome to the glt-devel mailing list. This message is a test. -- Nigel Stewart (ni...@ni...) http://www.nigels.com/ |
From: Nigel S. <ni...@ni...> - 2001-12-05 11:38:56
|
Hi, This is a first message for the GLT announcement list at sourceforge. Nigel -- Nigel Stewart (ni...@ni...) http://www.nigels.com/ |