Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Oct 2010
Offline Last Active Feb 14 2015 12:42 PM

#5076083 Direction Vector2 from float 0-360 degree in pixel shader?

Posted by on 08 July 2013 - 04:10 AM

float2 vec;
sincos(radians(angle), vec.y, vec.x);



#5074733 Distance field font artifacts

Posted by on 02 July 2013 - 07:46 AM

Off topic tip: Instead of an alpha threshold, you could try a steep gradient outside the threshold, which will give nice antialiasing :)

#5061508 Compute project triangle's area

Posted by on 13 May 2013 - 08:03 AM



Some other ideas are this ...


Use D3DXVec3Project to take each point of a triangle and project it to screen space.


Take the cross product of any two screen space triangle points. This is twice the area of the triangle (in screen space).


Slightly incorrect. If you take the cross product of two points as position vectors, the magnitude of the resulting vector will be equal to the area of the triangle formed from the two points and the origin, which you don't want.


To calculate the area of the triangle formed by the points A, B and C, calculate the normal to the triangle by n = (B - A) x (C -A). The area is the length of that normal.


Pointless but interesting extra maths fact: if A, B, C are transformed by a linear transformation represented by matrix M, the area will be multiplied by the determinant of M. (Note projection matrix is NOT a linear transform ;))

#5061041 To Defer or Not To Defer

Posted by on 11 May 2013 - 05:34 AM

Some thoughts:


Mobile devices generally have really small screens. Is deferred rendering really worth it?


As for rendering the scene to a cubemap with deferred rendering, well that just sounds ridiculously expensive, and again, mobile hardware


No MRTs means multiple full-scene passes. Thats however many buffers there are in the gbuffer, x7 (1 for screen,  6 for a cubemap).


We tend not to use refraction on most transparent objects because it's quicker to use normal boring alpha blending. (Did I misunderstand you here?)


I was playing Black Ops 2 earlier, and I noticed a weird transition on the reflections on my golden gun whenever I exited a room. That I suspect is caused by the engine using pre-baked cubemaps.


Lightmaps can look absolutely gorgeous if well done.

#5059705 Weird skeletal animation collapsing error

Posted by on 06 May 2013 - 05:43 AM

I know t is in [0, 1], because it is calculated as

t = (requested_frame - min_frame) / (max_frame - min_frame)

where min_frame is the previous keyframe before the requested, and max_frame is the immediately next.


Anyway, when I was checking this, I found the problem: For calculating the position at any given frame, the animation track does this:

Vector3 GetFrameTranslateKey(float frame)
    Vector3 before = ...
    Vector3 after = ...
    float t = ...
    return before + (after - before) * t;


So that's fine, but then I carelessly copy-pasted that into the quaternion version

Quaternion GetFrameRotateKey(float frame)
    Quaternion before = ...
    Quaternion after = ...
    float t = ...
    return before + (after - before) * t;

so I changed the last line to

return Quaternion::Slerp(before, after, t);

and it works flawlessly. Thanks for helping guys!

#5053290 [DirectXTK] Custom SourceRect for SpriteBatch doesn't show up? (Solved)

Posted by on 14 April 2013 - 05:54 PM

I'm using SpriteBatch from the DirectXTK


So I want to display a texture across the whole screen, and it's smaller than the screen so I provide a SourceRect that's larger than the texture, scale it up to fit the screen, and provide a CommonStates::LinearWrap() as the sampler state.


However this doesn't display the texture, although I pass nullptr as the SourceRect, it displays the texture stretched across the entire screen.


What could be going wrong? It's not a feature level problem, The texture is a 256x256 (although it still fails on FEATURE_LEVEL_11_0)


EDIT: Solved, I flipped the top/bottom of the SourceRect.

#5039709 What would you make armour out of?

Posted by on 05 March 2013 - 03:02 PM

Here we are then;



From left to right: Iron Plate Armour, Steel Plate Armour, Leather Armour, as modeled by the player in the middle, and two human NPCs with default hair. I like how the Leather Armour turned out, slightly inspired by the Roman lorica segmentata with the shoulder pieces. The Steel has no texture yet, and looks like the normals need fixing as well :)

I'd also like to point out that the lighting and terrain are unfinished!



I admire the enthusiasm, but you'd be wise to keep in mind that sometimes less is more.


There's no quicker way to ruin a game--or, more likely, to simply send it into the abyss of non-completion--than to just throw in every idea that sounds cool. The creative act of achieving a harmoneous whole is as much about taking away as it is adding to. In fact, I'd argue that knowing what to take away (or simply not add) is the more important part.


