Hey, nice demo. I really liked your physics. I know youre not done with it, but here is some feedback.
When you are dropped onto the map, you slide around the hill until you hit something or are in a depression. Players shouldnt be affected that much by physics. Also, every 10 seconds or so I fall through the map and then fall back onto the map. If I go to the very end of the map, then I get stuck, and the camera gets askew. If I try to move left or right then the program crashes and throws a gpf.

There is collision detection between the player and the ground and trees, but there seems to be no collision detection between the player and the fortress.

I was running that demo on a P3 1GhZ, w/ 128 mb RAM and a GeForce2 GTS 64MB DDR


But, like I said before it is a nice demo, and I really like the physics work you have done so far. The sky is very nice too.

Regarding your skybox technique: Wouldn't it be easier to just draw the skybox as a textured sphere, or part thereof?

I have a few comments on the game. The first thing is that you use a weird format to distribute the game. I don't have a program that decompresses ace files. Use zip, or tar.gz, or some sort of standard. Sice I couldn't actually play the game, I only have one further comment.

The controlls were ill considered. Although they may work fine for you, I have an egronomic keyboard. This means that your movement controlls are split right down the middle.

There is some considerable tiling there. Maybe you should go with larger textures, or unique texturing over your entire landscape.

Another aproach would be to use a "filth map". You have a texture that is basically a very bright texture with small variations in color. It's supposed to be grayscale. Then you render that on top of the other texture with multiplicative blending. If you scale the filthmap to an odd size (such as 7.42 times the original) and rotate it att an odd angle (completly arbitrary, like 33.12 degrees for instance) you will reduce the perceived tiling considerably.

You can have many layers on the terrain to get cool effects. Like one "color layer" one "shadow layer" one "detail layer" and one "filth layer". Just scale them differently and at different angles and you won't get any repeating artifacts.

Oh, and couldn't you sphere-map a cube to get the same effect? For the clouds I mean.

This demo looks good, although there are a few problems: as other people have said, the gravity is a bit strong, and there are problems with falling through the map and going over the edge (the first problem could be from the strong gravity). The movement keys are a bit hard to find, and since I have a Microsoft Natural keyboard, G is not in the same area as Y, H, and J.

The effect of the sun going behind the clouds looks very good. Do you just check what density of clouds are in front of the sun and use that to set the size of the glow? The clouds look good, although I don't understand your description of the rendering. Are you raytracing the whole sky, or just raytracing blocks (Oni uses this to render everything)?

Nice. Nice and fast too and I like the physics they feel really natural. Any chance of seeing any source code? I'm working on a terrain engine myself right now and I'm curious as to how you do a few things..

Nice, but one thing I hate... the inverted Y axis... Some people hate it, some people like it. I hate it. You're not playing a flight simulator! This is an fps!

But still, the skybox is very nice, with the multiple layers and all. Everything is nice, the terrain is good!

I downloaded your file, landscape.ace, but I am having trouble opening
it. First of all, what is .ace? What do I need to uncompress it?
Sorry, but I've never heard of it. :)

You might want to use a more commonly known compression format like
.zip instead.

Ah, nevermind. I got it. Winace. I remember using it before. :)

hey, ACE for mat is pretty standard nowadays. it is a very good compression program that handles all sorts of formats.

Thanks for the comments.

bit64:
yeah, there are a few bugs near the edge of the map. I am re-writing the part that chooses the part of the map to draw (as well as just about everything else :) ) The collision detection is just pretty poor, and the user is just a point on the ground. The camera is then shifted around 1.5m higher then that. This means that you can sometimes walk under the edge of the castle (which may be above the land), and sometimes the colision detection just buggers up.

fluffy:
With a textured sphere, depending on where you look, you must draw different levels of triangles. I wanted to try having a fixed number of triangles.

shrike:
sorry about the controls. It is just what I use for all the fps i play, and didn't think about other keyboards... As for the ace format, I was going to use that or rar, because of the better (i think) compression. I'll put up a link to a decompressor (www.winace.com)...

Sebastian Sylvan:
Thats a good idea, and I am trying to put it in now. Do you know of any problems (for a noise/grass map) of using a texture map (with alpha) and vertex alpha, with an alpha test, to vary the level of grass over the landscape (depending on things such as height)? My banshee doesn't like a few things (like single pass multi-texturing... doh!)

