Not going to happen, at all. Everything is heavily dependent (not that that's a bad thing). Besides, I'm working on my own engine and game here. This isn't a "try to make portals" project. It is merely a sub-system to the whole enginePraetor wrote:How viable is it to not create this as an entire engine, but instead as a library which can hook into engines? It might be a pain to abstract out things like which physics engine is used, so maybe it isn't worth it at first.
- NewtonGD is the best choice for this since it used C-style callbacks for everything. A normal "here, on each update just use getPosition() to put your graphics object at the right spot" type of engine is not going to work.
- my whole framework of physics is based directly upon Newton and directly upon portals (... and, *cough* other physical confusions I'm not going to talk about here )
- due to the portals, the rendering order and loop is heavily dependent. I'm skipping the whole renderOneFrame()/FrameListener idea. I'm also skipping the whole windowRT->update() idea. I render the main scene manually, then each portal manually. The stencil buffer should not be messed with during some parts, either.
- many other things that I'm not going into-depth here
Basically, portals aren't a plug-n-play type of thing, to put it simply. That's why it took Portal a year or two, even though the whole game engine and everything was complete.
On another note, I've lots of updates. Going to upload a video and put it on the first post shortly.