Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jorgon]

That is exactly what I thought.

The code I posted doesn't have any rendering paths for old hardware in it. It requires EXT_framebuffer_object and ARB_texture_non_power_of_two extensions to work properly. The final logic should be:

Code: [Select]

turn partial print on
if framebuffer_object support
  use render to texture
else
  use original partial print.

If non power of two texture support is missing, the target render buffer would just need to be rounded up to the next power of two.

[Electronic Phantom]

...Ok...

I'll see what I can do.

Just out of curiosity, does your accelleration coding require the extra extensions... Let me put the question another way: If I manage to put in the below logic correctly, will I still get (approx) the same results as somebody who doesn't have the logic?  I'm trying to figure out if it's worth my time to 'fix' the code so that it works.  If I can't fix the code without doing a major rehaul, then I'm not really interested in trying considering that that project alone is quite a bit beyond my capabilities and would require programming resources I don't have available to me at this time.

-(e)EP

[Jorgon]

It should only be a few lines, tops.

I just updated the code to detect whether or not the card has render to texture support, and if it does, it uses it. If not, it uses toady's normal partial print.

If you want to look at what happens, find

Code: [Select]

if(GLEE_EXT_framebuffer_object)

and references to the rtt_hardware_support variable. PARTIAL_PRINT is forced on in this code but you shouldn't need to turn it off.

I also included a prebuilt exe for people to test if they are curious.