Physics engines + Graphical engines + fun

luca-deltodesco · 2007-07-06 08:36:59

Over the last (Insert undetermined period of time), i've been working on my full C++ game.

It started out with a basic engine, with basic graphics and basic physics.
http://img146.imageshack.us/my.php?image=s1bp9.jpg

I then started adding a little more advanced framework and got this:
http://img293.imageshack.us/img293/7746/scr3ef5.jpg

I then started to learn about shadow mapping after looking at different techniques, and created this:
http://img455.imageshack.us/img455/5880/shadowmap4ly3.jpg

Which was then implemted into this engine:
http://img127.imageshack.us/img127/1755/scr7ff0.jpg

Of which a video is available here:
http://youtube.com/watch?v=o2QheciKSes

I then started to look into rigid body physics and underlying collision algorithms etc etc. and after figuring some stuff out myself i made this:
http://img99.imageshack.us/img99/6184/ball2vr7.jpg

And a little glitch engine, but all the same a big step up
http://img217.imageshack.us/img217/4396/interpeniu2.jpg

I then started to look into Seperating Axis Theorem, and moved into 3D, which was a big step up on the physics of things. And made these:
http://img502.imageshack.us/img502/6311/ball6gv0.jpg

Of which i have videos:
http://youtube.com/watch?v=XqA4bMBVj1w&mode=related&search=
http://youtube.com/watch?v=QEq01p8EKh4&mode=related&search=

I then stepped things up a bit, created a new engine from scratch for the current release of my game. Of which i have these two images:
http://img294.imageshack.us/img294/2527/scr3ul7.jpg
http://img48.imageshack.us/img48/158/scr4pi4.jpg

I'm now going to start on elastic and non elastic collidable ropes to add to the engine, and then start re-integrating the graphics of the previous game engine.

I know the engine is certainly not perfect, the current release of the game, shown in last two images, the physics engine is much more stable and realistic than that shown in the two physics videos. However, i am only 16 so I certainly think these are big achievements.

Putting together all the source code for the engine of the last two screenshots, i have roughly 4000 lines of code, everything from my float2,float3,float22,float33 vector and matrix classes, to loading JPEG files into openGL textures, to the physics, to the tesselationg of icosahedron for the player particle mesh.

-------------------

The deformed object you see in various screenshots, is the object the player controls in the game, it is a deformable soft body composed of particles held together with springs, simulating the containment of a gas, with forces applied to each triangle of the mesh simulating the forces of internal pressure.

In the last two, the player is the orangey object you can see.

Last edited by luca-deltodesco (2007-07-06 08:41:09)

Ricky · 2007-07-06 09:34:25

Do you have any intention of releasing the source code? I'd certainly like to have a look.

mikau · 2007-07-06 09:46:41

where do you learn about all this stuff?

luca-deltodesco · 2007-07-06 10:28:19

probably not ricky not because i dont trust you or anyone else, but i just don't like to, although once i get a website up, im wanting to make some articles on things ive learnt other the years, which will include all this stuff.

to mikau, the internet ^^

... its 4000 lines now, imagine when ive got all the graphical stuff from previous engines integrated, and all the menu systems, and then to actually START the game, as opposed to the engine for the game, i can understand why programmers work in teams now ^^

Last edited by luca-deltodesco (2007-07-06 10:29:59)

Ricky · 2007-07-06 11:05:36

I'm not too interested in the graphics programming itself, but rather in looking for ways to optimize the code behind the engine.

Also, with what you've done so far I'm certain you already know this, but make sure you make the entire engine external to your game. I made that mistake many years ago when I didn't know anything about design and it proved to be fatal.

MathsIsFun · 2007-07-06 13:10:29

You have a real talent, luca ... that was breathtaking. And I can underestand the difficulties involved, though I have never taken 3D to the level you have.

And it also looks really cool.

Please keep us updated.

(PS: Ricky may be able to help you ... by the sound of it!)

Zhylliolom · 2007-07-06 14:24:13

Very nice, I'm looking forward to seeing more of your work in the future.

luca-deltodesco · 2007-07-06 18:07:44

Ricky wrote:

Also, with what you've done so far I'm certain you already know this, but make sure you make the entire engine external to your game. I made that mistake many years ago when I didn't know anything about design and it proved to be fatal.

i've already made that mistake many times in the past.

in my flash games i did the same thing, but i went through some many re-writes optimizing things that the engines i use in my flash games, i can literally re-write on the go from scratch in about 10 minutes, so thats never been a problem lol.

however, i only learnt the wonders of using multiple source code files a few weeks ago, which is why ive been re-writing things from start, now everything is properly seperated out and on its own.

I know i've done it properly this time, and havn't been making the same mistakes, because this is the only time i've actually felt that multiple programmers COULD work on this project at one time if you know what i mean. I've already completely seperated all my vector and matrix classes into a static library that now, i can use it like any other library without even worrying about adding its cpp files to the project.

everything to do with physics in the current release is within 4 set of files. 'physclass.hpp/cpp' containing the class declarations and definitions for all the classes im using in the physics side of the engine, particle classes, triangles classes, generic rigid body, sphere inheriting the generic rigid body, box, inheriting the rigid body, and they all have their own namespace to stop any possible clashes in future. the 3 classes for the player body, are player:∂icle, player::triangle, player::edge.

the triangle for the world geometry for collision is world::triangle, the 3 rigid body classes are rigid::base, rigid::sphere, rigid::box

