argh!

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • [SIZE=1]
      hi all,

      Just a couple of random questions I have after reading Chapter 5. I know that more will be explained as I progress through the book so I'm not getting too caught up on the code just yet.

      1. Is it common for a professional game to use the DirectX framework or is this just used to keep us focused on the examples?

      Prior to reading this book, I did everything manually - create/register a window class and my D3D init code looked like this:

      Source Code

      1. void d3dApp::initD3D()
      2. {
      3. //1. DXGI_SWAP_CHAN_DESC
      4. DXGI_SWAP_CHAIN_DESC sd;
      5. //Back buffer dimensions and format.
      6. sd.BufferDesc.Width = mClientWidth;
      7. sd.BufferDesc.Height = mClientHeight;
      8. sd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM;
      9. //Full screen mode options.
      10. sd.BufferDesc.RefreshRate.Numerator = 60;
      11. sd.BufferDesc.RefreshRate.Denominator = 1;
      12. sd.BufferDesc.ScanlineOrdering = DXGI_MODE_SCANLINE_ORDER_UNSPECIFIED;
      13. sd.BufferDesc.Scaling = DXGI_MODE_SCALING_UNSPECIFIED;
      14. //No multisampling.
      15. sd.SampleDesc.Count = 1;
      16. sd.SampleDesc.Quality = 0;
      17. sd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
      18. sd.BufferCount = 1;
      19. sd.OutputWindow = hWndApp;
      20. sd.Windowed = true;
      21. sd.SwapEffect = DXGI_SWAP_EFFECT_DISCARD; //Let display driver select most efficient presentation method.
      22. sd.Flags = 0;
      23. UINT createDeviceFlags = 0;
      24. #if defined(DEBUG) || defined(_DEBUG)
      25. createDeviceFlags |= D3D10_CREATE_DEVICE_DEBUG;
      26. #endif
      27. //2. D3D10CreateDeviceAndSwapChain()
      28. D3D10CreateDeviceAndSwapChain(
      29. NULL, //Display Adapter, NULL == Use Primary Display Adapater.
      30. D3D10_DRIVER_TYPE_HARDWARE, //Specify D3D10_DRIVER_TYPE_REFERENCE for software implementation.
      31. NULL, //Software Rasterizer
      32. createDeviceFlags, //D3D10_CREATE_DEVICE_DEBUG (Enable debug layer, error messages to output) or 0
      33. D3D10_SDK_VERSION, //Never changes
      34. &sd, //DXGI_SWAP_CHAIN_DESC (1)
      35. &mSwapChain,
      36. &md3dDevice);
      37. resize();
      38. }
      Display All


      And then resizing the buffers, creating the views etc in resize().

      Do professional games use DXUT or does it vary from game to game?

      2. In the book it says that every Windows application starts in _tWinMain but uses wWinMain in the example. I would normally just define WinMain. Should we always define wWinMain over _tWinMain and WinMain? What's the difference?

      3. Does an underscore before a function name denote anything special? Is there any time we would choose to use string objects over char arrays?

      4. Is the same technique still used to calculate CPU speed? I don't know anything about assembly language or really what is happening in the code there. I skipped over it, and will probably have to skip this test, but I was just wondering if this process has gotten any easier since the book came out.

      Argh! I think that best describes the mood of this post since I get frustrated easy. :)
      [/SIZE]
    • Hey boogey,

      Unfortunately I don't have an answer for 1 and 4, but here goes on 2 and 3:

      2. Those names are just special names available inside of Visual Studio (I think through Windows.h and some automatic project settings) for trying to be Unicode/ASCII independent. _tWinMain uses the same logic as TCHAR which is basically:

      Source Code

      1. #ifdef UNICODE
      2. typedef wchar_t TCHAR;
      3. #else
      4. typedef char TCHAR;
      5. #endif


      So just by changing your project settings, you can switch between Unicode and ASCII compilations. How well that actually works in practice is probably up for debate, as you'd need to use TCHAR, _tSomething, etc. everywhere, and I don't believe there's STL support there (no std::tstring that I'm aware of).

      Long story short, depending on whether your compiling as ASCII or Unicode, the compiler is going to look for WinMain or wWinMain, so as long as you have the correct one you're all set. If you prefer, you can use _tWinMain and TCHAR, etc.

      3. Underscore in front of a function name is just a style/convention thing. To a compiler it's just another name.

      As for std::string vs char*, I'm partial to std::string. STL stuff is usually very optimized, and from a readability standpoint, you can't compare char* to std::string. That being said, if you start doing low level stuff like constructing packets, or you have a particular string operation in mind (like combining multiple strings together) that you can optimize, then char* MIGHT be better. That being said, using std::string.reserve() you can specify the expected string size, and I'd imagine it comes out to being about the same speed. Similarly for packets, you could always use std::stringstream, although from a quick look a StackOverflow answer, pre-allocating space there might not be as easy.

      Long story short, I'd recommend using std::string unless I hear a good, performance critical reason not to (so basically low level stuff). From a high level, the readability is just not worth giving up. Also if you consider that any scripting languages you implement will be doing a lot of string parsing and string manipulation, I would imagine the majority of your string overhead is there, not in your engine.

      James
    • 1) Professional games abstract out the specific libraries they use. For example, The Sims Medieval shipped on PC & Mac. The PC version uses DirectX while the Mac version uses OpenGL. All we had to do was change a compile flag. I have never seen a professional game use DXUT. It's a bit too bloated and not flexible enough for our needs, but it's an EXCELLENT way to get started with DirectX. We chose it for the book because we're not teaching you to be a graphics programmer. We want you to learn the basics of 3D math and rendering, which we can teach through DXUT. If we went with strict D3D, we'd have a LOT more to go through with vertex buffers, index buffers, etc.

      2) What James said. Just use WinMain(). Your compiler settings will figure out the rest.

      3) std::string is slower and takes more memory than a char array. char arrays are faster but more of a pain in the ass (no dynamic resizing, etc). Which one you use really depends on the case, though in all honesty, the overhead of std::string is pretty minimal. For now, I'd just use std::string. It's probably not worth the headache at this point. Just remember, pass by reference or pointer, not by value.

      Or.... if you REALLY want to be a badass, implement your OWN string class using a char*. Try to make it as fully featured as std::string. This is something I would tell anyone else to never ever do, but as a beginner, I think you'll benefit greatly for having to figure out things like how to dynamically resize an array. If you do go this route, post it so we can have a look. :)

      4) This is the accurate way since it's literally timing the CPU, though I don't know if it'll work on a non-Intel processor. AMD will probably be fine since they have very similar instruction sets. Honestly, I don't know of any truly portable way to get the processor speed. I think you can read it from the registry. For the stuff you're doing, it's probably not important to run those tests, especially since the clock frequency isn't as important these days. It's all about multi-core.

      Anyway, here's an article from The Code Project talking about how you can read it from the registry:
      codeproject.com/KB/system/Processor_Speed.aspx

      -Rez
    • [SIZE=2]
      Originally posted by rickvanprim
      2. Those names are just special names available inside of Visual Studio (I think through Windows.h and some automatic project settings) for trying to be Unicode/ASCII independent.

      Long story short, depending on whether your compiling as ASCII or Unicode, the compiler is going to look for WinMain or wWinMain, so as long as you have the correct one you're all set. If you prefer, you can use _tWinMain and TCHAR, etc.

      Ah yeah, I remember reading about the Unicode/ASCII situation in the first couple of chapters of Petzold's book. Ugh, what a nightmare.

      I'd like to design things to be Unicode friendly from the start but I think that is going to be much more of a nightmare than it's worth. Especially at this point, so I'll just stick with WinMain.

      Originally posted by rickvanprim
      3. Underscore in front of a function name is just a style/convention thing. To a compiler it's just another name.

      I know it's just another name, but I'm curious as to the motivation behind it. This is just a complete random guess, but does a function name starting with an underscore imply that it is from some C library?

      In other words, why _tcscpy and not tcscpy? Why __int64 and not just int64?

      This is just something I've wondered about for a while.

      Originally posted by rezination
      1) Professional games abstract out the specific libraries they use. For example, The Sims Medieval shipped on PC & Mac. The PC version uses DirectX while the Mac version uses OpenGL. All we had to do was change a compile flag. I have never seen a professional game use DXUT. It's a bit too bloated and not flexible enough for our needs, but it's an EXCELLENT way to get started with DirectX. We chose it for the book because we're not teaching you to be a graphics programmer. We want you to learn the basics of 3D math and rendering, which we can teach through DXUT. If we went with strict D3D, we'd have a LOT more to go through with vertex buffers, index buffers, etc.

      Gotcha. I figured that might be the case but I just wanted to make sure. I just finished Frank Luna's DirectX 10 book so maybe I am ahead of the game. I'll learn to use DXUT, though, so I can follow along with the examples and see how it works.

      Originally posted by rezination
      3) std::string is slower and takes more memory than a char array. char arrays are faster but more of a pain in the ass (no dynamic resizing, etc). Which one you use really depends on the case, though in all honesty, the overhead of std::string is pretty minimal. For now, I'd just use std::string. It's probably not worth the headache at this point. Just remember, pass by reference or pointer, not by value.

      Gotcha. That's also the impression I got from rick's post. I guess it depends on what I need to do with it and how much I will need to change or manipulate it. I could always just design any functions with a const char * parameter. That way, I can use .c_str(), char arrays, or string literals as an argument. I don't want to get ahead of myself any more than I have to at this point so I'll wait for a situation to arise and then see what works best and get some advice.

      Originally posted by rezination
      Or.... if you REALLY want to be a badass, implement your OWN string class using a char*. Try to make it as fully featured as std::string. This is something I would tell anyone else to never ever do, but as a beginner, I think you'll benefit greatly for having to figure out things like how to dynamically resize an array. If you do go this route, post it so we can have a look. :)

      Uh oh, this is setting off alarms of "boring programming project"! Just kidding, I'm sure projects like this help you become a better programmer. If you think it would help me, I'll give it a shot. Would it be cheating to use a vector of char as the underlying storage? Or do you mean just use a simple char array and dynamically allocate memory as needed?

      Maybe I'll give it a try sometime. But first I want to finish creating my simple Init() based on what I've seen in Chapter 5. I'll post that for some feedback when I finish.

      Originally posted by rezination
      4) This is the accurate way since it's literally timing the CPU, though I don't know if it'll work on a non-Intel processor. AMD will probably be fine since they have very similar instruction sets. Honestly, I don't know of any truly portable way to get the processor speed. I think you can read it from the registry. For the stuff you're doing, it's probably not important to run those tests, especially since the clock frequency isn't as important these days. It's all about multi-core.


      Yeah, I'm just going to skip the CPU test for now. It's just more effort than it's worth right now. If I ever get to a point of making a fairly decent indie game, I can always come back and add it in. Hopefully by then it will be as easy as a simple function call?

      [/SIZE]

      The post was edited 1 time, last by boogey ().


    • I'd like to design things to be Unicode friendly from the start but I think that is going to be much more of a nightmare than it's worth. Especially at this point, so I'll just stick with WinMain.

      Yeah, probably not. ;)


      I know it's just another name, but I'm curious as to the motivation behind it. This is just a complete random guess, but does a function name starting with an underscore imply that it is from some C library?

      In other words, why _tcscpy and not tcscpy? Why __int64 and not just int64?

      This is just something I've wondered about for a while.

      Ahhh, that's Microsoft's way of expanding the standard C library. __int64 is not a standard C++ type, it's a special type that exists in Visual C++. Same thing with _tcscpy() or _itoa(). They're VS specific implementations.


      Uh oh, this is setting off alarms of "boring programming project"! Just kidding, I'm sure projects like this help you become a better programmer. If you think it would help me, I'll give it a shot. Would it be cheating to use a vector of char as the underlying storage? Or do you mean just use a simple char array and dynamically allocate memory as needed?

      Maybe I'll give it a try sometime. But first I want to finish creating my simple Init() based on what I've seen in Chapter 5. I'll post that for some feedback when I finish.

      Trust me, if you want to be a "real" programmer, you will need to do a LOT of programming that's not necessarily interesting. The stuff I'm doing at work right now is pretty boring, but extremely necessary foundation work.

      Either way, it's really important to learn how to write these kinds of data structures. You need to learn how a double linked list works, or how a map works (which is a red/black binary tree), how to write a binary search, how to implement a quicksort or insertion sort, etc. Without an understanding of these data structures and the algorithms that operate on them, you'll never get passed the beginning stages.


      Yeah, I'm just going to skip the CPU test for now. It's just more effort than it's worth right now. If I ever get to a point of making a fairly decent indie game, I can always come back and add it in. Hopefully by then it will be as easy as a simple function call?

      Don't bet on it. ;) But yeah, it's not really important at this point.

      -Rez
    • [size=2]I'm trying to use DXUT for the first time, but I must be doing something wrong. Here are the steps I followed:

      1. Copied C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Samples\C++\DXUT to my Source directory
      2. Opened my solution in VS and added a New Project (DXUT)
      3. Added all of the header and source files from DXUT\Core and DXUT\Optional to the DXUT project

      When I try to build the project DXUT:

      Source Code

      1. 1>ClCompile:
      2. 1> DXUT.cpp
      3. 1>c:\gcc\source\dxut\core\DXUT.h(14): fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory
      4. 1> DXUTenum.cpp
      5. 1>c:\gcc\source\dxut\core\DXUT.h(14): fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory
      6. 1> DXUTmisc.cpp
      7. 1>c:\gcc\source\dxut\core\dxut.h(14): fatal error C1083: Cannot open include file: 'dxsdkver.h': No such file or directory
      8. 1> DXUTcamera.cpp
      9. 1>..\..\..\..\..\..\..\GCC\Source\DXUT\Optional\DXUTcamera.cpp(6): fatal error C1083: Cannot open include file: 'DXUT.h': No such file or directory
      10. 1> DXUTgui.cpp
      11. 1>..\..\..\..\..\..\..\GCC\Source\DXUT\Optional\DXUTgui.cpp(6): fatal error C1083: Cannot open include file: 'DXUT.h': No such file or directory
      12. 1> DXUTres.cpp
      13. 1>..\..\..\..\..\..\..\GCC\Source\DXUT\Optional\DXUTres.cpp(6): fatal error C1083: Cannot open include file: 'DXUT.h': No such file or directory
      14. 1> DXUTsettingsdlg.cpp
      15. 1>..\..\..\..\..\..\..\GCC\Source\DXUT\Optional\DXUTsettingsdlg.cpp(8): fatal error C1083: Cannot open include file: 'DXUT.h': No such file or directory
      16. 1> SDKmesh.cpp
      17. 1>..\..\..\..\..\..\..\GCC\Source\DXUT\Optional\SDKmesh.cpp(11): fatal error C1083: Cannot open include file: 'DXUT.h': No such file or directory
      18. 1> SDKmisc.cpp
      19. 1>..\..\..\..\..\..\..\GCC\Source\DXUT\Optional\SDKmisc.cpp(8): fatal error C1083: Cannot open include file: 'dxut.h': No such file or directory
      20. 1>
      21. 1>Build FAILED.
      Display All


      Yikes. I don't even see dxsdkver.h. Am I doing this completely wrong or just missing a step?

      Edit: If it makes a difference, I am using the Direct3D 10 SDK Tutorial.

      And a side note that there doesn't seem to be a D3D10 equivalent to :

      Source Code

      1. DXUTSetCallbackD3D9DeviceReset( OnResetDevice ); DXUTSetCallbackD3D9DeviceLost( OnLostDevice );

      so I've excluded them.
      [/size]

      The post was edited 2 times, last by boogey ().

    • I've never used DXUT in any real capacity so I'm not sure how much help I can be here. dxsdkver.h lives in the DirectX include directory. If you don't have it, or you're not including the DirectX SDK include directory in your include path, Visual Studio won't find that header. Did you install the DirectX SDK? If not, I would do that. If nothing else, it should set up your Visual Studio include paths correctly.

      It also looks like it can't find DXUT.h, which is also an include path issue. Have you set up your Visual Studio paths to include this directory?

      -Rez
    • Originally posted by rezination
      dxsdkver.h lives in the DirectX include directory. If you don't have it, or you're not including the DirectX SDK include directory in your include path, Visual Studio won't find that header. Did you install the DirectX SDK? If not, I would do that. If nothing else, it should set up your Visual Studio include paths correctly.

      Whoops, forgot to setup the include directories for the project. That took care of that problem, but now I'm getting some linker problems:

      Source Code

      1. 1>ClCompile:
      2. 1> All outputs are up-to-date.
      3. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__DispatchMessageW@4
      4. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__ExtractIconW@12
      5. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__DefWindowProcW@16
      6. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetStockObject@4
      7. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__DestroyMenu@4
      8. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__AdjustWindowRect@12
      9. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SendMessageW@16
      10. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__IsWindowVisible@4
      11. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetSystemMetrics@4
      12. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__RegisterClassW@4
      13. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__MessageBoxW@16
      14. 1>dxerr.lib(dxerrw.obj) : error LNK2001: unresolved external symbol __imp__MessageBoxW@16
      15. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__UnhookWindowsHookEx@4
      16. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SetWindowsHookExW@16
      17. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__CreateWindowExW@48
      18. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__ClipCursor@4
      19. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SetMenu@8
      20. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetObjectW@12
      21. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__ShowWindow@8
      22. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetCursorPos@4
      23. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SetWindowPos@28
      24. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SetWindowLongW@12
      25. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__ReleaseDC@8
      26. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__PeekMessageW@20
      27. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SystemParametersInfoW@16
      28. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetWindowTextW@12
      29. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetWindowLongW@8
      30. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SetRect@20
      31. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetAsyncKeyState@4
      32. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetWindowPlacement@8
      33. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__CreateCompatibleDC@4
      34. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetMenu@4
      35. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__TranslateMessage@4
      36. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetDC@4
      37. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetIconInfo@8
      38. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SelectObject@8
      39. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__DeleteObject@4
      40. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetClassLongW@8
      41. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetClientRect@8
      42. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetDIBits@28
      43. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__CallNextHookEx@16
      44. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__LoadCursorW@8
      45. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__DeleteDC@4
      46. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__IsZoomed@4
      47. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__UnregisterClassW@8
      48. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__IsIconic@4
      49. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__PostQuitMessage@4
      50. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__GetWindowRect@8
      51. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__ScreenToClient@8
      52. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__DestroyAcceleratorTable@4
      53. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__TranslateAcceleratorW@12
      54. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SetCursor@4
      55. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__SetWindowPlacement@8
      56. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__DestroyWindow@4
      57. 1>DXUT.obj : error LNK2001: unresolved external symbol __imp__CommandLineToArgvW@8
      58. 1>DXUTenum.obj : error LNK2001: unresolved external symbol __imp__EnumDisplaySettingsW@12
      59. 1>DXUTenum.obj : error LNK2001: unresolved external symbol __imp__GetMonitorInfoW@8
      60. 1>DXUTmisc.obj : error LNK2001: unresolved external symbol __imp__SystemParametersInfoA@16
      61. 1>DXUTmisc.obj : error LNK2001: unresolved external symbol __imp__ShellExecuteW@24
      62. 1>DXUTcamera.obj : error LNK2001: unresolved external symbol __imp__ReleaseCapture@0
      63. 1>DXUTcamera.obj : error LNK2001: unresolved external symbol __imp__SetCursorPos@8
      64. 1>DXUTcamera.obj : error LNK2001: unresolved external symbol __imp__GetForegroundWindow@0
      65. 1>dxerr.lib(dxerrw.obj) : error LNK2001: unresolved external symbol __imp__GetForegroundWindow@0
      66. 1>DXUTcamera.obj : error LNK2001: unresolved external symbol __imp__PtInRect@12
      67. 1>DXUTcamera.obj : error LNK2001: unresolved external symbol __imp__SetCapture@4
      68. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__GetCaretBlinkTime@0
      69. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__SetClipboardData@8
      70. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__OpenClipboard@4
      71. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__EmptyClipboard@0
      72. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__GetClipboardData@4
      73. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__IntersectRect@12
      74. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__OffsetRect@12
      75. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__InflateRect@12
      76. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__SetRectEmpty@4
      77. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__GetKeyState@4
      78. 1>DXUTgui.obj : error LNK2001: unresolved external symbol __imp__CloseClipboard@0
      79. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__SetWindowTextW@8
      80. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__EnableWindow@8
      81. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__SetDlgItemTextW@12
      82. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__IsDlgButtonChecked@8
      83. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__CheckDlgButton@12
      84. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__EndDialog@8
      85. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__GetDlgItem@8
      86. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__LoadIconW@8
      87. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__SHGetFolderPathW@20
      88. 1>SDKmisc.obj : error LNK2001: unresolved external symbol __imp__DialogBoxIndirectParamW@20
      89. 1>MSVCRT.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@16
      Display All


      Hmm, I've tried to copy my settings from the SDK Tutorial project. In addition to inherited values:

      Executable Directories:
      $(DXSDK_DIR)Utilities\bin\x86

      Include Directories:
      C:\GCC\Source\DXUT\Optional
      C:\GCC\Source\DXUT\Core
      $(DXSDK_DIR)Include

      Library Directories:
      $(DXSDK_DIR)Lib\x86

      Linker->Input->Additional Dependencies:
      d3dx10.lib
      d3dx9.lib
      dxerr.lib
      dxguid.lib
      winmm.lib
      comctl32.lib

      It looks like those are the tutorial settings and it builds fine. I have the SDK installed and $(DXSDK_DIR) is set to C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\ which seems right.

      I must have some project settings wrong somewhere. I wish they would put how to configure the project in the tutorial. It seems odd to have to manually copy in the DXUT directory and then set up a project to build it myself. Hope I'm doing this right.

      The post was edited 1 time, last by boogey ().

    • Just a shot in the dark, try playing with whether or not the project is building as Unicode or ASCII, and whether or not wchar_t is treated as a built-in type. Also make sure that Windows.h is included before any DX stuff (no idea if that will change anything, but I've seen compiler and possibly linker errors from the order it's included in with other libraries).

      James
    • Those all look like core Windows functions. Are you including windows.h? I think James is right, in that it's probably a compile order thing. windows.h should be the very first thing you include in the file that defines WinMain(). That should cause the program to link to the appropriate libs.

      -Rez
    • [size=2]The project settings are set to use Unicode. I tried changing it but got:

      Source Code

      1. fatal error C1189: #error : "DXUT requires a Unicode build."


      So I put it back to Unicode. I'm not sure how to tell if wchar_t is treated as a built in type. Is this somewhere in VS 2010 Pro settings?

      As far as Windows.h. Originally, I did not have any of my own code. I just added all of the headers/source from the DXUT directory.

      But now, just to give it a try, I've created a new source file, testing.cpp:

      Source Code

      1. #include <Windows.h>
      2. int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
      3. PSTR szCmdLine, int iCmdShow)
      4. {
      5. return 0;
      6. }


      When I go to build project it looks like everything compiles but more linker problems:

      Source Code

      1. 1>Build started 7/25/2011 10:54:55 PM.
      2. 1>InitializeBuildStatus:
      3. 1> Touching "Debug\test.unsuccessfulbuild".
      4. 1>ClCompile:
      5. 1> testing.cpp
      6. 1> SDKwavefile.cpp
      7. 1> SDKsound.cpp
      8. 1> SDKmisc.cpp
      9. 1> SDKmesh.cpp
      10. 1> ImeUi.cpp
      11. 1> DXUTShapes.cpp
      12. 1> DXUTsettingsdlg.cpp
      13. 1> DXUTres.cpp
      14. 1> DXUTguiIME.cpp
      15. 1> DXUTgui.cpp
      16. 1> DXUTcamera.cpp
      17. 1> DXUTmisc.cpp
      18. 1> DXUTenum.cpp
      19. 1> DXUT.cpp
      20. 1> Generating Code...
      21. 1>ManifestResourceCompile:
      22. 1> All outputs are up-to-date.
      23. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmSetConversionStatus@12 referenced in function "long __cdecl ImeUi_ProcessMessage(struct HWND__ *,unsigned int,unsigned int,long &,bool *)" (?ImeUi_ProcessMessage@@YAJPAUHWND__@@IIAAJPA_N@Z)
      24. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetConversionStatus@12 referenced in function "long __cdecl ImeUi_ProcessMessage(struct HWND__ *,unsigned int,unsigned int,long &,bool *)" (?ImeUi_ProcessMessage@@YAJPAUHWND__@@IIAAJPA_N@Z)
      25. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmReleaseContext@8 referenced in function "long __cdecl ImeUi_ProcessMessage(struct HWND__ *,unsigned int,unsigned int,long &,bool *)" (?ImeUi_ProcessMessage@@YAJPAUHWND__@@IIAAJPA_N@Z)
      26. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetContext@4 referenced in function "long __cdecl ImeUi_ProcessMessage(struct HWND__ *,unsigned int,unsigned int,long &,bool *)" (?ImeUi_ProcessMessage@@YAJPAUHWND__@@IIAAJPA_N@Z)
      27. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmSetOpenStatus@8 referenced in function "void __cdecl ImeUi_SetState(unsigned long)" (?ImeUi_SetState@@YAXK@Z)
      28. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmSimulateHotKey@8 referenced in function "void __cdecl ImeUi_SetState(unsigned long)" (?ImeUi_SetState@@YAXK@Z)
      29. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmAssociateContext@8 referenced in function "void __cdecl ImeUi_EnableIme(bool)" (?ImeUi_EnableIme@@YAX_N@Z)
      30. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetCandidateListA@16 referenced in function "bool __cdecl ImeUi_Initialize(struct HWND__ *,bool)" (?ImeUi_Initialize@@YA_NPAUHWND__@@_N@Z)
      31. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetCandidateListW@16 referenced in function "bool __cdecl ImeUi_Initialize(struct HWND__ *,bool)" (?ImeUi_Initialize@@YA_NPAUHWND__@@_N@Z)
      32. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetCompositionStringW@16 referenced in function "bool __cdecl ImeUi_Initialize(struct HWND__ *,bool)" (?ImeUi_Initialize@@YA_NPAUHWND__@@_N@Z)
      33. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetCompositionStringA@16 referenced in function "long __stdcall AW_ImmGetCompositionString(struct HIMC__ *,unsigned long,void *,unsigned long)" (?AW_ImmGetCompositionString@@YGJPAUHIMC__@@KPAXK@Z)
      34. 1>ImeUi.obj : error LNK2019: unresolved external symbol _VerQueryValueA@16 referenced in function "unsigned long __cdecl GetImeId(unsigned int)" (?GetImeId@@YAKI@Z)
      35. 1>ImeUi.obj : error LNK2019: unresolved external symbol _GetFileVersionInfoA@16 referenced in function "unsigned long __cdecl GetImeId(unsigned int)" (?GetImeId@@YAKI@Z)
      36. 1>ImeUi.obj : error LNK2019: unresolved external symbol _GetFileVersionInfoSizeA@8 referenced in function "unsigned long __cdecl GetImeId(unsigned int)" (?GetImeId@@YAKI@Z)
      37. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetIMEFileNameA@12 referenced in function "unsigned long __cdecl GetImeId(unsigned int)" (?GetImeId@@YAKI@Z)
      38. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetVirtualKey@4 referenced in function "bool __cdecl ImeUi_IgnoreHotKey(struct tagMSG const *)" (?ImeUi_IgnoreHotKey@@YA_NPBUtagMSG@@@Z)
      39. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmSetCompositionStringW@24 referenced in function "void __cdecl ImeUi_FinalizeString(bool)" (?ImeUi_FinalizeString@@YAX_N@Z)
      40. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmNotifyIME@16 referenced in function "void __cdecl ImeUi_FinalizeString(bool)" (?ImeUi_FinalizeString@@YAX_N@Z)
      41. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetOpenStatus@4 referenced in function "void __cdecl CheckToggleState(void)" (?CheckToggleState@@YAXXZ)
      42. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmIsIME@4 referenced in function "void __cdecl CheckToggleState(void)" (?CheckToggleState@@YAXXZ)
      43. 1>ImeUi.obj : error LNK2019: unresolved external symbol _ImmGetDefaultIMEWnd@4 referenced in function "void __cdecl ImeUi_ToggleLanguageBar(int)" (?ImeUi_ToggleLanguageBar@@YAXH@Z)
      44. 1>SDKsound.obj : error LNK2019: unresolved external symbol _DirectSoundCreate8@12 referenced in function "public: long __thiscall CSoundManager::Initialize(struct HWND__ *,unsigned long)" (?Initialize@CSoundManager@@QAEJPAUHWND__@@K@Z)
      Display All


      Other than testing.cpp that I posted above, I'm not sure how to include Windows.h and make sure its gets included first.

      If anyone here on the forums has used DXUT recently, and can tell me exactly how you configured the project, it would be helpful. There must be an easier way - this is madness!
      [/size]

      The post was edited 1 time, last by boogey ().

    • The latest linker errors look like you forgot Coreimm.lib.

      Here's a hint: If you copy & paste the function name, minus the W at the end, you'll find the msdn page for the function. At the bottom it tells you what lib you need for that function.

      -Rez
    • [size=2]
      For those who are interested, it looks like I finally got it to build.

      I had to add 2 more lib files to Linker->Input->Additional Dependencies:
      Imm32.lib
      Version.lib

      These are NOT included in the tutorial project settings. I have no idea why the tutorial project builds fine without them but my project won't.

      Anyway, I'm just keeping my fingers crossed for now and hoping everything continues to work. Otherwise, my head may explode.

      Thanks Rez, that's what I ended up doing. I guess you can't just assume that all the lib files will be complete in the sample projects.

      It looks like I wasn't the only one who had this problem:
      forums.create.msdn.com/forums/p/34612/198886.aspx
      [/size]

      The post was edited 2 times, last by boogey ().

    • [size=2]
      This is an odd observation, I just thought I'd share. I've kinda been messing around with this all day.

      Basically, I built this project, just drawing a simple 3D cube to try out DXUT. I noticed that when I tried to run the program (both debug and release builds) it took about literally 10 seconds to load. I would double click, sit there for about 10 seconds, and then finally the window would come up.

      I thought I screwed something up in the project settings so I created a new project (with a different name) using the same source files. I changed all of the same settings as before. The problem disappeared, so I thought I had definitely screwed something up in the project settings before.

      I decided to delete the original project and remake it with the same name. I changed all of the same settings, being extra careful this time. Low and behold, the same problem appears again!

      Now I was really confused, because I just made a project with those settings and it worked fine. Here are some of the main project settings in case anybody wants to try it (C:\Game is the root directory for everything):

      Solution Name: Game
      Project Names (2 Total): Game and DXUT (just added existing DXUT project using the provided DXUT_2010.vcxproj)
      Output Directory: C:\Game\Test\ for Debug and C:\Game\Bin\ for Release
      Intermediate Directory: C:\Game\Obj\$(Configuration)\
      Include Directories: C:\Game\DXUT\Core and $(DXSDK_DIR)Include
      Library Directories: C:\Game\Lib\Release and $(DXSDK_DIR)Lib\x86

      Linker->Debugging->Generate Program Database File: $(IntDir)$(TargetName).pdb

      Linker->Input->Additional Dependencies:
      d3dx10.lib
      d3dx9.lib
      dxerr.lib
      dxguid.lib
      winmm.lib
      comctl32.lib
      Imm32.lib
      Version.lib
      Dsound.lib
      DXUT.lib

      For the DXUT project I just changed the Output and Intermediate directories:
      Output Directory: C:\Game\Lib\$(Configuration)\
      Intermediate Directory: C:\Game\Lib\Obj\$(Configuration)\

      It seemed like the naming is somehow connected to my problem, so I went into the Bin directory and renamed Game.exe to yy.exe. Low and behold, the problem is gone! The name of the exe is somehow causing the problem!

      I also tried changing the name of the project from Game to something else and it also worked (maybe because it generates an .exe with a different name).

      Anyway, I just thought this was kind of odd. I didn't think the name of the .exe could cause a problem like this!
      [/size]
    • Huh, that's definitely a strange one. I've certainly used Game.exe a number of times before so there's some other funky combination of stuff happening. It might be worth setting up a profiler and seeing where it's hanging.

      -Rez
    • I'll have to read up on this and give it a try. Only problem is MSDN's article on "Beginner's Guide to Performance Profiling" excludes VS 2010 Professional. Only Premium and Ultimate. Maybe there is another way. :(

      EDIT: I see something called NVIDIA PerfKit. Has anyone ever used this? Is it worth the effort?

      I don't think I'll be upgrading to VS Premium or Ultimate any time soon, hehe.

      The post was edited 1 time, last by boogey ().

    • nVidia PerfHud is specifically for GPU and graphics profiling (unless they changed it in the last few years). It's EXCELLENT for this, but I don't think that's the issue.

      I would check out one of the free profilers. Luke Stackwalker is one that I've used which isn't bad, albeit fairly primitive compared to one of the pay ones. It might not be worth opening that whole box of horrors (profiling can be a complicated subject) so take that with a grain of salt. I'm the type of person who would dig around until I found the answer because I'm crazy like that. ;)

      -Rez
    • I don't mind digging into new things here and there as long as I don't get completely overwhelmed. :)

      ren.exe:
      [IMG:http://img232.imageshack.us/img232/5007/renh.jpg]


      Game.exe:
      [IMG:http://img823.imageshack.us/img823/6938/gamev.jpg]


      I looked up System Error Codes on MSDN:
      ERROR_INVALID_ADDRESS
      487 (0x1E7)
      Attempt to access invalid address.

      ERROR_MOD_NOT_FOUND
      126 (0x7E)
      The specified module could not be found.

      Pretty strange, huh? Eventually it runs as Game.exe though...

      EDIT: Oh, and I added C:\Game\Obj\Release to the Debug Info Directories in the project settings. This is where the .pdb files are.

      The post was edited 1 time, last by boogey ().

    • Huh, yeah, it looks like it's failing to find the address for those functions. I'm not really sure what the issue could be, especially considering that all you're changing is the filename. Sorry man, I don't know what to tell you. :-/ Looks like you'll have to not use Game.exe. ;)

      -Rez