• 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

664 Good

About alkisbkn

  • Rank

Personal Information

  • Location
    United Kingdom
  1. Hi Dukus, Those are some good points, thanks. I have a flat scenegraph at the moment, but intend to go to a more spacial approach soon.   For sort bins, you suggest that I have a render queue per property batch, let's say, and sort the objects that are bined in it using their sort key? That may parallelise better, as at the moment I am sorting all the objects in one job.
  2. Hi Hogdman,   Thanks for your reply. That is how I do the Culling and sorting at the moment. DrawCalls are created before the Sort job, where 1 mesh = 1 task, if that makes sense. Would it be correct to say that it'd be the Sort job's job to cut the sorted DrawCall array into pieces and create N BuildCmdList tasks (where N = the maximum number of commandlists)? That way I could guarrantee the order of the command list building.   @Dukus That is how I have structured my renderer (or well, structuring it now :P). It is based on an article from Blizzard. However, 1 task per scene-view will not parallelise very well; that is why I am trying to add subtasks to each scene-view rendering process.
  3. This is a question that perhaps a seasoned engine programmer could asnwer for me. In a single threaded renderer, a possible approach would be something like this:   - Collect visible drawable objects - Create DrawCall instances, containing everything that the renderer needs to visually describe this object, including a sort key. - Sort those instances based on the sort key - Go through them all and render them   Roughly...     However, with a commandlist approach (D3D12/Vulkan), I can see some problems. So, we want to record commandlists from multiple threads; let's say we have a task scheduler which we feed it rendering tasks. We also have a pool of commandlists and we get the next available. So far so good, we can record our commands. How would the drawcalls be ordered?   Thanks!
  4. Is this for updating the slices of a 3d rendertarget?
  5. You could do the displacement in the vertex shader and using transform feedback to get the updated vertexbuffer cpu-side and write that to OBJ. Maybe that could work?
  6. time.h and gettime ?
  7. Had a quick look, this may not be the issue, but why is your w set to 2 here? gl_Position = gMVP * vec4(Position, 2.0); Also try instead of (1,1,1). vec3 DirectionalLightDirection = normalize(vec3(1.0f, 0.0f, 0.0f));
  8. Man that's horrible :( My grandmother used to sleepwalk a lot, but not to that extent, she would keep herself within the house.   This may be of some help to you, although I am sure you have done your research on the matter: http://www.nhs.uk/Conditions/sleepwalking/Pages/Introduction.aspx
  9. OpenGL

    Links are good. http://nehe.gamedev.net
  10. Some kind of animal, maybe a racoon.
  11. So I was browsing through the code trying to fix some camera issues that we have in the game. This is what I encounter at some point, made me laugh a lot: //TODO: PUT Back IN !!!!! NAUGHTY   (I am naughtier) return 0;//(int)Mathf.Floor (t * 100);
  12. OpenGL

    The transformed vertex due to the model*view*projection transformation ends up in clip space. To translate that into ndc, you need to take into account the perspective divide as such: // vertex shader: float4 p = mul(mvp, vertex); o.screenPos = p; // fragment shader: float2 screenPos = (i.screenPos.xy / i.screenPos.w) * 0.5 + 0.5; You ignore the z coord.   screenPos will be in 0..1 range.  Is this what you need?     This doesn't look right to me. You are passing a near plane of 10 (which means you will get shadow clipping when the camera is very close), and a far plane of 1000000. Also, why is aspect ratio = 2?   I'd suggest to go with an orthographic projection to begin with instead of sharing the same projection matrix between your main camera and your light shadow caster.
  13. OpenGL

    Is the light a directional one? Where are you calculating the light's projection and view matrices? gluPerspectiveA(90.0, 2.0, 10.0, 1000.0 * 1000.0); What is the last parameter of gluPerspectiveA, is it the far plane? If so, it may be too big and you lose depth precision. You should also be using an orthographic projection for your directional light, as it's considered to be very very far away. Matrix44<double> SMVP = ( (ACTUAL_MODEL * shadowView) * ACTUAL_PROJECTION ) * ShadowbiasTex; The order of multiplication in opengl is projection * view * model, I think you got this the other way round. I'll have a better look at your code later, I am at work now.
  14. OpenGL

      Personally, if the shader does not contain the specific uniform buffer name (using glGetUniformBlockIndex), I ignore it/send a warning to the console.   Moreover, my renderer is a deferred renderer so I more or less know exactly what kind of shaders I have at any given time.
  15. OpenGL

    I do it in the following way:   My UniformBuffer has a usage flag, which is "Default" or "Shared". Now we have 2 scenarios on using the UBO:   1) If the UniformBuffer usage is "Shared", then the UBO send an event to the ShaderManager to register this UBO to all the loaded shaders. In my engine it's guaranteed that all the shaders are pre-loaded, so when you create a shared UBO, it's also guaranteed that all the shaders will know about it. When the renderer is binding a shader, it also binds its registered UBOs.   2) If the UniformBuffer usage is "Default", then I manually register the UBO to whichever shader I want.   I use the std140 layout as well. I am not sure if this approach is 100% correct though. Reading haegarr's approach makes me re-think of my design a bit.