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]

[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]

[taniwha]

[leileilol]

That's

[Spirit]

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

[taniwha]

[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:

[taniwha]

[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 ( 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]

[qbism]