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

  • Rank
  1. I'm trying to debug my project, and for some reason MSVC 2017 can't find the source code  file.....even tho it says it can and the checksum matches. Sometimes won't load the source file at all, other times it will load and I can start stepping through it, but then it errors out and says it can't find the code. I'm guessing some sort of optimization is happening, which is confusing the debugger? Locating source for 'b:\projects\paroikos\src\dev_ui.cpp'. Checksum: MD5 {76 c2 7b ca ab 92 b8 c5 2d 4 10 c8 13 32 26 3f} The file 'b:\projects\paroikos\src\dev_ui.cpp' exists. Determining whether the checksum matches for the following locations: 1: b:\projects\paroikos\src\dev_ui.cpp Checksum: MD5 {76 c2 7b ca ab 92 b8 c5 2d 4 10 c8 13 32 26 3f} Checksum matches. The debugger found source in the following locations: 1: b:\projects\paroikos\src\dev_ui.cpp Checksum: MD5 {76 c2 7b ca ab 92 b8 c5 2d 4 10 c8 13 32 26 3f} The debugger will use the source at location 1.Build command: cl /GR- /MP /MT /WL /DPAROIKOS_EDITOR /DDEBUG /Z7 /nologo /EHsc /Fobin/ src/platform_windows.cpp "opengl32.lib" "User32.lib" "Gdi32.lib" /Febin/paroikos_editor /Fdbin/paroikos_editor /link
  2. I'm working through adding texturing to my program by following vulkan-tutorial.com and was wondering about row pitch. The tutorial states that images must obey the implementation's row pitch amount, which makes sense. However, the question I'm running into is that I want to use a VkBuffer for staging rather than a separate staging VkImage. From what I can tell, the only way to get the needed row pitch is from the linear tiled staging image. I'm assuming the optimal tiling image will have a different row pitch, and I can't find anything stating either way. Can I use the row pitch from the destination optimal tiling image, or do I not have to worry about the pitch it in this case?
  3. Vulkan

    I question the need to only render a small portion of the UI at a time. Maybe it was useful back in the day before we had hardware acceleration and blitting pixels in the CPU was slow, but if you're using hardware accelerated rendering...I don't really think it's a problem redrawing the whole UI when something changes. I did a small immediate mode UI for a basic map editor in opengl. I filled an array of all the vertices, copied them to the VBO, and rendered everything....every frame (and this was split up into multiple draw calls if the scissor rect changed). There was very little performance hit (everything, including the map itself, was being push out in <1ms iirc). In a UI that isn't limted to real time framerate of a video game..it's even less of a problem since acceptable delay is much more lenient. So if it takes 5 or even 10 ms to render your whole UI, it wouldn't cause noticeable lag in your application's usage.  
  4. I think it's a matter of order. You want to position the weapon at the camera, rotate, then offset in the direction the camera is facing. So some psudocode would look like m_Weapon->Position(m_Camera->GetPosition()); m_Weapon->OrientY(m_Camera->GetYaw() + 30); m_Weapon->OrientZ(m_Camera->GetPitch() + 30); weapon_position += m_Camera->getForward() * weapon_offset;
  5. There's been a few games I've tested where they just plaster an alpha'd texture over the whole screen with the user id repeated all over it. 
  6. The way I would do it is sort objects by their y value. Assuming +y is downward, if your player's y (probably best to check the player's position at their feet) is less-than the object's y (offset a little from the top), then the player gets drawn first. Whereas if the player's y is > object's y then the player gets drawn first. This will get you proper sorting for if the player is behind or in front of. For jumping, you would have a "z" value in addition to the x and y. The z value would represent the player's jump height. When the player's sprite gets drawn you draw the sprite at (x, y + z).  I haven't used Gamemaker, but if there is a "depth" value that specifies draw order, just set that depth value to the object's y location. For the player sprite, it would be a good idea to get the y position of the feet (y + spriteHeight) for best results. For jumping onto objects, you would have to think about the 3rd dimension. Normally you just do intersection testing with the bounding box of the object to figure out if the player collided with the object. To keep things simple since this isn't "real" 3D, I would have a "height" value for an object. So for example, that table could have a height of 4 units tall. When the collision check happens, I would just do something like: if collidedWithObject AND player.z > table.height THEN allow movement ELSE collide. Then as the player falls down from gravity and lands on the table, you would set the player's "z" to the table's height. Then of course you would have to set the z value to 0 once the player gets off the box. It is complicated, and theres a lot more work to be done. I don't know how to translate this into gamemaker, but that is the concept behind it.
  7. Oh wow. I can't believe I missed that, tho I'm still surprised this problem occurred in this code base and not my previous one. I normally don't unbind anything, since the binds get overwritten anyway, I'll just have to be more careful about texture units. Still, what was happening is when the window is resized...I recreate the frame buffers (which are what those glTexImage2D calls are after binding to the texture units). So after the initializing the framebuffers for the first time, they immediately get recreated again because Windows sends a resized event when the app first starts up. I'll admit, this should be changed. I guess I didn't realize that calling glBindTexture while a different texture unit was  active, would change the texture bound to that unit. It makes sense in retrospect. I'll figure out a way to prevent this from happening in the future. Thanks!
  8. I don't touch the depth texture at all after creating it, aside from clearing it every frame.
  9. EDIT: here's the GL command call log http://pastebin.com/0xxVqDQq Couple more points to add: Another strange discovery I found is that if I comment out the last texture bind, by doing this:     BindTextureUnit(&editor->devTexture, 0);     BindTextureUnit(&editor->renderBuffer, 1);     BindTextureUnit(&editor->lightBuffer, 2);     //BindTextureUnit(&editor->uiSprites, 3); The first texture, devTexture at unit 0, renders as black. If I uncomment it, it works fine.   Secondly, I have a previous revision of this code that works with all four texture units bound. The difference between this code base and the previous one, is this one I have converted to 3D rendering with depth testing. This is how I build the frame buffers with depth texture: _INTERNAL RenderBuffer  CreateRenderBuffer(u32 width, u32 height, b32 hasDepthBuffer = true)  {     RenderBuffer result = {};     result.width = width; result.height = height; glGenFramebuffers(1, &result.fbo); glBindFramebuffer(GL_FRAMEBUFFER, result.fbo); glGenTextures(1, &result.texture);     glBindTexture(GL_TEXTURE_2D, result.texture); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 0);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);     glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0,                  GL_RGBA, GL_UNSIGNED_BYTE, NULL);          glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, result.texture, 0);          if(hasDepthBuffer)     {         glGenTextures(1, &result.depth);         glBindTexture(GL_TEXTURE_2D, result.depth);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_COMPARE_FUNC, GL_LEQUAL);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 0);         glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0);                 glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT, width, height, 0,                      GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);             glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, result.depth, 0);             }  GLenum drawBuffers[1] = { GL_COLOR_ATTACHMENT0     };     glDrawBuffers(1, drawBuffers);      GLenum fboStatus = glCheckFramebufferStatus(GL_FRAMEBUFFER); ASSERT(fboStatus == GL_FRAMEBUFFER_COMPLETE);          glBindTexture(GL_TEXTURE_2D, 0); glBindFramebuffer(GL_FRAMEBUFFER, 0); return result; } Could the two be somehow related? I've double checked the generated texture IDs and none of them are overlapping. No gl errors even after multiple frames and the frambuffers don't trigger the assert.
  10. regular tex parameters   _INTERNAL Texture CreateTexture(Bitmap bitmap, b32 convertToLinear)  {     Texture result = {};     result.handle = UINT_MAX;     result.width = bitmap.width;     result.height = bitmap.height;     glGenTextures(1, &result.handle);     glBindTexture(GL_TEXTURE_2D, result.handle);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_BASE_LEVEL, 0);     glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_LEVEL, 0); GLenum colorType = (convertToLinear) ? GL_SRGB8_ALPHA8 : GL_RGBA;     glTexImage2D(GL_TEXTURE_2D, 0, colorType, bitmap.width, bitmap.height, 0,                  GL_RGBA, GL_UNSIGNED_BYTE, bitmap.pixels);     glBindTexture(GL_TEXTURE_2D, 0);     return result; }
  11. Quick update: I went through and did glBindTexture(GL_TEXTURE_2D, 0) after creating the frame buffers. Now instead of being white, the texture comes out as black. Same order dependency as before. Calling glGetError() at the end of the game loop still returns 0.
  12. Basically, I store the assigned texture unit in the Texture struct as seen above. When I go to set the uniform in the texture, I use that texture.unit.  _INTERNAL void UseTexture(RenderContext* context, Texture texture, u32 loc) {     if(context->cmdBufferSize > 0)     {         ASSERT(!"InvalidPath"); }     glUniform1i(loc, texture.unit); } The render part looks like this glClearColor(0.0f, 0.0f, 0.0f, 1.f); BeginRenderPass(&editor->renderContext, editor->spriteShader, SPRITE_SHADER_UNIFORM_TRANSFORM_MAT, viewMatrix, editor->renderBuffer); {     UseTexture(&editor->renderContext, editor->devTexture, SPRITE_SHADER_UNIFORM_TEXTURE);     PushVertexBuffer(&editor->renderContext, editor->floorVbo, 6, RenderMode_Triangles);   } EndRenderPass(&editor->renderContext);  So all I do to test this is change editor->devTexture to editor->uiSprite.   devTexture works, uiSprite doesn't. The same shader is used, so the sampler location doesn't change.   Renderdoc doesn't work on my application for some reason (Doesn't support OpenGL 4.5?). But i can use GLintercept to post the GL calls log if needed.
  13. Unreal Engine 4 is probably the most capable 3D engine to get stuff going without programming due to the Blueprint visual scripting. UE4 does have simple 3rd person examples and first person shooter examples for free, I would definitely take a look into that. The closest game that matches your idea is Skyrim, which can be modded.
  14. World could have a reference to player (since the player is in (or on?) the world, right?) then you can just grab the needed values player->getPos() etc. If you have some external class handling your game objects, that one should be what creates the projectile. Player input shouldn't be handled inside the player class. The input should drive the player from the outside, something like if(is_key_pressed) { player->move(dir, speed) }
  15. I have the following code:     BindTextureUnit(&editor->devTexture, 0);     BindTextureUnit(&editor->renderBuffer, 1);     BindTextureUnit(&editor->lightBuffer, 2);     BindTextureUnit(&editor->uiSprites, 3);     GLenum err = glGetError();     Which consists of: _INTERNAL void BindTextureUnit(Texture* texture, u32 unit) {     glActiveTexture(GL_TEXTURE0 + unit);     glBindTexture(GL_TEXTURE_2D, texture->handle);     texture->unit = unit; } This section before the game loop is the only place where I bind textures to texture units. Rest of the time I set the sampler in shaders. Also note that the GL Error is set to 0 through all of this. The first three textures work as expected, no problems. I recently added the fourth texture "uiSprites". When I render anything with that texture, it comes out white. Now supposedly my GPU can handle 192 texture units, so I'm not running out...but for some reason the texture units above 2 don't work properly. Here is what I've found in my investigations - I know for sure that the textures are being loaded correctly. If I put uiSprites into the first texture unit, it renders correctly. Similarly, if I put devTexture into the 3rd unit, it renders white. - If I comment out the first line, where devTexture is being bound, then I bind uiSprites to unit 0 AFTER binding the renderBuffer and lightBuffer...the texture is rendered as white. This means that the only time binding to texture unit 0 works is if I do it before the other two.   renderBuffer and lightBuffer are both Framebuffers and work correctly the whole time while testing this. I'm wracking my brain trying to figure out why a) the 3rd texture unit is white b) why is this order dependent?