116 Replies - 13019 Views - Last Post: 18 April 2011 - 03:20 PM

Dagger3d! engine

Posted 17 June 2008 - 03:31 PM

I've started a separate Sourceforge project for my game engine, Dagger3d! Got an email saying it was approved but I'm still waiting for the site to agree.

I've switched to using the BSD license for all future versions. I think it will allow more flexibility with people who want to use Dagger3d! for proprietary games. Making a game is a lot of work, and most games (multiplayer-only games excluded) are "play once and forget" kind of deals. An Open Source application can stick around for years, being improved upon by the original developers and even some of it's more technical users. That said, not many people play through single player games, write patches to improve them, and then immediately go back to play through them again. For that reason I feel that the technology behind games (namely the engine) should if possible be Open Source, but the games themself should not be. Open Source game development (again, excluding multiplayer) just does not seem to work out.

So far I've written every line of code in the engine (roughly 10,000 lines including comments), but I could use a little bit of help coming up with a good collision detection system. Get in touch with me if you're interested.

Replies To: Dagger3d! engine

Re: Dagger3d! engine

Posted 23 June 2008 - 12:24 AM

I've started work on a mini game (a 3d clone of Asteroids) using Dagger3d. Dagger3d is far from being finished, but my reasoning is that if I try writing a game with it I will discover it's immediate limitations and fix them. So far I've already caught a couple of bugs, and I've added some things that (for some reason) didn't pop into my mind as useful before.

I'm adding a slightly reduced version of what I've got so far as a "test". Basically it involves loading a mesh, and allowing the "player" to fly it around at a constant speed (because I'm lazy) on the screen.

Here are some screenshots:

Note: That is a low polygon "ship" I made , I made a texture for it as well but my skill at exporting UV texture coordinates in Blender isn't very high yet, so for now there is the crazy gradiant texture.

The "ship" flying towards from the camera.

The "ship" flying away the camera.

The "ship" with wireframe mode enabled.

Here is the source code for the test. Please note that this isn't necessarily the best way to do this, and the code certainly could be shortened. That said, it is late and I am tired: you do the thinking.

Also please note that this won't do you a whole lot of good without the Dagger3d library, which you can either checkout of the subversion server and compile yourself, or you can get from me (if you ask nicely).

I have used it to parse 3D Model files, including .x, .obj (Wavefront object), and several custom models.

My setup:
1.7 GHz Pentium M
1 GB of 333 MHz RAM

Thanks, I'll look into that. I'm a little hesitant of including 3rd party libraries in my engine though. I started off using libxml2 to parse xml files and man was that a disaster. One of the few benefits of writing everything myself is that everything is easily portable.

What license is your parser under? Because if I were to include it in Dagger3d, it would be easiest if I could distribute a version of it with Dagger3d (dependency hunting is the pits).

Re: Dagger3d! engine

Posted 28 June 2008 - 10:53 PM

The parser is portable. I test it on 7 compilers (with max warnings turned on, except for the MS compiler) on Windows, and 2 on Linux. It even runs in a 16bit environment. I haven't tried it on Max OS X, but since it is Unix based, it should work without a hitch.

It is written entirely in ANSI C. If the platform support stdio.h, stdlib.h, and string.h, it will work.

As for the license, personally, I don't really care. Basically, I don't care if it's used in commercial project or not. File that under what ever license you want.

Re: Dagger3d! engine

Posted 28 June 2008 - 11:10 PM

Cerolobo, on 29 Jun, 2008 - 01:53 AM, said:

The parser is portable. I test it on 7 compilers (with max warnings turned on, except for the MS compiler) on Windows, and 2 on Linux. It even runs in a 16bit environment. I haven't tried it on Max OS X, but since it is Unix based, it should work without a hitch.

It is written entirely in ANSI C. If the platform support stdio.h, stdlib.h, and string.h, it will work.

As for the license, personally, I don't really care. Basically, I don't care if it's used in commercial project or not. File that under what ever license you want.

Sounds good. Maybe I'll add it in as a backend, with preprocesser macros to switch it out with my (slow) parser.

If I do use it, I'll keep it isolated from the engine (dynamic linking ftw). If you wanted to write up a copyright file/terms of use/something like that, I would love to include it (I don't think I saw one when I was browsing your source).

