• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

scniton

Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

252 Neutral

About scniton

  • Rank
    Member
  1. 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. 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. 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. As others have stated, things are more diverse on linux. I personally love KDevelop for C++ on Linux (I used to use codelite.)
  5. 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. 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. 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.   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. 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. 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. 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. Also, please post what you're using for your projection matrix (you suspect that it is related to perspective.)