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

Labrasones

Members
  • Content count

    24
  • Joined

  • Last visited

Community Reputation

354 Neutral

About Labrasones

  • Rank
    Member
  1. It was always more of a hypothetical question. Questions like this which cover extreme situations help me understand what is going on behind the scenes. It's not just about optimization, it's about understanding how it works. If I can understand how it works, I'm less likely to use it wrong.
  2. So, I could create a VBO for every model upon game load (assuming it totals less than system RAM size)? The nature of my original concern was doubling the memory requirements of the game, since I'd otherwise be storing the model data outside the VBO as well as within one during rendering. Ideally, I'd like to load the model data for all the objects within the player area, directly creating VBO's for those objects whether or not they are visible. However....   How does one go about giving hints to the driver? I'm feeling like that would be vital to good performance.
  3.   Does this mean that if there is not enough VRAM, the vbo will be stored on ram instead? Or will it just throw a memory error and not store it?
  4.   Or, check out Blender. It's free, and has everything you could possibly ever need. From motion tracking to GLSL shading preview, and a sculpt mode with dynamic tessellation. (Oh, and the Student Autodesk license is nasty. You don't own what you create with it -> http://wiki.blender.org/index.php/User:Ton/Autodesk_EULA It's from 2012 but probably still relevant.)
  5.   So, what if I have the same Shader and camera matrix for all objects, could I use a VAO to bind those two things, then manually bind each of my vbos after? It would make things much simpler. But wouldn't that then bind all those VBOs to the VAO state?
  6. The reason I'm not sure about the matrix transformations is that I thought the whole idea of combining them was so you could make one draw call, which reduces api call time. I'm not sure how I would send a matrix or a position for all of the objects as well as the data.   How I imagine using a VBO is when I load model data from the hard drive, I create a VAO, then create and bind a vbo for the data (as most tutorials do). According to my understanding, that this allows me to bind the VAO instead of the VBO, which gives better performance(?).
  7. You said that sections within the view frustum are sent to the GPU. Binding a VBO and adding data to it is the process through which data is sent to the GPU in OpenGL right? (I want to make sure I know what a VBO is before I try and design a system to use them effectively. Have to leave the tutorials behind somewhere.)   When it comes to actually changing VBO data, is there any reason to try and maintain them? Or should I just tell OpenGL I don't need them any more and create new ones?   I'm also curious to know if the combined VBO method has any merit. I've seen a lot of posts suggesting that as many models as possible should be joined in a single VBO. I feel that this would be more effective if I wasn't doing matrix transformation during the vertex shader (which I plan to). I also think that it would remove the possibility of instancing any of the models within that VBO.
  8. I'm trying to understand more about how Vertex Buffer Objects work and how to best use them. I've run into a hypothetical situation that I can't find an answer to. Most tutorials are simple and don't cover complexity such as this. A lot of these questions probably stem from misunderstandings about VBOs.   If I have more models required in the current scene/level than I can create VBO data for, but not all are visible all the same time, how do I resolve the issue?   From my understanding of VBOs, they are expensive to build per frame, and are typically built when model data is loaded from the hard drive. From what I've seen in tutorials, every object needed in the scene/level is built into a VBO upon level initialization. While this works fine for simple tutorials, what if I have a huge level, or a world that needs to stream in real time from the hard drive? (Eg, Skyrim, Burnout Paradise, Just Cause 2, Far Cry 2 & 3)   Obliviously, I will need to create new VBOs at some point. But when? I can't change the VBO per frame without significant performance loss can I?   One solution I can think of is a grid system. Moving beyond the edge of a grid causes a rebuild of the current VBOs to match the new player area. While this works in the worst case, I feel that general usage won't produce very many worst case scenarios. Thus this would lead to unnecessary performance loss.   Would a Dynamic VBO be part of a solution? If so, wouldn't that mean I either have to combine all the objects into one VBO, or, carefully keep track of which VBOs I can reuse?
  9. I would probably just try an animated image. Like a .gif. Or just use a series of images to do the animation. Personally, I think that would be the most simple method of doing that. I'm sure it has many downsides but if you have a deadline and you can't find a better solution, this could be a fallback idea.
  10. So, I recently lost all my data (long story, due to user error :| ) And I've hit exactly the same problem again. Except this time it doesn't even work if I multiply the shaders on the CPU. I'm basing it off of a tutorial I found here -> [url="http://openglbook.com/the-book/chapter-4-entering-the-third-dimension/"]http://openglbook.co...hird-dimension/[/url] I've converted it to use GLM Math instead of the math functions included in the tutorial. That's the only change though. If there is a specific bit of the code you would like to see, let me know and I'll post it. Solutions I've tried so far: -Transposing the matrices before transferring them to shader. - Using identity matrices, doesn't give the blank screen. - Made sure version numbers are the same - Used same matrix multiplication order as last time. None of these have made any difference. The only thing I've managed to do is fill the entire screen with 2 triangles when I disable the OpenGL culling operations. This problem seems to be kicking my ass over and over again and I wish I knew why I can't get it to work. Any suggestions would be very useful.
  11. Thanks for the suggestions! I think Hodgman's suggestion is exactly what I was looking for.
  12. So I've started writing my own project in C++. I was getting along quite well I thought, until I started to get compile errors with multiples of the same header files trying to be compiled. I took a closer look at my #include statements and came to a terrifying realization that it was a mess. A HUGE mess. I was amazed it had taken me that long to run into that error. My question is; how do you keep track of your includes? What method works best? (eg. flow chart, string and bulletin board, white board, just a plain list....) Also, what is the best way to create the hierarchy of includes, for example: Lets say I have these files. Bone, Mesh, Model, Entity, Manager, Updater, Main Model relies on Mesh and Bone Entity relies on Model Manager relies on Mesh Updater relies on Entity Main relies on Manager, Updater. What is the best way to include these files according to their individual dependencies? I get stuck like this: Model: #include "Bone" #include "Mesh" Entity: #include "Model" Manager: #include "Mesh" Updater: #include "Entity" What now? What do I include in Main? I need both Updater and Manager, but if I include both, I've included Mesh twice!? I've got no strategy to contend with this. Any suggestions?
  13. This is getting more and more off topic, but the way I've always seen the sun glares is that there is a lens over the player's eyes. I mean, you have a HUD (In most FPS modern setting games) that implies some sort of lens or screen in front of the viewer's eyes. So I find that a sun glare makes sense. For games set in the past, or games with HUDs that look more drawn than digital, the lens flare can be explained away by glasses on the player. And then, like MJP said, flares give clues as to brightness, you can't stare at the sun after all, and you can't in game either.
  14. Thanks! That's exactly the type of stuff I was looking for. And now I have a keyword to google if I wan't more info and stuff!
  15. I'm trying to find more tutorials on general window creation, but specifically how to customize the border of the window. For example, Steam, Desura, and Chrome. These applications all have cool looking borders instead of the default Windows one. I've found many tutorials on how to show a window with the regular border, but I can't find any that go into customizing it. I don't really know what I should be searching google for either. Can someone point me in the right direction?