Jump to content
  • Advertisement
Sign in to follow this  
XVincentX

Writing an engine: where to start?

This topic is 4437 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Good morning to everyone. I'm not a complete beginners, i use DirectX since a year, and then i have got some knowledges about vertex and index buffers, shaders (bump mapping, phong, lambertian, blur, depth of field),Matrix, loading and render .x meshes, using Render Targets (but only via D3DXRenderToSurface), light via fixed pipeline (D3DLIGHT9) and some other things. Now i'd like to write a little framework but i do not know where to start. For first thing, how can a class know what render and what not? A my friend said me to use a generic class and insert into device with a list (std::list<CGeneric> RenderObjects; for examples) but it's too many complex. If an object have to be rendered with a shader, and another not? I do not know how to start And another thing: i do not know how Matrix works. I know what they are and how to mul them, but i do not know the relationship between Matrix and object space. I'm tired to use everytime D3DXMatrix functions to build a camera and move objcets, i want to understand. Are there ?Books, links, tutorial and other for me? If there is someone (italian also) that want to help me via msn, contact me at darkfrenesy@yahoo.it

Share this post


Link to post
Share on other sites
Advertisement
Look at other engines/frameworks. Let their designs inspire yours. There are a number of open source engines, or other engines that provide source at reasonable/no cost.

Share this post


Link to post
Share on other sites
Could you suggest me some engine or other little works to study for understand?
Please do not see me Ogre becouse it's impossibile.
And for other questions about matrix?

Share this post


Link to post
Share on other sites
I agree with Oluseyi - there's plenty out there already. Although writing your own framework or engine can teach you lots, most of the lessons learned in writing your own are about how NOT to do things.

If you're currently unfamiliar with the intimate details of how matrix math works, I would suggest that there's plenty out there to help you with how to do things, and I'd recommend you follow that path for awhile before striking out on your own.

A quick query for "matrix 3d math" on Google turned up
this, which looks like a reasonable start, in addition to a number of links to articles/posts here on GameDev.

Just so's to actually provide some information here:

* A list<> (or whatever container your prefer) of generic renderable things is a perfectly valid approach - I've used that basic approach in multiple shipped titles.

* For any non-trivial scene, you'll need to further refine what you're considering rendering. Most schemes provide a rough bounding volume for each potentially renderable object. They then determine what part of the world is visible. From there, it's a matter of figuring out which renderable objects are in the visible parts of the world. There are a plethora of choices for approaches for each of the parts of that process, which ones make sense are highly dependent on what your world looks like, and what inhabits it.

* Once you've determined that you're going to render something, you need to have some render state attached to it: This can include things like blend modes, vertex or pixel shaders, textures etc. You need to bind the state to the hardware (using calls like SetRenderState(), SetTexture(), etc. for D3D), issue your drawing calls (using calls like DrawIndexedPrimitive() for D3D), and then potentially unbind anything before moving on to the next renderable object. Managing render state can range from the very simple, to the very complicated, depending on your needs.

Cheers,
Jason

[Edited by - JasonBlochowiak on June 27, 2006 5:09:23 PM]

Share this post


Link to post
Share on other sites
I disagree, I suggest writing your own engine. While doing so is almost certainly more difficult and will take longer you will learn so much more in doing it. Also, when your project is done, you will actually get to claim that it is all your work :-)

Share this post


Link to post
Share on other sites
If you think Ogre is impossible, then you can't write an engine. Go ahead and write an abstraction for something like 2D rendering. Take a look at SDL.

As for matrices, there is no relationship between matrices and object space. Matrices represent a transformation from one orientation to another, or from one coordinate system to another. Because all of these coordinate systems (within the field of 3D graphics) represent 2-space or 3-space, the transformations to and from them are comparatively simple. Essentially, the transformation from world-space coordinates to view-space (camera) coordinates involves displacements (translations), rotations and scale operations.

Because of the way that matrix multiplications work, several individual transformations can be concatenated into a single transformation matrix, making it easier and more efficient to transform a number of vertices.

The Direct3D documentation includes discussions of the nature of transformations, as does any rudimentary 3D graphics text (Computer Graphics by Foley, Van Dam et al is typically the "canonical" suggestion). You'll simply have to keep at it until you get it.

Share this post


Link to post
Share on other sites
Quote:
Original post by medevilenemy
I disagree, I suggest writing your own engine. While doing so is almost certainly more difficult and will take longer you will learn so much more in doing it. Also, when your project is done, you will actually get to claim that it is all your work :-)

This is good if writing engines is your objective. If, on the other hand, your objective is to write games, it helps to use other engines. Further, if you simply start hacking away at an engine, your first several will be terrible. If, however, you study a few before writing your own, you will rapidly accelerate your advance toward quality.

Just a few things to keep in mind.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi
Quote:
Original post by medevilenemy
I disagree, I suggest writing your own engine. While doing so is almost certainly more difficult and will take longer you will learn so much more in doing it. Also, when your project is done, you will actually get to claim that it is all your work :-)

This is good if writing engines is your objective. If, on the other hand, your objective is to write games, it helps to use other engines. Further, if you simply start hacking away at an engine, your first several will be terrible. If, however, you study a few before writing your own, you will rapidly accelerate your advance toward quality.

Just a few things to keep in mind.


Again, I agree with you Oluseyi.


Discounting that the user name "medevilenemy" implies trolling, and using "you/your" in the generic sense here...

I would point out that all of the commercially available "major" engines have some non-trivial aspects that seriously suck, and they were written by smart people who have several generations' worth of experience.

If your goal is to write engines, regardless of quality, you should immediately strike out on your own.

If your goal is to write engines of any semblance of quality, then you should take a look at what's already out there, and learn and understand their design and implementation philosophies. Once you understand how (and why) they work, you can evaluate if they suit your needs. If they mostly do, you can make some minor modifications and/or additions. If they don't, you can set out on your own, with at least a clue as to what you want to do differently that none of the available options is suited for.

To include the obvious analogy: If you wanted to build a car, you wouldn't start from a blank piece of paper. You'd probably start out with an existing car, and maybe start tinkering with the engine timing or air/fuel mixture curves. From there, you might add a turbo or something. Etc. After quite a bit of experience, you might decide to reject a flaw you saw running through all of the designs you'd run across, and do something revolutionary. However, if you started from scratch, you would probably end up with a less-than-impressive go-kart that was prone to exploding.

Oh, also, you're much more likely to understand what an engine needs to do if you've written multiple games, preferably in completely different genres.

Cheers,
Jason

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!