Join 117,156 Programmers for FREE! Ask your question and get quick answers from experts. There are 2,330 online right now! We've got more than 500 tutorials and 2,000 snippets. Join and find out why Dream.In.Code is the #1 programming help community on the internet! Registration is fast and FREE... Join Now!
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.
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).
Another update, the Dagger Mesh Format that I came up with is an XML based format modeled off of ID's old MD2 format.
My XML parser is a little on the slow side, so I'm writing up a script to "compile" DMFs into a new (non-XML) format, dubbed Compiled Dagger Meshs (ie. cdm).
Loading times aren't noticeable on faster machines and with lowpoly meshes, but I would like to have this as a backup plan in case I can't speed up my XML parser easily.
My benchmarking has giving me a ~16 MB/s transfer rate, on my crappy laptop
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).
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.
This post has been edited by Cerolobo: 28 Jun, 2008 - 10:58 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.
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.
----------------------------------- 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.
Attached is a zipped example model of a tank.
Attached File(s) tank_model.zip ( 2.23k )
Number of downloads: 9
Another update, I've finished my DMF to CDM converter.
The size of JUST the mesh file (that means no definition or animation file) of an example DMF is 19305 bytes. The size of the entire mesh converted to the CDM format is 8531 bytes.
That combined with the bypass of my slow XML/string parser should speed up loading models plenty (it also means smaller model sizes on disk).