Archived

This topic is now archived and is closed to further replies.

ktron

3dengine design-please help if u can!

Recommended Posts

Hey all, I''m kinda designing my own 3d engine just so I can get a taste of what is involoved. So, a couple of basic question follow: 1. First, I''m not sure whether I sould use this kind of function format: void SetCurrentCamera(int CameraID); void SetCameraPosition(Engine_Vertex* CameraPosition); void SetCameraTarget(Engine_Vertex* CameraTarget); or this: *Engine_Camera GetCamera(int CameraID); The second method returns a pointer to the internal engine''s definition of a camera. Any ideas/experience/guidance that can be offered here? Can anyone suggest a reason I should do it one way or another. 2. Second, right now I''m planning to place the entirety of my engine into a engine class that will encapsulate all engine functionallity. Is this a good idea or should just export a ton of functions?

Share this post


Link to post
Share on other sites
All i can tell you is to be prepared to start over a few times. Choose any of those methods, and sooner or later you will probably realize some way that it could be done better. Then go back and rewrite it. I''m currently working on an engine that I''ve had to rewrite about 4 times so far, but i''ve learned tons from it.

Share this post


Link to post
Share on other sites
quote:
Original post by Mulligan
All i can tell you is to be prepared to start over a few times.

Hehe. Ya, I''m kinda expecting that to happen. I just wanna get off on the right foot, ya know.

Still, anyone have any new ideas on the subject. I don''t really want to do the pointer to internal structure method because, although I''m the only one that will be using it, I still think that exposing internal stuff easy very good design (I would be exposing my linked-list pointers, etc.)

Do most other engines do it either of these ways?

Thanks to all who''ve helped.
Kevin.

Share this post


Link to post
Share on other sites
I reccomend trying out a few different open source engines to see what it takes. No offense but they would get it right before you. I''m just saying this because I wish I had (it would have saved loads of stupid mistakes).

I personally use the GetCamera() format. Well, in a sense. There is a Camera Manager that takes care of the Camera for me, but my Renderer contains the Camera Manager Interface, so really I get a pointer from the Renderer to the Manager then use that to get a camera, which has it''s own SetPos(), SetTarget(), etc..

Namespaces or Classes? What the heck is wrong with using both???
I use a namespace for every class I use. So my Camera class is:

namespace AURELIO_REIS
{
class CCamera
{
// Tor, DTor, functions, etc...
SetPos( VECTOR3 &vPos ) { m_vPos = vPos };
}
}


So the scope for the SetPos function would be AURELIO_REIS::CCamera::SetPos(), UNLESS you use the using namespace key words which allow you to just limit your scope to the class (so now it''s just CCamera::SetPos()).

using namespace AURELIO_REIS;

BTW, I use my last name to denote which area''s I worked on. If Bob or Joe Smith did something, you could have had it be BOB_SMITH, but even better you should be descriptive, ex: MICROSOFT_GRAPHICS_COMPONENT. It doesn''t hurt.

Good luck!

"Love all, trust a few. Do wrong to none." - Shakespeare

Dirge - Aurelio Reis
www.CodeFortress.com
Current Causes:
Nissan sues Nissan

Share this post


Link to post
Share on other sites
quote:
Original post by Dirge
I reccomend trying out a few different open source engines to see what it takes. No offense but they would get it right before you.


No offence taken. :o)

quote:
Original post by Dirge
I personally use the GetCamera() format. Well, in a sense. There is a Camera Manager that takes care of the Camera for me, but my Renderer contains the Camera Manager Interface, so really I get a pointer from the Renderer to the Manager then use that to get a camera, which has it''s own SetPos(), SetTarget(), etc..



Could you explain this in a bit more detail? I''m a little confused on the camera ''manager'' part. Thanks.

quote:
Original post by alfmga
u''ll find what ur looking for here



Good article, but I was looking more for info on game engine API design. Thanks anyway, it was a good read.

Also, I''m still wondering if it''s a good idea to wrap the entire engine in a single class that the calling application must instance.? Any ideas?

Thanks all,
Kevin

Share this post


