Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2005
Offline Last Active Yesterday, 06:07 PM

#5297251 Is it possible to declare a macro and have Intellisense ignores it ?

Posted by on 19 June 2016 - 03:19 PM

The intellisense parser declares __INTELLISENSE__ - so you can use this to hide code from Intellisense easily.

See: https://blogs.msdn.microsoft.com/vcblog/2011/03/29/troubleshooting-tips-for-intellisense-slowness/ for more information :)

#5289276 Does server's location affect players' ping?

Posted by on 29 April 2016 - 11:44 AM

According to Wikipedia:

"From this information, a simple rule of thumb is that a signal using optical fiber for communication will travel at around 200,000 kilometers per second."

Looking at google the distance from UK to South Korea and back is around 17700 kilometers. But I guess that the fibers won't be laid in a perfect line from the UK to there so let's assume 20000km for a rough estimate.

This would say that you have at least 1/10th of a second latency (100ms) due to speed of light in fibers and that's just true if you have really only 20000k of fiber between your server and your player. So getting to <60ms from Europe to South Korea is basically not possible due to the physics involved.

And then routing can still bite you. A test trace from my location (Germany) to korea.net reveals that I'm being routed via San Jose which means that at the San Jose hop I'm already at 350ms latency.


This serverfault post talks about US connections but still contains interesting numbers:


#5289268 Does server's location affect players' ping?

Posted by on 29 April 2016 - 11:04 AM

Sure, since the ping is the time for a round-trip between server and client :)

Over these distances the physical distance (speed of light in fibers) actually matters. Also with a bigger geographically distance you also very likely have more routers in between your server and the client where each router may add a tiny bit of latency due to packet processing.


For the best experience of your players having a server closer to them will matter. But as always that depends on your budget etc. 

#5265192 How to mark roof for show/hide?

Posted by on 06 December 2015 - 05:06 PM

I would suggest to find all roof tiles adjacent to the roof tile above the player via a simple flood fill style algorithm. Easy to implement and will only hide all tiles which touch other roof tiles which are connected to the roof tile above the player. If you want to separate roofs which have no spacing in between you would need to add additional criteria for the neighborhood check (e.g. same roof tile set or something similar).

But the easiest to do would be to ensure a space of at least one non-roof covered tile between two houses..



See here for the algorithm: https://en.wikipedia.org/wiki/Flood_fill 

#5253423 Deconstructing Post process of the Order 1886

Posted by on 22 September 2015 - 05:24 AM

Until the developer is here I would recommend their slides on their rendering tech:




(See here: http://advances.realtimerendering.com/s2015/index.html and the other presentations here: http://www.readyatdawn.com/presentations/ )

#5244353 High Speed Collision Detection

Posted by on 03 August 2015 - 01:22 PM

What you described there has actually a name smile.png

It's Continuous Collision Detection (see here for example: https://en.wikipedia.org/wiki/Collision_detection#A_posteriori_.28discrete.29_versus_a_priori_.28continuous.29 )


Most Physics engines have switches to enable CCD for certain bodies (e.g. bullets, rockets, stuff like that) but often have it disabled by default since it is more costly than the standard simulation.


Edit: This page has some nice graphics explaining the stuff as well: http://www.stencyl.com/help/view/continuous-collision-detection/

#5243379 Is it worth to use index buffers?

Posted by on 29 July 2015 - 09:00 AM

It is worth noting that some APIs (e.g. OpenGL ES 2) only allow for indexed drawing and if your engine wants to support that you then need to have fallback index buffers which contain a linear list of indices. But alone for the performance reasons mentioned above (and typical meshes) I would recommend using index buffers.

#5240525 Game login - password sending security

Posted by on 15 July 2015 - 10:55 AM

If you can use HTTPS via an established library - go for it (with certificate checks and pinning).

Otherwise you can use e.g. OpenSSL to setup a TLS secured connection but there are plenty of things you can do wrong (e.g. not checking certificate validity).


Which language & libraries are you using for your project?

#5240290 Graphics options for DX9 2D sprite based game

Posted by on 14 July 2015 - 11:44 AM

If you have solid sprites (e.g. filled to the border) MSAA on/off & quality may make sense as well.

Also potentially having options for people with vision problems like color blindness etc. you could add special color modes so they can play the game better.

#5238143 HDR lightmap compression

Posted by on 03 July 2015 - 02:33 AM

If you want to support older hardware (or you need to) maybe this presentation about lightmap compression & optimization techniques from Bungie can be helpful:


They actually use two DXT5 textures to store SH coefficients (see slides 14 onwards).

#5236130 Read a text file from a .zip container

Posted by on 22 June 2015 - 03:48 AM

If you have garbage at the end of your shader:


Are you storing the 0 terminator with the string in the zip file? If not (likely) your buffer to read a text file should be allocated so it has space for one extra '\0' character at the end.

Otherwise basically all methods expecting c strings will read over the end of the string since there is no marker denoting the actual end.

#5226083 sfml health bar

Posted by on 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 ;)

#5174293 Compute shader values

Posted by on 17 August 2014 - 11:46 AM

Once you've written your computation results to a buffer (or texture) you can Map() the buffer/texture and read back the results.

Note that for some resource types (depending on the creation flags) you may first need to copy your results to a staging resource and then Map() this intermediate resource.


This link (even though for DX10) contains some pointers to related topics: http://msdn.microsoft.com/en-us/library/windows/desktop/bb205132(v=vs.85).aspx


One thing to keep in mind: If you read back the results in the same frame as the computation happens you will probably introduce stalls in your CPU-GPU communication which can lead to performance problems. So wait at least a frame before reading back data. Even better would be to issue a query after your Dispatch() call and then asynchronously ask DirectX if the query is finished so you know your computation you did before is finished as well.

#5167765 Vertex Shader responsabilities if I have Tessellation Shader

Posted by on 19 July 2014 - 05:41 AM

It helps to think of the shader pipeline as a set of refinement steps in my experience.


The earlier you can calculate something in the pipeline the cheaper it usually is (barring interpolator costs etc. so caveat empor).


If you have a calculation you can do in the vertex shader because it affects all triangle emitted by the tesselation the same then do it there instead of in the tesselation stage.

One example would be shader based skinning. Usually your vertices are affected by the bones and all tesselation generated triangles move the same based on the "basis" triangle coming from the vertex shader stage. This would speak for performing the skinning calculations in the vertex shader as it is called less often (and you benefit from the vertex reuse cache as well).


It always depends on what exactly you want to achieve. For example your vertex shader can transform all vertices to world space and then your tesselation stuff can do it's operation in world space. If on the other hand you have some calculation which needs to happen in object space (in the tesselation stage) you need to move the transform step further back.


The usual implementations I have seen have used world space for most operations after the vertex shader so it was safe to have TBN calculations etc. in the vertex shader stage. Often you can also find transformations to move your problem between the stages even if it doesn't look like that first.