TrianglesPCT

Members
  • Content count

    40
  • Joined

  • Last visited

Community Reputation

599 Good

About TrianglesPCT

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. I converted some code to use tiled resources and noticed a few issues that I was wondering if anyone else knows anything about. First of all, the tiled resource is working and visually everything is correct-- but.. 1. It takes a long time to create the tiled resource. The call to CreateTexture2D to create the tiles(D3D11_RESOURCE_MISC_TILED) often doesn't return for a few seconds. There aren't any warnings or messages from the debug layer either, so this seems very strange. My resource is a texture2d array with 453 entries, each 2d slice is 2048x2048. I tried reducing the size to 256x256 instead and it still takes at least 2 seconds to complete the function call. 2. I set the lowest mip layer(128x128) in each slice to a unique mapping, and all of the rest of the tiles to a single default tile, I'd expect performance to be fairly good since this means that aside from the lowest mip, there is only 65k of texture memory being accessed, but it destroys my FPS-- going from 80 to 20. Visually it is correct, the tiles show as expected-- This is on a tier1 device and apparently mip maps under the tile size(128x128 in my case) do not work with texture arrays. So in the shader I check the distance and only use the tiled resource when near the camera, this helps but performance is still rubbish. GPU is an AMD 285x
  2. OpenGL Vulkan or D3D12?

     Is there any clear advantage with either of these?    Are vulkan drivers reliable on windows for all of AMD/Nvidia/Intel(ie not like OpenGL last time I used it)?
  3.  Well Unreal is based on java style design, and as such is slow, bloated, and hard to maintain(mountains of code, where each line does as little as possible).    Moving away from Unreal style engines would be a first step.   Also games that use the same engine seem very 'same same' to me, greatly reducing their appeal...     -Moving content creation to users -removing the endless hacks  -engines that scale to near 100% hardware utilization on whichever platform they happen to be running on -turing complete game worlds -original visual designs, not just replicating reality
  4. How phat is your v%#!&x?

    16 byte per vert   10/10/10/2 for position and 2 bits that aren't being used atm 10/10/10/2 for normal encoded into x/y. The last 12 bits aren't used atm  8/8/8/8 - albedo in first 3, shadow value in last  8/8/8/8 - roughness, spec, and ao. Last is unused.
  5.  If you use SoA format and have long enough instruction chains it isn't hard to get 4x for SSE and 8x for AVX   You can also do things in AVX/SSE such as  (FMA, rcp_sqr, rcp) which will outperform standard C++ in specialized cases, and easily go over 8x    I have a bunch of template math functions when can be invoked either with AVX types or standard C++ float. The difference is about 10x.
  6. Am I crazy for wanting to switch from Ue4 to Unity?

     UE4 tends to take longer to compile than an ideal C++ setup would allow.      Their custom build tool is slow, and in general, the code is over coupled and skews toward the broken Java model of inheritance    It is possible to have very fast iteration in C++, but it requires a lot of stupid work that smarter languages do for you.   If you are just working on a hobby game, you might be better off doing most of it in Blueprints, or as you said, using a different engine.
  7. What IDEs are recommended for Lua and/or Python?

    Writing lua: sublime, zerobraine Debugging lua: decoda or BabeLua
  8.  Many of the complaints in the paper are out of date( as the follow up comment often shows), why include that stuff?   Wanting the language to remove global new is abit silly     Regarding customizing vtables, I think typeclasses would be an improvement over the inheritance crap we have today for runtime polymorphism, so a proposal for that would be nice   I think the biggest improvement for games in c++17 would be modules, most of the rest of this stuff like flat_map we can already do ourselves(although it would be nice to standardize it)   Maybe we need to switch to Rust, it has almost none of these problems..            
  9. What Are You Working On

       Thanks, it is voxel based    Yah the colors don't look real, just fanciful nonsense.
  10. What Are You Working On

       Thanks,    Yes it is my own engine/renderer.  I do use some 3rd party stuff like TBB.     It is designed to generate everything on the fly.    I have not uploaded any videos
  11.  TBB is solid, it doesn't have some of the features C# has like 'await', but it does have a task scheduler    TBB has a PPL translation layer if you for some reason need that
  12. What Are You Working On

    Not sure what I'm making exactly, but here are some random pics Probably 90% C++, 10% Lua, current renderer is D3D11  
  13. Client systems: Cpu, Gpu, Memory, Hd, or Internet

     Super CPU: many applications are memory bound, but mine happens to be compute heavy.    CPU compute is preferable to me since there is less latency between the serial and vector code & you don't have to write against some terrible GPU API.     And presumably this super CPU has more & better cache.  Wider vector lanes, many core, and more instructions per cycle pls.
  14.  std::vector<bool> happens to be implemented using bits instead of bytes, so you might as well use that instead of hacking in your own implementation on top of it.
  15. LOD in modern games

     I am wondering. When it says a card supports 1/2/4 primitives per clock..   Does this mean that those primitives must be within the same 8x8 block? Or the exact opposite? If I'm rendering pixel sized triangles, and 4 of them land in the same 8x8, can it only do one at a time?     Also I'd like it if future GPU's might offer the ability to disable the mandatory 2x2 triangle blocks(used for derivatives), since not all shaders require them, and in particular the stuff I'm working on does not;)    I have a project that supports a variable # of primitives per pixel. From testing, it does drop significantly as I approach 1/1 ratio, although it is still playable. Since the GPU screws me with the 2x2 quad thing, for near 1/1 ratio scenes I've found that doing super sampling isn't very expensive ;0