Sign in to follow this  

What do you think of my Game framework design

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

// GameLib.h -- GAME LIBRARY
#pragma once
#include <d3dx9.h>
#include <dinput.h>
#include "sound.h"
#include <vector>
#include <string>

struct GAMEOPTIONS
{
	bool windowed;
	int width, height;
	D3DDEVTYPE deviceType;

	HINSTANCE*			phInstance;
	HWND*				phWnd;
	IDirect3DDevice9**			ppD3DDevice;
	IDirectInputDevice8**		ppDIKeyboard;
	IDirectInputDevice8**		ppDIMouse;
	std::vector<IDirectInputDevice8*>*	pvecpDIJoystick;
	std::vector<std::wstring>*		pvecJoyInsName;
	std::vector<std::wstring>*		pvecJoyPrdName;
	CSoundManager*			pSoundManager;
};

// prototypes of user defined functions
LRESULT CALLBACK GameWndProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam );
void GameOptions( GAMEOPTIONS* pOptions );
void GameSetup( );
void GameLoop( float time );
void GameCleanUp();


This is the header of the library I created that handles creating DirectX graphics, input and sound components. I am using the sample Sound class from the SDK.. The library defines a WinMain such that it first calls GameOptions, querying the user of the framework for options, (takes address of pointer that will be pointing at created objects).. Plus it takes display option stuff.. After options are queried, the framework calls GameSetup() where the user does game-specific initialization... For each frame (yeah, the game loop is in WinMain :D ), the GameLoop() would just be called filled with the correct time elapsed (huh!, something feels wrong). And GameCleanUp() is called before the application exists for game-specific clean up (all directx objects are destroyed in the framework).. The question is open, what do you think of it... I mean would you use it? How can I improve it? Does it feel limiting?

Share this post


Link to post
Share on other sites
The question is open, what do you think of it...


std::vector<std::wstring>* pvecJoyInsName;
std::vector<std::wstring>* pvecJoyPrdName;


Congratulations, you've wasted 4 characters telling me a second time that it's a pointer to a vector, but shortened the important part (Ins, Prd) so much that it's not understandable anymore. Ins as Insert, or Inside? Prd as Prediction? What the hell?

Other than that, why are you using pointers-to-pointers? Why are you passing the GAMEOPTIONS argument by pointer instead of reference?

I mean would you use it?

Perhaps, yes, if its interface was made a little bit better adapted to my purposes.

How can I improve it?

Instead of expecting callback functions, let the user provide a class (so, you know, he isn't forced to have global variables in order to use your framework). A personal nitpick: provide the absolute time, either instead of the delta-time or as a framework function. Also, allow setting the name of the window, as well as changing the name/width/height/fullscreen at runtime.

Also, do you handle device resetting?

Share this post


Link to post
Share on other sites
NOTE: All quotes belong to ToohrVyk
Quote:

std::vector<std::wstring>* pvecJoyInsName;
std::vector<std::wstring>* pvecJoyPrdName;


Ins = Instance
Prd = Product
OK, I see your point, these will be changed

Quote:

Other than that, why are you using pointers-to-pointers? Why are you passing the GAMEOPTIONS argument by pointer instead of reference?


1 - I am using pointer-to-pointer variables so that the user provides the address of the pointer that will point to the created object/device/blah...
I actually implemented conditional creation, I mean putting a 0 in pvecJoyInsName would mean that you don't want to get Joystick Instance Names...

2 - The *pOptions variable will be changed to &Options.. Good Point

Quote:

A personal nitpick: provide the absolute time, either instead of the delta-time or as a framework function. Also, allow setting the name of the window, as well as changing the name/width/height/fullscreen at runtime.


These points are taken into consideration (and will be changed, [smile])

Quote:

Instead of expecting callback functions, let the user provide a class (so, you know, he isn't forced to have global variables in order to use your framework).


OK, here's an example of how I would implement the GameOptions in a game. note that the Options is initialized to zero in the framework [smile]:

void GameOptions( GAMEOPTIONS* pOptions )
{
pOptions->windowed = false;
pOptions->height = 600;
pOptions->width = 800;
pOptions->deviceType = D3DDEVTYPE_HAL;

pOptions->phInstance = &hInstance;
pOptions->phWnd = &hWnd;
pOptions->ppD3DDevice = &pD3DDev;
pOptions->ppDIKeyboard = &pKeyboard;
pOptions->ppDIMouse = &pMouse;
pOptions->pvecpDIJoystick = &vecpJoy;
pOptions->pSoundManager = &soundManager;
}



I can't wrap my head around the class thingy you are suggesting. Can you show me an example?

Share this post


Link to post
Share on other sites
Quote:
Original post by arithma
I can't wrap my head around the class thingy you are suggesting. Can you show me an example?



class IGame {
public:
virtual void WindowProcessing(UINT msg, WPARAM wParam, LPARAM lParam) { }
virtual void Options(GAMEOPTIONS& options) { /* Default options */ }
virtual void Loop(float time) {}
virtual void Setup() {}
virtual void Cleanup() {}
};

void StartGame(IGame& game);



The user inherits from IGame, implements the functions for which he wants non-default behaviour, creates an instance and passes it to StartGame().

Then, the framework calls game.Options() to apply the options for that game, and forwards all window-processing calls to game.WindowProcessing() in addition to calling Loop, Setup and Cleanup at appropriate times.

Share this post


Link to post
Share on other sites
I admitt it: yours is better [tears]

I suppose for lost device we should just add a callback function?

What about the Effect system, should I care about it, or is the current barebone framework more desirable?

Share this post


Link to post
Share on other sites

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