CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 5 of 5
  1. #1
    Join Date
    Feb 2015
    Posts
    6

    Post App -- Engine interaction need help

    In learning purposes I've started to create my own game engine using C++, OpenGL 3.3, XAudio2 and some minor dependencies
    The problems i reach are most commonly about structure of engine itself, like where does the App begins and Engine ends?
    Name:  schemeengine.jpg
Views: 653
Size:  93.6 KB
    For now I have Engine project building into .lib, and Editor project building into .exe, that depends on Engine.lib and uses it:
    Name:  projectlist.jpg
Views: 761
Size:  90.8 KB

    -----------------------------------

    The problem is i need my Logic of App to react on events like Update, click on Button, how do i achieve that if Engine must be a built-ready alone app, not depending on my Logic.h, but Logic.h must react on events in Engine?

    I thought about engineSetButtonPressCallback(void (*p)(...)), engineSetUpdateCallback(void (*p)()), but that seems wrong, like accessing not your own scope

    So if Engine and App are 2 different entities, who can transport events from Engine to App? I prefer not to use OOP, so Engine is not a class, and App can't be like class App:Engine, so i could use virtual methods

    -----------------------------------

    main.cpp is like:
    Code:
    int __stdcall WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
    {
    	// Pre-init
    	CoInitialize(0); // COM init
    	std::ios::sync_with_stdio(false); // super fast io
    
    	ResetCurrentDirectory();
    
    	// Init
    
    	swEngineInit();
    
    	// 
    
    	logicInit();
    	
    	// Run
    
    	
    
    	swEngineRun();
    
    	// Release
    
    	swEngineRelease();
    
    	// Exit
    
    	closelog();
    	CoUninitialize();
    
    	return 0; // end app
    }
    logic comes for smth like that:

    Code:
    #include "Logic.h"
    
    // globals
    
    bool bUILoaded = false;
    
    
    
    // end globals
    
    void preloadUI()
    {
    	std::ifstream input("UIList.txt", std::ios::in);
    	char buffer[256]; string line;
    	while(input.getline(buffer, 255))
    	{
    		line = buffer;
    		if(line != "")
    		{
    			tpPreloadTexture(line, TEXTURE_TYPE_SHARP);
    		}
    	}
    
    	input.close();
    	
    	bUILoaded = true;
    }
    
    void logicInit()
    {
    	tpPreloadTexture("Graphic/UI/LoadScreen.png", TEXTURE_TYPE_SHARP);
    	uiSetBackground("Graphic/UI/LoadScreen.png");
    
    	Sprite s;
    	s.name = "test";
    	s.relx = 0.5;
    	s.rely = 0.5;
    	s.posy = 60;
    	s.width = 100;
    	s.height = 60;
    	s.texture = "Graphic/UI/ButtonStart.png";
    	uiAddSprite(s);
    
    	
    
    	saDestroyOnEnd(saCreateSound("Sound/Arrow/arrwdth_02.ogg"));
    
    	preloadUI();
    }
    
    void logicUpdate()
    {
    	
    }
    
    void logicSpritePress(string name)
    {
    
    }
    
    void logicButtonPress(string name)
    {
    
    }
    the main loop stuff hiden in engine:

    Code:
    void swEngineRun()
    {
    	printlog("message: entering win loop");
    	waEventLoop();
    }
    winapi, depending highly on framework GLFW:

    Code:
    void waEventLoop()
    {
    	LARGE_INTEGER timeFrequency;
    	LARGE_INTEGER timeNow;
    	bool useQPC = QueryPerformanceFrequency(&timeFrequency);
    	double prevTime = 0.0;
    
    	if(useQPC)
    	{
    		QueryPerformanceCounter(&timeNow);
    		dCreateTime = (1000LL * timeNow.QuadPart) / timeFrequency.QuadPart * 0.001;
    	} else
    		dCreateTime = GetTickCount() * 0.001;
    
    	while(true)
    	{
    		glfwPollEvents();
    
    		if(bErrorFlag)
    		{
    			printlog("message: fatal error in engine, closing win loop");
    			break;
    		}
    
    		if(bExitFlag)
    		{
    			printlog("message: exit message recieved, closing win loop");
    			break;
    		}
    
    		prevTime=dRealTime;
    
    		if(useQPC)
    		{
    			QueryPerformanceCounter(&timeNow);
    			dRealTime = (1000LL * timeNow.QuadPart) / timeFrequency.QuadPart * 0.001;
    		} else
    			dRealTime = GetTickCount() * 0.001;
    
    		bPrevMouseLeft = glfwGetMouseButton(hWindow, GLFW_MOUSE_BUTTON_LEFT);
    		bPrevMouseRight = glfwGetMouseButton(hWindow, GLFW_MOUSE_BUTTON_RIGHT);
    		for(int i = 0; i < 512; i++)
    		{
    			bPrevKey[i] = glfwGetKey(hWindow, i);
    		}
    
    		if(dRealTime - dTime >= UPDATE_INTERVAL)
    		{
    			dTime += UPDATE_INTERVAL;
    			if(dRealTime - dTime > UPDATE_INTERVAL * UPDATE_DEATH)
    			{
    				dTime = dRealTime - UPDATE_INTERVAL * UPDATE_DEATH;
    			}
    
    			// update
    
    			swEngineUpdate();
    
    			// errors
    
    			if(saGetErrorFlag()) bErrorFlag = true;
    			if(raGetErrorFlag()) bErrorFlag = true;
    
    			glfwSwapBuffers(hWindow);
    		}
    
    		if(!glfwGetWindowAttrib(hWindow, GLFW_FOCUSED))
    		{
    			Sleep(2);
    		}
    	}
    }
    engine update is like:

    Code:
    void swEngineUpdate()
    {
    	// update
    
    	uiUpdate();
    
    	// render
    
    	raRenderStart();
    
    	uiRender();
    
    	raRenderEnd();
    }
    --------------------------------------------

    sorry for my crappy english, i hope u understood my question and can help me with the topic, im solving this question for a long time. also sorry for in-text attachments, can't find the spoiler button :/

  2. #2
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: App -- Engine interaction need help

    Any part of your game that is generic enough that you could reuse it in a totally new game, probably should go into "engine"

    There is Always going to be a grey area in that. If you make a 3D space game, then some parts of your 'game' would be reusable in another 3D space game, but would probably not make much sense in a sports game.

    You can Always also split up into 3 projects rather than 2. "engine", "space 3D game", "the game"
    There's pro's and cons to each thing. Are you writing an engine just for yourself, then this stuff is going to matter less, if you intend to make the engine available to others, then it may be more important (but then you'll be dealing with the competition in that area).

    Also: A big part of your game is goign to be developing the game resources such as maps, I see you're making your own here. NOthing wrong with that per se, but that typically only happens for "big budget" games. Most games tend to revolve around procedurally generated data or "big spreadsheets" with some simple conversion apps in between.
    Full fledged editors take a lot of time to make, so you could end up spending a lot of time on that rather than on your actual game.
    I can only stress how important it is to work on your game and not get stuck on developping side tools. Avoid the side tools as much as possible, focus on your game, and make what resources you need "by hand" until you get to the stage where your game engine and game itself is nearing completion. A lot of games run dead JUST BECAUSE of this simple fact of getting stuck in design phase and stuck in developing tooling. USe as much available tooling as there is rather than making your own.

  3. #3
    Join Date
    Feb 2015
    Posts
    6

    Re: App -- Engine interaction need help

    Thank you so much for the answer, i know about the map stuff, i've seen may editors like TQ's, ARMA's, Unity's, and Warcraft 3 Map editor, that's my favourite, i know it's going to be hard, but i love making this shiet so much, so that's not a question of completion, but the process itself, and now im sad because im just stopped unable to continue my project, but I think there's nothing that can "stuck" you on phase of developing tooling except yourself or timelack, and i'm saying i have enough time...

    It is not going to be reusable, starting from my coding skills, finishing with my aim - learning! It just needs to be useful by me, you know, before that project I used DirectX 11 and monolit style programming - I wrote everything in a single .cpp file, what resulted in uneditable, unreadable hell after week of non-coding(i forgot what is what), now i'm trying to do it all great, so i think not about using of Engine for diffent projects, but about using it for my App, which will consist of map editor, game itself(just a 3d walkaround simulator, maybe rpg elements if some concept comes).

    Yesterday i though about Engine.exe, reading Scripts.txt(different for editor and game app), which is like:

    Code:
    void OnInit()
    {
    PreloadBG(...)
    SetBG(...)
    PreloadUI()
    WaitPreload() // sleep logic thread until parallel texture loading count > 0
    AddButton(...) // n times
    }
    void OnButtonPress(string name)
    {
    if(name == "play")
    {
    ClearUI()
    SetBG(...)
    PreloadWorld()
    WaitPreload()
    bPlaying = true;
    }
    }
    
    void OnUpdate()
    {
    if(bPlaying)
    {
    doAI()
    moveBullets()
    moveUnits()
    movePlayer()
    doCollisions() //bullet or smth
    }
    }
    But why the hell should engine be about the app itself? X_X

    I started to think about this again:
    Code:
    class Engine
    {
    virtual void onInit()=0;
    virtual void onButtonPress()=0;
    virtual void ...
    }
    class Editor:Engine
    {
    ...
    }
    I can only stress how important it is to work on your game and not get stuck on developping side tools. Avoid the side tools as much as possible, focus on your game, and make what resources you need "by hand" until you get to the stage where your game engine and game itself is nearing completion. A lot of games run dead JUST BECAUSE of this simple fact of getting stuck in design phase and stuck in developing tooling. USe as much available tooling as there is rather than making your own.
    I mean not like creating a game, but like learning to create a game, another way i would use Unity, but i have neither ideas nor concept creating skills

    All I want is to hear about(watch at) good realization strcucture of Engine-Game contact, like a hand in the right direction, because bad model will result in a crappy engine, im sure

  4. #4
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: App -- Engine interaction need help

    You cannot realistically develop a usable game engine model/concept if you have never made games.

    It's the experience at making games and how design choices affected your outcome that will teach you what things work, and what ideas are bad.

    "on paper" you can make pretty much anything work, but in practice is another thing.

    A game engine like unity has "a lot of history" in how they approach things. And unity works for the type of projects it was designed for and "can be made to work" (with issues) for things it wasn't designed for (like Kerbal Space Program, unity isn't really designed for spage games), and isn't usuable at all for some other things. That's why there's different game engines catering to different genres of games.

    Again, you need to have a "real game" in mind if you're going to do this, making an engine without an actual game concept it needs to support isn't going to get you far.

  5. #5
    Join Date
    Feb 2015
    Posts
    6

    Re: App -- Engine interaction need help

    Quote Originally Posted by OReubens View Post
    You cannot realistically develop a usable game engine model/concept if you have never made games.

    It's the experience at making games and how design choices affected your outcome that will teach you what things work, and what ideas are bad.

    "on paper" you can make pretty much anything work, but in practice is another thing.

    A game engine like unity has "a lot of history" in how they approach things. And unity works for the type of projects it was designed for and "can be made to work" (with issues) for things it wasn't designed for (like Kerbal Space Program, unity isn't really designed for spage games), and isn't usuable at all for some other things. That's why there's different game engines catering to different genres of games.

    Again, you need to have a "real game" in mind if you're going to do this, making an engine without an actual game concept it needs to support isn't going to get you far.
    Yep, you are right, thank you for placing dots above i

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured