Nadro wrote: REDDemon wrote:
So my patch is ok for you?
No, we can't use video driver call like a ITexture::lock() in a createImageFromFIle method (threading problem). Now I understand Hybrid's solution and it's similar to my idea, it's only extended. We have to also remove extra class from Your patch - CKhronosTexture and prepare KTX support in standard C[DriverName]Texture and CImageLoaderKTX (it will include many lines of code from Your CKhronosTexture file) a files.
BTW. We'll firstly release v1.8, before adding a compression texture support.
When Hybrid will tell his solution I'll decide to agree or less to your statement. For now he has just told some general guidelines ^^. I think that what he sad is mostly related to the patch I 'm working on than your solution.
Also If you say so I think that you just didn't looked at my patch on the tracker but only at the snippet on my project page. The snippet is made for Irrlicht 1.7 and 1.8 users to have texture compression already available. The real patch is currently in testing phase (and is directly builded above the latest revision). The pre-patch gives an Idea of what will be changed but does not have any CKhronosTexture. Please before criticize my patch at least read it ^^ (and read that there: viewtopic.php?f=2&t=46041
). I'm taking you seriously, but there are slight pros with your solution.
I think that Hybrid will consider also my solution.
You have solved a thread problem... (not just really solved, you moved the thread problem from "createImageFromFile" to "Itexture->lock" because at some point the user will need to compress/decompress data in some way and that can be done only with a GL context. So there will be exactly the same problem of creating the Image, with the added difficulty that there's the need to the users to handle decompression. What if the user didn't checked if compression is supported at this point? with my solution the user simply was not able to load unsupported "images", this make the application even easier to debug. if something works, it works immediatly. If something don't works it don't works immediatly.)
Seriously. If the only deal is solving a specific
thread problem with huge API changes.
Why it should be added instead of a general
solution wich is simpler/more maintenable/without API changes? You should be masocist for doing do that^^.
Multythreading Is really specific on how you implement it. So if you want to make that method thread safe why you want to do that only for that method? at this point you should make whole Irrlicht thread safe. Even some times ago (don't remember who) someone sad that texture compression will not be added to Irrlicht. And now everyone have its own solution ^^. Making all that changes for a single method and then other methods not thread safe? If your solution will be added I hope that also lots of other methods will be made threadsafe^^.
Multithreading is specific on how you implement it. For example I'm using texture compression on my terrain manager and texture streamin^^ And works perfectly with my solution..
1) Thread 1: Irrlicht start (any driver)
2) Thread 2: Irrlicht start (OpenGL) // the second thread don't share any data with first thread. Except for sporadic read-only locks.
3) Thread1 (main thread) -> request to Thread2 of loading Image
4) Thread2 ->receive the message-> createImageFromFile (download from hardware the texture already uncompressed).
5) Thread2-> loading finished-> signal to Thread1
5) Thread1-> receive the message-> lock the data of the Image and copy (readonly) it in its memory.
(are 2 devices expensive? probably yes. but only at startup. At run time there is huge improvement without pauses for loading and anyway that's just a specific usage. No one will do again the same. )
I also now that you are already involved in irrlicht development so your opinion just matters for that^^. But just give hybrid time to see/consider my solution at least. AFAIK if a feature can be added without API changes that is great. What if everyone added API changes for every improvement?
OpenGL is not hard. What you have to do is just explained in specifications. What is hard is dealing with poor OpenGL implementations.