Advertisement Jump to content
  • Advertisement

Adam_42

Member
  • Content Count

    1908
  • Joined

  • Last visited

Community Reputation

3646 Excellent

About Adam_42

  • Rank
    Contributor

Personal Information

  • Role
    Programmer
  • Interests
    Art
    Audio
    Business
    Design
    Education
    Production
    Programming
    QA

Recent Profile Visitors

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

  1. 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/
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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.
  7. 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.
  8. 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.
  9. Are you processing the whole of the windows message queue on each game loop?
  10. 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.
  11. If you're interested in details of what commercial games do, http://www.adriancourreges.com/blog/ has some interesting breakdowns of how frames are put together in various games.
  12. Hmm. Maybe as that CreateTextFormat() call is done using COM, it's actually talking to another process.
  13. You might prefer to use AddFontResourceEx() with the FR_PRIVATE flag, that way the font is only available for your game, and will be automatically unregistered when the process exits.
  14. Adam_42

    Frame analyzer without swapchain

    I think RenderDoc can do it, but you'll need to call its API to tell it where the capture should start and end. See the discussion on: https://github.com/baldurk/renderdoc/issues/817
  15. As the main component of your game will be audio, I'd suggest looking at audio libraries first. Once you've chosen a library, you can select a programming language based on which ones your chosen audio library supports, and what language you're most comfortable using. I'd expect that most audio libraries will be usable from C, C++, C# and Python on Windows - although some languages may be better supported than others. For example, FMOD comes with C, C++ and C# APIs, but not a Python API, although a quick search found a third party one - http://pysonic.sourceforge.net/. The runtime performance of your chosen programming language probably won't make any significant difference. In addition, if performance does become a problem both Python and C# can call into C/C++ code.
  • 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!