Planet Chili

Just a guess here, but I'll try my best. When you create a projection matrix, it defines the entire area the camera can see. Setting the near Z to 1.f would/should be where the "screen" is. By lowering the near Z, you move the near clip plane or closest viewable plane closer to the camera and increa...

Look in Graphics::EndFrame(). You'll find something like pSwapChain->Presetn( 1u, 0u );
Change it from 1u, 0u to 0u, 0u. This will avoid v-sync.

There is another way to determine collision and how much correction called Separating Axis Theorem ( SAT ). This took me some time to figure out from all the information on the subject, a lot of the code examples online have errors that the authors never address. Unfortunately, it has been too long ...

Glad you figured it out, the text in the image is WAY too small for me to read, so I wouldn't have been able to help at all.

Sorry for the late reply, I guess not many people still visit the forum and I have been busy for the past few months.

The way you are handling the collision is missing a key factor, where the collision is taking place. Let's say you are coming from the top and heading to the right. The first thing your code does is check the direction you're traveling. In this case, we are moving right, so the green rectangle gets ...

Ultimately, there are a few steps to achieve what you want. First, you must #include "Graphics.h" at the top of the header ( .h ) file you want to use the Graphics class. Put this line after #pragma once. Second, in the declaration of the Draw function you must pass the Graphics object by reference ...

the only classes I see in those files are position and inhibitions.

Interesting stuff.

Have you determined how many particles you're creating and rendering? Seems to be quite a few and still pretty smooth.

Are you planning on releasing the source code? or as a library? or just for personal use?

Wasn't able to run your program there, says there's an assertion in file Surface.cpp on line 9.