• 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

331 Neutral

About JonnyQuest

  • Rank
  1. Damn, above post was from me. ~phil
  2. I rent a server in a data centre, and only have network access to it, and can hard-reboot the thing remotely, optionally using a network 'rescue' boot image. Doing anything to the system gives me the creeps, but sometimes it must be done. I managed to re-partition the thing (including shrinking the / partition) and installing the Xen virtualisation system without locking myself out. I even installed a virtual machine without too much fuss. Then I wanted to install all the security patches before actually booting the VMs, so I mounted the logical volume for the virtual machine, chrooted into it, and started the upgrade. Suddenly, my ssh connection just died and I couldn't get back on. Turns out the patch it was installing was openssh. OK, looks like it kills sshd processes except for a list of PIDs with current connections when it upgrades. Except that list is on the original filesystem, not the one I just chrooted into. Oops! OK, so I think, just reboot. So I do, and it doesn't come back up. I'm starting to panic a little, so I reboot into the rescue system. I can log into that (phew!) except I can't seem to find anything wrong with the system. A reboot into the installed system locked me out again though. It took me a week to figure this out, but I had inadvertently added the VM partition to /etc/fstab in such a way that it automatically mounted the file system on boot, making sure the file system was consistent. As it turns out, hard-rebooting after my ssh fiasco had caused the file system to need a replay of the journal, and the system was asking me on the local, physical terminal whether I wanted to run fsck, (or so) effectively halting the boot process before starting ssh. Gaah. Removing that option from fstab did the trick, but as I said, I only figured that out after a week. D'oh! ~phil
  3. Genius :D ~phil
  4. Quote:Original post by phantom Bzzzt! wrong. It is perfectly legal to place different data into different VBOs, it might not be optimial from a data fetching point of view but it IS perfectly legal to do so. Oops, sorry about that, I must have seriously misread the VBO spec then. Interesting. How exactly do you use them, bind the VBO, set the array data, bind another VBO, then set the rest of the array data? ~phil
  5. Quote:Original post by phantom Quote:Original post by JonnyQuest I'm pretty sure the art/programming analogy extends all the way. Programming IS A art form I would agree for the most part, but it seems to be recurringly debated, and I didn't want to derail the thread with such a statement. ~phil
  6. Quote:Original post by sunandshadow I have seen programming books that take a project-based approach. The student is given a series of goals starting from "hello world" and working up to more complicated things, and the student learns whichever few new fundamentals are required for each project. I have found this approach works well for learning new art and writing skills because it helps me focus on learning one thing at a time, and I am motivated to learn that thing because I want the project to turn out well. I don't consider myself in a position to judge any art, but I am a programmer. (I've taken art classes but I'm still working on the fundamentals) And you'll find that, consistently, people who read and follow such books, don't take much from them, if they don't already know the fundamentals. These are the people that flock to these forums in droves claiming they, for example, "know C++" (after having read that book and done all the examples, if that) and now are stuck trying to write an MMO. Their skill stagnates, and they don't actually achieve anything in relation to the amount of time they put in. I know this from my own experience. I was the same, I headed straight for the hard stuff, as a result the code was a mess and the projects became unmaintainable and were never finished. My code was essentially broken because I lacked proper mastery of the fundamentals. However, I realised this sometime between ages 15-17 and took a completely different approach and went back to learning the fundamentals. Since then my skill has improved by leaps and bounds. (I'm 22) I've overtaken all my peers who refused to take a similar approach, yet those who had a similar revelation have had equal success with it. Coincidence? I doubt it. I'm still learning, of course, but then I doubt I'll ever hit a limit with that. Interestingly, I found that the fundamentals were actually highly interesting and engaging in their own right. It turns out there's a pretty good reason we have universities full of professors studying, understanding, and improving the fundamentals. I'm pretty sure the art/programming analogy extends all the way. EDIT: With regard to judgement: exposure and experience is key here. If you can't tell right from wrong, you've not practiced enough, and not studied other peoples' work enough. I don't mean looking at it and thinking "that's nice". I'm talking about taking their work apart and analysing it to death. You can do that with a painting just as much as you can with code. Concerning not finding human anatomy attractive, that's kind of sad. I know little about psychology, but I bet Freud would have had a field day with that. ~phil
  7. From what I can tell, you're using a separate VBO for vertex coordinates and texture coordinates. This is not correct. You need to put the entire data into different parts of the VBO, so you need to do something along the lines of: /* Create only one VBO */ GLuint vbo; glGenBuffersARB(1, &vbo); /* Allocate an array big enough to hold the whole data */ size_t vertex_array_size = nVertexCount * 3 * sizeof(GLfloat); size_t texcoord_array_size = nVertexCount * 2 * sizeof(GLfloat); char* temp = malloc(vertex_array_size + texcoord_array_size); /* Fill the array with the vertex data */ memcpy(temp, nVertexArray, vertex_array_size); /* Fill the rest of the array with texture coordinate data */ memcpy(temp + vertex_array_size, nTexCoordArrays[0], texcoord_array_size); /* Copy the whole thing into the VBO */ glBufferDataARB( GL_ARRAY_BUFFER_ARB, vertex_array_size + texcoord_array_size, temp, GL_STATIC_DRAW_ARB ); free(temp); That should hopefully do the trick. EDIT: Note that the glTexCoordPointer() call must be changed to this: glTexCoordPointer( 2, GL_FLOAT, 0, (char*)NULL + vertex_array_size); To correctly take into account the position of the texture coordinate data within the VBO. ~phil
  8. OpenGL

    Could you clarify the problem? Post a screenshot, say? ~phil
  9. Quote:Original post by kindjie After wasting an entire day trying to figure out why my Framebuffer object code was running slower than my glCopyTexSubImage code, I realised that the problem was with multi-display acceleration being enabled under Nvidia settings. For some reason it doesn't give me any errors when I checked the FBO status... Unfortunately, I'm running two OpenGL windows each on a separate display, both needing some sort of render to texture solution, and 14fps is not nearly fast enough (I need at least 50fps). Does anyone know if there's a workaround for this? Does Nvidia plan on enabling this for either the Geforce 6800GT or the Quadro FX 4500? I'd rather not use p-buffers if it can be avoided, assuming they'll even work... Could this be some sort of rendering context issue? I've never played with multiple rendering windows. I assume you are using separate contexts (and switching between them every frame) for the windows, so using P-buffers (with suitable use of the WGL_ARB_render_texture extension) might not have as much of an impact as you think. Quote:On a related note, both my FBO and glCopyTexSubImage code have a problem with leaving traces behind when I try to fade out an image. For instance, if I don't clear the FBO and just draw a black quad with a constant alpha less than 1.0, then render a few things and repeat, I'll end up with ghost images of the objects no matter how many times I draw the semi-transparent black quad. These ghost images get brighter the closer the alpha value is to 1.0, and seem to approach the same colour value over time. This sounds like a Z buffer problem. Are you sure you're clearing Z/stencil every frame, are Z tests enabled? ~phil
  10. The answer is pretty much 'no'. There aren't any extensions I know about that enable this either. I suspect the overhead would be too great, and it would mess with the card's ability to stream the content, and the whole thing would be counter-productive. If you're worrying about the amount of data in your vertex buffers, I'd try playing with the data types you use to pass vertex attributes to the card, particularly if you're using shaders. You can usually, for example, use signed/unsigned short ints for normal vectors and texture coordinates and map them to a suitable range in the vertex shader. From what I remember, strides of multiples of 16 bytes, aligned to 16-byte boundaries tend to be optimal for caches on the card. Don't forget to benchmark these things though, especially on older cards. ~phil
  11. You can get the OS to schedule threads to wake up for you, which should not cause any CPU usage while the thread is sleeping. You could use a mutex/condition variable with a timed lock so you can wake the thread up manually if you need to. Boost threads will even let you do that in a cross-platform way. I'd definitely prefer VSync (at least as an option) though: tearing is independent of the type of monitor, it's an artifact of the way the video card writes to the screen. ~phil
  12. Big desk, crappy camera. ~phil
  13. In the UK the Wildlife and Countryside Act 1981 makes it an offence to plant or cause Giant Hogweed to grow in the wild.
  14. Quote:Original post by Toolmaker Pouya was arrested and TA was shutdown over this. Watch what you say or they'll arrest you too. *misses TA* ~phil