2 hours ago, ryt said:
I created a simple project/game around Allegro. The project is tightly bound to the API, including rendering, transforms, audio and other. I would like to port it to SFML but without loosing all of the work I already have done. I thought to create some wrapper around them so the game doesn't even know which one I'm using and I also wanted to be able to switch between them with few lines of code.
Has anyone done something similar and maybe has some recommendations how to do it?
Assuming you're doing it in proper OO, there are design patterns such as Adaptor and Facade which you might want to read about.
In my experience, backfitting a decoupling layer is usually a significantly larger PITA than doing things with that in mind from the beginning.
You might want to start by analysing which functionaliy you use from the library and how (at it's most basic, just make a list of objects used and methods called), which is boring from the point of view of a coder but does end up paying itself by sparing you some back-and-forth time wasting that happens when one dives into coding too early and then suddenly discovers something that screws up one's approach.
At the same time, you might want to set up some kind of unit testing around the whole thing so that you can test the before and after refactoring results and make sure they're the same.
Also, COMMIT EVERYTHING into your source control before you start refactoring! (probably needs not be said, but hey: no harm done)
Beware of implicit and non-visible dependencies, such as things like how NULLs are handled in one library vs the other, expectations in your code of getting back empty strings or empty arrays signifying NOT FOUND and now getting back nulls (or vice-versa), how objects are supposed to be initialized or not and other such expectations in the code which are not visible from simply the method signatures.
Keep in mind that if your code is tightly coupled to the library, this might be a much vaster task than you expect. That analysis job at the beginning will give you a much better grasp on the size of the task and let you see if for some parts it's less work to redo them from scratch than refactor them.