I use dx9 for a few small things here as I've gotten used to it and it does it's job pretty well, but lately I've been facing quite an issue that no matter how much I try look into, I can never find a solution for.
As the title states, I sometimes freeze the whole program and I'm forced to close it on calling CreateTexture, CreateSprite and sometimes from the device's Present which I can only guess stems from the last 2 ones. Thing is, there seems to be some kind of spots that whenever I try call any of the above functions for it freezes without fail, but without creating a texture at all and simply using a plain rectangle I'm 100% fine. I've tried going through all the memory pools of CreateTexture as it could perhaps been any of that but it still happens. For reference I call these functions like so
m_pDirect3DDevice->CreateTexture(m_nImageX, m_nImageY, 1, 0, D3DFMT_A8R8G8B8, D3DPOOL_MANAGED, &m_pNewTexture.m_pTexture, NULL);
D3DXCreateSprite(m_pDirect3DDevice, &m_pNewTexture.m_pSprite);
m_pDirect3DDevice->Present(NULL, NULL, NULL, NULL);
Any help or suggestions at all are greatly appreciated!
Related
I'm just trying to make an empty game loop that doesn't lag!
My loop does basically nothing, yet sometimes it lags enough to drop frames (I'm trying to run at 60fps)
I traced the problem to SDL_GL_SwapWindow. I made sure vsync is turned off.
Most of the time SDL_GL_SwapWindow(window); takes <1ms. But sometimes it can take long enough to drop frames. Is this normal? I can't believe my raw C++ empty game loop is sometimes dropping frames!
My code doesn't do anything interesting, I've tried tweaking it quite a bit, but I've seen no improvement. You can see it all here http://pastebin.com/GpLAH8SZ
P.S. I'm on a decent gaming desktop!
I think it is the OS, which may not schedule you 100% of time.
You can change the msdn : process class. But there is going to be intervals where windows does not have resources to keep running your code, and keep running.
We have a program which is proving difficult to debug. The MFC application runs fine for a few hours but over a day it will crash. Sometimes it will not throw any errors and simply exit the "dlg.DoModal()" section of our code without the user (or any obvious part of the code) closing the dialog. Other times it will crash and throw an error outside of our code and have a horrendous call stack that has nothing to do with our code, it has a lot of calls to system DLLs however.
A bit of background to our problem.
We are trying to develop a MFC bases C++ application (with a dialog). We have multiple threads and the code is rather large which makes debugging a nightmare. We have been experiencing intermittent crashes that we have been unable to locate the source of so far.
We are well past the use of breakpoints for debugging as we are pretty sure it is an issue somewhere in MFC, maybe not a bug but more a problem with the way we are using MFC.
Now we've tried simple things to help us like:
Enable all debug exceptions:
Debug -> Exceptions and then checking all the boxes so that we can
trap silly mistakes.
This proved helpful but we've now corrected all the errors it throws
within a few hours of running.
Search for memory leaks
We then tried Visual Leak Detector (which works beautifully by the
way) located here: http://vld.codeplex.com/ Our code now reports no
memory leaks so it is not an obvious memory leak issue. We have
included vld.h in the very top of our code near the entry point.
Adding Microsoft Symbol Server to obtain debug symbol files.
We then tried making our call stacks more human readable by using MS
Symbol servers shown in these tutorials:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/3f1825e1-6770-48c0-91b0-12d8946ab259/2-how-do-i-configure-visual-studio-to-use-microsoft-symbol-server?forum=vsdebug and http://support.microsoft.com/kb/311503
This ultimately did nothing as it still doesn't tell you enough about any errors.
Using the Thread window to see all call stacks, and using the
Parallel Stack window
We have been using the Thread and Parallel stack windows to aid our
debugging but ultimately they have proved nothing more than pretty
pictures and fancily formatted call stacks that makes you feel good
more than anything. We have been using the tutorial here which has
been very handy
http://www.codeproject.com/Articles/79508/Mastering-Debugging-in-Visual-Studio-A-Beginn
Now for the more interesting things we've tried that do not throw errors straight away but can be detected as problems:
GDI Objects not being destroyed
This one is not obvious in VS2010 as an issue. Basically if you use a call like "CDC* pDC = lChild->GetDC();" and do not use the call "ReleaseDC(pDC);" then you have just created a GDI Object that will not be destroyed until your program terminates. VS2010 is a bit dumb in this regard and will keep creating these objects until your program crashes, and the call stack will look horrible and you will probably have no idea why it has crashed.
To find this issue, start Windows Task Manager -> Click Processes Tab -> Click the View Toolbar item -> Select Columns. Now check Handles, Threads, User Objects, and GDI Objects. Now start your program, find it's process in the list under Image Name, and watch to see if the GDI Objects column keeps growing or stabilizes.
Objects Not being destroyed
This is another not so obvious error, if you create a bitmap like this: "reinterpret_cast(LoadImage( GetModuleHandle(NULL), MAKEINTRESOURCE(IDB_BITMAPNPR), IMAGE_BITMAP, 0, 0, 0))" and assign it straight to a picture control, the bitmap will not be destroyed if you assign another bitmap to this picture control using similar code. Instead you need to assign the above to a HBITMAP variable which you then need to destroy when you are done.
This situation can also arise if you create a font or colour in a similar fashion.
Now with all that being said, we have tried all the methods above and we still can't find our issue. Sometimes our program will exit normally and we won't be given any debug info (this is usually after is has been running overnight), other times our program will lockup the PC (tested on multiple PCs), other times it will throw an error but we can't locate the culprit because it simply points to the ".DoModal()" part of our code and the rest is native windows DLLs which is useless for debugging purposes.
We suspect something is either being created and not destroyed properly but we aren't sure what and VS2010 is not telling us anything useful to point us in the right direction.
Does anyone have any ideas? How do we trap errors that aren't obvious to VS2010? Or rather how do we easily trap "GDI leaks" and the like?
Thanks in advance
Edit:
We've been using Microsoft's Application Verifier, it's found a few errors so far. To use it download it here http://www.microsoft.com/en-us/download/details.aspx?id=20028 run Application Verifier, add your .exe file in your Debug or Release directories and run the program in VS2010 as normal. VS2010 will break when Application Verifier 'sees' an error. It hasn't found anything too outrageous yet so I assume that we still have issues with our code.
I'm writing a program in C++ using DirectX 11, and I would like to have it so that my program minimizes whenever a user presses Ctrl-Alt-Del or Alt-Tab.
Getting the window itself to minimize is the easy part, as all I have to do is call this function:
ShowWindow(hWnd, SW_MINIMIZE);
The part I'm stuck on is getting it to detect when either of those two particular keystrokes are inputted, so that I may call that function when one of those events occur.
Any assistance would be appreciated, and if you need me to clarify on something please let me know.
Someone far more well-versed in the Kernel of Windows can stomp in with heavy boots here and correct me, but as far as I know, Ctrl-Alt-Delete is so system, it's "mega system". The reason is that if programs could latch in to it, you'd end up with a dead desktop the moment some idiot decided it was a great idea to pop up an "Are you sure?" message box when the user realised his computer had gone to hell.
There are guidelines that we should follow as software developers, and trying to change the behaviour of the operating system (however good our intent), will always end in tears.
I suggest you don't try and do this (if it is indeed possible, I've never tried - to be frank), and start thinking about the more important things you can be doing. If memory serves and the user does hit Ctrl-Alt-Delete when you're running a DirectX application, you'll lose the surface/device context (assuming you're full screen).
Exit gracefully, or if you can recover - do so.
I am starting using FMOD API and I have got problem with sound playing. I've used tutorial from this site: http://glasnost.itcarlow.ie/~powerk/audio/AddFMODtoaproject.html and only think I have got is sound cracking.
This is the code which I am using in my OpenGL init function:
FMOD::System_Create(&system);// create an instance of the game engine
system->init(32, FMOD_INIT_NORMAL, 0);
system->createSound("sound.wav", FMOD_HARDWARE, 0, &sound1);
sound1->setMode(FMOD_LOOP_OFF);
system->playSound(FMOD_CHANNEL_FREE, sound1, false, 0);
Does anyone have any idea what is wrong? Or mayby there is another way for that.
Firstly make sure you check the return code of all functions, ensure it is FMOD_OK.
Second, you need to call System::update regularly, once per frame for FMOD house keeping.
Regarding your issue though, what platform are you on?
Crackling generally means the hardware cannot keep up, to fix it you can increase the amount of buffering FMOD does. This is controlled via System::setDSPBufferSize, try increasing the numBuffers count. You can determine the current values with System::getDSPBufferSize, also make sure you call System::setDSPBufferSize before System::init for the new values to take effect.
I don't know If you are calling FMOD::System::Update() .. you need to call this at least once per frame
The overall program is too complex to display here. Basically, just pay attention to the green highlights in my recent git commit. I am very new to DirectInput, so I expect I've made several errors. I have very carefully studied the MSDN documentation, so I promise I'm not just throwing this out there and stamping FIX IT FOR ME on it. :)
Basically, I think I have narrowed down my problem to the area of code around Engine::getEvent (line 238+). I do not understand how these functions work, and I've messed with certain pieces to achieve different results. My goal here is to simply read in keyboard events directly and output those raw numbers to the screen (I will deal with the numbers' meaning later). The problem here relates to KEYBOARD_BUFFER_SIZE. If I make it small, the program seems to run fine, but it outputs no events. If I make it big, it runs a bit better, but it starts to slow down and then freeze (the OpenGL window just has a rotating color cube). How do I properly capture keyboard events?
I checked the return values on all the setup steps higher in the code. They all return DI_OK just fine.
Your code seems to be okay (according to this tutorial, which I have used in the past). The use of several stack-based arrays is questionable, but shouldn't be too much of an issue (unless you start having lots of concurrent getEvent calls running).
However, your best bet would be to stop using DirectInput and start using Windows Raw Input. It's best to make this switch early (ie, now) rather than realise later on that you really need to use something other than DI to get the results you want.