Yeah +1 To Getting That To Happen!!
#293 posted by RickyT33 on 2010/11/02 10:28:19
I would throw in a hand-job to the man who can get it done!!!
Uh Ok
I'm out.
Assume The Position
#295 posted by mh on 2010/11/04 00:05:48
#296 posted by necros on 2010/11/04 00:11:41
make a news thread, yo!
#297 posted by necros on 2010/11/04 00:23:45
on second thought...
seems like the elapsed time output stuff is broken?
Light: 0.0%, Elapsed: 0:00
Light: 0.0%, Elapsed: 0:00
Light: 16.3%, Elapsed: 0:00
Light: 28.2%, Elapsed: 0:00, Left: 1:00, Total: 1:00, 24%
Light: 41.1%, Elapsed: 0:00, Left: 0:00, Total: 1:00, 39%
Light: 72.2%, Elapsed: 0:00, Left: 0:00, Total: 0:00, 81%
Light: 92.0%, Elapsed: 0:00, Left: 0:00, Total: 0:00, 92%
Light: 99.3%, Elapsed: 1:00, Left: 0:00, Total: 1:00, 98%
Light: 100.0%, Elapsed: 1:00, Left: 0:00, Total: 1:00, 100%
Light: 100.0%, Elapsed: 1:00, Left: 0:00, Total: 1:00, 100%
done in 60.771000 seconds
looks like it was rounding off the numbers.
also, how do you use _color with sunlight? tried sticking that in world, but no luck.
#298 posted by mh on 2010/11/04 00:26:07
_color with sunlight is an exercise for the future. ;)
The time counter is no longer reliable since I multithreaded it, but it still gives a reasonable approximation.
#299 posted by necros on 2010/11/04 00:35:37
about the time counter, that's not what i meant. if you look, you can see that the tool is only displayed minutes and floor'ing the seconds, even on the elapsed time.
Oh And
#300 posted by necros on 2010/11/04 00:53:26
please get rid of 'press any key...' pause at the end of light processing. it's downright annoying and serves no purpose. at the very least add a switch to disable it. even just hooking it into -nowarnings.
Hmmm
#301 posted by necros on 2010/11/04 01:24:39
on re-reading, my posts sound rather negative.
sorry about that, the multithreading is going to be a great time saver and i'm quite excited about that. :)
BTW
#302 posted by ijed on 2010/11/04 01:27:00
This is 'coloured lighting in AguirRe's light tool'.
#303 posted by gb on 2010/11/04 02:25:44
good job mh.
Oh And
#304 posted by gb on 2010/11/04 02:27:01
I think someone deserves the bounty now.
Yeah, And Also
#305 posted by RickyT33 on 2010/11/04 03:32:42
This tool applied coloured lighting to one of my current projects which has 104 lightmaps, and over 60'000 vertexes and marksurfaces. Its a benchmark in Quake1 lighting tools. Coloured lighting on massive maps with extra4 etc. It auto-detects if you are using RGB "1.0 1.0 1.0" or "255 255 255" colourscales, too, which is cool.
That's All Very Well But
#306 posted by rj on 2010/11/04 11:15:39
what does it all have to do with fitzquake sdl version beta? ;)
what does it all have to do with fitzquake sdl version beta? ;)
Hmmm... something or another ;>
I got another report of brightness failing too.. So the gamma feature is probably worthwhile. But in my experience, a gamma slider shouldn't be placed beside the brightness one. I'd like to have a GL Options menu (just above the Video Options menu), and put the Gamma slider in this sub menu. Any extra GL menu items can also be placed here.
Players Don't Give A Crap
if it's a GL option or not. To them, it's all video related, so that's where it should go. Maybe split the video menu into resolution / bpp options and other options like brightness / gamma / etc
#309 posted by metlslime on 2010/11/05 18:39:12
but the quake brightness slider IS gamma. It has always been directly linked to the gamma cvar, way back to dos quake, and the gamma cvar has always controlled basically the same gamma ramp function that we are doing with hardware gamma in fitzquake/etc.
"idgamma" is different, i only assume that it implements additional contrast/saturation controls since people who use it complain about how things look without it.
- Ah Ha Ha
Stevenaaus
#311 posted by than on 2010/11/06 11:36:23
nope, I've got a radeon HD4850 1gb ram and the latest ati drivers.
Hmmm
This seems to work for some people.
Download the source and patch
tar xzf SDL-1.2.14.tar.gz
cd SDL-1.2.14
patch -p1 <libsdl-new_gamma_ramp_support.patch
Remove your old libSDL somehow, or "configure --prefix=/usr" will overwrite libs in /usr/lib
configure && sudo make install
sudo ldconfig
quakespasm
SDL Keymap
#313 posted by Baker on 2010/12/07 14:21:39
Does FitzQuake SDL automatically properly keymap a keyboard ... like if someone is using a US-101 keyboard versus, say, a German keyboard user?
From the code, I am guessing it does but I don't have an easy way to verify this.
Nope
#314 posted by negke on 2010/12/07 14:27:19
EN/US layout
I Wanted To
do that, but it would have required replacing Quake's own keyboard codes with SDL codes throughout the entire codebase, and I didn't want to do that way back.
I do think it should be done though, and maybe I'll convince the QS guys to let me fix this in QS.
Thanks
#316 posted by Baker on 2010/12/07 15:04:14
I was trying to determine why the Key_Map function was converting the key code whenever the Key_Event function was called.
Ok ... I was reading too much into it.
#317 posted by Spirit on 2010/12/07 15:35:34
Apart from the umlauts QuakeForge does it, if you need a starting point.
|