• 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

564 Good

About AverageJoeSSU

  • Rank
    Advanced Member
  1. NCsoft just released a fully featured javascript plugin for unreal engine 4. For someone like you that might be a fun thing to hammer on.    https://wiki.unrealengine.com/Unreal.JS   https://forums.unrealengine.com/showthread.php?92022-Unreal-js
  2. Unfortunately it seems like TexPageCommittment is a blocking operation?
  3. Fixed! somehow the format passed to subimage either changed the second time around, or mattered the second time around, prolly the former. UGH. at least i found it.
  4. Puzzling issue. I have a code path that creates a sparse texture, and returns a Texture that is committed and sparse.   I then can uncommit it, which turns the texture to black ( i am rendering it onto a quad). If i then commit it again, which is the same path as was used when the texture was first created (minus the storage part), the texture appears but is totally mangled.   I checked width and height and texid values and format values, and they are the same (or at least after many checks appear to be, i could be missing something stupid). I know my data is at least getting in because the recommitted image is there, just mangled and rearranged in chunks.   Are there any things i need to do when recommitting a sparse textures memory? I know i need to reupload my pixels, and i know the memory needs to be commited before doing so, but I use the same code path when creating it the first time, and it renders and looks fine. the ONLY difference is i call uncommit before that same code path gets executed.   Any ideas?    -Joe   PS: First time image is created and committed (and bits uploaded) and rendered : [attachment=27579:firstTime.png]   Second Time the image has been uncommitted, then recommitted (and bits uploaded) and rendered: [attachment=27580:recommit.png]     
  5. Needed to commit the storage before calling texSubImage to upload the data. Simple but elusive issue.
  6. Anyone else experiencing completely broken sparse texture support on Nvidia Linux?   I tested my program on a GT 750m and k5000 with 331 drivers and 346 drivers and got the exact same behavior. basically when you do a glTexSubImage the driver loads the texture data incorrectly into the tiles of the sparse texture. If the image is the size of one tile, then it is uploaded fine, but if it exceeds 1 tile, the same (some arbitrary subset of) texture data is seemingly copied to each tile, rather than the driver correctly offsetting and mapping the correct texture data to the correct tile.   Super annoying since for a while i thought it was my code, but my tests and reading suggest otherwise (there is no mention anywhere of an application having to manage tiles).
  7. Sparse texture requires that Texture storage be a multiple of Virtual Page Size.   Any ideas at what the best approach is for handling any width and height of image? Does Texture data HAVE to fill exactly the dimensions of a TexStorage?   If a texture is added at 0,0 and just doesnt fill the entire texture storage, you would need to know the texture width and physical width and then divide to figure out where the sample should be. Is there any way to avoid this?
  8. Little late to this topic but....   First off since you mention you are learning, do yourself a favor and if you really want to learn opengl, get yourself in a situation where you can limit the frustration of having to do setup code, and provide yourself with an environment that can help you debug. THIS IS NOT MAC OSX. Ubuntu or Windows  + Clion or VS + GDEbugger + common support libraries like Glew, GLFW and SOIL help you get a window and load textures quickly (just a hypothetical example)   Also, as has been suggested before, there is very much an old way and a new way of doing things in OpenGL, and they have big implications on performance.   Luckily, An Nvidia guy has a github page that has sample code for the new way of doing things. I highly suggest you clone that repo and study it religiously.   That github page, paired with study of the opengl spec that describes the features in that code, will IMO be your best bet at learning opengl.   In a nutshell... the movement in the OpenGL API has been that of 0 driver overhead. That is, the application does some of what the driver usually does and thus the driver does less work, so you can really slim down the runtime graphics stuff.   Lastly, in the repo is a solution to packing multiple textured quads using (might not have the right names) ARB_BUFFER_STORAGE, SHADER_DRAW_PARAMETERS,  BINDLESS_TEXTURE_ARB, SPARSE_TEXTURE_ARB, and MULTI_DRAW_INDIRECT. Again, the application is doing what the driver might do, thus reducing overhead. If you think of a draw call as packing data of similar objects as opposed to actually drawing a single object, you begin to see how the transition of old opengl to modern opengl is themed.
  9. Phew, I grossly misunderstood bindless texturing. Residency is only for the texture handles. Sparse Texture support is for residency of texture memory. Luckily the two work together quite well, so if I add sparse texture immutable storage I can leverage the same querys of determining bindless residency to deal with sparse residency.
  10. So I think it actually is working.... what throws me off is that vram seems to stabilize... so the driver must keep residency memory reserved using a data structure of some sort (makes sense).   i can handle 80 high rez images w/ mipmaps (basically camera animates over them (by 2s).
  11. I wanted to keep my issues with bindless in the same thread, as to keep things somewhat tied together. See latest edit at the top for details.   I could post more detailed code if needed, But it seems like a simple thing.   What are the requirements for making a resident texture non resident? By definition, what does making a texture non resident actually do?   A comment in the spec says that if the texture isnt going to be used "for a while" it can be made non resident, maybe the GPU won't specifically release the memory if it has plenty? Perhaps the crashing i am seeing is when it actually starts releasing and adding textures from VRAM.
  12. I actually tried just doing regular binding and i get the same result.   Do i NEED to bind a "sampler"?   maybe its my VAO... it's pretty straightforward vertexBufferSize = desc.vertexBufferSize; indexBufferSize = desc.indexBufferSize; glGenVertexArrays(1, &vaoID); glBindVertexArray(vaoID); glGenBuffers(1, &vboID); glBindBuffer(GL_ARRAY_BUFFER, vboID); glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex)*vertexBufferSize, &desc.meshData[0].x, GL_STATIC_DRAW); glGenBuffers(1, &indexID); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexID); glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(unsigned short)*indexBufferSize, desc.indexData, GL_STATIC_DRAW); glEnableVertexAttribArray(0); glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, sizeof(Vertex), 0); glEnableVertexAttribArray(1); glVertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, sizeof(Vertex), (void*)(12)); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, indexID); fprintf(stdout, "vbo: %d\n", vboID); fprintf(stdout, "index buffer: %d\n", indexID); fflush(stdout); glBindVertexArray(0); // Disable our Vertex Array Object }
  13. Okay...   Texture Creation Texture &tex = (*textures)[desc.filename]; if (tex.name.compare(desc.filename) == 0) { return tex; } if (desc.width < 1 && desc.height < 1) { //bad input } int width, height, channels; unsigned char *textureData = SOIL_load_image ( std::string(TEXTURE_DIRECTORY).append(desc.filename).c_str(), &width, &height, &channels, SOIL_LOAD_AUTO ); fprintf(stdout, "width: %d, height %d: \n" , width, height); fprintf(stdout, "Done Loading Texture... \n"); printf( "SOIL loading error: '%s'\n", SOIL_last_result() ); fflush(stdout); GLuint textureHandle; glGenTextures(1, &textureHandle); glBindTexture(GL_TEXTURE_2D, textureHandle); glTexImage2D(GL_TEXTURE_2D, 0,GL_RGB, width, height, 0, GL_BGR, GL_UNSIGNED_BYTE, textureData); //set texture parameters glTexParameteri(textureHandle, GL_TEXTURE_WRAP_S, GL_CLAMP); glTexParameteri(textureHandle, GL_TEXTURE_WRAP_T, GL_CLAMP); glTexParameteri(textureHandle, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(textureHandle, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glGenerateMipmap(GL_TEXTURE_2D); //get GPU PTR GLuint64 textureGPU_ptr = glGetTextureHandleARB(textureHandle); fprintf(stdout, "texture pointer: %lu \n", textureGPU_ptr); fflush(stdout); //Make the handle resident on the GPU before using it. //Here we assume that we are creating a texture because we want to display it. //If we didnt want to display it right away, we wouldnt make it resident. //We can also move textures off the GPU by calling glMakeTextureHandleNonResidentARB glMakeTextureHandleResidentARB(textureGPU_ptr); tex.TextureID = textureGPU_ptr; tex.width = desc.width; tex.height = desc.height; //if everything checks out, assign the name so it becomes valid in the hashmap. tex.name = desc.filename; glBindTexture(GL_TEXTURE_2D, 0); return tex; Square mesh data... struct Vertex { float x, y, z; float u0, v0; }; name = "square"; vertexBufferSize = 4; indexBufferSize = 6; meshData = new Vertex[vertexBufferSize]; for(int i = 0; i < vertexBufferSize; i++) meshData[0].x = -0.5f; meshData[0].y = -0.5f; meshData[0].z = 0.0f; meshData[0].u0 = 0.0f; meshData[0].v0 = 0.0f; meshData[1].x = -0.5f; meshData[1].y = 0.5f; meshData[1].z = 0.0f; meshData[1].u0 = 0.0f; meshData[1].v0 = 1.0f; meshData[2].x = 0.5f; meshData[2].y = 0.5f; meshData[2].z = 0.0f; meshData[2].u0 = 0.0f; meshData[2].v0 = 1.0f; meshData[3].x = 0.5; meshData[3].y = -0.5; meshData[3].z = 0.0; meshData[3].u0 = 1.0; meshData[3].v0 = 0.0; indexData = new unsigned short[indexBufferSize]; indexData[0] = 0; indexData[1] = 1; indexData[2] = 2; indexData[3] = 0; indexData[4] = 2; indexData[5] = 3; } the setUniformTextureHandle64NV call above actually calls glUniformHandle64ARB void Shader::setUniformTextureHandle64NV(GLuint location, GLuint64 value) { //Runtime function glProgramUniformHandleui64ARB(this->ShaderProgram, location, value); } and the shaders again: #version 440 layout (location = 0) in vec3 VertexPosition; layout (location = 1) in vec2 TexCoords; uniform mat4 worldMatrix; uniform mat4 projectionMatrix; uniform mat4 viewMatrix; out block { vec2 Texcoord; } Out; void main() { mat4 mvp = projectionMatrix * viewMatrix * worldMatrix; Out.Texcoord = vec2(TexCoords.x, 1.0-TexCoords.y); gl_Position = mvp * vec4(VertexPosition, 1.0); } #version 440 //#extension GL_NV_gpu_shader5 : require // for 64-bit integer types #extension GL_ARB_bindless_texture : require in block { vec2 texCoords; } In; layout (bindless_sampler) uniform sampler2D textureID; layout (location = 0) out vec4 FragColor; void main() { FragColor = texture(textureID, In.texCoords); } Here are images:   [attachment=25574:bindlessNotWorking.png]   [attachment=25575:textureAndStack.png]
  14. Double EDIT: I have updated my renderer with a prototype to test this feature. and glMakeTextureHandleNonResident seems to not do anything.   I used the following code as a test to see how much memory i have (at the end of my Renderer::Draw() before unbinding the GLContext): GLint currentAvailableVideoMemory = -1; glGetIntegerv(GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, &currentAvailableVideoMemory); GLint totalAvailableVideoMemory = -1; glGetIntegerv(GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX, &totalAvailableVideoMemory); float percent = (float)currentAvailableVideoMemory/(float)totalAvailableVideoMemory * 100.0f; fprintf(stdout, "VRAM (%d MB) Usage: %f%% \n", totalAvailableVideoMemory/1024, 100.0f - percent); fflush(stdout); which reports 95.xxx% always...   And in gDebugger i always have the same number of texture objects.   when i add 100 images. i get a couple of frames and then the renderer dies, asummingly because the textures are not actually made NonResident.   Is there something i need to be doing to ensure that non resident calls are executed? Could this be a bug in the nvidia linux driver?       EDIT: stupid shader in/out blocks didnt match... thanks compiler!   Here is the output for my program, i also checked in gDebugger and the texture loads just fine.   Vendor: 4.4.0 NVIDIA 343.36 Supported GLSL version is 4.40 NVIDIA via Cg compiler. Aspect Ratio: 2.400000  vbo: 1 index buffer: 2 Shader Source: #version 440   layout (location = 0) in vec3 VertexPosition; layout (location = 1) in vec2 TexCoords;   uniform mat4 worldMatrix; uniform mat4 projectionMatrix; uniform mat4 viewMatrix;   out block {     vec2 Texcoord; } Out;   void main() {     mat4 mvp = projectionMatrix * viewMatrix * worldMatrix;     Out.Texcoord = vec2(TexCoords.x, 1.0-TexCoords.y);     gl_Position = mvp * vec4(VertexPosition, 1.0); }   ../shaders/simpleTexture.vert Compilation Successful  Shader Source: #version 440 //#extension GL_NV_gpu_shader5 : require    // for 64-bit integer types #extension GL_ARB_bindless_texture : require   in block {     vec2 texCoords; } In;   layout (bindless_sampler) uniform sampler2D textureID;   layout (location = 0) out vec4 FragColor;   void main() {     FragColor = texture(textureID, In.texCoords); }   ../shaders/simpleTexture.frag Compilation Successful  Linking Shader Program: simpleTexture.vert Shader Link Successful GL_ACTIVE_UNIFORMS = 4   0) type:mat4 name:projectionMatrix location:0   1) type:sampler2D name:textureID location:1   2) type:mat4 name:viewMatrix location:2   3) type:mat4 name:worldMatrix location:3 width: 500, height 331:  Done Loading Texture...  SOIL loading error: 'Image loaded' texture handle pointer: 4294969856     My question is, given those shaders and the fact that glGetTextureHandleARB returns non 0, should it work? (of course given the correct geometry and uvs)  
  15. Thanks for the review!   High resolution clock is the "fastest", but it is not reported as steady. I think this means that if the CPU is throttled and the system clock is changed because of battery or whatever, then the clock will change, thus becoming inconsistent? I am not sure if this is important or not, since it doesnt need to be 100% consistent forever (perhaps this is what i am seeing in the blips?)   The autos might seem a bit tough to decipher if you are not familiar with chrono. accumulator is a duration<int64_t, std::micro> which should be as good as i can get?   your snippet of code looks good, i'll plug it in and see if that improves the results!