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

japro

Members
  • Content count

    460
  • Joined

  • Last visited

Community Reputation

887 Good

About japro

  • Rank
    Member

Personal Information

  • Location
    Switzerland
  1. Wasn't checking if "glGetString(GL_VERSION)" returns null the way to do that? (null meaning there is no context...)
  2. OpenGL

    Wasn't OSX 10.9 announced to have OpengL 4.1? On current versions you can create 3.2 core contexts at best.
  3. Actual console APIs (curses?) tend to be very restrictive and not very portable depending on your requirements (color...). As a result a lot of "ascii games" like roguelikes or Dwarf Fortress actually run their own console emulation in OpenGL. Also its most likely faster. I can run a full screen "console" in OpenGL on my crappy netbook (GMA3150) at a cost of less than a millisecond per frame while doing the same in a console API is significantly slower.   btw. modern style dx/ogl are really just general purpose graphics APIs and using them for non 3D isn't overkill at all.
  4. For a monospaced console font just use a "spritesheet" Its fairly easy to then create a console by either instancing those or doing it via clever texture lookups on a fullscreen quad (see how libtcod does it for example).
  5. I feel it should be mentioned that if you want to dynamically allocate arrays you should probably use a std::vector to begin with. You can usually afford those two size_t for size and capacity...
  6. Yes, an actual 1/d^2 falloff for arbitrarily low d would be unphysical... but so is the concept of a point light source ;). Now if you have a spherical light source you can integrate the 1/d^2 over the sphere surface and will find that it is equivalent to having a point light source at the center of the sphere as long as you are observing from outside the sphere (edit: to clarify i think you have to integrate over the whole sphere surface, so this would be a "transparent" light emitter). Also notice that while moving arbitrarily close to a theoretical point light source the energy doesn't go to infinity, the energy density does... Generally when we speak of point light sources we mean that the radius of the light source is a lot smaller than the distance we observe from. If for example you had a linear light source then you will find a 1/d falloff and and if you have a light emitting plane there is no falloff at all (assuming the plane/line is infinite, or we are so close to it that we can consider it infinite for practical purposes)   Here you are mixing up relative and absolute measurements. You quoted "doubling the distance cuts the intensity by four"... now how do you go from doubling the distance to "2 feet"? Or more specifically, which distance did you double? Doubling the distance would mean to go from 1 foot to 2 or from 0.3m to 0.6m in both cases you doubled the distance and quartered the intensity...
  7. So? Doing 2D means you are using a orthogonal projection, or at least its equivalent to doing that. You can always treat 2D as a special case of 3D.
  8. You usually don't actually scale any objects, you just change the "camera transform".
  9. I don't even know what that means... So when i encounter a problem that is inherently mathematical I'm supposed to solve it in a "non formal way"? what would that be? Applying numerical solutions to everything instead of searching for a closed form solution?
  10. At least under linux I can use GLSL 1.0 on my Atom N550 netbook (which has said GM3150). Performance is obviously questionable at best.
  11. OpenGL will run on almost anything, but the feature level will vary. Intel based netbooks report as OpenGL 1.4 I think but support extensions that almost make them OpenGL 2 compatible (most of the missing extensions are multisample related afair). I think some of the AMD based netbooks even had OpenGL4 support but don't quote me on that.
  12. I can't remember where I read that but there was some article about building a "safe environment for kids" in a online game by having a sentence construction toolkit that only consisted of "safe words". Apparently within minutes of playtesting with actual children someone had come up with something along the lines of: "I want to stick my ice cream into your fluffy bunny"... so no matter how you do it time-to-penis is always finite and usually really short
  13. Which is what I found so infuriating about most OpenGL resources... They claim to teach OpenGL in their name but in reality try to teach Graphics Programming while wierdly working around the math and just happen to use OpenGL for that. But that is apparently the main audience I guess . So if you don't need someone to simplify the math for you and have some idea about how computer graphics work you are better off diving into the specs.
  14. The best way for me to learn OpenGL was/is to get examples from somewhere and cross reference them with the specification and reference pages. That is also why I wrote a bunch of examples myself (see my signature) that i regularly consult and copy from as a starting point.
  15. Also not ussing a quadtree at all is probably even faster :p. I don't get why everyone instantly jumps to quad trees for broad phase collision detection. Just grids/cell lists are often easier to implement AND perform better. Especially in the asteroids case where the domain is limited.