#1397 posted by JneeraZ on 2014/11/06 00:55:50
Do whatever Preach says. :) Thanks!
Fullbrights
#1398 posted by Baker on 2014/11/06 05:55:47
A number of old releases were made for GLQuake and never tested in WinQuake or an engine that supports fullbrights. And as a result, you have fullbright patches in the map textures.
It is possible that in the future, some sort of informational only external .ent file could tell the engine not to use fullbrights on the map textures supplied in the .bsp.
Similar to the idea of producing external .ent files signaling the author's intended r_wateralpha value for the level.
I'm just filing this thought here.
.ent Files
#1399 posted by mh on 2014/11/07 11:31:30
I have problems with these on practical grounds.
A .lit file can be associated with the source .bsp by comparing the size of it with the size of the original lighting lump.
A .vis file can be associated with the source .bsp by comparing the number of leafs in it with the number of leafs in the original leafs lump.
There's no such comparison available for .ent files.
Sure, you can do string comparisons of certain fields in the worldspawn entity but it just doesn't seem as robust.
I'm aware that Quakespasm has it's own way of checking these, by means of only loading them from the same gamedir, but I can see a case where someone might want to keep these modifications in a second gamedir so they have the option of playing with either the original content or modified content.
I personally have the extended Dismal Oubliette (among other things) in a pak2.pak in ID1 so how can I be sure that a hypothetical .ent file for it - even if loaded from ID1 - refers to the original version or the extended version?
I don't pretend to have an answer to this, just highlighting potential issues as they occur to me so that we don't end up with another half-baked standard that isn't as robust as possible from the outset.
#1400 posted by Baker on 2014/11/07 22:31:09
How can you determine if an external .ent file is for the right .bsp?
Right now, you can't.
But I guess a .ent file could have some information about the expected .ent size or count it should be replacing, perhaps in the worldspawn section or some such thing.
#1401 posted by necros on 2014/11/08 01:37:34
what about an md5 hash of the bsp file?
#1402 posted by metlslime on 2014/11/08 01:44:38
how about... don't use the .ent file if it's lower on the search paths than the .bsp file of the same name?
i.e. id1/maps/e1m1.ent won't override mymod/maps/e1m1.bsp
likewise, a .ent in a pak file won't override a loose bsp in the same game dir.
#1403 posted by mh on 2014/11/08 03:24:58
how about... don't use the .ent file if it's lower on the search paths than the .bsp file of the same name?
I'm not saying this is something that does happen, but I'd prefer a solution that can handle a case where somebody manages to get e.g a hipnotic start.ent into their ID1 directory.
This is mostly coming from reading various QuakeOne threads and observing the difficulties that people have with even getting the most basic stuff set up right.
Mh:
#1404 posted by metlslime on 2014/11/08 03:38:58
i think my suggestion would handle that by rejecting the start.ent (start.bsp would be later in the search path in that case.)
Hmm...
Actually a pretty good check would be to compare number of submodels in the bsp... since they are referenced in the .ent file right?
That would only fail if the .ent file doesn't use the highest-numbered submodel, which is still a point of failure i suppose.
#1405 posted by Baker on 2014/11/08 04:05:37
@metslime ... I don't think it does even now with Quakespasm's ingenious content protection scheme.
#1406 posted by ericw on 2014/11/08 04:49:57
I think QS already does what metl suggested; here's a comment from gl_model.c:
// use ent file only from the same gamedir as the map
// itself or from a searchpath with higher priority.
#1407 posted by metlslime on 2014/11/08 09:04:16
yay, problem solved.
QS seems to run significantly slower after I die and reload the map. How come?
Very Weird
#1409 posted by ericw on 2014/11/14 19:46:28
Shouldn't happen, I'd like to be able to reproduce that. Can you give me a scenario where it happens, like any command-line flags (heapsize), mod/map. Assuming the win32 0.90 exe? You're just pressing space to restart when dead, not loading a save? Can you see an increase in the frame times reported by r_speeds?
Powerup Flash
#1410 posted by ranger on 2014/11/15 17:49:35
what console command disables the screenflashes when grabbing powerups?
#1411 posted by anonymous user on 2014/11/15 20:06:56
gl_polyblend 0
Wait What?
#1412 posted by necros on 2014/11/16 01:08:24
the powerup flash is built in and can't be disabled.
although, amusingly, if you type 'bf' into the console, it will play it.
My Bad
#1413 posted by necros on 2014/11/16 01:09:58
i forgot, but it's not actually 'built in', but is part of the progs.dat.
The code actually sends a 'bf' console command when you pick up items. In theory, you could make a mod to disable it.
Or In Theory
#1414 posted by Preach on 2014/11/16 01:50:58
You could also create a modified engine that makes "bf" a command that does nothing - or have a cvar that introduces that change. I read ranger's post as looking for such a cvar, dunno if it's an existing feature in quakespasm or elsewhere...
Minor Issue With Joined Console Commands
#1415 posted by Pekka on 2014/11/16 20:52:20
This one is a really minor issue. It's about as non-urgent as they come, since working around it merely requires typing in the console commands separately.
I noticed that you cannot autocomplete map names when joining multiple console commands using a semicolon. The following happens to me on QS 0.90 using the Quoth mod as an example. Any collection of Quake maps will do.
I start the engine and enter the command "game quoth". There are now maps titled breakable, e1m1quoth etc. available to launch from the console. If I type "map " (including the space), I can press tab to autocomplete them. This works as intended.
Let's say I want to play on Hard. I type "skill 2; map " and try to autocomplete the maps now. It doesn't work. It only offers to autocomplete commands instead of map names, which isn't right in this context. If I type in a proper map name, the commands still work, as you'd expect.
Presumably the autocomplete logic considers the whole console command line and not the part after the last semicolon. This would be a nice little thing to fix if you revamp the autocompletion feature some day.
Uneeded Levelshots
#1416 posted by ranger on 2014/11/23 01:09:10
SQ saves unneeded levelshots TGAs in the game's maps folder.
These image are never seen ingame and the files take up space, so QS should not generate these files anymore
QS Crash
#1417 posted by mfx on 2014/11/28 21:00:50
texture coords on a brush were:
16777740 1584.00 832
don�t ask...
FitzMKV crashed too.
What The Fuck Is That
Looking For Testers
#1419 posted by ericw on 2014/12/19 06:12:22
I was wondering if anyone with AMD/ATI cards could try this build for me (I've tested some intel and nvidia cards already, but if you have those you're welcome to try it too):
http://quakespasm.ericwa.com/job/quakespasm-alias6/lastSuccessfulBuild/artifact/quakespasm/quakespasm-rbe2d155ae59744afad9faf79e5d9b82e1f54430e.zip
It has the alias model speedup I've been working on (only requirement to get the speedup is opengl 2.0+), so a good map to test is jam3_tronyn from map jam 3, with its 120k epoly. A good commandline would be:
"-heapsize 256000 -game jam3 +map jam3_tronyn"
then check the first number of the r_speeds when looking at the demon face. If it's not too much trouble, checking the r_speeds with QS 0.90.0 for comparison would be great too. With any luck, the frame time should be half of what it was in 0.90.0. Thanks!
Continued..
#1420 posted by ericw on 2014/12/19 20:26:25
Ok Here
I guess you mean the start of jam3_tronyn. On my HD 6750 it improves from (some version of 0.90) ~ 13 ms to under 5 ms.
Havent played that map yet. Third of the way through now... Not bad :)
|