|
|
stbenge wrote:
> Hello everyone,
>
> I made a game demo featuring a near-infinite landscape. I say
> "near-infinite", because computers as they stand now cannot produce a
> string of random numbers which do not repeat. But you can get close, so
> close in fact that I bet you will never see my demo repeat itself.
>
> Here's the file:
> http://www.caltel.com/~abenge/NearInfinity.zip
>
> And a screen shot:
> http://www.caltel.com/~abenge/NIscreen.jpg
>
> You can change many aspects of the program via "NI.ini", included in the
> zip.
>
> You will need DirectX 8.0 or higher and the Windows operating system to
> run this program.
>
It doesn't work on my win2000 machine. reinstalled DirectX 8.1 but still
no luck. I get the HGE splash screen followed by a notice that NI
generated errors and that I had to restart the program. NI.log does not
seem too informative:
HGE Started..
HGE version: 1.70
Date: 26.03.2008, 22:53:37
Application: NearInfinity 2008 Sam Benge
OS: Windows 5.0.2195
Memory: 1048032K total, 453348K free
D3D Driver: nv4_disp.dll
Description: NVIDIA GeForce FX 5200
Version: 6.14.10.9371
Mode: 640 x 480 x X8R8G8B8
Init done.
Post a reply to this message
|
|
|
|
andrel wrote:
> stbenge wrote:
>> I made a game demo featuring a near-infinite landscape. I say
>
> It doesn't work on my win2000 machine. reinstalled DirectX 8.1 but still
> no luck. I get the HGE splash screen followed by a notice that NI
> generated errors and that I had to restart the program. NI.log does not
> seem too informative:
Hmm, that log file is never very informative :(
What video mode are you running under? More specifically, what bit
depth? My program runs under 32 bit color, but I didn't consider making
it changeable since HGE seems to always detect the right mode. I can
think of one other problem which might be causing the error, but that
will also require a new release....
Sam
Post a reply to this message
|
|
|
|
> 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
|
|
|
|
stbenge wrote:
> andrel wrote:
>> stbenge wrote:
>>> I made a game demo featuring a near-infinite landscape. I say
>>
>> It doesn't work on my win2000 machine. reinstalled DirectX 8.1 but
>> still no luck. I get the HGE splash screen followed by a notice that
>> NI generated errors and that I had to restart the program. NI.log does
>> not seem too informative:
>
> Hmm, that log file is never very informative :(
>
> What video mode are you running under? More specifically, what bit
> depth?
1024*768*32 bit (first generation flat screen)
> My program runs under 32 bit color, but I didn't consider making
> it changeable since HGE seems to always detect the right mode. I can
> think of one other problem which might be causing the error, but that
> will also require a new release....
Your 'Lights Out' and 'Maze' do work here.
Post a reply to this message
|
|