• Content count

  • Joined

  • Last visited

Community Reputation

1828 Excellent

About cgrant

  • Rank

Personal Information

  • Interests
  1. DirectX Texture Tool

    I would recommend AMD Compressonator.
  2. My post wasn't mean to be a critique, nor a deterrent( was just pointing out a few salient issue ), nor can I tell you what to do I can only make suggestions. How can I be correct about you, when I don't even know who you are? I would suggest get comfortable with the toolchain first before even thinking about the next step.
  3. I guess my question are why are you so hell bent on programming a console ( portable or not ). Getting the toolchain working is part of the battle and not a simple one. If you are not familiar with cross-compilation and the required setup as other have mentioned then you are going down a path that will lead to you getting frustrated and giving up before you even start. Once the toolchain is configured correctly, then you have to now worry about the hardware and all its idiosyncrasies. I would suggest start of with smaller task before diving into the deep end of the pool. Have you ever worked with the GCC toolchain ? If not, get familiar with it first. Have you ever done any cross-compilation ? If not start cross-compiling a few simple application and then testing them on the target system.
  4. Importing .OBJ model to OpenGL

    So today you can read .obj, and if you have to support another format? Apart from being a lesson in how to do this on your own, why would you want this responsibility. If its education then by all means I recommend doing it, other than that find the right tool for the job. What exactly was the issue with Assimp? It could have simply being the tutorial you used and not Assimp itself. You should be able to just grab the Assimp documentation and use the library to do whatever you need which is just the basic loading. I've been using Assimp to load models for a few years now with no problem. Also be aware that Assimp does NOT load textures you will also need another library for that or roll your own. As for organization, offering suggestion without use case makes it hard to offer help. It would definitely help to abstract a mesh and all its contents. But again, use case would dictate organization.
  5. What Hodgman said. Plus there is the tendency to write GPU shader code as if its equivalent to CPU. Though programmable, GPU architecture and programming paradigm have subtle differences than CPU. If you think about this, crashing aside...why would you want to write code like what was posted, keeping in mind that this code will be execute per fragment...thus as the resolution of your render target increase, so does the cost of this shader.
  6. What am I not understanding about programming?

    The question you really need to ask yourself is do you really understand the fundamentals?...and by fundamentals I mean the very basics, variable type, function, function params vs arguments, loops among other things. If you really do, then simple text base programs that accept input and print something out to the console etc should be no worries. Then work your way up to more complex problems. If you can't make it past the first step of the simple programs, then you are working up for disappoint if you proceed to more complex problems. This should be an indication that you really have not grasp the basics. As other have mentioned before, you just don't get good at something by 1. giving up or 2. dreaming. you have to do it over and over until you've mastered it or at least at a level of comfort where you know it like the back of your hand.
  7. Normalizing normals in VS

    How could it not be correct considering that your VS output are interpolated so each fragment will received this interpolated value. If you are transforming your normals with matrices having non-uniform scales or any scales for that matter is asking for trouble..ex..why doesn't my lighting looks correct. Rotation should be the only thing affecting your normals.
  8. Another thing to keep in mind is do NOT expect the same level of performance for each OpenGL implementation, but it looks like you are on the right track as you did mention testing on different GPUs. Also drivers may have bugs here and there, but they are most likely tested more than your code. This leads back to what Matias mentioned above. There is the possibility that a fast path on Nvidia/Intel may not be the same on AMD. In fact from my experience I would use AMD as the base-line when developing when you can as there adhere more to the spec than Nvidia. Long story short, you should take a deep look at your code using some form of profiling tool before you can conclude/assume its a driver bug.
  9. 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 2cents..
  10. 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.
  11. 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.
  12. 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 ?
  13. 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.
  14. You are still assuming that the decrement operators are actually 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.
  15. 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.