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


  • Content count

  • Joined

  • Last visited

Community Reputation

130 Neutral

About sdaq

  • Rank
  1. Thank you SimonForsman and dpadam450, I appreciate the explanations. I have not really done much profiling with gDEBugger but when I noticed that it was warning me about the percentage of batches with a single vertex I assumed something catastrophic was happening to our performance. In one scene we had 20 fps and it did not matter that I had removed all the glBegin/glEnd calls.
  2. hi all, looking for ideas on how to do this... we have a Java GUI that needs to be able to make some function calls to a C++ library. Any help would be appreciated! Thanks.
  3. [quote name='dpadam450' timestamp='1330383989' post='4917208'] I batch of 5000 verts is way faster than 5000 batches of 1 vertex. [/quote] I agree, but SimonForsman seems to be saying that batching only helps the CPU and does not help the GPU.
  4. okay... then the benefit of batching is only reducing calls on the CPU side? there is no benefit on the GPU side?
  5. i'm confused now. I get that draws will take the same amount of time regardless of how many primitives there are. but are you are saying that reducing the number of batches only reduces the amount of work done on the CPU side? how is it possible that the GPU works the same amount to execute 5000 batches with one vertex as 1 batch of 5000 verts?
  6. I imagined that removing 93.58% of the batches would amount to a nominal improvement in framerate, but is it possible for 93.58% of the batches to run in only 10% of the total time to execute all render calls?
  7. update: just by chance I decided to go throught the code and comment out every instance of glBegin/glEnd and sure enough that was enough to cease submitting batches of a single vertex. Despite the catch, my framerate has not improved! oh well...
  8. hello world, gDEBugger Statistics and Redundant Function Calls Viewer reported to me that 93.58% of my batches have 1 vertex. I'm using OpenSceneGraph and I don't feel like diving into the OSG renderer source and rebuilding... Is there an easy way for gDEBugger to tell me what effect is causing this? E.g. can I just break on the draw that only has 1 vertex and look at the shader it is using? Thanks!
  9. [quote name='Garra' timestamp='1318523077' post='4872236'] Alright, well I guess I'll give it a shot! With Assimp you only have to make one mesh loader, and then your able to load in any model that Assimp supports without having to modify that code correct? [/quote] it's super straight forward, just follow this link: http://assimp.sourceforge.net/lib_html/usage.html inspect the aiScene object after importing with a debugger... you can see that it has a root node, a transform, and a set of arrays for the meshes, materials, animations, etc... the root node is a scene graph that has children that index into those arrays. basically you just traverse the tree and copy out the information that you need into your own data structures. check out the source, it comes with a very simple opengl demo. good luck!
  10. [quote name='Garra' timestamp='1318518510' post='4872213'] I'm debating on rather to use Assimp or create my own MD5 model loader. I've been studying up on MD5 models and the main thing I'm not sure about with Assimp is if it has the ability to attach weapons to the player model.. since the game it will be added to is a FPS. Could someone possibly share some insight on the subject, it would be nice to be able to use multiple model formats without having to code multiple loaders. [/quote] I don't think you can modify the scene that is returned by Assimp after importing an MD5. I would use Assimp to read in the MD5 into my own scene graph hierarchy, find the transformation for the weapon and attach it that way. Either way you need to import the MD5, you may as well use Assimp. Funny thing, I wrote a small test program a few days ago to read in the Hellknight.md5mesh and several of the animations... worked like a charm for me
  11. Hello! I need to make a little buoy wake effect around the buoys that are floating in the water. I have two parameters for velocity that will control it. looking for suggestions and recommendations for literature or even expert advice. Thanks!
  12. another relevant post I found. hope this helps someone in the future: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=263583#Post263583 [quote] For a proper projection, an object that is twice as far away appears half as big in each dimension, so what you want is the size in pixels being the quad size multiplied by some constant, divided by the view space distance: size' = size * C / D C is the size in pixels of an object of size 1 at distance 1 in view space, and usually equals the (0,0) component of the projection matrix multiplied by half the screen width. The formula used for the attenuated point size is size' = size / sqrt(a + b * D + c * D²) with (a, b, c) being the point distance attenuation parameters. With a = b = 0 you get this: size' = size / (sqrt(c) * D) So what's left to do is to figure out the value of c. C = 1 / sqrt(c) c = 1 / C² And, as mentioned above, C is the first component of the projection matrix multiplied by half the screen width. [/quote]
  13. update, I found some information related to the opengl function glPointParameter which seems to be relevant: [quote] void [b]glPointParameter[/b]{[b]if[/b]}(GLenum [i]pname[/i], GLfloat [i]param[/i]); void [b]glPointParameter[/b]{[b]if[/b]}[b]v[/b](GLenum [i]pname[/i], const TYPE * [i]param[/i]); Sets values related to rendering point primitives. If [i]pname[/i] is GL_POINT_DISTANCE_ATTENUATION, then [i]param[/i] is an array of three floating-point values [i](a,b,c) [/i]containing the constant, linear, and quadratic coefficients for deriving the size and brightness of a point, based upon eye-coordinate distance, [i]d[/i]: [i]derivedSize = [/i][i]clamp([/i][i]size*sqrt(1/(a+b*d+c*(d^2))))[/i] If [i]pname[/i] is set to GL_POINT_SIZE_MIN or GL_POINT_SIZE_MAX, [i]param[/i] is an absolute limit (either lower or upper bound, respectively) used in the previous equation to clamp the derived point size. If multisampling is enabled and [i]pname[/i] is GL_POINT_FADE_THRESHOLD_SIZE, then [i]param[/i] specifies a different lower limit ([i]threshold[/i]) for the size of a point. if [i]derivedSize[/i] < [i]threshold[/i], then the factor fade is computed to modulate the point's alpha, thus diminishing its brightness: [i] fade = (derivedSize/threshold)^2[/i] [/quote] I think I want to use this formula to scale the textured quad and modulate the brightness.
  14. [quote name='Buckeye' timestamp='1297195783' post='4771492'] [quote]modulate the alpha channel of the texture with?[/quote] No, modulate the color itself. The physical navigation light isn't transparent, just brighter or dimmer. EDIT: [quote]keep the size of the quad constant [/quote] Probably. I would think you'd want at least several pixels involved, but the physical size of a navigation light beyond a certain distance won't be relevant. Scaling the quad will change the number of pixels, but doesn't change the intensity of the color. [/quote] I appreciate your replies but I am still confused. Navigation lights are commonly viewed from up to 35 kyards away. at this distance the ship itself wouldn't be more than a few pixels, and the lights themselves will not even generate a fragment to be shaded. that is why I was thinking to scale the quads themselves so that no matter the distance, we always have at least 1 fragment to shade. I think I really want to know how to parameterize the quads scale as well as the color by the view and distance, and incorporate the inverse square law of intensity somehow. I agree with what you are saying but this size limitation seems to be throwing a monkey wrench in my plans.