krogoth
The files .skb in the sky transparency directory are just a 256*256 map of the cloud intensity (much like the texture is). I find where the sun is on this map, have a look at the density at this point, and adjust the flare alpha accordingly.

The points on the screen are a 4*10 grid, and the texture coordinates of each of these points are gained by casting a ray towards the sky, and from the intersection point tu and tv are calculated.

morgar
I might release the source later, but not till I tidy some things (and totally change others)

again, sorry about the ace. you can download a decompressor from www.winace.com

As nobody else has mentioned it, I assume other peoples input works alright. On mine, the input is no good at higher frame rates... I guess it is just some wierd configuration on my computer.

Finally got it running, but I had a problem with your demo.
All the textures were white. But the log file said I got
at least 32.569736 fps :).

Since the demo runs in windowed mode, I had to chage my display
resolution to 16-bit. I tried it in 24-bit at first, but the log
file said it couldn't create a z-buffer.

I'm running a P3, 800x600x16, Intel 810 AGP, 20 MB VRAM.

I have uploaded a zip file, which is around 2.8 mb. Also uploaded is a different executable, with different controling keys (up/left/down/right/pgup/pgdown).

Hemp
I had the same problem when I tried it a different computer. I think it is because of texture compression. I don't know if the Intel 810 AGP drivers support it... As for the z-buffer problem, can it handle 32 bit zbuffering? I run it in a windowed mode because my initialisation doesn't work to well in full screen (it doens't go full on full screen... there is still the window edge around the side)

My card only supports 16-bit z-buffers. Perhaps that is why my
display resolution must also be in 16-bit as well.

And I think you are correct about the texture compression. My
card doesn't support DXT1, DXT2, DXT3, DXT4, or DXT5. It seems
you have to do the decompression yourself.

From the DX docs:

"If the device does not support texturing from compressed texture
surfaces, you can still store texture data in a compressed format
surface, but you must convert any compressed textures to a supported
format before they can be used for texturing."

For DX7, you have to call EnumTextureFormats() to test for support
for compressed texture surfaces.

If you were using DX8, you could use CheckDeviceFormat() and pass
the compressed format as a parameter to check for support.

To be absolutely safe, I would recommend enumerating all pixel formats
and all texture formats, and checking for support where appropriate.

Nice terrain. How do you find quadtrees? slow, efficient, ... ?

I think my method is similar to a quadtree. All my data is split up into a grid, with triangles referencing into this grid. I draw certain parts of the grid, depending on what the camera is doing. One grid co-ordinate can have loads of points and triangles associated with it. I think this is similar to (or is) a quadtree. I find it very good for this sort of landscape (where the land will not be just a heightmap).

This is a very good start, if not further than that. I hope someday to be at this point with my ideas. I'm a long ways off. You are definitely on your way with this one. I dont know if anyone mentioned it but the character can back up out of anything.

Again, I enjoyed your engine. Just to be able to run that fast :)

Dave

dave, I don't reckon you should try to make your stuff go fast. Try to make your stuff do some cool things (like adding in stuff to do...). I'm trying not to optimise anything beyond having nice data structures, and it runs nice and quick on mine (without vertex buffers). With the backing up, if you look upwards and press forwards, you can fly. (ie: input works anywhere on the land). oh well... be fixed when I put in better collision.

Oh, I know this is a work in progress. It's very well done. If I can get THIS far someday, (I'm a seasoned web/VB programmer trying to make the move over to C++ and directX. I'm currently learning 3D Studio Max as well) I'll be excited. I hope you know I meant no lack of respect, because this is very well done. As far as speed goes, I see what you mean. Just so you know, I got around 47 - 62 fps on my VooDoo 5 card when I checked the log.

Dave

Hmm.. Maybe you should try some hierchial frustrum culling instead. You said you divided your landscape into a grid, why not do that hierachially (sp?), first your landscape is one huge square, then you split that into 4 new squares, then you split those into 4 more squares etc. etc. then when you cull against the frustrum, if a square is outside it, you can discard all the squares within that square...

Anyway, that's what a quadtree is.. Read a little about it, it would speed things up quite a bit I would imagine...