Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

805 Good

About CodeMunkie

  • Rank
  1. CodeMunkie

    Help with jumping

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

    Help with jumping

    Are you asking for help or do you just want someone to write the game for you?
  3. CodeMunkie

    Linking to a static library?

    Check out the possible causes here and see if any apply: http://msdn.microsof...s(v=vs.71).aspx 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. 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); workingSet.pop_front(); size = workingSet.size(); } m_threadFinishedEvent.signal(); } 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. CodeMunkie

    SFML slowness

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

    out of memory

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

    SDL chashes

    I think you need to call SDL_Init before SDL_GetVideoInfo. It is safe however to call SDL_GetVideoInfo before SDL_SetVideoMode.
  9. CodeMunkie

    VR game and TV production concept

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

    PBO issue using SDL

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

    PBO issue using SDL

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


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

    How does it work?

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

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!