Re: d3dx9: Texturing functions
So, the first thing I want to make sure is that we redirect the function calls correctly in order to reduce double coding. This means on the one hand that we should call the Extended versions of each function from inside of the simpler ones (most default parameters for the Ex functions are on MSDN) and on the other hand that we unify all D3DXCreateTextureFromXXEx functions somehow. I don't know how Resources are stored internally, but I guess the simplest would be to redirect all of them to D3DXCreateTextureFromFileInMemory, i.e. when D3DXCreateTextureFromFile is called we read the file into memory and call the InMemory function. I hope this shouldn't be too hard to be applied to the resource function either. Of course, this should also be done at the corresponding Surface, Volume and cube texture functions. Also, I haven't looked too much into it yet, but I guess we could go even a step further and define the CreateTextuteFromXX calls like this: 1. Redirect to the corresponding D3DXCreateXFromFileInMemoryEx call 2. Call D3DXCheckXRequirements 3. Call IDirect3DDevice9::CreateTexture 4. Lock its surface 5. Call LoadSurfaceFromFileEx with it This would reduce most of our coding work on LoadSurfaceFromFileEx. However, there are still plenty of formats supported by the texturing functions and thus, plenty of work for us to do. IIRC we once came to the decision to use libraries like libpng or so to reduce that work, too, so we'd just need to implement formats like .dds. I can't remember what the differences are between the CreateTexture and LoadSurface functions, but this is what I'd do for the LoadSurface functions: LoadSurfaceFromMemory (read data with the specified pixel format) LoadSurfaceFromFileInMemory (parse image format, read actual data into memory) LoadSurfaceFromFile (open file, read contents into memory) LoadSurfaceFromResource (open resource, read contents into memory) LoadSurfaceFromSurface (read image data from a surface) This would mean two huge chunks of code: One which parses image formats (LoadSurfaceFromFileInMemory), and one which handles all the resizing, conversion, filtering and stuff (LoadSurfaceFromMemory). Sorry that I'm replying that late, I was a bit busy when you wrote the reply and then nearly forgot about it. I'd agree with that design and I'll soon prepare a stub-layout for texture.c for after-code-freeze. However, have you finished the D3DXCheckTextureRequirements code meanwhile so we can start implementing the other functions? Best regards, Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
Re: d3dx9: Texturing functions
On Sat, Apr 19, 2008 at 10:11:06AM +0200, [EMAIL PROTECTED] wrote: So, the first thing I want to make sure is that we redirect the function calls correctly in order to reduce double coding. This means on the one hand that we should call the Extended versions of each function from inside of the simpler ones (most default parameters for the Ex functions are on MSDN) and on the other hand that we unify all D3DXCreateTextureFromXXEx functions somehow. I don't know how Resources are stored internally, but I guess the simplest would be to redirect all of them to D3DXCreateTextureFromFileInMemory, i.e. when D3DXCreateTextureFromFile is called we read the file into memory and call the InMemory function. I hope this shouldn't be too hard to be applied to the resource function either. Of course, this should also be done at the corresponding Surface, Volume and cube texture functions. Also, I haven't looked too much into it yet, but I guess we could go even a step further and define the CreateTextuteFromXX calls like this: 1. Redirect to the corresponding D3DXCreateXFromFileInMemoryEx call 2. Call D3DXCheckXRequirements 3. Call IDirect3DDevice9::CreateTexture 4. Lock its surface 5. Call LoadSurfaceFromFileEx with it This would reduce most of our coding work on LoadSurfaceFromFileEx. However, there are still plenty of formats supported by the texturing functions and thus, plenty of work for us to do. IIRC we once came to the decision to use libraries like libpng or so to reduce that work, too, so we'd just need to implement formats like .dds. I can't remember what the differences are between the CreateTexture and LoadSurface functions, but this is what I'd do for the LoadSurface functions: LoadSurfaceFromMemory (read data with the specified pixel format) LoadSurfaceFromFileInMemory (parse image format, read actual data into memory) LoadSurfaceFromFile (open file, read contents into memory) LoadSurfaceFromResource (open resource, read contents into memory) LoadSurfaceFromSurface (read image data from a surface) This would mean two huge chunks of code: One which parses image formats (LoadSurfaceFromFileInMemory), and one which handles all the resizing, conversion, filtering and stuff (LoadSurfaceFromMemory). -- Philip Nilsson
d3dx9: Texturing functions
Hi all, as it's a larger chunk of functions, I felt like proposing my design idea for the D3DXCreateTexture/Volume/CubeTextureFromFile/Resource/FileInMemory/etc... functions. I'm CC'ing it to any wine d3dx coder I have in my addressbook yet, so sorry if I forgot one :) So, the first thing I want to make sure is that we redirect the function calls correctly in order to reduce double coding. This means on the one hand that we should call the Extended versions of each function from inside of the simpler ones (most default parameters for the Ex functions are on MSDN) and on the other hand that we unify all D3DXCreateTextureFromXXEx functions somehow. I don't know how Resources are stored internally, but I guess the simplest would be to redirect all of them to D3DXCreateTextureFromFileInMemory, i.e. when D3DXCreateTextureFromFile is called we read the file into memory and call the InMemory function. I hope this shouldn't be too hard to be applied to the resource function either. Of course, this should also be done at the corresponding Surface, Volume and cube texture functions. Also, I haven't looked too much into it yet, but I guess we could go even a step further and define the CreateTextuteFromXX calls like this: 1. Redirect to the corresponding D3DXCreateXFromFileInMemoryEx call 2. Call D3DXCheckXRequirements 3. Call IDirect3DDevice9::CreateTexture 4. Lock its surface 5. Call LoadSurfaceFromFileEx with it This would reduce most of our coding work on LoadSurfaceFromFileEx. However, there are still plenty of formats supported by the texturing functions and thus, plenty of work for us to do. IIRC we once came to the decision to use libraries like libpng or so to reduce that work, too, so we'd just need to implement formats like .dds. And the last thing I'd like to ask goes to Louis Lenders: I've just found out that you have been working on a D3DXCreateTextureFromFile implementation. Are you still working on that? I'm really looking forward to do some coding work again, so I could continue your implementation from the 24th March if you've stopped to work on it ;-) However, feel free to comment on my proposals for the texturing functions and tell me if you see any concerns with it :) Best regards, Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
