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

gold

Members
  • Content count

    156
  • Joined

  • Last visited

Community Reputation

412 Neutral

About gold

  • Rank
    Member
  1. I forgot that bindable uniforms are not part of GL3, but you can use vertex textures. On this generation of hardware, vertex textures are very fast - the shader units are unified so anything you can do with textures in the fragment stage can be done in the vertex stage, too. The InstanceID therefore can be used to generate texture coordinates.
  2. Instancing may be performed with the ARB_draw_instanced extension, which didn't make core 3.0 but will likely be promoted in the next release.
  3. Quote:Original post by Peti29 - immediate mode. I understand that it's hard to optimize in the driver. But to kill it entirely? IHVs can serve you better by focusing development and maintenance resources on modern features instead of emulating legacy features, when you can do so more efficiently by focusing on your own usage and not every possible corner case the spec allows. Quote:- "fixed function vertex processing", like: VertexPointer, NormalPointer... huh??! This means no more matrix stack, lighting, etc. You'll have to write your own vertex shader or write/find a utility library which emulates the legacy vertex pipeline. Quote:- LineWidth: why? Apparently some vendors hardware doesn't support wide lines natively, and they don't want to emulate it.
  4. The number one rule is: don't call anything that starts with Get. The GL is designed for information to travel one direction: from the app to the hardware. Gets force a pipeline stall. Likewise, there is almost never a good reason to call Finish. Flush is OK but usually unnecessary, and flushing too often can slow you down.
  5. In-band just means it executes serially with other commands in the command stream and therefore requires no sync/stall. In plain English: its fast.
  6. OpenGL

    Quote:Original post by GamerSg Just out of curiosity, when a IHV releases new hardware, do they not have to implement drivers for DX 7/8/9/10? Else older games coded in DX7 will not work on newer hardware. Microsoft provides a shim which layers older versions on the more recent, so IHVs don't have to support them all. Older titles run fast enough when emulated on newer hardware.
  7. You should be able to copy the window depth buffer to the FBO depth buffer using glBlitFramebuffer() (ARB_framebuffer_object or OpenGL 3.0) or glBlitFramebufferEXT() (EXT_framebuffer_blit). 1) Create a depth texture or renderbuffer with the same depthBits as the window depth buffer. 2) Bind the default framebuffer (0) as the READ_FRAMEBUFFER. 3) Bind the FBO as the DRAW_FRAMEBUFFER. 4) Blit the depth buffer: glBlitFramebuffer(0, 0, W-1, H-1, 0, 0, W-1, H-1, GL_DEPTH_BUFFER_BIT, GL_NEAREST);
  8. One form of render-to-vertex-array that can be done on older hardware: render to offscreen memory (e.g. a FBO), then ReadPixels into a PBO. Then bind the same buffer as a VBO. While this requires copying the data to the buffer, the copy can be performed in-band and without requiring a round trip to the host. Thus it should be very fast.
  9. By the way if you use FBO you should switch from the EXT to the ARB/3.0 version. It adds two restrictions but removes others. The new restrictions are: - No more user-generate names. You must call glGenFramebuffers() - No more sharing of the FBO between contexts. The FBO may be used only with the context on which it was created. However if you really need to render to the same buffers from multiple contexts, the buffers themselves may still shared and bound to context-specific FBOs. New functionality includes: - Mixed size attachments. For example you may now share a single large depth buffer across many different sized color buffers. - Mixed format attachments. You may now attach e.g. an RGBA8 image to COLOR_ATTACHMENT0 and a RGBA32F to COLOR_ATTACHMENT1 and write to both from a single shader. (Note that this might generate FRAMEBUFFER_UNSUPPORTED on older hardware.)
  10. Depends on the hardware you wish to target. If you want to support older cards (e.g. GeForce 7x00 series) you'll need to stick with 2.1. If you want to take advantage of the functionality on newer cards (e.g. GeForce 8x00) you can run version 3.0. But... There is a lot in common between these versions. Really, you can conditionalize your code based on the available version and support both generations of hardware. Some of the new 3.0 functionality is even available under 2.1 with the same API (e.g. FBO and VAO)*. 3.0 is really 2.1+. *This is something new. The ARB made extensions for 2.1 which expose a subset of the core 3.0 functionality. Because the functionality is core, and will run under 2.1 unchanged, the API looks like core, i.e. there is no ARB suffix on the function names or enumerants. This was done to simply the lives of developers who want to support multiple generations of hardware with common code.
  11. Short answer: it cannot be done. The ARB seriously considered supporting this and chose not to, at least not at this time. The good news is that FBO in 3.0 allows mixed size attachments so you may share a depth buffer for offscreen rendering to color images of different sizes.
  12. OpenGL

    Quote:Original post by MARS_999 Please clarify this, are you saying the GL3 model that everyone wanted would be difficult or the existing API is going to be difficult and therefore we are dumping the old crap!! :) I'm saying the problems in the legacy object model which Longs Peak attempted to address are still there in 3.0, and this affects functionality which the ARB might like to expose in the future. At this point I know better than to make any promises on behalf of the ARB.
  13. OpenGL

    Quote:Original post by stimarco Quote: 3) The object model. We talked in lengths about this, so I won't repeat it here. But I'd still like to point out how extremely disappointed I and many other people were about this, excuse my language, complete fuck-up. I think it's clear that pragmatic issues forced the ARB's hand here. I'm guessing that simply dumping 2.x and starting afresh was unfeasible as it would require companies like ATI, NVidia and Intel to maintain both 2.x and 3.x drivers. As OpenGL is a niche API, this makes little sense: ATI, NVidia and Intel make their money from consumer graphics products, which means DirectX gets the bulk of the attention. Making OpenGL even harder to support over the near-term was never going to go down well with the IHVs. Actually some IHVs were looking forward to making a clean break with the past. Support for existing APIs is a (largely) solved problem, but continuing to aggrandize the existing model means continuing to modify (i.e. break) existing code. And, some of the new and upcoming functionality is really difficult to integrate with the existing object model.
  14. OpenGL

    Adding to what Rob said, if you change no code you will continue running on 2.1 as long as its supported. Given that 100% of existing applications run on a base which is compatible with OpenGL 1.0, I can't see IHVs dropping support anytime soon, although some legacy features might become layered (i.e. slower) for compatibility. If you write a few lines of wgl code and create a 3.0 context, you can use the new features *and* 100% of your rendering code will continue to run. If/when a new version breaks compatibility and you can still use new features without rewriting old code. You can create both a legacy and an incompatible context and call MakeCurrent when you transition between old and new code. [Edited by - gold on August 23, 2008 5:45:31 PM]