KieranChandler

Members
  • Content count

    45
  • Joined

  • Last visited

Community Reputation

241 Neutral

About KieranChandler

  • Rank
    Member
  1. Unity Game Engine Modules/Projects

    I have tried putting the COMPONENT_REGISTER macros in the Run() function, but now i am getting a load of errors the first being: Error C2951: template declarations are only permitted at global, namespace, or class scope.
  2. Unity Game Engine Modules/Projects

      Ahh okay, that way works a treat actually because i have to have Engine.Run(); so if that way would work that would be perfect. I will try it when i get home, Thanks!
  3. Unity Game Engine Modules/Projects

    Yeah this is what i mean the only solution i can find on the interwebs is to reference or define the statics in the executable, but the game is the executable so that means every time a game is made I (or any other user for that matter) will need to manually register not only their components, but the engine components too.   Is this actually the ONLY way to do this? or might there be some elaborate way to conquer this?
  4. Unity Game Engine Modules/Projects

      I've been reading quite a bit about it and everywhere i read, there is at least someone saying something along the lines of 'it is bad practice', but I can't think of any other "automatic" way of doing this. I want to be able to create new components in the game project and possibly in scripts in the future, so it needs to be automatic.   How would you recommend approaching this?
  5. Unity Game Engine Modules/Projects

    I was given this code by another member of this forum a while ago. I still don't thoroughly understand it which may be what is impeding me in overcoming this.   namespace ComponentRegistry { typedef Component* (*CreateComponentFunc)(); typedef std::map<std::string, CreateComponentFunc> ComponentRegistry; inline ComponentRegistry& getComponentRegistry() { static ComponentRegistry reg; return reg; } template<class T> Component* createComponent() { return new T; } template<class T> struct RegistryEntry { public: static RegistryEntry<T>& Instance(const std::string& name) { // Because I use a singleton here, even though `COMPONENT_REGISTER` // is expanded in multiple translation units, the constructor // will only be executed once. Only this cheap `Instance` function // (which most likely gets inlined) is executed multiple times. static RegistryEntry<T> inst(name); return inst; } private: RegistryEntry(const std::string& name) { ComponentRegistry& reg = getComponentRegistry(); CreateComponentFunc func = createComponent < T >; std::pair<ComponentRegistry::iterator, bool> ret = reg.insert(ComponentRegistry::value_type(name, func)); if(ret.second == false) { // This means there already is a component registered to // this name. You should handle this error as you see fit. } } RegistryEntry(const RegistryEntry<T>&) = delete; // C++11 feature RegistryEntry& operator=(const RegistryEntry<T>&) = delete; }; } And then for each component i have this macro in the .cpp file #define COMPONENT_REGISTER(TYPE, NAME) \ template<class T> \ class ComponentRegistration; \ \ template<> \ class ComponentRegistration<TYPE> \ { \ static const ComponentRegistry::RegistryEntry<TYPE>& reg; \ }; \ \ const ComponentRegistry::RegistryEntry<TYPE>& \ ComponentRegistration<TYPE>::reg = \ ComponentRegistry::RegistryEntry<TYPE>::Instance(NAME); \ When i run the version where the engine is static lib and the game and executable the component registry is empty
  6. Unity Game Engine Modules/Projects

      I remember now! it is because i have a component factory that uses static initialization, which if the statics are defined in the static library, don't get initialized :(
  7. Unity Game Engine Modules/Projects

      This is the sort of thing I attempted when I first tried it, but I can't remember why it didn't work. I'll give it another go and see what results I get!   Thanks for the help Josh!
  8. Unity Game Engine Modules/Projects

      That class is tied into the engine project not a separate one its part of the platform abstraction layer the header and class declaration resides in Core/Platform/GameLoop.h and the definitions reside in Core/Platform/Windows/GameLoop.cpp where windows would be the platform for which the game is being compiled. this makes it a fundamental part of the engine, which means i can't put it in the game project
  9. Unity Game Engine Modules/Projects

      You'll (generally) have to write a main function for all of your games, since the games are the .exes where your main entrypoint has to be. However you can reduce the amount of boilerplate to something like: int main () {   MyAwesomeGame game;   return game.run(); } or similar with a bit of work (here "MyAwesomeGame" is a subclass of "YourEngine::Game" or whatever which implements only the game-specific logic, the boilerplate stuff being taken care of by the YourEngine::Game base class from your static library. Is that what you were going for? Where did you run into trouble along that path?   (there are ways to avoid having to write a main function, including a paradigm where you engine is the .exe and your games are shipped as DLLs, but again, that's probably overcomplication).     I have a class that basically brings all the main subsystems together such as the graphics manager, the timer, the world manager, the game loop (which does essentially what a main function would do) int GameLoop::Run() { m_pTime = m_pEngine->GetTime(); MSG msg = { 0 }; while(!m_bWantToQuit) { if(PeekMessage(&msg, (HWND)m_pWindow->GetHandle(), 0, 0, PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); } if (msg.message == WM_QUIT) break; m_pTime->Tick(); m_pEngine->Update(m_pTime->GetDeltaTime()); m_pEngine->Render(0); } return 0; } I did this to allow me to abstract the platform specific code so all implementation is in the cpp file and there are different ones for each platform.   would the Engine class be the one you are talking about? Or are you saying to make a separate class that starts up the Engine class so to speak?
  10. Unity Game Engine Modules/Projects

      That is what I have been aiming to do. Initially I just made the Engine project compile to a static lib and had the game as the EXE but i couldn't come up with a way to make that work without having the entry point in the game project and have that load the engine, which means i have to write that main function for every game i ever want to make with the engine
  11. Unity Game Engine Modules/Projects

      It does because i cant make the game as well at the moment because i have no way of separating the game from the engine.     After what I've been reading recently I would prefer to compile to a static lib to begin at least because it is simpler, I agree with that.
  12. Unity Game Engine Modules/Projects

    That advice also means that if you make a game from scratch, you will automatically end up with an engine by the end, but if you make an engine in isolation, it will be a jack of all games and master of none. As for DLLs vs static libs, use static by default and DLL when forced to. DLLs are a lot more complex and only give a few benefits - dynamic loading (and potentially reloading) ability to be replaced without recompiling the game (assuming the DLL was written in C, not C++...). Having "engine" (shared, reusable) code in a library, shared by multiple EXEs is a fairly common approach.    So do you think, given what i said before, that it would still be more beneficial for me to try and create some specific games first?   Also if I were to start out compiling to a static lib and then find out down the line that I need to compile to DLL I would need to make quite a few code changes wouldn't I? also if iI wanted to have c# as the primary scripting language I would have to compile to a DLL wouldn't I?
  13. Unity Game Engine Modules/Projects

    I know the common saying is to make games not a game engine, but there are some things that you may not learn by simply making games and i would like to learn about those things, which is why i would prefer to make a game engine.     Why? What are your goals in choosing this particular approach?     To have an engine that i can use to make basic games in and use as a test platform for learning new things (more specifically, low level aspects). It also means i can easily modify the engine while working on games.       I'm not sure which one will work better though. Ideally, i would like people who have had past experience with this to comment on their experience and possibly what mistakes they made and why they think their way is better.
  14. Hi there,   I recently started writing a small game engine, mainly for educational purpose not intending to sell it, but i do intend to use it (hopefully). I have got to a point where it has enough features to make a basic game, but i can't really think of any way to make a game with it without tying game-specific code to the engine.   I would like to have 3 projects setup like this: ·         Engine [Lib/DLL] ·         Game [EXE] ·         Editor [EXE] Im not quite sure how to achieve this or if this is even the correct approach. I'm also not entirely sure, lets say this is the correct approach, whether or not i compile the engine into a static library or a dynamic library. I have read a little about static libraries vs DLLs but i'm still not sure which one would actually better as they both have their disadvantages.   The game world in this engine is composed of actors(Game Objects) which can have components attached to them, just like unity and UE4 (more so like UE4) and i would like to be able to easily define actor and component types in the game project.   Also please note i am hoping to make this cross-platform (the editor side of things at least, so i can edit the game on linux).
  15. What i mean by Unity3D doing it is the engine is written in C++ and only the users use C# to script it, so the adding of components and things related are all implemented in C++ and then you just call the functions in C#   There is some stuff there i don't completely understand, so i would like to try and understand that lot of code before i implement it. I think is saw something very similar to this a few days ago when i was searching for a solution so i'm guessing this is a popular way to do it.   Thank you very much for your help Juliean