Issues:

1. gamma and contrast appear to do nothing (No big deal in my case, cos I have a desktop workaround).

2. Toggling external textures in windowed mode crashes cleanly to desktop.

3. When I go fullscreen, it always reports that it has set Quake to my desktop resolution (1680x1050), and refuses to stretch out lower resolutions to full screen. Not sure if by design, but frankly, it's so fast that I'm not sure it matters.

Requests:

1. support for 6+ mouse buttons (seems limited to 5 right now). Not sure how mwheelup and mwheeldown factor in, so I might need up to 10?

2. MP3 emulation of CD music (Is it missing in Linux, or do I just need a workaround?)

3. "Restore" printing of console messages to Linux terminal too (minor, but would be nice). 

This is something that crops up from time to time. "How come HL/HL2 can do XYZ but Quake can't?"

On the surface it seems reasonable. Both HL and HL2 are ultimately derived from Quake.

The difference isn't technology. The difference is content.

If you're starting from scratch with entirely new content you get to be able to say things like "brush models don't exist" or "I only have one directional light and that's the only light that casts shadows" and whole classes of problems just go away.

If you're retrofitting new technology on existing content you often don't have that luxury.

As always, a best effort will be made, but Thou Shalt Not Break Existing Content. 

vid_hardwaregamma 0 should give you control over gamma/contrast. Use the "txgamma" console command to change gamma. I haven't taken the time to fully integrate it into the menu.

mp3 music. At the moment, no Linux music option. I've had my eye on a few different methods including what VideoLAN does to unlock mp3 hardware accelerated decoding on Linux already built into your processor (Intel, AMD, ..). Haven't had time to conduct experiments and evaluate choices.

/So the quick ones are out of the way ;-) 

I'll play with the GL_SetCanvas and see what happens. 

From what I've read, only the video decoding part of video playback is hardware accelerated, since it takes very little CPU power to decode mp3, but I am curious anyway. Some link dumps:
https://trac.ffmpeg.org/wiki/HWAccelIntro
https://www.remlab.net/op/vlc-vdpau.shtml
https://en.wikipedia.org/wiki/Video_Acceleration_API

Wonder if gstreamer would be an option? It's a big bloated API, but I think it handles sending audio to the OS mixer itself.. so maybe you could get away with no changes to the Quake sfx mixer. Wouldn't be great for Mac though as it's more of a Linux library. 

txgamma works!

IDK if this helps at all, but Darkplaces for linux has working MP3/CD audio. 

I tried doing "dir" just to see it...

YIKES. I'd say it's a bad idea to do a complete listing of every file contained in every subfolder in the current directory... (I have a lot of content folders in my fvf directory...).

Make it like DOS does. Only show the names of folders, and not a full directory listing of each of those subfolders.

...unless I Ask for "dir maps" ...which doesn't actually work....




Also, just thought, can that fugly fog fix (and other stuff) be applied to the DX8 build? 

Some, but not all, could be applied to DX8. I'm not sure there's any really huge need to, however. 

The "fugly fog fix" isn't a one-line-of-code thing.

It means implementing GL_COMBINE modes, close on 100 lines and a complete re-architecting of how texture environment modes work.

Then you get to do the one-line-of-code thing.

Given that the DX9 build will run on downlevel hardware I don't think it's a productive use of time. 

Then perhaps have this work so that whatever is set last take precedent. So if anisotropy is already set and then nearest is chosen it undoes anisotropy. And vice versa, that way you get a visual feedback back that you can't have your cake and eat it 

At least from my point of view that seems like an improper request.

Let's focus on the future.

There is only so much time in the day, let's use it wisely. 

/I was referring to the idea of updating DX8. 

iirc nearest+anistrophy is undefined in opengl, so fte only enables anisotropy with mag=linear so you know what you're going to get.
should probably force mip filters too... :s 

GL_EXT_texture_filter_anisotropic

GL actually does define GL_NEAREST + anisotropy, but it modifies the behaviour of GL_NEAREST from being a "crunchy pixel" mode to being a "select the type of anisotropic filtering used" mode.

The extension notes that such hardware actually does exist. Maybe it did back then but I'm not certain that it does any more.

