scniton

Member
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

252 Neutral

About scniton

  • Rank
    Member
  1. C++ IDEs for Linux

    KDevelop, like every other IDE, only requires its dependencies on your development machine. It does not force you to add any dependencies for deployment. The LGPL licensed Qt option sounds like what you'd want.
  2. C++ IDEs for Linux

    It runs much better than eclipse here. "Bloated" can be subjective, the only way you'll know for sure is to try it. The OP specifically asked for Linux and didn't mention cross-platform. Furthermore, I don't think most people consider having to use different IDEs on different platforms a deal breaker.
  3. C++ IDEs for Linux

    My hands down favourite is KDevelop. Before finding KDevelop I had tried: * Code::blocks * codelite * QtCreator I haven't looked back since switching to it.
  4. [SOLVED] C++ compiling on Linux. (IDE for Linux)

    As others have stated, things are more diverse on linux. I personally love KDevelop for C++ on Linux (I used to use codelite.)
  5. max coord values and fp precision

    Yes, and depending on the range of height values (dy) a 64bit unsigned may not be enough for the intermediate results depending on the chosen representation. Using doubles is the easier path if it satisfies your requirements.   Converting to relative doesn't usually cause significant loss of precision. If the integer parts are big, then your objects are at extreme distances from the camera and so any differences introduced from converting from fixed point to floating point should be insignificant.
  6. I will outline a method I used in a similar situation, though in my case: - The camera/projection was not constrained: it could rotate in all 3 axes. - The tiles corresponded to a height map terrain. 1. Obtain a world-space representation of view frustum either by computing it directly with view&projection data or extracting it from a view&projection matrix. 2. Clip the segments that join the near plane to the far plane against a plane representing the minimum height of the tiles. 3. Discard the height component of the end points of the clipped segments (i.e. project the end points onto a 2d plane.) 4. With the above 2D points you can do the following interesting things: - Compute the 2D AABB which contains the visible tiles. - Compute a 2D convex hull containing the visible tiles. - From the convex hull compute a minimum 2D OBB of the visible tiles. In your case you will only want the 2D AABB and you will want to "round up" to integer extents so that you include all the edge tiles. If the camera is constrained as you have described then the 2D AABB, 2D convex hull and 2D OBB should all be identical.
  7. max coord values and fp precision

    Depends on the language / compiler: Assuming C/C++: - long long is present in all C99 and C++11 compilers - long long is often present in many popular compilers, possibly in extension form (e.g. __int64) Since I use gcc mostly, I've always just include stdint.h / cstdint.h and assumed the 64bit types were there. Some projects make things easier: http://www.boost.org/doc/libs/1_53_0/libs/integer/doc/html/boost_integer/cstdint.html https://code.google.com/p/msinttypes/
  8. max coord values and fp precision

    These cases are easily handled using either 32 bit integers (both signed and unsigned would work) or floating-point doubles. I personally prefer using integers / fixed point (for determinism/reproducibility/constant precision reasons.) You still need to convert coordinates to camera relative before sending them to D3D / OpenGL in these cases.   I would probably only resort to a sector based system if a 64 bit integer wasn't satisfactory.
  9. The effect is called "ribbon trail."
  10. Does anyone use fixed point math anymore?

      I think you still have a number of issues in your code that skew the result. One thing is that you do an float->int conversion for each int operation, this will likely slow down the int operations more then they should. The other is that you use base 10 for the precision, you should use base 2, and then a lot of muls and divs will become shifts.   The old code had these issues, I believe you're quoting the wrong person.
  11. Does anyone use fixed point math anymore?

    Those weren't exactly the result I would expect from quick test code, so I dove down into the code and made some changes to make it closer to a fair comparison. The test still has the issue that it assumes that +,-,* and / are equally common.   Modified code: http://pastebin.com/mvPR2snF (Note: some changes are purely for preventing the optimizer from removing entire sections.)   I tried it with multiple compiler flags:   Compiler: gcc 4.6.2 (mingw) Flags: (none) Typical result: 2.3s for floating point, 2.75s for fixed point (1.2 times slower)   Compiler: gcc 4.6.2 (mingw) Flags: -O2 Typical result: 1.3s for floating point, 1.65s for fixed point (1.27 times slower)   Compiler: gcc 4.6.2 (mingw) Flags: -O2 -mfpmath=sse -march=native   Typical result: 0.9s for floating point, 2.0s for fixed point (2.2 times slower)
  12. Does anyone use fixed point math anymore?

    In addition to the uses for fixed point already stated (e.g. large worlds,) it is also used to make code deterministic across machines/platforms/etc. It is possible to do this with floating point code but your milleage may vary (in my experience it is challenging.) One example of this is RTS games where inputs are broadcast to all clients and each client must update their state and stay in sync.
  13. Imported OBJ Looks Funky... :(

    In addition to what has been said about the indexing base, you code makes several assumptions about the content of obj file, in particular:[list] [*]Triangles only (i.e. always 3 sets of indices for faces, no more, no less) [*]Texture AND normal data is always present (i.e. face indices are always of the form: #/#/# ) [/list] I would check the file by hand to make sure these assumptions are not violated. Also, I'm not sure what you mean by changing the topology to triangle list, given your above assumptions the trivial way of rendering the parsed obj data is as a triangle list.
  14. glRotatef behaves strange

    Also, please post what you're using for your projection matrix (you suspect that it is related to perspective.)