Tag Info

New answers tagged

0

You can't use SV_Position for this in hlsl, you should get the position from an other output slot without the SV_Position semantic instead. output.mPosition = float4(output.mTexcoord * float2(2.0f, -2.0f) + float2(-1.0f, 1.0f), 0.0f, 1.0f); output.mNewPos = output.mPosition; //use mNewPos in the pixel shader SV_Position is just for the rasterizer.


0

Transforming uv coordinates should be good enough. You could do it while loading your model, or even in a shader. Whether the texture is upside-down in memory is irrelevant for performance when sampling the texture.


8

There are a number of different techniques for organizing the data, and many games use a mix of them. For static geometry, it's best to have fewer individual IBs and VBs. Traditionally games are 'level' based which means the assets for a section of play are loaded and then the game play begins. To minimize load-times, the information is ideally organized ...


0

I personally haven't used the method your using. But since you have asked if there is another way to do this... Suppose you have a texture atlas (texture made up of sub-textures) where each sub-texture has the same dimensions: Then if you create a RECT R = {j*64, i*64, (j+1)*64, (i+1)*64}; ->Where int j = currentFrame / 6 //row ->Where int i = ...


0

Since there is no value for this listed in the Direct3D 11 Resource Limits I don't think there is a limit. However according to the documentation 9_1 feature level devices only support 16-bit index buffers.


0

Given the option between "warping the cursor back to the middle of the screen every frame" or "constraining the mouse inside the game window", you always want to constrain the mouse within the window. With the "teleport the mouse to the middle of the screen each frame" approach, the mouse is actually not being constrained within the window; it's just ...


0

There's no "better" solution here. You describe 2 different techniques, choosing between them is a design decision that depends entirely on the context and the intended effect. Locking the mouse with instant camera moves comes from FPSes, but I'm sure it has been used for other genres. It gives a very responsive and precise camera movement, but the down ...


2

Play some game with your system. Check FPS you are getting. Analyze what is on the screen of the game and compare to yours. If your one cube is rendering slower than game screen, you are obviously doing something wrong. I would expect one cube with all the normal stuff applied running atleast 500-1000fps on my computer. I can run games like Battlefield 4 ...


5

For a simple 2D engine with sprites, a single-threaded approach is perfectly good. But since you want to learn how to do multithreading, you should learn to do it correctly. Do not Use 2 threads that run more or less lock-step, implementing a single-threaded behavior with several threads. This has the same level of parallelism (zero) but adds overhead ...


3

I am not sure what you want to achieve by limiting the FPS of the Update and Render both to 60. If you limit them to the same value, you could have just put them in the same thread. The goal when separating Update and Render in different threads is to have both "almost" independent of one another, so that the GPU can render 500 FPS and the Update logic ...


0

Turns out, the depth values were correct the whole time. I was looking at a bad image for reference, where objects would get darker as they got further away from you. Of course, this is completely incorrect. After seeing how crazy normal depth precision is, I decided to use my own linear depth, which worked much better for shadow mapping.


8

For newcomers to this question, it looks like Microsoft has put up XNA installers for Visual Studio 2010/2012/2013. I haven't personally tested to make sure these work, but they might be worth a look: https://msxna.codeplex.com/releases/ EDIT: After running all included installers for the Visual Studio 2013 release (running VS 2013 Ultimate on my ...


0

By default, the Direct3D 10 device interface is 'thread-safe' if you don't use D3D10_CREATE_DEVICE_SINGLETHREADED. This means it should work from multiple threads, but could well have lock contention. Direct3D 11.x splits the device into two parts: a Direct3D 11 device interface which is always 'thread-safe' (again unless you use ...



Top 50 recent answers are included