Link to post
Share on other sites
There are of course a hundred (thousand) ways to do it but i
like the ObjectFactory Model where you have a master class that creates instances of your various objects, it makes it really easy to manage your collections and to apply all your various validations, which rolls right into your next big project, a well thought out and super-powered debugger class, which turns your automation errors into read-able text.(a must)

Good Luck

Share this post


Link to post
Share on other sites
Why have a "get camera" at all? What other part of your application ever needs to know about the camera? Positional logic should not be incorporated into the camera. Try to minimise dependencies between subsystems, this will help when it comes time to rewrite it

eb.

Share this post


Link to post
Share on other sites
Some advice I would give is to perhaps consider writing what I call a "mini engine". This is an engine which encapsulates the following:
graphics routines (startup, shutdown, draw, clear etc.)
resource management (for textures, sounds, models, sprites - you can write a general template resource manager and instantiate it with a different type to create each kind of resource manager),
sound routines (startup, shutdown, play etc.)
camera routines (which might interface with the graphics stuff but should probably be kept separate).
basic physics.

this isn''t a full fledged engine but it would allow you to write some cool stuff and you probably won''t get too bored along the way.

I tried to write a full on engine earlier this year but got bored quickly because of the size of the task. Also I now realise that it was too much of a leap to make from the last game I''d written.
Now instead I''m building such an engine I''ve described above and will use it to make a 3d space shooter.
The good thing about this is it doesn''t involve a lot of other issues which would complicate the project and distract me from the actual game side of things.
Writing a BSP/PVS compilation tool (which I''m still trying to finish) is a hell of a lot more boring than programming a "game".

Keep it small, the biggest problem most people have it trying to do too much at once. Many hobby game programmers it seems start to write their first 3d engine and try to do too much. they get bored with it and then throw the whole thing away and perhaps never even come back to game programming.

Just my overstated opinion
Toby

Gobsmacked - by Toby Murray

Share this post


Link to post
Share on other sites
Toby has it right, especially if it is your first time. Pick some basic features you would like, in your case if it is your first engine, seeing anything. Then hack, and hack your first game together. The important thing is that you finish it. Do not waste too much time on design for now, just hack it together.

After you finish, or do not finish, you will not only have a complete game you can show people, but you will have a sense of how a whole project''s architecture might work. Repeat. Keep hacking, but because you will have more experience, you will notice that your next engine, and game architecture will be better designed.

Design is good, and I will not argue it. Just do not fall into the trap that so many do, and never finish a project because you are too stuck on getting it perfect the first or nth time.

Share this post


Link to post
Share on other sites
Thanks all. But I have already desiged a couple sinple 3d games in direct3d and I just want to try my hand at designing a basic engine for them. I really wondering which way I should go about building the api to my engine.

Any last ideas about my first question?

Thanks. Kevin

Share this post


Link to post
Share on other sites
Oh yea, your original question.

1) Your first question had two common ideas.
A) Pass throughs. Instead of having one class with many different sets of unrelated methods, you may want to consider having the class support several interfaces. Of course, this still means the one source file will have the implementation of all the functions.
B) To save having the passthroughs/interfaces, you can get a pointer to the member itself. This is looked upon like a global to some, and they treat it as a singleton (several articles here).
As alsways, it comes down to personal choice, and the ONLY way to find out the correct way is through experiments. Pick a way. Roll a die. Just decide, and do it. If it works, great for you! If it does not, then you learn, there is no PERFECT design. Some books call it a Silver Bullet. It does not exist.

Second question, this again will be different for every person. Before, I tried making one class that wrapped everything I needed out of DX, just like I did when I was doing software renderers. However, as my tasks changed, my architecture changed. In the end you will have to make some sort of wrapper. DX is a wrapper in itself really. The sort of wrapper you will make depends upon your project. This again comes through experience and what you need.

First, you must ask yourself, what part of the DX library do I need? Graphics? Sound? Input? Etc. It is pretty huge.
Then ask yourself what sections of each part do you care about?
For your first project, keep it simple (KISS). Choose an EXTREME subset, and just make something work, finish a project.

Share this post


Link to post
Share on other sites
Thanks Taulin. I was planning on just doing setting up a device with multiple cameras and md2 loading. I''ve got all the code, I was just wondering how I should expose it in the API. Thanks again.

Kevin

Share this post


Link to post
Share on other sites