Working on a game...
 

Thought I'd post something here and resurrect this area. Anyways, I'm working on my own little project that will eventually turn into a game engine - just got a level editor to the stage where it can export enough info for a map (it basically does texture management, terrain editing, add some planes [e.g for water], and a player start location) and I'm now working on visibility culling & map compiling, from whence I can start working on the rendering pipeline of the engine in earnest.
Anyway, if people are interested, let me know and I'll set up a sourceforge site or something (warning: I'm on a 56k modem here, so I'm limited to putting up source code and very small files!).

Re: Working on a game...
 

Maybe an SF/BerliOS site would be nice and some screenies :)
Also is it (going to be) cross platform? :shifty:

Re: Working on a game...
 

well if the software is cross-platform you can also try http://sv.gnu.org as this one doesn't have any annoying advertisements, and the project hosted there is not as many as sf.net, so it could be a little faster than sourceforge.net for 56k modem :P

Re: Working on a game...
 

hmm sounds intresting. I can also provide you hosting if you wish.

A little more info about what the game will be like would be more helpful.

Re: Working on a game...
 

Not entirely sure of the game yet - working on the engine first - but I do know it'll have outdoor terrain, as I for some reason enjoy working on that.
And yes - it will be cross platform. Using the fox gui toolkit for the editor (www.fox-toolkit.org) [which actually has some problems getting to run under MacOSX, unless the OSX x11 server is installed], and SDL for graphics of the engine itself. When I eventually move to sound, I'm thinking OpenAL. License will be lgpl, when I actually put the right stuff in the source files, and make everything comply.
I'll organise some screenies of the editor and post them up tomorrow.

Thanks for the feedback!

Re: Working on a game...
 

Having problems attaching images. Can't paste any links to any as I don't have any web space! Please have a little patience, I'm working on it...

Re: Working on a game...
 

Though somewhat small, some pictures. I'm working on octree generation at the moment, and will be putting it into the engine as soon as saving it to file is finished! The pics should be attached - if not, then I buggered up!

Re: Working on a game...
 

Well I've been absent for a while, but I'm still working on my engine. I've come to some realisations about what I want with it, and thought I'd just post a few thoughts here.
I want to make something worthy of "ooooooh"s and "aaaahhhh"s.
Anyway, I haven't browsed the source code for heaps of other engines (the quake series for example) because I'm making things the way I want to, not the way other people _used_ to do it. Starting from the beginning with programming is often a good thing because of new technologies, and I also learn more this way. Once I have a foundation laid out, then I can look into other people's work for inspiration (rather than for emulation).
All that laid aside, I'm going to spend at least 1.5hours a day programming (I'm flexible here of course - it may not be appropriate some days), and in a month I'll put whatever I have up on the net (I say a month to give myself a time frame - pressure is a good motivator).
Right now I have a basic editor, and I'm working on basics of the engine itself. Momentarily distracted because I thought of a faster method to drawn terrain, I'm working on generic and terrain-specialised line intersection tests (useful for determining if something is at ground level or not). After that I'm going to work on environment modification (water at first), simple shapes (crates, that kind of thing), and solidifying the internal tree structures to best manage it all.

Re: Working on a game...
 

Been a month since I last posted here, and I've got a lot done - and realised to change a lot! I realised earlier in the week that I should change some internal tree structures - doing so will effectively halve the rendering time and almost double the frame rates.
Anyway, if I can think of a name for the engine and associated editor (any ideas?) I'll try put them up on sourceforge, otherwise I'll just put some tarballs on my webspace.

Re: Working on a game...
 

How about YAE - Yet Another Engine? ;)

Does it have anything specific over other engines? If so, it would be easier to come up with a name :)

Re: Working on a game...
 

Re: Working on a game...
 

3 basic questions:
1)Are you using Directx or openGL?
2)Does your Engine support loading external 3d map files Like Vrml or Autocad files?
3)What about physics , how do you simulate it?

Re: Working on a game...
 

