Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 04 Mar 2011
Offline Last Active Today, 12:36 PM

Topics I've Started

Particle Z Fighting

23 March 2015 - 10:30 AM

I have these particles drawn with transparency, and as such have turned off writing to the depth buffer. They are waterfalls that start blue and turn white as they hit bottom and lose energy. Unfortunately, this creates noticeable z fighting that is really bugging me, since the flickering seems to happen in unison with all the other waterfalls on screen.


I don't suppose there is a way to turn on the depth buffer only for pixels at full alpha? I'm not even sure that would look better as the sprite edges would still fight... What if anything can be done about this? Sorting them seems out of the question since there's hundreds of thousands of them. They are sorted by age I suppose, maybe I can use a depth bias.

FPS counter suspicious

20 March 2015 - 02:24 PM

My FPS counter is updated in the main game loop, like most tutorial examples you see. So, I have this computer that has a fairly fast CPU and a bad slow GPU. When I adjust certain things to put more work on the GPU, the reported frame rate improves, but in every other way it feels like performance has worsened. The animations and camera controls stutter noticeably. When I shift that work back to the CPU, my reported frame rate worsens, but the animations are much smoother.


Is it possible that my update loop is going at a different rate than my render loop? Maybe frames are being skipped automatically somehow? How is this possible?

Rotating texture coordinates

17 March 2015 - 01:46 PM

I have a game board that consists of hex polygons with a glyph texture on them. The hexes are all lying flat facing up in the positive Y direction. The texture coordinates for the six vertices are currently just the x and z vertex positions of a hex, offset so that the texture is centered on the hex. If you orient the camera with the screen top toward 'north', you see a hex with the chosen glyph on it. If you orient the camera so that the screen top is facing 'south', then you see a hex with an upside down glyph on it. This is exactly what you would expect, since the texture coords are fixed. 


Here's what's bugging me... Since the meaning of the hex is denoted by a glyph, It would be better I think if the glyphs were always oriented with the bottom of the screen, even when the geometry is not. A letter 'A' is much more quickly communicated when it's not upside down or sideways, so I would like to try rotating the texture coordinates to see if that looks better.


I'm a bit rusty on my matrix operations. How can I create a texture rotation matrix that will do this?


If I cross the camera vector with the up vector, and then cross the result with the up vector again, I get... I don't know what I get. Here is my current vertex shader:

VertexOutput VS(VertexInput vin)
	VertexOutput vout;

	float3 positionWorld = vin.PositionLocal.xyz;
	positionWorld.x += vin.Translation.x;
	positionWorld.y += vin.Translation.y;
	positionWorld.z += vin.Translation.z;
	vout.PositionH = mul(float4(positionWorld,1.0f),ViewProjection);

       //a hex is exactly 2.0f tall, these adjustments center the texture
	vout.TexCoord.x = vin.PositionLocal.x * 0.5f + 0.5f;
	vout.TexCoord.y = vin.PositionLocal.z * 0.5f + 0.55f;

	vout.TexCoord.z = vin.Translation.w; //this is a 2D texture array slice selection

	vout.Bary = vin.Bary;

	return vout;

'un-flattening' a 3D array

16 March 2015 - 05:30 PM

So in the case of a 2D array, you can have 2 coordinates to describe a location in that array. You can also describe the data as a 1D array by calculating the raw index by x + y * width. If you have the raw index, you can get the y coordinate with an integer divide like so: y = i/width. Then you can get the x coordinate with the modulus operator x = i % width.


This should also be possible to get the coordinates for a 3D array, but I can't figure it out. If you know the width(maxX), height(maxY) and depth(maxZ) of a 3D array, you should be able to convert a raw index into coordinates... right?

Drawing things off screen performance

16 March 2015 - 08:20 AM

I currently have a working particle system for waterfalls on a hex map game board, and I'm trying to get some better performance.


I currently have a scheme that only updates and draws particles on map chunks that are in the view frustum, but the problem is that my frustum culling is inefficient and also that when the user mouselooks around the map, the waterfalls are just turning on when they come in to view, betraying the fact that when the user is not looking they are turned off, which looks a bit goofy.


I can update the particles all around the camera without penalty, and in fact getting rid of the frustum culling could be a huge boost in terms of updating particles, but I'm concerned about the drawing of them.


I've noticed that drawing small particles is much faster than drawing large particles, but what about drawing that ends up off screen? Is there any automatic culling that goes on in that case? One thing I might be able to do is frustum culling in the update compute shader to set my particle radius to 0, that way if they are drawn at least they will be drawn quickly, but if they aren't drawn anyway then there is probably nothing to gain by that.


Does it take as long to draw a large particle off screen as it does to draw a large particle on screen?