Dagger3d is under a BSD license, which basically says that anyone can modify the source code and use it for whatever they want (without having to release the modifications) providing they leave the copyright information intact.

Re: Dagger3d! engine

Posted 28 June 2008 - 11:21 PM

My model format keeps data in 3 files.

Here is the format specification.

-----------------------------------
dmf - Dagger Mesh Format
by Tom Arnold
-----------------------------------
Overview:
* Data is stored in an XML format.
* Consists of three XML files and a texture.
1) Header file, contains references to the other files, and information
like the number of vertices, etc.
2) Mesh file, contains frames, vertices, normals, and texture coordinates.
3) Animation file, consists of frame indices.
4) Texture file, should be a binary uncompressed TGA image.
* Frames are all stored in the same place, animations are only
divided up by start indices.
* Number of triangles = number of vertices divided by three,
therefore it is very important to not have any stray vertices!
* Number of vertices = number of normals.
Restrictions:
* You can only load triangles (the dmf_mesh_t type in Dagger3d allows for other
formats like QUADS and TRIANGLE STRIPS).
* No stray vertices (see above).
* No untextured meshs.
* Every mesh should have at least one animation. That animation
should be a one-frame static version of the mesh. If there are
multiple animations, it should be the first.
* There are no obvious limits for how many frames you can have,
or how many vertices/animations (like with MD2 models), but
keep in mind that more "stuff" will use more memory, and more
cpu time to render.
* Each mesh is limited to ONE texture (the dmf_mesh_t type in Dagger3d
allows for a lightmap texture, but information regarding that is NOT stored
in the dmf format).
* Textures MUST be in the TGA format.
* Each frame MUST have the same number of vertices.
Header:
* Name of the mesh.
* Mesh filename.
* Texture filename.
* Animation filename.
* Version number.
* Number of vertices (in a frame).
* Number of frames.
* Number of animations.
Other notes:
* The G3D Blender export script provided with Dagger3d will automatically
include all 250 (or so) animation frames. This leads to unnecessarily large
filesizes. To avoid this, go to the ANIMATION window in Blender and change
"End" to equal however many frames your mesh has.

And here is a link to the documentation for the C data structure that holds mesh information.

Re: Dagger3d! engine

As a side note there are some serious optimizations you can do to your data structures.

I don't know why you choose to do so, but using your matrix_t for coordinates is extremely wasteful, and rather slow.

And another note. In the header section, you declared your version as a unsigned int, yet you have a float in your def file.

Nice catch, didn't notice that (the version as a uint). I can be pretty thick-headed sometimes.

I use the matrix_t type mainly for safety. I know it's not the most efficient way of doing things, but it beats memory leaks. Any advice on slimming them down (other than not using them)?

Edit: Ahhh, the matrix_t type has a number of functions associated with it (for getting and setting values within the matrix, and for creating/deleting matrices), which is the main reason I use them. I don't think you used them in your implementation (whether that was intentional or not).

Re: Dagger3d! engine

Posted 29 June 2008 - 01:31 PM

Personally, I can't help but recommend you avoid them. Just for some basic coordinates, the matrix_t uses 5 pointers. All of those can be reduced to just one. To me, it is far easier to deal with just one pointer. Plus, you will benefit from things like Locality of Reference, since all the memory will be next to each other (IE, far faster), and less function calls (malloc() and free()).

The reduction in derefrencing alone will provide a nice performance boost, plus I find that a lot easier to work with. Not to mention you can take advantage of some OpenGL optimizations (Part of OpenGL 1.1, which is supported by pretty much everything).

glVertexPointer() - Can read the Coord struct. IE, you only have to pass one pointer to OpenGL.

This is far faster then calling glVertex3f() or what ever variant. And yes, there are functions to pass in texture coords and normals as well.