At the moment, it loads some terrain, and renders it! I was about to start integrating some crates bouncing around the place, as some of the physics codebase is in place, but decided to re-write the quadtree structure. So it's not really even alpha yet...
Uses OpenGL. I like things to run across multiple platforms, so I've been using SDL.
What I have right now:
Texture management (re-loading a texture package from file still needs to be done).
Terrain quadtree system (optimised for rendering, working on additional structure optimised for physics which will be used in conjuction).
Basic sphere-sphere, sphere-cone, object-aligned bounding box collision is in place.
Camera system is in place (multiple viewport support will be added eventually!)
Loading a font (that's about it - I'm also going to work on a 2d-gui outline one day).
-- Note: I'm doing the lot from scratch. May use things like ODE for some physics stuff, but anything like a 2d-gui system, I'll build myself.

I'm making an editor in parallel to the engine, and use my own file format. But I have written code a long time ago that should load most *.dxf meshes, and *.3ds, which would be simple enough to incorporate into the editor.

For more useless info, feature wise, I've been approaching it with the view of re-making some old games, and designing something that could be used in all of them (from Mechwarrior 2, to Space Hulk).

Re: Working on a game...
 

you have ambitious plans I See:)
I'm not the very expert in this Area , but wouldn't it be easier and more straight forward IF you create a 3d interface using direct3d ?
because then you wouldn't have to worry about lighting ,rendering , shading , camera stuff etc.....and all those great feature that come with Directx.
in other words your engine would basically function like a 3d graphic displayer , then you have to add collision detection and you are done for the beginning;)

you surely have more experience than I do because i never tried to program a game engine or anything similiar , maybe I'm totally wrong about this.
but hey! Life is always forth a gossip...:yinyang: LOL

P.s have fun , enjoy and Good luck

Re: Working on a game...
 

Ambitious maybe, but every single game engine (from Jazz Jackrabbit to Doom3) had to start somewhere!
Using d3d wouldn't make things more straight forward - d3d is just a rendering api, and it's specific to Windows. As a programmer, you need to specify the lighting, the shading, etc, camera setup, etc, and use the api to interface with the hardware. The api, be it d3d or OpenGL, will take care of things like mapping a given input (in 3d space) into the required 2d screen co-ordinates for rendering (remember, it may look 3d, but it's still just mapping a 3d scene to a 2d display). For example, the programmer sets up the view, and specifies where to draw a crate in the world, what textures to apply, uv co-ordinates, and maybe some shading. The rendering api will take the data of the crate, and transform it into an on-screen display. The on-screen display will appear different if the camera system you've set up tells the rendering api whether you're looking at the crate, or away from it.

Hope that makes some sense....
Anyway, major reason for stearing clear of d3d is that I want to run it across multiple platforms (even MacOSX, though I need to buy a Mac first) natively (no emulation). So OpenGL is the way to go.

Re: Working on a game...
 

I'd like to be added to the list of testers, when it eventually gets drawn up. Have you considered talking to some of the bot coders for a built in AI system? (I know that'd be a long way in the future)...

Re: Working on a game...
 

A relatively long way, but I have started to think about parts of the design to allow for A.I. For example, the controller setup is such that any glob (Game Level OBject - just to sound cool) can be controlled via a controller. Whether that controller is human or computer doesn't matter, and it allows for a glob's controller to be easily swapped between human and computer. It also makes for easy scripting of globs. A glob is basically any object - light source, crate, player, bullet, etc. I did have interesting thoughts of a person looking at some crates, then one of them suddenly jumping up and bouncing around the place.
But I will be talking to the bot coders more once the physics is more concrete, as I want to know fairly early on what would make the task of A.I programming easier!

Re: Working on a game...
 

