• 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

713 Good

About noodleBowl

  • Rank
  1. I was wondering how do you guys handle loading in your image resources for your textures?   I was hoping since DirectX seems to be more of a complete package (APIs for rendering, sound, and etc) there would be some kind of function to load in various image types so I could use them as texture resources. Eg I could use something like loadResource(fileName) and I would get back something that I could use as a texture resource, where fileName could be a image resource that is a png, jpg, bmp, or dds file. But I don't think there is one directly within the DirectX APIs. Is this correct? or is there something I can use that can accomplish this? Do you guys just roll your own image loaders?  
  2. I think I'm more focused on the vertex buffers and how that data for the meshes, regardless if it was a truck, car, boat, cat, sprite, or whatever, should be organized in code       I think this captures my line of thinking best when I was writing this   In my example, I was thinking that regardless of how many or whatever item(s) I need to render they would all have their resources at hand. Eg all Vehicles would use the Vehicle Shader (created once and then referenced) But my issue came up in what to do about the buffer's like the vertex buffer. Now I'm starting to think that I should handle everything like the Shaders. I load the mesh and create whatever buffers I need once. Then I have a separate class that will use the mesh. Eg I have a TruckMesh class. This class holds all of the buffer data (vertex, index, etc), the texture, shader to use, etc. But then I also have Truck class which has all the properties needed by a truck (speed, turn radius, damage, etc) and it just references the TruckMesh so I know's what resources to use when I need to render it
  3. I have been thinking about this lately and I was wondering if I could get some guidance   Lets say I have 4 models   Truck Boat Airplane Sprite (2D Quad)   They all use a different texture and have a different set of vertices. The vehicles use a vehicle shader and the Sprite uses its own sprite shader. So we are looking something like this Models and their resources Truck Truck Vertices Truck Texture Vehicle Shader Boat Boat Vertices Boat Texture Vehicle Shader Airplane Airplane Vertices Airplane Texture Vehicle Shader Sprite (2D Quad) Sprite Vertices Sprite Texture Sprite Shader   Now my question might be stupid, but how do you go about rendering all of these different things in a manor of best practice? Leaning more on the side of how should all this data be organized so rendering is efficient?   Should all of these models boil down to their own class? Eg The Truck model is really a Truck Class. Then I store all of the information (vertices, shader, texture) in the class. Eg the Truck class has a ID3D11Buffer member for the vertex data required by the model. And then all other Models follow suit. EG Sprite class also has its own ID3D11Buffer member which holds the 6 vertices of a quad   Then when rending I do something like //Psudeo Code Foreach renderable //A renderable is one of the models as its class (Truck class, sprite class, etc) { //1. Bind the renderable's texture //2. Bind the renderable's Shader //3. Bind the renderable's vertex buffer //4. DirectX device context draw call } //Present all the things we just drew swapChain->Present(0, 0);\   Am I right on my assumptions or is this actually a really horrible way to handle things?
  4. I have been wondering this for a while now and this is in very general terms. Including a general non-specific programming language context.   But which of the below is "better." Not just in speed but in practice. Is there even any real difference? //Local scope variable outside the for loop CoolObject obj; for(int i = 0; i < 5; ++i) { obj = coolObjectList[i]; obj.doWork(); } //Local scope variable inside the for loop for(int i = 0; i < 5; ++i) { CoolObject obj = coolObjectList[i]; obj.doWork(); } In what instance does the placement of local scope variables effect the quality of ones code?
  5. IMO, you need to get away from this train of thought You are not making 2 builds. You have one platform, which is Android. You need to be able to keep track of that new glesVersion flag you have. The purpose of that flag is to know if you are running ES 2 or ES 3. That flag should be the deciding factor of whether you use shorts or ints. You could do something like int* AllocIndicesBufferES3(int numSegments) { int* indices = (int*)malloc(numSegments * 2 * sizeof(int)); for (unsigned int i = 0; i < numSegments; i++) { indices[i * 2 + 0] = i; indices[i * 2 + 1] = i + 1; } } short* AllocIndicesBufferES2(int numSegments) { short* indices = (short*)malloc(numSegments * 2 * sizeof(short)); for (unsigned int i = 0; i < numSegments; i++) { indices[i * 2 + 0] = i; indices[i * 2 + 1] = i + 1; } } //Whereever in your code that you would normally have this void ThatOneMethod() { if(glesVersion == 3) { indicesES3 = AllocIndicesBufferES3(numSegments); } else { indicesES2 = AllocIndicesBufferES2(numSegments); } }
  6. This would not work, because you are doing the USING_GLES3 if statement. What you have here would be a compile time thing. You want a run time thing. I was thinking something like this EGLint attribsES3[] = { EGL_CONTEXT_CLIENT_VERSION, 3, EGL_NONE }; context = eglCreateContext(display, config, NULL, attribsES3); if(context == EGL_NO_CONTEXT) { //We failed to create the ES 3 context. Try ES 2 EGLint attribsES2[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE }; context = eglCreateContext(display, config, NULL, attribsES2); if(context == EGL_NO_CONTEXT) { //Something is wrong... Failed to create the ES2 context LogError("Failed to create a supported ES Context"); } } //Other code to create the EGL Display
  7. I'm not saying this would work (I'm making an educated guess here) Now I'm now sure how you are creating your opengl context. Since you are using the NDK I assume you are doing the part where you create a EGL Display with the function eglCreateContext What I think you could do is try to create a context with EGL_CONTEXT_CLIENT_VERSION 3 and if the creation fails default to EGL_CONTEXT_CLIENT_VERSION 2. Then set some kind of flag saying you should be using ES 3 or ES 2 render commands This is also very true, even though I dont think you want to do this. You could build and run your code for ES 2 and at least that way you can have your application run on both ES 2 and ES 3 devices
  8.   100% honest, this is Ironic   I am porting my engine over from Java and originally in my Java code I had a Engine / Application class. Where the user extended from this class and used override methods on things like Update, Render, etc. But when I came over to C++ I felt that this was "too" Java and went a completely different direction
  9. I was wondering if there is a way to have user defined functions?   Here is my situation, I'm trying my hand at multi-platform code. I have a source file that has multiple main functions meant for their specific platform. When I compile a specific platform, the main function for that platform will be the one available and act as the programs entry point. So for example:   Desktop compile would have and use the typical main: void main() { //Program entry point }   Where compiling for Android would use and have this main function: ANativeActivity_createFunc AndroidStart; void AndroidStart (ANativeActivity *activity, void *savedState, size_t savedStateSize) { //Program entry point } Now I'm looking to have some user defined functions for Update and Render. Where these are automatically called by the internals of my code, but are what the user needs to have. Something like:     //In the internals of on my android application void MainThreadRun() {      while(running)      {             HandlePollData();               //User functions that the user made             UserDefinedUpdate();             UserDefinedRender();      } }     I was hoping I could do something like an extern method, but seeing that I want to package my code up as a SO / DLL library. Making methods like those and declaring them extern cause linker errors. Which makes sense cause they would not be declared in my code.   So what can I do? What are some better options?
  10. See this the tiny dilemma that I have. I want to better my sprite batcher as now it currently just does a intermediate mode (no sorting, no support for changing shaders, etc). But I do not know which is worse: Creating and allocating additional VBOs for the GPU when I do not have a "free" VBO OR Creating one large VBO and have something like the batch class above. Then when I do not have a "free / used" batch I create a new one and add it onto some vector   Boiling down using up more GPU memory or system memory  Keeping in mind I am targeting mobile devices, using OpenGL es 2.0 where I do not have direct mapping functions for pushing data directly into a VBO.
  11. I have a quick question about std::vector and its push_back function   If I have this data class: class DataBlock { int blockID; float data[25000]; }; What happens, memory wise and with the block variable, when I do //In some function if(needNewDataBlock == true) { DataBlock block; dataBlockVector.push_back(block); }
  12.   According to the Google docs that function is not guaranteed to work   Swiftcoder is absolutely right on this one. You need a way to recreate all of the OpenGL resources you needed. What I have done is something like: //In some init code area SpriteBatcher batcher; //In android onResume batcher.Init(); //Create the opengl resources //In android onStop batcher.Dispose(); //Clean up the opengl resources That way when a user does send the app to the background (Destroying the current OpenGL context) and then brings it back my OpenGL resources are recreated/linked up to the new OpenGL context that was created
  13. VS 2015 works great for me, although I pretty much just using it for intellisense when it comes to android. The emulator can't run opengl calls for me and the NDK debugging part won't work cause my device is too old. Otherwise awesome
  14.   This is what I'm trying to avoid. Making all of my C++ very Java esque   What is the general consensus on creating objects on the stack and then having to call an init function? MyClass myClass; myClass.Init(); But I kind of feel like this is counter productive to the constructor of the class   The reason I ask all of this is, well, long story short. I'm currently working in Android and struggling with class creation when they use OpenGL calls in their constructors. As they need a valid OpenGL context in order for them to work/not crash the application. I would like to have my classes created on the stack, but because my constructors have OpenGL calls in them I need a valid OpenGL context created first. This is where I'm not sure how to handle them as things like:   void MainLoop() { bool run = true; while(run) { PollForEvents(); if(TeminateSignaled) run = false; if(window->OpenGLContext->Inited() == false) continue; //Would like to create objects on the stack. This object uses OpenGL calls in its constructor. //Not sure how to do this without either: Keep on creating it (super bad) or having it stuck in local scope /* if(window->OpenGLContext->Inited() == false) continue; if(firstRun) { SpriteBatcher batcher; //not sure how to use out of local scope firstRun = false; } */ SpriteBatcher batcher; window->OpenGLContext->ClearBufferBits(); window->OpenGLContext->SwapBuffers(); } } Hope my issue above makes sense, never really had to wait for a window callback (Android triggers onNativeWindowCreated when the window is ready to display / used)in order to tie a OpenGL context to it. Always had something along of the lines of create the window right now and then use it
  15. I was wondering if someone could tell me the difference between: MyClass class; And   MyClass *myClass; myClass = new MyClass(); Other than the second block of code is making a dynamic memory allocation and that I must delete it when I'm done with it otherwise I'll suffer memory leaks.   But what I mean is which one should I be using the most? Does it matter even? Would it be bad to have all of my custom classes created using the dynamic memory way?