Jump to content

  • Log In with Google      Sign In   
  • Create Account


Using same graphics framework across different projects?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Waaayoff   Members   -  Reputation: 770

Like
0Likes
Like

Posted 27 April 2014 - 10:50 AM

I want to make games but i also like doing the graphics stuff myself. Over time i wrote a small graphics engine that i continuously add new features to. Up till now I've been copy/pasting the engine code between projects but I want to have the graphics code in just one place and use it across different projects. I also want to keep adding new features to the engine such that the changes affect the engine code in all projects.

 

How can i do this?


"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

Sponsor:

#2 ProtectedMode   Members   -  Reputation: 1083

Like
0Likes
Like

Posted 27 April 2014 - 11:43 AM

I would recommend using a VCS (Version Control System) and a host like GitHub. Then you can easily clone the repository when you need to use it and compile it. You can also easily undo changes that breaks code that's using it. I'm afraid there is not some magical way to update the repository for all projects and compile it AFAIK, but I could be wrong. From your question it seems you want that it automatically updates, but did you think about the fact that the code is probably not compatible all the time?



#3 Waaayoff   Members   -  Reputation: 770

Like
0Likes
Like

Posted 27 April 2014 - 11:48 AM

I am using Mercurial but like you said it doesn't update other projects. The code will always be compatible because it's mostly adding fixes/updates/features to the underlying graphics pipeline.


Edited by Waaayoff, 27 April 2014 - 11:49 AM.

"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

#4 ProtectedMode   Members   -  Reputation: 1083

Like
0Likes
Like

Posted 27 April 2014 - 11:51 AM

I am using Mercurial but like you said it doesn't update other projects. The code will always be compatible because it's mostly adding fixes/updates/features to the underlying graphics pipeline.

It's highly unusual to update a library your project depends on the hole time. I recommend just tagging versions and upgrading once in a while to a stable version. Using a build system like CMake can make it much easier to pull a new version, compile it and use it.



#5 Waaayoff   Members   -  Reputation: 770

Like
0Likes
Like

Posted 27 April 2014 - 12:09 PM

 

I am using Mercurial but like you said it doesn't update other projects. The code will always be compatible because it's mostly adding fixes/updates/features to the underlying graphics pipeline.

It's highly unusual to update a library your project depends on the hole time. I recommend just tagging versions and upgrading once in a while to a stable version. Using a build system like CMake can make it much easier to pull a new version, compile it and use it.

 

 

It's because it isn't finished. I'm basically creating it as i go. When i needed to use 3D textures, i added 3D texture support. When i started using sophisticated shaders, i created a shader pipeline, etc...

 

I guess i can just manually replace the "engine" folder in one project whenever i change it in another one.


"Spending your life waiting for the messiah to come save the world is like waiting around for the straight piece to come in Tetris...even if it comes, by that time you've accumulated a mountain of shit so high that you're fucked no matter what you do. "

#6 stupid_programmer   Members   -  Reputation: 1007

Like
1Likes
Like

Posted 27 April 2014 - 12:31 PM

With SVN you can set an external property to point to another repo.  Whenever you update the first repo it will also check any externals and pull those down as well.  You can do something similar with Git but I'm not sure if that is something that can be done with Mercurial.

 

If you don't want to copy an entire source code folder all the time you could just have your engine code in its own repo and just build the .lib and/or .dll when you do an update and just include that with your games.



#7 ProtectedMode   Members   -  Reputation: 1083

Like
0Likes
Like

Posted 27 April 2014 - 03:54 PM


It's because it isn't finished. I'm basically creating it as i go. When i needed to use 3D textures, i added 3D texture support. When i started using sophisticated shaders, i created a shader pipeline, etc...



I guess i can just manually replace the "engine" folder in one project whenever i change it in another one.

If that's the case I recommend you start with one game, finish it, and then extract the generic parts (your engine) that are useful in other projects, instead of threating your engine as another project...



#8 arka80   Members   -  Reputation: 716

Like
0Likes
Like

Posted 28 April 2014 - 02:55 AM

I think you want to compile the engine part as a (static?) library instead of copy/paste the source code between projects.

 

If you're using VS you have only to create a Library Project, copy and paste (for the last time ;) ) your engine's code, compile et voilà, you have your .lib done, ready to be linked to your projects.


Edited by arka80, 28 April 2014 - 02:56 AM.


#9 Hodgman   Moderators   -  Reputation: 27841

Like
2Likes
Like

Posted 28 April 2014 - 06:20 AM

Just use branches/tags/whatever-your-VCS-calls them for each game/project.
When you update the engine for a new project, the old projects will still be on their old engine branch so will keep working. If you want to go back and update your old projects, you can merge/rebase/etc the latest branch over their old branch (and then manually fix the old code I there were any breaking changes introduced by the update).




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS