• 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.

Nairou

Members
  • Content count

    585
  • Joined

  • Last visited

Community Reputation

430 Neutral

About Nairou

  • Rank
    Advanced Member
  1. It's mostly a hope at this point. I'm still planning the project, haven't started coding it yet. And I do most of my development on Linux, but will build on MSVC when it's far enough along to get other people to test it. So my hope is that C11 support will have improved some by then.   If it hasn't, then there's always MinGW, but I'm trying not to rule out MSVC at this stage.
  2. It has potential, but the LGPL license and the fact that it only compiles with GCC (not MSVC) make it unattractive for my project...
  3. Good idea. If I don't end up finding an existing library, I might look into doing that...
  4. Unfortunately, GLM itself is C++ only, not C.   This is the problem I'm having, all of the good ones I know of are C++ only. :)
  5. Good points. What I'm looking for would be primarily for use in 3D calculations, for 3D games. So just small vectors, small matrices, and quaternions. And operations like building translation/rotation/viewport matrices, generating camera projection/ortho matrices, quaternion interpolation, etc.   I know with C++ the math libraries can do operator overloading to make them feel natural, and I wouldn't have any of that in a C library, but that's fine. Even if the library was limited to integers and floats (and didn't mix them), since it doesn't have the template abstraction, it would be fine. When you're doing matrix operations with the goal of feeding it to the GPU, there isn't a lot of variety needed.   Simple enough set of requirements that I could probably write my own library if I had to, but I don't have the math optimization experience necessary to make the library as fast as it would need to be.
  6. There are lots of forum topics about C++ math libraries (like CML, GLM, Eigen, etc.), and I've used many of them in past projects.   However, my next project is going to be C (C11), not C++, so now I'm looking for a good C math library. I'm not having much luck finding one that isn't just someone's pet project.   Anyone have recommendations for good C math libraries that have been battle-tested in real projects?  
  7. Thanks for the reply. I actually had that thought as well, but got stuck trying to implement it. I'm pretty sure I could create a forward vector and use matrices to rotate that by the x and y angles, and then extract the position. But I don't know if there is a more direct way to convert it. I thought I could use the angles directly and just normalize them to get a point, but if the camera looks directly at the point then the angles are zero, and I get an invalid result doing that.
  8. I've got a simple test program with a camera within a cubemap (skybox). You can look around, and it feels like you're in a 3D room, but really it's just a cubemap image.   Now I want to draw a point (well, ultimately, a large number of points) on the screen, such that it appears to be anchored at a point on the cubemap. For example, if the cubemap is of a room, then I want to put a point on the "wall", and have it appear to be stationary when you look around.   Given that there is no actual environment, it's just a cubemap, the points I want to project are represented as x/y rotational angles, rather than absolute 3D vertices. I tried calculating the position manually, using the camera x/y angles and interpolating across the screen. However because the cubemap is distorted at the edges due to the camera's projection matrix, my linear calculations don't match up, so the point appears to wobble as you look around.   I know I need to incorporate the camera's projection matrix to get it to appear in the correct position, but I'm not sure how. I'm using the CML math library, and I noticed it has a project_point() function, but it works with absolute 3D coordinates, so I don't know how that helps me when starting with angles instead of coordinates.   If someone could get me pointed in the right direction, I would appreciate it.
  9. Thread is a bit old, but I wanted to point one thing out. You mention several times the desire to remove heavy programming and make the project as light on programming as possible. I assume this is with the intent of making things "easy" for whatever programmer you end up working with, in hopes of getting work done.   While that is a good idea when trying to do the programming yourself or use an existing framework, I don't think that is a valid concern when bringing in an experienced programmer to work on the project with you. Most programmers (especially those in games) do programming because it's what they enjoy. If we didn't like programming, we'd be doing something else. So reducing the amount of programming required is, to some degree, making the project more boring from our perspective. With less programming, you have less features, less options, less of a game to be proud of in the end. You don't want to cut down on programming effort for it's own sake. That's like asking an artist to help with a game that only needs drawings of stick figures in crayon. Where's the fun in drawing that?   Instead, have a clear idea of what game you want to make, and all of the necessary features and details. Think it through, don't be overly vague. If a programmer likes it, they'll do the necessary programming to make it happen. Stay focused on what's important, the end result.
  10. OpenGL

    I use freetype (the original, not freetype-gl), and rasterize my fonts to a texture when my game start up. Then to draw text on the screen, I just generate quads with the font texture, one character at a time. Doesn't require anything special, and works on all platforms.
  11. What is the state of the art in terms of shadow rendering? My target is OpenGL 3.2, using a deferred rendering pipeline, if that matters.   It's been years since I looked into shadow rendering, and at that time there were numerous techniques available, from stencils to the various shadow mapping methods. At that time, rendering shadows required separate rendering passes, controlled by the CPU. But then recently I saw a demo where a scene was rendered entirely on the GPU, including shadows. I have no idea how that would have been accomplished, or if it is even a reasonable thing to do (beyond a tech demo).   Given the large amount of old info on the internet, I'd like to learn what methods people are using these days, and how much of it can be pushed to the GPU (assuming my target OpenGL version supports it).
  12.   But I'm assuming you can't have both textures bound for this to work, right? If you updated texture 0, and the shaders knew to only sample from texture 1 this frame, would the GPU really know that texture 0 wasn't accessed? Or would you still end up with a synchronous flush from updating texture 0?
  13.   Very interesting, I didn't know textures could be double-buffered. Do you have any links on doing this in OpenGL?
  14. How well does OpenGL (3.2, if it matters) handle modifying or replacing textures that have already been uploaded to the GPU?   I always had the impression that messing with textures was always much more expensive than replacing VBO data, even if the texture is far smaller in byte size, but I'm starting to think this might not be the case.   Is there perhaps a list somewhere that shows what sort of operations are most expensive in OpenGL?   For context, I'm working on a terrain system where the terrain colors can change frequently. I figure I can either do texture mapping, and modify the texture pixels, or put the color in the terrain vertices and rebuild the VBO for each change. I'm accustomed to continually rebuilding dynamic VBOs for other tasks, but in this case I am thinking that a texture would be a lot less data to upload than the block of geometry.  
  15. Say you have an arbitrary 3D line (not aligned to any axis), and a short distance away, a vertex. Is there a way to calculate what point on the line is closest to the vertex? I've seen posts that demonstrate how to find the shortest distance, but I need to come up with an actual 3D vertex that exists on the line. For context, I'm trying to move character joints with the mouse. The line is a ray cast into the world from the mouse pointer, from the arbitrary angle of the camera, and the vertex is the character joint that I'm trying to drag around.