Pages: [1]
  Print  
Author Topic: PowerVR fun  (Read 11805 times)
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« on: March 14, 2012, 01:58:25 AM »

here's q3 running fast on a pcx2

learning how to pull this off makes me a bit more optimistic about doing OA3 since q3's a technical mess.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #1 on: March 14, 2012, 04:06:20 AM »

Sorry I'm no graphical artist Sad Could you please explain what is the problem? Q3 seems to be looking fine to me in this benchmark.
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #2 on: March 14, 2012, 04:28:46 AM »

This is a video card originally meant for games like Mechwarrior 2. It's going some places where it's never gone before and it's performing well..
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #3 on: March 14, 2012, 04:33:07 AM »

Oh well, then you've succeeded pretty well, it all seemed so normal and natural to me in the video XD
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #4 on: March 15, 2012, 06:30:39 PM »

The main quirks:
  • Textures are blended by their sample size. RGB is always opaque while RGBA will always be alpha blended no matter what you do.
  • Min tex size: 32x32. Max tex size: 256x256
  • You only have alpha blend available
  • No texture clamping
  • RGBA4 and RGB5 are supported only
  • On top of being only 4-bits of alpha ever, there's also only 16 steps of alpha modulation, so fade outs WILL ALWAYS BE BANDED
  • John Carmack kind of gave up on this card in early development of Q3A, as a matter of fact it's like one of the only cards that can't properly run the game
  • no portals

One way of doing some compatibility with PCX2 is slipping a forced 24-bit texture upload by a new flag in shader in way of this....

Code:
textures/goodset/someshinewall
{
          //PCXHACK force24
          {

And for stuff that's meant to be additive, we could have alternative 32bit shaders and other commands loaded through a PCXHACK comment


Code:
gfx/2d/marks/somemark
{

          {
             map gfx/2d/marks/somemark.tga
             blend GL_ZERO GL_ZERO
             rgbGen vertex
             //PCXHACK map gfx/2d/marks/somemark_alpha.tga
             //PCXHACK blend alpha
             //PCXHACK rgbgen const '0 0 0'
          }
}

It's also possible to do a similar method for other cards like Rage Pro, in which it's reverse of pcx2's issues - it can't alpha blend at all, and it does that through the CPU which makes extremely slow performance.

Like
Code:
gfx/2d/fx/smokesmoke
{

          {
             map gfx/2d/fx/smoke.tga
             blend alpha
             //RAGEHACK map gfx/2d/fx/smokeadd
             //RAGEHACK blend add

          }
}

« Last Edit: March 15, 2012, 06:52:44 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #5 on: March 16, 2012, 02:19:55 AM »

A video of oa088 on the PCX2

Necessary cvars:
videoflags 0
r_vertexLight 1        (hardware like this is the reason vertexlight is made for)
r_fastsky 1
r_picmip 1
r_detailtextures 0
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #6 on: May 11, 2012, 03:28:00 AM »

I got flares looking good on alpha blends as an option




Also another unrelated renderer change, i've made rgbGen const get affected by overbrights leading to more consistent color between fullscreen and windowed for shaders that use const.  Does doing this bear any consequences?
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
andrewj
Member


Cakes 24
Posts: 584



« Reply #7 on: May 27, 2012, 10:17:49 PM »

Bumping this since I had an idea....

I think rather than hacky comment crap in the shader files, you should have a special folder for different hardware containing shaders just for that hardware, and modify the engine to load those shaders when that particular hardware is being used

This applies to GLSL too!

It might work best with a 'hardware' top-level folder

Examples:
  hardware/pcx/oanew.shader
  hardware/glsl/coolwater.shader
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #8 on: May 28, 2012, 05:14:55 PM »

I thought of that, but loading shaders twice I thought would cause issues with shaders of the same filename. Say if you only had a shader file with one shader entry in hardware/glsl/gothic_block.shader, it'd break all the shaders in scripts/gothic_block.shader

There'd also needed to be hardware/rage/ and hardware/sw/ too. Rage would try to have additive blended alternatives to alpha-heavy shaders like rocket smoke (pretty much the opposite of PCX2), and Sw/ would just be a last ditch alphatest GT0 mania.


Having hardware/ folders WOULD maintain compatibility better than trying to bloat a shader with workarounds. Q3ASE destroys those comment tricks sadly.
« Last Edit: May 28, 2012, 06:26:31 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
andrewj
Member


Cakes 24
Posts: 584



« Reply #9 on: May 29, 2012, 01:07:23 AM »

I thought of that, but loading shaders twice I thought would cause issues with shaders of the same filename. Say if you only had a shader file with one shader entry in hardware/glsl/gothic_block.shader, it'd break all the shaders in scripts/gothic_block.shader
My idea is to use FS_ListFiles twice, once to get the normal shader filenames and second time to get the hardware specific filenames, appending the hardware ones onto the end of the list.  Hence you would get both scripts/gothic_block.shader and hardware/glsl/gothic_block.shader in the list (and in the final big block of shader data).

The reason I put hardware/ at the top level (instead of having scripts/pcx/*.shader) is that I think FS_ListFiles will match results that are in sub-directories too, so you would end up getting all the shader files in all the sub-directories of scripts/ -- not what we want.

Maybe tonight I'll play around with the code......
Logged
andrewj
Member


Cakes 24
Posts: 584



« Reply #10 on: May 29, 2012, 05:41:31 AM »

OK, I tried it.

The main problem is that all shaders in an active hardware/ section override any shader with the same name, even in in later pk3s (i.e. earlier in the search path).

I'm not sure that is a big problem, because shader overriding (on a per-shader basis) has never worked properly (although it is easy to fix).  I guess when people wanted to override a particular shader, they copied the whole xxx.shader file and modified that shader -- i.e. the granularity of shader replacements was at the file level, not at the level of individual shaders.

Anyway I'll post a patch soon.

P.S. I'm not sure how to determine the sub-directory name (nothing for normal, "pcx" for PowerVR, etc).  Should it be stored in a new cvar??
Logged
Pages: [1]
  Print  
 
Jump to: