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

KarimIO

Members
  • Content count

    74
  • Joined

  • Last visited

Community Reputation

271 Neutral

About KarimIO

  • Rank
    Member
  1. OpenGL

    I found the answer. The SwapBuffer(hDC) command was simply where the error occurred, but did not have anything to do with it. I believe my error was due to something related to my indices, as if I draw only the first mesh in the model, everything works as intended. Nvidia crashed with this error, Intel went on and disregarded it. Nonetheless, thank you to Chris Becke for pointing out a future memory leak using GetDC(hwnd).
  2. OpenGL

    I have. Now it's this: SwapBuffers(hDC); Which means I get it once in the beginning and remove it once in the end of the process.
  3. OpenGL

    Also, by "crash", I mean the program freezes, screen goes black, and then I get a fatal error called in Visual Studio from Nvidia's DLL
  4. OpenGL

    I've instead used the same hDC stored in my graphics class, but it solves nothing. I'm sorry, but can you think of anything else?
  5. OpenGL

    I tried to use the same DC, but still get issues. EDIT: To be clear, you mean to ReleaseDC when cleaning up / exiting the process, correct?
  6. EDIT: I thought this was restricted to Attribute-Created GL contexts, but it isn't, so I rewrote the post. Hey guys, whenever I call SwapBuffers(hDC), I get a crash, and I get a "Too many posts were made to a semaphore." from Windows as I call SwapBuffers. What could be the cause of this? Update: No crash occurs if I don't draw, just clear and swap. static PIXELFORMATDESCRIPTOR pfd = // pfd Tells Windows How We Want Things To Be { sizeof(PIXELFORMATDESCRIPTOR), // Size Of This Pixel Format Descriptor 1, // Version Number PFD_DRAW_TO_WINDOW | // Format Must Support Window PFD_SUPPORT_OPENGL | // Format Must Support OpenGL PFD_DOUBLEBUFFER, // Must Support Double Buffering PFD_TYPE_RGBA, // Request An RGBA Format 32, // Select Our Color Depth 0, 0, 0, 0, 0, 0, // Color Bits Ignored 0, // No Alpha Buffer 0, // Shift Bit Ignored 0, // No Accumulation Buffer 0, 0, 0, 0, // Accumulation Bits Ignored 24, // 24Bit Z-Buffer (Depth Buffer) 0, // No Stencil Buffer 0, // No Auxiliary Buffer PFD_MAIN_PLANE, // Main Drawing Layer 0, // Reserved 0, 0, 0 // Layer Masks Ignored }; if (!(hDC = GetDC(windowHandle))) return false; unsigned int PixelFormat; if (!(PixelFormat = ChoosePixelFormat(hDC, &pfd))) return false; if (!SetPixelFormat(hDC, PixelFormat, &pfd)) return false; hRC = wglCreateContext(hDC); if (!hRC) { std::cout << "wglCreateContext Failed!\n"; return false; } if (wglMakeCurrent(hDC, hRC) == NULL) { std::cout << "Make Context Current Second Failed!\n"; return false; } ... // OGL Buffer Initialization glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glUseProgram(myprogram); glDrawElements(GL_TRIANGLES, indexCount, GL_UNSIGNED_SHORT, (void *)indexStart); SwapBuffers(GetDC(window_handle));
  7. I'm mostly asking about best practices. I know every application is unique but there's still stuff that's a good guideline. Well in that case would it make sense for one secondary command buffer per graphics pipeline? I'd have to recreate it more often but it would be larger and therefore faster, I suppose. Thanks!
  8. Yes, but what I mean is that, is there a way to bind one graphics pipeline once for some command buffers, and then bind another one once for others. Right now I'm just binding it for every single model (and therefore every single command buffer).
  9. Thank you very much! That makes a lot of sense. How, though, would I bind a graphics pipeline and descriptor set for multiple command buffers?
  10. Hey guys. Vulkan newbie from OpenGL here. Is there a way to remove a secondary buffer from a primary buffer in Vulkan? If not, how else can I remove objects? I'm binding my primary buffer to: Bind RenderPass Draw Related Secondary Command Buffers End RenderPass And my secondary buffers to: Bind Graphics Pipeline Bind Vertex Buffer Bind Index Buffer Bind Descriptors Draw Indexed The only other way I can guess to have objects be removeable is to have one command buffer per object and add them all to submitInfo.pCommandBuffers, but then I'll be rebinding the renderpass a lot, plus I figure it's more work for the GPU. Also, how would object removal be handled with indirect draws, as I'm planning on looking into that relatively soon? EDIT: One more question, is there a way to bind one descriptor set (for the projection, view, model, and combination matrices) to multiple graphics pipelines? And is there a way to bind graphics pipelines to multiple secondary command buffers?
  11. I was using TGA, but I'll go ahead and try to convert to DDS. I can't do it right now, as I'm rewriting my graphics module to be more flexible and gradually degrade in terms of drawing techniques, but I'll work on all this afterwards. I hadn't considering async for file loading but I'll look into it. The material and shader format I'm designing will be loaded along with files with the same name, and then report the shader files for the graphics library I'm going after, as well as name the uniform data I can pass to it including textures, color data, etc, which will be handled by the material files so it's more flexible. The material files will contain a list of all textures, I'll load a list of all the textures I need for the entire scene and then load them all, so that should fit the list you were referring to.
  12. I've previously traced the long loading times to my textures 80 textures (at largest, 1024x1024) that take a while to load. The paths of those are all taken from assimp FBX (though I'm hoping to develop my own material and shader group formats as soon as I get around to it). I'm well aware that some stuff I do probably take up more time (for instance I copy my buffers at least once. I'm also using a single thread to start off with before things get too hectic rather than multiple. Additionally, I'm tracing down a claim that BRG is faster for loading images as it doesn't have to convert between formats). I'm well aware there are OTHER things that are slowing things down. And I'm trying to nail them down. All I wanted to know was whether this was a consideration. Not so I can deal with it right away, but so I can know if this is a significant issue that I'll probably need to deal with if everything else doesn't work, or even if it does work to shave of a few additional seconds of load time. I use stb to load and parse image formats and assimp to load and parse model formats. STB uses C File loading while I'm not sure what Assimp uses. I'll continue investigating further, but I don't want to go even further off-topic here.
  13. The problem is that it takes me several minutes to load even a small sponsor map with a couple dozen textures. I'm currently looking into seeing how much I copy data around and seeing if I can bind images and meshes to buffers directly as well as other speed improvements. But even if it's fast, there's always faster. I don't want my work to be just good enough, I want it done right. That's why I'm losing all my perfectly good gldraws for indirect multi draws and command buffers. It's why I'm trying to decrease load times before it's a huge concern. Because I'd rather get things right now than rewrite tons of code because I bought my head. In games, every millisecond counts because they all add up. So if I'm trying to ensure I load things properly.
  14. Thanks Hodgman, you're always very helpful, but will this actually help? Everyone's essentially saying that unless I use optical media I shouldn't bother. Thanks to everyone else that posted, as well!
  15. I suppose I was mostly trying to change the definition of those things rather than swap them out, though at runtime. Thanks though.