This will most likely make code backwards incompatible, but rapid hasn't had a stable release yet so it should not be a problem.
This accounts for:
[ ] Re-organizing the modules
[x] Refactoring some of low-level gfx/surface, because it's a mess
A good example of this is that there are procs like proc newGfx(width, height: int, conf: RTextureConfig): RGfx, which allow you to create off-screen framebuffers, but they're unusable since template render is specific to window-bound Gfxes and there is no proc for switching the framebuffer manually (except using raw OpenGL calls, but that completely loses the point of even having a game engine)
[ ] Move all of res into gfx, to follow that audio did with RWave (it's a better idea, and it removes the need for common rapid/res/texture imports)
Use a state object (called REngine? RState? Rapid?) instead of global variables This will make code more complex, giving up on this
This will most likely make code backwards incompatible, but rapid hasn't had a stable release yet so it should not be a problem.
This accounts for:
gfx/surface, because it's a mess A good example of this is that there are procs likeproc newGfx(width, height: int, conf: RTextureConfig): RGfx, which allow you to create off-screen framebuffers, but they're unusable sincetemplate renderis specific to window-boundGfxes and there is no proc for switching the framebuffer manually (except using raw OpenGL calls, but that completely loses the point of even having a game engine)resintogfx, to follow thataudiodid withRWave(it's a better idea, and it removes the need for commonrapid/res/textureimports)Use a state object (calledThis will make code more complex, giving up on thisREngine?RState?Rapid?) instead of global variables