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

CodeMunkie

Members
  • Content count

    1698
  • Joined

  • Last visited

Community Reputation

805 Good

About CodeMunkie

  • Rank
    Contributor
  1. [quote name='DrNicholas' timestamp='1318546365' post='4872342'] Debugger doesnt work on my computer :S I have windows 7 x64 [/quote] If you can't use your debugger, then your dev environment is broken and you need to stop programming until you fix it. Being able to step through code and look at the values of variables while your program is running is one of those basic things you just gotta have. You can either set up a dev environment where your debugger will work, or get a tool that will work properly in your current environment. I would ditch dev-c++ and get something that will work properly. CodeBlocks or Visual Studio Express would be great choices.
  2. [quote name='DrNicholas' timestamp='1318539029' post='4872304'] I did that didnt I? lol, it still doesnt work. Please just help me get it done. Thanks [/quote] Are you asking for help or do you just want someone to write the game for you?
  3. Check out the possible causes here and see if any apply: [url="http://msdn.microsoft.com/en-us/library/ts7eyw4s(v=vs.71).aspx"]http://msdn.microsof...s(v=vs.71).aspx[/url] If you can confirm that the file exists while you are building your project, then maybe it is a permissions thing. I find that things go smoother if I "Run as Administrator" when starting VS2010 (on Windows 7).
  4. Transformation, and if matrices are involved, transformation matrix. So getTransform() or getTransformation() would make sense.
  5. [code] while (true) { m_signalThreadEvent.wait(); if (m_shutDownThread) break; m_lock.enter(); std::deque<RayTestJob*> workingSet = m_rayTestJobs; m_rayTestJobs.clear(); m_lock.leave(); size_t size = workingSet.size(); while (size > 0) { const RayTestJob &job = *workingSet.begin(); for (size_t i = 0; i < job.numTests; ++i) m_simulation.rayTest(job.tests[i]); workingSet.pop_front(); size = workingSet.size(); } m_threadFinishedEvent.signal(); } [/code] Something like this would be safer. Create a local copy of the entire shared set and clear the shared set. Now you don't need to lock again until you run out of work to do when you go to get the next set. This assumes that another thread will not touch any of the RayTestJob pointers.
  6. testSprite=new sf::Sprite(testImage); You are continuously allocating memory and never freeing it. Eventually you will run out of memory. Also, why did you open a new thread for this, you already had replies to your first thread.
  7. How are you allocating the memory for your sprites and how many are you creating? Post your Sprite class and post the code where you "load a lot of sprites".
  8. I think you need to call SDL_Init before SDL_GetVideoInfo. It is safe however to call SDL_GetVideoInfo before SDL_SetVideoMode.
  9. First off, I like the idea. I did a lot of work in the VR space and I think there is a killer app out there somewhere. However, from my perspective there are two big hurdles to overcome before VR is ready for the living room: 1) HMDs are expensive. Consumer grade HMDs have been around for 10 years or so, but the prices have stayed pretty much the same. Today there only a couple of "low price" (less than $2000 US) HMDs with integrated tracking. The VFX3D from IIS (now defunct) and the z800. You can find display only solutions like the icuiti for cheaper (under $1000), but then you have to add a tracking solution. Once you start looking at Polhemus and 5DT solutions you are talking $5000++. Now consider a family of 4 who would normally sit around a single shared display in their living room. They are probably not likely to purchase 4 HMDs @ $2000 each when they get an HD 3D TV + shutter glasses for around $2000. You could argue that the VR experience is more immersive than the 3D TV experience, and I would agree, but it's going to be like arguing that the Porsche 911 is a better driving experience than the Minivan. Even if that is true, in then end it will come down to which one fits the family budget. The cost factor could go away if a lot of people started buying these displays, but I don't see that happening because: 2) The equipment is cumbersome. In my experience, people do not like wearing HMDs for extended periods of time. 30 minutes to an hour is about the limit. Beyond that many people begin to experience headaches, nausia, motion sickness, vertigo. Once the initial novelty factor wears off, people rarely ask to try it again. Another issue is position tracking. You can either use a sensor array that gives the user a fixed area in which they can walk, or you can use an input device like a Cyberpuck that the user can use to navigate. Sensor arrays obviously consume space and input devices are not very intuitive for most users. The only way VR is going to gain widespread appeal is to ditch the HMD and use only natural motion/gestures for input/orientation/position. CAVE systems try to ditch the HMD, but they take up a lot of space. You need something that can integrate into a room as easily as a television. It also needs to be intuitive to use. If you look at gaming the trend is to decrease the amount of equipment that the user is required to hold/wear and increase the use of natural gestures for input. The Wii gave us a great implementation of natural gestures as input. The Kinect takes this a step further by not requiring the user to hold any equipment. A tracking system for VR will have to be as hands-off and take up as little space as the Kinect before it will gain mass appeal. So that's the current state of the tech of VR. What we need is a break through in CAVE type display systems and position tracking that does not require an entire room for this to really work.
  10. Quote:Original post by bigbadbear9885 My big future dream is actually a very bigger thing but creating a system is a part of it. I wanted to develop a system that is as powerful as ps3 or xbox 360 or more powerful actually I wanted to it to have many many games that range from the most weakest graphics to the pressence. With the state of emulation you can achieve this today with a moderate pc setup. Just build it in a shuttle or htpc case to get that console form factor and load it up with emulators. Write a little app to let you browse your games with a joystick, plug it into your tv and play!
  11. OpenGL

    I'm glad that you resolved your initial issue. As for the drop in frame rate, I will admit that I have not reviewed your code in depth, so I can not make a direct recommendation. On one hand, I probably would not worry about a drop of 5 frames per second. On the other hand, your code does not appear to be doing anything terribly complex, so it is strange to see a drop. Did you benchmark your updated code with the GLUT version? What type of GPU are you running this on?
  12. OpenGL

    Flags like SDL_DOUBLEBUF and SDL_HWSURFACE have no effect on an OpenGL rendering context. Also, you don't define the bit depth in SDL_SetVideoMode for OpenGL, just pass 0. The only flag you need is SDL_OPENGL and optionally SDL_FULLSCREEN if you want fullscreen. You configure other things like bit depth, double buffering, etc with SDL_GL_SetAttribute (which you must call before SDL_SetVideoMode). To create an OpenGL rendering context with SDL, the correct order of calls is: SDL_Init(SDL_INIT_VIDEO); //setup OpenGL parameters SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1); SDL_GL_SetAttribute( SDL_GL_RED_SIZE, 8 ); SDL_GL_SetAttribute( SDL_GL_GREEN_SIZE, 8 ); SDL_GL_SetAttribute( SDL_GL_BLUE_SIZE, 8 ); SDL_GL_SetAttribute( SDL_GL_ALPHA_SIZE, 8 ); SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 0 ); //and so on, set other attributes here SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 0, SDL_OPENGL); You can read more here. Once you have a valid OpenGL rendering context, then you can use OpenGL features such as PBO. Since you never actually define your rendering context correctly, my guess is the speed difference is due to OpenGL having to convert from whatever the default format is to match the format of the PBO. Thus the performance hit. Use SDL_GL_SetAttribute properly to make your framebuffer format match your PBO format and I bet you will see a big improvement in performance.
  13. Which hint would you like ;)? Seriously though, you need to learn to use your debugger. It is an essential skill. In this case, you don't really need a debugger, you need to use another essential skill which is tracing though your own logic. You say your bricks start out in the "off" state. Let's solve that problem first. How do you represent the "on" and "off" state for your bricks? It looks like you use bricks[row_index][col_index]==1 for "on", and I would assume 0 is "off", but this is your code, so you tell us. So how do you initialize your brick array? In other words, before you get into your main game loop, if you were to examine your array, what is the value of each element?
  14. OpenGL and Direct3D define their interface at the application level, they don't do any low-level hardware stuff. It is up to the hardware vendor to wrap the hardware level details inside their OpenGL or Direct3D implementation. This implementation is usually shipped as part of the driver package that you install for your specific video card.