Hi everyone, here's a fun one. I've been using DX11 for ages and I've never seen anything like this happen before.
I found a bug in an application I'm developing when changing the resolution in full-screen mode. In order to handle arbitrary display mode changes (such as changes to MSAA settings), I destroy and recreate the swap chain whenever the display mode changes (rather than just using IDXGISwapChain::ResizeBuffers and IDXGISwapChain::ResizeTarget).
On application startup, the device and initial swapchain are created via D3D11CreateDeviceAndSwapChain. When the display mode changes, this initial swap chain is destroyed, and a new one is created using IDXGIFactory::CreateSwapChain, with a new DXGI_SWAP_CHAIN_DESC.
What I've found is that, despite the new DXGI_SWAP_CHAIN_DESC being correct when supplied to IDXGIFactory::CreateSwapChain, if I then retrieve the desc from the resulting swap chain, it has values from the old one. For example, if the resolution is changed, the swap chain is created with new (correct) values for BufferDesc.Width and BufferDesc.Height, but this new swap chain contains the old values which the initial (now destroyed) swap chain desc had.
Consequently the back buffer is the wrong size, which leads to obvious problems and errors.
Has anyone encountered a similar situation, or can think of anything useful to investigate?
Here's a simplified version of the code for the display mode change:
m_pDeviceContext->OMSetRenderTargets(0, nullptr, nullptr);
m_pSwapChain = nullptr;
IDXGIFactory *pFactory = nullptr;
CheckResult(CreateDXGIFactory(__uuidof(IDXGIFactory), reinterpret_cast<void **>(&pFactory)));
IDXGISwapChain *pSwapChain = nullptr;
DXGI_SWAP_CHAIN_DESC swapChainDesc = CreateSwapChainDesc(...); // Returns populated DXGI_SWAP_CHAIN_DESC with correct values.
CheckResult(pFactory->CreateSwapChain(impl.m_pDevice, &swapChainDesc, &pSwapChain));
// swapChainDesc does not equal verifySwapChainDesc.
Am a Computer science graduate student and planning to do the Game designing course in Canada and this is my personal statement for the college and it is the first draft ,hence no professional or fancy words used here.
Please help me in the statement before i submit it and let me know if there is anything that has to be cancelled or shortened or edited.
The essay is way over the specified word limit and i will work on trimming it so please help me on this. Essay attached as txt file.
Any help would be appreciated.I have just two days left to submit so please reply as soon as possible.
I'm trying to implement character movement so that my character would slide along the wall (plane) instead of getting stuck next to it.
There is quite a lot of information regarding character sliding on the internet. However all that information seems to be covering only basic cases where character slides only on one plane at a time (collides with one plane at a time). I could not find any information about how to solve corner cases with multiple planes for example where character collides simultaneously with two walls and ground.
My current implementation's general idea is to:
1. calculate the movement velocity vector (intended position change)
2. try to move my character along that vector if vector length is bigger than some epsilon.
2. a. If there is no collision I update the position and I'm done.
2. b. If there is a collision, I move character to the TOI (time of impact),
3. then for the remaining velocity vector I calculate new velocity vector depending on collision normal and repeat the process (go back to 2.)
This seems to work in simple cases, when I'm dealing with one plane (ground for instance). It also seems to work if I simultaneously collide with two objects (ground and wall) if two collision normals are perpendicular. However if angle between two simultaneously collision normals are less than 90° (like "V" corners), my new velocity vector (3.) starts bouncing back and forward between these two surfaces and I need quite a few iterations to resolve the final position. The smaller the angle the more iterations I need. If it was 2d I probably could just stop the algorithm and bale out if I find out that I'm "bouncing" between two surfaces, but in 3D every time I "bounce" my velocity vector slowly changes direction away from current collision normals. But as I said it takes quite a few iterations to get the final result, and this causes freezes, I could limit the iteration count however this might cause my character to stick to a wall instead of sliding along it as I would never reach the correct length of sliding vector.
Some engines like "DigitalRune" move character to the final position, then check for collisions and tries to resolve the final position, in that way you get the sliding effect. This could work in my case as well, however I'm using GJK for collision detection, so I could only solve shallow penetrations, not bigger than 2xMargin. Maybe after first collision and finding TOI I should move my character in smaller steps (not bigger than 2xMargin) for the remaining velocity. In that case I could resolve penetrations. This might work, however it seems that again I potentially can get a lot of iterations. Secondly, by resolving penetration my character might get stuck in another object.
I found one quite fresh topic related to mine:
Randy Gaul says that after finding TOI and collision normal "<..>calculating resolution terms is trivial". Sadly, I find it not that trivial 😞
I know that all my rambling is confusing and hard to understand, but I hope you'll be able to give me some tips.
Any help will be appreciated thank you.
Trivia Quiz: All about everything! - this is an exciting intellectual game that allows you to learn a lot about the world and improve your IQ.
Especially useful quiz will be for students and pupils - it allows you to learn more than tell in the classroom, as well as help to test your knowledge!
Choose your favorite theme and test yourself in different quiz modes! You can choose from one to four topics of questions or all at once! Play in Steam: Trivia Quiz in Steam
To your taste, the game has a wide range of topics:
- Geography - here you can test yourself on the knowledge of countries, capitals, flags, continents, volcanoes, mountains, lakes and other things.
- IT - if you know all about computers and technology, then you here.
- Amazing nearby - find out the most-the most on the planet: the biggest, the longest, the most unusual, the smallest and other amazing facts.
- Biology - test yourself on the knowledge of biology from cells to animals and humans.
- Space - all about the planets, their satellites, galaxies and the conquest of space!
- Chemistry - is a topic for those who know chemical formulas not only of water and alcohol, but also understand the structure of elements)
- Mathematics - answer questions on mathematical formulas, famous scientists-mathematicians and various definitions.
- History - do you like to study dates and key events in the world history? Do you know who Alexander the great, Napoleon and Kutuzov are? Then you here!
The game has several modes:
1. Game on time (Classic, Until the last)
2. Free play (Classic, Until the last)
3. Try your luck
5. Survival for a time
6. Campaign Mode
For streamers, we have a special option that allows your channel's subscribers to vote online for one of the answer options during the game. If you use this option, you can contact us and we will provide you with everything you need.
This feature makes the stream much more interactive and fun!
For you there are Achievements and a rating of Knowledge Leaders.
With each update we will add questions on existing topics and create new topics!
Soon we will add themes:
Linear interpolation (sometimes called 'lerp' or 'mix') is a really handy function for creative coding, game development and generative art.
The function interpolates within the range [start..end] based on a 't' parameter, where 't' is typically within a [0..1] range.
For example, divide 'loop time' by 'loop duration' and you get a 't' value between 0.0 and 1.0.
Now you can map this 't' value to a new range, such as `lerp(20, 50, t)` to gradually increase a circle's radius, or `lerp(20, 10, t)` to gradually decrease its line thickness.
Another example: you can use linear interpolation to smoothly animate from one coordinate to another. Define a start point (x1, y1) and end point (x2, y2), then interpolate the 'x' and 'y' dimensions separately to find the computed point in between.
Or use linear interpolation to spring toward a moving target. Each frame, interpolate from the current value to the target value with a small 't' parameter, such as 0.05.
It's like saying: walk 5% toward the target each frame.
A more advanced example, but built on the same concept, is interpolating from one color (red) to another (blue).
To do this, we interpolate the (R, G, B) or (H, S, L) channels of the color individually, just like we would with a 2D or 3D coordinate.
Another quick example is to choose a random point along a line segment.
There are lots of ways to use linear interpolation, and lots more types of interpolation (cubic, bilinear, etc). These concepts also lead nicely into areas like: curves, splines and parametric equations.
Source code for each of these examples is available here: https://gist.github.com/mattdesl/3675c85a72075557dbb6b9e3e04a53d9
About the author: Matt DesLauriers is a creative coder and generative artist based in London. He combines code and emergent systems to make art for the web, print media, and physical installations.
This brief introduction to lerp was originally published as a Twitter thread and is republished here with the kind permission of the original author.