OK I'm understanding your point , Mirv:chef:
Actually that gets us to another very important aspect ...You are making a game engine, correct?
So do have a play scenario , gaming concept , a story based adventure or something like that?
or is it more of the flavor of a simulation software?
If you ask my opinion about how you can make life easier for AI coders , then I would recommend that you orient yourself by Webots (It's a great software indeed:clap:)

Re: Working on a game...
 

Spent some time looking into physics libraries - I'm learning "bullet" at the moment, but I'll keep things modular enough to allow for PhysX when it has linux support. Hopefully soon I'll have a few boxes you can push around some terrain. And cloud shadows moving across the terrain if I delve into manipulating OpenGL's texture matrix.

Re: Working on a game...
 

Sounds really nice , mirv!
keep me updated.

Re: Working on a game...
 

Still working on those darned boxes. I've decided to have physics being heavily integrated into the engine - I have the theory that physics hardware can deal with the extra calculations. I think that rather than using such hardware for lots of particles, etc, I'd rather have more user interaction with a scene - for example, in a forest, I'd like to be able to shoot branches down and stuff.
Anyway, when I work on things, I'll keep the updated here.

Re: Working on a game...
 

What do you mean with heavily integrating physics in your engine?
do you mean that you are starting your own physics simulation or are you still using bullet that you mentioned in a previous post?

anyway , the idea of moving the physics to a specialized hardware is a great idea as you suggested !:)
it would allow because of the higher processing capabilities , much more detailed simulation ......like you would be probaply able of simulating a model(like a tree or car ,etc...) as many smaller models , you would have a group of tiny models which are processed independently that together form up the bigger one(car,human,tree,etc...)

and then if the car for example crashes the individual smaller pieces of the car would fall apart or even deform like in a real accident!

As someone said : imagination rules the world!

Re: Working on a game...
 

Quality rather than quantity. Stuff like grass moving as you pass by, blowing bits off a car and using it, etc etc etc.
Of course, dealing with collisions and physics is one thing, what to do with it all once you know it's collided is another! But I figure with the extra cpu cycles saved on physics, that kind of thing can be taken care of.

Re: Working on a game...
 

Anyways , you are the Expert when it comes to Graphic Engines...
I think the extra cpu cycles saved after implementing hardware acceleration for physics could be employed best for some kick-ass AI:)

Re: Working on a game...
 

In Germany, and will be getting back up to work on the engine again soon (kudos to Nova for my beast of a machine, and nice monitor, both of which I will find very nice for programming).
Anyway: question for A.I guys - would it be useful to have a way of quickly determining what dynamic and / or static objects are close to a character? I'm thinking of making an octree with one object per node for things like that - I figure it would be useful in visibility culling, but is kind of overkill for that, and might take time to sort it and keep it "nice", but if it would help for a.i then it would be worth it!

-- Ignore this, I was tired.

Re: Working on a game...
 

Just letting folks know I haven't stopped working on things - I'm getting back into it any day now, once I have my spatial storage method sorted out in my head.

Re: Working on a game...
 