Cross-checking this extension with FitzQuake's checks for anisotropic filtering, I'm not sure what the intent behind the latter is, but the extension notes that 2 is minimum value so it would be sufficient for FitzQuake to just check for 2.

Setting to 1 disables anisotropic filtering. I'm not sure how well-known that is; disabling anisotropic filtering is a value of 1, not 0. Setting to 0 will actually throw a GL_INVALID_VALUE.

D3DTEXTUREFILTERTYPE enumeration

Direct3D 9 doesn't clearly define how anisotropic filtering works at all. You need a bunch of trial and error to figure it out yourself.

It does state that you cannot set an anisotripic mip filter, but you also cannot set an anisotropic mag filter - the D3D debug runtimes will throw "unsupported mag filter" errors. So anisotropic is for min filter only.

Setting max anisotropy to any > 1 value without also setting the min filter will not give you anisotropic filtering.

Setting mag filter to point/nearest and min filter to anisotropic will actually give you a blurry mag filter.

What a mess.

Decision time

I'm going to do the same as Spike and only enable anisotropy with mag filter = linear. It's clear from upthread that expected behaviour is "if I ask for crunchy pixels I want to get crunchy pixels".

I think setting them in the order that commands are issued is just going to create a mess that will eventually explode in your face. I do understand the visual feedback element, but that only applies if you're entering commands manually in the console. Whatever is chosen must also give expected behaviour with config files. 

 

I get this error: video: ChoosePixelFormat failed 

The OpenGL build should also fail because this is common to both.

I'll override ChoosePixelFormat for DX9. 

FitzQuake's GL_SetCanvas (CANVAS_MENU) was leaving the viewport smaller than the full render target when doing the gamma/contrast pass. That's what caused it to be off-by-1 and that's why I saw it shifting while toggling the menus.

I've a nice body of fixes built up again now so may do another code dump soon. 

Thanks for the shadow explanation, mh.

Gunter - I did stress that it seems to be in fullscreen borderless mode. It gives the impression of being so due to the appearance of a mouse cursor on the screen, that then goes away if I alt+enter. Once the game is definitely in fullscreen exclusive mode, alt+enter always triggers a switch to bordered window mode. Not sure if this was of any use to determine if what you describe in comment 991 is working correctly, mh.

Regarding the OpenGL performance issues I mentioned in comment 985 - it seems they actually started appearing from 125 on. I tried a few builds prior to that - 1001, 1016, 1017, 1019 (1019 being the last Windows OpenGL build I could see before 1025) - and they all performed well on ad_swampy. 1025 + 1028, the 2 Windows OpenGL builds I could see since 1019, both peform very poorly on the same map. 

So I'm testing LAN play at the moment!

It seems I have to connect using the connect command with IP addresses. I have tried using the 'local search' function but it doesn't seem to find the games being hosted.

I'm not an expert on LAN stuff so maybe I am missing something important? 

Also, I wanted mirrors. You can fake reflective water, a mirror teleport, you can do a lot of cool stuff... =~) So happy now. 

1) See post #8 in this thread http://celephais.net/board/view_thread.php?id=61375&start=8

Computer #1: In console: maxplayers 4; coop 1; map start
Computer #2: In console: connect lan // you're done!

2) @breezep - What are your computer specs? Like operating system, video card. I would guess that the DX8 build is a sure thing, but I would think all of them should work so this bugs me.

3) @rail - This bugs me just a little. I'll have to check and see what I changed since 1020 in the Open GL, but its not been anything deep. 

The 'dir' command seems to work fine, lists all the files inside the current game directory and its sub-folders.

The other commands you listed all seem to work fine too, though they only apply to the game directory itself, not its sub-folders (ie id1, but not id1/maps). So one can find *.pak but not *.bsp, for example. Not sure if this is as intended.

It's actually a potentially handy feature if you have a ton of maps inside a folder but can only remember a partial name for one. Quicker than scanning through the results of 'maps' command anyway. The ultimate would be a dir type command for Quaddicted files. =) 

Bloom

I just wanted to see what this would look like. Almost requires darkness and a base map with bright lights. Medieval wouldn't be a fit.

I was engine-mining and this wasn't what I was after, just incidental (what I was after is rather obscure and is likely on the verge of forgotten). It's been assimilated, although the code is not exactly efficient. 

involuntarily.....