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

stenny

Members
  • Content count

    549
  • Joined

  • Last visited

Community Reputation

142 Neutral

About stenny

  • Rank
    Advanced Member
  1. As everyone has said, the problem lies in the initialization of your two numbers, NOT in the while-loop (although it could be optimized). Look at these two lines: int num1, num2; diff(num1, num2); These were on top of your "kinda" improved version of the code, right at the start of main() and thus your program. My question: what VALUES are you passing to diff() right now?
  2. Because headers normally only contain declarations and no definitions. Thereby, libraries are precompiled, which is a huge advantage with bigger projects. They only need to be linked. Correct me if I'm wrong though, I'm learning just as well ;)
  3. Things are started to clear up. Slowly. Separating logical and graphical data seems like a solid plan to me. A Scene Graph consists of nodes describing how the world is ordered in a logical fashion. Adding a node (or entity, as you'd like to call them) doesn't necessarily mean it has a grapical representation, only a location/transformation and volume in 3d space. As soon as you 'attach' e.g. a mesh (or light, etc.) to the entity, you update its bounding volume. Then I register the current entity to the spatial tree, you say? I take it you insert that node at a spatial leaf that's coherent in 3d space with the world coordinates of the node in the SG? I.e. this is where you separate logical data from spatial data. --- Ok, so immediately converting my modeldata to vbo-indices right after loading a mesh isn't the way to go. My current meshclass consists of several submeshes. Each submesh is assigned a material and indiceslist. The indices, of course, refer to the vertices, normals and texcoords in the main mesh class (vertex arrays). You suggest I keep it at that and convert all data to VBOs at a later stage, right before rendering the spatial tree? This would help with sorting my rendering by material/texturestate switching, something I had been wondering about too. Does this also mean that, when I want to render my scene, I don't call SceneGraph->render(), but SpatialTree->render()? Thanks for helping out guys; the fog is clearing up, keep it coming! - Stijn
  4. Thanks for answering, Wiegje85. Nonetheless: yes, I could have used google for this. And I already had. As much as I appreciate your reply, I understand the concept of all these trees. The problem is the implementation (for which google, frankly, doesn't yield that many results). Coding a SceneGraph doesn't seem too hard (using c++, btw). Create a node (abstract base) class, a std::vector with children and a pointer to its parent, etc. Problems arise for me when I think about combining this with a spatial and other trees (or, whether that IS actually the right way to go). As it is now, I've got a (static) Mesh class that, when calling loadFromFile() reads in a binary meshfile, places them in VBOs and returns the VBO-indices (OpenGL). That means my data is either already there, or being transferred to the GPU. How can I do processing on polygonlevel - like splitting up faces - when I'm supposed to put it in a VBO? Should I be using VBOs in the first place, or are they deprecated or so? And also, yes I'm an HKU student. Unexpectedly though, I study Composition for Adaptive Systems there. Music. Game desing/programming is just a 'hobby' for me, as it is for a lot of us here on GameDev ;) - Stijn [Edited by - stenny on May 1, 2010 5:21:15 AM]
  5. Hey there, I seem to find the concept of scene graphs and other sorts of hierarchical trees rather confusing, so I thought to post for some guidance here on gamedev. I haven't really got a specific question, I'd just like someone to explain me the matter of the topic or give me some direction. I've searched gamedev for some information - and there sure is a lot to be found (Yann L's ABTs, etc.) - but none of it how to actually implement this stuff. So, let's see where I'm currently at. By all means, correct me if I'm wrong. As far as I know scene graphs and spatial trees aren't the same thing, right? They're both a hierarchical collection of data but the difference lies in the fact that SG's are ordered by logical connections in the game world and ST's by, well, space. Does that mean SG's shouldn't be used for culling, collision checking or anything like that? If not, that would mean I'm supposed to create more than one tree of my scene. A scene graph for logical...yeah, what? If data is ordered in a spatial manner, what would I need a Scene Graph for? Or am I supposed to put my transformations in the SG (which seems highly unlikely, because that hasn't got anything to do with game logic, and more so with space). Another thing I don't get is the concept of a spatial partitioning tree itself. Or at least, I think I understand the use of BSPs, Quad-/Octrees, ABTs, and so on and so forth (speeding up culling), but not in combination with e.g. a VBO. When computing a spatial tree there is a possibility you'd have to splice up polygons, right? What if a mesh I've loaded in a VBO crosses the border of a ST-node; the idea of vertex buffer objects is that you load in a bunch of data and send it to your GPU in one go, for it to remain there. When I'm supposed to splice up vertices VBO's get rather obsolete then, right? I noticed a lot of people say spatial trees should only be used for static geometry, but e.g. Yann L mentions his ABT could be used for dynamic geometry just as well. And if not, what do current engines use anyway? I'm confused, someone please help me! - Stijn
  6. Quote:Original post by jyk I think the question wasn't so much, 'Why is my context being lost?', but rather, 'Why aren't I seeing anything after the context is recreated?'. Yup. Anyway, I think you're right jyk. Deleting the OpenGL Resources before 'losing' isn't a bad idea anyway. If SDL ever fixes this issue, that doesn't mean the OpenGL context will never ever get 'lost' again. Having a simple reloadTextures() in such a case doesn't hurt. Also, SFML looks promising. I'll look into that :) - Stijn
  7. Thanks for replying, idinev, jyk and szecs! I solved the problem, thanks to you guys. It lay indeed in the not resetting of the OpenGL state correctly after switching. Quote:original post by jyk: You are right that textures need to be re-uploaded to OpenGL after the context is recreated; this also holds for other volatile resources that may reside in video memory or in OpenGL-managed system memory, such as VBOs or display lists. Code such as glBegin()/End() blocks, on the other hand, simply issue commands and will be unaffected (aside from being dependent on the overall OpenGL state, of course). What OS are you developing on? Windows? Also, if I may ask, are you only losing the context on windowed<->fullscreen switches? Or are you losing the context in other situations as well? Yeap, it was indeed the OpenGL state. Now for another important question though: Should I glDeleteTextures() all my textures before switching fullscreen<->windowed? I wouldn't want any allocated and unrefered to memory internal to OpenGL hanging around. I'm developing for Windows, right now. Not necessarily into cross-platform, I just happen to like the SDL+OpenGL combination (however, if porting to e.g. OSX would work out, why wouldn't I?). As far as I know, I only lose the context when switching from windowed to fullscreen switches and vice versa. Alt-tabbing works perfectly well, if that's what you're asking. Again, thanks for helping out, - Stijn
  8. Dear reader, Today I decided to tackle the problem of reloading my textures whenever the OpenGL context gets lost and recovered (for example when SDL switches to fullscreen or windowed -> a new window is created). However, this seems to be harder than I reckoned, because I can't get it to work. Whenever I switch to fullscreen, the simple textured GL_QUADS I render every frame disappears, and when switching back to windowed mode, it doesn't come back. Before asking any other questions; when I don't texture the quad (but just glColor3f() it), and then switch to fullscreen, the quad disappears just as well. This isn't supposed to happen right? As far as I know, I need to reload textures because they allocate memory internal to OpenGL, but a simple glBegin(GL_QUADS) - glEnd() structure does not right? Can anyone point me to the right direction and take a guess as to why my vertices disappear? Oh, and if it's any help: I clear the screen with a colour determined by the mouse position (so it changes whenever I move with my cursor). This works before I switch to fullscreen, but does so too in fullscreen mode and after switching back. I also glEnable(GL_TEXTURE_2D); after (re)setting up SDL's video mode, so that can't be it either. Thank you for reading (and hopefully replying) - Stijn Frishert
  9. Audio. Never, ever, forget that! ò_ó On a more serious note: you'd need a lot more than those three. But try and think about it yourself. Go play a game and ask yourself: what's all running in the background? What makes this experience (or breaks it by a lack thereof)?
  10. I don't think that sharing code would make it any simpler. In fact, NeHe is simply sharing code too. What seems to go wrong in the first place?
  11. First things first: don't draw anything that's not currently in your view. Of course, you'd first have to know what exactly IS in view, and what not. So, as rxa suggested: get those transformations working, then find out a way to check if something's in view or not, and if not, don't draw. May sound like a simple answer/solution, but it reduces the number of calls a lot. =] [Edited by - stenny on June 4, 2009 5:59:48 AM]
  12. Hehehe...why don't you just try it out, mate? And report back with some results? ;)
  13. Well, I guess you'll then have to flip the texture coordinates, instead of vertex coordinates, as Mars suggested.
  14. I'm not sure, I've not tried this out, but I reckon you could just scale to -1 along the corresponding axis? Something like: glPushMatrix(); glScalef(-1.0f, 0.0f, 0.0f); DrawImage(); glPopMatrix(); I know this to work in 3d applications like Maya, so I reckon OpenGL'd work the same. Hope that helped, -Stijn
  15. Yeah, that was still the old function and a quick fix. I'll change it. Thanks again, man! ^_^