Zaoshi Kaba

Member
  • Content count

    364
  • Joined

  • Last visited

Community Reputation

8442 Excellent

About Zaoshi Kaba

Personal Information

  • Interests
    DevOps
    Programming
  1. I have also spotted an issue in another method: std::vector<SDL_Rect*>* ObstacleManager::getCollisionRectVector() { std::vector<SDL_Rect*> collisionRects; for (int i = 0; i < m_Pillars.size(); i++) { collisionRects.push_back(m_Pillars[i]->getCollisionRect()); } return &collisionRects; } You create collisionRects on the stack, but then return pointer to it - after it gets destroyed. Eventually this will cause hard-to-diagnose crashes. Either return a copy or use new ..() and return pointer.
  2. I don't see where you call m_obstacleManager = new ObstacleManager();. How do you initialize it?
  3. Does crash occur if you call m_Pillars.empty()? I don't see anything wrong with std::vector<Pillar*> m_Pillars, perhaps you could show how you use ObstacleManager class?
  4. Most likely you have corrupted memory so vector<> became garbage and everything you do starts to cause issues. Are you sure your pointer is valid - perhaps you are using object after it was deleted?
  5. Are you still constructing vertices on CPU? If yes, try moving that to GPU using instancing. One of ways to do that would be to create: vertex buffer that contains only 4 vertices (there's a way to achieve same without vertex buffer at all, but let's keep it simple for now) instancing buffer that contains position, scale (optional), rotation (optional), texcoord Then you'd just set them both and render N number of instances of 4 vertices and use information from instancing buffer to transform vertices into sprites.
  6. Do you really need whole matrix for each sprite? Perhaps you could limit it just to position? Then you will save a lot of space and increase max number of instances.
  7. "With the debugger configuraiton set" That one word could use a correction.
  8. Half of that sentence is very suspicious. Could you show code for your flushVertexBuffer method? Or even better - upload all code in .zip (if possible), it's somewhat hard to track things when it's all over the place. I see that addToVertexBuffer(Sprite* sprite) also creates geometry for sprites every frame. Most of the time that's not the right way to do it and it probably still uses majority of your CPU.
  9. Am I understanding this correctly: your renderList contains 10,000 sprites and you Map() > memcpy() > Unmap() each one individually? No wonder you're having issues. It should be a single Map() > memcpy() > Unmap() call.
  10. It's almost 2018. Update your Windows 10 and your Task Manager will be able to show GPU usage % and GPU memory usage.
  11. DirectXMath conditional assignment

    XMVectorLessOrEqual returns 0xFFFFFFFF on true and 0x00000000 on false, therefore you can play with bitwise operations: Edit: ajmiles suggestion is better - XMVectorSelect does exactly same thing as I suggested above.
  12. In the past I had some random crashes when SSE was being used on unaligned data. In your case it might happen when DirectX Math objects (vector, matrix, etc.) are stored on the heap.
  13. There is LZ4 which is slow to compress on highest level (thus should be done offline), but decompression is 10 times faster than zlib according to them (and half the speed of memcpy). https://github.com/lz4/lz4
  14. Probably that's your problem. Visual Studio comes with DirectX since a few years ago. Mixing them together is just asking for trouble. Also, are you sure it's not simply compiling shaders / loading data? 
  15. Animation is buggy in Java

    1. Wrong forum 2. I'm not sure how you expect us to help if you haven't even posted source code or explained the problem properly (what exactly is wrong?)