Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
On Friday 25 March 2011 08:40:04 Joshua Beck wrote: > Is there any documentation I can read on how to program for these DLLs? > I've been looking through MSDN and I can't find anything specifically > about those DLLs. However I did find Windows Imaging Component (which I > think is what windowscodecs.dll implements) and that seems like it would > be helpful for the D3DXSaveSurfaceTo* functions. gdi32 is the classic Windows graphics API used by pretty much every application for drawing text, bitmaps, lines etc. It has some functions to load bitmaps from files. windowscodecs handles the newer formats I think, so it is probably what you want. You can make use of both dlls too.
Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
On 03/20/2011 05:42 PM, Stefan Dösinger wrote: Wrt this specific function we already have some related infrastructure for D3DXLoadSurfaceFrom* . Also other parts of Wine(gdi32.dll, windowscodecs.dll) have functions for handling various on-disk file formats which can(and should) be used. (That's just some generic implementation hint, it doesn't mean that it makes the idea good or bad) Is there any documentation I can read on how to program for these DLLs? I've been looking through MSDN and I can't find anything specifically about those DLLs. However I did find Windows Imaging Component (which I think is what windowscodecs.dll implements) and that seems like it would be helpful for the D3DXSaveSurfaceTo* functions.
Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
On Sunday 20 March 2011 22:29:34 Joshua Beck wrote: > I erred on the side of caution because I didn't want to spend all summer > working on a project that I couldn't finish. Finding the right amount of work is certainly tricky. Luckily d3dx9 has many functions, so if you find out that you have plenty of time left you can include extra work in your project later on. You don't have to get the set of work perfect at the start - reevaluating the amount of work needed and adjusting the goals during the project is part of gsoc. However, finding a most likely doable, but not overly simple set of work does improve the application. We'll provide feedback on this(as I just did, I hope others who know the library better will jump in if I am telling you incorrect things) > However I do have other > ideas that I would also like to implement. For instance, I would be > willing to implement the D3DXSave[Surface/Texture]ToFile* functions for > all file formats currently supported by WINE. Wrt this specific function we already have some related infrastructure for D3DXLoadSurfaceFrom* . Also other parts of Wine(gdi32.dll, windowscodecs.dll) have functions for handling various on-disk file formats which can(and should) be used. (That's just some generic implementation hint, it doesn't mean that it makes the idea good or bad) signature.asc Description: This is a digitally signed message part.
d3dx10: Float16To32Array and Float32To16Array (GSoC)
I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn’t committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch’s code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck
Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
On 3/20/2011 1:02 PM, Stefan Dösinger wrote: On Sunday 20 March 2011 18:15:20 Joshua Beck wrote: I'm looking for feedback on an idea for a Google Summer of Code project. Cool, thanks for your interest! I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn’t committed yet. I think those two functions are way too small for a summer of code project(~2.5 months of work). I implemented the original half-float conversion code in wined3d, and it took me about a day with some tests. This code didn't have to deal with too many special cases, so the d3dx* implementation is a bit more work, but still not enough to fill 2.5 months. I erred on the side of caution because I didn't want to spend all summer working on a project that I couldn't finish. However I do have other ideas that I would also like to implement. For instance, I would be willing to implement the D3DXSave[Surface/Texture]ToFile* functions for all file formats currently supported by WINE. The general idea I have for implementing them is to have two basic groups of functions. One would be to convert the format that the surface or texture is stored in to an intermediate, uncompressed format. The other group would convert from this uncompressed format to another format supported by these functions. If that isn't enough, I would also be willing to start adding support for DDS files to the various functions that need them (for example GetImageInfo*, LoadSurface*, and Save[Texture/Surface]*).
Re: d3dx10: Float16To32Array and Float32To16Array (GSoC)
On Sunday 20 March 2011 18:15:20 Joshua Beck wrote: > I'm looking for feedback on an idea for a Google Summer of Code project. Cool, thanks for your interest! > I looked at bugzilla and found that the D3DX9 versions of > Float16To32Array and Float32To16Array were needed for some games to run. > I thought that implementing those functions would make a good Google > Summer of Code project, but later discovered that Misha Koshelev had > already implemented them in a patch that wasn’t committed yet. I think those two functions are way too small for a summer of code project(~2.5 months of work). I implemented the original half-float conversion code in wined3d, and it took me about a day with some tests. This code didn't have to deal with too many special cases, so the d3dx* implementation is a bit more work, but still not enough to fill 2.5 months. signature.asc Description: This is a digitally signed message part.
d3dx10: Float16To32Array and Float32To16Array (GSoC)
I'm looking for feedback on an idea for a Google Summer of Code project. I looked at bugzilla and found that the D3DX9 versions of Float16To32Array and Float32To16Array were needed for some games to run. I thought that implementing those functions would make a good Google Summer of Code project, but later discovered that Misha Koshelev had already implemented them in a patch that wasn’t committed yet. In looking up documentation on half floats and these functions gave me ideas for other improvements. For instance, the functions may be implemented differently in D3DX10. A post in this thread: http://www.devmaster.net/forums/showthread.php?t=10924 says that D3DX10 uses different rounding rules and can store NaNs and infinities. I have access to computers running Vista and 7 so I would be able to test how the D3DX10 versions of the functions convert floating point numbers. After doing so, I could make the D3DX10 versions of the functions by modifying the D3DX9 patch’s code. I could also write a conformance test to make sure that the functions are implemented correctly in D3DX10. Joshua Beck
