Welcome to Dream.In.Code
Getting Help is Easy!

Join 132,487 Programmers for FREE! Get instant access to thousands of experts, tutorials, code snippets, and more! There are 1,102 people online right now. Registration is fast and FREE... Join Now!




Dagger3d! engine

8 Pages V  1 2 3 > »   
Reply to this topicStart new topic

Dagger3d! engine

Tom9729
post 17 Jun, 2008 - 02:31 PM
Post #1


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


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. tongue.gif

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. icon_up.gif
User is offlineProfile CardPM

Go to the top of the page

Tom9729
post 22 Jun, 2008 - 11:24 PM
Post #2


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


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 smile.gif, 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.

IPB Image
The "ship" flying towards from the camera.

IPB Image
The "ship" flying away the camera.

IPB Image
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. smile.gif

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).

cpp

/*
* Copyright © 2008, Tom Arnold
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without modification,
* are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this list
* of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright notice, this
* list of conditions and the following disclaimer in the documentation and/or other
* materials provided with the distribution.
* 3. Neither the name of the Dagger3d! Engine nor the names of its contributors
* may be used to endorse or promote products derived from this software without
* specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <stdlib.h>
#include <stdio.h>
#include <dagger.h>

game_ent_t* domo = NULL;
camera_t* c = NULL;

void update_scene(void)
{
// Move the ship based upon it's speed & heading.
phys_vel_update_pos(domo->phys_info.loc, domo->phys_info.dir, -domo->phys_info.speed, 0.001);
}

void keyboard_func(uchar* state)
{
if (state[_KEY_ESC])
{
exit(0);
}

if (state[_KEY_W_LC])
{
// Toggle wireframe mode.
wireframe_enabled = !wireframe_enabled;
}

if (state[_KEY_RIGHT])
{
matrix_t* rot = NULL;
float yt;

// Rotate the ship's heading.
rot = matrix_vector_rotate(domo->phys_info.dir, -5.0f, _Y_AXIS);
matrix_destr(domo->phys_info.dir);
matrix_vector_normalize(rot);
domo->phys_info.dir = rot;

// Rotate the actual mesh.
yt = point2d_get_rotation(matrix_get(domo->phys_info.dir, 0, 2),
matrix_get(domo->phys_info.dir, 0, 0));
matrix_set(domo->phys_info.rot, 0, 1, yt);
}

else if (state[_KEY_LEFT])
{
matrix_t* rot = NULL;
float yt;

// Rotate the ship's heading.
rot = matrix_vector_rotate(domo->phys_info.dir, 5.0f, _Y_AXIS);
matrix_destr(domo->phys_info.dir);
matrix_vector_normalize(rot);
domo->phys_info.dir = rot;

// Rotate the actual mesh.
yt = point2d_get_rotation(matrix_get(domo->phys_info.dir, 0, 2),
matrix_get(domo->phys_info.dir, 0, 0));
matrix_set(domo->phys_info.rot, 0, 1, yt);
}

else if (state[_KEY_UP])
{
matrix_t* rot = NULL;
float xt;

// Rotate the ship's heading.
rot = matrix_vector_rotate(domo->phys_info.dir, -5.0f, _X_AXIS);
matrix_destr(domo->phys_info.dir);
matrix_vector_normalize(rot);
domo->phys_info.dir = rot;

// Rotate the actual mesh.
xt = point2d_get_rotation(matrix_get(domo->phys_info.dir, 0, 1),
matrix_get(domo->phys_info.dir, 0, 2));
matrix_set(domo->phys_info.rot, 0, 0, xt);
}

else if (state[_KEY_DOWN])
{
matrix_t* rot = NULL;
float xt;

// Rotate the ship's heading.
rot = matrix_vector_rotate(domo->phys_info.dir, 5.0f, _X_AXIS);
matrix_destr(domo->phys_info.dir);
matrix_vector_normalize(rot);
domo->phys_info.dir = rot;

// Rotate the actual mesh.
xt = point2d_get_rotation(matrix_get(domo->phys_info.dir, 0, 1),
matrix_get(domo->phys_info.dir, 0, 2));
matrix_set(domo->phys_info.rot, 0, 0, xt);
}
}

int main(int argc, char** argv)
{
// This must be called right off the bat, for obvious reasons.
game_engine_init(argc, argv);

// Set up and add the mesh+entity to the scene.
{
dmf_mesh_t* m;

// Load the entity from a file, and set some attributes.
domo = game_entity_create("data/sabre.xml");
domo->phys_info.speed = 10.0f;
matrix_set(domo->phys_info.loc, 0, 2, -5.0f);
matrix_set(domo->phys_info.loc, 0, 1, -0.25f);
matrix_set(domo->phys_info.dir, 0, 0, 0.0f);
matrix_set(domo->phys_info.dir, 0, 1, 0.0f);
matrix_set(domo->phys_info.dir, 0, 2, 1.0f);

// Load the mesh from a file.
m = dmf_load_mesh("data/sabre_def.xml");

// Add both to the world.
dmf_queue_add(m);
game_world_add_ent(domo);
}

// Set up and add the camera.
{
c = camera_create();
camera_add(c );
camera_set_active(0);

matrix_set(c->dir, 0, 0, 90.0f);
matrix_set(c->dir, 0, 1, 180.0f);
}

// Bind our keyboard and update functions.
keyb_set_func(&keyboard_func);
scene_set_update_func(&update_scene);

// Start rendering.
graphics_start();

return EXIT_SUCCESS;
}


There are still a few little glitches to work out (rotating the ship "jumps" a bit at certain angles), but I think it's coming along nicely. smile.gif
User is offlineProfile CardPM

Go to the top of the page

Tom9729
post 28 Jun, 2008 - 07:08 PM
Post #3


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


Dagger3d is approximately at 12,013 lines of code (as of this moment). That's a lot of code. smile.gif
User is offlineProfile CardPM

Go to the top of the page

Tom9729
post 28 Jun, 2008 - 09:25 PM
Post #4


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


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). smile.gif

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.
User is offlineProfile CardPM

Go to the top of the page

Cerolobo
post 28 Jun, 2008 - 09:32 PM
Post #5


D.I.C Regular

Group Icon
Joined: 5 Apr, 2008
Posts: 440



Thanked 31 times
My Contributions


Actually, I can probably help you out on the Parsing.
http://www.dreamincode.net/forums/showtopic52533.htm

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
User is offlineProfile CardPM

Go to the top of the page

Tom9729
post 28 Jun, 2008 - 09:47 PM
Post #6


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


QUOTE(Cerolobo @ 29 Jun, 2008 - 01:32 AM) *

Actually, I can probably help you out on the Parsing.
http://www.dreamincode.net/forums/showtopic52533.htm

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. icon_up.gif

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).
User is offlineProfile CardPM

Go to the top of the page

Cerolobo
post 28 Jun, 2008 - 09:53 PM
Post #7


D.I.C Regular

Group Icon
Joined: 5 Apr, 2008
Posts: 440



Thanked 31 times
My Contributions


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 - 09:58 PM
User is offlineProfile CardPM

Go to the top of the page

Tom9729
post 28 Jun, 2008 - 10:10 PM
Post #8


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


QUOTE(Cerolobo @ 29 Jun, 2008 - 01:53 AM) *

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. icon_up.gif
User is offlineProfile CardPM

Go to the top of the page

Cerolobo
post 28 Jun, 2008 - 10:15 PM
Post #9


D.I.C Regular

Group Icon
Joined: 5 Apr, 2008
Posts: 440



Thanked 31 times
My Contributions


Truthfully, I have no desire to write up any terms of use, or other legal document.

I wrote the whole thing, and that's good enough for me.

In any case, if you have a sample model file, I could probably write up a example on how to drive it.
User is offlineProfile CardPM

Go to the top of the page

Tom9729
post 28 Jun, 2008 - 10:21 PM
Post #10


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


My model format keeps data in 3 files.

Here is the format specification.
CODE

-----------------------------------
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)
Attached File  tank_model.zip ( 2.23k ) Number of downloads: 12
User is offlineProfile CardPM

Go to the top of the page

Tom9729
post 28 Jun, 2008 - 11:42 PM
Post #11


Debian guru

Group Icon
Joined: 30 Dec, 2007
Posts: 1,447



Thanked 10 times

Dream Kudos: 325
My Contributions


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). smile.gif
User is offlineProfile CardPM

Go to the top of the page

Cerolobo
post 29 Jun, 2008 - 04:19 AM
Post #12


D.I.C Regular

Group Icon
Joined: 5 Apr, 2008
Posts: 440



Thanked 31 times
My Contributions


I was able to correctly load the sample files you gave me 1,000 times in
@1.7GHz: 3.3 seconds, 5.74 MB/s
@500MHz: 20 seconds, 0.95 MB/s

The code was compiled with cl *.c /O2

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.

This post has been edited by Cerolobo: 29 Jun, 2008 - 04:31 AM


Attached File(s)
Attached File  CeroParserLoader.zip ( 20.74k ) Number of downloads: 15
User is offlineProfile CardPM

Go to the top of the page

8 Pages V  1 2 3 > » 
Fast ReplyReply to this topicStart new topic
Time is now: 11/22/08 04:10PM

Live Help!

Tutorials

Programming

Web Development

Reference Sheets

Code Snippets

Bye Bye Ads

Free DIC T-Shirt

T-Shirt Example

Related Sites

Monthly Drawing

Thumb Drive

Partners

Top Contributors

Top 10 Kudos This Month