• 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

383 Neutral


  • Rank
  1. Try without the Entity:: part. Unless you have overrrided/hidden the function, there is usually no need to qualify a call to a base member function with the name of said base class. Entity::update has no problems as CrawlerTurret hides the Entity::update function, so by calling Entity::update the compiler knows which version you are trying to call. As was said above, looks like GCC is trying to find a static function called collision_correction. Weird bug, might want to report it as I'm not sure if it's proper C++ behaviour (assuming you can replicate it with test code).
  2. If you're using VS2010, you can use static_assert instead, i.e. Vector(T x, T y, T z) { static_assert (N == 3, "Too many arguements passed"); c[0] = x; c[1] = y; c[2] = z; } static_assert either gets resolved immediately if in non-templated code, or when the template class/function is instantiated. It's much cleaner to read than the array trick, but requires an up to date compiler as it's part of C++0x. And obviously, unlike normal assert it fires off an error message at compile-time rather than runtime. If you want something that will work on older compilers, you can use http://www.boost.org/doc/libs/1_43_0/doc/html/boost_staticassert.html
  3. As per the OpenGL references, gluUnProject4 is only available on GLU version 1.3 or higher, so basically good luck using it on Windows. As per a previous thread (http://www.gamedev.net/community/forums/topic.asp?topic_id=516284&whichpage=1&), you can get the source code to this function from MESA.
  4. Quote:Original post by dm_3xJust don't know why the program won't quit when I hit the close button. :[ Because the quit message is sent to the thread that created the window which in this case is different from the main application. You need to have a message pump (PeekMessage, TranslateMessage, DispatchMessage) running on the window thread. When it picks up WM_QUIT, it needs to somehow signal the main thread that the application needs to close. I did this by having the window thread exit, and the main thread repeatedly checking to see if the window thread has stopped running (if so, we know it encountered a WM_QUIT message). This is an absolutely terrible way of doing things for anything more sophisticated than a simple demo for a forum :) Good luck, and welcome to Parallel Hell :)
  5. Quote:Original post by jyk Quote:Original post by MENTAL Most vector implementations are smart - if you hit your limit and need to allocate more memory, it would just allocate enough memory to hold one more object.Did you mean, 'it wouldn't just allocate enough memory to hold one more object'? Ahem... thank you.
  6. With a vector, you can reserve memory to begin with. So if you know that unless in extreme circumstances you'll never go above 50 objects in the vector at once, you call myvec.reserve (50) and it will preallocate enough memory to hold 50 objects. You can then push, pop and erase to your hearts content without having to worry about vector allocating anymore memory until the moment you try to make it store 51 objects, at which point it will create a new batch of memory big enough to hold 51 objects (more on this in a moment), copy the old objects over and delete the old memory. Most vector implementations are smart - if you hit your limit and need to allocate more memory, it wouldn't just allocate enough memory to hold one more object. It might increase the maximum number of objects it can hold by 10%, 20%, 50%, 100%, whatever. The standard doesn't dictate the maximum it can grow to, only the minimum. So your vector with 50 objects in it might be resized to hold a maximum of 75 objects, meaning once you push object 51 onto it, you can push another 24 objects before it needs to reallocate (and then might reallocate to 112, i.e. 50% extra of 75). If your vector is unsorted, the quickest way to erase an object from anywhere but the end is: 1) Overwrite the object you wish to erase with the one at the end of the vector 2) call pop_back, which will destruct the old version of the object you just moved. anyway, to answer your question, for small amounts of objects or when you know roughly how many need to be stored, a properly managed std::vector is probably the best solution providing your copies are lightweight. [Edited by - MENTAL on May 11, 2010 4:10:18 PM]
  7. Instead of using the wgl* commands directly (which are Windows only), you'll have to write a wrapper that calls wgl* when compiling for Windows, GLX* when compiling for Linux, whatever the Mac uses when compiling for MacOS, etc. Quote:So why use SDL? Because it's a nice library.
  8. As I said, custom builds. More than likely you're only using a limited subset of that DLL, so you might as well compile out the rest of it (wxWidget's Setup.h is your friend :)).
  9. wxWidgets doesn't need 8mb of DLLS if you do custom builds with only the controls/libraries you will actually use :)
  10. Yep, triple-thread system working: http://depositfiles.com/files/g9ldeumax (again no project files, and the code is even more horrible and may include resource leaks for windows thread handles). Main Thread 1. Starts Window Thread. Control doesn't return to Main Thread until the window has either been initialized successfully (go to 2) or failed (exit). 2. Starts Renderer Thread. Control doesn't return to Main Thread until the renderer has either been initialized successfully (go to 2) or failed. 3. Sits in a loop checking to see if Window Thread is still running. If so, do game logic. If not, go to 4 4. Stop the renderer. This will cause the Renderer Thread to safely exit, and the renderer will be shutdown fully. 5. Stop the window. If the Window Thread has already exited, this still needs to be called to actually destroy the window itself. Window Thread 1. Create window 2. Message loop until WM_QUIT is received (either from closing the window, or from having Main Thread call Stop when it is still running). 3. Exit the thread. Window Thread will not clean itself up if the window is manually closed due to the renderer needing to be stopped first. A call to "Stop" must be made at all times to fully free resources. Renderer Thread 1. Init OpenGL 2. Sit in a loop drawing until it's Stop method is called. It's horrible horrible horrible but it works. A proper message/event system is far more efficiant for passing things back and forth between threads, but this is just a proof of concept :).
  11. Quote:However, there is one interesting I found, in 3 threads structure. If all those register window class, create window function are NOT done by the window thread but called by the main thread. And then you create a thread that only takes the windows message and try to pump in to the WndProc. You'll see the OpenGL is drawing but the window isn't responding at all. That's the what I call the "semi 3 threads". You can try it if you've time. Yep I encountered this one too. This is because Windows sends messages to the thread that created the window. Hence, if you're trying to do the message pump in another thread, it won't do anything as that thread won't actually have the messages sent to it (the messages will be sitting unprocessed in whichever thread made the window). I'll give the triple-thread approch a try to see if I can get it working.
  12. You can do it with 3 threads if you really want. However, you must have your message loop (Peek/Translate/Dispatch) running in the thread you created the HWND in. You would have to organise it as so: Main Thread: Starts up the Window and Renderer threads in order, then goes into a loop doing game update stuff. Window Thread: Creates the HWND (and HDC if you want). If successful, operates the standard message pump until WM_QUIT is received. In order to ensure the correct order of deinitialization, it would have to either stop the Render Thread itself, or notify the Main Thread that it's time to close the application. As far as I am aware, it is perfectly safe to call DestroyWindow from any thread. Once WM_QUIT is encountered, you could have the Window Thread exit (and notify the Main Thread of this). Main Thread can then stop the Render Thread, and then call a Shutdown method on the window (this would execute on Main Thread). Render Thread: Calls wglMakeCurrent (and can do anything starting from GetDC if you want), and then goes into a loop drawing stuff until told otherwise. This thread must be created after Window Thread is fully initialized, and stopped before the HWND is destroyed. wglMakeCurrent (NULL, NULL) must be called from the Render Thread. wglDeleteContext can be called from any thread. To be honest, the reason this kind of system isn't used much is because it introduces a lot more headaches due to having the message pump on it's own thread (and dependant on Renderer as it has to shutdown in a specific order). Either having the pump running on the Main Thread is the common way, or in the Render Thread (along with all window creation stuff). Although I can't see why you want a 3-thread system (unless this is just an experiment), it certainly is possible. edit: a slightly simpler approch would be to start the Render Thread from the Window Thread. As the Window Thread would have full knowledge of the renderer (this is a one-way relationship - all the renderer needs to know is the device context), it would be far easier to structure the code. You would still need a way of signalling the main thread to stop accessing the window or renderer however, otherwise you could (and to be frank - will) get access violations.
  13. All done: http://depositfiles.com/files/sjs7m5yog (no project files as you might not be using 2010 - just create blank Win32 project, add these files, and compile). Steps you need to follow: 1) CreateWindow has to be called on the thread that your message loop will be operating on. This is because window messages are bound to the thread that created the window. 2) wglMakeCurrent has to be called on the thread that you with to do the drawing on. This is because the rendering context will be bound to that particular thread, and OpenGL will refuse calls from any other thread. 3) Initialization can not be properly parallel. You need to create the window first on your main thread, then create the renderer thread, and then do the wglMakeCurrent commands. 4) The code provided is a bit hacky but is designed to show the basics. For production code (my app is MT but I have the renderer running on the main thread so didn't come into these problems) a proper message-passing system is needed. For this, I abuse critical sections and member variables to pass data back and forth instead. 5) You can call GetDC and all the pixel format functions, right up to and including wglCreateContext on any thread you like - whether you do it on the main or render thread (or even make another thread just for the lulz) is up to you. Just make sure you adher to #1 and #2. 6) This was tested using 2010 Express 32-bit on Windows 7 (both Debug and Release mode). The casting to Get/SetWindowLongPtr is probably wrong for 64-bit mode, as is possibly the cast for ThreadProc. Hope it helps. This is the easy part - safely passing information back and forth between your main thread when you create/move/modify objects is where it really starts to get interesting :P Suspending the renderer thread and having it only draw frames when instructed to by the main thread is an exercise for you :)
  14. It's your coding. I've put together a basic spinning window demo by hacking apart the nehe base code. All rendering is done in a child thread but window creation and the message pump is in the main thread. I'm just tidying it up as the code is an absolute mess, and then I'll upload it. Will be another 3-4 hours as I'm going out for a Pizza :P
  15. As was said in the other thread, you can only use opengl on the thread the render context was created on. Try creating the entire window + setting up OpenGL in the render thread. That should allow OpenGL to run in your child thread while you do your normal stuff in the main thread. You can even have the event loop and WndProc running from the main thread (indeed, the WndProc function is called from whichever thread your message pump is running in), just create the window + render context in the GL thread. edit: Also, if you're setting up your Viewport and perspective by responding to window resize events, chances are you're calling those GL functions in the main thread and not the render thread. You'll have to find a way of notifying the render thread that the window dimensions have changed, and have the render thread do the appropriate glViewport/gluPerspective calls at the start of each frame (providing there has been a change from the previous frame).