cgrant

Members
  • Content count

    403
  • Joined

  • Last visited

Community Reputation

1825 Excellent

About cgrant

  • Rank
    Member
  1. Any hope for Indie developers?

    There is always hope... Given most of the post I see on this and other forum especially in the technical dept that usually goes.." I'm working on this game...but how do I do XYZ " where XYZ are sometimes fundamental concepts that should have been acquired before even going down that road, I'm going to go off on a limb and say there are plenty people out there that have in their head some "get rich quick" indie scheme. Not saying this is your approach as no knowledge of your intent, but if you enter the field with some "get rich quick" scheme in mind, then prepare to be disappointed. Lets say you make a game and its not doing so well sales wise, we all want to recoup our development cost, but at same time, you have to be realistic or set realistic goals. If you are going to dwell on sale figures vs making the games you love, then to answer your question, all hope is lost. Whenever becomes more about money rather than passion, then all hope is lost...my 2cents..
  2. How to save cooked geometry data in PhysX?

    Yes..that is correct. As long as the platform doesn't change...ex going from PC to ARM etc..your serialize data should work on the same platform it was cooked on. So I don't understand the comment in regards to the cached file is better generated and used by one user.
  3. you need to used a toolchain file that specify the configuration to use as I found this was the easiest way to do cross-compilation/non-standard toolchain. Ex This is the content of my basic toolchain file for Android x86 build set(CMAKE_SYSTEM_NAME Android) set(CMAKE_SYSTEM_VERSION 16) # API level set(CMAKE_ANDROID_ARCH_ABI x86) set(CMAKE_ANDROID_NDK<Path>/Android/android-ndk-r11c) set(CMAKE_ANDROID_STL_TYPE gnustl_shared) set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang) If you need further detail see the CMake docs in regards to using toolchain files. Also I remove the actual path for the variable CMAKE_ANDROID_NDK, but this should not have any impact as this was just for illustration..Please do not just copy and paste without consulting the CMake documentation.
  4. glut only runs at hd? can it run at 4k?

    DId you try resizing the window ? If so, did it resize to the maximum size of the desktop? Are you assuming that GLUT will open up a fullscreen window by default ?
  5. Virtual Memory

    Like others have pointed out before and I suggest you take heed..You are trying to do the job of the Operating System...if thats the case why are you even using one? Why not just write your own OS that more secure than every other OS out there. Its the job of the OS to virtualize memory( with HW support) and to manage swapping to and from a pagfile. Just like its next to impossible for an errant program to write into the memory owned by your program, this also extend to the swap file so whatever security concerns you have are unwarranted.
  6. You are still assuming that the decrement operators are actually atomic...like I mentioned I did not look at the spec, but iirc before the standard C++ supported atomics, the Boost C++ atomic template operators were not atomic, one would have to use the compare and exchange methods to guarantee atomicity. This looks like the approach the re-write too.
  7. Seems like you found a workaround instead of a comprehensive solution. If you are going to use atomic variable, then make sure they are being used effectively..with that said and without checking the documentation of std::atomic, if the -- operator is not atomic they you'll have race conditions like Kylotan pointed out.
  8. The question is rather vague as no use case was mentioned...mhagain highlighted some good points to factor in, but overall I'm inclined to think you are looking for specific answers.
  9. How to save cooked geometry data in PhysX?

    There seems to be a disjoint in the question you are asking and the information used for illustration. Maybe the following will help clarify what you are trying to achieve. 1. If you are cooking high poly mesh, I would refrain from doing so as a tri-mesh is not optimal for PhysX so I would try using convex meshes where appropriate. With that said I don't recall if PhysX limits the number of vertices in a tri-mesh, but it does for convex meshes. Runtime cooking of a few convex meshes is not that slow, but I would image the cost would add up if you are cooking a lot of meshes. The trade-off here would be whether or not you have a hard load-time requirement. 2. When you cook any representation, be resulting binary stream can be serialized to disk and reloaded. This is where I got confused as the 2 snippets posted just shows 2 ways of creating a triangle mesh representation, not the offline/runtime method as you would think. The first snippet posted would be the same offline/runtime. The only difference being with offline method, some external tool is used to cook the data using the same method as you would at runtime. However, instead of just turning around and consuming the buffer after cooking, the tool would save the stream to disk. Whenever the app is run, the cooked data is read from disk into a stream and used to create the tri-mesh representation. See the documentation regarding PxPhysics::createTriangleMesh Hope that helps clarify the issue.
  10. Source code organization is not enforced by the language. This is an organizational decision. Still doesn't answer your question, but one can only speculate why your compile time is so slow. In my experience I find that heavily templated code usually compiles much slower than the non-templated version. I have no experience with UE4 source code so I don't know if this applies.
  11. How are point clouds used?

    The first question you should ask yourself is why do you think points clouds is the complete solution? To answer that question you and only you can do the cost-benefit analysis as no one else knows your use case. A part of that is knowing how the chosen tech works in-depth, again no one can tell you how, they can just point you to resources. I'm saying this because you mention this. Seems like you are expecting specific help when the only one who knows the use case is you.
  12. At the end of the day, vertex buffer and index buffer is just another buffer with semantics attach..as pointed out above I think vertex caching is one of the biggest reason for the having this distinction still as without this, the API will have to be able to flag a generic buffer as being cacheable..
  13. If the amount of light is fixed, then the static indexing for arrays shouldn't be that much of an issue.
  14. Just to add to what Hodgman said, you cannot treat the GPU like a general purpose CPU as you will quickly run into some limit which are imposed for very good reason. If you data is not in buffers, then changes are they have to be stored in registers which are a limited commodity on any hardware. Long story short, take a real deep look at what you are trying to accomplish and map that to a GPU paradigm instead of a CPU one.
  15. #4 should work well, easy way to tell if this will work well for you, is if the vertex morphing is at all noticeable..