Thread: [tgtl-devel] Hello and more
Brought to you by:
bobvodka
Menu
▾
▴
tgtl-devel
|
From: Markus H. <mar...@gm...> - 2007-07-27 20:24:21
|
Hi there, as you have noticed I'm through with my patches in the bug fixing branch. There is one "bug" left I would like to discuss first: Bug: Loading a texture from a file fails when the file cannot be opened for writing (read only file system!). While it would be easy to just change the io mode when opening the file my solution would be to just remove the whole writing and seeking stuff and just work with boost source like devices. I didn't see writing being used anywhere and I think I removed seeking from all the filters. Do you see any problems with that? This leads me to another point. The whole device concept with boost::iostreams seems a little bit over engineered to me. While I think boost is a great thing and I advice it's usage in all bigger C++ projects I think for GTL the cost is bigger than it's value. I think it would be much easier for users of GTL not being forced to install additional dependencies to use it. The device interface could be implemented just as easy without boost::iostreams. The fixed size data types could be easyly moved to custom typedefs too. So for the next major release I think it would be a good idea to kick out boost and simplify the device concept. Do you agree? Have a nice weekend! Markus |
|
From: Robert J. <rob...@gm...> - 2007-08-20 05:22:13
|
Hi, Firstly, sorry about the huge delay in replying to this; between my normal ability to be distracted by 'good ideas', finding and starting work and my email server falling off the internet I've not had a chance to reply. Anyways; thanks for all the fixes and work you did. I've now merged them back into the main branch and, along with a rewrite of the PNG setup code (your reading loop is still the same, I just made some changes so it could handle paletted, grey and grey + alpha images), I've done a 2.2 release. Now, the bugs; I can't see any problem with your plan to fix problem which files which can't be opened for writing. Indeed if I had remembered about this bug I'd have fixed it myself before the 2.2 release (2.2.1 at some point soon I guess then). I did however remember about what you wrote with regards to the iostreams and boost usage; The iostreams got used for two reasons; one being my attraction to new things and the other being I thought they could solve various design issues. They did in a way but reintroduced a number along the road, so yes for the next major version I agree that they should be removed. In fact, I don't know how compatible they would be with the concept of adding async file loading in the next revision (optional; so you can still load as now but also an interface will exist to allow async loading.. I'm still working on the details). As for kicking boost out completely, I'm not so convinced; while iostreams is going to go until C++ gets fixed data sizes I'd much rather rely on someone else doing the work for other platforms rather than myself (or anyone else). Also, boost::shared_ptr<> is in the public interface for the safe loading routines and while writing a smart pointer could be considered trivial I'm not keen on reinventing that wheel; plus it just becomes another interop problem as now the user needs to support whatever smart pointer we come up with and potentially another, I'd much rather go with something more standard (if TR1 was widely in use I'd consider dropping boost::shared_ptr for the TR1 revision, at which point the question about the usefulness of the fixed data sizes from boost alone could be called into question... in fact, there is probably some logic to switching to TR1 for the next version as boost supplies a lot of it, I'll have to try to remember to look into that). My final reasoning is that I would hope that GTL would be used in a large project and, imo, any C++ programmer who is even vaguely serious about using the language should have boost available, in header form if not compiled. So, in summary, while I'm behind shunting out iostreams boost itself stays for now, unless you have some other convincing reasons you can throw at me? With regards to the next major version I'll try to get some 'grand ideas' down on paper soon and post them to the list. -----Original Message----- From: tgt...@li... [mailto:tgt...@li...] On Behalf Of Markus Henschel Sent: 27 July 2007 21:24 To: tgt...@li... Subject: [tgtl-devel] Hello and more Hi there, as you have noticed I'm through with my patches in the bug fixing branch. There is one "bug" left I would like to discuss first: Bug: Loading a texture from a file fails when the file cannot be opened for writing (read only file system!). While it would be easy to just change the io mode when opening the file my solution would be to just remove the whole writing and seeking stuff and just work with boost source like devices. I didn't see writing being used anywhere and I think I removed seeking from all the filters. Do you see any problems with that? This leads me to another point. The whole device concept with boost::iostreams seems a little bit over engineered to me. While I think boost is a great thing and I advice it's usage in all bigger C++ projects I think for GTL the cost is bigger than it's value. I think it would be much easier for users of GTL not being forced to install additional dependencies to use it. The device interface could be implemented just as easy without boost::iostreams. The fixed size data types could be easyly moved to custom typedefs too. So for the next major release I think it would be a good idea to kick out boost and simplify the device concept. Do you agree? Have a nice weekend! Markus ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tgtl-devel mailing list tgt...@li... https://lists.sourceforge.net/lists/listinfo/tgtl-devel |
|
From: Markus H. <mar...@gm...> - 2007-08-20 20:36:31
|
Robert Jones schrieb: > Hi, > > Firstly, sorry about the huge delay in replying to this; between my normal > ability to be distracted by 'good ideas', finding and starting work and my > email server falling off the internet I've not had a chance to reply. > > Anyways; thanks for all the fixes and work you did. I've now merged them > back into the main branch and, along with a rewrite of the PNG setup code > (your reading loop is still the same, I just made some changes so it could > handle paletted, grey and grey + alpha images), I've done a 2.2 release. > > Now, the bugs; > > I can't see any problem with your plan to fix problem which files which > can't be opened for writing. Indeed if I had remembered about this bug I'd > have fixed it myself before the 2.2 release (2.2.1 at some point soon I > guess then). > > I did however remember about what you wrote with regards to the iostreams > and boost usage; > > The iostreams got used for two reasons; one being my attraction to new > things and the other being I thought they could solve various design issues. > They did in a way but reintroduced a number along the road, so yes for the > next major version I agree that they should be removed. In fact, I don't > know how compatible they would be with the concept of adding async file > loading in the next revision (optional; so you can still load as now but > also an interface will exist to allow async loading.. I'm still working on > the details). > > As for kicking boost out completely, I'm not so convinced; while iostreams > is going to go until C++ gets fixed data sizes I'd much rather rely on > someone else doing the work for other platforms rather than myself (or > anyone else). Also, boost::shared_ptr<> is in the public interface for the > safe loading routines and while writing a smart pointer could be considered > trivial I'm not keen on reinventing that wheel; plus it just becomes another > interop problem as now the user needs to support whatever smart pointer we > come up with and potentially another, I'd much rather go with something more > standard (if TR1 was widely in use I'd consider dropping boost::shared_ptr > for the TR1 revision, at which point the question about the usefulness of > the fixed data sizes from boost alone could be called into question... in > fact, there is probably some logic to switching to TR1 for the next version > as boost supplies a lot of it, I'll have to try to remember to look into > that). > > My final reasoning is that I would hope that GTL would be used in a large > project and, imo, any C++ programmer who is even vaguely serious about using > the language should have boost available, in header form if not compiled. > > So, in summary, while I'm behind shunting out iostreams boost itself stays > for now, unless you have some other convincing reasons you can throw at me? My main problem with boost was that it is such a huge thing. For small projects that want to use GTL just to get some textures loaded this is quite a lot of stuff to download. Furthermore a lot of game developers are quite conservative when using external libraries. When I introduced boost to my co-workers they thought I was joking to use a library with 20MB headers and about 1Gig of libs. On the other hand these people are probably not the ones using GTL as they will stick with the standard windows+directx setup anyway. Additionally GTL doesn't need to link to any boost lib so the headers are enough when iostreams are removed. So I think I can easily live with your opinion. > With regards to the next major version I'll try to get some 'grand ideas' > down on paper soon and post them to the list. Sounds interesting. One thing I could really need is image resizing and format conversion. Did you plan support for this stuff? Collada FX does support specifying texture size and format that differ from the image file used. It's quite a mess to do that using gluScaleImage as even version GLU 1.3 doesn't support all texture formats of opengl 2.0. But I'm not sure if it's not better to just skip this feature and leave image conversion to external applications as GTL was written to provide features actually needed by game engines and not stuff that hardly anyone might need. Regards, Markus |
Thanks for helping keep SourceForge clean.
X