i then have 'prim.hpp/cpp' which contains basicly helper stuff, like functions i can call to generate display lists for the sphere and box bodies, and a generic vertex list for a box, with and lists of references to this list, to define all edges and faces for the SAT tests.

i then have 'col.hpp/cpp' which is for anything to do with collisions that is not related to anything else, this is the main bulk of the physics engine.

i then have 'phys.hpp/cpp' which is the main physics functions that would be used in the game engine 'physics()' for dealing with integrating everything and applying any forces that are global, 'satisfy()' to deal with all collisions etc.

Anthony.R.Brown · 2007-07-07 02:07:30

To luca-deltodesco

Quote:" Over the last (Insert undetermined period of time), i've been working on my full C++ game. "

A.R.B

It would Help if first you understood how operating Systems worked! before you try any Programming!...

--------------------------------------------------------------------------------------------------------------
Genius Is Noticed! But Refused Acceptance! By Persons With Academic liabilities! .....................

Ricky · 2007-07-07 03:30:12

Ok, it sounds like you don't have too much experience in design. I was the same way till I came to college as a CS major. So here are a couple of general tips I found useful when I was designing large systems:

Always use abstract data types. For example, lets say you have an array of light sources. Don't do "Array light_sources;". Rather, do "Collection_Light_sources" and implement the general data structure functions (Insert, Remove, Find, etc) using an array. Why? Because lets say through your coding that you suddenly realize that it's better to use something like a B+ tree. What you would have to do is go through all your code renaming every time you used the structure. If you use an abstract data type, then all you have to do is change one file. This will create a whole lot of files for your project. But remember that size doesn't matter, it won't hamper performance.

Always use encapsulation. The only time to brake encapsulation is when it is impossible to do something using it (virtually never). Even if you have a variable say num_objects in a class, and you have to write a get_num_objects and a set_num_objects, it kind of seems silly to make num_objects private, no? I mean, anyone can access or modify it. But now lets imagine that you want to track num_objects whenever it gets changed. If you are directly accessing it (not going through class functions), this would be really tedious. You'd have to track all over your code. If you encapsulate it, then any modification to num_objects would have to happen in the function set_num_objects itself, or possibly the class it's in. Much easier to do.

Always write default, copy, and deconstructors. If you don't, the C++ compiler will for you and you may end up calling these even though you don't mean to. It takes a helluva long time to figure out what's going on when the compiler preforms a shallow copy on dynamically allocated class members, because you change one instance of a class and another instance changes. Deconstructor isn't all that important unless you are using dynamically allocated memory.

Use inheritance wherever you can find a place for it, always try to find ways around using multiple inheritance. You may want to consider using inheritance on a general Object class, but I'm not sure the ramifications of this (I'll have to think about it for a while). Polymorphism is a really neat tool to use, but remember it can also lead to crashes if you aren't sure of the class type before you recast a pointer.

Expandability, expandability, expandability. This one I still have trouble writing code with, but you have to think before and during you code, "What possible things could I ever want to do with this in the future?" Then, you have to think, "The way I'm planning to write this code, would it be easy or hard to incorporate those ideas?" It's very difficult to do with an open-ended project like a graphics engine, but ya gotta at least try.

Edit:

Oh, and one more. Always use const where appropriate (there are a like 8 different uses of it in C++). You may find yourself casting off the const especially with pointers, but that's ok. It will help the debugging process because you'll know exactly in what sections of code variables can be changed.

It would Help if first you understood how operating Systems worked! before you try any Programming!...

ARB isn't too far off. Understanding how the operating system works will help a lot in programming. But it isn't necessary. It's much like asking someone to understand Abstract Algebra before they try high school algebra. Come to think of it, it's exactly like that.

luca-deltodesco · 2007-07-07 04:34:39

thanks ricky for the tips, some of them i already do, some i hadn't thought of, like the abstract data types one.

MathsIsFun · 2007-07-07 11:23:58

Great advice Ricky (which I should follow more often ... to the extent I can in the scripting languages I tend to use)

My guiding light is "could I just lift this chunk of code out of here and drop it another application and use it straight away", and using "get" and "set" really helps, as does setting defaults and checking everything you can think of.

And if I get lazy (or time challenged) I put little "NB" comments (literally the letters "NB" so I can search on them) saying what needs to be done to make it more robust. Like "NB: need to handle zero"

Math Is Fun Forum

#1 2007-07-06 08:36:59

Physics engines + Graphical engines + fun

#2 2007-07-06 09:34:25

Re: Physics engines + Graphical engines + fun

#3 2007-07-06 09:46:41

Re: Physics engines + Graphical engines + fun

#4 2007-07-06 10:28:19

Re: Physics engines + Graphical engines + fun

#5 2007-07-06 11:05:36

Re: Physics engines + Graphical engines + fun

#6 2007-07-06 13:10:29

Re: Physics engines + Graphical engines + fun

#7 2007-07-06 14:24:13

Re: Physics engines + Graphical engines + fun

#8 2007-07-06 18:07:44

Re: Physics engines + Graphical engines + fun

#9 2007-07-07 02:07:30

Re: Physics engines + Graphical engines + fun

#10 2007-07-07 03:30:12

Re: Physics engines + Graphical engines + fun

#11 2007-07-07 04:34:39

Re: Physics engines + Graphical engines + fun

#12 2007-07-07 11:23:58

Re: Physics engines + Graphical engines + fun

Board footer