Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

3649 Excellent

About Adam_42

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'd suggest enabling page heap mode, which tends to make heap corruption bugs crash quicker, and therefore makes them easier to debug. You can enable it with the gflags tool, which is part of Debugging Tools for Windows: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/ https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap
  2. If you don't want to re-create the swapchain to change the multisampling settings, you can always work around that by doing some or more of your rendering to an off-screen buffer using multisampling (if it's enabled), and then copying the result to the swap chain after you've done everything that requires multisampling. For example, you could do the copy as part of a post-processing effect as you need to copy between render targets at that point anyway.
  3. Lost devices are a pain to handle, mostly because you need to release everything that isn't in the default pool or Reset() will fail. You can enable the debug runtime from the DirectX control panel (which only works on Windows 7 or earlier) to get a better error message. Your other option is to use D3D9Ex, which avoids almost all lost device issues. See https://docs.microsoft.com/en-gb/windows/win32/direct3d9/dx9lh
  4. If you're hashing large quantities of data, and need good performance xxHash is a good option. For small quantities of data, something simple like FNV should be good enough. Note that thanks to the birthday paradox, once you've generated about 77,000 hashes (with a well behaved hash function), the chances of a new hash being equal to one of the existing hashes is 50%! This means you want 64-bit hashes if you think you might exceed a few thousand items, and you can't handle collisions easily. There's some more discussion on various hash algorithms at https://aras-p.info/blog/2016/08/02/Hash-Functions-all-the-way-down/
  5. You can check against a wide range of virus scanners by uploading the suspect file to VirusTotal.com. In general a false positive is more likely to be identified as different things by different scanners, and also be marked as clean by most of them. Assuming it is a false positive you have a few options: 1. Consider changing to a different anti virus program, especially if you're not distributing your software to other people yet. I've never had any troubles with the free one that's built into newer versions of Windows. 2. Submit a false positive report to all of the places that detect it as a virus. 3. Try to make changes to stop it from being detected. For example, switching to a different installer may help.
  6. Under some circumstances Windows will "helpfully" catch exceptions that are thrown in message handlers. https://stackoverflow.com/questions/2622200/exceptions-silently-caught-by-windows-how-to-handle-manually https://stackoverflow.com/questions/23603391/why-does-windows-swallow-exceptions-during-wm-close https://web.archive.org/web/20170214101142/http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/ https://randomascii.wordpress.com/2012/07/05/when-even-crashing-doesnt-work/
  7. For those types of games it's generally done the other way around - the graphics are positioned based on timing information from the audio. That allows you to just render as fast as possible, and still keep the graphics in sync with the audio.
  8. Adam_42

    C++ threading question.

    If you don't want to use a pre-built lock free queue, I'd suggest starting with a combination of a mutex and a semaphore. Unless the functions are very quick to execute then there shouldn't be much contention on the mutex anyway. The the semaphore is needed to keep track of how many items are in the queue so you don't need to poll - the worker threads simply wait on the semaphore, and then remove an entry from the queue, and the main thread signals the semaphore whenever it adds an item to the queue. Even if you had a lock free queue instead of one using a mutex, you'd probably still want the semaphore to avoid the need for polling to see if there's anything in the queue.
  9. For a first programming language, I wouldn't suggest either C or C++. The problem with them for learning is that bugs in code are less likely to end up as runtime errors than for higher level languages like C# and Java. The most obvious example is out of bounds array accesses - when you first start programming it can take a while to get used to the fact that array indexing is zero based.
  10. Here's one way to do it, at least for return types, with the help of std::result_of. template <typename T, typename = std::enable_if_t<!std::is_same<typename std::result_of<T()>::type, void>::value>> auto call(T lambda) -> decltype(lambda()) { auto result = lambda(); static_assert(!std::is_same<decltype(lambda()), void>::value, "This overload can return a value of any type"); return lambda(); } template <typename T, typename = std::enable_if_t<std::is_same<typename std::result_of<T()>::type, void>::value>> void call(T lambda) { static_assert(std::is_same<decltype(lambda()), void>::value, "This overload returns void"); lambda(); } int main(int argc, char** argv) { call([] {}); call([] {return 1;}); } Try it online: https://godbolt.org/z/kGwoi7
  11. For investigating performance issues, you need some kind of profiling data. You could build some simple profiling into the game, or you could ask people to run an external tool. I'd also suggest asking users with issues to run dxdiag and send you the log file - that will tell you their system specs in some detail, including driver versions. If it's only a small number of users with problems then it could be that they have hardware problems of some kind. For example: https://randomascii.wordpress.com/2013/08/06/defective-heat-sinks-causing-garbage-gaming/ For crashes, what you want are crash dumps from users computers. One option to obtain those dumps is to ask them to enable http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx temporarily and send you the dump files. You should then be able to load them in a debugger and work out what's gone wrong. For them to be useful you need to have enabled pdb file generation when you compiled the game (but you don't need to distribute the PDB file). Also see https://randomascii.wordpress.com/2012/07/22/more-adventures-in-failing-to-crash-properly/ if your game is exiting unexpectedly without generating a crash dump.
  12. Adam_42

    Avoid branch instructions

    If you want to work out which has fewest branches, then just compile it and look at the disassembly: https://godbolt.org/z/4W1y2Y Of course the results will vary somewhat between compilers, and will depend on the implementations of the other functions that you don't show the source for.
  13. Beware that as well as choosing a sort order for opaque objects to optimize performance, you'll also need to separate out transparent objects and render them separately. There's also post-processing, and the user interface to consider. A generic rendering order might look something like this: 1. Depth only pass to minimize overdraw (ideally you only want to render stuff in this pass that's a good occluder (i.e. it's got a relatively low poly count for it's size, and is likely to be in front of other things). 2. Opaque render pass, sorted to optimize performance. 3. Some full screen post-processing might need to happen here if it shouldn't (or can't) be applied to transparent objects. For example, SSAO. 4. Render all transparent geometry, furthest away things first (you'll need to sort by distance to the camera). The sorting is for correctness, and not performance. 5. Render any other post-processing effects (bloom, etc.) 6. Render the user interface (assuming it's 2D, and not part of the 3D scene). Obviously most of those passes are optional. Some games will also have more rendering passes than that, especially if they use some form of deferred shading. One common way to handle the sorting within each render pass, is to create an integer sort key for each thing you render. See http://realtimecollisiondetection.net/blog/?p=86 for an example.
  14. Are you processing the whole of the windows message queue on each game loop?
  15. Firstly, 0x80004003 is E_POINTER which might just mean there's a null pointer been passed to a COM function somewhere, and something has translated it to an exception. Finding out what's gone wrong could be tricky though. The way most video recording tools work is that they hook the D3D API so a call to Present() with them loaded will not just call the standard function - it will also do some extra stuff to capture a video frame. It sounds like your program exposes some sort of bug in the video recording program - they should be completely transparent to the game programmer. Also note that inside D3D a lot of the things you ask the API to do are buffered up, and delayed until the Present() call. This means that Present() can report problems which are actually caused by earlier API calls. You're probably doing something which most other games don't do. Off the top of my head I'd suggest: - Enable D3D11_CREATE_DEVICE_DEBUG (or rather the SharpDX equivalent of that) and make sure the debug runtimes aren't reporting any issues with the way you're using the API. Note that if you're using Windows 10 you'll need to install the optional "Graphics Tools" component for this to work. - Try some different options for recording the game output. Windows 10 has built in support to record games - just press Win+G. I'm sure you can also find some other programs that are free, or have a free trial (OBS Studio, and FRAPS spring to mind). You may well find that some work and some don't. If that's the case then submitting a bug report for the software that doesn't work might be be easier than trying to work round their bugs. - Simplify things as much as possible. Try taking the most basic SharpDX example program that you can find, and record the output of that. Gradually add stuff from your code to the example until you find out what breaks it. I'd start with the device creation and setup code. - The last resort is to do some native code debugging to try to work out what's gone wrong. At the very least the debugger should be able to catch that exception when it's thrown and show you a call stack.
  • 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!