Sign in to follow this  

Game engine Render loop

This topic is 3584 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

I have recently began trying to create my own game engine. Nothing very advanced, a few features that are necessary and maybe a shader system would be nice, but I am not trying to make a be all end all game engine. Anyways, I have my basic game loop set up. I call the engine's update function, then the render function, etc. So, My question is, what do I do in the render function? Right now, I have a std::vector of class type Object* (which is my lowest abstracted geometry class) which has its own Update and render functions (virtual). So as of Right now, I am just iterating through the vector and calling obj->Render(). In the inherited Object's render function, I just make the calls to glBegin(), and glVertex3f's, and finally glEnd(). This seems extremely inefficient however. Should it be done similar to this? I mean, is this how it is typically handled, calling the gl functions in each object's individual render function?

Share this post


Link to post
Share on other sites
This is precisely why one should do this

What do you do in a render function? I don't know. What do you need to do? If you can't answer that question, you have a big-picture problem. You don't know what you're making.

What you have, as a basis, is fine -- the only major problem is that you're using OpenGL's immediate mode, which is the least efficient means of rendering with OpenGL. Consider exploring vertex buffer objects and the like.

Beyond that, you're fine. Don't worry about doing anything else until you develop a need for it or until your existing solution becomes unworkable. The best way to develop those needs in this context is usually to focus on the creation of a game, a concrete product, and not some abstract "enginey" type thing.

Share this post


Link to post
Share on other sites
While the idea of writing a game engine to make your life easier sounds like a good idea it can be accomplished easier by sitting down and writing a couple of very simple games. (basically they don't even have to be 'games' they just have to have the ability to draw to the screen and take user input).

I say this from my own personal experience. I started writing a 'engine' after getting sick of rewriting the same code to setup windows and handle input and so on. After spending about 6 months trying to get things working I ended up going back to my old projects and striping out and reworking the code that was already there to begin with.

From this code i build a framework and created a lib that i could link to that took care of setting up the window, handling input, loading objects, etc etc. And before i knew it i had my engine.

My engine now handles everything from models, textures to physics each part is its own entity that i can use with or without the rest of the objects.

So in the end i have to agree with jpetrie, build games not engines the engine will come together eventually. That along with a solid knowledge of OOP and proper design will win in the end over trying to code it from scratch.

Anyway using a vbo would be better then doing things on the high end.

Share this post


Link to post
Share on other sites
No, I know that if you have an end need established... Ie, create a game, you should do that. I have done that in the past. What I am doing now is mostly a software engineering exercise, on the large scale. I want to see if I could do it. I want to eventually have a toolset that is diverse and robust enough where I will try to make a sample game on it, but the end product here is not in the interest of making a game, but rather the learning exercise of building the internals of an engine.

So, I guess I am going to research into Vertex Buffers and the like, but as I said, the project/eng goal is to test my Knowledge of OOP and program design and to create a generic engine, because I would eventually want to become an engine programmer. Thanks for your help though. Also, if anyone could suggest a book that might help grasp some of the details of an engine, that would be awesome.

[Edit] And I do have a few specific features that I wanted, so I thought that would be a good way to work. Design a general scenegraph / rendering system. Then work on some of the more advanced features, such as loading a mesh, terrain & vegetation, physics, etc. But I thought it would be a fun exercise.

Share this post


Link to post
Share on other sites
The problem with doing this, especially if you have never written one before or have not been working on one in the industry, is that you don't know what the larger scale is. If you are adament that you are going to write an engine and not a game then the best thing to do is come up with some concise feature list. Then, gradually divide the list into subsections on smaller details of the feature list, until you think you have most of it covered.

The last thing you want to do is rewrite vast amounts of code because you didn't consider that you might need X.

Aside from what i said, jpetrie is correct, games, not engines.

Share this post


Link to post
Share on other sites
Siding with Dave here, I think you might be missing the point... which is that an engine doesn't exist in isolation or in a vacuum. When you say things like
Quote:
the end product here is not in the interest of making a game
and
Quote:
to create a generic engine
it smacks of not really having a clear picture of what you want your engine to support. If you don't want to make a game with it, then at least come up with a clear set of requirements for what you're trying to achieve before you set out to create the perfect "engine". It seems like you might be on the right track at least with
Quote:
And I do have a few specific features that I wanted, so I thought that would be a good way to work. Design a general scenegraph / rendering system. Then work on some of the more advanced features, such as loading a mesh, terrain & vegetation, physics, etc. But I thought it would be a fun exercise
, but that is very general and large in scope. Get your requirements down in specifics. This would go for creating an engine for a game as well. Working on an engine when the game design is not clear is also an exercise in futility (or, at a minimum, an exercise in asking for work to have to be re-done).

Share this post


Link to post
Share on other sites

This topic is 3584 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this