Jump to content
  • Advertisement

siaspete

Member
  • Content Count

    2028
  • Joined

  • Last visited

Community Reputation

208 Neutral

About siaspete

  • Rank
    Contributor
  1. siaspete

    CSG, fisheye and spotlights.

    Hi Ben, Thanks for sharing your project, your journal is a good read. In my hobby project I'll need to texture map a sphere soon. I had a little look at the source code (Sphere.cs) to see how you did the mapping from polar coords to texture coords. If I understand correctly, you more or less map it as if it were a cylinder, so that the texture will appear to pinch together at the top and bottom of the sphere, is that right? Peter
  2. siaspete

    HOLY SHIT IT WORKS!!!!!!1

    Good work!
  3. siaspete

    Scan line rendering

    Hello, I was curious why you might need to use threads. I would have done something like: for (;;) { for (int scanline = 0; scanline < 160; ++scanline) { draw(scanline); run_cpu(cycles_per_scanline); } present_back_buffer(); sync_to_60_fps(); } But I may be oversimplifying the problem, it's been a while since I did any emulator programming.
  4. siaspete

    The Color Map

    Looking cool.
  5. siaspete

    How not to ask a question on a technical forum

    That's absolutely incredible. It's like every awful post rolled into one.
  6. siaspete

    MRT and GLSL : The Reply

    That's good news, thanks for the head's up!
  7. siaspete

    MRT and GLSL : The Reply

    There was also that bug with ATI drivers that leaked a small amount of memory every time you called wglMakeCurrent. Unfortunately if you wanted to write an OpenGL + wxWindows editor, you'd leak that small amount of memory every frame. In my project that added up to a couple of MB per minute. Imagine using the editor for a few hours! While attempting to report it to ATI driver support, their site kept crashing and timing out, deleting my bug report. I gave up and vowed never again to go ATI. I tried, dear God I tried, but sometimes it seems that companies just don't want to improve.
  8. siaspete

    volatile auto_ptr

    I'm fairly sure you can override libpng's default "oh crap!" function with your own, so that might help. In this case you may want to throw an exception or something. But it's been a while since I worked with libpng so I can't say for sure.
  9. siaspete

    Normal to Parallax to Relief

    Quote:Original post by jollyjeffers Think you'd be interested in my proposed progression through lighting resolution/techniques? Yes!
  10. siaspete

    oops

    If the only member of the struct is that union, you could just take the outer struct out of the picture entirely, leaving a named union.
  11. siaspete

    Ships comparison, persp. sheet

    Which handles better, the battleship or the church?
  12. siaspete

    I'm alive

    The "Break On AllocID" box in the DirectX control panel works well for finding what is leaked, providing you get the ID from the debug pane after your app closes, but I don't know if that's FAQworthy. Edit: I would also strongly recommend using Boost "intrusive_ptr"s as smart pointers for wrapping COM objects, but you have to be careful since their default constructor adds a reference.
  13. siaspete

    Resizing the Client (win32)

    Have a look into the AdjustWindowRect function - it should do what you want.
  14. siaspete

    A discussion about fixed time steps

    Quote:Original post by Ysaneya And you did not suffer from the problem i described ? When your framerate starts to slow down, it makes the number of physics steps explode.. My physics was very simple, so the number of physics steps per render was pretty stable at low frame rates. Something like 10 updates per draw. It was the draw which was slow, so that didn't matter. Quote:Original post by Ysaneya I've already read that article you read to. I find it interesting that he says you should understand all the "subtleties", calls his technique "perfect" and recommends it for "all game systems" ... Yes, you're right there - it's clearly neither.
  15. siaspete

    A discussion about fixed time steps

    Reading over your post again, it seems that the problem is that you can't guarantee that on average your do_physics takes less time than your timestep, which is an unwritten requirement for fixing the timestep. I can only think of two solutions: 1. Optimise do_physics to take less than a 100th of a second. 2. Reduce your update rate, to say 50/second instead of 100, depending on your preference. With complex physics becoming more present in modern games, a good solution to this problem would be very handy. Anyone got any other ideas? Pete
  • 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!