Small news update (nobody minds me giving one I hope) - spatial tree is starting to stand. Memory footprint is about 3.7MB for handling 50,000 objects (400kB less for 32bit systems), however it doesn't handle dynamic memory too great - set the tree at startup, and don't put in more than it can handle basically. Startup for that many takes some time (12 or 13s, but that's including some texture loading) - so dynamically moving 50,000 objects in & around the tree may need some work.
Anyone know that if, in theory, replacing ~21 +/- operations with one square root and a couple of +/- operations is better? I've had it drilled into me so much to avoid square root functions that maybe I'm over-compensating.
edit -- it's not better, it's much slower.
edit2 -- no, I was wrong! turns out constraints on node spatial size were causing an unbalanced tree. Different algorithm using square roots allows tighter constraints and (I think...) a better tree, resulting in a load time of about 2s now.

Re: Working on a game...
 

Cool
Don't hesitate on screenies ... :)

Re: Working on a game...
 

I won't when there's something more interesting than 50,000 grey boxes on the screen. Still working on my spatial tree - it's a rotten bugger to get balanced, though (I think and hope...) once balanced it's easier to keep that way due to locality of movement. So I'm focusing on repairing it when it's out of whack (aka rebuilding below a given node).
Good news is that it doesn't just apply to visibility culling, but overall determination of nearby "stuff" should be simple - and that is of value to many aspects of a game engine I believe (a.i, physics, rendering).
Back to it...

Re: Working on a game...
 

Another update: my visibility tree is coming along very nicely. I just finished some code to rebuild the tree when unbalanced (only to be done when there's free time), which works just fine (near as I can tell). And a balanced tree improved my test bed framerates substantially for viewing only smaller areas - though as expected it was a tad slower if I tried to view everything at once.
Now to stress test the new "balancing" code and see where it breaks, and more of the fun that is debugging.

Re: Working on a game...
 

Hi mirv (been a while since i posted here O_o),

I've been following your progress with great anticipation, just thought i'd log into my old account to voice my support, keep up the great work ;)

Re: Working on a game...
 

Thanks for the support!
I'm still poking away at my tree structure. It's nice to have a static environment of 50,000 boxes, but a dynamic one is a whole different story. As expected, some slow downs occur when moving 5000 of the boxes around, however I haven't as yet optimised any of the "update" code (at the moment, I simply remove then reinsert each updated box from the root node). I could spit out some framerates, but they probably don't give much indication of what's under the hood considering I always try to get a high end computer. I suppose I should give out a little test app soon for other people to look at.

Re: Working on a game...
 

I haven't been idle - simply been reworking the editor to comply with a change in idea on how to handle terrain. Blending layers is slow compared to using one large texture, so I'm going with the large texture. Several ideas came to me on getting it to fit nicely into video ram - unfortunately the best one I came up with I think happens to be what Megatextures are all about. I'll probably get around to that one day - but for now, a 4096x4096 texture compressed to about 8MB + appropriate mip map levels is where I'm headed. Maybe combine it with a random noise detail texture...hmm...
Anyway, if anybody wants I hope to have a (very) basic, undocumented terrain editor in a usable state on monday. Just for fun.

Re: Working on a game...
 

http://garry.rank.googlepages.com/test.zip
No loading or saving yet. No smoothing or shifting of terrain. Many of those things did work, but then I changed some stuff and broke it all. It will load and save again when I put in the ability to load and save compressed textures (give me a few days). The editor is not meant to be superb or anything - just something to give me levels to load into the engine! Texture packages are best saved into the "textures" folder - no jpeg support at the moment, sorry!
Comments welcome.

Re: Working on a game...
 

Looking good there, nice work :clap:

Re: Working on a game...
 

Things are on hold a little bit to see what ageia does - they're supposed to be releasing linux software soon, and I'd prefer to use a mature physics library rather than write my own. Bullet is a good alternative, but it's still very much a work in progress and changes quite regularly.

Re: Working on a game...
 

Agreed, you have to be careful when choosing something which will be wrapped around in a large portion of the engine, however, just to be on the safe side, i'd recommend creating a 'wrapper' library which sits between the main code, and the engine you use. That way, if at some point you change your mind, just re-implement your custom (classes/)methods.

Also means that if an update to the physics engine does become avaliable and changes something, you can transparently alter your wrapper.

I did this recently with a small C++ linux project i was working on, given the different OSs, the socket engine varied (i could have stuck with the basics, but Linux 2.6+ and FreeBSD have optimised socket engines). During the configuration stage, a single include is added for the socket engine it's going to use, and it becomes built in with no changes to the core code :)

Something to concider.

Re: Working on a game...
 

You're right - a wrapper is most definitely the way to go. Sadly I'm getting twitchy about a few things with various physics libraries - either the way things are done, or stuff not being released, so I'll just write my own (basic) one soon, and change it as required. When I get back in a couple of months anyway.

-- back, working on it again!

Re: Working on a game...
 

Thought I might post a quick update where I'm at. I've got most of the core physics functions done, though there's still a fair bit to be built on top of that. At the moment I'm optimising my sphere/triangle collision code. And running a large number of tests on the same data to see where things do actually slow down.

Re: Working on a game...
 

Nice :D

:thumbup: :thumbup: