• 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

127 Neutral

About buddysk

  • Rank
  1. OpenGL

    I only have one glDepthMask call at the beginning, and I set the comparison function to GL_LEQUAL. I now tried different shaders for visualizing the depth: One vertex shader A only calculated the gl_position. The other vertex shader B also assigned a texCoord attribute to a varying. This is more or less the only difference between!! While shader B shows the artifacts, shader A doesnt .... I can switch between the two shaders and see the artifacts present a not ... Really seems to be some kind of memory thing?!
  2. OpenGL

    Thanks for the answers! @Katie: I currently have no other android device for testing. At the moment I am running it on a Samsung Galaxy S i9000. @Olof Hedman: I was looking for glClear in my whole project code. I am only calling it once, in onDraw and in the form of: [source lang="java"]GLES20.glClear(GLES20.GL_COLOR_BUFFER_BIT | GLES20.GL_DEPTH_BUFFER_BIT);[/source] Sadly I dont know how to log all gl calls, in order to verify there is no implicit glClear inbetween. [source lang="java"] _glView.setDebugFlags(debugFlags | android.opengl.GLSurfaceView.DEBUG_CHECK_GL_ERROR | android.opengl.GLSurfaceView.DEBUG_LOG_GL_CALLS);[/source] seems not to work for OpenGL ES 2.0, and the [url="http://developer.android.com/tools/help/gltracer.html"]GLTracer tool[/url] is only supported by Android 4.1 and higher. I will try to get some other device to test it on.
  3. OpenGL

    In the onCreate method of my Activity I only call [source lang="java"]_glView = new GLSurfaceView(this); _glView.setEGLContextClientVersion(2); _glView.setRenderer(this);[/source] When I query in onSurfaceCreated (like [source lang="java"]GLES20.glGetIntegerv(GLES20.GL_DEPTH_BITS, tempInt, 0)[/source] ...), I get the following values: GL_DEPTH_BITS = 24 GL_DEPTH_RANGE = 0,000000, 1,000000 GL_DEPTH_TEST = 1
  4. OpenGL

    Yes sorry, I must admit the images look quite chaotic. But when I reduce the amount of cars, the problem does not seem to happen. The weird thing is, that it is always whole objects, that pop up in front of the others that are really near, so I don't think it is a pure precision problem. It also seems to be always the latest objects that are rendered. When I render the base plate before the cars, it does not pop up. Every object is drawn using GLES20.glDrawArrays(GLES20.GL_TRIANGLES, 0, _numVertices); Maybe something like double buffering out of sync or clearing/loosing the depth buffer during rendering when the rendering call takes to long or the "pipeline" is filled up? Well sounds unlikely ... Maybe this image does illustrate the problem better: See the left lane of cars popping up in front although they should be hidden. Also note the car in the middle lane pop up in front. [img]http://www.eyedbits.com/upload/depthbufferproblem2.png[/img]
  5. I don't know about cocos2d-x or IPhone development. So my answer is purely shader oriented. Because the shader does not seem complicated, and only evaluated once per pixel, is it really the shader that limits the application? (60fps are quite fast isnt it? Maybe it will drop down anyway later on) - For the shader: You could try to use the [u]squared[/u] distance, which maybe calculates faster than taking the root for calculating the distance. The Lightsource can also directly save the squared radius instead of radius. But be aware that using the squared values for the (adapted) mixfunction will change the lighting into some kind of quadratic attenuation (maybe a benefit ;-)) Still I dont think this will help alot. - vec2 pos could be calculated within the vertex shader and interpolated as varying to the fragment shader, maybe this is minimal faster (or slower :-)) - Does the speed vary when you use 1 light compared to when you use 10 ? (In order to test if the uniform is valid for the loop condition) - You could try to make a full screen mesh grid (for example 20x20) instead of one quad and evaluate distances in vertex shader -> interpolate in fragment shader (quality depends on your light source radii) - If the lights are small you could render multiple smaller quads, one quad per light at the position of the lights (one quad per light) (But this would most probably need an extra pass) These are just some fast thoughts, not sure if it helps. Still I think, the shader and the task does not seem like a real performance hitter.
  6. [i][b]Hi there![/b][/i] I am facing a problem on an Android Application using GLSurfaceView. The problem seems to happen only, when quite alot of objects are drawn. Although most of the time, the depth test seems to work, there are some positions of the camera, when glitches appear. That is, objects in the back appear infront of nearer objects. In order to track the problem, i visualized the depths (gl_FragCoord.z) within the pixel shader (z, pow(z,20), pow(z,80)). (the whiter the further away, red = really near) Here is a combined image to show the problem. (alot of jeeps aligned in a x,z grid with a plane as bottom) On the left all is working fine. The mid shows the "bug", the right image is the visualization of the fragment.z value for the mid image. [img]http://www.eyedbits.com/upload/depthbufferproblem.png[/img] The fragment depths seems to be OK, but not properly used for visibility determination. Is it possible, that the z-buffer gets corrupt/overflown/deactivated somehow? Can a low framerate lead to a silent disabling of the depthbuffer? Z-Fighting does only appear between objects that are near to each other, right? So in general a far away object should still not appear in front of a near one? I don't know if it is a problem within my camera implementation, an android specific problem, or a general opengl thing. Any help is appreciated :-) [b][i]buddysk[/i][/b] (The quadMesh on the floor is 40x40 centered around 0, near plane 0.1, far plane 100 (problem also appears for nearplan 1, far plane 1000)) (I sometimes notice, that a frame changes between the first draw and the succeeding ones. Is openGL allowed to drop drawing calls? And I "remember" to have once read that it is not guaranteed, that all drawing commands are executed within one batch?! Maybe there are two frames rendered and combined afterwards?! (just a wild guess))