R_speed Test
#1425 posted by LeopolD on 2014/12/21 09:20:25
Went from average 69.15 to 12.21 on a 6770 using OSS radeon drivers.
Pulling the console down almost doubled the value on the old build while the test build kept the rate.
Gamma And Runes Problems.
#1426 posted by Bloodbat on 2015/01/01 04:02:00
Hi! Thanks for all the hardwork in the port :) however, I seem to have come across two problems:
1.-Gamma isn't respected unless the engine is set for 16 bit color depth; if using 24 the gamma slider works and the gamma console command indeed changes the brightness, the gamma value is saved, but ignored when exiting and restarting the game (or rather reset when the vid_restart occurs in config.cfg), it's a bit annoying having to reset the gamma (by typing gamma 1 to "reenable it": the engine assumes the value it read is already there [despite being ignored] and does nothing, and then gamma 1.35, since the slider won't go above 1 and 1 is to bright, could these values by fixed, too?) every time I start the game.
2.-My runes disappeared! I finished episode 3 (after finishing 1 and 2 beforehand) and noticed the bars weren't there...true enough...no runes. Sure it can be fixed by impulse 11 (and I know it can happen in vanilla Quake), but it's annoying nonetheless.
The engine I'm using is the latest stable Windows 64 bit build, SDL 2 with a GeForce GTX 750 Ti using the latest drivers (347.09 at the time of writing). It may or may not interfere that I do have the drivers set to use NVidia color controls (since allowing "other programs to control color" makes the desktop [and mostly everything] look like ass). Other games have functional (or not ignored) gamma controls.
Thanks in advance :)
@Bloodbat - Runes Disappeared
#1427 posted by mh on 2015/01/01 16:57:29
Did you use the "kill" command at any stage? This is an old Quake bug where the "serverflags" field is wiped by using kill, and I guess that QS hasn't fixed it.
@mh - Disappearing Runes.
#1428 posted by Bloodbat on 2015/01/02 05:27:57
Nope, no kill command. The only command I've used is vid_restart and some screen related cvars (including, obviously, gamma) for dealing with and testing the other problem I mentioned.
Bsp2 Leafs
#1429 posted by negke on 2015/01/06 09:47:58
I'm getting an error trying to load a BSP2 map that exceeds 64k leafs. Shouldn't this limit have been raised (or abolished) for BSP2?
#1430 posted by Spike on 2015/01/06 11:10:18
@negke
The file format itself abolished the limit, yes, however, the PVS buffers within the engine tend to be a fixed size, and there needs to be one bit per leaf.
large leaf counts are just all kinds of bad.
By the time you reach 64k leafs, your uncompressed pvs data is half a gigabyte.
If your editor supports detail brushes, try using those.
#1431 posted by Kinn on 2015/02/03 13:22:30
Ok guys, what are the chances of putting this into Quakespasm:
QuakeForge uses shader magic to simulate the look of the software renderer...
http://www.quakeforge.net/screenshots.php
I don't see the difference between that and changing the texture mode using gl_texturemode
Fifth
#1433 posted by Kinn on 2015/02/03 13:37:20
the output pixel colour uses quake's colormap like in SW rendering (which is a lut basically that combines texture pixel colour with the lightmap)
It really makes a big difference imo
@Fifth
#1434 posted by mh on 2015/02/03 14:11:05
There's a subtle difference in that a GL engine, even with a gl_texturemode change, calculates lighting by doing a multiplication of texture colour by lightmap intensity.
The software Quake approach uses a lookup table but the result of the lookup is constrained to colours that are in the Quake palette, whereas the GL multiplication can produce results that are not in the Quake palette.
For a truly authentic look you'd also need to use the software Quake miplevels, since once again these are constrained to colours in the Quake palette but GL's miplevel reduction can likewise produce colours that are not in the palette.
Oh ok, so the lighting being restricted to the palette? Fair enough.
#1436 posted by Lunaran on 2015/02/03 17:05:01
I would really like to see before and after shots on that.
#1437 posted by Lunaran on 2015/02/03 17:05:33
(because I have no idea what kinn is looking at)
+1 Simulate Software Quake
#1438 posted by killpixel on 2015/02/03 17:50:07
i think that would be great, I really like the look of software quake... it just seems more surreal and gritty.
#1439 posted by Spirit on 2015/02/03 19:01:26
Random saw this https://gaming.stackexchange.com/questions/164991/quake-1-under-linux-using-quakespasm-0-85-9-couldnt-find-a-cdrip-for-track-an
The QuakeSpasm developer said that I'd need a full version of Quake for the music to work.
Bacause of the shareware is limited to only what is inside pak0.pak file - music resides outside it so the engine ignores it.
I am 99.9% sure that the Quake shareware came with the CD audio, can check if you want me to. You could unlock the full version with just the shareware disc so the CD audio had to be on the disc.
So there is no reason to block CD audio if someone does not have pak1.pak.
There is one important difference between software and GL: http://imgur.com/a/DhAgo
OTP
That's the first show that shows the difference pretty clearly. Winquake seems much sharper and harder due to the way the palette has to cope with gradients.
#1440
#1442 posted by Kinn on 2015/02/03 19:54:06
also....models have minlight in software?
@Kinn
#1443 posted by mh on 2015/02/03 20:30:30
IIRC models are minlighted to 5 in order to avoid a check for division-by-zero in an inner loop.
The MDL lighting is almost completely different in software in general; it just doesn't use the same calculations as GL did, although I don't recall specifics.
#1444 posted by ericw on 2015/02/03 20:41:40
Yeah, in software, mdl's have minlight. From this comment, it sounds like the reason for doing that was an optimization:
#define LIGHT_MIN 5 // lowest light value we'll allow, to avoid the
// need for inner-loop light clamping
I'm not sure if this is the only difference. The code for determining the light level of each mdl vertex in software quake is structured a bit differently than glquake. These are the relevant parts of sw:
https://github.com/id-Software/Quake/blob/master/WinQuake/r_main.c#L563
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c#L617
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c#L433
And glquake:
https://github.com/id-Software/Quake/blob/master/WinQuake/gl_rmain.c#L476
QF
QuakeForge uses shader magic to simulate the look of the software renderer...
Hmmm - we're not really about geewhizz effects.
I do love these effect sort of things ... but the code belongs in separate patches and/or forked projects.
I Don't See It
#1446 posted by necros on 2015/02/07 03:05:20
unless.. are you talking about the banding from lighting? why would you want that, it looks shit.
Ok
#1447 posted by Kinn on 2015/02/07 11:12:40
I can see where this conversation is going.
I'll just leave it at that, and say that yes, quite a few people do actually like quake's original 8-bit aesthetic, and have done for some time.
I like the 8bit feel. It's difficult strokes for different folks. :)
Dev Build
#1449 posted by ericw on 2015/02/07 20:38:59
if anyone wants to test a dev build, there's one here with some neat features:
http://quakespasm.ericwa.com/job/quakespasm-sdl2/146/artifact/quakespasm-r1164.zip
@Bloodbat: this has a new gamma implementation that should fix your gamma issues
@LeopolD: I didn't get around to adding vid_borderless, but did add something: set vid_desktopfullscreen to 1 to make fullscreen mode use sdl2's new "fullscreen deskop" mode.
Other stuff:
-it has the glsl-accelerated mdl renderer. Szo reported an issue where some models are rendering black on his AMD card, still working on finding that bug.
-"game" command tab-completion
-demo pause support
|