POV-Ray : Newsgroups : povray.off-topic : NearInfinity game demo : Re: NearInfinity game demo Server Time
1 Oct 2024 15:20:54 EDT (-0400)
  Re: NearInfinity game demo  
From: scott
Date: 27 Mar 2008 03:28:45
Message: <47eb5abd$1@news.povray.org>
> Thanks! Is the collision detection too bouncy? I kind of like it that
> way, as it makes the game feel "softer".

No, I like it too, it gives a different feel to the game (more fun) rather 
than if you just exploded or got damage when you hit into something.

> Thanks, I will read that. I tried to implement a lower limit to the FPS,
> but everything I did resulted in an exponential speed increase, hence my
> crappy patch in the config file. At least I'm learning to control the 
> framerate without compromising functionality (ie. collision detection).

The key is to run your physics calculations (movement, collision detection, 
etc) totally separately from the graphics.  You do your physics calculations 
with fixed time intervals (eg 50 or 100 times per second, whatever is the 
minimum needed), and just draw the graphics as often as you can.

> I thought all monitors were backward-compatible.

Yes, but 640x480 looks very poor on a 1920x1200 24" LCD ;-)  And very small 
when it's in a window.

> What resolution would
> you suggest? 1280x880?

In my programs (when running full screen or switching to it) I usually start 
by running in the same resolution that the desktop was in.  Then you can be 
sure that is working, and always give the option to choose some other 
resolutions.

> I think maybe I could get away with having a
> variable resolution, as it appears any speed bottleneck occurs when more
> pixels are drawn to the screen. A person could choose a lower res if a
> high one is too slow.

Yes, your game looks like it uses a very small amount of geometry as I 
assume all the sprites as just drawn as two triangles.  So the limiting 
factor will be the pixel throughput of the graphics card, then of course 
higher resolution will mean lower frame rate.

> That's a good idea. It is possible to do this, and I could change the
> color at each corner of every sprite for a smoother look. Maybe I could
> do it with a perlin noise function, although the only one I found repeats 
> rather quickly, hence my question in p.programming.

If I understand Perlin noise correctly, you can just scale it up and then 
add more iterations to keep the same fine detail level?  This would increase 
the repeat length.

Or just generate some number based on the x,y coordinate rounded to the 
nearest (say) 1000 pixels, then use those values to interpolate the colour 
for all other pixels.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.