You're right, but I'm having so much fun right now smile.png Some stuff might have to come out later, I shall give each one careful thought before I start modeling it. This sounds like really good advice for working on something really important like gameplay features, but hey, these are just items with varying stats.

#5039528 What would you make armour out of?

Posted by on 05 March 2013 - 09:36 AM

Hi y'all. Hoping to set up a brainstorming session here smile.png


What, in a medieval-fantasy world a la Elder Scrolls, could armour be made from? I'm hoping to have a vast array of different armours, and perhaps the magical ones could have their own subtle abilities. All ideas welcome! Here is the most interesting subset of what I have come up with so far:


EDIT2: No longer taking armour ideas - I have 30 different materials now, but thanks to everyone who contributed! I got rid of a few, including a few of my own, and am satisfied with the final list smile.png Seeing how awesome this thread was, I might make another suggestions thread for other items (Especially weapons!) and spells


The armour categories are now divided into: Mundane, Elemental, Natural, and of course the two Divine armours accessible to demigod characters



Animal Hide


Scale Mail

Chain mail

Iron Plate

Steel Plate



Golden - magic properties of gold allow mage-smiths to alloy it with steel to make it stronger





Leaf - Armour made from very very tough leaves! Very lightweight.






Spider Silk




Igneous - rocky exterior with the lava core showing through cracks

Sanguine - steel fused with blood, forged by vampire blood-alchemists


Magesteel / Necrosteel - Normal steel forged with enchantments

Skysteel - rare metal found in falling stars (meteorites)

Aphotic - this mysterious material absorbs all light...




Apocalyptic - forged in the heart of a dying star


(Apocalyptic and Halcyon armour only accessible to characters that have become demigods)


Again, all ideas welcome, and feel free to suspend disbelief/ignore the practicalities!

#5005551 DrawInstanced problem

Posted by on 29 November 2012 - 09:14 PM

You can, but I think the vertex buffer is a better idea.

Sometines you might not even need any per instance data, you could generate it in the vertex shader. For example if I was drawing an NxN square of objects I might do

// game code
int squareSide = 10;
SetVertexShaderInt("SquareSide", squareSide);
DrawInstanced(numVertices, squareSide*squareSide);

// shader
int SquareSide;

VertexShader(instanceID : SV_INSTANCEID)
	 instance_pos.x = instanceID / SquareSide;
	 instance_pos.z = instanceID % SquareSide

fairly contrived example I concede

#5004995 (D3D9): Managed resources not re-appearing after Reset() ?

Posted by on 28 November 2012 - 10:48 AM

Solved. It was actually the DRAWING of the skybox that was causing problems. (Setting some shader constants which weren't reset for drawing meshes, making them appear black, which tricked me into thinking the textures were being lost).

#5003313 What would you want from a zombie apocalypse simulator.

Posted by on 22 November 2012 - 02:50 PM

- Colossal map.
- Hunger/thirst simulation
- 10-50 players per server. Incentivise sticking together in smallish groups, but not too large. Battle other groups to get their resources
- Guns and ammo are rare and valuable
- Fast zombies, slow zombies, large zombies, small zombies, zombie dogs, zombie fish...
- Motor vehicles, but also bicycles, horses, rowboats.
- Make fuel a (valuable) commodity
- Build a fortress and craft items (traps, explosives, weapons even) from stuff
- Make it winnable (maybe make one game mode winnable) Eg - "the chopper arrives in 10 days, survive until then", or "the zombies spawn at the evil pentagrams scattered about the map, visit and destroy these to win" - forces players to explore the map.

#5003249 Instancing render strategy: altering renderbuffer or throwing all at card?

Posted by on 22 November 2012 - 09:26 AM

I really really don't recommend throwing everything at the card. I might point out that in any game scenario there's a limit to however many shadow maps you're going to be using in one frame anyway, because the expense of generating more than 4 shadow maps per frame, then over 4 texture comparisons when shading the scene, becomes prohibitive.

I would really create as many instance buffers as you need. Let's say you want 30 different meshes to be instance-able. (5 tree variations, 10 rock variations, 5 grass variations, 10 floor clutter variations, random props eg crates, barrels, etc etc).
Each instance requires one float3x3 for a rotation*scale, float3 for a position, float3 for a diffuse color, and 2 more arbitrary float parameters which could be used for different things, makes 16 floats which fits nicely). The total amount of data is 64 bytes per instance
You want 1000 maximum instances in the level, and you limit the number of active shadow-mappable lights to 4. This means each mesh needs 5 instance buffers. So that's
30x5x1000x64 bytes = about 9 mb of VRAM. Not a huge amount, and will be eclipsed by the shadow maps themselves. (4x1024x1024x32bpp = 16 mb)

