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 07 Mar 2005
Offline Last Active Yesterday, 09:58 AM

Posts I've Made

In Topic: Weird glitch with overlapping polygons

04 May 2015 - 03:41 PM

D3D unfortunately doesn't expose any 64 bit data formats (with a single component being wider than 32 bits) yet - so no dice with 64 bit buffers. Also I guess that most depth buffer compression schemes in use by the IHVs won't fit out of the box with 64 bit precision requirements etc. So for now you need to be careful with the ratio of near to far plane I'm afraid :)


All formats (potentially) supported by D3D11 are here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb173059%28v=vs.85%29.aspx

In Topic: Weird glitch with overlapping polygons

04 May 2015 - 09:13 AM

Like Buckeye wrote the ratio of your near to far plane is one of the most important tweaking possibilities - since the values are not distributed uniformly over the range you see that the artifact gets better when you get closer.


Out of curiosity: What are your near & far plane values? And are you using a D32F, D24S8 or D16 depth buffer format?

In Topic: Weird glitch with overlapping polygons

04 May 2015 - 07:30 AM

Welcome in the land of limited depth buffer precision and non-uniform value distribution ;)


What you're experiencing is known as z-fighting - see Wikipedia here: http://en.wikipedia.org/wiki/Z-fighting

So the two triangles have similar depth values in the area of the intersection - there are a couple solutions but it is a very tricky problem.


The best solution is to try to not have the situation in the first place ;)

Then you can also try to have a greater angle between the triangles so their depth values differ more quickly.

Sometimes also using a depthbias is a viable option (e.g. you hint the renderer that the depth value should actually be closer of further from the original value), but itdepends on the situation if this is a usable solution. 


Some background on the depth bias can be found for example here in the Microsoft documentation: https://msdn.microsoft.com/en-us/library/windows/desktop/cc308048%28v=vs.85%29.aspx

In Topic: sfml health bar

28 April 2015 - 09:20 AM

What you're hitting is that you (very likely) hit the classic first time problem of integer division.

The SFML setScale() method accepts a floating point value - but if your m_playerHealth and maxHealth values are of integral type this will basically only return 0 if m_playerHealth < maxHealth and 1 otherwise.


To fix this you can simply cast one of the values (or both) before doing the division to a floating point value.

healthBarSprite.setScale(static_cast<float>(m_playerHealth) / maxHealth, 1);

This should fix it - beware that of course the floating point values may not be 100% exactly the same as your integer values but for your UI it should totally be fine ;)

In Topic: Why do games not have items 'one sale' in their stores

25 February 2015 - 07:55 AM

In Animal Crossing: New Leaf (at least) they have also this mechanic. You can basically order anything you had (or have seen in a street-pass house) via the catalogue. However sometimes they have special items of the day which are special priced (or even only available then).