Jump to content
  • Advertisement

darkzorb

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

128 Neutral

About darkzorb

  • Rank
    Newbie
  1. Hi,   I'm having trouble understanding how to go about defining unaligned pointers. The reason I need them is that they are suggested for the ID3DXFileData::Lock method, to be used as the data buffer.   http://msdn.microsoft.com/en-us/library/windows/desktop/bb205845(v=vs.85).aspx   I read a bit online that there's the __packed qualifier, but when I tried using it, it came up undefined. Can someone point me in the right direction? Maybe I just don't understand alignment and am looking for a quick and easy solution where there is none.
  2.   Hey Buckeye,   Thanks for testing material template inside and outside of the frame hierarchy with your own code. If not even D3DXLoadMeshFromX/D3DXLoadMeshHierarchyFromX loads the X-File correctly when inside the frame hierarchy, that's enough evidence for me to assume the format for my X-Files are not written as they were intended. I will go ahead and take your suggestion of modifying all the offending X files. Thanks for the help!
  3.   You actually didn't miss the mention of GetChildren(). I added that to the title after your initial response because I felt that my thread title was a bit vague before. Sorry about the confusion.       Yeah, I would like to get rid of the interface altogether at some point, but I'm really just not all that ambitious right now to go that route as I would not only have to rewrite a lot of code but would also need to redo the 100s of models I have. It's definitely something I'll consider in the future though. For now, I'm just trying to port the program which in the past only worked on 32-bit Windows to now also run on a 64-bit Windows client. The 32-bit program had used the even older IDirectXFile interface, which lacks compatibility with 64-bit. This is why I switched over to ID3DXFile, since it does have 64-bit compatibility. Unfortunately, ID3DXFile no longer supports the GetNextObject() method which had parsed all the mesh files correctly, and now uses the GetChildren() method to scan for templates.       To be honest, I'm not really sure why the original developer designed the architecture of the program in this way. What the program currently does is, it reads in data from .X model files into a structure which can be later read by OpenGL to display the graphics. Honestly, it would have made more sense to use all DirectX or do the graphics part with OpenGL but without the X-file API, but unfortunately that's not how the previous developer did things, and I really don't have the time at this current point in time to redo everything from the grounds up  .       Yes, you are correct! I do have a lot of existing files in that format, which is why I'm hoping that I don't need to go and modify every single X-File I have that isn't being parsed correctly.       Hmm, as far as I know, the previous developer did not have any special parsing code to recognize "variables" and replace them with material data, it seemed the GetNextObject() method inherently has the capability to recognize these references and replace them with the associated named template.       I hope I'm understanding your question correctly, but correct me if I'm not. What I have posted above is exactly what is in the file, I did not alter it in any way. In the file {material1} is not replaced with the actual contents of the material. It merely has "{material1}" as the text, and uses it as an embedded template reference, which should be picked up by the ID3DX interface GetChild() method to automatically replace the reference with a previous declaration of the template with that name.       From what I've read, X-Files has supported these embedded template references for a while. The page linked below has some examples where they have materials defined, and then inserts a reference by the material name. http://paulbourke.net/dataformats/directx/
  4. Hey Buckeyes,   First of all, thanks for the response. Appreciate you reading over my post and trying to help. Forgive me if some of my assumptions are incorrect as I work through your post, as I'm still new to DirectX.     I register the D3DRM_XTEMPLATES found in rmxftmpl.h. That way I don't need all of the template front matter in every single .X file. Plus I only use predefined templates, so D3DRM_XTEMPLATES is more than enough. Below is the contents of my .X file in it's original non-working format. As I originally stated, when I move the material out of the Root frame, so that it is the first template in the file, all of a sudden the material1 reference found in the MeshMaterialList is recognized by the GetChildren() call when parsing MeshMaterialList. See code example at end of post for clarification of this move. Frame Root { FrameTransformMatrix { 1.000000, 0.000000, 0.000000, 0.000000, 0.000000,-0.000000, 1.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 1.000000;; } Material material1 { 0.000000;0.000000;0.000000;0.000000;; 0.000000;0.000000;0.000000;0.000000;; 0.000000;0.000000;0.000000;; TextureFilename { "material1.bmp"; } } Frame Cube { FrameTransformMatrix { 1.750000, 0.000000, 0.000000, 0.000000, 0.000000, 0.583333, 0.000000, 0.000000, 0.000000, 0.000000,16.291666, 0.000000, -0.010820, 0.000000, 0.000000, 1.000000;; } Mesh { 8; -0.304800;-0.304800;-0.304800;, -0.304800; 0.304800;-0.304800;, 0.304800; 0.304800;-0.304800;, 0.304800;-0.304800;-0.304800;, -0.304800;-0.304800; 0.304800;, -0.304800; 0.304800; 0.304800;, 0.304800; 0.304800; 0.304800;, 0.304800;-0.304800; 0.304800;; 6; 4;0,1,5,4;, 4;1,2,6,5;, 4;2,3,7,6;, 4;3,0,4,7;, 4;3,2,1,0;, 4;4,5,6,7;; MeshNormals { 6; -1.000000; 0.000000; 0.000000;, 0.000000; 1.000000;-0.000000;, 1.000000; 0.000000;-0.000000;, 0.000000;-1.000000; 0.000000;, -0.000000; 0.000000;-1.000000;, -0.000000; 0.000000; 1.000000;; 6; 4;0,0,0,0;, 4;1,1,1,1;, 4;2,2,2,2;, 4;3,3,3,3;, 4;4,4,4,4;, 4;5,5,5,5;; } MeshMaterialList { 1; 6; 0, 0, 0, 0, 0, 0;; {material1} } } } } ?   As far as I know the MeshMaterialList template for X-Files hasn't changed from IDirectXFile to ID3DX. I looked at the template format found on the Microsoft website and it still seems to look the same. Not sure why it would parse correctly in the past with GetNextObject(), but returns zero children with GetChildren(). But maybe I'm just not understanding your explanation correctly.   http://msdn.microsoft.com/en-us/library/windows/desktop/bb147192(v=vs.85).aspx   Moreover, if the format of MeshMaterialList is incorrect, then it goes back to my original question of, why does it parse correctly when I move material1 outside of the Root frame. If {material1} is undefined when written in this way, then shouldn't GetChildren() similarly not recognize the reference when parsing the X-File with material1 outside of the Root frame?   For clarification, this is the adjustment to the X-File that causes the material1 reference to be recognized by GetChildren(). Again, I would make the edit to my X-Files, but the problem is, I have a bunch of X-Files that use the above format, and I rather not manually edit all of them. Much rather have a more robust parser if at all possible. Material material1 { 0.000000;0.000000;0.000000;0.000000;; 0.000000;0.000000;0.000000;0.000000;; 0.000000;0.000000;0.000000;; TextureFilename { "material1.bmp"; } } Frame Root { FrameTransformMatrix { 1.000000, 0.000000, 0.000000, 0.000000, 0.000000,-0.000000, 1.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 0.000000, 0.000000, 1.000000;; } Frame Cube { FrameTransformMatrix { 1.750000, 0.000000, 0.000000, 0.000000, 0.000000, 0.583333, 0.000000, 0.000000, 0.000000, 0.000000,16.291666, 0.000000, -0.010820, 0.000000, 0.000000, 1.000000;; } Mesh { 8; -0.304800;-0.304800;-0.304800;, -0.304800; 0.304800;-0.304800;, 0.304800; 0.304800;-0.304800;, 0.304800;-0.304800;-0.304800;, -0.304800;-0.304800; 0.304800;, -0.304800; 0.304800; 0.304800;, 0.304800; 0.304800; 0.304800;, 0.304800;-0.304800; 0.304800;; 6; 4;0,1,5,4;, 4;1,2,6,5;, 4;2,3,7,6;, 4;3,0,4,7;, 4;3,2,1,0;, 4;4,5,6,7;; MeshNormals { 6; -1.000000; 0.000000; 0.000000;, 0.000000; 1.000000;-0.000000;, 1.000000; 0.000000;-0.000000;, 0.000000;-1.000000; 0.000000;, -0.000000; 0.000000;-1.000000;, -0.000000; 0.000000; 1.000000;; 6; 4;0,0,0,0;, 4;1,1,1,1;, 4;2,2,2,2;, 4;3,3,3,3;, 4;4,4,4,4;, 4;5,5,5,5;; } MeshMaterialList { 1; 6; 0, 0, 0, 0, 0, 0;; {material1} } } } }
  5. Hey Everyone,   I'm trying to debug some code I have which reads in .X files. The problem I'm having is depending on the structure format of my .X files, sometimes the embedded template references are not read.   I have a particular template with the following format:   Frame Root {     FrameTransformMatrix {...}     Material material1 {...}     Frame ChildFrame {         FrameTransformMatrix {...}         Mesh {             MeshNormals {...}             MeshMaterialList {...                 {material1}             }         }     } }   And for some reason when I perform a getChildren when I am parsing the MeshMaterialList template, 0 children are found. It seems material1 is not recognized even though I define it before the ChildFrame.   What I noticed is that when I take the material out of the Root frame, all of a sudden DirectX recognizes the previously defined template. So my new template would take the following form:   Material material1 {...} Frame Root {     FrameTransformMatrix {...}     Frame ChildFrame {         FrameTransformMatrix {...}         Mesh {             MeshNormals {...}             MeshMaterialList {...                 {material1}             }         }     } }   Anyone have any idea why DirectX would not recognize the material1 template in the first format?   To clarify what I'm trying to do, I recently updated some old 32-bit code which read X-Files using the old IDirectXFile interface to use the 64-bit compatible ID3DX interface. So I'm still registering templates and creating enumeration objects in the same way. My old .X files mostly get read in correctly except for those in the format listed above. I would manually change the .X files, but I'd rather retain the robustness of the type of .X files that the code can read in if at all possible.   I saw that the new ID3DXFile interface has a new RegisterEnumTemplates method which wasn't in the old IDirectXFile API. Not sure what it is, so I tried using it to register templates, but it didn't seem to do anything, or maybe I'm just not using it correctly.   Not sure if my post makes any sense. I'm still a bit new to DirectX, so forgive me if I'm lacking clarity in any of my explanation of the problem. Any suggestions/hints on this matter would be greatly appreciated. Thanks!
  6. So I finally had a chance to try using DirectSetup and deploy all the D3DX* files that were missing from the default SDK...and I realizing I'm confused as to what I'm actually looking for. It didn't deploy any DLL's specified "D3DX9.DLL", there's just a bunch of D3DX9_##.DLLs which I believe I had even before the install.   To provide more context for what I'm attempting to achieve, my program currently loads XFiles utilizing a procedure similar to the one found here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb174704(v=vs.85).aspx   The first step in that procedure utilizes a method DirectXFileCreate to create an IDirectXFile object, and this particular method according to the MSDN library link below requires d3dxof.lib: http://msdn.microsoft.com/en-us/library/windows/desktop/bb219709(v=vs.85).aspx   My original thinking was that the original poster on the Xbox forum was insinuating that there is a 64-bit compatible d3dx9.dll which utilizes all the same methods for dealing with the XFile API, and that I would just need to include d3dx9xof.h and everything would be golden. That does not appear to be the case...I know wishful thinking. I commented out my line regarding the d3dxof.lib link and now it has no idea how to process the DirectXFileCreate call.   Again, I'm really new to DirectX development, so maybe I'm just missing something really obvious, but if anyone has any pointers to get me in the right direction it would be greatly appreciated.   UPDATE (Edit): I searched around and finally found some documentation in regards to the new XFile API that utilizes d3dxof.h. The method names changed, apparently DirectXFileCreate is now D3DXFileCreate, and it uses a new format called ID3DXFile instead of the old XFile API which used IDirectXFile.   The documentation is located here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb172985(v=vs.85).aspx   Pretty cool stuff. Looks like I've got lots of work to do. I'm going to start updating my code. Thanks again, appreciate the help! Cheers!
  7. First of all, thank you both for prompt responses.       Alessio1989, I tried utilizing the d3dxof.lib contained in the June2010 DirectX SDK thinking that maybe the d3dxof.lib I was currently linking to was outdated, but it's still complaining about a missing d3dxof.dll. Is that static library by any chance linking to the .dll and thus giving me that error?         kauna, thank you for the information. I'm waiting for my admin to use DirectSetup to deploy D3DX9.DLL, but once it's installed, I'll let you know if that fixes the problem.
  8. Hi Everyone,   I'm new to this forums and directX development, but I recently was tasked with porting a 32-bit windows applications to 64-bit windows.   The program uses directX to load in .X model objects, and it runs fine in 32-bit. When I compile the application in 64-bit and then attempt to run the application it gives me the following error, "The program can't start because d3dxof.dll is missing from your computer. Try reinstalling the program to fix this program."   I started looking around for d3dxof.dll. I have the D9 SDK installed on Windows 7 64-bit. It looks like there's only a d3dxof.dll in the SysWOW64 folder (for 32-bit applications), and there isn't a version of the library in the system32 folder (for 64-bit applications).   I started searching around on google and wasn't able to find anyone else with a similar issue. If anyone is willing to shed any light on this issue, it would be greatly appreciated. Thanks!
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!