Objects don't need to know how many cameras they are visible to. The scene can do frustum culling for all objects and lights at the same time, and write the instance buffers as necessary.

Let's take a good example from the game du jour - Slender. If you haven't played it, it's a horror game where the player walks around in first person view in a forest at night with a torch. Now obviously the torch is represented as a spot-light, which has an associated shadow map. (I think it's the only light source in the game as well as a very small amount of ambient light). Now let's say there are 100 trees in the game level. About 20 are visible to the player at any time, and 5 fall within the torch's beam. You tell me how much of a waste it is to throw everything at the card.

This is the approach I'm using anyway.

#5003076 Instancing render strategy: altering renderbuffer or throwing all at card?

Posted by on 21 November 2012 - 06:54 PM

You could use multiple instancing buffers. One for each light for the shadow map generation, one for the scene rendering. Then you can lock them ALL, iterate through the scene and add all instances to their respective buffers as required, then unlock all and start using them to generate shadow maps and render the scene. By doing the lock/unlocking concurrently (well, interleaved), you reduce the amount of time the CPU has to wait for the buffers to be free

compare the following two strategies, given that you have 2 shadow mapped lights (makes 3 instance buffers used in total)

lock | iterate scene/copy instance data | unlock | render shadow map 1 | lock | iterate scene | unlock | render shadow map 2 | lock | iterate scene | unlock | render scene

lock x3 | iterate scene/copy instance data | unlock x3 | render shadow maps 1-n | render scene

(I assume that by the instance buffer you mean the vertex buffer that is bound to slot 1 and contains a Matrix per instance, or float3(pos)+float(uniform scale)+float(quat rotation) if you're really fancy)

#5001999 Creating Texture2D with OpenCL

Posted by on 18 November 2012 - 04:07 AM

Why aren't you using DX compute shader? Probably the only way to get OpenCL/D3D11 interop is using a CPU copy

#5001997 problem initializing Direct 3d Device

Posted by on 18 November 2012 - 04:01 AM

Did you copy the original code from Riemer's website? That would be why it worked before, but unfortunately you've mangled it quite badly in the class-ifying process Posted Image I was feeling generous this morning so I fixed it for you

Here are the changes:

- Changed the window procedure and got rid of the global "int run" variable. (In general people stay away from global variables in C++; if you want to know why, there's a discussion somewhere in the General Programming forum I think).
- Only need 4 files
- You didn't provide Game.h? So I basically rewrote the Game class.
- Game class does not own the Direct3D interfaces - they are owned by Graphics
- Initialisation of Direct3D now happens in Graphics::Graphics() rather than Game::Play() (this is probably what was causing the problem)
- Got rid of the Renderer class (not needed)
- Changed the PeekMessage() call, passing in NULL for the HWND parameter. This makes PeekMessage read all messages destined for the program (thread) not just the window
- Renamed the OURCUSTOMVERTEX struct to Vertex and moved it out of the Graphics class
- Added some stuff to Graphics class
- Lots of smaller changes.

// Defines.h



// Camera.h

#include "defines.h"
class Camera
void SetUpCamera(LPDIRECT3DDEVICE9 );

// Game.h

#include "Graphics.h"
class Game
Graphics* pGraphics;
Game(HWND hWnd);
void Play();


#include "defines.h"
struct Vertex
float x,y,z;
DWORD color;
class Graphics
Graphics(HWND han_WindowToBindTo);
void RenderScene();
LPDIRECT3D9 p_dx_Object;
Vertex cv_Vertices[3];

// Windows.cpp

LRESULT CALLBACK OurWindowProcedure(HWND han_Wind,UINT uint_Message,WPARAM parameter1,LPARAM parameter2)
  case WM_KEYDOWN: // delete this line to disable any-key-exit
  case WM_DESTROY: // when the user presses the red X button
   return 0;
return DefWindowProc(han_Wind,uint_Message,parameter1,parameter2);

HWND NewWindow(LPCTSTR str_Title,int int_XPos, int int_YPos, int int_Width, int int_Height)
WNDCLASSEX wnd_Structure;

wnd_Structure.cbSize = sizeof(WNDCLASSEX);
wnd_Structure.style = CS_HREDRAW | CS_VREDRAW;
wnd_Structure.lpfnWndProc = OurWindowProcedure;
wnd_Structure.cbClsExtra = 0;
wnd_Structure.cbWndExtra = 0;
wnd_Structure.hInstance = GetModuleHandle(NULL);
wnd_Structure.hIcon = NULL;
wnd_Structure.hCursor = NULL;
wnd_Structure.hbrBackground = GetSysColorBrush(COLOR_BTNFACE);
wnd_Structure.lpszMenuName = NULL;
wnd_Structure.lpszClassName = "WindowClassName";
wnd_Structure.hIconSm = LoadIcon(NULL,IDI_APPLICATION);


return CreateWindowEx(WS_EX_CONTROLPARENT, "WindowClassName", str_Title, WS_OVERLAPPED | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX | WS_VISIBLE, int_XPos, int_YPos, int_Width, int_Height, NULL, NULL, GetModuleHandle(NULL), NULL);
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPreviousInstance,LPSTR lpcmdline,int nCmdShow)
HWND han_Window = NewWindow("DirectX C++ Tutorial",100,100,500,500);
Game gm(han_Window);
MSG msg_Message;
  if (msg_Message.message == WM_QUIT)
// p_Device->Release();

return 0;

// Graphics.cpp


Graphics :: Graphics(HWND han_WindowToBindTo)

p_dx_Object = Direct3DCreate9(D3D_SDK_VERSION);
if (p_dx_Object == NULL)
  MessageBox(NULL, "DirectX Runtime library not installed!", "InitializeDevice()",MB_OK);

ZeroMemory( &dx_PresParams, sizeof(dx_PresParams) );
dx_PresParams.Windowed = TRUE;
dx_PresParams.SwapEffect = D3DSWAPEFFECT_DISCARD;
dx_PresParams.BackBufferFormat = D3DFMT_UNKNOWN;

if (FAILED(p_dx_Object->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, han_WindowToBindTo, D3DCREATE_HARDWARE_VERTEXPROCESSING, &dx_PresParams, &p_dx_Device)))
  if (FAILED(p_dx_Object->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_REF, han_WindowToBindTo, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &dx_PresParams, &p_dx_Device)))
   MessageBox(NULL, "Failed to create even the reference device!", "InitializeDevice()",MB_OK);
