 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
IIRC the only reason for -quoth is to allow it to support the Hipnotic HUD, together with Quoth content, together with an (optional) additional gamedir for a mod which requires Quoth.
-quoth is just a hack, in other words. But it's a hack that the community has come to accept and expect. This is clearly a "survival of the unfittest" situation. A simple-to-implement, adequately robust, but not necessarily full featured solution will always win over an elegant, extensible, more correct solution but that is significantly more difficult to implement. EF_STARDUST in the DarkPlaces source looks nearly identical to EF_FLAME, except that it uses pt_static instead of pt_flame.
Is EF_STARDUST needed for a model to emit, say, sparks? Is or EF_STARDUST redundant because the same effect can already be achieved through other means? Hence its non-inclusion in "Spikespasm". /I'm looking at smc and thinking about extracting an effect or of it for a tutorial later in the week or on the weekend. its either '-quoth' in an engine that hardcoded a specific mod, or '-hipnotic -game quoth' for vanilla, but yeah iiuc its just for the hud.
DP didn't add 'double-gamedirs', it has multiple gamedirs, because limits suck. As does FTE. of course, when you have more than one, order matters. I handled 'game foo -quoth' by parsing the list twice and then re-ordering. And if you want to mess everything up for everyone, all you have to do is to put a space in the subdirectory name! yay! EF_STARDUST is what exactly?.. Its a specific effect that you wouldn't have a clue what it really looks like until you've actually used it so that you can see. I don't see the point of it because its a specific effect. Its just not significant compared to the more generic stuff like r_effect or traileffectnum. Iiuc, it predates custom effects and stuff, dating back to the time of hardcoded effects. Same with all the extra TE_ effects. Yeah, it might be simple enough to rename it to 'ef_customeffect1' or something lame, but that's just lame. So yeah, you might want it for compatibility, but moving beyond that its probably not very useful, so I didn't see the point of implementing it. If I remember correctly, it's an effect used on slipgates that displays star-like sparkles floating upwards. I don't think it would do for, say, electric sparks coming from a broken panel.
That's what I thought! (It's obsolete, artifact from more primitive days). Thanks!
@mugwump - the particle system lets you set the origin and the velocity and other things. the originoffset could be instead of above it could be to the side and instead of sparkles, sparks. It's just an emitter. Simple effect videos
1) Sparkle: https://youtu.be/9TWUVe2_T3c 2) Smoke: https://youtu.be/K4iyK6yW8bw 3) Flame: https://youtu.be/ZH9zMBCyRFw 4) Myst: https://youtu.be/YXRx6sr-H4k 5) Rocket Trail: https://youtu.be/mOE71jc0RtI 6) Decal: https://youtu.be/3mRtTRSOKeE 7) Model Light: https://youtu.be/L8QX0TuTLTw To be followed up maybe this weekend by tutorials. Hey there,
I recently dug around a bit trying to find out how to get some popular source ports including Quakespasm to look as close to the original DOS Quake as possible. Changing texturemode, particles, lerpmove, lerpmodels, etc. one can get Quakespasm to look nearly identical, but the weapon offset is still problematic, it's just too low. Using scr_ofsx gets you somewhat closer, but it's not ideal. I've seen that Tarvis/bangstk made some effort here earlier this year to change that with an unofficial fork, but I guess that wouldn't work for the most recent release. Or can that somehow still be included without official support? Otherwise, is there any way to change the weapon offset to really get the original look, or isn't that possible right now? And if it isn't, can anybody give me some insight into why exactly that change is there in the first place? Thanks :) There's a comment in the source explaining this removal:
//johnfitz -- removed all gun position fudging code (was used to keep gun from getting covered by sbar) I believe that Baker's FitzQuake Mark V fork restores that code, but QuakeSpasm doesn't. Original gun is available as an option in mark v. Default is still the FitzQuake norm that Quakespasm uses but yeah you can go menu
I'd like a cvar for that.. we had a patch contributed that enables the classic gun position: https://github.com/bangstk/Quakespasm
It's on my todo list to review and compare to how MarkV implements it. Ironically, if I recall, Mark V doesn't have gun fudging code. Original Quake did fudge the gun position. Classic weapon in Mark V calculates the right gun position for the gun to appear on top of the status bar based on FOV and HUD settings and screen aspect ratio. This calculation also has to take into consideration FOVy adjustments for screen aspect ratios.
When you think about the gun fudging code in original Quake, it sounds newbiesauce easy. But just see what happens when you change the resolution to something with a weird aspect ratio or set an irregularly sized window resolution of 600 x 600 or 400 x 600. The original weapon position fudging code breaks down terribly in situations deviating far from a 4 x 3 aspect ratio or with enlarging the HUD (hudscale). (If I recall correctly, it's been a while since I worked on that.) Speaking about FOV, I think this option should have a threshold of sorts. Right now it always draws the gun the same, even with a very narrow FOV, which makes zooming very weird. Maybe it should take a value (in degrees) beyond which the gun stops changing.
Hehe, I noticed that once but thought that I was only the person that actually created such a bind.
You could actually modify your zoom bind. +zoom "fov 70; r_viewmodel_fov 70; wait; fov 50; r_viewmodel_fov 50" -zoom "fov 50; r_viewmodel_fov 50; wait; fov_70; r_viewmodel_fov 70; wait; fov 90; r_viewmodel_fov 90" will Spike's code be integrated into the next Quakespasm release or it is intended to be a stand-alone piece of software?
Thanks for the explanation about the weapon offset. I hope the patch or another kind of fix finds its way into a release eventually :)
Regarding Mark V, I noticed that it's better there, although unfortunately the beta release of the mark_v.exe crashes on my computer, unlike the latest stable release. However, I've used the WinQuake port of Mark V for playing through Quake the first time only recently and it worked flawlessly :) Now onto Arcane Dimension with Quakespasm. For the time being I'll stick to scr_ofsx -2.8. Mousewheel weapon switching is broken on macOS 10.12 due to a SDL2 bug: https://bugzilla.libsdl.org/show_bug.cgi?id=3432
The SDL1.2 version seems to be unaffected. Icaro: I'm not sure.. For the time being, it's a fork / branch. If I were to modify gl_model.c to allow for more animated textures (beyond 10 per surface) would I also need to modify the compilers to save the extra textures (beyond +9) to the bsp file?
You can add the textures the manual way by including a brush in the void with the desired textures. That's how we used to do it in the old days before compiler did it for you.
Is this a change that the guys would be willing to see incorporated into the engine? I don't want to fragment the engine ecosystem for such a small change.
Especially with spikes modifications being released too. My music has spontaneously stopped working in quakespasm. I have the tracks as
Findfile: can't find music/trackXX.mp3 Findfile: can't find music/trackXX.flac Findfile: can't find music/trackXX.wav Any ideas what might have caused this? animated textures
It is 20 per surface already according to this http://www.celephais.net/stuff/texturefaq.htm Which was written by metlslime, hehe. 0-9 for regular animations. a-j for alternative animations. the limit is due to the base animations using digits, although the alternative anims could be bumped to 26 chars.
more than 10 (or 26 for alt) requires getting people to agree with a single consistent naming system within the 16-char name limit, and that all gets far too political... What I was thinking was expanding the frames by a factor of 10 for the numbers and leaving the alternate animations alone. +00 to +99 is what I was thinking.
If nobody cares for it that's cool too, I won't make this change unless the QS authors are cool with it. Like I said engine ecosystem and all. slimealpha worldspawn key does not work in Quakespasm
The value seems to never be honored. Unless I'm doing something Put in worldspawn: "slimealpha" "1" // Nope, uses r_wateralpha All the other ones work like "telealpha" and "lavaalpha". It's working for me.. tried "slimealpha" "1", as well as "slimealpha" "0.1" in worldspawm.
Does the r_slimealpha cvar work for you? The interaction between the cvar and the worldspawn key is a bit confusing.. when the map loads, if the worldspawn key is set, that gets used until the next time you change the cvar. So the cvars behave like the fog command. Also if the cvar or worldpsawn key is 0 (the default), that is interpreted as "use r_wateralpha" Here is an example of misbehaving, although apparently in different way.
1. Empty Quake folder, just pak0.pak + pak1.pak 2. This start.ent in quake/id1/maps Mainly featuring "lavaalpha" "0.5" "telealpha" "0.5" "slimealpha" "1" "wateralpha" "0.7" 3. Result: No water transparency but the other 3 settings are used. I *think* that might just be un-water-vised transparent water? QS defaults to gl_clear 1 so you get grey tinted instead of a HOM.
I type r_novis 1 in console. Now water is transparent like it should be.
And although I specified slimealpha 1 in the worldspawn, it is not being used. Slime is transparent but I said 1! (which is not transparent) Slime is under medium bridge. I typed "fov 10" to magnify. Test was that start.ent, no config (I deleted every time to make sure it couldn't be config) and just the pak0/pak1. under the "normal" bridge? It's not burning if I noclip into it..
This one isn't imaginary. :)
I wanted to check out Spike's skyrain in Quakespasm Spiked on E1M1. To make sure it was using the external ent file I changed the name in worldspawn. Never worked. Tried other engines with external ent support = worked. The Z fighting fix in quakespasm.pak apparently takes priority over an entity file for those maps like id1\maps\e1m1.ent Just wanted to point this out. @Shamblernaut sorry for not responding earlier. I hate always to be grumpy; but I'm not keen on extending the number of animation frames just for engine fragmentation reasons.
Baker - thanks! Not sure what to do at the moment but that is an unfortunate behaviour. Priority (for id1 folder):
1) Pak files (pak0.pak, pak1.pak, 2) Free standing files 3) quakespasm.pak /Mark V just patches the entity string if it passes a "is it right map?" check, but I understand why you guys chose a pak file. Priority (for id1 folder):
1) Pak files (pak0.pak, pak1.pak, 2) Free standing files 3) quakespasm.pak For standalone ent files on the OS filesystem to take priority, that order you mentioned needs changing to 3, 1, 2 (using your numbers.) That may (or may not) have unwanted side effects, and/or break things, which I don't know at the moment. changing to 3, 1, 2 (using your numbers.)
Well, that should be 3,2,1 to be correct. But I _think_ that would mess things. continuing from the jam thread..
what's the history behind qs The QS changelog is the best summary of what was changed versus Fitzquake. Likewise, the Fitzquake changelog summarizes what metl changed versus GLQuake Also worth mentioning, QS started as a continuation of SleepwalkR's port of fitzquake to SDL (for mac/linux support): http://www.kristianduske.com/fitzquake/ It also shares some code and maintainers with uhexen2 Thanks for the links, good stuff. Not quite what I meant with my question, though; I'm more in learning about the circumstances behind QS's adoption by the community as a "Standard" engine. Was it just momentum carried forwards from the popularity of fitzquake, or something like that? Mostly just asking because I wasn't around in the community at the time, so it's all a bit of a mystery to me as to how we got to where we are today.
is there plans to add some of the graphical features shown elsewhere on the forum, about flames rendering and other special effects ?
And what about the OS X version ? Pritchard, I'm kind of curious to hear how other folks answer your question, but from my POV... yeah, Fitzquake had established itself as the "better version of GLQuake" that was the standard for making/testing/playing custom Quake maps. Fitzquake stopped development after a while and then Quakespasm sort of carried that torch forward.
QuakeSpasm took over because it was more actively developed and cross platform, I would say.
A fork of QS made by Spike that supports fancy stuff like particles and weather effects. There's a tutorial thread here: http://www.celephais.net/board/view_thread.php?id=61351
Additionally, here: http://www.celephais.net/board/view_thread.php?id=61359 is an example of effects for E1M1. You'll find the download link for the latest revision either on top of this page or in post #25 of the previous link. I have no idea if there is a Mac version, though. I'm sure some people here would know. QS-Spiked is a version of quakespasm that'll get you drunk faster than you expected...
it still looks+feels the same, unless someone actually uses one of the new features (which is imho why quakespasm is the more accepted / neutral engine). and annoyingly people focus on only the particles rather than the other things intended to stop it from being crippleware. grr. there's no prebuilt mac build, no linux build, no win64-specific build. the only prebuilt build is for win32, on account of it being intended as an updated patch rather than an engine in its own right, and me being too lazy to make 4 different builds with all their dependancies and crap. its still based on sdl, so you should be able to compile your own version if you're determined (but you might need to grab any missing files from vanilla quakespasm). *shrug* Aren't you also the man behind FTE? Considering that, I find your comment very surprising. At any rate, the people who come to QSS for the pretty-shiny can discover its other features afterwards.
Spike is all about the QuakeC. What would really need to happen is some single player modder using the QuakeC extensions available in the modified engine.
Like use the magic ear extension in QuakeC to create a shrine area with different statues and you have to say a magic word like "Klaatu Barada Nicto" to open the entrance to the tomb. Like those games where the vault combination "4398" or the computer password is scrawled on a wall, possibly an alert player could use it to get a secret item. Or have computer be able to do different commands like "airlock" to open a door on a base map. See? I've just discovered something! I admit that my interest in QSS resides primarily into said pretty-shiny, because I'm a DP fan and "normal" QS looks a bit too vanilla and I want to play maps/mods that have issues with DP but still get the bling, but what I've just read is AWESOME SAUCE!
The actual extension is KRIMZON_SV_PARSECLIENTCOMMAND and QSS totally has it.
Which let's QuakeC intepret chat knowing what player entity said it and where they are. Krimzon was a community member from ancient times. 2001/2002 or so; don't ask me to be any more specific.
Considering that, I find your comment very surprising. If you use Linux you should be able to compile yourself. If you're not able to compile yourself maybe you shouldn't use Linux. Barnak has a Mac which can only run 10.6 (32 bit or something). Spike doesn't have a Mac, gotta have a Mac to compile Mac version because Apple wants it that way and sells hardware. SleepWalkerR has a method to compile for old Mac OS versions, it's obscure as hell and requires frameworks no longer available from Apple. Ericw has those frameworks/files.
Ericw = only guy on planet who can make binaries for Barnak's Mac. Krimzon was a community member from ancient times.
Oh, OK. Just asking because Crimson is one of my fav bands. If you're not able to compile yourself maybe you shouldn't use Linux. I don't. I tried a S.u.S.E. distro a long time ago but Linux is not user-friendly enough for me. I wasn't talking about the build part but about your jaded/angry tone. @Mugwump,
I personally tend to play quake with vanillay setting. Pretty stuff like rtlights is not what I personally favour, which is why I've not gone completely crazy with that stuff. For instance, FTE has a number of presets, and only ONE of them has fullblown rtlights enabled. Pretty stuff sells (yay screenshots), hence your interest in DP, which is why FTE has the effects that it does, but its not my personal focus. I'm more about letting people do what they want without extra barriers (bug-willing), hence csqc etc. Note that QSS has a whole load of ssqc extensions, such that mods like SMC can run. I'm not saying that its worth playing SMC with QSS, only that its content-loading limitations that really holds it back (well, okay, a couple of extra things that I didn't bother to network up because I couldn't be bothered to implement the various clientside parts). The point is that QSS should no longer feel like crippleware to an aspiring ssqc modder. And hopefully FTE+DP users won't be left with horrible clunky mods that comprise of 60% hacks that were needed to work around QS limitations. The particle system is useful to mods+maps, in much the same way as fence textures or strcat (though you're likely to need to use the more limited DP-defined effect definitions if you want compat across all 3 engines). My personal justification for including the particle system was because Sock used custom particles in AD, demonstrating a need, but that his particles made the game totally unplayable in coop - using the engine's particle system, this problem goes away. Anyway, that's my reasoning. @ericw, I *really* need to get off my arse and do that bugfixes-and-polish-only r5 build, then start harassing you or the other guys to get it merged into vanilla QS... but meh, lazy. @baker, numberic combinations like 4398 could easily be done with impulses, but yes that would generally imply breaking weapon switching in certain areas. I'd like if someone made a proper map-scripting language some time, but I'm too lazy myself. -/*QUAKED trigger_magicear (0 0 1) (-8 -8 -8) (8 8 8) IGNORE_SAY IGNORE_TEAMSAY IGNORE_TELL IGNORE_INVALIDTELL REPLACE_WHOLE_MESSAGE REPLACE_OUTSIDE CONTINUE NODECOLORIZE
-Triggers targets when a given magic word has been said --------- KEYS -------- -message: message to wait for (can start or end with * for wildcards) -netname: replacement text (by default, no replacement is performed if empty) -radius: radius in which the player has to be for this to match -target: all entities with a matching targetname will be triggered. -target2: all entities with a matching targetname will be triggered. -target3: all entities with a matching targetname will be triggered. -target4: all entities with a matching targetname will be triggered. /Xonotic QuakeC source code My OS X 10.6 is full 64 bit.
If Quakespasm runs well on it, then it should run well on all newer OS X's. such that mods like SMC can run
Ooh, I wonder if Seven knows about this... The more I read about QSS, the more it looks interesting to me beyond the scope of playing maps/mods that DP breaks. I'm an aspiring mapper and one of my main concerns is compatibility with at least the most popular engines. Something that seemed hard to pull of with regular QS vs. DP/FTE, according to a discussion I had a few days ago on the map jam 8 thread. Lately I had noticed a trend among mappers to only care about QS anymore because having to juggle the different behaviors of engines became a PITA, while a few years ago they often tested their maps in 3 or 4 engines. I was even considering making 2 versions of my maps, one for engines that support graphical enhancements and another for the QS/Fitz family. Hopefully QSS will level the gap between those engines, be adopted en masse by QS users and I won't have to resort to that if I want QS purists to play my maps. This is going to sound really crazy, while testing my start map for the last jam I realised that blooms or similar would work really well for the streetlights.
Normally I think such features in a game like quake would be OTT (and I do think a lot of the features in DP are OTT). But standing under a streetlight looking up at it, you shouldn't be able to see the texture of the light itself, just brightness. Anyway, I know this was only sort of tangentially related to the discussion at hand, but I thought it was interesting none the less. Spike lacks enthusiasm because he isn't being stimulated by an exciting challenge like writing a Vulkan renderer. Spike is in it for the puzzle solving.
So Challenge: Take DPMaster source code 1) Implement connect mechanism that the client sends to DP master to tell it that it wants to connect to a server. Client to DP Master: "I want to connect to 33.44.55.66, I will be using the current IP:port" DP Master to Quake Server: "9.8.7.6 wants to connect to you with (client ip:port)" DP Master initiates some STUN/ICE/TURN server action with the client/server to punch a hole. *BAM* You don't even need to mess with port forwarding on your router any more. Complete server freedoms for all! Casual player just starts server and it work for all. /I wonder if Spike has thought of this before. I would guess that he HAS. I already implemented ICE with fte's xmpp plugin (including STUN, but not TURN because I'm too much of a cheapskate and I'm too lazy to deal with public TURN servers). You can use it for either voip calls (compatible with eg linux versions of pidgin) or for playing quake.
The only real limitations are that it doesn't really show any serverinfo nor ping, just the server's 'nick', and that servers/clients don't auto-join any chatrooms (iirc chatrooms are still kinda awkward to get going, at least compared to one-on-one chats - xmpp isn't like IRC in that regard). Starting such a connection basically requires that both the client and server use some sort of identifier such that they can resume the connection if their IP changes (notifying the peer of new candidates). Getting that secure enough to block hijack attacks would require tls or something... in which case dpmaster kinda becomes obsolete. Either way, there's no way that bloat would get merged into QS, so you'll just need to stick with the existing fte plugin if you want that sort of thing. Its not going to happen so any more discussion on that subject is kinda offtopic. ... gotta have a Mac to compile Mac version
None true. I suggest that you look at the cross-compile scripts in the qs source tree. @szo -- re: build script contents --- that's very interesting.
Read them along with the associated makefile. Setting up the cross-toolchain requires some getting used to, but once that is done, it becomes heaven on earth. Baker, you don't need anything special to build a 10.6+ 32/64 bit Intel
cd MacOSX xcodebuild -project QuakeSpasm.xcodeproj The only Mac configuration of quakespasm that isn't so easy to build is the 10.4 PowerPC one. We have a separate Xcode project in svn that builds on xcode 2.5 on OS X 10.4 so you can actually run and debug on a powerpc mac if you have one. I recently updated my Nvidia graphics drivers to 375.70, Windows 7 64-bit. As a result, Quakespasm 0.92 shows some terrible texture problem that must be seen. https://www.youtube.com/watch?v=ulOeZEYqOk0
As you can see, its like some weird texture overlap on one another, and even weirder is it mostly affects floors, it rarely affects walls or ceilings and models are untouched by it. The problem is present in all texture modes, the one I use is gl_nearest_mipmap_linear. Obviously the easiest solution is to revert back to older drivers, but is this affecting anyone else? anistrophy without linear filtering is basically implementation-defined. The driver is free to ignore your attempt to use nearest filtering, or even to only partially obey it, resulting in bluring between mip levels.
you can tell that its anisotropic filtering at fault, because it only really happens on surfaces that are at an angle to the view, as opposed to any surface merely between mip levels. side note: for the highest texture filtering quality with the lego look, you probably want the minification filter set to linear, the mipmap filter linear, and the magnification filter set to nearest. unfortunatetly most engines do not allow using independant settings for the min+mag filters. this results in aliasing that is visible on maps the width of eg dm4 Hm. I've never seen those black lines through lava at 0:36.
try disabling anisotropy with: gl_texture_aniostropy 0 unfortunatetly most engines do not allow using independant settings for the min+mag filters.
It's worth noting that this setting is legal in both GL and D3D. However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min. It's probably worth bouncing around suggestions for how to cleanly handle this without breaking compatibility. Add new filters to the end of the list? Add a separate command to specify mag (and a "revert to default" option)? Accept breaking compatibility and chuck out gl_texturemode, adding new commands for gl_min|mip|magfilter? Some combination of these? Something else? However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min.
It occurs to me that this may have been a constraint of 3DFX and other contemporary video cards but which is no longer relevant. the gl_texturemode list currently has 6 enumerated items, i don't think it breaks compatibility to add more at the end.
I think it merely doubles the length of the list to support mismatch of min and mag filter, which isn't that bad. Well I would love to tell you if this worked, but Quakespasm simply refuses to turn it off. Whether it be through the command line, or the autoexec.cfg, Quakespasm decides gl_texture_anisotropy must always stay at 1.
https://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt
When the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is equal to 1.0, the GL uses an isotropic texture filtering approach as described in this section and Section 3.8.6. However, when the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is greater than 1.0, the GL implementation should use a texture filtering scheme that accounts for a degree of anisotropy up to the smaller of the texture's value of TEXTURE_MAX_ANISOTROPY_EXT or the implementation-defined value of MAX_TEXTURE_MAX_ANISOTROPY_EXT. A value of 1 is off; unfortunately the stock code contains assumptions that are inconsistent with the spec. I tried updating my nvidia driver to 375.70 and I don't see anything wrong (tried all the texture modes, gl_texture_anisotropy 1 and 16.) I am on Win 10 64-bit and a GT 650m, so I imagine it's a case of a different hardware generation behaving differently.
Would you mind uploading a full resolution PNG screenshot? The youtube compression makes it a bit difficult to see. https://i.sli.mg/tV6enY.png
I am using an Nvidia GTX 970. I would hate to think its the cause of the newer hardware generation, but hopefully its not a complicated issue. I'm still on 372.54, so I can't say if I'm having the same issues or not. I can say however that the 9XX series of cards are a real pain for compatability compared to older generations... The example that sticks out to me was NFS Shift 2, which would frequently display black frames that made the game basically unplayable.
You could try rolling back and seeing if that helps, unless you desperately need whatever new game support the latest drivers have... Even forcing Quakespasm to use no anisotropic filtering through the Nvidia control panel, the issue still persists.
I feel like I really screwed the pooch by updating, but it I haven't in so long and felt it was time to do so. You could try the second to most recent drivers and see if the issue is there. Basically once you find where the issue first appears, you need to investigate the patch notes and see if any setting had been added or defaults modified from a previous version.
I don't know, that's the best I can think of when tackling from Nvidia's perspective. I use a 980ti and I believe I have either the latest or second latest driver and do not encounter this issue using the latest non-spiked QS. But why does QS have different strafe jump acceleration to darkplaces, and others?
I'm gonna go out on a limb and suggest that it's darkplaces that has the different-from-quake movement code, and not QS.
I remember hearing that in vanilla quake, "always run" had different (slower) movement than holding Shift, and that QS changed it so "always run" is the same as holding Shift.
I think this is the patch that changed that (while adding QS's feature that pressing Shift while "Always run" is enabled slows you down to walking speed): https://sourceforge.net/p/quakespasm/code/797/ edit: load the entire Fitz Mark V thread and search in the page for "always run" - Gunter talks about it.
I'm not 100% sure about any of the above, but it sounds plausible after a quick glance at the code. That was exactly what I was looking for. I plan to expand my quakespasm-irc port to include speed running features, and "fixing" the strafe jump to the accepted standard (by the speed running community) needs to happen for runs made with the engine to be legitimate.
I'm not sure if QS inherited the code from fitzquake. Gunter explains it in post 1149 in that thread.
What I might do is enable caps lock to be used for +speed. That way you don't need to physically hold down the key in order to always run and get the bonus strafe speed. The stock Quake engine only supports -hipnotic and -rogue, and these commands have other effects besides just loading a new game dir - they also change the Status Bar layout, for example.
Quoth requires the Hipnotic status bar layout so many engines add -quoth as another option to allow players to more easily specify this. Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it. The big take-home from this is that a game dir that functions in a manner such as Quoth, Hipnotic or Rogue must be explicitly hard-coded in the engine. You cannot specify "-hd" and expect the "hd" game dir to load, because it's not been hard-coded in the engine. Multiple game dir support - such as "game hd ad" - is trivial to add to the console but slightly more difficult to add to the command-line. Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it.
You don't need hipnotic to be installed to change the HUD with -hipnotic. You don't even need the directory to exist. The second point still stands though. would it be possible to hard-code "-HD" just for textures?
hard-coded in order to allow command lines like: -hd (for ID1 and/or generic maps) -hd -hipnotic -hd -rougue -hd -quoth (-game 5rivers) -hd -game ad The (sloppy) DarkPlaces multi-game dir system that has 3 major flaws also depends on the same system that allows DarkPlaces to crash if you have a start.lit file for a different start.bsp
Quakespasm, on the other hand, has the "Quakespasm content protection" system to prevent that. Implementing a "hires" folder capability as a separate cvar like "cl_replacementfolder" (name?) would be the right way to do it, but might not be trivial to implement due to the above. It would need to be placed at the end of list. The (sloppy) DarkPlaces way is not the right way. If it were, a lot of engines would do it that way --- case in point Quakeworld loves replacement textures --- but ezQuake would never do such a thing because the (sloppy) DarkPlaces way breaks the QuakeC precache system and cannot tell replacement content from the original content. (Also would happen to mess with physics in a FitzQuake engine in some circumstances due to FitzQuake using the model bounding box instead of -16, -16, -16 to 16, 16, 16 The right solution for people like Icaro is a separate cvar for the use of such a folder, and then maybe adjustments as uncommon problems crop up. If it were coded as a separate cvar or a command like option like -hd as Icaro suggests, it would be easier to tune and get users to have the right habits.
I've seen notes in Quakespasm Spiked where Spike was at least thinking about the vastly enhanced networking code provide for automatic download for coop (and even the start of commented out prediction code). Implementing something that separately specified a replacement content folder for the client would be compatible with not breaking such ideas. (But the DarkPlaces (sloppy) multi-game way would totally break it. fte has a 'gl_load24bit' cvar that can be set to 0 to disable replacement textures.
it has a similar cvar for alternative model extensions to try to load (screw s_light.<mdl|spr>). this means that mods can provide one set of content for chunk pixel style stuff, and another set for people that weirdly crave shinies and a lack of clear boundaries... imho, that's much cleaner than lots of different extra directories all over the place. the easy way to fix the +/-16 issue is to just have setmodel use +/-16 for ANY model with regarding downloads, both gamedir switching and downloading paks/pk3s have issues if not handled properly / explicitly. Which files to use/download/cache/reuse/delete is an entire subject in its own right. Avoiding the transmission of personal or copyrighted data makes things fun, and *which* network protocol to use just makes things that much more political. So yeah, QSS doesn't do downloads, which saves me a massive headache. Besides, download code is annoying to test. I have a working solution to this problem in a version of Mark V that will be released in the next 30 minutes.
There is a command called "hdfolder" where you can specify the content replacement directory and change it, it saves to config. So you can have different sets. A fair number of things that have been proven to be good ideas have gone from Mark V to Quakespasm or Quakespasm to Mark V. /I'll save explaining to Spike why this is a needed feature or how it avoids every downside of DarkPlaces multi-gamedir for some other time. Looks Like One Of My Fans Disappeared In The Final Build
Weird. what QS version / OS / 32/64-bit, etc? First of all, thank you for great port!
I'm wondering, is it possible to disable mouse acceleration on Windows 10? It looks like sensitivity in game depends on pointer speed in Windows. SDL1.2 supports older OSes (back to windows 95? and the mac version, back to 10.4/powerpc), but it's no longer under development.
SDL2 has more features (raw mouse input, borderless fullscreen, better international keyboard support, etc.) but has had more bugs. At this point I recommend using the SDL2 binary unless you need the old OS support. I recently recorded some Youtube videos for Retro Jam 5, and in the process discovered a glitch with regard to model loading. I'd initially passed it off as an Nvidia driver problem, but I'm not sure. EricW commented on one of my videos to see if I could reproduce it, and he'll be happy to know I've managed to do so:
1.) Running Quakespasm 0.92.1 (I was running 0.92.0 for the videos, but 0.92.1 works the same way) and Nvidia driver 375.95, run quakespasm -game retrojam5, make sure the game is running at 1920x1080. 2.) In the console, load my RJ5 entry with 'map retrojam5_tens'. 3.) Hit Escape, and in Options|Video Options, change the resolution to 1280x720 and Apply Changes. 4.) Load the first map in the pack, 'map retrojam5_breezeep'. You should see two light fixtures at the far end of the room with flames in them, clearly visible, no problems yet. 5.) Drop the console and go back to my map with 'map retrojam5_tens'. 6.) Again in Video Options, switch back to 1920x1080 and Apply Changes. 7.) Load Breezeep's entry with 'map retrojam5_breezeep' and the flames should be invisible. If you follow the same procedure, but replace retrojam5_breezeep with retrojam5_newhouse, you'll find not only missing flames but invisible enforcers, which makes for a bit of interesting gameplay. Not sure why it only affects some models, or how I might reproduce the glitchy blue polygons you can see in parts of my video for NewHouse's map, I'm sorry. It's a bit of a convoluted procedure, but in prepping for the video recording I was toying with my settings, going back and forth between maps and changing resolution, so it's no wonder I stumbled over whatever's happening here. Just to keep these two reports clearly separated, I'm using a new post for this one.
Also with regard to Retro Jam 5, and also in Quakespasm 0.92.0/0.92.1, my map has a hovering quad damage, using the trick of having a func_wall underneath it and firing killtarget at the map start, from a trigger placed over the playerstarts. In one person's demos/video, namely khreathor's, the quad is instead sitting in the water underneath it. Some discussion with him revealed that when loading the map with 'map retrojam5_tens', the quad is suspended midair as expected, but subsequently using 'restart' means it falls down into the water. While the map doesn't fall completely apart if one grabs the quad out of order, it is a bit less fun, and though adding a short delay to the trigger that kills the func_walls might have avoided the issue, it raises the question of whether this behavior is by design or is some sort of bug. Should this be happening? Is this bug specific to Quakespasm? There have been other instances in Quake where the restart command doesn't behave like loading the map normally, e.g. https://tomeofpreach.wordpress.com/2016/06/19/missing-items-and-the-restart-command/
Oh, it might just be my ignorance, then, sorry. I'm not intimately familiar with the subtleties of Quake and its various sourceports, so if this is standard operating procedure that mappers are just expected to accommodate, never mind the second bug report, I'll just get used to it.
ahh good to know. I'll use "map" instead of "restart" from now. I wonder if putting Quad higher above the func_wall will fix this behavior?
QuakeSpasm 0.92.1 - I can't load E1M7, I get
"host error: mod_loadclipnodes: planenum out of bounds" Weird, I've never seen that error before.
Check the md5 hash of pak0.pak, it should be one of: 85fc9cee2035b66290da1e33be2ac86b 5906e5998fc3d896ddaf5e6a62e03abb - https://quakewiki.org/wiki/pak0.pak Today I played the MP2 (Rogue), and I ran into a problem.
We all know that elevator in R1M7 is broken, and while Seven made a fix, it was done via progs.dat file. Few years ago, I asked someone to interpolate the Rogue buzzsaws movement, so Necros made a quick fix. The problem - it was also done via progs.dat file, but the game can use only one progs.dat file at a time. I don't have any experience in QC, but is there any way to "combine" the two fixes? I have source files from both fixes - BUZZSAW.QC from Necros, and a folder with many QC files from Seven's fix. I hope someone can do this, here are the files: https://www.sendspace.com/file/zdcg8w Instead of asking people "please do this for me", which will most likely be met with a resounding "no", ask "how can I do this?"
I've found an apparently very clear tutorial that will guide you through the process of making your own progs.dat. It seems quite simple. Looky here: http://www.angelfire.com/ult/td/tuts.html I replaced the BUZZSAW.QC from Seven's folder with the one from Necros, and compiled using the default settings in FTEQCC GUI. Result is that Seven's fixes work, but Necros buzzsaw fix is ignored. It would seem there's more to this than just modifying BUZZSAW.QC file.
And I didn't actually ASK Necros (or anyone) to do this, I just reported the problem and Necros explained it and made a quick patch. Well pickle my pangolin, that was it - my pak0 was scrozzled, with a different checksum to what it should have. Which means some data on my hard drive became corrupted, which is worrying!
I re-downloaded from Steam and all works. Cheers cheps. R1M7 elevator works fine WITHOUT the buzzsaw patch, but the moment I add it, the elevator breaks.
All qc must be subsumed into the collective.
I can't open your zip, 7zip says its corrupt. Maybe try putting it on quaketastic. (see screenshots thread for login+password) What's wrong with the elevator? I never noticed anything on my last playthrough. Granted I think I was 14 at the time. Buzzsaws interpolation: Do you mind sending me what necros said to you? Also, are both progs.dat files in your rar? I can decompile the progs to find out what all else he did to it. I've become a qc comparison junky of late what with AD absolutely doing everything better so of course I had to update my own personal mod to add some awesomeness. Well honestly, "I hope someone can do this" sounds a bit like asking people to do it for you... ;) Anyway, this thread is dedicated to Quakespasm and people here are not too fond of off-topic, so you should move your problem to that thread instead: http://www.celephais.net/board/view_thread.php?id=60097
I wish I could help more but I know about as much QC as you. Check this out. Few hours ago, I tried compiling Rogue progs.dat from untouched Rogue source code (QC files). Guess what? Elevator doesn't work. I can't explain it, since the elevator DOES work with progs.dat located in original PAK0.PAK straight from the Rogue CD. Is it possible that Rogue CD contains different version of the PAK0.PAK file, with some kind of fix?
Necros said: "The buzzsaw doesn't actually move in the normal way. What it looks like (only from looking at the QC) is you make a func_train or something that the player can't see. Then you target the train with the buzzsaw. Every 0.1 seconds, the QC sets the origin of the buzzsaw to the targetted train. This is why it doesn't interpolate, because it's not supposed to-- the QC call is setorigin." Necros patch: http://s000.tinyupload.com/index.php?file_id=67396143984564862910 Seven's fixes: http://s000.tinyupload.com/index.php?file_id=56371481422796763833 (Seven's fixes still corrupted, I don't know why, here's a direct link from QuakeOne)
https://www.dropbox.com/s/j2zixlpqcpt5tjy/ROGUE%20fixes%20V1.11.rar Post your QuakeC questions in the following thread, which is a Quake help thread:
http://www.celephais.net/board/view_thread.php?id=60097 Your hipnotic buzzsaw issues have nothing to do with the Quakespasm engine. System, ubuntu 16.04, running latest quakespasm, quakespasm executable (does not occur in quakespasm-sdl2) lauched from terminal without any parameters.
Replicating the bug: Upon load of the game, new game is selected. *Just* before the console retreats all the way to the top the tilde key is pressed and the console comes down again. Here is where the bug occurs, the console, instead of staying down, goes back up. Now every time the console button is hit, the console will drop, then return back to the top. This also affects other keys, if you then hit escape and go to "new game", when you're prompted "Are you sure you want to start a new game", the game will accept no input. Alt-Enter is locked, so I can't quit the game, Escape is locked so I can't return to the menu. All I can do is change terminals (ctrl-alt-F1) and kill quakespasm. I reposted it to the bug tracker, hope you don't mind: https://sourceforge.net/p/quakespasm/bugs/17/
I have seen it before and IIRC it was SDL1.2 sending invalid key presses, but it would be good if QS behaved better if possible instead of locking up. Good that SDL2 is working properly though, that was my experience as well. I've been using the 1.2 up until this point in time because for some reason my system (or quakespasm) wanted 32 bit SDL, vorbis and mad libs.
I didn't have them installed because I've been trying to avoid system bloat. I've installed them now though. Fingers crossed it won't break any of my other games :) weird, I'm having trouble reproducing it at the moment. The last time I saw the bug was a year ago or so, but I don't run QS on linux very often, just when testing releases really. I am also on Ubuntu 16.04 with all updates applied, and using the unity desktop.
Just to double check the SDL version you have, mind running this? dpkg -s libsdl1.2-debian | grep Version The command you supplied tells me its not installed, the version I have installed is 1.2.15+dfsg1-3 according to synaptic.
I just looked up what dfsg meant, apparently its debian free software guidelines. Now I wonder if the dfsg version is behind the non-dfsg version. I'd just like to make the following correction. Over a month ago , post #2571, I reported a problem with Quakespasm and the latest Nvidia drivers cause an ungodly texture blurring scenario, and I was curious as to why nobody else was experiencing the same issue.
As it turns out it was my fault. I did a complete uninstall/install of Nvidia's latest Windows 7 drivers, totally clean. The problem was gone, so I can only conclude it was a certain graphic setting I had used within Nvidia's control panel, but which one it was I don't know. Or it may have been something else entirely. But either way nothing is wrong with Quakespasm, nothing (as far as graphics are concerned) needs fixing, and I apologize if I caused any time wasted trying to figure out a problem that was never there. Is the culprit responsible for Quakespasm's blurry texture scenario when using the latest Nvidia drivers. Avoid using that setting.
OK, when minimised, Quakespasm's CPU usage shoots right up to use over 20% of my CPU, and my fan kicks in to overdrive (happens the same whether I'm in fullscreen, then alt-tab to windows - or in windowed mode, then I minimise the window).
I'm using the SDL2 version. I implemented a lightmap format change that may help the AD start map performance on your Intel graphics system:
1. unmodified svn r1371 2. new lightmap format (GL_BGRA GL_UNSIGNED_INT_8_8_8_8_REV) I wonder if you could test these two buildson your system and report what FPS range you get in ad1.5's start map for each build. link to source code I can't measure any difference between those builds on:
-Intel HD Graphics 4400 (2013? laptop) -Intel 855GM (2004 laptop) Back a few years, I tried that modification. Tried the binary on several machines, couldn't locate one where it made a difference (Intel, GeForce, Radeon, etc.)
I believe such machines do exist, but I just didn't have any of them. Baker, yeah.. MH mentioned in the insideqc thread:
This is only really important for Intels that have hardware T&L - say, the 965 onwards; it seems as though earlier generations are more tolerant. I guess my old intel is the more tolerant earlier generation.. and my newer 4400 came out several years after that thread, so apparently Intel fixed the perf issue by that time. Yeah, I haven't tested this in a long time but I don't believe it's an issue any more either. GL_RGB should still be an issue, but GL_RGBA should be fine.
Just for reference, I've tested these builds on a more recent Intel 520 machine without measuring any difference either. This supports my guess that with DX10+ class hardware (where Microsoft forced the vendors to standardise on RGBA) it no longer matters.
A more interesting benchmark would be gl_flashblend 1 versus gl_flashblend 0. That would really help determine if it's dynamic light uploads. Thanks. For reference, build #1 I posted above (and QS releases) are using GL_RGBA / GL_UNSIGNED_BYTE.
-- Question for Shamblernaut: Can you still reproduce the console retraction bug with sdl1.2? I just tried again and can't trigger it (though I remember seeing it like 1-2 years ago). I tried in the default ubuntu 16.04 Unity desktop as well as the "ubuntu flashback (metacity)" one. Tried both windowed and fullscreen. This time on an Intel HD2000, which is closr in performance to @QuakePone's, but still no measurable difference.
That's what I get for skim reading.
As an aside, is there any particular reason for console commands being case sensitive? I understand that filenames require it, especially in *nix based systems. Is this just a legacy code thing or are some commands actually case sensitive? in certain cases, yes, especially if you're exposing them to qc.
there's no good reason for case-sensitive tab completion though. I did test ad_start first by doing nothing and then b-hopping around until I catched those frame drops in each version. The more I tested the less times I encountered them and I usually got different results every time I restarted the map in 92.1 before this.
FPS go around 27 but in 92.1 I sometimes got the framedrops during late tests. It's very unconsistent. You can't really take my word here, I am very confused about all of this and in the end I will probably need an engine that takes more advantage of unused GPU power. Sorry, I can't be of much help here. Ok, thanks for checking anyway. It sounds like the GL_UNSIGNED_INT_8_8_8_8_REV thing is no longer an issue.
My laptop with Intel HD 4400 is faster, but QS doesn't exactly fly on content like AD; some time I will have to look more closely at whether I get the same speed increase when switching to MarkV DX9. This isn't something I've sat down and analyzed. I'm just making general observations here.
Even with the fastest lightmap updates in the world, you'll still bottleneck on lightmap updates. In RMQ we had a scene with 20+ flickering candles; every lightmap in the scene would get updated and it would pull the NV 280 (I think) machine I was using at the time down to 20 fps. GPU lightmaps are the future. Dynamics still have a cost but lightstyles are completely free. FitzQuake's brush model renderer sucks. If you were to be actively malicious and deliberately set out to write a bad brush model renderer you might do worse but I doubt it. Ideally brush models should go through the same renderer as the world. A map with lots of brush models is always going to run slow. FitzQuake's sky renderer sucks. If you were to be actively malicious and deliberately set out to write a bad sky renderer you might do worse but I doubt it. I had one of those "sweet baby Jesus" moments when I analyzed a scene in PIX and saw that 80% of the time was spent drawing sky. Any scene with sky in it is going to bog down on slower hardware. What both of those have in common is per-polygon state changes. In the absence of batching in your own code the driver will make reasonable efforts to batch itself, but state changes will break that. There are certain items of "Quake lore", such as Quake can't do big scenes, sky is slow, disable multitexturing, and so on. They're not true. The problem is in the implementation, and they can all be solved. In Quakespasm, the brush models are drawn with the world, if I recall.
As a general note, since I don't know if you are aware of this -- Arcane Dimensions is a bit less optimal than some other single releases in a couple of departments: 1) First, it uses sprites as particles. So each little floaty pixel is an entity. You can turn this off by doing "temp1 0" and restarting a map, if I recall. 2) Second, you know static entities like torches? Arcane Dimensions doesn't do torches as static entities. And Arcane Dimensions uses a lots of torches. I haven't checked, but combined with the fact that Arcane Dimensions maps tend to have tons of details and complex geometry and generally the maps tend to have at 200-300 monsters and super-tons of items/books/etc It's a bigger load than most maps tend to be. And because of the torches and particles, I suspect puts more pressure on the QuakeC interpreter too. The end result is very cool and creative. Also: I have never checked, but in complicated maps with huge entity counts -- how much is vis helping? Engines with r_lockvis you might not be able to tell (If I "r_lockpvs 1" in Mark V, then no clip outside the start map it looks like this http://quakeone.com/markv/media/start_map_r_lockpvs.png Now, mh, look at this On ad_mountain I type "r_lockpvs 1" and noclip outside map http://quakeone.com/markv/media/ad_mountain_r_lockpvs.png <--- RED ALERT!!! So Imagine how many entities are drawn per frame with vis doing that? 500? 1000? I don't know, but frustum culling cuts some of that down. So I wouldn't approach this this that the maps are optimal and the mod are optimal from a performance standpoint and the Quake tool are doing a good job. Arcane Dimensions is a great experience, but there is plenty of room for performance. 2nd opinion on "r_lockpvs 1" using DirectQ, just to make sure.
http://quakeone.com/markv/media/ad_mountain_r_lockpvs_directq.png And let's throw ARWOP Roman1 into the mix which isn't Arcane Dimensions http://quakeone.com/markv/media/arwop_roman1_r_lockpvs.png ^^^ With vis generating results like the above, well --- let's just say the wide open outdoors map thing sure doesn't vis very well. Is a struggle.
In the old days mappers used water volumes to control vis as they were vis blockers. I asked ericw to add a vis brush to perform this task instead when compiling. Don't think it was ever implementedy Vis doesn't do its job all that well, not even on many of the original Quake maps.
But Sometimes it does. But the real problem is even more insidious. Vis is used to determine what entities Quake thinks you can see! If it is drawing damn near the whole map, it's also drawing all those spritey particles and perhaps most of the monsters in the map. In Mark V, if I type sv_cullentities 2 in the console.
I get a significant frames per second boost. 15-20% on ad_mountain. sv_cullentities 2 is a very strict "is the entity visible" check on the server side against all entities. It is otherwise known as "anti-wallhack". It's also a somewhat cpu expensive, but I guess it is saving several hundred entities from being drawn at all so it is paying off here. Could that be detail brush shenanigans? I remember a discussion once where it was concluded that detail brushes can sometimes mess up the PVS if they totally cover a world face.
Try it in id1 Zendar and then ad_zendar?
I recall sock doing some hint brush fuckery, maybe that's the culprit. I wouldn't read too much into ARWOP behaviour, ARWOP is very much a special case.
The AD screenshots definitely indicate that something different is going on too. I'm going to do a bunch of testing on that and see can I figure what it is. Re: VIS I'm amazed that no Q1 VIS tool has implemented area portals. Being able to lob off huge chunks of geometry just by closing a door is a win. I'd love to see Q1 VIS moving to legacy; engines can still load & use it for compat but let's standardize on Q2 VIS for the future. is there a different culling method that could potentially be written into a quake engine that would be better suited to big open maps?
designing as intelligently as possible. Don't make giant box maps (something I need to work on myself).
However it would be nice to have some extra toys to work with. Big open maps and culling are not the problem. The current culling is perfectly capable of handling them, a minor optimization to R_RecursiveWorldNode makes it a little better (software Quake has the optimization, GL doesn't).
The problem is in the renderer and server processing. QuakeSpasm now has the necessary renderer work to be able to handle big scenes. It could go faster by bumping the hardware requirements to GL 3.x and implementing array textures for lightmaps, as well as putting in some instancing for MDLs, but that might be too intrusive a change to the codebase. Server processing is a problem and QC is just too slow for large entity counts. That's the next tree that has to fall. I agree with mh, it still works impressively well on big, open maps, and it matters a lot on AD maps. ad_tfuma was fastvised it right up until release, because Fifth and I both assumed vis would take forever and not be able to optimize much, since it's more or less a giant box with some underground areas. Just before release, one of the testers complained of low fps, so I tried full-vising it - took only 20 minutes (8 threads), and the wpolys visible from the start position were cut in half (30k to 14k iirc).
QS's brush model renderer was the first renderer thing I changed (this was ~2014 for RRP, ijed's map had some complex bmodels), they're not merged with the world, but each is drawn using the world renderer. QS uses the Fitz sky renderer unmodified. (same for liquids). GPU lightmaps: blending the 4 lightmaps per face sounds like a straightforward good idea. I'm wondering if it will be difficult to do the moving dynamic lights from rockets/etc. IMHO they need to be kept at the low-res of the lightmaps - when I was experimenting with high res lightmaps and LIT2, I remember noticing that rocket trails really stuck out like a sore thumb when they were over a high-res lightmap. @mh did you do any experiments with this part of GPU lightmaps? I draw dynamics as additive blended extra passes over the scene. Full per-pixel quality. TBH it doesn't bother me but maybe this is one of those things that annoys different people in different ways.
I guess you could use a low res attenuation map texture but I just do the maths. Optimizations: Eric Lengyels scissor test optimization is mostly designed for shadows but helps here too. Frustum culling the dlight. Only light surfaces that were drawn in the main pass. I also add dynamics to BSP brush models using this scheme. Light styles: I actually use 3 textures, one for each of R, G and B and encode the styles into the color channels. Animation is a 4-component DotProduct per channel and combine them to the final color. Another side effect, not related to rendering, of the vis problems combined with spritey particles is huge demo sizes.
As you know, the vis information is used to determine what entities the server side thinks is visible to you. If you record a demo in most of the Arcane Dimensions maps, the demo is going to be massive after 30 minutes of play (600 MB). I ended up disabling the autodemo feature by default in Mark V because recording a demo in Arcane Dimensions became a performance issue So anyway, the full deck of cards. /The very nice thing about Arcane Dimensions is that it is open source. Sock is #1 in my book because he's always been open source. Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles). Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. particles - qss uses fte's particle system to support the effectinfo stuff that sock used in ad, as a result qss should have much more sane demo sizes with ad 1.5.
choppy - use a thread to perform the disk writes, then you don't get stalls from flushing happening on the main thread. making that change reportedly solved multi-second stalls with fte on linux. size - gzip it as you go (you don't rewind, right?...). damn
the demo that i recorded for ad_magna is 2gbytes i checked with r_showtris 1 and no particles-entities, the demos should be smaller All the FitzQuake derivatives support r_drawworld 0; fog 0 // fog 0 helps visualize distance entities.
The following screenshot demonstrates how map vis isn't helping much Particles http://quakeone.com/markv/media/r_drawworld_0.png All those monsters that have no chance of being seen 1) Get sent to the client by server. 2) So they get recorded in a demo 3) So the engine tries to render them on the screen Rendering hundreds of entities that cannot be seen is a performance hit. "Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).
Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. " I was tinkering around with an idea, (well mostly because I found what I did wrong with bsp2), working on some AD stuff, and particles. I started with making little flames on the tops of candles, instead of the bouncy little polygons. But I could expand this to replaces the sprite emitters from AD and use QMB particles on the engine side. I'll post some results/screenshots when I get things rollin'. Hey, I'm getting a weird wateralpha bug
see: http://imgur.com/a/rqoGv the lava (or any fluid) appears milky except for when the player is clipped into a wall? the alpha is set to 0.3 the version is version 0.92.1 (SDL 2 build) I'm running ubuntu 16.04 LTS using opensource radeon drivers. Is this a configuration thing or a software bug? Cheers. only if you revis them yourself, or use get vis patches.
otherwise they'll just be transparent and reveal the void below. if you were using a value of 0.6, you might not have noticed. I thought that the vanilla maps worked fine with wateralpha
No, they don't. This is actually called out in the original GLQuake readme: https://github.com/id-Software/Quake/blob/master/WinQuake/docs/readme.glquake#L152 Unfortunately, the standard quake maps don't contain any visibility information for seeing past water surfaces, so you can't just play quake with this turned on. Note that r_novis will just let you see surfaces through water; it will not let you see entities (monsters, doors, pickups, etc) through it. Mark V and DarkPlaces (rather sure) and some other engines support external
https://quakewiki.org/wiki/External_Lit_And_Vis_Files You put the It's pretty much the same thing as external I use this from BPJ wrote on an old thread on QuakeSource.org that just draws everything
[code] byte *Mod_DecompressVis (byte *in, model_t *model) { static byte decompressed[MAX_MAP_LEAFS/8]; int c; byte *out; int row; row = (model->numleafs + 7) >> 3; out = decompressed; if (!in || r_novis.value == 2)//BPJ { // no vis info, so make all visible while (row) { *out++ = 0xff; row--; } return decompressed; } do { [/code] it simply allows me to see all ents underwater, yet im sure it's not optimal :P It's definitely not optimal because it will also pull in ents that would otherwise not be visible in a properly watervised map.
The other thing it will do is increase server load and protocol traffic. The latter is something you might be surprised about. We have a tendency to base assumptions and measurements only on things we can directly see. In a scene with 400 active and moderately complex entities, the bottleneck isn't the renderer - it's PR_ExecuteProgram (QC, in other words). Some weirdness going on with the sky at high distances: back wall disappears when more than 8192 units away.
It's at 16k as per default. With normal textures it works fine, just the sky brushes are affected.
I bet it's a qbsp limit (BaseWindingForPlane). Someone reported this as a bug in tyrutils-ericw a while ago and I raised the limit, try the latest version of my tools.
You really should just draw sky with glDepthRange (1, 1) - that way you can draw it as a tiny (but larger than nearclip) cube around the viewpoint and it will automatically position itself at the far clipping plane. The way Fitz & derivatives handle both the scrolling sky and skyboxes makes this very possible.
I know most of the mods/maps have to be installed in the base Quake folder, but it really keeps that folder messy and it's hard to sort through if you have tons of maps/mods and when you want to delete a folder it's a hassle.
Is it possible to put all the mods/maps in a seperate folder and still be able to launch QuakeSpasm with enjector? I tried doing that but it won't let me because everything has to be in the basedir, is there a command i could use? Is it possible to set a path to a different folder in quake injector? Hi!
Thanks for all the hard work you've put on this great engine. It wasn't until now that I was able to come across a bug that I'd like to report. Fairly recently I got myself a monitor with a max refresh rate of 165 Hz, so to squeeze out all that juicy smoothness the monitor can offer, I decided to adjust the host_maxfps setting in the config to 200. However, this causes problems that can be seen most notably in elevators: all entities onboard the elevator seem to kind of lag behind. For example, if I go down an elevator, the elevator goes down smoothly, but I go down in skips, as if I was Wile E. Coyote forgetting that gravity exists for a split second and then I fall on the elevator again only to forget gravity for another instant as soon as I touch the elevator again. And the pattern repeats. The same happens going upward, with more severe consequences, as I end up slightly inside the elevator, which may sometimes cause the elevator to think that it's squishing me, which causes it to damage me and then reverse back down. I did some testing, and the only influencing factor seems to be the value of the host_maxfps setting. (Fiddling with the V-sync settings didn't seem to do anything.) The threshold value seems to be about 165, above which the problem starts appearing. Anybody else have this problem? Sorry, if this has been addressed before. In most quake engines and wasn't really designed to go that high. Some engines have uncoupled physics from framerate and work better at higher frames. I believe dark places is one such engine.
Hi,
I know QS is OpenGL while RPi is GLES, but, really, it would be great to enjoy Quake (or Arcane Dimensions)on a small, silent and low-power-consuming Raspberry Pi 3. BTW Quakespasm is yet available in Raspbian Jessie repository, but I get a "Couldn't load video device" error when I try to run it in framebuffer mode (CLI). So really no interest in a Raspberry support? :( there's actually a few engines that support gles2 nowadays.
Izhido(was it?) had one for ios, alternatively there's multiple engines that run on android with its gles1/2 limitations, including my own. If you grab the source for fte, you should be able to use the following command for the original rpi (cross compiles, you might need to fix up some assumed paths inside the makefile): cd engine && make gl-rel FTE_TARGET=rpi If they've fixed up their egl support since the original, you can try and be more generic and just use the following: cd engine && make gl-rel FTE_TARGET=linux32 CFLAGS=-DUSE_EGL With that generic build line, you can switch between egl vs glx under x11 with setrenderer egl vs gl. I don't actually have any sort of rpi, so I can't really help much more than that. Funny thing I just ran across...
Using the latest 64-bit quakespasm-sdl2.exe, with the latest NVidia drivers, there are certain POV points on the DM3 bridge where sections of the outside pentagram area are being rendered in my view. Screenshots: https://www.dropbox.com/s/1b5cb0dbg9t51o6/spasm0000.jpg?dl=0 https://www.dropbox.com/s/nlst7lupknon1ga/spasm0001.jpg?dl=0 and here's my config.cfg and autoexec.cfg: https://www.dropbox.com/s/wm75461ngtotcv8/config.cfg?dl=0 https://www.dropbox.com/s/6i1jj64oelutyg2/autoexec.cfg?dl=0 I think it's just r_wateralpha 0.5 in config.cfg + non-watervised bsp (QS has had gl_clear default to 1 for a few versions, so you don't get HOMs anymore, but you get that instead, which is less obvious what's happening).
So it's good that it's not some deeper bug in the renderer, but this is a common enough thing (it's been reported a couple times I think, happens to me fairly regularly) that we should probably do something about it... IIRC, QS has had r_wateralpha be archived in config.cfg since an early version, and when you combine that with changing gamedirs with "game" you can easily launch something like AD, then change to id1 in the console, exit, and end up having r_wateralpha 0.5 saved in your id1/config.cfg. There's also the option of having the engine detect watervis, etc. Ah hum. Yeah I clean-installed recently and I guess I picked up a default r_wateralpha of 0.5 from either QS or Mark V. Actually it's been so long since I messed with those settings for non-watervised maps I forgot that it even had an effect if r_novis was 0.
I really wan't to play Arcane Dimensions in low resolution. Unfortunately mark v, which supports resolution scaling, doesn't support AD. The winquake version has problems everywhere and the opengl version can't handle some things like the fog in the necromancers keep. Apart from that performance is also really bad. mh explained how that has to do with mark v being cpu-bound while engines like quakespasm are fillrate-bound, which also means that downscaling would greatly improve performance in quakespasm while having close to no benefit in mark v.
I mainly wan't this feature because of the way it looks (explained in detail in my mark v post here: http://www.celephais.net/board/view_thread.php?id=61375&start=1487 ), but the potential performance boost is also incredibly useful to me as I'm running quake on pretty slow hardware. Quakespasm is already a huge improvement over mark v in AD, but I still get occasional framedrops on 1366x768 (native resolution of my laptop) while 320x200 runs silky smooth. Of course not in fullscreen, but quakespasm will output that resolution in windowed mode if you specify it with -width and -height. That proves to me that the resolution I wan't to play on is at least technically possible in quakespasm, I would just need a feature similar to that in mark v which stretches a borderless window to fit the full screen without interpolation. You can even simulate something like this by using the windows magnifying tool, but it's horribly awkward to set up and doesn't allow you to use the mouse (more on that in my last post in the mark v topic). So, getting to the point here, I will pay the developer who implements this feature in quakespasm. That's how badly I want this. I absolutely love quake, and the amazing lovecraftian environments in AD make me truly happy to experience, but I can't enjoy them as much on high resolutions as I would otherwise. If you're one of the developers reading this, name your price for the time it would take you to implement this. I will pay you, given that the price is within reasonable bounds. Not sure I'd play on 320x200 but less detailed quake maps definitely look better in lower resolutions IMO. I tried setting QS to a lower res than my laptop screen, but my screen just blurs it and it looks terrible. It would be nice to have the option of playing on lower resolutions but with krisp krunchy krixels
Yep. In vulkan quake i dont see an issue with 289. In quakespasm i get the gravity problem or when going up a lift it damage happens to health.
Boris,
You could try this workflow for your purposes. The following link details a DOS compilation of super8. I'm not sure how recent it is, however it may support modern map limits and features. http://www.vogons.org/viewtopic.php?f=24&t=39878 If you don't have a DOS machine, you could try running it from DOSBOX or similar emulator or VM to achieve your desired results. Good luck! I am game to implement this - it shouldn't be much work, and it fits well with the "vid_desktopfullscreen" feature we've had for a while (If you set this to 1, the vid_width/vid_height cvars are ignored when you go fullscreen, it just uses you desktop res.) Another reason to do it is, one of my test machines (Linux) doesn't offer any fullscreen modes besides the native LCD res.
How does this sound, new cvars r_width/r_height, which default to 0 (use window size), but if you set them to something else like 320/240, Quake would render at that given resolution and then get scaled to the window size. The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched, and should the stretching be always nearest-neighbour or respect gl_texturemode? I am thinking always letterbox rather than stretch if the aspect ratios differ, and always nearest for now? Off the top of my head, if I was doing this I'd repurpose the old vid_stretch_by_2 cvar and retain the aspect ratio.
"The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched"
Imo horizontal letter box is the best option, stretching looks bad. Setting resolution to 320x240 (4:3) and then stretching it to 16:9, defeat the purpose. I guess someone who wants to play in 16:9 in super low resolution will set it to 320:180 anyway. Yeah, I just thrown this as an example.
I think hardware-wise minimum resolution available in modern cards is 640x480, so it will be scaled to closest minimum anyway (or to whatever resolution you have), so you could go with any resolution you like :D Something weird I just came across by accident. If you give yourself 99999 (i.e. 5 times "9") health via the console (by typing "give h 99999"), the player's perspective tilts sideways like it does when you die, but you can still keep playing normally.
It doesn't happen when you type 4 x 9 or lower, nor when you type 6 x 9, but it does happen again with 7 x 9 and higher. Any idea why this happens? Is this a known bug? Here is my theory, correct me if I'm wrong:
I think max health you can apply is 32767: 0111 1111 1111 1111 Why not 65534? Because leading bit is reserved for sign, so -32767 is: 1111 1111 1111 1111 Now if you type 99999 you get: 0001 1000 0110 1001 1111 but you can't keep 20 bits so 4 bits got chopped and you end with: 1000 0110 1001 1111 and leading bit is 1 which means you get a negative number of -1695 That's why camera is "broken" and you are still alive(?) 999999 gives: 1111 0100 0010 0011 1111 same story as above, too many bits, so we chop it to: 0100 0010 0011 1111 leading bit is 0 so it's positive, which gives 16959 etc. Here is my theory, correct me if I'm wrong:
You're right. There are two "views" of health in Quake: the value stored on the server and the value stored on the client. The server is the master whereas the client is just used for determining if the screen tilts, whether the status bar displays, stuff like that. So each frame the server writes it's current value for health to the client. The server stores health with full 32-bit precision, which is why movement and not actually being dead still works. The client stores it with 32-bit precision. However, and because saving 2 bytes per client was important in 1996 but bites us in the ass today, it writes it as a 16-bit signed short value. So yes, it's losing significant bits in the transmission from server to client. All happens in SV_WriteClientdataToMessage and a quick fix might be to bounds-check what's written. Yup, as a quick fix this appears to work fine.
I'm not sure of the utility of having values below 0 or above 999 on the client, because the client only needs to know (1) are you dead, so it can tilt the screen, change the sbar, and not draw the viewmodel; and (2) if you're not dead, what your health is to a limit of 3 digits because that's all that the sbar has room to display. if (ent->v.health < 0) MSG_WriteShort (msg, 0); else if (ent->v.health > 999) MSG_WriteShort (msg, 999); else MSG_WriteShort (msg, ent->v.health); I'm not sure of the utility of having values below 0
Isn't the negative magnitude used for gibbidy giblets? ignore me
Have more beer. :) Even if it was an issue you could bound it to signed 16-bit range instead. That's great news!
Concerning the stretch or letterbox question, I think there is a way to get around the issue altogether. Create a console variable like "vid_scaler" which defaults to 1 and determines by which number your resolution should be divided before scaling. For example, you're running quakespasm in 1920x1080 and set vid_scaler to 4, which results in a new resolution of 480x270. The game renders this resolution and scales it 4 times without interpolation, fitting the screen exactly. Alternatively, you could have also set it to 3 or 2 which would give you 3x-scaled 640x360 or 2x-scaled 960x540. That is the way mark v does it, and it looks really good. Even if the scaled resolution will always be somewhat higher than 320x240 depending on your native resolution, having no letterboxing more than makes up for it. And you could always create a custom resolution like 1280x960 to get 4x 320x240. That's how I run mark v on my 1366x768 laptop. Since 1366 cant be properly divided by 3, I created 1344x768 for myself which has small black bars but can be 3x-scaled properly from 448x256. Most people won't have that problem anyways, and doing it this way would also allow you to customize the chunkiness of the pixels to your personal preference. FifthElephant could play on 640x360, given that he has a 1080p display. Clamping health on the server message sounds like a bad idea because it assumes the client will never display values above 999 . Network code should clamp to the protocol maximum, display code should clamp to the display maximum.
Also I agree that scaling only seems to make sense at integer scales so a single cave defaulting to 1 would be simplest for the user. Unless there's a desire to scale different let on each axis.
Hey guys
Apologies if I've missed something - but is it possible to use a PS4 Controller with Quakespasm? I'm using DS4Windows as a wrapper to the xinput. Any known issues? Using latest version of Quakespasm with the controller Thanks! Use quakespasm-sdl2.exe which has xinput support (via SDL2). I have only tested a wired X360 controller and steam controller (in Xinput mode) but both of those worked.
There are some notes on config settings here: http://quakespasm.sourceforge.net/Quakespasm.html#ss3.2 Just wanted to say thankyou ericw - I wasn't using the SDL exe. Had a great day playing Quake on the couch!
All my social events will be quake once 4-player splitscreen with pads is on one of the engines. Currently being dominated by Turok 2's splitscreen right now :P
Some of us have friends in real life and like to play games with said real life friends...
Post with your Nick next time asshat. I don't mean to be pushy, but is this still happening? It's been radio silence for quite some time now.
Sorry for the silence, I coded most of it and got sidetracked. Here is a built to test out:
windows build source The cvar I went with is "vid_scale", default 1, set it to 2/3/4 to get 2x/3x/4x scaling. You have to do a "vid_restart" in the console after changing the scale (this could be improved later to have it live update). I didn't push this to the main QS codebase yet, wanted to get some feedback / testing first but it seems good to me so far. I like this feature... I also turned off basically everything, lerping, shadows etc to get it really old school
Had a quick look, works well! Screenshots are fubar'd though, looks like it's only screencapping 1/4 of the screen.
build with fixed screenshots
Glad you like it Fifth - yeah, it seems good on id1 maps with square particles + lerping off. Does this build have spikes weather code included?
I'm really curious as to what "vanilla" quake would have looked like with weather effects. Not in this build, the scaling should be straightforward to add to QSS though.
Fifth I know, hopefully at some point (or in MarkV :) http://fte.triptohell.info/quake?+set%20cl_splitscreen%203%20+set%20coop%201 :)
@Shamblernaut, at 320*200 rain-like effects will probably just look like a few sparkles occasionally. slow moving comparatively large snow-like particles are probably going to be okay though. note that hexen2 had snow effects too. I like vid_scale....would it be a daft idea to hack in support to be able to scale the console and HUD differently to the main scene?
I like the chunky piskels but the screen-filling HUD less so.... is it still too big with the "scale" slider in the settings menu at the minimum setting?
@boris appreciate it, my email is in my profile. is it still too big with the "scale" slider in the settings menu at the minimum setting?
Lolbiscuits, I didn't know about that setting. Seems to fix the issue, cheers :} Seconding what Kinn said. I was imagining it implemented along the scr_scale settings like;
scr_menuscale 3 scr_conscale 1 scr_sbarscale 2 scr_vidscale 4 As it is though, with all the scr_scales at 1, vid_scale 3, and scr_sbaralpha 0.999 running at 1920x1080, it looks wonderfully chunky. I'm loving it. Another way around the screen engulfing sbar would be allowing scales below 1. So a vid_scale of 4 and a scr_sbarscale of 0.25. I dunno, you're the one coding. Can I get you a beer? That would be cool but will probably be really hard to implement.
I think Quake basically runs at a really low resolution that is just being displayed bigger than it actually is, so it would be impossible to have scr_ scalers below 1 since that would require more pixel density than is available. At 0.25 you would need to display 16 different colors in what as far as quake is concerned is only one pixel. This kind of feature only works if the 3D world and the ui elements are rendered completely independent from one another, so basically the ui would have to be running at desktop resolution while the 3D world runs at a fraction of it. Can't guarantee you that's right though, just my understanding of it. Yeah, scr_sbarscale below 1 would not really work with the current set-up, as you would get pixellated and unreadable status bar.
Having vid_scale affect the 3d view only (drawing 2d UI after scaling) would be possible, main disadvantage is it requires another framebuffer copy (more VRAM use and fps hit), whereas currently I combine scaling with brightness/contrast at the very end of rendering. On the other hand I can see how the current implementation is a bit confusing with how scr_vidscale is applied on top of scr_sbarscale/scr_conscale/scr_menuscale. Not totally sure but maybe I'll experiment with the "draw hud after scaling" variant. That is also how FTE and DarkPlaces do this feature. https://drive.google.com/open?id=0BzKtjR7p3BXddUo3TVhPd3U5WVU
depending on your aspect ratio and scaler value the console text gets screwed up in a few places. there is usually either at least one horizontal or vertical line somewhere that is a copy of a line directly next to it. strange double dots also keep appearing in some words when typing in the input bar. i checked to see if this happens with winquake mark v scaling aswell, but it doesn't. maybe this problem is exclusive to hardware scaling? you'll also notice that the console background image is scaled incorrectly (look at the row of holes near the bottom) since the source image is designed to span the width of 3:2 resolutions and is being upscaled slightly to fit 16:9. well, it's actually 683:384 in my case, which is essentially the poor man's 16:9. it's almost unnoticeable without downscaling, but it looks really jarring compared to everything else in scaled modes. i tried to get around this by creating 1152x768 as a custom resolution that fits my native y exactly to play in 3:2 with letterboxing, the same trick that worked for me in mark v. doesn't work in quakespasm though, it doesn't seem to care about custom resolutions. they don't just fail to show up in the menu either, entering the mode manually into the console just yields the "that mode is not valid in fullscreen" error, even though the resoluton is recognized by the system. well, since that solution is stupid anyways i'd like to propose the following: https://drive.google.com/open?id=0BzKtjR7p3BXdbGk2a1k3ZF9SUGM scr_conaspect: 0 is scaled to fit the x of your resolution, 1 is a 3:2 overlay independent from it. is the amazing ericw up for this incredible task? :) oh yeah and while we're on the topic of ui related stuff, is there a way to get the sbar centered in multiplayer that i'm unaware of? couldn't find the cvar for that, apparently it's exclusive to mark v. i know it's faithful to the original quake but i'd still like it centered. depending on your aspect ratio and scaler value the console text gets screwed up in a few places
This happens because the console text is a single texture with each letter packed tightly against it's neighbours. When rendering the text with linear interpolation a 2x2 block of texels is selected and a weighted average is taken (note: this behaviour is built into the txture sampling hardware); adjacent texels may be sampled, hence you see some "spill-over" from adjacent letters in the console text. Solutions? Always render the console text with nearest sampling. This is what the original GLQuake does but I'm not certain how well/nice it would look with various scaling modes. "Pad" out the console text by adding a minimum 1 texel border to each character (in practice a 4 texel border will exactly double the size of the texture which may be required for old hardware that requires power-of-two dimensions) with repeated texels from the edges of that character so that the 2x2 sampling will work as expected. Adjust the texture coords for characters slightly so that sampling always occurs from within the exact character we're drawing; this is what GLQuake does with the little status bar icons which it also packs into a single texture. Unpack the characters to 256 8x8 textures and draw them individually with clamp mode. This might run slow. Build a 256-slice texture array and draw them with clamp mode using the character number as the array slice. This runs fast but requires OpenGL 3.0 or GL_EXT_texture_array. Don't scale them at all and accept having to squint to see them at higher resolutions. Draw the 2D GUI stuff to an offscreen texture at the scaled resolution then stretch it over the scene to full resolution. Will run slightly slower. Something else I haven't thought of? boristhesp1der, for the screenshot with the double lines, can I check your vid_width, vid_height, vid_scale, scr_conscale?
The way I implemented vid_scale, if the window size is not divisible by the value of vid_scale, it will just stretch the framebuffer to fit and I think you may get artifacts like that repeated line, I should double-check that. - The "leaking" between characters is an old problem with QS's scaling, it would be nice to fix sometime using one of the solutions mh gave. - multiplayer sbar centering: not possible atm, someone submitted a patch for it a while ago, and adding it as a cvar sounds good. doesn't work in quakespasm though, it doesn't seem to care about custom resolutions hm, interesting. The difference between markv and QS is we are using SDL (cross-platform library) whereas MarkV is coded against windows directly.. so maybe SDL is not noticing custom resolutions. - re: the console background, by "scaled incorrectly", do you mean the aspect ratio isn't preserved? That seems like a bug. I'm not sure about supporting a narrower console as the UI code tends to be pretty complex / fragile and it may be messy to do. And scr_conwidth is 0, don't know if that is the default but it doesn't play nice with scaling.
I don't think the aspect ratio is the problem, it's just how the improperly scaled image looks through a rough pixel grid. the x resolution is what matters here, it needs to be either exactly 320 or a whole multiple of it since that is how wide the source file is. that's just the way it has to be when the image is forced to span the width of the screen exactly, other ui elements like menu and sbar are not affected by this problem since they are free from this constraint. I haven't tested the latest QS build, but I play with a 1366x768 res too. I seem to remember that earlier in this thread someone pointed out that this exact resolution is difficult to scale. I'll have a look with 'search' function. My english is really bad in the way I start every sentance with I.
eric is right, that number is not divisible by 3 so scaling by that factor is bound to cause problems. 1344 is though, real bummer with that custom resolution allergy. :/
just checked winquake again, scaling seems to work differently there. check this out: https://drive.google.com/open?id=0BzKtjR7p3BXdRVpIWXhvTEFkRXc https://drive.google.com/open?id=0BzKtjR7p3BXdb3VMejhqeXFWQ3M both are taken from 1366x768. Quakespasm has the framebuffer line while winquake does not, even though both are scaled 3x to very similar size. background is also differently ugly in both versions, interestingly enough. by the way, I noticed the reduced color palette in software quake actually changes atmosphere in ad pretty drastically, would like to try this in quakespasm. the color depth option is stuck to 24bit though, is it just there for decorative purposes or can you actually change it? :P 1366 is difficult to scale in this kind of way, yes.
Basically: 1366 / 2 = 683, and 683 is a prime number so nothing else will divide equally into it. I tried downloading the testbuild for the vidscale feature but the link is broken. error 502
Did a bit of experimenting..
Yeah, 1366 = (455 * 3) + 1, so with vid_width 1366 and vid_scale 3 you'll get mostly 3 pixel wide columns, but one column 4 pixels wide. For me it's right in the center of the window, and pretty difficult to spot.. However I think I see why the console looks so bad.. it's a case of doing nearest-neighbour scaling twice. The actual size that everything is rendered to is 455 pixels wide, which is a poor fit for a 320 wide console background. Then it's scaled up ~3x to 1366.. so all of the scaling errors are magnified 3x. If you do nearest-neighbour scaling from 320 directly to 1366, the artifacts are much less ugly. So this may be a good argument for changing vid_scaled to affect the 3d view only.. hm.. when you look closely there is a hairthin line at the right edge of the screen where the desktop is peeking through. it sorta just pushes the problem away instead of dealing with it.
@brassbite seems like our displays have digital down syndrome :( here's the link: https://drive.google.com/open?id=0BzKtjR7p3BXdYk1nQ2hfM2lNOU0 @ericw how are the video modes determined? can you just change what it makes available to you by default in the source code or does it depend entirely on the system it's running on? i agree with brassbite, simply being able to set an aspect ratio to get a resolution based on your native height would be very useful and evade the problem alltogether. brassbite: sorry, the link in #2727 is fixed.. my server went down for some reason. When it's official: not sure, I think I might try redoing it to only scale the 3d view, as this will avoid the ugly artifacts on the conback / console text that boris reported.
@boris, regarding color depth, on some systems (usually old hardware / OS'es) Quakespasm will let you select 16-bit color in the video menu. Rendering to the quake palette would have to be coded explicitly, probably as a postprocessing effect. Can't promise it'll happen but I agree it would be a cool option to have aesthetically. You are looking for a pixel magnification factor, but are instead inputing a pixel division factor.
Division doesn't naturally lead to an integral scale, and since a screen is 2D it may lead to situations where a number works for width but not for height. i.e. scr_conscale magnifies the console i.e. Sounds like you are using vid_scale to divide the resolution rather than magnify the pixels. scr_conscale 2 in FitzQuake doubles the size But you have vid_scale half the size. If I am making any sense. /Scaling is always enjoyable to work through and satisfying upon completion. If you like math problems. The auto-scaling HUD in D3D/GL uses magnification factor. Like always, one opinion -- probably wrong. There are different ways to do scaling, anyway i don't get it. how is magnifying helping the situation compared to division?
they way i understand it is that we have an image that is 320px wide, and we need to scale it to fit on a screen that is not a whole multiple of 320px in width. no matter whether you divide the resolution by a whole number or magnify the source texture by that number, it should be impossible to have a proper result. let's take my case as an example, which is having 1366 horizontal pixels available. i created a custom resolution of 1344 to be able to divide by 3, which means i am now rendering 448 pixels that all occupy 3 horizontal pixels on my screen. otherwise i would have 455 x 3 + 1, but that doesn't affect the problem and just complicates the explanation. now we need to display the console in a way that fills the entire width of my screen with 448 pixels available in that direction. this cannot work because the next whole multiple of 320 is 640, not 448. that means only 448 of 640 pixels can be displayed and 192 can not, resulting in an image where most pixels are being displayed at full size but some are displayed at half size. do i have an error of thinking in that? if i don't, i can't see why magnifying would help since it is affected by this problem in exactly the same way. i also tested 1280 which is a whole multiple of 320 in 2x and 4x, and both display the console properly. @eric can you take a look at this? https://drive.google.com/drive/folders/0BzKtjR7p3BXdUG5SclhqaG15b28 i would really like to play with 4x scaling, even though my display technically doesn't meet the requirements for that. the text in the menu gets scrunched up since it's running out of space, but this could be fixed by splitting the menu into two pages. is that something you can change? would be cool to have it automatically detect whether enough space is available and switch to split mode if there isn't, but having a cvar like scr_menusize is also fine. there is also another problem outside of the menu, the text messages are affected aswell (look at the u and r), even though they have more than enough space available. the text in the map info is being displayed properly, which leads me to believe that fixing it should be possible. right? @Baker
i was wrong, apparently there is something else going on. 1280x720 looks almost right, but not quite. the aspect ratio has an effect on how the texture is displayed, it needs to be 16:10 or else it gets stretched vertically even if the horizontal resolution is fine. 1280x720 is so close to 1280x800 that i didn't notice the artifacts at first glance. i don't understand why it's doing this though, the source file is tall enough that stretching shouldn't be necessary. is it a bug or is this behavior intended? I started a rewrite of this yesterday that just scales the 3d view, and it's a lot cleaner as far as the code, and will avoid all of the UI scaling issues (at least, not introduce new ones :). So you'd be able to set "scr_viewscale 4" but "scr_conscale 2", etc. I'll post a build as soon as I fix a few things.
Baker, yeah this has been fun. :) I think I see what you mean, the naming is a bit strange for "vid_scale 2" - it does scale up by 2x, but also shrinks the rendered area by 1/2 at the same time. new build to try
Cvar is now "r_scale", and it only scales the 3d view, so you can adjust it independently of the console/menu/sbar scale this fixes pretty much everything, i can even play on 1366 instead of 1344 now. you da man! :)
I'm assuming you figured out everything ;-)
And it sounds like you got the reward of the "Aha!" moment. Use metlslime's oldwater method or what mh does for GL waterwarp
1. Calculate magnification factor + virtual resolution 2. glViewport 0,0,virtual screen width, height 3. eglCopyTexSubImage2D to capture that area 4. Maybe glClear the texture buffer if you aren't drawing full-screen, although there are ways to avoid this step entirely. 5. glViewport 0,0,real screen width, height 6. Render the texture captured but now to the full screen Now draw the 2D like normal. No shaders. Maybe 10 lines of code. I think that's close to what I ended up with, here is the full patch:
https://github.com/ericwa/Quakespasm/compare/master...vidscale?expand=1 No shaders, I think it only needs GL1.1. i understand if im getting on your nerves with my questions and requests, and i sure as hell don't have the same technical knowledge like you two. but i do care about this stuff a lot and would greatly appreciate if you at least explain to me we where i'm wrong. seriously, i have huge respect for what you're both doing and try to learn from talking to you.
if you don't like the pitch about splitting the menu into two pages that's ok, i have a better idea anyways. the reason behind it was to allow for proper ui scaling for aspect ratios wider than 16:10, but there is something less invasive that can be done to display at least 16:9 properly. https://drive.google.com/open?id=0BzKtjR7p3BXdOHRtQTBEdXBuSGM as of now the text messages and menu are not being scaled all the way to 4x in 16:9, even if the cvars accept that input. the console background also gets screwed up but that has to do with something else. i made some mockups showing how it should look using 1280x800 as a reference. for the text message you can see that there is more than enough space availabe, but the way it is being scaled is governed by some rules that should not apply when scaling to this extent. seems to me like there is an invisible frame around it that is not wide enough to fit the message at 4x, so the scaling is reduced to a number between 3 and 4. the sbar is not affected by this rule, which means the text in the tab view is scaled properly, giving you a direct comparison in image 1. the same thing is happening with the menu, only difference being that there is much less space availabe. as you can see it's still enough space to fit everything important on screen however if you were able to remove the frame restriction. proabably a good idea to change viewsize to 120 when entering the menu so the bottom of the options is more readable. the console image probem is slightly different, i think it is just being scaled according to aspect ratio when it shouldn't be, causing it to be stretched vertically. this is even worse at 4:3, where it defintely shouldn't happen since quake was designed for that aspect. quake's minimum resolution is 320*200, so 16:10, not 4:3
(320*240 won't fit inside a single dos segment, and is NOT a standard VGA resolution, you need SVGA for it, on the other hand 320*200 is _the_ VGA 256-colour mode) the conback.lmp is 320*200 as a result of this. I don't know of ANY quake engine that preserves the conback aspect correctly - not even software rendering will. the only real way to do it is via letterboxing, and even then replacementtextures will generally expect some other aspect (like 4:3). really, perfectionism here is a lost cause. you'll either need to pad (with more rendering/drawfills, or with letterboxing), or use funny sized pixels. just make sure you never consider ONLY the height nor ONLY the width. no worries, it's great to have your feedback.
I did see #2754 but I wasn't sure how much of that was caused by the first "vid_scale" implementation. For the text messages (centerprints like the "Arcane dimensions 1.5 update" one), the thing to remember is they can get quite long, like in this discussion a while ago about dealing with a long episode end message (from "Rapture"): http://celephais.net/board/view_thread.php?id=60831&start=847&end=857 I think you're right that there is an invisible frame around centerprints; since QS always uses the same scale factor regardless of the message length. Anyway I'll need to do some testing to give a proper reply. so just to double check, I should test 1280x800 with all of the scale factors set to 4x? @spike (and also baker and eric)
yeah you're right, i worded that poorly. i know it was originally designed for 16:10 and also about the dos thing. you can really only play those games at 960x600 if you're bound to a 1366x768 display, everything bigger than that will have inconsistencies of some type or another. what i meant was that 4:3 is an aspect ratio that was actually a thing in 96 in contrast to 16:9 and is supported in the original winquake options menu. it is something that should work properly since it is not an afterthought like 16:9, even if it doesn't. i don't blame quakespasm for that, but i do think it would be cool if it was the first engine to not have this shortcoming :) the thing is that displaying the console properly shouldn't be a problem, right? my mockup proves that at least from a non-programming perspective, but is it really that hard to just not have the image aspect "corrected" and leave it at 16:10? all i did was copy the console from a 1280x800 screenshot and overlay it in 1280x720 stopping at the same height, which makes it look way better. i don't get the part about considering width and height separately being a bad thing and this being a lost cause. why does the height matter here? i can understand stretching the image if the source file isn't tall enough, but it is. it would be a problem if the source was 16:9 and we had to make it fit on 16:10, cause then the height does fall short if you want to display the image fullscreen. the only "problem" i can think of is that a little bit of the top of the image can't be displayed since it will be over the top boundary of the screen, but that is not nearly as much of an eyesore as the distortion. you also don't have to look at the top of the console nearly as often as the bottom. the top not being visible is part of the console anyways as far as im concerned, like a theatre curtain that is falling down and lifting up to different heights. i agree that this is pretty hardcore perfectionism, all the devs and especially eric (since he's also acting as somewhat of a community manager) have done a fucking fantastic job with quakespasm and it is in a pretty great state as it is. but it's not perfect. feel free to tell me to stop asking if you don't care about this level of perfectionism. seriously, i can totally understand that. it's your time that is being taken up developing after all, and i really don't want to get on your nerves. i swear i'd code this all myself if i could. i am learning, but it's a slow process for me and i'm and nowhere near the level you guys are at. it would probably take me years to reach it since i just lack the deep insight into quakes and opengls inner workings as of right now. i'm sorry if i'm abusing you to code my ideas, but it's just really great to see the things i've been wishing for actually become real, even if i didn't do the dirty work myself. for me personally it's just fun and maybe almost therapeutic to get quake into a state where nothing nags you in the back of you head. even if the text and menu scaling thing is far from catastrophic from a sane point of view, having it fixed and being unable to find any visual inconsistencies just makes playing it infinitely more enjoyable to me. and i really do love quake, it's pretty damn important to me as far as games go. i just never get sick of it, especially since i got into arcane dimensions. regarding the testing, 1280x800 at 4x worked without any problems for me. i think they only scale up to 3.6 or something close to that on 1280x720 as of now. same goes for the menu. would be awesome if you did find a way to fix it, i promise i'll stop asking for any more stuff after this :P Here is a $20 CRT they are selling on EBay:
http://www.ebay.com/itm/Dell-Computer-Monitor-CRT-E773c-17-/222512283616 Then you have 4:3 CRT like when Quake came out. In the Arcane Dimensions folder, there is conback.lmp which is the console background.
You can open this in the Quake image editor fimg. https://www.quaddicted.com/files/tools/fimg_v0192.zip Edit it how you like, then save it. i think you might have skipped a few lines if you got the impression i actually want to play on 4:3. don't blame you, its a big wall of text. i'm no good at keeping it short. read #2764 if you want know what i actually wanted.
thanks for the idea with fimg though, i guess that's the manual way to do it. I just took some screenshots of extreme resolutions that maybe illustrate the reason behind the current behaviour: (it looks like the conback is just scaled to fit the window width/height exactly, then it's scrolled up).
http://i.imgur.com/k0m2LTk.png http://i.imgur.com/xiqatwK.png Also note that when you start a new game the console starts fully closed and then opens all the way up, so it would be weird if it used a different stretch factor when half open. yeah i get why it's done this way now, avoids a lot of potential problems. my idea wasn't to change the stretch factor but rather just not stretch anything at all and instead align the texture to fit the bottom of the screen and overshoot it at the top, as if it were dropped down a bit by default. stretching should only occur when it is necessary, which it is only for aspect ratios narrower than 16:10 so you don't end up with a hole dropping down from the top of the screen instead of overshooting it.
that's the way i'm gonna try to code it for myself as soon as i figure out how, but right now i think i'll stick with baker's idea. this change probably doesn't justify the effort on your part and could cause a lot of unexpected problems down the line, and i don't want you to have to deal with that because of me. you've already done a lot :) Qmaster, yeah it's sock's map, it's not released yet though. The screenshot is in QS_Spike with the r_scale cvar.
can't wait for sepulcher, that screenshot makes it look badass.
@eric i saw your name in the credits for tfuma, which is actually my favorite of the bunch in ad. it feels way more interactive than the others and is probably the best looking map using the base style ever created. giant robots are also a plus. how did you and gavin split work on that map? are you responsible for the ambush at bottom of the slime pit? :P Is there a way to get multiple transparencies to overlap properly? If I have 3 transparent brushes overlapped, the engine treats them as see through. Maybe there is a bug when the alpha sum is greater than 1.0? Using water alpha of 0.4 and *glass textures.
for a quick fix, "scr_ofsz -2" (haven't done proper testing to pick this but it seems close-ish)
We really should add a proper toggle.. I can't stand the SSG hiding completely behind the status bar. Is there any way of having QS having strafe work more like Mark_V and Winquake?
Currently the strafe value feels far too jerky. It's easy to tell the difference between QS and Mark_V/Winquake by holding forward and then hitting strafe left/right. QS seems to allow too much travel sideways when going diagonal. Proper depth peeling in quake is rare. I hope that it becomes less rare in the future :(
Has Quakespasm got original Quake movement, or has Mark V got the 'real' movement? Or none of them?
afaik the only thing QS changed is it made "always run" equivalent to holding the run key, whereas in winquake, "always run" is slightly different (I think?)
Fifth, did you have "always run" on when comparing QS/MarkV/Winquake? were you holding shift/run? I made a slight change to this in my source, allowing the player to bind capslock to commands (in this case +speed).
That way if +speed behaves differently to "always run", any differences can be mitigated by using capslock. (of course the frustrating thing with this is the console is case sensitive for most commands) I use always run.
The QS implementation is basically like holding shift to run. You are correct, using always run is a different feeling to holding shift (even in Winquake). Not sure if this is a bug. It would be nice to have an option to have this operate more like Winquake. It would be nice to have an option to have this operate more like Winquake.
Put cl_forwardspeed 400 cl_backspeed 400 I'm playing through on NM and my realm progress isn't saving, using latest version of Quakespasm. Is this a known bug?
Hi Quakespasmers. I stopped by here because someone mentioned a "Beef Thread." I didn't know there was a "Beef Thread!" So I decided to go look for it, but I stopped in here too.
I see FifthElephant is asking about the "Always Run" thing being different. I actually made a post about this on my FvF forum which goes into detail describing WHY it is that way, so I thought I would post a link here for those who are interested (especially for FifthElephant, because he is my BESTEST buddy! >:D Hi FifthElephant!) http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3776 After playing Quake for 20 years I am used to the default behaviour. Maybe it isn't in the design goal of the engine and an option wont be included.
I find strafe jumping harder in Quakespasm as the movement is too sudden and jerky. I think I may have suggested in the Mark V thread that "Always Run" could be made to have 3 different settings in the menu: OFF, ON, and ALL.
ON would be the standard old setting that doesn't affect side speed, for people who have just gotten used to that. ALL would be doubling the movement in all directions, including the side speed. Unfortunately, Mark V changed it so that "Always Run" is ON by default, using the old method that doesn't affect side speed.... I dislike that settings, but could always just ignore it -- I prefer to be able to sidestep really FAST to dodge those rockets. But changing the default so that it's ON is just awful; now I have to make extra settings just to get back to normal. (Yeah, I've complained about this in the Mark V thread already, heh.) But perhaps Quakespasm would be interested in my idea of 3 different settings for the menu option, for people who prefer it the old way. More user control is usually a good thing, even though I really, really like the way Qspasm has implemented "Always Run," with the full speed in all directions, and having the +speed key still be useful to toggle you to a slower pace. What is it with Quakespasm that makes it draw certain brush models regardless of their actual visibility - always and on the other side of the map, even from the outside. Unnecessary triple digit epoly boost.
What's going on and how can I work around the system? Check detail1.jpg from my post in the Tyrutils_ericw thread as an example: the square things in the bottom right corner. Originally, there were some columns in the back of the map as well, but I had returned them to world geometry already. Sounds like it's just the "brush model in too many leafs" fix.
Note that because QS uses VBO drawing and draw call batching poly counts aren't as relevant. that's the "flicker fix" we implemented. QS's MAX_ENT_LEAFS is 32, so I think the way it works is if an entity bbox spans more than 32 leafs, the server will make it always visible rather than potentially flicker.
Workarounds would be simplifying world geometry where the bmodel is or shrinking the bmodel. When this problem really came forward in community consciousness (http://forums.insideqc.com/viewtopic.php?p=26885#p26885) I had just recently fixed it by dynamically recalculating visibility for each client, for each entity, each frame. That was effective (it wouldn't have pulled large bmodels into the PVS all the time) but caused hugely excessive CPU load.
It turns out that in this case just drawing it anyway is a more efficient approach, at least for hardware-accelerated engines (the point I made above about r_speeds counts not being so relevant to a properly-optimized renderer can't be overstated enough).
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |