marcjulian

Members
  • Content count

    110
  • Joined

  • Last visited

Community Reputation

959 Good

About marcjulian

  • Rank
    Member

Personal Information

  1. 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 :)
  2. 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: http://serverfault.com/questions/137348/how-much-network-latency-is-typical-for-east-west-coast-usa
  3. 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. 
  4. 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 
  5. Until the developer is here I would recommend their slides on their rendering tech:   http://advances.realtimerendering.com/s2015/rad_siggraph_advances_2015.pptx   (See here: http://advances.realtimerendering.com/s2015/index.html and the other presentations here: http://www.readyatdawn.com/presentations/ )
  6. Well usually physics engines don't use a simple line test but sweep more or less complex shapes to get accurate hit detection in that case. Bullet for example seems to switch to a swept sphere for CCD instead of using the original shape to reduce cost. ( https://www.panda3d.org/manual/index.php/Bullet_Continuous_Collision_Detection )   However it probably depends on your use case :) If you can get away with a simple ray cast then it shouldn't be too bad considering that this is something physics engines are optimized for.   The PhysX manual - see the advanced section here: https://developer.nvidia.com/sites/default/files/akamai/physx/Manual/Advanced.html also contains interesting tidbits.
  7. What you described there has actually a name 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/
  8. I don’t believe there are any API’s that require index buffers, and OpenGL ES * does not.   If you take a naive array of vertices then triangle strips are only faster generally speaking if the resulting index buffer is 75% or below compared to the original size. You should instead sort the vertices by best cache usage, which in my experience has yet to produce slower results than not. From there, if you then generate a triangle strip, my experiments show it only fruitful to keep the strip if the resulting index buffer is 25% or below (basically never). L. Spiro   Actually both draw methods in GLES 2 need indices - glDrawArrays uses the indices from the bound array and glDrawElements gets the indices as an argument. See https://www.khronos.org/opengles/sdk/docs/man/xhtml/glDrawArrays.xml for example. It says the index type needs to be unsigned byte or unsigned short - it doesn't look like the indices parameter is optional. And actually the documentation for draw elements that you linked states the number of indices to draw, not vertices..   And I know for a fact an API under NDA which definitely has no non-indexed draw capability ;)
  9. 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.
  10. 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?
  11. Well with what DX9 gives you you will notice MSAA only if you have sprites which are colored to the edge of your triangles you use to render them indeed. With DX10.1+ you could actually write a new coverage mask when alpha testing to get smooth inner edges in the sprite. So with DX9 it depends a bit more on how your artwork looks if MSAA will give you any advantage.   Edit: on the refresh side of things - an option for a 30Hz refresh can also be helpful as a battery saving technique for laptops etc.
  12. 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.
  13. If you want to support older hardware (or you need to) maybe this presentation about lightmap compression & optimization techniques from Bungie can be helpful: http://halo.bungie.net/images/Inside/publications/presentations/Lightmap_Compression_2008_02_22.pptx   They actually use two DXT5 textures to store SH coefficients (see slides 14 onwards).
  14. 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.
  15. 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