p_dx_Device->SetRenderState(D3DRS_CULLMODE, D3DCULL_NONE);
cv_Vertices[0].x = 5.0f;
cv_Vertices[0].y = 10.0f;
cv_Vertices[0].z = 0.0f;
cv_Vertices[0].color = 0xffff0000;

cv_Vertices[1].x = 10.0f;
cv_Vertices[1].y = 0.0f;
cv_Vertices[1].z = 0.0f;
cv_Vertices[1].color = 0xff00ff00;

cv_Vertices[2].x = 0.0f;
cv_Vertices[2].y = 0.0f;
cv_Vertices[2].z = 0.0f;
cv_Vertices[2].color = 0xff00ffff;

if (FAILED(p_dx_Device->CreateVertexBuffer(3*sizeof(Vertex), 0, D3DFVF_XYZ|D3DFVF_DIFFUSE, D3DPOOL_DEFAULT, &p_dx_VertexBuffer, NULL)))
  MessageBox(NULL, "Error while creating VertexBuffer", "FillVertices()",MB_OK);

VOID* p_Vertices;
if (FAILED(p_dx_VertexBuffer->Lock(0, 3*sizeof(Vertex), (void**)&p_Vertices, 0)))
  MessageBox(NULL, "Error trying to lock", "FillVertices()",MB_OK);
  memcpy(p_Vertices, cv_Vertices, 3*sizeof(Vertex));
void Graphics::RenderScene()
p_dx_Device->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(72,61,139), 1.0f, 0);

p_dx_Device->SetStreamSource(0, p_dx_VertexBuffer, 0, sizeof(Vertex));
p_dx_Device->DrawPrimitive(D3DPT_TRIANGLELIST, 0, 1);

p_dx_Device->Present(NULL, NULL, NULL, NULL);
// Game.cpp

Game::Game(HWND hWnd)
pGraphics = new Graphics(hWnd);
delete pGraphics;
void Game :: Play()

// Camera.cpp

Camera :: Camera ()
void Camera :: SetUpCamera(LPDIRECT3DDEVICE9 p_dx_Device)
D3DXVECTOR3 m_EyePos(0, 0, -30);
D3DXVECTOR3 m_TargetPos(0, 0, 0);
D3DXVECTOR3 m_UpVector(0, 1, 0);
D3DXMatrixLookAtLH(&m_View, &m_EyePos, &m_TargetPos, &m_UpVector);
p_dx_Device->SetTransform(D3DTS_VIEW, &m_View);
D3DXMATRIX m_Projection;
D3DXMatrixPerspectiveFovLH(&m_Projection, D3DX_PI/4, 500/500, 1, 50);
p_dx_Device->SetTransform(D3DTS_PROJECTION, &m_Projection);

Directx stuff is hard! So make sure you understand classes and other C++ concepts well!