#1106 posted by metlslime on 2014/08/27 21:08:44
The standard quake colormap accomplishes 3 things:
1. force last 32 colors to be fullbright (but it could be different with a different colormap)
2. force the other colors to have 2x overbright lighting (but it could be different with a different colormap)
3. create a lookup table to find the correct palette index for the texture color + lighting value.
#1 and #2 are hard-coded into fitzquake based on the setup of the standard colormap. This means fitzquake assumes 2x overbrightening and the standard 32 fullbright colors.
#3 is irrelevant in a 32bpp renderer.
Of course there are all sorts of crazy effects you could do with a colormap, so no matter what assumptions the glquake-based engine makes, those assumptions could be wrong. For example, you could have colors that have an inverted lighting model (shadows would make them brighter) and you could have colors that change hue based on brightness (like orange highlights, blue shadows) And many other things. The only way to truly support those things is to write the equivalent of a pixel shader that uses the colormap as a lookup table.
@metlslime
#1107 posted by ptoing on 2014/08/27 21:13:45
Then that would be the way to go, imo, just speaking as an artist here.
And I for one do not like to play with 32bpp because it makes stuff look washed out and bland. Keeping the original stepping of the colours used in the colormap makes things more contrasty as well as grittier and more surreal. It just is part of the feeling of Quake for me. With a pixel shader you could also have the added benefit of 32bit smoothness while still keeping the stepping of the colormap. So it't a win win I would say.
But I guess there would have to be some command for it that would deactivate the colormap, just to make sure, or of people want to use truecolour textures or something like that.
New Builds (0.85.10-r980)
#1108 posted by szo on 2014/08/29 11:50:44
New prerelease builds uploaded at http://quakespasm.sf.net/devel/
win32:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r980_windows.zip
win64:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r980_win64.zip
macosx:
http://quakespasm.sf.net/devel/QuakeSpasm-0.85.10-macosx-r980.zip
Linux users can checkout the svn and build for themselves.
Changes since the previous r958 test builds from Aug. 08 include:
FSAA support, fence textures support, brush model drawing speedup,
better cross-map demo playback support, and increased limits for
MAX_ENT_LEAFS (32), MAX_EFRAGS (4096) and MAX_CHANNELS (1024).
For more detailed list of changes see the READE file (or browse the
svn history.)
Orl's test map is playable now :). Nice one.
Any likely/possible regressions with the new brush model code ?
FSAA ?
#1110 posted by Barnak on 2014/08/29 16:40:55
I tried the OS X version, and I don't see any FSAA option.
Where is it ?
Barnak
#1111 posted by szo on 2014/08/29 17:12:15
RTFM
Nice, Thanks
#1112 posted by negke on 2014/08/29 17:16:54
Though what bothers me a little is that the readmes are called README.* instead of quakespasm.* - with all the stuff in my Quake dir, I prefer it all easily recognizable (without having to rename the files with every new version I install). </Spirit>
Szo
#1113 posted by Barnak on 2014/08/29 17:32:12
WTF!?
You shouldn't have to read a manual for a graphical option . It needs to be shown with any other graphical option in the interface.
This is nonsense !
#1114 posted by Spirit on 2014/08/29 17:43:36
I support negke's cause at least for "extract and go" packages. All files should have unique names.</honk>
Lava And Teleport Alpha ?
#1115 posted by Barnak on 2014/08/29 17:47:52
Is there any lava and teleport field alpha parameters now ? I don't see anything related to these, in the readme.
#1116 posted by Spirit on 2014/08/29 17:48:54
If there were, they would be documented in the readme.
Fantastic Job
#1117 posted by Orl on 2014/08/29 18:25:19
My hats off to you Quakespasm team. My map now runs at a constant 60 frames per second or higher, never dropping below that. It even runs well on my laptop with much weaker hardware. Great job guys!
#1118 posted by ericw on 2014/08/29 21:00:42
Thanks for putting up the builds szo.
Orl, glad I could help. :-) Your map looks wicked!
There are still a couple more optimizations I want to look at some time, namely using vertex arrays for world/bmodels and alias models.
Barnak, I tried to put fsaa in the menu but it requires a cascade of deeper changes in the engine that need a lot of care to get right. You can just set vid_fsaa in the console and it'll get written to your config.cfg, and used on all subsequent launches.
Ericw
#1119 posted by Barnak on 2014/08/29 21:07:59
Thanks for the info.
Now, what's up with a separate alpha for water, lava and teleporters ?
Barnak
#1120 posted by mfx on 2014/08/29 21:18:30
Rome wasnt build in a day.
@szo, ericw, steven you rock! Thanks guys!
Sndspeed Issue In QS-0.85.10-r980 Win X64
#1121 posted by MaxED on 2014/08/29 21:34:19
- If you change 'sndspeed' in the console, the value is not saved in the config.cfg.
- If you manually add 'sndspeed' to the config.cfg (I was adding 'sndspeed "44100"'), the engine uses the new value, bit it disappears from the config.cfg after closing the engine.
#1122 posted by ericw on 2014/08/29 22:13:58
AFAIK sndspeed wasn't automatically saved in 0.85.9 either. config.cfg is just for things the engine saves itself, you should put that a custom sndspeed setting autoexec.cfg.
I know it's confusing. i don't know if it's documented anywhere other than the source code which cvars are saved in config.cfg or not!
Also just a note, the meaning of sndspeed was changed slightly in this release. QS now opens the OS audio device at 44100hz by default, and internally upsamples the sfx to 44100.
If you were setting sndspeed 44100 for better quality with replacement sounds, keep doing that and it will work as it was before.
If you were setting it to 44100 to hear the music at full quality, there's no need to do that any more, the music will be output at 44100Hz even if sndspeed is at the default of 11025.
#1123 posted by Joel B on 2014/08/29 22:22:28
Speaking of which: section 3.1 in the Readme needs to be modified a bit now, and 6.1 could be clearer about how music is affected (or isn't).
Good Catch, Will Update That
#1124 posted by ericw on 2014/08/29 22:40:51
#1125 posted by Baker on 2014/08/30 00:47:54
Nice!
(Especially the fence texture support)
Expect To Be Seeing That In A Map
#1126 posted by ijed on 2014/08/30 01:35:20
Sometime soon :)
Thanks Baker!
#1127 posted by ericw on 2014/08/30 01:46:56
I pretty much just nabbed it from Mark V :)
No Locs, Timer Is Tiny
#1128 posted by Omi on 2014/08/30 21:37:13
Hi guys for multiplayer play, I have some issues.
1) There is no .loc support, which makes the engine unusable for DM :(
2) The timer in the bottom right is very small, there's no way to scale it other than to also make the HUD big. Can we have some sort of command to scale the timer? Thanks!
C&P From Quakeone.com
#1129 posted by mfx on 2014/08/30 22:08:09
Baker says:
Unfortunately there are 2 standards for loc files:
1. The Quakeworld way (ezQuake, FTEQW, ZQuake, DarkPlaces)
2. The ProQuake way (ProQuake, Qrack, DarkPlaces)
There are about 160 loc files for Quakeworld, about 120 for the "ProQuake way".
The ProQuake way is harder to make, but far more accurate about your actual location (a series of 3d "boxes" defines where you are), the Quakeworld way is easier to make (a series of points, closest point matches).
Personally, I'd opt for the Quakeworld way as a priority because it is easier to get the Quakeworld community to play a custom map (the NQ community is more set on long-time favorite maps).
draw your own conclusions..
#1130 posted by metlslime on 2014/08/30 22:13:09
how about supporting both? or are the file formats hard to distinguish when parsing them?
|