really glad i decided to do that as i can see in gDEBugger i've finally got the darn render to texture working..
i just need to get it rendering to a quad, do some housework on the code and i'm on to actually doing stuff with it.
and after a splurge trying to fix it to make a compo entry, i fixed somethings and saw no end in sight.. 3 months due to that, and due to xmas (sounds like an ideal time, but with the mrs off too, hardly any alone time)
i've done very little for too long.. and run out of will power to debug it anymore, still in the back of mind all the time though, and i've stil been checking in on DBF (and Pouet)
have put a few hours in and entirely given up. am circumventing the current issue by making a new test app to learn about and create helpers for the texturing bits.
test app i'm just starting will have 3 textured in quads on the screen.
the first one will be a traditionally loaded from BMP style (i'm going to use the 'crate' image form the NEHE tutorials but convert it to a .H so there's no need to load from disk).
the second, a buffered "texture"
the third, rendering the texture create via RTT (which hopefully now gets me to where I've fixed the original problem and have some robust, multipurpose where necessary texturing code)
just to add even more pain to this, once i'm done and have what I feel I need in my boilerplate 'simple' opengl c framework. i'm going to sit down and review the whole structure of what i've got and rejig it, mostly i think the style/structure of the API and how the code is included in projects will go through the most change.
currently: some things aren't abstracted enough, and some are abstracted too much.
i need to get to a point where i'm focusing on writing apps not the shit to manage it and rebooting the lib seems arse backwards, but its not currently designed along the lines of seperatoin in some places where it could be.
