Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Mar 2006
Offline Last Active Apr 27 2016 03:16 PM

Posts I've Made

In Topic: Recover full screen device, procedurally from other process.

27 February 2013 - 08:33 AM

I'm handling all the input through the traditional WndProc message callbacks. I have a feeling I might be incorrectly using AllowSetForegroundWindow in the process that is supposed to give up focus when its done to the dx9 app, and that is what's causing the weird "rending on top, but input falls through to the windows behind".


Thanks, for helping tho!

In Topic: Recover full screen device, procedurally from other process.

26 February 2013 - 04:13 PM

Are you releasing all of your device resources, including textures, vertex buffers, essentially anything created by D3D? I'm only seeing the device currently, and it can't reset properly until all resources have been released.

Yeah, the m_pDevices[j].OnLostDevice(); is handling all of that within. I am able to have it recover properly when I use the mouse and keyboard to select the minimized application. That's why I'm pretty certain it's some sort of focus issue.


void LtGDevice::OnLostDevice()


	// Kill all the tasks... they will be repopulated upon DeviceReset
	for(unsigned int i = 0; i < m_vScheduledTasks.size(); i++)

	for(map<int, LPDIRECT3DTEXTURE9>::iterator iter = m_mapTextures.begin(); iter != m_mapTextures.end(); ++iter)

	for(map<FONT_HANDLE, LPD3DXFONT>::iterator iter = m_mapFonts.begin(); iter != m_mapFonts.end(); ++iter)

	m_bForceReset = false;

In Topic: Draw text and color bar using sprites

05 February 2013 - 10:17 AM

I'm not sure what you mean by "solid rectangles", but it may be that you don't have the correct render states enabled to draw text.





try enabling those states on the d3dDevice using SetRenderState();

In Topic: walking enemy - better algorithm sfml c++

31 October 2011 - 12:48 PM

There's nothing really "wrong" with what you have, but a large constraint to your enemy's AI is that it's entirely hardcoded in its logic. A better algorithm that would be more flexible would be to create a node based path that the enemy will take and repeat. The enemy would move toward the next node regardless of its current position, then continue to the next one once it reaches its destination.

The nodes in your case would be the four points (X,Y) of the square. Store the nodes in a dynamic container and you gain the flexibility to add or remove nodes on the fly. If the enemy ever gets off its path such as it chased the player, it could resume back on its path when instructed to since it's not hardcoded (and assuming there isn't anything obstructing its path).

Another important benefit to using something more flexible is that the system you write that moves the enemy could be reused for other enemies or new levels.

In Topic: [dx11] vsync causes lag( little jumps from time to time)

31 October 2011 - 12:13 PM

its just one or two frames, so Im not sure if those are indeed the ones that bumps, would one frame drop be so noticeable?

Dropping from 60FPS to 30FPS, even if only a single render frame would cause a noticeable 'jump' if an object on the screen (or camera) is translating using a time delta.

What the hell can be causing this, its weird, when I searched for something like this(bumps), ppl solved by turning vsync ON, not vsync causing it...

Glitches/bumps/jumps shouldn't be resolved with vSync unless their transformations are being updating on a frame by frame basis rather than time (you should almost always be using time for this). Vsync is implemented to reduce screen tearing, which looks like your screen has a horizontal rip in it.

I did found that from times to times, I get a frame running at 0.03xx, witch is a 30fps value

This is likely due to the fact that your monitor is refreshing at ~60Hz, which means with vSync enabled, Present() will block until your monitor is in the vertical blank state, throttling your game to 60FPS. It will drop to 30FPS if one of the updates takes longer than 60Hz and misses one of these vBlanks, thus the next update won't get around until two vBlanks.