What are you working on?

[leileilol]

Personally i'd want DDS loading in OA as well, but decoded differently in software, being 25% of the texture size instead, so I could have large 2048x2048 DDS textures loaded as 512x512 with none of the blocky DXT artifacts if the hardware sucks (most likely pre-Savage4 and free Linux implementations of drivers would need this)


A good tr_image_dds.c is something I wish for.

XreaL has one but it's suspicious and potentially patent violating.

[mh]

Personally i'd want DDS loading in OA as well, but decoded differently in software, being 25% of the texture size instead, so I could have large 2048x2048 DDS textures loaded as 512x512 with none of the blocky DXT artifacts if the hardware sucks (most likely pre-Savage4 and free Linux implementations of drivers would need this)


A good tr_image_dds.c is something I wish for.

XreaL has one but it's suspicious and potentially patent violating.

That's more or less what DP does; it quarters the size in each dimension and just decodes the palettes into the destination texels. It looks fine enough, but at that kind of resize you may as well go for the original native textures to be honest. My own decoder does each 4x4 block properly and is almost just as fast

Older hardware that doesn't support texture compression is highly unlikely to support high res textures either. That leaves free Linux drivers as the real target for this kind of solution.

Some research indicates that the patent may actually be invalid, but I haven't found anything to definitely indicate it's status.

[mh]

Hmmmm. Xreal's looks suspect.

Xonotic has an "S2TC" format which is MIT licensed and they provide code to convert raw DXT to this format (without any intermediate RGBA). Round-tripping though this converter then decoding the resulting S2TC seems a more viable approach to me.

[Spirit]

http://leileilol.mancubus.net/engoo/tinge1.gif

I always wondered, what causes the ugly distortion on the weapon? FOV?

[taniwha]

http://leileilol.mancubus.net/engoo/tinge1.gif

I always wondered, what causes the ugly distortion on the weapon? FOV?

Looks to me like widesceen with incorrect aspect ratio.

[leileilol]

That's something i fixed today

[Spirit]

Hm, that gl looks a bit curvy, like a banana.

[taniwha]

That's something i fixed today

Yup, that looks right for widescreen at the correct aspect

Wow, that's a tiny status bar, but you get that if you don't get scaling for free.

[leileilol]

what I really need to do is compensate the FOV somehow by editing R_ViewChanged. It's too zoomed in and this is fov 90!'

EDIT: now it's too zoomed out!

[taniwha]

what I really need to do is compensate the FOV somehow by editing R_ViewChanged. It's too zoomed in and this is fov 90!'

EDIT: now it's too zoomed out!

Maybe a tad. QF still bases its FOV calcs on X (ie, FOV is the angle in the X plane, rather than Y (screen coords)). The corners of the near side of the entrance pillars and the outer walls are pretty much on the edge of the screen in QF (give or take a few pixels). There are two other alternatives: base the calculations on Y (but this will give different results to standard quake), or base the calculations on the X of a 4:3 window in the widescreen. This will give the closest results, with extra view to the sides. However, both methods will have trouble as you approach extreme FOV angles (nearing 180). Not insurmountable, but care must be taken.

Is that colored lighting?

[leileilol]

What i'm after is just making a FOV like the original Quake's but wider, complete with the old viewmodel fudging. I'm also trying to maintaing the old Quake aspect, fov and frustum for all the non-wide modes under 720 height.

Yes, that's colored lighting. It's kind of sluggish because there's no ASM function written for its surfmipblock functions or its model drawing functions. What it does is process in 24-bit RGB and then throw it through a 18to8 lookup table (also an option for 15to8 for crappier precision lighting). For the colors on the dynamics I tried to follow the colors set by Darkplaces and DirectQ

[mh]

