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

Mathias_L

Members
  • Content count

    6
  • Joined

  • Last visited

Community Reputation

132 Neutral

About Mathias_L

  • Rank
    Newbie
  1. Thank you, calling glFinish() after rendering the quad made it run fast so that I don't need the glReadPixels-hack anymore! Seems like glReadPixels does something like glFinish internally. (btw. Putting glGetError at locations behind context creation also removed any gl-errors [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] ) [quote]I'm also wondering what you mean by "submitting the results to GPU", if you never read back the texture data to CPU won't you just keep working on the same data? The piece of code you commented as submitting the results just binds another texture.[/quote] I'm not deep into that but I think it's like this: The texture data doesn't need to be transferred to the CPU, since after rendering the quad the data is inside the texture memory on GPU - binding the texture and sending the texture unit via glUniform to the shader allows accessing the texture memory on GPU where the texture data still is. (Is that right?)
  2. Oh sorry, I didnt... I was just checking for glsl errors... What could it mean that i got an invalid operation error (0x502) at the very beginning of my Program? [source lang="cpp"]int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) { checkErr(); // GL_INVALID_OPERATION !!!!!!!! MSG msg = {0}; WNDCLASSEX wcl = {0}; wcl.cbSize = sizeof(wcl); wcl.style = CS_OWNDC | CS_HREDRAW | CS_VREDRAW; wcl.lpfnWndProc = WindowProc; wcl.cbClsExtra = 0; wcl.cbWndExtra = 0; wcl.hInstance = g_hInstance = hInstance; wcl.hIcon = LoadIcon(0, IDI_APPLICATION); wcl.hCursor = LoadCursor(0, IDC_ARROW); wcl.hbrBackground = 0; wcl.lpszMenuName = MAKEINTRESOURCE(MENU_FIXED_FUNC); wcl.lpszClassName = "GLWindowClass"; wcl.hIconSm = 0; if (!RegisterClassEx(&wcl)) return 0; ......[/source]
  3. Hi there, I do some calculations on the GPU by rendering a quad into a FBO. The result is subsequently submitted back to GPU for further processing. The result looks fine but due to some strange mistake I seem to make, it runs very slow (below 1 fps). But when I include a "glReadPixels" call after rendering the quad, the performance goes up to 20 fps (the result of the calculation stays absolutely the same!). But since I don't want to access the data on CPU between the two shader calls, I don't need to acces the pixels and therefore there should be no need for a glReadPixels call. The result of the glReadPixels call is not even read by the program and I only need to read a one-pixel-region to get this effect (see comments below). I have no Idea how this strange behaviour could be explained. The relevant code is posted below. I used an FBO without an attached depth buffer, only a rgba-texture. The functions "renderToFBO" and "submitToGPU" are called subsequently. If you are interested in initialzation code or something, please let me know. I figured out, that the performance issue is not related to the glsl-shader code. Thanks for your answers. [source lang="cpp"]// RenderTarget - Type: typedef struct { bool isAllocated; bool hasDepthBuffer; GLuint color_tex; GLuint fb; // FBO GLuint depthBuffer; GLsizei width; GLsizei height; TextureType textureType; } RenderTarget; // ------------------ render to FBO --------------------- void RenderTargetContainer :: renderToFBO(RenderTarget *rt) { glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, rt->fb); glViewport(0,0, rt->width, rt->height); glClear(GL_COLOR_BUFFER_BIT); glMatrixMode(GL_PROJECTION); glLoadIdentity(); gluOrtho2D(0.0, rt->width, 0.0, rt->height); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); glBegin(GL_QUADS); glVertex2f(0.0, 0.0); glVertex2f(static_cast <float> (rt->width), 0.0); glVertex2f(static_cast <float> (rt->width),static_cast <float> (rt->height)); glVertex2f(0.0, static_cast <float> (rt->height)); glEnd(); // -- these two lines make it run fast // -- although the visible result statys the same. // -- "foo" will never be read. // -- region needs to be at least 1 to get the speed up effect. static float foo[4]; glReadPixels(0, 0, 1, 1, GL_RGBA, GL_FLOAT, foo); } // ------------------ submit result to GPU --------------------- void RenderTargetContainer :: submitToGPU(GLint shaderVarLocation, int textureUnit, RenderTarget *rt) { glActiveTexture(GL_TEXTURE0 + textureUnit); glBindTexture(GL_TEXTURE_RECTANGLE_ARB, rt->color_tex); glUniform1i(shaderVarLocation, textureUnit); }[/source]
  4. Hi, I just found the bug... Something really stupid... I assumed that max_phot in the constructor of the Photon_map class would be the same number of emitted photon, what results in loosing information of one light source, if more than max_phot would be saved. That's why the error ocured only when I used indirect Lighting. Thanks anyway for reading, I really thought it would be something more complicated.
  5. Hi, I'm trying to add some photon-mapping to my simple Ray-Tracer that I have to develop for school. I took the photon-map data-structure of Henrik Wann Jensens "Ralistic Image Synthesis Using Photon Mapping" book, although I don't understand every part of that example code, but I'm working on that. Of course, I also considered the errata-list on his homepage as well as the topics in this forum that focus on special parts of his example code. My first experiences with only one light sources seemed to work quite well, but now, using two light sources, I'm not sure if the resulting fault in the picture is because of an error in my sourcecode or because I don't use the photon-map in the right way. Thats what I'm trying to do: I've defined a simple scene (like cornell-box) with two light sources. I'm using only one photon-map for the whole global illumination. (Later I'll include a separated caustic and shadow-map, but at the moment I'm testing the photon-tracing and -storing with only one map.) In this photon-map, I'm storing the photons every time they hit a diffuse surface (by russian roulette) and scale the photon power by the diffuse object-color of the object they hit, until a photons power is under a threshold-value. So sending out 10.000 photons results in ca. 30.000 stored photons in the map. The failure in the picture: That all worked fine until I used more than one light-sources. Using two light sources results in a picture, displaying only one light-source. The surprising thing: When I set the threshold value up to a value, that a photon is ONLY stored when it hits a diffuse the FIRST time (->no indirect illumination), all lights are displayed! And if I'm storing only the photons that bounced MORE than once (store only indirect illumination), the picture also displayes the indirect illumination of all light-sources. So the failure only occures, if I store EVERY hit of a photon, and it doesn't occure, if I store only the first hits or all hits excluding the first. The question: Is the discribed problem a normal result? I've read in a topic of this forum, that it's normal to seperate the indirect illumination from the direct, and what I'm trying to do, is doing both in one... is that my fault? If yes, I don't understand the photon-locating-algorithm in the kd-tree, because it should find the photons of my second light-source anyway, does't it? I'd be glad, if someone understands the problem and has an idea where it's comeing from. Thanks a lot for reading!