• 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

378 Neutral

About N1ghtDr34m3r

  • Rank

Personal Information

  1. Thanks for that, xycsoscyx. But it occurs, that if I use alpha testing and discard it, the smooth outline of signed distance field won't be smooth anymore, due to the fact, that the smoothness (like antialiasing) relies on the alpha fading. Any other ideas?
  2. Helloy xycsoscyx,   that's a point I've forgot to mention: since I'm using OpenGL 3.3 Core, I can't use alpha testing by using glEnable(GL_ALPHA) and glAlphaFunc(...). Is there some other way for that?
  3. Hello Stainless,   that doesn't changed anything and wasn't a problem.    Anyway, two of the three questions aren't answered by now. 
  4. Hello C0lumbo,   thanks for replying.      Thanks for that. If I substract the spread from xAdvance it seems to be alright. Anyway, sometimes it looks not so perfect, but I think, this is due to no kerning yet. Any idea on how to implement it? I've got the data for a simple alphabet (something around 1111 kerning values), but don't know how to iterate it fast enough on a per character basis.       Unfortunately it is no illusion.  Here some screenshot, zoomed in a little bit:   It is the same font with the same size but without a different color in the background. Why does it occur? Is my fragment shader wrong?   Thanks and a good evening, NightDreamer
  5. Hello everyone    I've just implemented signed distance field text rendering and I've got a few minor problems, I can't solve by myself.    First of all, a quick overview of the problems: I advance the cursor on the x-axis with the value of "xAdvance" (should be self-explanatory), but the space between two characters seems to be wrong (see screenshots). How can I fix this? How could I set a font size like "Set this font to a size of 12px"? => How do I calculate the correct box size for a single character? It occurs that the visual font thickness depends on the background color (see screenshots, in the upper one, the font seems to be clearly thicker). Why does it happen? (Due to alpha?)  And how can I prevent this behaviour? So, here are some screenshots:       Now, I hope you see what I meant. If not feel free to ask and I will try to clarify it. Here, my implementation:   The signed distance field font files were created with Hiero It created the texture (512x512 in my case) and a .fnt text file. The important (and almost all) parts (/lines) of this file are like char id=33 x=484 y=202 width=24 height=60 xoffset=-7 yoffset=7 xadvance=33 where x,y,width,height represent non normalised texture coordinates and the offsets and xadvance represent pixel numbers.   The fragment shader, which calculates the actual visual character on the signed distance field texture: #version 330 core in vec2 _uv; uniform vec3 color; uniform sampler2D fontAtlas; const float width = 0.5; const float edge = 0.1; void main() { float distance = 1.0 - texture(fontAtlas, _uv).a; float alpha = 1.0 - smoothstep(width, width + edge, distance); gl_FragColor = vec4(color, alpha); } This is how I calculate the vertices for drawing: void Font::write(const char* text, float scale, float x, float y, float z) { for (const char* p = text; *p; p++) { Glyph g = m_glyphs[*p]; float gx = x + static_cast<float>(g.xOffset) * scale; float gy = y - static_cast<float>(g.yOffset) * scale; float gw = static_cast<float>(g.width) * scale; float gh = static_cast<float>(g.height) * scale; x += g.xAdvance * scale; if (!gw || !gh) continue; float u1 = static_cast<float>(g.x) / static_cast<float>(m_atlas.width); float u2 = u1 + (static_cast<float>(g.width) / static_cast<float>(m_atlas.width)); float v1 = static_cast<float>(m_atlas.height - g.y) / static_cast<float>(m_atlas.height); float v2 = v1 - (static_cast<float>(g.height) / static_cast<float>(m_atlas.height)); m_buffer.push_back(Vertex(gx , gy , z, u1, v1)); m_buffer.push_back(Vertex(gx , gy - gh, z, u1, v2)); m_buffer.push_back(Vertex(gx + gw, gy - gh, z, u2, v2)); m_buffer.push_back(Vertex(gx , gy , z, u1, v1)); m_buffer.push_back(Vertex(gx + gw, gy - gh, z, u2, v2)); m_buffer.push_back(Vertex(gx + gw, gy , z, u2, v1)); } } This is how I render all of this: void Font::render(const glm::mat4& ortho, const glm::vec3& color /*= glm::vec3(1.0f)*/) { if (m_buffer.size() > 0) { m_shader.bind(); m_shader.setUniform("ortho", ortho); m_shader.setUniform("color", color); glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, m_atlas.id); glBindVertexArray(m_vao); glBindBuffer(GL_ARRAY_BUFFER, m_vbo); glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex) * m_buffer.size(), &m_buffer[0], GL_STREAM_DRAW); glDrawArrays(GL_TRIANGLES, 0, static_cast<GLsizei>(m_buffer.size())); glBindTexture(GL_TEXTURE_2D, 0); glBindBuffer(GL_ARRAY_BUFFER, 0); glBindVertexArray(0); glDisable(GL_BLEND); m_shader.unbind(); m_buffer.clear(); } } If you need some other code, just say it and I'll provide it.    Cheers, NightDreamer   EDIT: - minor changes in question 1 and 3
  6. OpenGL

      Okay, yeah, I think I will stick to Bruneton's implementation for a while. But it's quite heavy. Any tipps/tricks for this? :)
  7. OpenGL

      Personally I get way more confused, looking at those publications. :) I need actual implementations to fully understand things like that.     Okay. If I understand it correctly, Sean O'Neill wasn't using precomputed scattering tables, was he?
  8. OpenGL

      Yep, Rayleigh scattering in interaction with Mie scattering, like Sean and Eric (and almost everyone I read about) used, if I understood that correctly.   EDIT: I realised, that Eric used 4-5 shader programs in his demo. Are they all needed? Or is only one program for the sky?
  9. OpenGL

      Okay, that's a good point. Although I'm developing on a GTX980Ti.   I'll try Eric Bruneton's approach first. If I got problems, I will ask again and/or try Alex Peterson's (btw: I'm aboslutely a fan of his program Spacescape) Unfortunately I couldn't get his sample project/code working. I've made a new VS2013 project, copied all his files, included GLEW and Glut but can't find the library/headers for "tiffio.h"...   EDIT: Also (if I commented all the texture loading stuff out) the linker complains about missing functions in glut, which can't be the case, due to the fact, that I'm successfully linking to the glut.lib and including the glut.h
  10. OpenGL

    Hello swiftcoder,   thank you for replying. That makes a lot more clear.     I think Eric Bruneton's work (which looks indeed extremely awesome) isn't a good solution for a game, isn't it? And the second approach from Alex Peterson shows only the perspective from the sky. In my use case it would be rendered to a screen filling quad to be the background sky in a game with day/night cycles. :)
  11. Hello everyone,   there's something special I want to implement, but that I can't understand: atmospheric scattering. My goal is, to achieve a sky background, where I can adjust the color gradients/etc. parameters.   Therefore I googled and found a lot of interesting stuff: Sean O'Neills GPU Gems 2 - accurate atmospheric scattering. 1. Question) Why is everything I found regarding the implementation stuff from before 2012?   Now I had a problem: the shader described is only the SkyFromSpace shader. This was fixed, after I found the link to the download section.   Then there came up another problem: almost everyone got the tip: visit his website and download the improved version. 2. Question) How should I visit Sean O'Neills old website, if the website is now a website for casinos?   TLDR: Have anyone an idea how to get the source for Sean O'Neills implementation 'SkyFromAtmosphere' in OpenGL? Or better: an actual tutorial for atmospheric scattering? Or is there something better these days? (<- that's why everything is from before 2012?)   Thanks in advance, NightDreamer
  12. Hi, Sorry for late answering, university eats all of my sparetime. :D Here's an example of what I mean: I want to have a Quadtree for the map, so I can easy traverse it and calculate collisions and other things. That would be no problem, if I would have an idea for how I can positioning an object like a building on the map/on that grid -> quadtree.
  13. Yeah, I know that. Sorry, if my message wasn't as clear as I thought. What I really wanted to say by that, was that I'm interested in learning the "background programming": how an engine would handle it, how far it can be handled, where pros/cons are, where performance critical sections are, how to achieve stable performance, etc. I already played around with Unity and Unreal. And I just don't want to click a game together.  (I know, you can code your own stuff, due to the fact, that I prefer C++ style over C#, I would stick to UE instead of Unity )  For me, it feels like a WYSIWYG Website Editor, just for Games. But I want to code it. I want to code something, that I'm proud off and not something, where some other devs can be proud of their engine, that she could handle it.      Back to topic:   Is it useful to use a "scene format" (XML or something like that) instead of hardcode positions in the mehs vertices? My thoughts were, that when the meshs vertex positions are hard coded (offsetted in Blender), it could be bad due to floating point errors. Is it something to worry about? Or should I make something like a world editor, where I can move objects around and save it to a file like a "world description"?
  14. Thanks for all this interesting stuff. Yeah, spacial partitioning was a thing I learned a time ago. Just forget about it, but ya, that will be definitely a thing I will implement. Moewover I will definitely look up software occlusion culling and predicate rendering. Thanks for that.           Mhmm... yeah, that's true. I can definitely use an premade engine. But what should I, as a programmer, learn, when I'm letting all the stuff done by the Unreal Engine which other programmer wrote. And where does these programmer have their knowledge from?  Another engine maybe? Maybe from Unity3D? 
  15. Thanks at all! That made it a bit clearer, especially the frustum culling.    I would appreciate it, if I could do this. But for me, there's one detail missing... If I have a bunch of meshs, all bound to a cube and a player with a "camera", I only have a bunch of points (the cubes) and a 4x4 matrix (the camera). How am I now able to compute the frustum culling on the CPU side? The link you gave me is awesome! Thanks!   But what about the logical update aspect instead of just the rendering? If I render only the objects within the previously calculated frustum, maybe I could update each objects logic? Or is something like "update only objects within a specific radius outside of the frustum" a good approach?