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

Stephan Picker

  • Content count

  • Joined

  • Last visited

Community Reputation

139 Neutral

About Stephan Picker

  • Rank
  1. I'm trying to query the size of a SSBO I declared in a shader. layout(shared) buffer SourceBuffer { float s[NUM_ELEMENTS]; }; glGetProgramResourcei(programHandle, variables, index, GL_ARRAY_STRIDE) returns 16 = 4*sizeof(float)     when setting NUM_ELEMENTS to 4096-> we have NUM_ELEMENTS * STRIDE = 4096 * 4 = 16384 elements = 64kb glGetProgramResourcei(programHandle, GL_SHADER_STORAGE_BLOCK, interfaceBlockIndex, GL_BUFFER_DATA_SIZE); With that setup glGetProgramResourcei returns the correct size. But when I get higher as the 64kb it returns -16 ?!?!?!   My card fully supports OpenGL 4.3.
  2. Oh interesting face: I just played around with my SSBO.   and changd: layout(shared) buffer Classification { float h[MAX_FACES]; }; to layout(std430) buffer Classification { float h[MAX_FACES]; }; now the stride is sizeof(float). But since my application is very performance critical (the algorithm will be running for hours) I still want to know what's up. std430 now gives me a "good" alignmen, but "shared" offers a implementation specific optimized layout. So my GPU (Radeon 6950) must have a reason to stride it the way it is?!?
  3. Thank you very much Ohforf sake. Very good post.   Now for the last open question: I read that GPU preferabley have 128bit registers. so this could explain the odd allignment. I also remember quite briefly, that if it was tightly packed, the ALU would have to mask out single 32bit packets and store them in a register.
  4. I'am having some questions about Image Image-LoadStore and SSBOs (and also UBO).   I will move solved Questions down to Facts.   Questions: * why is a float[]-array not tighly packed when declared in a SSBO. ??? There is always a stride of sizeof(vec4). * ... why does this make sense ??? * what are typical use-cased for the two ???   Facts (or educated-guesses): * SSBO and Textures both reside in global memory?                                       normally yes. * Acces to SSBOs is uncached?                                                                       only L2 cache. * Acces to textures via LoadStore is cached (texture-cache)?                          yes, uses texture-Cache. * The actual load and store via LoadStore is done by texturing-hardware?      yes, uses texture-memory-pipeline. * which of the two is more performant?                                                             texture-cache has better 2d-spacial-locality, but latency longer * where do UBOs reside in memory?                                                                uniform-buffers reside in the constant-cache! (only 1-float per clock) * can I also write to an Uniform-Buffer?                                                             no.
  5. I'm working on a formular to calculate the index for the frustum of a 2D-Point-Light. My Light-System is rendering the Scene into 4 1D-Textures: Right, Left, Top and Bottom.   Now, in the fragment shader I want to query the index for the frustum corresponding to the fragment position in light-space, so I know which depth texture I have to sample.   I got one that works, but it's very complicated.     Or should I just do a series of "if" statements. My concern with that is, that inside a warp, only the body of one if-statement can be entered, which leaves all fragments idling, if they have different frustum.
  6. I fixed the problem.   The thing is that you can't do: gl_Position = vec4( vs.lightSpace.y / vs.lightSpace.x, 0.0f, depthToHom(vs.lightSpace.x), 1.0f); because the vs.lightSpace.y / vs.lightSpace.x is a perspective divide - and you can't interpolate already divided values.    The Fix: gl_Position = vec4( vs.lightSpace.y, ... ... ..., ... ... ..., vs.lightSpace.x); The divident and divisor of the perspective projection have to be interpolated independently in order to guarantee a perspective correct interpolation of depth values. also the "... ... ..." have to be modified, but that's not essential to the point I'm trying to make.   - This cost me a hole day to figure out- 
  7. I still want to known, where my math is wrong. Every context in my rendering is linear. So why do I see a curve?! When I insert more points it gets better.   I dumped the content of my shadow-map to see whats wrong. (The two color-transitions represent the content of the shadowMap - you can see - they are not the same - even though they should be)  
  8. What do you mean by "screenspace raytracing".   Do you mean: for every light L - and every angle Alpha - you start at the origin of L and trace the direction given by Alpha until you hit a blocker in your fbo?
  9. I'm writing  a shader for a 2d point light shadow mapper.   I render the depth-values of the right Frustum of the light into a texture which is 1024x1 pixels in size.   I project the vertices myself, so I dont use the w coordinate.   This is my projection into the shadow-map. "vs.lightSpace" means that all vertices are in the coordinate-system of the light. (0,0) is it's origin. gl_Position = vec4( vs.lightSpace.y / vs.lightSpace.x, 0.0f, depthToHom(vs.lightSpace.x), 1.0f); float depthToHom(float depth) { float near = 0.5f; float far = 10.0f; return depth * 2.0f / (far - near) + (-far - near) / (far - near); } As you can see the depth-values are not interpolated correctly. On long edges there is a round curve in the shadow. Is this because I don't divide correctly? The big white circle is supposed to be a point-light.     To sample the depth I use: float depth = texture(shadowMap, vec2((lightSpace.y / lightSpace.x + 1.0f) * 0.5f, 0.5f)).x; if(depthToNorm(lightSpace.x) > depth) { //... ... ... } float depthToNorm(float depth) { float near = 0.5f; float far = 10.0f; return depth * (1.0f / (far - near)) + (-near) / (far - near); }
  10. ok! Doesn't sound unreasonable.   But Is there still a mechanic/technique, that allows me to query layout information even though I don't use any variable at all ?
  11. ... I just want to get a valid index/location for all of them - even if they're not used. Because they're shared and not every shader needs all of them.
  12. no ?!? But it's "shared": So it must not be optimized out.   If I'm not understanding right - whats the right approach to get the layout even for variables which are not used?
  13. <h1>Problem</h1>   Hello. I'm trying to share a Uniform Buffer among different programs. The problem is, that I have to query the layout - which is shared - at one point. I tried all possibilities, but it always return -1.   The specification tells me, that with the shared layout, the driver is not allowed to optimize and has toactivate the variables.   What did I miss?   <h1>Code</h1>   #version 420 core   layout(shared) uniform Camera { mat4 camViewProj; mat4 sunViewProj; mat4 sunViewCoordProj; };   out mat4 outVar;   void main() { //outVar = camViewProj; }   I only get a valid index for "camViewProj" when I uncomment the section above.   To Query the indices, I used:   glGetProgramResourceIndex(); glGetUniformIndices();
  14. ... ok, but still - as long as I use "textureLod" all I get is black pixels ...
  15.   Doesn't Work.   I also just read that you can only use "textureLod" in vertex buffers. Isn't that nonsense?