The way I do it is that I first set fov_x to the cvar value. Then I calculate a new fov_y using that value, but as if the screen were a fixed-size 4:3 resolution (I actually subtract 48 for the default sb_lines from height here), although you could set this up to mimic DOS Quake's default 320x200 if you wanted. Finally I feed the actual screen resolution (again subtracting 48 for the default sb_lines) and this new fov_y into a calculation of the final real fov_x. These values of fov_x and fov_y are then used to build the projection matrix directly (http://msdn.microsoft.com/en-us/library/windows/desktop/bb147302%28v=vs.85%29.aspx is helpful, although it needs some tweaking for OpenGL) rather than using any helper functions like glFrustum or gluPerspective (what's neat about this is that you can then twiddle with elements in the matrix to produce a good-looking underwater warp effect for free).

Much of it is based on a GameDev post at: http://www.gamedev.net/topic/431111-per ... -vertical/ and it also gives results consistent with an online FOV calculator at http://www.emsai.net/projects/widescreen/fovcalc/

[ceriux]

leilei i have to say that engoo , looks pretty awesome.

[Baker]

What i'm after is just making a FOV like the original Quake's but wider, complete with the old viewmodel fudging. I'm also trying to maintaing the old Quake aspect, fov and frustum for all the non-wide modes under 720 height.

Yes, that's colored lighting. It's kind of sluggish because there's no ASM function written for its surfmipblock functions or its model drawing functions. What it does is process in 24-bit RGB and then throw it through a 18to8 lookup table (also an option for 15to8 for crappier precision lighting). For the colors on the dynamics I tried to follow the colors set by Darkplaces and DirectQ

I wrote this code to be able to simulate other screen aspect ratios. To simulate an 8:5 aspect ratio, for example .... 8/5 = 1.6 or cvar value scene_fov_scaleaspect "1.6", or for 4:3 would be "1.33333333", etc. etc.

Code: Select all

   switch (scene_fov_scale.integer)
   {
   case 0:   r_refdef.fov_x = scene_fov_x.floater;      // Standard Quake
         r_refdef.fov_y = CalcFov (r_refdef.fov_x, r_refdef.vrect.width, r_refdef.vrect.height);
         break;

         // Aspect ratio correct to 4:3 or whatever scr_fov_scaleaspect's value is
   case 1: r_refdef.fov_y = CalcFov (scene_fov_x.floater, r_refdef.vrect.height * scene_fov_scaleaspect.floater, r_refdef.vrect.height);
         r_refdef.fov_x = CalcFov (r_refdef.fov_y, r_refdef.vrect.height, r_refdef.vrect.width);
         break;

         // Aspect ratio correct favoring Y
   case 2: r_refdef.fov_x = CalcFov (scene_fov_x.floater, r_refdef.vrect.height * scene_fov_scaleaspect.floater, r_refdef.vrect.height);
         r_refdef.fov_y = CalcFov (r_refdef.fov_x, r_refdef.vrect.height, r_refdef.vrect.width);
         break;

   case -1:r_refdef.fov_x = scene_fov_x.floater;      // -1 use cvars
         r_refdef.fov_y = scene_fov_y.floater;
         break;
   }

And view model adjustment.. yeah this is OpenGL and I haven't given any thought on how to adapt to software rendering ... that being said since the .mdl model loader uses the scale at first thought it shouldn't be hard. The following code makes the view model immune to FOV changes:

Code: Select all

   else if (isviewModel && r_viewmodel_fovscale.integer)
   {
      float   scale = (0.5f + CLAMP(0, viewmodelsize, 1) / 2.0f) / tanf(DEG2RAD(fov_x/2));

      eglTranslatef(pAliasHeader->scale_origin[0]*scale, pAliasHeader->scale_origin[1], pAliasHeader->scale_origin[2]);
      eglScalef(pAliasHeader->scale[0] * scale, pAliasHeader->scale[1], pAliasHeader->scale[2]);
   }

[qbism]

Yes, that's colored lighting. It's kind of sluggish because there's no ASM function written for its surfmipblock functions or its model drawing functions. What it does is process in 24-bit RGB and then throw it through a 18to8 lookup table (also an option for 15to8 for crappier precision lighting). For the colors on the dynamics I tried to follow the colors set by Darkplaces and DirectQ

Have you considered palletizing the incoming .lit file with the bestcolor function to create an 8-bit palettized colored lightmap? Code like pointlight that simply adds light sources together would need to do a lookup instead. But it might be faster than the separate RGB calcs.