Engine Internal Fundamental Design
Post: #1
Up until now I've been using GLUT applications to test my bits of code, but I've begun to realize that I finally need to make some sort of core set of functions for setting up a video mode and getting input in a simpler function. Since I'm using SDL when not testing code I'm gonna use that for input and window setup, but that's all. It's funny that what some people would probably do first, I have put off until I absolutely half to. Why? Well there is a sorta good reason for that. I'm not sure how I should organize the 'renderer/driver/input' stuff.
Take another engine, like irrlicht for example. It has classes for a 'device' (computer) the 'device' class has subclasses for the video driver, input (event manager) driver and application GUI. I'm not sure I understand the need for classes at all for this set of functions. Surely, they make things less fail-safe by allowing the user to declare more that one renderer or more than one 'device' and then capture the screen more than once (possibly, though not in this case). What I'm trying to say is, why type this:
When you could type...
I guess what I'm asking is, what advantage does OOP programming give you when setting up stuff like this? I ask because I don't want to lay down a bunch of code that will serve no purpose and slow down the program or make it less fail-safe.
Thanks!
Take another engine, like irrlicht for example. It has classes for a 'device' (computer) the 'device' class has subclasses for the video driver, input (event manager) driver and application GUI. I'm not sure I understand the need for classes at all for this set of functions. Surely, they make things less fail-safe by allowing the user to declare more that one renderer or more than one 'device' and then capture the screen more than once (possibly, though not in this case). What I'm trying to say is, why type this:
Code:
Device *myDevice = captureDevice(320, 240, 16, I_WANT_FULLSCREEN);
Keyboard *myKeys = myDevice->InputDeviceInit();
bool test = myKeys->checkKey(IMPORTANT_KEY);When you could type...
Code:
captureDevice(320, 240, 16, I_WANT_FULLSCREEN);
bool = test = checkKey(IMPORTANT_KEY);I guess what I'm asking is, what advantage does OOP programming give you when setting up stuff like this? I ask because I don't want to lay down a bunch of code that will serve no purpose and slow down the program or make it less fail-safe.
Thanks!
Post: #2
I recently began evaluating the same thing. My conclusion, which others may not agree with, is that it's more personal taste. I went with an mixed approach of sorts. I think it works well for me. I have an App class that is pretty much in charge of everything. It handles setup and the main loop as well as input and video. I use an event system with listeners to get the input rather than using calls like your checkKey() function that way I can more easily allow different classes access to key states and such. The part that makes it mixed is that setting up my window seems a bit like GLUT (I admit, I use some function pointers, but it works for me at this point). It creates a procedural sense a little bit, but I tried to stick a lot to using a more OO approach. For each function callback, the App passes itself as a parameter so that I can avoid global variables if possible.
Here's a basic setup of how it works:
EDIT: Because I needed some help with my physics code, I've uploaded the whole project for download. Xcode 2 required. I've included the two SDL frameworks I'm using as well. Download Here (2.4 MB ). Feel free to peruse the code if you'd like.
Here's a basic setup of how it works:
Code:
#include "App.h"
#include "Exception.h"
#include "EventListener.h"
#include <stdio.h>
#include "gl.h"
class MainListener : public EventListener {
public:
void handleEvent( SDL_Event *event, App *app ) {
//do whatever with the event
}
};
void init( App *app ) {
//create a new listener
MainListener *listener = new MainListener();
//the autoDestroy gives the app the OK to delete it when
//the app is deleted at the end of the program. this allows
//us to avoid global listeners without requiring that all
//listeners be deleted with the app
listener->setAutoDestroy( true );
//this tells the app which events to send to the listener
app->subscribeListener( SDL_KEYDOWN, &mainListener );
}
void update( App *app ) {
}
void draw( App *app ) {
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
glLoadIdentity();
SDL_GL_SwapBuffers();
}
void quit() {
}
int main( int argc, char *argv[] ) {
App *app = NULL;
try {
app = new App;
app->setTitle( "My New Window" );
app->setScreenSize( 800, 600, 32 );
app->enableAntialiasing( true, 8 );
app->enableDoubleBuffer( true );
app->enableVsync( true );
//app->enableFullscreen( true );
//this is the final call to create the app itself
app->initialize();
glEnable( GL_POLYGON_SMOOTH );
glEnable( GL_LINE_SMOOTH );
glEnable( GL_POINT_SMOOTH );
glDepthFunc( GL_LEQUAL );
glEnable( GL_DEPTH_TEST );
glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );
glEnable( GL_BLEND );
glEnable( GL_TEXTURE_2D );
//i manually do this step to move custom initialization
//out of my main() function
init( app );
//this is where the function pointers come in
app->mainLoop( update, draw );
}
catch( Exception e ) {
printf( "Exception caught: %s\n", e.getMessage().c_str() );
}
//call our custom quit function
quit();
//delete the app if it was created successfully
if( app )
delete app;
return 0;
}EDIT: Because I needed some help with my physics code, I've uploaded the whole project for download. Xcode 2 required. I've included the two SDL frameworks I'm using as well. Download Here (2.4 MB ). Feel free to peruse the code if you'd like.
Post: #3
Thanks Nick, for your insight and your sample code. I like certain elements of the style you've setup.
What exactly is wrong (or what do you think is wrong?) with your physics code? The chain appears to 'swing' and react to force/gravity quite realistic-ly. Very smooth.
Once again, thanks!
What exactly is wrong (or what do you think is wrong?) with your physics code? The chain appears to 'swing' and react to force/gravity quite realistic-ly. Very smooth.
Once again, thanks!
Post: #4
You're welcome for the code. Hopefully it will benefit you in your own design.
As for the chain, it just doesn't seem to behave correctly. For instance, if I change the masses to very higher values, the chain swings slower and if I change the masses to 1 it swings very fast. Little things like that mostly.
As for the chain, it just doesn't seem to behave correctly. For instance, if I change the masses to very higher values, the chain swings slower and if I change the masses to 1 it swings very fast. Little things like that mostly.
Post: #5
If that's your problem, then you're applying a constant force instead of a constant acceleration. (since gravity has a constant acceleration regardless of the mass, so the resulting force changes with mass)
Post: #6akb825 Wrote:If that's your problem, then you're applying a constant force instead of a constant acceleration. (since gravity has a constant acceleration regardless of the mass, so the resulting force changes with mass)Thanks for the tip. I am indeed using a constant force rather than constant acceleration. I'll fix that.
To Jones: I didn't mean to get your thread hijacked. If an admin wants to move this post and akb825's to my other thread, that'd be nice.
Post: #7Nick Wrote:Thanks for the tip. I am indeed using a constant force rather than constant acceleration. I'll fix that.
To Jones: I didn't mean to get your thread hijacked. If an admin wants to move this post and akb825's to my other thread, that'd be nice.
Heh, that's no bother to me. I think I've got a good answer to my problem, thanks to you.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| Internal Error on XCode | softengg | 1 | 2,396 |
Jan 23, 2008 11:40 PM Last Post: OneSadCookie |
|