#244 posted by JneeraZ on 2009/10/18 17:54:11
Especially considering that machines these days come with a few GB of RAM standard. Seriously, jack the default up to 128MB and be done with it. :)
#245 posted by necros on 2009/10/18 19:37:22
for me, i never even thought about it because i never actually run the executable itself.
i always have my fq.bat file which does things like -particles 10000 -heapsize 64000 -bpp32 etc etc.
if you wanted to make the stuff standard, that's cool, but it doesn't bother me either way. :)
 Yup
I was thinking about adding permanent parameters to the next version of fitz sdl on mac. There would be a preferences dialog where you can set some permanent parameters, and then add other parameters using the standard launcher dialog.
 Heapsize
#247 posted by mh on 2009/10/20 01:01:45
Well it's not DOS anymore, even a 32-bit OS will be able to address ~4GB of virtual memory, irrespective of how much actual physical memory you have. Using a heapsize of 128MB is enough to run warpc with quite a bit of headroom (you can squeeze it into 64MB if your engine is careful enough about what it allocs), so I'm wondering is there any requirement for this command-line option to even exist any more? My own engine got rid of it a good while back, but then I use my own custom allocators which are NOT a trivial thing to write.
#248 posted by JneeraZ on 2009/10/20 01:03:40
Who doesn't have 128MB oF RAM? Seriously, it's time to just set it to something huge and move on. :)
#249 posted by necros on 2009/10/20 04:20:34
is there a way to dynamically set it?
i mean, it would be pretty bad ass if the engine just reallocated everything if it ran out of room automatically... ^_^;
 Yeah...
#250 posted by metlslime on 2009/10/20 04:47:39
writing a whole new memory system would solve this :P
 EzQuake
#251 posted by Baker on 2009/10/20 04:57:28
Has some code IFDEF'd labelled "DarkPlaces memory manager" that dynamically allocates memory as needed.
 Memory
#252 posted by mh on 2009/10/20 18:21:32
Oh, dynamically allocating as needed is easy. Keeping track of what memory you have allocated, freeing it in the correct places, keeping contiguous blocks where needed, ensuring nothing gets stomped, and transitioning from Quake's cache/hunk/zone system - that's hard.
It's the kind of thing where - unless you *REALLY* need it, or unless it scratches some particular itch you have - you might be better off just upping the default Heapsize.
#253 posted by mh on 2009/10/20 22:25:05
I forgot "...and doing it all efficiently..." :)
 If It Works ...
#254 posted by Baker on 2009/10/20 22:53:59
The ezQuake #IFDEF DARKPLACES_MEMORY_MANAGER code -- if it works -- is rather simple.
Shockingly simple, actually.
 Alias Models + External Textures
#255 posted by Baker on 2009/11/05 07:13:11
Does FitzQuake support external textures for alias models?
/Btw ... FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1. I never had a doubt ;)
 Argh .. Nevermind
#256 posted by Baker on 2009/11/05 07:22:21
I thought this was added in 0.85
 Regarding -heapsize And Such
#257 posted by Jago on 2009/11/05 12:50:29
Is there any particular reason why things like -heapsize aren't automatic and dynamic?
#258 posted by Spirit on 2009/11/05 15:10:59
Yes, check 5 posts above yours.
 This Thread Beats The Record Folks
#259 posted by QMD on 2009/11/12 02:57:03
On september 16, year 2000, 'maiden' posted the #237 message on the infamous thread at Qmap, called:
- - - - - - - - - - - - - - - - - - - - - - -
QuakemapDesigner... Err Designs Quake Maps.
Posted by Shambler [194.112.32.102], 31/08/2000 09:13 GMT
" The modestly named QuakeMapDesigner has been shouting about the Quake maps he's, err, designed at his QuakeMapDesigner site. They look like deathmatch and/or CTF maps to be (though I can't be sure), and QMD is after some reviews, so be sure to pick up some maps and give him an honest appraisal of their quality.
P.S. He's French apparently - any relation to you, Bal?? =) "
- - - - - - - - - - - - - - - - - - - - - - -
So just for you to remember the " good old days " folks and congrats on this thread, because it has a higher number of posting message.
Cheers!
QMD
"Where imagination means, levels!"
P.S.: QMD stands for "QuakeMapdesigner" and not " Quick Masturbation Discharge ".
 Crikey!
#260 posted by RickyT33 on 2009/11/12 10:29:12
When that message was posted I was running around, truant from 6th form, popping magic pills and sleeping in every day.
#261 posted by mh on 2009/11/13 23:38:03
"FitzQuake is about the only non-DarkPlaces engine that renders a skybox when submerged in a liquid with r_wateralpha < 1."
No it isn't. ;)
 Weird...
#262 posted by metlslime on 2009/11/14 01:33:29
i'm not even sure why any engine would fail to draw the skybox when underwater, unless they specifically added code to do it. Otherwise you'd think that "if sky polygons are visible, draw skybox" is the most obvious logic. Or even the more dumb and simple "always draw the skybox" approach.
 User Error
#263 posted by Baker on 2009/11/14 03:19:31
I had underwater fog on and didn't make the connection between that and the traditional fog. Skyboxes are viewed as infinitely far away. JoeQuake, Qrack, FuhQuake, ezQuake just draw the underwater fog.
And I believe none of the above even draw the skybox with any fog setting.
Bad post on my part!
 True Tho
#264 posted by RickyT33 on 2009/11/14 03:56:29
#265 posted by mh on 2009/11/15 14:52:11
Yeah, fog needs tweaking for an infinitely distant skybox, and at the very least the fog end value needs tweaking also even without an infinitely distant one. Haven't looked at FQ's skybox code yet but I wouldn't be too surprised if it did something like double the fog end value when drawing the sky.
 Some FQ 0.85 Bugs
#266 posted by mh on 2009/11/15 21:02:52
In TexMgr_LoadImage8 you have "if (glt->flags & TEXPREF_ALPHA && !(glt->flags & TEXPREF_CONCHARS))" (also the same in a few other places) - "glt->flags & TEXPREF_ALPHA" needs parentheses.
 More Bugs
#267 posted by mh on 2009/11/15 21:20:18
The initial value of gl_max_anisotropy should be 1. This fixes the infinite loop in the cvar callback and is conformant with the spec (i.e. a value of 1 specifies normal isotropic filtering).
 Mh:
#268 posted by metlslime on 2009/11/15 21:50:15
fitzquake disabled gl_fog and just does a fixed-opacity blend over the sky, unless gl_skyfog is 1 (fully fogged) and then it just draws solid-colored, textureless sky polys.
As for the other bugs, thanks... i'll have to check those out.
|