 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
|
That was faster than I expected. I haven't even finished my beer.
This is an incredible community and it showed as I got very close to getting things release quality -- tons of beta testing help with great detail, made it so I could solve remaining issues quickly! Ericw provided a key assist with something I was struggling with regarding the German keyboard. I hope Gunter (co-op server operator) sticks around sees how great this place is! I read the thread for every issue ever reported.
Might as well do everything right, even if it meant somewhere in the world, a puppy must die. Better engine coders than myself would have Quaked in fear. Me? I just wanted it to work perfect so I could finally play it ;-) And when I got it right a couple of weeks ago, I played it for 3 hours. lol If you want Mark V to be able to play everything, you can try to support that old version of Industri. The Maps are nice even if the shadows can't be supported
Great that you decided to resume working on this before next year after all! Just hoping that it isn't the end of the road yet. I am still dreaming of vanilla-style underwater warping! :P
Anyway, thanks a lot for your continued work on this port and your determination to turn it into the best way to play Quake for fans of its retro look (while still offering/allowing many nice visual enhancements)! The engine crashes for me somewhere half way through ne_ruins second level, shortly before or after obtaining the gold key (not in a specific area). I recall this issue existed in previous versions as well, since the mod demands a very specific amount of edicts or something.
Other than that, the engine seems to be really awesome, I especially appreciate the faithful software renderer with proper resolution upscaling. Thanks a lot for all the effort! In Malice, +attack doesn't move the probe. Quaskespasm has the same problem.
The probe is an inventory item, it can be found at the end of the first (tutorial) level. It works in vanilla Winquake. Co-Operative Play Example
Computer 1: - Type "install travail" (Downloads from Quaddicted) - Type "game travail; maxplayers 4; coop 1; teamplay 1; map start" Computer 2: - Type "install travail" - Type "connect lan" BOOM! Your done. And you have a per-player monster kills scoreboard. Mark V clients auto-switch gamedir and detect LAN severs. Maps without co-op spawns --- for the first 5 seconds after spawn, players are transparent and can walk through other players. Feature can be turned off via sv_coopenhancements 0. The Undergate is an example of a map without co-op spawns. @mandel if you see this thread -- dwere had an issue with cl_autodemo. Mark V now defaults it to 0, but you may need to set it manually. Mark V has had autodemo on for years and about no one had a problem with it, but nevertheless now defaults off.
@dwere - Malice. Thanks for the info. @pathogen - Mark V uses 8192 edicts. I've played ne_ruins through to the end multiple times, but not lately. Sounds like something to check out when the time comes for the next version. Unknown command "+zoom_key"
Unknown command "-zoom_key" The alias works fine in id1 and Nehahra, at least. If a mod has its own default.cfg, the alias is not created.
It was only meant to smash the horrible F11 "zoom_in" alias in original Quake that wrecks your fov and sensitivity and replace it with something very nice. /Another thing to possibly do when the time comes the next version. Baker,
I wanted to give this release a try since I see you have been on a developing frenzy. This is from someone who only used QS. First of all I love the support and auto-scaling for 3440x1440 resolution. The "Levels" selector built into the menu is really sleek. The mirror support is something really novel as well! I'd like to convince my brother to play some coop with me sometime to try it out all of the features. I am just having an issue with playing external music. I was thinking I need the same setup as QS (id1/music) but nothing plays regardless of external_music being set to 1. I have the Thanks again for your support and I think I will play around with more of the features and I may set this to my default engine. :) Mark V only supports mp3.
Mark V uses system methods to play MP3 that take advantage of hardware accelerated decoding of mp3 built into your processor. Intel processors, AMD processors, the iPhone, Android phones all provide hardware accelerated MPEG-1 decoding (mp3 is part of MPEG-1 specification). Plus the mp3 decoding patents expired in September 2015. Alright, mp3 I went ahead and grabbed the mp3s of the soundtrack and converted my two custom tracks to mp3 and there we go!
Wow, it literally is instant playback! I am used to the 2 second delay. Thank you! Demo playback and also the selector is incredible and rewind/fast-forward controls...delicious! I'm glad you are enjoying it, I put my all into trying to get it from beta quality to release quality, not easy considering the feature set that I wanted.
/Mirrors aren't novel if someone sets up an angled mirror and an observant player notices a secret item or X to shoot. ;-) It may be why Mark V can stop/pause/restart music instantly and engines using a software decoding library cannot.
Baker,
You are right about the mirrors haha...I like that idea! You did well with this release, I am really happy with the features when comparing to my other default engine of choice. Underwater (slime, lava as well) is very clear and has barely a tint to it. I see that you could alter the percentage via r_watercolor but if I change the number it just becomes completely clear. I did a search on the older Mark V thread and saw Gunter discussing it but I did not see a solution. :O Mark V default blends should be same as Quake.
In the menu there is an option to set them to light or normal. You should probably do resetcvar r_watercolor because changing that isn't something so easy to do. /Changing the number requires 4 numbers, red green blue alpha. It is sort of an advanced feature for a mod that wants different underwater colors. Wow, right there in the menu I had set to lite for whatever reason...yeah Quake default setting looks perfect.
I also performed the reset as well. Thanks, I think that should keep me quiet for now! On a side note, the tool_inspector is amazingly helpful for mapping! http://www.quaketastic.com/files/screen_shots/mark_v_0000.png I also made the screenshots PNG, you noticed.
That way you can instantly post them without mucking around with opening a graphics editor or such. If you want to do something fun, do this
Install DivX/XVid codec pack download page 1) Record a demo ("record mydemo") 2) Type capturevideo_console 0 (prevents console from being captured) 3) Type "capturedemo mydemo" 4) Type "folder" Upload your video to YouTube. (*) Link to codec pack is now http://quakeone.com/markv page too. Oh yes I did notice the native PNG, that is a nice quality of life change!
When I enter capturedemo, Mark V crashes. I can see that it makes an incomplete I have the codec installed, so not sure! :O Could you enter "capturevideo_codec divx" before doing capturedemo and see if the problem remains.
I use capturedemo all the time, this will allow me to determine if the automatic codec selector is the source of issue. Mark V download has been updated
(New update shows build 1000 when "version" is typed in the console). Changes: 1) Increased max model vertexes/triangles to match Ben Jardrup's Enhanced GLQuake/WinQuake limits of 3984 and 4096 to support more replacement model content. (Gebloner) (The vertex limit is the highest number possible for WinQuake asm according to a comment in that engine. Both of these limits are about 2x the old ones.) 2) Fixed loadgame issue when demo playing (zbikey) 3) +zoom_key always available now. (dwere) 4) "capturedemo" to AVI video should be fixed. (Bloughsburgh) Extra files: The Mark V page site now has extra downloads on it. 1) DivX/Xvid Codec Pack link for video capture (the capturedemo command) for compressed AVI video. 2) Frogbots -- truly awesome bots and has support for 120+ maps due to incorporating code Trinca wrote. 3) Correct Nehahra fmod.dll for xm music (2004 date). The Quaddicted Nehahra 3) Color lights and transparent water (.lit/.vis) files for Quake and Mission Pack maps assembled by NightFright. The Mark V has automatic detection of transparent water in maps so releases like Travail -- with no transparent water -- render nicely regardless of r_wateralpha setting. --------- @Bloughsburgh A lot of driving games, and the new duke 3d port on steam, have a re-wind feature. So instead of saving the game you just rewind to a 'safe' point... I'm always forgetting to save and I hate starting from the beginning
Mark V can already help with the "Oh no! I forgot to save situation"
If you die and forgot to save, type: 1) load a0 2) load a1 3) load a2 Wrote feature because one time died 2/3 through a great map in one of the early mapjams and it took me 45 minutes to get to that point. (sv_autosave - defaults on for precisely this reason) /Admitted the rewind back into demo and play it would be cool. I can think of ways it might be possible to write such a feature (inserting savegame info into the demo occasionally -- perhaps in a way a non-supporting engine would just ignore). Maybe at some future time I might think of a way to design such a thing. about the a0-2 save situation... Would be nice to have some kind of option in the load menu for this? :)
There's a small typo on the Quakeone page (http://quakeone.com/markv/). If you'd care to fix it, it's as follows.
"Spike solved added BSP2 to Mark V" Remove solved. --- Thanks to everyone for the effort put into the engine, coding, testing, extras and so on. I appreciate your work very much. Nice 90's vibe.
Hey why does Spike and NightFright get capitalization but others like Fifth, Gunter and Qmaster don't. Just nit picking. And Fifth is missing his Elephant. Love all the new features. Will have to use this for coop sessions from now on. You are on the ball baker!
Capturedemo works as expected with the exception of two things: 1) There is no music recorded (Due to how mp3s are read from the game maybe? Not a bug? 2) I just get the sounds of the demo and no video but a black screen. No idea if this has crossed the border of a "It's on my side" issue. https://www.youtube.com/watch?v=kmFG5pkcBAk&feature=youtu.be Hey why does Spike and NightFright get capitalization but others like Fifth, Gunter and Qmaster don't.
I've always given my name without caps, here and elsewhere. Bugtester names are case-sensitive, just like function names!
Since we're moving to a new page, I'm gonna transplant a few items of feedback/wishlists which still apply for me (some recent and some from the past) to this new page. And I'll throw in some new things to be thorough! Old feedback page, as reference for those who didn't come here from there: http://www.celephais.net/board/view_thread.php?id=60831 Baker, bolt1.mdl is still in the noshadow list.... Just delete it. it doesn't exist in Quake. I've been reporting this issue since March 2014 :D Ya know, I think you should stick all the Windows downloads into a single zip file (GL, Win, and DX). That would just seem more convenient for everyone (you only have to make one zip, and we only have to DL one zip). I think pq_download_http_locs should default to OFF. The other auto-downloads are things that are automatically used by quake, like maps, models, sounds, vis files (er, does it automatically DL vis files? It should do that, and maybe colored lit files too!) -- all those things will automatically enhance Quake. But loc files won't do anything unless people actually want to set up the binds to make use of them, so for the majority of people, you're just downloading files that aren't wanted/needed and probably won't ever be used (in my case anyway -- of course, I'm disabling them now, but I still think this one should default OFF). +zoom_key -- I think you are setting the sensitivity too low when this is used. 1/10th standard sensitivity seems better (10%). Looks like you're using 6.25% Do any other users have an opinion on the sensitivity? There's an issue with the Winquake version if you run in a window with the vertical resolution set the same as your screen height. Like if I run in an 800 x 600 window on my 1024 x 600 netbook. The HUD is chopped off at the bottom of the screen. Setting alpha by an FTE has a nice feature when you are in the menu and the focus in on either the "brightness" or "contrast" slider, the "menu background darkening" of your game screen goes away. It's much easier to adjust your screen values when you can see the results as you adjust, instead of having to adjust, then exit the menu to see the actual results. When you switch a gamedir, it really should exec the autoexec.cfg file found therein. Those only run when you first start Quake, from whatever -game you have set. But if you change "game blah" in the console, then it will never get executed. And an autoexec in a gamedir generally contains the binds just for that mod which will need to be set. I would like to be able to bind a key to turn off skyboxes, but you can't bind something with "" in it (so no key can be bound to: sky ""). Perhaps a different command to disable skyboxes would be better, maybe even sky '' or anything that can be bound to a key. Or a whole new command: nosky, or skyoff.... I've mentioend before I have a modified DM6. Mark V does not apply the usual custom textures to it, but Quakespasm does.... The texture names should all be the same. Oh, you still need to have a name change not be committed until the setup screen is exited. Old page #1221 I will re-mention.... I feel "always run" should not default to ON. Standard Quake default is OFF, and the setting is flawed for reasons I explained on old page #1154. So, ya know, either use defaults or don't in this case: 1. Leave the default (flawed) behavior for "always run" but also leave the default of leaving it OFF. 2. Change the default to having it ON, but also change the default to fix the flawed behavior (like Quakespasm did -- preferred option in my view). Joystick support was disabled at some point. #1352 for more interesting control options (even for keyboard). A separate console variable to adjust ring (etc.) blends might be useful for fine-tuning. Possible shadow hack improvement: don't draw a shadow if the entity is more than like 100 units away. That is one of the weird things about shadows. Which I know are a "hack" to begin with.... How about that multi-layer sky with transparent standard quake clouds in front of a skybox? Old page #1321 (screenshot) fullbright textures getting ugly when contrast is applied. Just have contrast not affect them? Texture gamma option doesn't address this issue, it seems. Oh yeah, I request removal of your anti-z-fighting hack, since it interferes with my own anti-z-fighting hack mod-side, heh. I discussed it on old page #1367 That type of moving entities around in the map should really be left at default so modders can take care of it :D Anyway, Keep up the great work! By the way, as you may know, I promote the use of Mark V for playing FvF. People who I have gotten to try it have really liked it.
Even after installing all the custom textures, lights, etc, one player said: "I really like this. It still looks like Quake, but nicer." I think that sums up the appeal for me as well -- it doesn't mess with the heart of Quake by drastically altering the look, feel, or behavior, but it subtly enhances things in just the right places. It's still standard Quake, but nicer! @gunter - Sure there is no bolt1.mdl, but if someone makes a mod with one then they don't have to add it to the r_noshadow_list
re zoom_key, window If you put your textures in, say, "c:quakehd" instead of quakeid1 and set "hdfolder hd" it will apply the textures to your custom dm6, the current method prevents the textures for start.bsp (id1) being applied to a different start.bsp (Like Travails) so it is working by design. quake.rc - apparently you haven't seen enough quake.rc files. Warpspsasm's quake.rc sets developer 1 in it, Zendar's actually sets a video mode, some of the old Quake mods set highly inappropriate things. Nothing can type "exec quake.rc" yourself. I've read the rest of the list before. It may or may not mean anything if I do or don't do something. My focus has been mainly on getting known issues resolved. @ Qmaster -- I think I used the first word in the sentence theory of capitalization ;-) @primal -- Hey primal, I assume you are the modelling Primal that I know ;-) Yeah I fixed that immediately when you posted. @bloughsburg
Are you using a crazy big resolution when doing capture demo like 3500 x 1400 or something? I don't know if there is a Windows resolution size limit involved. Also mp3 music, since it is being played in Mark V externally isn't captured because it isn't part of the Mark V window's sound. @anyone else willing to do a quick test Could someone else install this codec pack and do "capturedemo demo1" with a reasonable resolution and confirm that the AVI capture works properly? I believe it works properly in the general case, it does on mine -- but I need confirmation from others. When Nightfright and I were testing around the time the feature was written, both of us found it annoying for autosaves to be shown in the save game menu.
Benefit for being a beta tester or reading the thread I guess ;-) I see the thread but I don't recall having opinions on the autodemo feature. Had to check the old thread to remind myself. Thanks.
About someone else doing the capturedemo test.
I attempted with 640x480 and same deal. :O Baker, another possible link for the Files section would be this map pack that contains (almost) all of the maps that Frogbot supports: http://eclecticmenagerie.com/jl/quake/bots/FrogbotMapPack.zip
(That's for Trinca's build 379 of the QW bots, I'm assuming your NQ version has a similar map set.) Download size is about 100 MB. @johnny -- Great download! Added.
@mandel - Once had stated you were getting inconsistent performance in Mark V when you tried it when it was beta, just pointing out that dwere experienced that as well and setting cl_autodemo 0 solved his issue. Made autodemo disabled by default. Just wanted you to be aware of it. @Six-Shoota - Eventually alpha masked support will happen in the WinQuake build. It's very hard to do because the code is like a maze-like. I've tried a few times before. Eventually I'll give it another try. ------------------ Still need a volunteer to test out demo to AVI movie by doing capturedemo demo1 after installing a codec pack download site Works fine for me, Bloughsburgh = black AVI with sound. We're trying to determine why it doesn't work on his machine but it does mine. Could you try this
capturevideo_codec xvid capturedemo demo1 I have an odd suspicion explicitly setting that codec might work. Frogbot map support was hardcoded into the QuakeC by Trinca, I don't really know how it works. But it is hardcoded into it.
Ah, I hadn't noticed that reply in the old thread.
"aliases" in console is an unknown command. But I did "alias +zoom_key" to get the information. I see some tools I did not know about in there... valsave and mul. Neeeeeeeeat. And I don't need a whole "exec quake.rc" -- just an "exec autoexec.cfg" which is a user-controlled file. Uhh, when I was just going to look at the textures in DM6, I got that weird crash that Dr. Watson says is an access violation. I had not changed anything yet, and I was just using the standard id1 stuff, so it wasn't even my modified DM6. You can see in the qconsole log that I had checked the values of developer and cl_autodemo, and they were both set, but I am not getting any autodemos. I've tested some more after that, and I am just not getting any autodemos.... They aren't appearing in id1 nor in my fvf folder when I run fvf. Though I don't think they would have revealed anything about the crash anyway.... Here's the log file (I just started DX version in a window, started a single player game, then tried to switch to DM6 -- I THINK the same thing had happened to me earlier but that time I think I had started a new multiplayer game instead): http://fvfonline.com/qconsole.log.txt I can't reliably repeat the big. I go through the exact same steps again, and it loads fine.... Oh, and autodemos definitely used to work for me, before you disabled them by default. I went in and made sure to delete my previous autodemos in anticipation of recording the crash happening.
re: quake.rc - just an "exec autoexec.cfg"
You haven't seen enough mods. A number of single player mods come with an autoexec.cfg, even though they shouldn't (one example among many, Once Up Atrocity And they often contain things they should not. Example gl_flashblend 0 r_shadows 0 scr_centertime 4 scr_printspeed 16 r_wateralpha 0.6 gl_subdivide_size 1024 r_maxsurfs 900 r_maxedges 2800 re: DX8 crash that occasionally occurs cl_autodemo 1 needs host_maxfps set to 72 -- otherwise it won't record because the demo size could be massive and 72 fps is only correct Quake physics in single player. (todo: document that) But yeah, I'd need the autodemo. Console log doesn't help. Still black video after setting xvid as the codec.
Here is what I am doing now to test: -I made a quick 20 second demo called test. -I run Mark V, capturedemo test It runs the xvid encoder window, once it is finished Mark V tells me so. I exit the game, check the created I am running at 640x480 for this test. I'll do some testing on a variety of different machines sometime this week. And we'll see what turns up!
re: DX8 crash under certain conditions
However, I looked at your console log and filling in my imagination with knowing your preferences I have successfully recreated the crash I believe you are experiencing with the DX8 version twice. /We'll see what's up. Ok, but what is the problem with having "things they should not" in the autoexec for a mod? If you ran the mod the standard way with -game mod, it would all happen.... and it will only apply to that mod, right? It's not going to alter your config files in id1 or anywhere else, is it?
If the mod author wants you to have weird settings when running his mod, and he includes an autoexec with those settings, what's the real problem? That's been a standard way of doing it for a long time. Alternately, you have to do a bunch of stuffcmds in the mod itself... but many mods don't do that, since the autoexec is easier. Heck, the good old Blabalicious Quake movie uses an autoexec.cfg to adjust your screen settings and start the demo playing. Or maybe the mod creator included vispatched maps, and he wants you to be able to see through the water, so he included r_wateralpha But by using the "game mymod" command in the console, now the player will not have the mod-specific settings applied, so he probably won't be seeing the mod as the author intended (hope there aren't any important buttons hidden in shallow water...). And Blahbalicious won't play, heh. For players who just have different keyboard configurations for different mods, they also expect the autoexec to run automatically for each different mod. I'm just wondering why anyone would ever NOT want to do so? If for some reason they don't, they just do the default Quake thing of deleting the autoexec, or modifying it to their liking. I guess I should just say that "game blah" should mimic the default Quake behavior of "-game blah" Strange things happen if you noclip out of the level that has mirrors: fps drops, you see a reflection of player in different places and some pieces of level.
There's an issue with the Winquake version if you run in a window with the vertical resolution set the same as your screen height. Like if I run in an 800 x 600 window on my 1024 x 600 netbook. The HUD is chopped off at the bottom of the screen.
Something has crossed my mind about this: it feels like it should be normal Windows behavior. I never play in windowed mode so I'm not sure but it seems logical to me that setting a specific window resolution should work for the CONTENTS of the window, not for the window itself (that is, not counting the window's borders). If this is how Windows work, then it makes sense to have the bottom of the window chopped off. Is there a Windows expert around to confirm this? Some mods come with autoexecs in their PAK files. At that stage it's no longer possible for the user to control their own settings.
The intention of Quake is clear: default.cfg is for the mod defaults, config.cfg is for user-configurable stuff that is saved, autoexec.cfg is an override to both and can also contain stuff that's not saved. Mod authors have in the past enforced their own preferences on users. You see video modes, key bindings, look-and-feel settings, all enforced in ways that users cannot control and on occasion even freely admitted as intentional by the author. Not running the cfgs is an unfortunate compromise but seems the only sane thing to do. Mods using autoexec.cfg to store their settings is only somewhat standart-ish because some mod developers aren't aware of this file's real purpose. This is player's territory.
If you need to force something in your mod, modifying quake.rc is a much better option. With this in mind, executing only autoexec.cfg is very selective. It's not even supposed to be the most important part of the settings, even if sometimes it is. As for whether to execute things when changing the game dir mid-session, I think it only makes sense for the behavior to be consistent with what's going on during startup. If the settings are questionable - well, blame the mod author(s). The chosen resolution in windowed modes is for what's called the client area of the window, in other words excluding the title bar and borders. Quake on startup calls AdjustWindowRect to add on the size of the title bar and borders, getting the actual window size.
This has been the behaviour of WinQuake and GLQuake from the beginning and is expected behaviour. So Quake is just doing what you asked it to do: Create a window with a client area of 600 high, which will get another 30 to 40 or so pixels added after AdjustWindowRect, which will then push the status bar off screen. The solution is to ask it for a smaller window. MH for the win. Read his post carefully. Some mods come with autoexec.cfg in pak files and such.
Mod authors almost never intentionally did wrong things, they only sought to provide a good user experience for their mod. Nonetheless, there are toxic quake.rc and autoexec.cfg files out there. And playing single player release with the player in control of his settings is #1 for Mark V. ----------- @ Gunter I'll soon be updating the version to build #1001 --- I believe will fix your DX8 issue. It only happened when a dynamic light was active, some lightmap fields needed cleared on map change. The DX8 wrapper reacted very negatively without those fields cleared. You're still executing these "toxic" settings during startup. So I'm not sure what's being achieved here.
after disabling smoothing in the preferences and restarting the game, lerp reverts to default though smoothstairs remains off. Currently using lerpmodels/move 0 in an autoxec as a workaround (which is fine, since I want smoothstairs on, anyway).
Really sweet port, getting my retro fix! anyway to disable/adjust mips in the winquake fork? Using pixel quadrupling and the next mip level gets drawn when you're pretty close to the surface; it's a tad ugly/jarring.
again, minor gripes. I really am enjoying this port :D Addressed that in upcoming build.
@dwere -- If I want to play something, I start up Quake and do "game warpspasm -quoth". And then start playing @killpixel +10. And just at the right time too! I understand what you say. I implemented what was easiest to do for approximate scaling solution in WinQuake build (stretch).
But yeah, I'd like to have full resolution pixels + scaled 320x240 or 640x480 HUD/Menu at same time --- but would take 3 weeks to write so /But notice it is separate option from GL Build automatic HUD scaling. Tells you I feel how you feel. Yeah, just as dwere said, I was going to point out that you are still running those files when mods are started by the standard, age-old method of "-game blah."
If a mod mod comes with an autoexec, generally it is is "part of the mod" that should be ran for the mod to function (as the author wanted). Of course, there can be "bad behaviors" from this, but any part of a mod is subject to such problems. Though I suppose true "player in control of his settings" would allow a player to choose if he WANTS to disable the default Quake behavior of running an autoexec.cfg when starting a mod.... Build 1001
Same place as usual 1) DX8 build intermittent crash due to dynamic lights fixed (gunter) 2) Mirrors + noclip outside world slow fix (pulsar) 3) r_lerpmove/r_lerpmodels preference now saves (killpixel) /Typing "version" in the console will show as build 1001. ... maybe in the future.
Looking forward to it (maybe). In the meantime, this will do just fine! But yeah, I'd like to have full resolution pixels + scaled 320x240 or 640x480 HUD/Menu at same time --- but would take 3 weeks to write so Actually, I use the scaling because I like the look, not because I need larger hud/menu. Though, controlling those independently would be nice. On that note, perhaps you could clarify something: I noticed that scaled pixels are square, meaning they aren't stretched to a different aspect ratio. So, when choosing scaling (320x240 or 640x480) it uses a constrained resolution/ratio that is closest to those listed resolutions? In other words, when using a 1920x180 display, your effective resolution when using scaling is 960x540 or 480x270? If this is the case, maybe it would be more clear to list the option as pixel doubling/quadrupling? Ok, no more nitpicking, I feel like I'm sending the wrong message. I'm off to play pixel quake... It was called vid_stretch in WinQuake so that's what I went with as the name. It finds the best multiple that comes closet to either 320x240 or 640x480
Though I suppose true "player in control of his settings" would allow a player to choose if he WANTS to disable the default Quake behavior of running an autoexec.cfg when starting a mod....
Well, technically, you're in control now. You can "game gamedir" without executing anything, or you can "game gamedir" and then "exec quake.rc" after that. Or "exec autoexec.cfg" if you know for sure that all you need is there. Executing quake.rc has a side effect of stuffcmds. Typical my you can divide Quake players into two broad categories: Those who know the inner workings of the game, and those who don't.
Those who know might start the game with command-line options, load new games with -game via batch files, and - crucially - will also have sufficient knowledge to deal with a rogue Those who don't, won't. There are more of the latter than the former, and this stuff is a barrier to entry. Hit one of those people with a rogue This isn't theoretical talk either. These are real problems that real people face. Have a look at the QuakeOne or Steam or Bethesda forums - there are people who have trouble getting an engine or mod into the right directory. These people are why the Quake Injector exists, they're why people like Spirit goes nuts if a mod is released with configs, and they're why unfortunate behaviours like not execcing configs on a game change exist too. I would love to see it happen too. But because of rogue configs, having it not happen is the lesser evil. After all: You are not representative of the typical Quake player. Here are a few more
LIT/VIS for Abyss of Pandemonium, Malice & Shrak (ZIP, 16.6 MB) LIT/VIS for Dimension of the Past, Nehahra & Travail (ZIP, 23.7 MB) May they serve you well while exploring the power of Mark V! It seems "window02_1" defaulted as being a mirrored texture?
IIRC that's leftover from Carmack's original glquake as a hack to play with mirrored surfaces, but maybe shouldn't still be in the engine? I mean, if we're going to just have "mirror_" be an identifier for mirrors, maybe just stick with just those and not also include a separate other texture Carmack picked long ago. Yeah, defaulted as an homage to the original GLQuake release (0.95? 0.98? I can't recall which one.).
You can turn it off. Set r_texprefix_mirror "" and it's done. Now that I think of it, that needs to save to config so someone can turn it off. As far as I can see, only the stained glass window in the intro map will turn into a mirror automatically. I dunno how to change the other windows.
A potential feature request: In the old Mark V thread, Baker mentioned a setmusic.cfg which allows music tracks to be remapped. I was wondering if it could be enhanced so that it also works for specific maps, like setmusic <map name> <track name>. Why I am asking for this: There are some addons in which authors erroneously use track01 in their levels (which doesn't exist). With an external cfg file which is automatically parsed, it would be possible to fix such glitches without having to mess with the map files. (There are more ways to use this, just pointing out one of them.) Throwing this out here, not sure if it is a thing or not.
Sound seems to have noisy feedback on louder noises (Grenade, lots of monsters attacking at once.) I thought this was from the audio set at 11k (I realize that may be Quake default) but is there a way to change it? I tried changing sndspeed to 41k and it sounded like the audio matched what QS detects but it just sounds more hollow. I'm more really asking because QS does not have this audio noise issue whatsoever. There are some addons in which authors erroneously use track01 in their levels (which doesn't exist). With an external cfg file which is automatically parsed, it would be possible to fix such glitches without having to mess with the map files.
... then it would always play the same track since all maps are set to track01. What I would want is to make all maps use different tracks...
I know an Arcane Dimensions map built by a very handsome young lad that has random mirrors in it now because of the feature "texures specifically named 'mirror_*' are mirrors... and arbitrarily 'window02_1' as well"
I'll just recompile the damn thing with the texture renamed I guess. oh, in less salty feedback on mirrors, may want to consider doing some sort of fade effect when a mirror becomes active? The pop in when it switches between mirrored and non-mirrored can be quite noticeable.
@Bloughsburgh
I'm glad you pointed this out, I was beginning to doubt my own ears. There definitely is a kind of audio problem, a crackling like sound that you described. Quakespasm is fine now but had the exact same problem a couple of years ago, very annoying. Of course I'm almost always going to push for keeping Quake's default behavior when that behavior isn't flawed, and in this case it is not -- it's just some mods that can be "flawed." Though you have to realize, the whole concept of running a mod is that you are handing over control to the modder to change a lot of default things.... But yeah, placing an autoexec in a pak file is really bad form, but how many mods is this actually an issue with?
In any case, I think as a minimum (mainly for "those who don't know the workings of Quake"), changing game directories should produce the same reminder text that Quakespasm does: 'enter "exec quake.rc" to load new configs.' Mh had actually already pointed out some options regarding how to pull off the original underwater warping effect in the old Mark V thread back in 2012.
I dunno if all of his suggestions turned out to be impossible to implement, but maybe they deserve a second look. (I know, I am kinda nagging with this, but it's one of the very few things that Mark V could still do better. :P) if switching gamedirs results in a different quake.rc, default.cfg, config.cfg, or autoexec.cfg file, then save the config, then (effectively) switch the gamedir, reset all cvars to their defaults and exec the new quake.rc. when saving configs always save to the same location as the shallowest of those 4 files.
mods that fuck up your config to enable things that increase sw-rendering capacities will still apply for the new gamedir, but will not be able to affect other gamedirs any more thanks to the reset thing. the mod will still pick up your normal config.cfg the first time you run it, but thanks to it declaring itself as a special snowflake, further changes to your regular config.cfg won't continue to impact it, and vice versa. if a mod wants/needs to be special, let it. and if its just a map pack then it really shouldn't need to have its own config file either. that's how fte handles it, except without the auto-saving-your-config part, because that's considered an explicit action in most quakeworld engines. that said there are still some things that I could improve... like userinfo changes spamming the server. :s https://twitter.com/tonycoculuzzi/status/800311323040976896
I want to see what mankrip and spike can do with this effect =D Serious Sam did that well, I really enjoy that effect.
I think killpixel was showing some of that type of stuff in the screenshot thread? Yes.
@Baker "cl_autodemo 1 needs host_maxfps set to 72 -- otherwise it won't record because the demo size could be massive and 72 fps is only correct Quake physics in single player. (todo: document that)" But what would be the problem if you have a lower FPS set, as I do (and probably anyone else who uses vid_vsync)? Sure, physics might be wonky in Single Player, but... that's not exactly a reason to prevent autodemos if the user wants them, at a lower FPS. I'm playing with zoom aliases now. I think r_viewmodel_fov should default to 0 (standard Quake behavior) rather than 90. Yeah, it improves the look if someone sets a higher fov, but it makes it look weird when you zoom in with a lower fov. Standard Quake is the opposite, looking correct when you zoom in but bad when you set a high fov. So, I prefer standard Quake behavior, especially when I have set "weapon draw = quake default" in the menu. An optimal way to do this might be to have 2 separate variables: r_viewmodel_fov_min r_viewmodel_fov_max Then you could set the max at 90 to never get the weird effect when zoomed out, but the viewmodel would still be allowed to be pulled back when you zoom in (which looks correct).. unless you wanted to clamp that too with the min setting to not go below. I'll make the cvar that control "window02_1" only apply to the id1 folder.
I'm hardcore and already had realized that even as a setting it would default on for people using -game. I know which mappers reside in Asgard and know you are one of them, I've read this site regularly and know, for example, you used to run the speed mapping session.
Let me assure you that if for instance that if you have something to say, I am always listening. I'm a very conservative engine developer despite also adding player-oriented features. When I started engine coding, Ben Jardrup helped me several times and would explain the compatibility mindset to me. I'm quite interested in why the framerate changes the physics. I wonder if it is the physics stuff being calculated every frame, rather than every 1/72nd of a second.
If that is the case is it worth trying to keep the framerate at a multiple of 72 to be safe? (144 if your monitor can do it). autodemo -- pulsar, I'll spend some time thinking about right way to handle to.
sound 44000 - bloughsburg, I remember some of the sound mixing discussions about that. I'm adding that to my list and will eventually happen. @fifth - Not sure what you are wanting. Quake physics are still 72 fps and although fps independent physics is on my eventual to-do list. If you set 144 hz in your video card and vid_vsync 1 and host_maxfps 144 in the console, do things work as expected? @gunter - at a higher fps, the demo files could become huge. Maybe make cl_autodemo 2 option -- record an autodemo regardless of the fps. gun fov 90 -- people love the feature, you know how to disable it. @nightfright - at least for now, Mark V is a pure Open GL 1.2 engine for maximum hardware compatibility for any machine Windows XP or higher. MH needed a glsl for that in Remake Quake engine. The track by mapname thing, I will think about and have an idea on a "correct solution" which would give you the same ability to control it but does not work in a way similar to what to you suggest, but I would need to put some thought into it so is more likely a future version item. @nightfright part 2 --- I'd recommend creating a Wiki page at https://quakewiki.org/wiki/Main_Page listing extra replacement content paks and I'll put a link to that page on the Mark V page -- that way if new content becomes available it can be updated and available to users without me continually editing the Mark V homepage. Be sure to upload mod enhancements to Quaketastic (see Func screenshots thread for username, password if you don't already know) beause Quaketastic files are preserved forever at the Amazon/Government funded archive.org site (!!) /I think that's most of the replies, I read Spike's thoughts on gamedir change and @snaut yeah that's cool. I've always thought that the engine ought to be able to cap the framerate of the demo independently of the actual client framerate -- When I recorded demos for rubicon 2 I intentionally set host_maxfps really low to get a smaller demo file, but it would be nice if it was an automatic feature.
But, I never did the research into what kind of problems would have to be dealt with to make the demo playback correctly. For example obviously the dropped frames might have important events in them, you'd need to save them and put them in the next demo frame so they are not lost. Spike actually has a separate thread (or similar) in FTE to ensure 72 fps even if the client goes under 72 fps.
In 2014, I made a run at acquiring DirectQ's fps independent framerate, but noticed a little jerk in DirectQ when using +turnleft and +forward at same time -- so I moved it to the back of the queue for future consideration. I suspect Spike might suggest that the best to get such a result might be having the "server" record the demo instead of the "client" --- in a properly client/server separated engine (like how the Quakeworld engines have complete client/server separation).
two things:
1) use a decent network protocol that doesn't resend everything every single packet. get AD's particles under control by harassing sock into using clientside stuff instead of network abuse. 2) screw threads, just don't send packets to the server quite so often. from what I remember the only real challenge is figuring out how to deal with impulse;wait;impulse scripts. one way is to just not wake up from waits while connected with an impulse still pending. obviously if there's any hacks internally directly linking both client+server then you'll need to fix them, otherwise independant rendering/server isn't really any different from a public server or demo. drop the server's rate to 10hz and you'll get quake2! Yes to all of that ;-)
Btw, offhand do you know about about the bloughsburg/zbikey sound crackle @ 44 hz. I don't touch the sound mixer often -- and such a conversation wasn't recent so I can't recall the details immediatelly. Is that the true hz is 48k issue? @spike also -- while I'm thinking about this -- your single port rewire of reading messages -- I haven't investigated so is probably non-issue, but in my head I was thinking "make sure that can't skip a player impulse". I think QSS queues up +jump and such.
/Again, haven't had time to focused on deep examination of that, so quite possible I'd see something obvious that I'm not thinking of at the moment. I have no audio crackling / distortion, everything sounds fine for me.
Those who are having glitched audio, might help track down the problem if you type 'condump', and paste this section from your id1/condump.txt: Sound Initialization Set primary sound buffer format: yes Using secondary sound buffer 2 channel(s) 16 bits/sample 11025 bytes/sec DirectSound initialized Audio: 16 bit, stereo, 11025 Hz Sound sampling rate: 11025 Also - congrats on the release, Baker :) qss's single-socket stuff just switches from looping through each connection and then handling the messages to checking the socket(s - ipv4+ipv6+ipx) and then parsing them within the context of the player with the same remote address.
there's no extra buffering there that wasn't already there, certainly not in the client-side stuff. inputs are handled the same way as they always were. if you're getting crackles mid-sound then rewrite your resampler. resampling 44->48khz will probably screw up the waveform if you have 44khz frequencies. most people can't hear those anyway. be aware that the vanilla resampler uses 'nearest filtering', which has somewhat obvious deficiencies... on the other hand, pops when you override another sound could be fixed with a gradual fade-out instead of suddenly dropping down to 0. Count me as another person who is very glad this release happened, and it happened now instead of later in 2017!
"gun fov 90 -- people love the feature" Well, people love lots of things, but that doesn't mean Quake's default should change, heh. I mean, lots of people probably love r_viewmodel_ring 1, but it's defaulted off.... From looking at the old thread, the people who are using r_viewmodel_fov are not using your default value anyway.... They are using 110 or 130. And of course, they are using it when setting a higher fov. It's good for that. I like it for that too. Too bad it doesn't work ONLY for that.... Lower fov's make it weird. So yeah, I'll disable it. I have a section in my fitzquake.cfg file for "Restore Quake Defaults." The section is actually not too long (about 7 behaviors), which is a very good thing. But I'd be more happy if it was completely unnecessary to restore any Quake defaults! Now, it's not always bad to change a default, but you have to be certain there is definitely no negative impact from the change. For example, I couldn't see any negative impact of defaulting r_viewmodel_ring 1. It's a cool setting, and everyone should use it... but I would never actually argue for making it a default... because it's not Quake's default! Heh. But of course, I would't mind if it was made default either, unless some unforeseen negative impact arose. Of course, sometimes the "negative impact" is simply that it doesn't look the way people are used to, and they don't like that... sooo... in the end (as you say), you gotta be really conservative about changing defaults. Err on the side of caution. In this engine, one thing I've tried to do is absorb as much of the feature set from other engines with great contributions that aren't developed any longer like Enhanced GLQuake/WinQuake, ProQuake, JoeQuake.
But it is currently lacking one of the most prominent features of JoeQuake as an option (will off by default), which are the optional particle effects system (QMB particle system by Dr. Labman). It'll need some rigorous testing when it's available in a few hours. Here you go! This is with me changing sndspeed to 44100
Sound Initialization Set primary sound buffer format: yes Using secondary sound buffer 2 channel(s) 16 bits/sample 44100 bytes/sec DirectSound initialized Audio: 16 bit, stereo, 44100 Hz Sound sampling rate: 44100 Oops, and here is QS:
Sound Initialization SDL audio spec : 44100 Hz, 1024 samples, 2 channels SDL audio driver: dsound, 65536 bytes buffer Audio: 16 bit, stereo, 44100 Hz I'm just going off current memory.
ProQuake + JoeQuake in Mark V ------------------ 1) Ping in scoreboard. 2) ProQuake enhanced client 3) ProQuake enhanced server *limited* to Spiked Quakespasm levels due to acquiring QSS single port server capability. 4) ProQuake 16-bit aim available under protocol 15. (Spiked Quakespasm has this too). ProQuake -------- 1) Mark V downloads depot http download missing maps, sounds, models when connected to ProQuake or DarkPlaces server, but not when a Mark V server or Spiked Quakespasm server. (* because Mark V is likely to have in the future peer-to-peer TCP/IP transfer of "gamepacks" -- think "travail.zip" due to conversations with Spike on how to do download right. On a LAN in particular, transferring "travail.zip" (83 MB) happens in the blink of an eye. Since Spike has already written And has all other ProQuake features except 2) Does not have ProQuake iplogging (check to see someone if someone is imposter). Not compatible with IPv6. 3) Cannot run ProQuake QCCX mods. 4) Typing matrix in console displays a Matrix movie full screen character effect. JoeQuake -------- 1) Mark V has 2) Mark V Has scr_showspeed - display speed on screen. 3) Will have QMB particle system tonight 4) Doesn't have cl_bobbing (items can bounce up and down) Enhanced GLQuake/WinQuake ------------------------- 1) Mark V should be able to play Q-Rally with sv_gameplayfix_setmodelrealbox 0. Maybe other rare (Spike says poorly coded) old stuff that needs it. 2) Mark V can read protocol 10002, allowing Mark V to play Warpspasm start demos. 3) Mark V, developer 2 displays extra warnings from that engine. 4) Mark V does not support 32 or 64 player scoreboard. 5) Mark V does support sprite32, even in WinQuake version. 6) Obv, Mark V can play Nehahra. 7) Mark V, unlike other FitzQuake forks except Spiked Quakespasm, can serve protocol 15 game. I really like the manipulation of console variables via mul, valsave, valload....
Here are my newly Mark V-enhanced zoom aliases, for anyone who wants to try them. The mouse wheel zoom is my favorite -- you can zoom in and out to different levels (even out to chase mode) with the mouse wheel. I've used it for a long time, but now it is better due to being able to save any fov before messing with it, and use math to change the sensitivity. If someone wanted to expand on this, you could make even more zoom steps, or even more zoom steps backward in chase mode with chase_back values. (to use these, you'd want to paste them in a // mouse wheel zoom alias zoom_out_full "mul sensitivity 2; bind mwheelup zoom_in_half; bind mwheeldown zoom_back; fov 50;wait;fov 70;wait;valload fov 1" alias zoom_out_half "mul sensitivity 2; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; fov 20;wait;fov 30" alias zoom_in_half "mul sensitivity 0.5; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; valsave fov 1;fov 70;wait;fov 50;wait;fov 30" alias zoom_in_full "mul sensitivity 0.5; bind mwheelup wait; bind mwheeldown zoom_out_half; fov 20;wait;fov 10" alias zoom_back "chase_active 1; bind mwheelup zoom_standard; bind mwheeldown wait" alias zoom_standard "chase_active 0; bind mwheelup zoom_in_half; bind mwheeldown zoom_back" zoom_standard Here is a single-key solution that still allows different zoom levels. Sometimes you may not want to zoom in ALL the way, right up the monster's nose. With this you get an alternating zoom level each time you press the key. // single-key multi zoom alias rekey1 "bind r +zoom1" alias rekey2 "bind r +zoom2" alias +zoom1 "mul sensitivity 0.5; valsave fov 1; fov 70;wait;fov 50;wait;fov 30" alias -zoom1 "mul sensitivity 2; fov 50;wait;fov 70;wait;valload fov 1; rekey2" alias +zoom2 "mul sensitivity 0.25; fov 70;wait;fov 50;wait;fov 30;wait;fov 20;wait;fov 10" alias -zoom2 "mul sensitivity 4; fov 20;wait;fov 30;wait;fov 50;wait;fov 70;wait;valload fov 1; rekey1" rekey1 Baker, your +zoom_key alias is rather non-optimized. There is no need to change the sensitivity with each step of the zoom (it all happens so fast, only the beginning and end sensitivity matters). And actually there's no need to save and load the sensitivity value at all -- you can just use the math to change it and restore it (X * 0.1 * 10 = original value). And there's really no need to use math on the fov for each middle step of the zoom either -- those steps are just there to provide an animation for the zoom effect, so they work fine at set values. Again, only the beginning and end values are important. So if I may, this would be a much cleaner, optimized version of your +zoom_key: alias +zoom_key "valsave fov 1; valsave r_viewmodel_fov 3; r_viewmodel_fov 0; mul sensitivity 0.1; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10" alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload r_viewmodel_fov 3; mul sensitivity 10" 1) Mark V does have ProQuake/JoeQuake/DarkPlaces bestweapon command
2) Does not support pq_moveup (swim up as fast +moveup). 3) No ProQuake 4.93 server browser pressing F5, but instead Spiked Quakespasm server browser. /Shorter version: For various reasons, Mark V won't likely appeal to most ProQuake users and almost all of them would probably stick with ProQuake because they aren't playing new single player releases and most probably only play dm3 24/7/365 or the start map or e1m7 in RuneQuake. Malice has items that modify the player's speed. One of them allows the player to go as fast as 600. Features of this kind are realized by modifying client settings (like cl_forwardspeed) every time an item is activated or deactivated, which leads to problems with savegames.
Perhaps what's more important is the way the mod sets sv_maxspeed to 600. I don't know why, but it does that at the beginning of each level, but not at the game startup. The symptom is: starting Malice and loading a savegame gets you a standart speed cap if 320. My limited understanding suggests that an engine-side solution to a problem of this kind won't be pretty, but I thought I'd mention these anyway. Yeah, that isn't related to Mark V as I think you know.
They could have benefited from some of the things Preach has Quoth do upon save/load, but Quake was new and no one developed Preach's Quoth trickeries. /Quake's save games don't actually save enough information. And never have. Capslock key not bindable? ("not a valid key")
Can it be? I guess you might have to disable its standard function so that it's not actually setting Caps Lock every time someone used it. Just do that if it's actually bound, but if not, let it be standard Caps Lock.... Or just disable it completely. Who needs Caps Lock in Quake? Hm, looks like Proquake just disables it... but... still won't let me bind it as a key ? Oh. Why is that? Is the CapsLock key just something Quake can't handle? I thought with all your extra keyboard code, it wouldn't be a problem.
It's a shame to have an unusable key right there next to WASD, where everyone's hand will be. Joking around aside, I spent quite a bit of time studying input API on various systems and in Windows. And with system methods and SDL input methods.
Caps Lock is a real PITA in a number of the above scenarios. I don't want the input code as a nightmare when I go to do Mac or Linux, so I don't want any differences in the keys behaviors. An analogy: Mark V's GL and WinQuake and Direct3D builds are a breeze to maintain because it's common code for about everything. By having unified input code (which is tough) Well, Grumpy Cat makes any thread better.
One last report, then I retire to my crypt for the night. scr_sbaralpha got borked at some point. In DX, it just doesn't make the HUD transparent at all. In GL, it does make the HUD transparent, but if the value is below 0.7, the console background becomes invisible. I've been looking through the "find all" list. I notice pq_fullpitch is in there as "external server hint." Is that just so you don't get errant messages like "unknown command pq_fullpitch" when you connect to a server that makes the setting? If that's the case.... When I connect to the FvF Proquake server, I get "unknown command cl_fullpitch." So could cl_fullpitch be added in there too? Very minor issue, really.... But It looks like Proquake has both those commands. I noticed the external texture sbar alpha thing with the dx build when I was trying to unravel your dx8 issue. The invisible HUD below 0.7 is probably due to alpha masking test 0.666 in FitzQuake. And cl_fullpitch thing bothers me some. I'll eventually address all 3 of those small little oddities.
In Shrak v2.0, they also fixed an issue in vanilla Quake, and I am not sure if it is fixed in Mark V. From the Shrak readme:
"id included sounds for unlocking the door as well as the normal 'door opening' sound. But because the unlocking and the opening happened at exactly the same time, you never heard the unlocking sound." This probably got lost in the old thread, but it's perfectly possible to do in GL 1.2 and no shaders needed.
Draw the regular 3D view. glCopyTex(Sub)Image it to a texture. Then draw that texture back using a grid with warps at the vertices. This is similar to stock Fitz/QS "framebuffer water warp" but kind of in reverse. It should even be possible to reuse much of the code, maybe tweaking some parameters. Of course the larger texture size needed for this implies a higher GL version, but that never stopped people with external textures or skyboxes. You can also hack something up by playing around with the projection matrix. In addition to the FQ stretch & squeeze, mix in some rotation. It can look good and it has minimal performance hit, but here you need to derive the frustum properly from the view and projection matrices rather than calculating it separately. IMO you should be doing that anyway, likewise with vpn/vright/vup, which also come straight out of these matrices. It's always good to clean up Quake's "calculate the same thing in different ways and in different places" crap. I fixed it in rubicon 2, the solution was to use a different channel for the second sound I think
Created a page on the Quakewiki for external
I separated out one (Abyss of Pandemonium) as an example and uploaded it to Quaketastic and put a link to it. See the first page in the Func "Screenshots" thread for the Quaketastic username and password. This way new Video - Flames using QMB particle system
The QMB particle system is now working. It'll be in the preferences menu and off by default. I have some extreme nitpickery to report.
Messing with the fullpitch stuff, I see that Mark V says these value mimic normal Quake: cl_maxpitch -70 cl_minpitch 80 Buuut, they don't. These values do: cl_minpitch -69.93 cl_maxpitch 80.17 So it seems Mark V's pitch is very close to 0.17 lower than it should me. How do I measure this? Well, start up a new multiplayer game, set gl_texturemode gl_nearest to get a nice sharp pixely look, and look all the way up or down. Looking down, set fov 30 or so and find a nice spot on the floor where you can mark your crosshair position. Do the same by looking up as far as you can with fov 10. Repeating this (take screenshots if you like), you can see that in original Quake and Proquake, the position is identical, but in Mark V (and I think earlier Fitzqauke) it's off by a bit, unless you make the settings I posted. Though neither of those cl_maxpitch values will be without issue when connecting to a Proquake server which disables fullpitch. Upon connecting to FvF, for example, I find my value is altered to: "cl_maxpitch" is "79.9969" (altered!) Setting anything above that value causes the weirdness when you try to look all the way down and your view is jerked back to a legal value. Though with the server sending the setting to me automatically, that's not really an issue. On a less nitpicky note (though some will disagree!), this is one of those settings I have in the "Restore Quake Defaults" section of my MarkV.cfg file. The Quake defaults should be respected and left as the defaults here. Fullpitch is for people who want an altered-from-default functionality. Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!! Though, cl_minpitch -700 cl_maxpitch 800 Is pretty funny to play with! You are very likely correct about the original pitch numbers because of how client/server read and write those numbers and various roundings that happen (floating point imprecision and conversion to integer types of various sizes).
I remember having to do some fighting with those numbers when test against servers that require original pitch limits or they will fix your angle for you, which is an unpleasant experience. I just noticed an interesting interaction between shadows and transparent water.
It looks like the water is being drawn on top of the shadow instead of the reverse. So if the r_wateralpha is 1, you don't see the shadow at all. If the r_wateralpha is This may be related to the issue NightFright reported on #697 of the old thread (and that issue still occurs, by the way). they seem to occur around every 30-60 seconds and last for about 3 seconds. the fps doesn't drop at all. It's like micro-stutter with input lag. I initially thought this had something to do with the seemingly random autosaving (didn't know winquake autosaved randomly until now) but loading the autosaves after a lag spike doesn't show a correlation.
this is on a relatively powerful pc (4970k, gtx980, ssd, etc). Still poking around for a solution... Shadows + water looks fine to me. screenshot.
Is this DX8 or a special circumstance or combination of settings? I believe you, but need more information or an example -- post a screenshot? /Note: I expect to change r_shadows -1 to r_shadows 2 in next version. Follows more closely to the way other cvars work like r_lerpmodels (0,1,2) Both GL and DX.
I think you are getting the shadow effect there, but it's not very noticeable because your shadow is fully in the water, and the area is dark. Notice you see the water texture on top of your shadow, but your shadow should be fully dark if you are using r_shadows -1 Stand somewhere so your shadow is partially over water and partially over solid ground, and alter the water alpha settings to 0, 1, and somewhere in between. Try the little square thin water place on e4m2 or just stand on the upper level of e1m3 so that your shadow overhangs the edge above the water. Or the Start map, just stand so your shadow passes over one of the cracks in the floor with water below. Uhhh... I wasn't going to post a screen because this should be easy to reproduce, but what the heck is happening here? http://imgur.com/a/vUIz9 Some kind of anti-wallhack thing? sv_cullentities is 0. If I set gl_clear 1 then that area becomes grey. This in in DX. Looks like in GL, the area is grey even with gl_clear 0. Oh, chase_mode 1 is what's causing that weirdness.... I know that's an "experimental" feature... but that's an ugly effect, heh.
You are using chase_mode and I told you it was experimental ;-)
Sometimes chase_mode can't work perfectly for a few different seasons --- remember the thing about saying how complex camera code is in modern games? In your screenshot, the camera and the player are in different visibility leafs. The player can't see those walls, but your camera view point can. Only one solution for you: Type r_novis 1 + sv_novis 1 and pay the price for the server sending 100% of all entities and the client-side just assuming every wall in the map can be seen. Yup, r_novis 1 clears it up. But I'm not leaving that on. Of course, normal chase_active 1 doesn't have the problem, but I like the neat feature of having my crosshair remain accurate in chase mode (that's all I really want), so I'll deal with the occasional ugly effect and keep using chase_mode 1.
It can actually even happen with standard Quake chase_active with all default settings pretty rare.
Maybe at some point I'll do some sort way to make the crosshair appear in chase_mode. Feature tweak request:
If your bestweapon is currently selected, then have the bestweapon command switch to the next item in the list. Example: bestweapon 8 5 4 3 2 Normally this command will switch you to weapon 8 (assume you have it). But if you have weapon 8 currently selected, have it switch you to weapon 5 instead (or 4 if you don't have 5, etc.). Activating it again would switch you back to 8. So effectively it will toggle between two weapons -- your best and second best, as you define. In this example it lets you toggle between your two best close-range weapons. I would find this quite useful, and better than doing "nothing" if you already have your bestweapon selected. Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!!
No we didn't, it's always been annoying. if it's there, I'm having trouble detecting it at 72fps since it's a slideshow at that point.
I don't notice any physics issues at 144. I'll live with the lag if the fps increase is indeed the cause :/ This may or may not help you
What would be different about your powerful machine that would make it have an input lag issue that doesn't appear on far lesser hardware? I mean Mark V --- even the WinQuake version -- runs great on some real clunkers. Try running on a different computer. Then think about yours. In my experience, people who beastly machines usually over-configure something. /If you ever do figure it out, let me know. Mark V does simple Windows input just like Notepad (no kidding). Doesn't even do DirectInput. Did you have something "amped up" going on with your mouse, or really fancy settings for your mouse or set a polling rate or anything.
/I hope whatever it is comes to light. A cursory check -- the Windows message queue appears to holds 10,000 messages, according to what I found on stackoverflow.
I don't know what your mouse polling rate is, but if it is set real high, it is possible your mouse might be overflowing the Windows message queue. Which according to these sources, would stall it. killpixel, I don't suppose you are using skyboxes? If so, try disabling them. I am playing with the GL version and getting reproducible stutters when using skyboxes, but there are other settings or something involved which I am trying to nail down....
Here's what I do to reproduce the stuttering: In a new instance of GL, single player, go to e4m5 (notarget), load a skybox, walk down the hall and turn right and walk out to the nails, it stutters in up to 4 spots (the same spots), I think as each section of the skybox loads. It happens every time with my full setup running (from my FvF folder), but I can't get it to happen reliably when running clean out of id1. I'll try to narrow it down.... Also: GL + fog 0.025 + r_skyfog 0.05 is being wonky for me. Not all maps and positions, but I think I can see the seems in the skybox appearing sometimes: http://imgur.com/a/fEMJ2 I was getting some weirdness in the upper level of the sky even with skyboxes disabled too, again when the fog settings were on. GL version only. Your link is broke, btw.
you are using skyboxes Nope. I play with classic sky 24/7/365. Unless --- the map sets a skybox. Note: r_skyfog 0.05 isn't so much for users to play with, but rather so mappers can tune the appearance of how they want the fog to look in the maps they are building. Common values are 0, 0.25, 0.5, I don't know what r_skybox 0.05 would look like, but it is an illogical value to set because someone would basically be using 0. So just use 0. /kp (killingpixels) is using WinQuake version btw. He likes pixels ;-)
@gunter --- Just tried your E4M5 setup. Since it shows so much sky -- and maybe you are using fog --- with your netbook that area is going to be a performance challenge. Even worse, because if you are using the Open GL version, it's going to stencil draw the sky and I suspect your netbook is going to hate that with a huge amount of sky drawing. The DX8 version doesn't support stencil, will be much faster. You could add -nostencil to the OpenGL command line. I don't know what size skybox you are using, 512x512 ? 1024 x 1024. But by comparison, the Quake sky textures are 256 x 128. So you have a special scenario and combination of settings that are going to be particularly rough on that netbook in that area. thanks for the ideas, baker. currently looking into anything I can think of.
I run a very lean setup that is judiciously (neurotically) tuned. Without going into detail, its not an infamous xxxgamerkid rig. However, that doesn't mean I haven't missed something. My current polling rate is 500hz, I'll experiment with lowering it. I'll also see how it runs on my laptop. I have a suspicion it might be my keyboard. Last week, I took a gulp of water that had a beetle in it and ending up soaking my keyboard. Sometimes some keys will register multiple hits. I wonder if it's sending some sort of input/signal I'm not seeing. @gunter - thanks for the ideas. the quake setup is 100% vanilla. I'll probably even disable music to see if that changes anything. I took a gulp of water that had a beetle in it and ending up soaking my keyboard
You should have eaten the beetle. Good source of nutrients! In countries where nobody wears clothes, they might even argue over who gets a tasty beetle! Besides, by eating the beetle you are exerting your dominance over the rest of the food chain -- and sending a clear message to any other beetles observing. -nostencil does fix the weird sky glitch that I was trying to post a picture of. Yeah, imgur seems to have developed a DNS problem shortly after I uploaded that image -- I can't access the site at all, but apparently some people can. The glitch I was talking about is easy to produce at the start of e4m7 with skybox + fog + skyfog with any values set other than 0.
However, -nostencil doesn't get rid of the stuttering. I can reproduce the stutter on e1m1 too. Also... Single Player -> Levels -> Select a level, does not reset variables such as Deathmatch, as happens if I instead select "New Game." Maybe it should, since this is the Single Player menu? And... I think r_mirroralpha should default to 1 ("off"). It's a fun thing to play with, but can cause a performance decrease (pretty significant in my case). It looks like I'll be sticking with the DX version anyway, as it performs better for me. Beetles aren't the kind of bugs I like finding.
Maybe the spirit of the beetle is haunting you now and causing the problems. Think about it -- to him that cup of water is like a well he fell down and drown... just like The Ring! Download same place as usual
No QMB option just yet. New Feature - Not fond of 1) Typing cvar without value in console shows help. 2) This can be turned off "con_verbose 0" (saves to config, of course) I don't like it printing help because I prefer lean and mean console. And some of the descriptions are too long for my liking (short is best). However, someone who does not know too much about Quake it will help. People that don't like it (me) can turn it off. Plus once someone has things setup, you aren't doing that often anyway. New features 1) Mirrors only to Quake (gamedir id1) or intended map (*). (scampie) 2) cl_truelightning. Eliminate lightning beam "stutter". Defaults on. 3) Type cvar in console, show defaults value too. 4) r_shadows 2 is dark shadow. 5) Random rarely used cvars from JoeQuake/ProQuake added (cl_item_bobbing, pq_moveup) for thoroughness. 6) cl_autodemo 2 = autodemo no matter the fps 7) If recording demo, pressing TAB shows name in top left. 8) Slightly better "read settings very early" behavior. I'm hoping #6 and #7 somewhat addresses the change in cl_autodemo to off by default by those who prefer this feature always on (pulsar, fifth, etc.). On a healthy computer and 72 fps, recording a demo is not exactly taxing behavior -- people have recorded demos while playing since 1996. * Worldspawn key "mirroralpha" "0.5" for example causes textures prefixed "mirror_" to have mirror effect. Setting r_mirroralpha 1, turns off mirroralpha. /Typing "version" in the console will show as build 1002. Could you add the teamplay scores to the scoreboard sheet
there is an ancient engine by tonic(?)glsq.exe that actually does this thing(very handy when playing vs frogbots) at this moment that engine refuse to run on my current rig , so there's no example screenies I think I like the con_verbose 1 (information is good), but I would really suggest reversing the order of what is printed; when someone types just a cvar in the console, they are wanting to get its current value of the cvar. So the current value should be the last thing printed, because your eye automatically goes to the last thing printed in the console when you are looking for the output of your request.
I do not like cl_truelighting. In fact, I think I GREATLY dislike it, heh. The lighting gun does not fire in a constant stream like a water hose; it fires in rapid pulses, like a lot of separate lighting strikes. This effect makes your visual indicator inaccurate and misleading. This may make a bigger difference online, but test it for yourself in single player by setting your host_timescale 0.1 You can now clearly see that your lighting bolt fires in pulses; the sound effect is now spaced out so you can clearly recognize this -- the stain maps on the wall also will demonstrate clearly where you are actually hitting. The sounds and stains will line up exactly with where you see the bolt strike if you have cl_truelighting 0. this is the correct effect -- the lighting gun fires in rapid pulses. But if you have cl_trulighting 1, you only see a "laser beam" effect of where your gun is pointing rather than the actual beam that is hitting the wall, when and where it is actually striking. So... "true lightning" is actually "false lighting." I have no use for this deceptive effect. Throw it away, or disable it by default! heh Disable it by default, and if someone tries to enable it, print a warning, "Are you SURE you want to enable this awful, deceptive effect??" ;) Hey killpixel, have you tried the GL or DX versions to see if you get the lag spikes in those versions?
You can change settings in them to make them look all pixely too, like: gl_texturemode gl_nearest and other stuff.... Uhhh, Baker, I know you're messing with particles... it seems the Grenade and Rocket Launcher have lost their particle explosions. And my Fvf chat bind is no longer working for the ` key when I bring down the console. I use: bind ` "impulse 39;toggleconsole" bindlist shows it is still set, but it doesn't seem to trigger the impulse. If I bind another key to that, like "w" then it works as usual. in the quakeworld community, truelightning is otherwise known as fakeshaft.
and it breaks mods, so should normally be disabled by default if you care about maps+mods rather than trying to be a replacement proquake. assuming baker implemented this too, try a fractional value. that should smooth it a bit while retaining a bit of its snappyness so you can still sync it up. cl_truelightning was written by Joszef, the author of JoeQuake -- the engine used by speed runners.
It just uses the player origin as the starting point. It sure as hell doesn't break mods, doesn't support fractional values, isn't server side. And it existed long before anyone in QW ever made such a thing. I can't add teamplay scores to the frogbots scoreboard in the engine because it requires QuakeC support. However, since you've modified the frogbots source yourself, you may be able to implement this in the mod by examining the only open source mod that I know of that leverages the feature source code.
/Contrary to impression some people get, my QuakeC skills are about cut-and-paste newbie level except I can see function operations from the engine side and I mentally have a catalog of modifications and what releases do what. @gunter - kp wants the real deal, he likes the software Quake look. He knows about GLQuake texture filtering command. @Spike - p.s.: guess which engine does not have such a feature -- it's modern ProQuake. I was a beta tester for JoeQuake, I sure knew about the feature. I've always considered truelightning a single player visual enhancement. Hence, gunter who plays co-op online is the only person who will complain about truelightning, that's the only time you wouldn't want the effect. It's like animation smoothing for the lightning gun. it's just depends of the color of given team,
the red team gives its own score points and so on not related to fb(qc whatever) at all re: RL Particles -- I'm on it. I was going to try to get a 2nd update in about an hour after that one. Thanks for heads up.
re: toggleconsole It is now key placement specific behavior hard-wired in the engine to support that the key below ESC activates the console no matter if the keyboard is German, French or Brazilian. You should have eaten the beetle. Good source of nutrients!
hindsight is 20/20... next time @gunter - yeah, I've tried the other versions, but only briefly. I will revisit that. My quakespasm setup is as you suggest. However, Mark V has two key features: indexed colors and resolution scaling. That aesthetic is my jam! Ah, I see. At some point, I'll look at the frogbots mod and see if I can causes it emit teamscores to achieve what you want, but using what I consider the "correct design" way.
I like knowing the team score. Admittedly, when I am playing frogbots, I'm generally playing free-for-all style, so didn't think of your idea. i'm gonna resurrect my old rig to give you a clearly view of my desired wishes
thanks for your reply /Contrary to impression some people get, my QuakeC skills are about cut-and-paste newbie
level except I can see function operations from the engine side and I mentally have a catalog of modifications and what releases do what. Mister B, you're underestimate yourselves and your skills "true"lighting -- actually, playing coop online won't be the only time I'd complain about it, heh -- it feels wrong in single player too. It is NOT the same as animation smoothing -- you are drawing the actual "projectile" that comes out of the lighting gun *in the wrong place*. I can tell this even in single player, and it feels wrong and fake, like I know that lighting bolt is a harmless illusion instead of an actual bolt that is striking where it appears to strike. The bolt just doesn't feel "real" anymore -- like real electricity is a series of rapid flashes, not a steady laser point beam.
though I do wonder how it could possibly "break mods..." unless slow motion was in play or something. toggleconsole/international keyboard -- err... this breaks compatibility then. Can it be disabled? New report -- during the "congratulations" screens, pressing TAB causes the text to disappear, but not the "congratulations" banner (this is in "DM mode" that FvF Quest runs in, when normally TAB should show the scoreboard). It doesn't actually show the scoreboard, it just makes the text vanish. Proquake didn't do this. Also, I guess I'll note that centerprint text still appears behind the standard menus (this is altered behavior too). And, should not "Weapon Draw" in the menu be defaulted to "Quake Default" rather than "Fitzquake?" Heck, "crosshair" in the menu should probably default to "quake default" too, even though the actual Quake default was "no crosshair" Download same place as usual
Changes - Fixes rocket explosion a missing particle. This is a correction of the 1002 build. /Typing "version" in the console will show as build 1003. I will put in a an option to disable the hardwired tilde key behavior in one of the upcoming versions.
I'll have it so if in_keymap is 0 (turns off international keyboard support), tilde behaves in the old way. The lighting gun does not fire in a constant stream like a water hose...
I hate to get all "Quake Manual" again, but... Thunderbolt: Try it. You'll like it. Use the same technique as watering your rosebush. Adding to what mh said:
QuakeC is trying to get the beam position to always be starting at player origin. The problem is, it is only updating 10 times per second because QuakeC is 10 fps. The implementation of rendering the lightning beam as if real-time (an illusion) on the client side is merely doing what QuakeC is trying to do, but can't. /I mean jerky sky scroll is how original WinQuake works, but Mark V straightens that out too. Same can be said about FitzQuake 0.85 animation interpolation. I don't see Jerky Lightning Beam being something that was a design plan, but rather a side-effect of a technical limitation of the speed of a 1990s computer. I'd be inclined to go slightly further with this: Lightning angles are another of those framerate-dependent client-side behaviours, so they should be simulated at a fixed rate instead.
NightFright went all out!
Take a look! If you want transparent water without vispatching (.vis) and colored lights (.lit) for Add-On Mission Packs https://quakewiki.org/wiki/External_Lit_And_Vis_Files - Nehahra - Beyond Belief - Abyss of Pandemonium - Several more There is a link to that page on the Mark V site next to the Transparent Water/Color Lights (says "More /The I suspect I'll make it work like this:
0 = off 1 = single player only + if you are playing bots [sv.active in engine terms] (because in my view this is the only correct use of feature) 2 = always If you look in CL_UpdateTents you'll see that lightning angles depend on a rand: ent->angles[2] = rand()%360;
So if you run at 20 fps this angle changes 20 times per second. If you run at 72 fps it changes 72 times per second. Etc. So this angle is framerate-dependent. A possible solution: create a lookup table of angles and index into it by some function of cl.time; probably also need to use the temp entity number so that not all bolts get the same angle. Ent->angles[2] = angletable[(Cl.time * 72) + i] Something like that. Forgive capitalization & typos, on a phone keypad. I actually remember that line from the manual about watering the flowers, heh. However, you could still water a rosebush with a sprayer that spurts water 10 times per second ;)
Ok, there is no limit in QuakeC about running things more than 10 times per second. You can easily make thing do stuff in much smaller increments. I actually have some test code I sometimes activate for fun that lets your weapons fire INSANELY fast. 10 nails per second is the standard rate of fire of the nail gun too, but I can modify it to fire a bazillion nails per second if I want. Screenshot of me firing a bazillion nails per second: http://imgur.com/a/m3ija heh The reason the guns don't fire any faster than that is not because of any QuakeC limitation -- it's because if it fires any faster, it would be too powerful in addition to burning through your ammo way too fast. Of course, the standard The lightning gun could easily have been made to fire/strike much faster than 10 times per second, but that would require it to do less damage per strike among other things. Now, the firing origin of the lightning bolt, by default, DOES stick to the player. You can see this in chase mode (use host_timescale You're trying to fix a problem that does not exist. If id wanted the end point of the bolt to stick to your crosshair position, they could have done that, just as the start point of the bolt sticks to your player position in chasecam. Oh, and I found a mod that "breaks" because of "truelighting" Anyway, if you want an "eycandy" effect like this, fine, but default OFF please. And be very careful about adding stuff like this -- junk like this is the whole reason many people dislike the majority of other Quake engines -- it changes the gameplay feel or look too much. A smoother-scrolling sky? Sure, that's just a visual thing that makes no difference in gameplay feel. Smoothed monsters look much better than jerky ones too (though some people prefer a "retro" feel). But the "jerkyness" of the lighting gun is not merely an animation issue -- it's actually showing you precisely where the bolt is striking as it pulses 10 times per second. Excuse the double post, but it's probably worth mentioning that in my own code I use 36, not 72, and talking a bit about why.
I take issue with the common statement that Quake is designed to run at 72 fps. If you look back at the time it was developed, while there certainly was hardware that could run it at 72, most hardware couldn't. Especially in the typical configuration, which was playing the DOS version on Windows 95. Most people were playing Quake at 20 fps, 30 maximum, and while id do design for the future, they also design to get a good game on current hardware. So I'm more inclined to say that Quake was actually designed to run at 20-30 fps and that 72 fps was nothing more than a framerate cap, "so packets don't flood out", according to the comment in host.c The number 72 is significant: it would have been a typical refresh rate of a typical CRT monitor from the time. Hence for certain framerate-dependent effects (rocket trails are another, rocket trails aren't actually a smooth trail at all but rather clumps of particles with each clump spaced out & intended to represent a puff of smoke) it makes more sense to run them at a slower rate. 36 is just a nice even reaction of 72 (24 would be another) but there's no actual technical or analytical basis for it. Oh, and I found a mod that "breaks" because of "truelighting"
Looks like defaulting it off then, it is. I did do testing against a few mods looking for differences, including the Zerstorer funky chain lightning gun. After not being able to locate any instances where it made any meaningful difference. So off will be default value in next version. Was trying to address the common beginner complaint "Why does my lightning act jerky". So question will remain, but answer will be "try setting cl_truelightning option to 1". Typing "sky" in the console does not report the help information for that command.
Thinking about the lightning bolts, the animation really isn't ideal, which is why beginners may ask why it's so jerky. The bolt is misinterpreted as a solid object that can be swept back and forth to touch things, when it's actually a series of very fast point-to-point pulses, like a stun gun ( reference: https://www.youtube.com/watch?v=OU95qvuKKMs ) Perhaps an easy hack to improve the animation so that it more accurately reflects the function would be to only draw the lightning entity for no longer than 1/20th of a second (it will currently stick around for up to 1/5 of a second if you don't fire a new one every 1/10th). That way the first pulse would vanish before the second pulse appeared, making it clear that it's a separate pulse. It would indeed create a more functionally accurate, rapid zap-zap-zap-zap effect instead of the look of a jerky sweeping line. And it seems like it might be an easy thing to do in the engine.... More complicated effects would involve the lightning bolt actually appearing to leave the gun and flash forward very very fast. The beam would still be instant, but the visible lightning in the beam would appear to move forward very fast. Animation tweaks like this I could get behind, because they would accurately reflect the function without ever drawing a bolt as hitting positions it doesn't actually hit. I think I may go play with some QuakeC and see what kind of funky lightning animations I can make. I'm getting crazy ideas, hehe. The end point of the bolt, however, sticks to where it HITS. There is no QuakeC limitation causing this behavior -- this IS the intentional and correct behavior of a rapidly-pulsing lightning gun.
I personally like my lightning bolt to stay in my crosshair but fom a logical perspective this makes sense. If you watch real-life electric bolts, you can see that when they find a "target" they tend to stick to it for a moment before jerking to another point. Sky is a command, it isn't a console variable.
Commands are things like "map start" or "status" or "load mysavegame" or "noclip". They might not even need a parameter. If you do "find sky" it shows things related to sky, for example, and it says "command" in the value column. Yeah, the difference between a command and cvar is not necessarily clear to the user. Like how "name" is a command but the value is a console variable _cl_name Ok, this turned out kind of cool....
I added my new lightning gun animation test to my little camtest mod: http://fvfonline.com/camtest.7z I didn't change the actual functionality of the gun at all -- just the way the lightning bolts are drawn. I think now the way they are drawn more accurately reflects how the gun actually functions. And it just feels POWERFUL! Somehow that "trueshaft" felt impotent, because it was waving all over the place but not hitting everywhere it waved. Don't you hate it when your shaft just waves around and feels impotent? heh. Well, Dr. Gunter's Shaft Enhancer is what you need! Rum the mod, give yourself a lightning gun (give 8) and a cell or two (give c 1) -- you only need one, I made it not use up any ammo for testing -- and go to town. Find some monsters to light up. The effect is more intense on a dark level, like maybe e4m7.... Tell me frying monsters with that thing doesn't make you feel like the friggin' god of thunder! hehe. Yeah, the lighting passes through walls... It's just a quick hack, and currently would probably not work for online play (I'm using those very tiny time increments that are fine for client animations). The stainmaps don't like it either. Also try host_timescale In any case, THIS animation (though primitive) feels right, and accurately reflects the function of how the gun actually works. Having good times playing with this so far. I know you don't like menus but I really appreciate the extent to which you've menu-ified some of the settings.
A minor ask: I've noticed on my system that the video stretch setting defaults to "640x480 Nearest" on first run. Can the default for that be "None" instead? That way if a naive user comes to the video settings and just changes the resolution, they'll get what they're expecting/intending instead of getting 640x480 stretched out to that resolution. The default value was supposed to 0 (none). The stretch item in the video menu is obvious. So
I know you don't like menus but I really appreciate the extent to which you've menu-ified some of the settings. Haha, yeah. I'm very judgemental about menus. Brevity is soul of wit. Where bad design exists, it expresses itself in the form of menus. I have now finished uploading my complete collection of
Check out all 32 uploads here. Fire up Mark V and enjoy! Lits for Malice are a little weird. For the most part they're reasonable, but it seems that some of the textures emitting colors shouldn't really emit anything. Like warning stripes.
...when using automated tools. The only handmade ones are from Quake and the mission packs (not done by me, btw), the others were generated with automated tools. One would have to edit the
If anyone has the time and motivation to go through all the (formerly) commercial/community release lits to eliminate bad color lights placement, feel invited to do so. In the recent DX version, the illusionary guy from the
Is it possible that screen resolution is not automatically copied from id1 config any more when launching addons in other directories (e.g. c:/quake/nehahra) for the first time?
I am in windowed mode and have to reset my addon screen resolution to 800x600 from 640x480 even though it's changed in id1 config already. A final tweak of my test lightning gun animation -- it won't pass through walls now and it interacts (heavily!) with stainmaps.
http://fvfonline.com/camtest.7z Download and give it a try, people. It's just a tiny mod. After playing with it for a while, I realize why it's so much more satisfying than the default lightning beam: the visual feedback lets you see that you are POUNDING the monsters 10 times per second with zaps of lighting rather than just focusing a beam on them which doesn't give good visual feedback of the hits/damage it's doing. And it's just so much more satisfying to pound a monster with 10 lightning bolts per second! It just FEELS more damaging. The "truelighting" effect waters this down even more, giving even less correct visual feedback of the pulsing of the lighting strikes. Again, I haven't actually changed the function of the lighting at all -- this is just visually illustrating how the lighting gun has always worked. The flashing lights I added may be a bit much (and may cause seizures!), but gosh darn if it doesn't make you feel like you're unleashing a massive, powerful Tesla Coil on those sorry monsters! There are two blue mechanical enemy types in the game, and they both seem to consist of two models - upper and lower. The upper model is often invisible in Mark V (GL and software), Quakespasm, and enhanced GLQuake, but not in enhanced Winquake.
Hi, I'm loving the engine so far (Former user of Quakespasm) and I was wondering what other audio formats are supported other than MP3?
Post #14, #16
Mark V uses system methods to play MP3 that take advantage of hardware accelerated decoding of mp3 built into your processor. Intel processors, AMD processors, the iPhone, Android phones all provide hardware accelerated MPEG-1 decoding (mp3 is part of MPEG-1 specification). Plus the mp3 decoding patents expired in September 2015. ... why Mark V can stop/pause/restart music instantly and engines using a software decoding library cannot. A polishing/tuning update probably within an hour.
1) Decided against printing console variable descriptions when typing a variable name in the console. Will revert to old behavior by default. Most of the important stuff is in the menu, someone new can always ask if they don't discover the "find" command first. 2) The lightning goes back to old behavior by default, someone can just turn it on if they like. Nothing else of interest except QMB support will be in the next as an option which defaults off. @dwere -- Probably a Malice content error that doesn't work Open GL engines. At some point I'll give it a look over to see why that would be the case. You said it shows in Enhanced WinQuake (but not Enhanced GLQuake) In the recent DX version, the illusionary guy from the
Triple check up close and personal. I just replicated a test to make sure, and in the test alpha entities are rendering in DX8 fine. But sometimes you have to get close and look hard to notice the transparency. DX still doesn't do the transparent HUD. That's on the to do list, I haven't forgotten. It will at some point be addressed. Seems that
Will investigate at some point to see why, but remember it has to use an alterate rendering pathway for this scenario (the one that metlslime) -- so may be little recourse. It already isn't drawing quite the same as Open GL, because it can't. Mark V's read early of the video mode "read early scan" only checks in the intended gamedir.
I guess I'll expand the "read early scan" to also include id1 if in a gamedir. You said it shows in Enhanced WinQuake (but not Enhanced GLQuake)
Strangely, no. A minor nitpick: the engine crashes with a generic error when provided with a wrong (non-existent) directory after -game. Noticed by making a typo. I had made an initial attempt at adding combine modes to the D3D wrapper but backed out of it on grounds of code complexity.
The irony here is that all multitextured bleeding in D3D is the equivalent of GL combine, but GL API quirks (specifically use of "selectors" rather than being "DSA"-like; in GL you set the current this, then the current that, finally the actual state, which has to track those current selections, in D3D it's all a single line of code) made everything messier than I was happy with. Nobody should read it as "D3D can't do combine" because it can and does. It's a deficiency in the wrapper and complexity in translating code between one API and the other. can't seem to get nehahra to work right, mainly it's opening scenes just never play (and in turn it won't start) and it's throwing gl fog errors. I tried with the latest version in all three renderer types, using the quaddicted zipfile. Am I doing something wrong? is there more steps to this than just -game nehahra?
Download different place than normal, on slow internet connection and can't get uploads to work except at
http://www.megafileupload.com/cb8d/mark_v_1005_everything.zip New Features 1. JoeQuake QMB particle effects option. video 2. "in_keymap 0" honors tilde key bind (gunter). 3. -game invalid dir warning (dwere) 4. Console default values are engine default 5. Normal lightning beam default again, instead of realtime simulated. 6. Console variable in console old behavior restored. 7. vid_stretch defaults 0 in software renderer (johhny law) I'm having difficulty uploading on a slow connection -- go figure. Typing a console variable name in the console no longer prints the description (at least by default). There are reasons this is undesirable. in_keymap 0 turns off international keyboard support (mostly) and therefore tilde key position is known and can use old behavior. @nightfright - Checked an the read early behavior in Mark V is actually correct and reads both gamedirs if a gamedir is used. /Typing "version" in the console will show as build 1005. I've never used that site before and attempting the download, my browser flagged the download as possible malware.
My (remote) internet connection is so slow, it is virtually impossible for me to conduct any research with any kind of speed. Maybe this warning is bogus, maybe it is real. I don't have a way of checking this out on this slow internet connect. I would not think that Google would list a file upload site that is known to add malware as the #3 search result, but maybe they do. Also, the first cutscene starts with a black screen. It's perfectly normal and you just have to wait a little.
Firefox is flagging the file as potential malware. Scanning with my Kaspersky shows no threat. Virustotal yields a positive (1/54, Invincea --> virus.win32.sality.at).
Looks like 1005 broke the tilde/console key again with German keyboards.
My config.cfg settings: in_keymap "0" in_system_enhanced_keys "1" In the final level of "Beyond Belief" (bbelief7 | The Unholy Alliance), just when Cthon dies and is about to fall back into the lava, Mark V crashes to desktop with a "Host_Error: recursively entered" message.
Can anybody confirm? Using latest Mk V 1005 build, GL version (mark_v.exe). Only happens when using Seven's BB enhancement mod.
From qconsole.log: Host_Error: ED_Alloc: no free edicts (max_edicts is 8192) Game is apparently running out of edicts when Chthon falls back into lava, bleeding. DX transparency -- Looks like gl_overbright_models 0 borks it up (makes it opaque) in DX. It also slightly alters the appearance in the GL version.
Wanna crash Mark V on startup? Just put scr_showpos 1 in your autoexec.cfg ;) @NightFright, I think you want to set "in_keymap 1" Yepp, already figured it out. It's actually set to 1 by default if you delete your config.cfg and let Mark V create a new one.
I dunno if my report about the max_edicts issue is relevant. I actually thought there is no limit for this any more. Last thing I read was that Mk V tries to detect the required amount automatically. Maybe it's not working reliably in all cases. If Seven's Beyond Belief is endlessly creating new edicts, it is a flaw in his QuakeC.
DarkPlaces is just hiding the problem by endlessly allocating edicts, but given enough time it would eventually run of memory. 8192 edicts is a whole ton of edicts, even Rubicon Rumble doesn't even half of that. And Beyond Belief is a 1990s era work that runs in original Quake with a 640 edict max. Were you using in_keymap 0 on purpose or on accident?
If it was intentional, was there something you preferred about in_keymap 0? I use USA keyboard so have to listen to experiences of others on this subject to learn. @fifth - After trying to upload 15 times, I just wanted it upload (was minor nightmare, would upload 50% or 98% and bail -- wasted a lot of my time). Either way, I'm no longer on a remote internet solution so I'll be able to upload ok again. Probably an update in next hour after I knock off the scr_showpos with no map issue that gunter pointed out. Download at normal location:
http://quakeone.com/markv A minor touchup to the 1005 build and distributed the usual way now that I am not on "bad internet". New Features - (from previous build) 1. JoeQuake/QMB effects option in preferences menu video 2. "in_keymap 0" honors tilde key bind (gunter). 3. -game invalid dir warning (dwere) 4. Console default values are engine default 5. Normal lightning beam default again, instead of realtime simulated. 6. Console variable in console old behavior restored. 7. vid_stretch defaults 0 in software renderer (johhny law) Touchups in Build 1006 1) Fixed scr_showpos bug. (gunter) 2) Made freezeall work in deathmatch if maxplayers 1 for debugging. This is a correction of the 1005 build. /Typing "version" in the console will show as build 1006. A possible solution would be to drop in some native D3D code instead of using the wrapper. That way you could get the combine mode properly set up, get improved performance and code simplicity.
Of course the down side is that you'd be losing the flexibility of going through a wrapper - you've now got native D3D in key parts of your codebase. That might not be such a big deal. IIRC FQ only needs this in 2 or 3 places and the only combine mode it uses is modulate colour 2x. I kind of like the QMB particles.
Feedback for that: Missing blood trails on gibs... unless a zombie is throwing them? Or unless they hit the ground maybe? Or.. unless they are moving very fast... Something is different. The chunks just aren't bleeding right. Flame effect doesn't work on new torch projectiles (FvF fighter/ninja). Eh, not a big deal. The old flame model still appears. Lightning is too blue -- needs to have bright white in it to look electrical. Oop. Crashed with AddColoredParticle: Invalid type (2) in FvF with mage/monk/cyborg weapons (they use red/orange/white particle explosions) The grenade and rocket launcher explosion effect is anemic. Not enough force or intensity compared to the standard particle explosion. The scrag projectiles are way overdone -- they look like green lasers. Decrease intensity. Vore ball too. Explosion sprite is completely gone (invisible), but frames of it are used for several FvF guns. The new effect only appears for the Quake guy's stuff. The, uh... yellow particle field effect is gone (runequake uses it for spawn shield, FvF for BFG explosion). Chaingun weapons do not leave sparks on the wall like the shotgun does, just a few grey particles instead which don't show up very well.. Would it help if I gave specific code for the various particles I'm talking about? Not sure if you can/will make any tweaks to the effects.... @gunter - Made what JoeQuake had to offer available as-is.
The rocket and grenade trails I feel work generally work nicely. Example: qmb_trail_scrag 0 (doesn't fit in, does it?) The menu only sets qmb_active 1 or qmb_active 1. If you individually turn off or change the others, they stay as is. "find qmb", you can locate things to turn off. I made every individual effect on|off via cvar. It is possible I look back at this thread for ideas on tuning for say a future version 2, but someone really into effects needs to be using Qrack, DarkPlaces, FTE or an effects oriented engine. So you can do: bind x "toggle qmb_active". Acquisition Main goal was full set of JoeQuake, Enhanced GLQuake/WinQuake and ProQuake feature set. To keep alive their unique contributions @mh - I agree with some of that, but main purpose the DX8 build serves to me is to help people with bad Open GL drivers. Having 98% is pretty good deal. Eventually problem will be solved by Gunter spilling drink on his laptop ;-) Haha and this is why scriptable particle systems are so nice. :)
That way you can tone them down or just avoid disturbing reinterpretations of the original intent of the effects. Yeah, in JoeQuake trails were all or nothing.
You couldn't turn off, for instance, just scrag trails (radioactive green). The FTE particle system -- even the subset in Spiked Quakespasm -- offers the user to be fully in driver's seat. Versus where effects are hardcoded into the engine. I just downloaded and tried JoeQuake, and the colored particle explosions work in it.
As mentioned, they crash Mark V. I can disable them by qmb_explosions 0 If you wanna see lots of effects like this, just connect fvf.servequake.com -- the mage uses lots of things in his various spells (vore balls, knight spikes, and lighting bolts), and the cybrog, monk, and cleric all toss around weird things too. But of course, if you have qmb_explosions 1 I'm combing through this and auditing a couple of things.
Do you know of a colored explosion in either regular Quake or a mod I can locally run? A situation where I can't savegame, then loadgame rapidly to tune isn't all that ideal. I have the gib trails fixed. Ya know, I don't think the effect is used anywhere in standard Quake.... It's just one of those unused effects.
Here, I updated my little camtest mod to include colored particle explosions: http://fvfonline.com/camtest.7z Just set scratch3 to any number from 1-255 (actually, you can probably set it higher, but you may get weird results, like black particles.... 12 is a good number to use -- it's bright white), and your rocket launcher will make colorful explosions. Ok, sometimes the torches in the Start map turn white (untextured) when QMB stuff is enabled in DX. I can't reproduce it reliably, but I've seen it happen twice. Once I see it, a restart of Mark V clears it up (or turning off the QMB effects).
Also, I have a little blue particle water splash effect in FvF, but sometimes it's turning out as an orange/yellow spark/explosion effect.... Can't reproduce that reliably either.... Download at normal location:
http://quakeone.com/markv 2 bug-fixes related to QMB -- gib trails, colored explosions. (gunter) I could really use a setting to always draw the standard explosion sprite even if QMB explosions are enabled (several FvF weapons make use of the sprite)....
Heck, I might even like having both the normal explosion particles and the QMB explosion effect both enabled at the same time. That would make the explosions look intense! qmb_explosions 2 ? I noticed when adding in QMB, setting qmb_rocketlightcolor
qmb_explosionlightcolor works possibly identically. Hm, qmb_explosiontype 1 keeps the sprite, but gets rid of all particles in the explosion (no QMB particles, and no regular particles either).
And standard QMB_bubbles are invisible when I play online, but they are visible when I am playing my own local multiplayer game. But, qmb_trail_spike produces the underwater bubble trail both online and not. @nightfright, dwere
re: keyboard Do I need to do anything with in_keymap 0, or is in_keymap 1 fine for both of you? Need input on this issue, since I am USA keyboard user and not super-familar with keymapping likes/dislikes/etc, other than listening to conversations in the past when I implemented a somewhat similar solution in a different engine. Oh, qmb_explosiontype 0 makes both the sprite and the QMB explosion particles. A setting of 4 does likewise.... Maybe 4 is not valid, and it's just going back to the "0" setting. But 5 hides the sprite again, hmm.
I'll keep testing and see if I can tell a difference in other settings..... But 0 is just what I needed. bubbles: invisible online, visible offline
Are maps vised? This is all client side. If your server isn't sending the sprites to you because the maps aren't water vised, you don't receive them. By definition, since QMB is client-side Bubbles are sprites, not particles qmb_trail_spike produces the underwater bubble trail both online and not The spike bubbles are a client-side manipulation where they are emitted as particles, but no real sprite ever existed. However, subject to the same conditions as first case. If the server doesn't send you the nail spike, no trail would be emitted. It probably just seems different because you were underwater at the time? re: Explosions
(Doesn't mean I won't consider it for a future version 2 --- I agree with what you say about the weirdness of sprite + QMB explosion sprite but no particles --- but testing JoeQuake it works that way too I don't know why, but it's definitely not showing the QMB bubbles when I'm connected to the FvF server -- the ninja actually throws out a row of bubble sprite bombs, so I can do this even out of the water. They are visible when locally running my own game, but invisible when connected to the FvF server. qmb_bubbles 0 makes them come back as the usual sprites (HQ replacements, actually).
Hm, there's something odd happening. I ran my own dedicated proquake server and connected to it with Mark V, and the QMB bubbles show up, but they move very choppily... like, uh, non-interpolated motion or something. Ok, I reset the level on the FvF server and now the QMB bubbles show, but again, very choppy movement. The regular bubbles move smoothly.... Connected to a different (non-fvf) server and got same result. Well, more testing will have to wait till tomorrow. If you wanna compare, connect fvf.servequake.com I left it on e4m3 where there is a nailgun right in the start room. Just select ninja class and use that gun to throw out a row of bubble bombs, and see how different it is with qmb_bubbles on or off. Or go jump in a water pool.... The nail trail bubbles move smoothly. Record a demo of it (tell me the clock time I should look at). I'll play it back. I can't debug connected to a server, I stop execution to examine, I'd lose connection.
I have a working theory that goes like this: there may be something in the renderer that isn't being reset to base state. Would seem to be a fit for what you describe, but isn't necessarily the case. But if it is a renderer state issue, I may not be able to replicate it easily because it depends on a very large number of factors. With a demo of where you say you have the issue, my first goal would be replication (which could be the hard part! Could depend on your settings, like even things like overbright or gl_fullbrights or what things you have turned on or off or what external textures, if any are loaded and what entities are on the screen). /Whenever I end up doing a future incremental upgrade (like a 1.1 or what not), I would likely implement a state manager and this could never happen. I already have a different engine with a state manager (Engine X, which is a few years ago) and it unearths lots of scenarios where the states are not reset. I haven't tested 1006 or 1007 yet, but in general, the only thing I noticed was the tilde key. I am playing Quake mostly with numpad keys (the block on the right keyboard side) which isn't affected by these changes.
Will try with the newer builds soon, but basically, the default behavior should always be the tilde key for console. Bubble demos:
http://fvfonline.com/bubbles.zip The bubbles are weird. I get the same result in JoeQuake. They work fine and smooth locally, but when connected to a server (even a server running on the same computer), they are very choppy, or if the level has been running a long time, the bubbles just don't show up at all. The effect is seen in the demos based on the settings you make while watching it. I thought maybe the difference might be that a proquake server would be protocol 15 and a local multiplayer game would be 666... But nope, that doesn't seem to make a difference.
Also, I tried running a dedicated Mark V server. DX or GL versions seem to start up and do stuff, but then the window instantly closes.... So I ran Mark_V_Winquake -dedicated, and the server window ran fine. But then doing "connect local" or slist or find local multiplayer game in the menu does not work in my Mark V client. connect [local ip address] works fine. @coburn -- there are a few interfaces for internal things that aren't meant for users (just for me for testing) that I need to make unavailable. You found one of them.
Mark V has the ability to read, write, edit pak files for future hub system for single player that want fully re-entrant maps (that requires no special QuakeC support!) -- so it needs to save the state of several maps. Not meant to be available to the user. @Gunter: connect local doesn't work It's "connect lan" ;-) "connect lan" doesn't work either.... "no lan quake servers found"
Connect 192.168.254.15 [lan ip on same computer] does work. Let me know if "connect lan works" on Windows XP. Mark V acquired Spiked Quakespasm's rewritten networking -- it uses some Windows networking capabilities that weren't available until Windows Vista, and uses a fallback on Windows XP.
If don't know if you are using Windows XP SP1 or Windows XP SP2 (or whether it SP2 makes a difference in this case). @gunter - gl_overbright_models 0 + no alpha transparency
The rendering code is a complex twisty path. @gunter --- -dedicated issue with GL fixed.
Bubbles -- hmmmm I know what is going on with the gray particles not appearing. Need to decide best way to address or maybe even make an extra qmb_ option to control behavior.
One way or another, later today you'll have those gray particles back. Windows XP Service Pack 3
Uh... what grey particles? Oh, was that about the chaingun weapons? It would be nice if they made sparks like when a nail hits the wall. My ninja bubbles are definitely sprites (I did the standard water drowning bubbles in the demos too). I usually use a replacement sprite texture though. Actually, I mentioned in the past, the replacement sprite texture that is included in the Quake Retexturing Project comes out as invisible in Mark V DX, so I had to alter its opacity. In any case, I've tested this new bug just using the standard bubble sprite too, so it's not the previous issue (qmb_bubbles replace the sprites anyway). Yeah, s_bubble.spr is pale blue, usually. When I watch bubbles1.dem I can toggle qmb_active 1 and the bubbles instantly go invisible, but they re-appear as soon as I set it back to qmb_active 0.... In both DX and GL versions. Were the qmb_bubbles invisible for you in the bubbles1.dem? And did they appear to move really choppily in bubbles3.dem? Oh my... yes, I can imagine the twisty mess of code that's doing transparency in DX, because I'm getting strange results. But transparency DOES work even with gl_overbright_models 0 For example: r_viewmodel_ring 1 external_textures 0 gl_fullbright_models 0 grab a ring (e4m6 has one at the start) and your gun will be opaque... But not the axe. The axe is alwys transparent. But no other gun. Unless you activate external_textures 1 (and you actually have replacement textures). Then all your guns are transparent.... Setting gl_overbright_models 1 also makes everything correctly transparent.... For clarity, can I get demo name + time into the demo for each separate issue so I don't miss one.
Like bubbles1.dem @ 18:45, etc. Here is what I'm going to do
If an alias model (.mdl) has I'm going to force fullbright + overbright off for the rendering. That will make your DX8 transparency look pretty much the same. Will probably add an unsaved cvar to disable the behavior, merely for possible future rendering testing purposes. But this will effectively remedy the DX8 The demos are very short, and it's all the same issue -- qmb bubbles being weird. Though there are two different, related weird behaviors.
The issue starts out as the qmb bubbles moving very choppily, and after the map runs for a while, they just become completely invisible. This only happens when connected to a server. I tested these demos on my older WinXP laptop and I see the same result in both DX and GL. bubbles1.dem -- shows the qmb bubbles being invisible. This should be dramatically obvious -- just watch it with qmb_active 0 (or qmb_bubbles 0) and you will see that the ninja throws a row of bombs using the bubble sprite. Then turn on the qmb bubbles... and you won't see them anymore. bubbles2.dem -- just shows that the qmb bubbles work correctly when not connected to a server. bubbles3.dem -- the qmb bubbles are doing the choppy movement. It's like the engine is struggling to render them or something.... Again, just watch with either qmb_active 1 or qmb_active 0 to see the difference -- the standard bubbles move smoothly. Hmm, I wonder if maybe the qmb bubbles look choppy because they are invisible PART of the time.... Wait a minute... I wonder if this has to do with ticrate... let me test. Yep, that's it! Mark V's rendering of the qmb bubbles is somehow affected by server ticrate. I can imagine if that gets out of sync, it could be drawing them invisible when it should be drawing them visible, or something.... The standard bubble sprite rendering doesn't suffer from this - they seem to move smoothly. Yeah, when I'm connected to FvF with a Adjusting the ticrate to Ohhh, another possibility: since QMB is replacing the bubble sprite with an EFFECT, perhaps the movement of that effect is not subject to motion interpolation, which is why it seems to jump along at the ticrate instead of moving smoothly? That wouldn't quite explain the complete invisibility though.... And other effects seem to move smoothly.... Like the underwater bubbles from explosions or nails -- they move smoothly. These things you are discovering me always aggravated me about QMB back in earlier times.
I'm going to see if I can fix them by rewriting the code to be more precise about what happens. I may be able to fix the bubble lerping interpolation too, great job thinking about that -- makes a lot of sense. The problem with how QMB was written is that it wasn't too friendly with what modders like to do and somewhat inconsistently changes the modder's intended particles, and in a way that appears random. Time to replace that with some sensible consistency that can also be turned off ;-) dwere, what Malice monster is the one that you are saying is multipart and only renders consistently in WinQuake and Enhanced WinQuake, but not even Mark V WinQuake.
Is it monster_banshee? I'm having difficulty locating one in game? Is there a certain map it appears on. Want to inspect that. "and somewhat inconsistently changes the modder's intended particles, and in a way that appears random.
Time to replace that with some sensible consistency that can also be turned off ;-)" Indeed. I added a new short demo to the zip called splash.dem, to demonstrate an example of just what you are talking about, involving a blue particle water splash effect I made. Hopefully this is one of the issues you can address: http://fvfonline.com/bubbles.zip Just watch splash.dem with qmb particles disabled, then watch it with them enabled to see..... If the monster in question is a banshee.
On map d12, I am at 2812 -668 -104 and looking at one. You can type setpos 2812 -668 -104 after loading d12 to teleport there. It looks fine in the opengl version and the winquake version. Is it a different monster with issue. Or a specific map. A save game or demo would be useful, I can't seem to recreate the issue. @gunter --- when you were doing the auto-connect test earlier were you using port 26000? Doesn't change that the Spiked Quakespasm networking code prefers Windows Vista and later operating system for best results and certain enhanced features, but server auto-detect requires server using port 26000.
Is it monster_banshee?
Yes, it's one of them. The other one is called "Takahiro Rider" (don't know the internal name). Off the top of my head, a banshee can be found on d8.bsp. Cheat yourself keys to speed things up, go to the yellow lift. You'll end up in a big square room. The banshee mech is gonna be revealed when the middle section opens. Sorry, should've told that earlier. Yep, default port 26000
I don't suppose these monsters you are looking at have skins with alpha transparency? That caused my replacement bubble sprite to be invisible.... You can type sv_novis 1 for that map to make even the top part of the monster visible in that room.
The upper model (banbody.mdl) is highly unusual as it is highly above the model centerpointer ("the origin" in QuakeC). On the server side, I think it thinks that part of model is in the ceiling. A can't change how server side visibility works, it would potentially bust modern compatibility with modern map releases. Mark V WinQuake tries to handle it like the GLQuake engines for consistency. /At some point, I might do some more thinking since technically "WinQuake is, by, definition actual Quake" -- but in practice, the GLQuake engines have been the dominant ones for 15 years -- which is why I made Mark V WinQuake handle things like a GLQuake engine. It isn't immediately clear if there is any change that could resolve this without breaking something else as a side-effect, but many times after thinking about things for a few days I might get an idea. I was hoping using NightFright's Malice I also experienced this back then when I was testing Malice by myself. However, I was focussing on the showstopper bugs that had still exited back then.
In case you don't find a way to solve this, it's not the end of the world imho since the addon itself remains quite playable. Which is quite something. I've already outlined possible solutions.
I do not like incompatibility. I want the engine to be able to play everything the way it is meant and the way it worked with original Quake. I'm hardcore about that. The qmb lighting bolt has transparency problems with vid_hardwaregamma 0
The lower your txgamma setting, the more noticeable it gets. Or maybe just modifying the setting makes it stick out more.... Just shoot some lightning and do a freezeall and you'll see what I mean. Actually, now that I'm looking for it I can see it faintly when using hardware gamma too -- it's just more noticeable using txgamma. But the view blends... the view blends look PERFECT when using txgamma.... Not too dark, not too light. I guess gamma adjustments really mess with those. The axe is alwys transparent. But no other gun.
Axe is the one gun without fullbright pixels, so probably follows a different codepath that doesn't use the fullbright mask. What metlslime said.
@gunter If you say it works, fine -- I'll apply lerping to all sprites. I honestly don't know of any moving sprites in any mod except yours, makes lerping of sprites real hard to test
Go into the water in e1m4, the air bubbles coming from the doorway on the right side are moving spirtes, I think? The player makes them when choking, too. @ericw -- e1m4
@dwere - sv_setmodelrealbox 0 -- before map load gets the job done. Is no doubt an ok setting for playing the entire Malice mod. Like "game malice; sv_gameplayfix_setmodelrealbox 0" in console which reverts to ancient style WinQuake culling boxes. sv_gameplayfix_setmodelrealbox defaults to 1 (1 = FitzQuake culling/physics box, 0 = WinQuake culling/physics box). That banbody.mdl model is pretty awkward, I don't if it thinks it is in several visibility leafs or just all the ones it thinks it is in are wrong or what. Download at normal location:
http://quakeone.com/markv Changes 1) Removed all the internal testing commands except "dir" (c0burn). 2) DX8 build: equivalent 3) sv_gameplayfix_setmodelrealbox 0 improved for Malice (dwere) 4) Sprites like E1M4 bubbles are now lerped (gunter). 5) QMB bubbles should behave like normal bubbles. (gunter). 6) Autosaves are named auto_save_0.sav to 2 7) GL/DX8 version can do -dedicated again ok. /Typing "version" in the console will show as build 1008. @metlslime - the more sprite examples the better. ;-) @gunter - Pay close attention to sprites and if you could, could you give the WinQuake build a look too. I don't expect problems, but without a lot of live testing, I'm always suspicious of any change. @dwere - This Malice multi-part model on d8 map is a great compatibility test case. First example I know of where FitzQuake bounding boxes cause unwanted culling. It is extremely rare and due to that, hard to find any examples at all. Conversely, Mark V WinQuake adopted FitzQuake bounding boxes as part of first version because it solved a glitch in the X-Men mod where items disappeared if you stood in the right place. sv_gameplayfix_setmodelrealbox 0 - WinQuake (-16 xyz to 16 xyz) 1 - FitzQuake (measure model, default) For Malice, set sv_gameplayfix_setmodelrealbox 0 before loading a map or save game and everything should be great with any multipart models. Next update will contain: 1) Alpha channel support for 2D replacement textures, current support is alpha mask only (yes/no). 2) Rewire QMB to be more consistent with particles and be able to turn precise particle behaviors off. (+ alpha channel issue with txgamma) 4) Sprites like E1M4 bubbles are now lerped (gunter).
5) QMB bubbles should behave like normal bubbles. (gunter). Uhhh, the first thing was never a problem. It was ONLY the qmb bubbles that were being weird. All other sprites were always fine and smooth-moving. So I don't know what you fixed, but you might wanna un-fix it to be safe, heh. The second things is definitely improved. The qmb bubbles now move smoothly, BUT the "sometimes invisible" issue still remains. I tested on the actual server and in the previously-recorded demos I made. So, if you watch bubble3.dem now with qmb bubbles, they will move smoothly. But with bubble1.dem you will see no bubbles at all.... This is a tricky one. All I know for sure is that if the level has been running for a while, the qmb bubbles are no longer being drawn. Resetting the level brings them back.... I'm going to try this locally by leaving Quake running for a while to see if it is just an issue when connected to a server. Hm, things now render transparently no matter what the gl_overbright_models setting is, BUT now gl_fullbrights affects them the same way: gl_fullbright 1 = most weapons opaque (not axe) unless using custom textures (must be as metlslime said, and the custom textures don't contain fullbright pixels). Illusionary ent guy is also opaque. gl_fullbrighs 0 = everything transparent, including illusionary guy. Also, toggling external_textures does not affect sprites (like the bubble and light ball sprites in id1\progs\) until level change. Mmmkay, verified: after running a map for 35-40 minutes, qmb bubbles become invisible.
Tested on e1m1 and reproduced. Go stand by the mega health and jump in the water and drown a little bit. Watch your QMB bubbles pop out and float above you. Now sit there and idle for 40 minutes... You don't need to do anything else in Quake. Now jump in the water and drown a little more, and you won't see any bubbles unless you disable the qmb effects. Oh, you don't wanna sit there for 40 minutes to test this? No problem! Just set host_timescale 100 or 1000 and run the clock up to around 40:00 and you get the same result! Isn't that weird? Ah, it's easier to test by going to e1m4 in single player, noclip, notarget and go stare at the bubbles underwater. Mess with your timescale.... I have found that the qmb bubbles go away like clockwork at: 34:08 QMB Bubbles: "This level is taking too long! I'm outta here!" 34'08" = 2048 seconds, or 8*256. Sounds like a pretty significant number to me. Does it give you guys a clue?
Ooo, good catch. I never would have considered that.
Hmm, I have no idea what the engine code looks like, but just making a complete guess, perhaps if there is some property of the qmb bubbles being set by: time / 8 then once time gets to 2048 or higher, that calculation produces a number of 256 or greater, and that might be "our of range" for some Quake calculations.... Like particle color generally ranges from 0-256, but it wraps around so that 256 is treated as 0, 257 as 1, etc. Temp Build before I continue trying to clear queue
http://quakeone.com/markv/mark_v_1009.zip - DX8 - Removed sprite lerping, since it produced no rendering difference. /Temporary middle point before build 1100 @gunter - Live toggle of sprite textures --- would be too time consuming (15 hours), mostly because I never thought of sprites when writing the live external textures toggle. Maybe someday.
I'll see what is going on with 34:08 too, while I'm getting QMB pacified. The scr_showpos 1 crash on startup has returned....
Hm, I have to set either gl_overbright_models 1 OR gl_fullbrights 0 to get transparency. And the transparency looks very different depending on which one I set. With gl_overbright_models 1, no matter the fullbright setting, things look much less transparent. Hm, yeah, it's like the gl_overbright_models 1 effects is being drawn on top of the gl_fullbright 0 effect. On the positive side, I like having all the exes in only one zip file to download, instead of separating them like on the Mark V web page ;) scr_showpos 1 crash on startup has returned
Are you sure? Can't reproduce. Does "version" say build 1009? If you are getting it, what method are you using to set it? Did you add to command line or autoexec or config.cfg? The difference between different combinations overbright_models on/off or fullbrights on/off doesn't relate to the model drawing in 1009.
It is a difference in how the map itself is draw, and what draw method is being used for drawing the map. And gl_fullbrights affects what rendering path is used for the map. The Ok, real Build 1009 in the zip (instead of 1002, however that happened).
http://quakeone.com/markv/mark_v_1009.zip Awesome. I wanted to permanently bury all the small items before reworking QMB some because it may be slightly complex.
I just wish there was some way I could make use of transparency.... Such a cool effect, but mostly unused.
I think it's cpu related.
Also, the stuttering doesn't occur at relatively regular intervals like I first thought. Generally, the more action taking place the more laggy it gets. Sometimes, the game will launch in a laggy state and have to be restarted. Also, I have it capped at a 60fps (72 felt like 15). All software/hardware cpu power management settings, c-states, EIST, turbo mode, etc. are all disabled. Disabling OS core parking helped quell the stuttering, but it's not a total fix. This is on a 4790k at stock speeds. On your beastly machine, it's only input lag right? I might be able to do something about that if it is just input lag.
Frag me --- that download I linked for the codec pack is 983 MB of bloatware + cruft + corporationary non-sense.
It wasn't like that a couple of years back. Going to link a codec pack is **just the damn codec ***. input does lag somewhat when the stuttering occurs, but that isn't the main issue. visually, it looks like frame loss (like down to 10-20fps or so) but the fps counter doesn't budge. I've also experienced total loss of sound on one occasion, I don't know if it's related.
And on this Windows 10 laptop I'm testing this out on, it doesn't even make the codec available as far as I can tell.
What nonsense. What does the Open GL version do? If the Open GL version doesn't have this kind of issue and the WinQuake one does, that tells me something.
Huge difference on how they update the screen. On the Mac version of Mark V, it actually uses the Open GL method of drawing in the software renderer. no issues withe the gl version. Also, the stuttering occurs when viewing demos as well, this might rule out input being the culprit.
1920x1080
I didn't mention this earlier because I have to do more testing, but the screen stretching may have an impact... or maybe it's more obvious when enabled, I'm not sure yet. http://i.imgur.com/mZrY3ws.png
http://i.imgur.com/1hujKqG.png Looks like some of the flame polygons aren't being removed when the particle flame is enabled. You noticed ;-)
It's a temporarily measure that is supposed to be hard to notice. QMB needs a flame.mdl without a flame. I can't roll up flame.mdl and include in the binary because flame.mdl belongs to id Software and is not licensed as open source. My temp measure was to shave off verts above a certain point until I determine best way to have Mark V conditionally render flame.mdl in 2 different manners. I will probably do this at some point in time by detecting unwanted verts via texture coordinates by haven't done this yet. If you are 100% sure GL that the GL version never has the issue, this is likely solved if the issue is buffer transfer.
I wouldn't overthink it. I don't know when I'll have time to rework it, because it is a bit of a time consumer (might take 20-25 hours). It's always been on my list do because then WinQuake gets Open GL's vid_vsync capability. That being said, you might try a lower resolution far closer to the original and it might work just fine right now.
1920 x 1080 x 24 bits per pixels is a lot of buffer transfer going on every second. Open GL was built for that. Windows API? Don't know. Lower resolution might help quite a bit. Or might not. I've spent far less time in the gl version than the software version. I'll play the fuck out of the gl version tonight then get back to you. I don't want to give you false info thus sending you on a wild goose chase. I appreciate your time and this engine. I played both Beyond Belief and Dimensions of the Past with it and it was a real treat!
Thanks for the headsup, Johnny. In this particular instance, I noticed the oversight after I uploaded it but since this is a temp build not linked as main download anyway, I figured I'd wait until I had the "non-temp build" done. ;-)
If Mark V supports shaders, you may want to try Seven's new_torch model found here: http://quakeone.com/forums/quake-mod-releases/finished-works/11595-a.html
Looks great and works like a charm (at least in DP). Uh --- Mark V certainly does NOT support shaders. And certainly never will support them either.
Do you have the slightest clue what dwere was posting about? No? Ok -- now get lost. /You are nice guy, but my tolerance for incompetence in a technical thread is zero. Don't do it again. I ran through an episode with the gl version and it performed flawlessly. It may be safe to say that this issue is winquake specific.
I'd like to draw your attention to another curiosity, not because I'd like it changed necessarily, just interested to know why it is: I like to use a faithful q1 viewwmodel fix that tweaks some verts and alignments. As you can see in this comparison, the texture alignment appears to be off even though we know it isn't (in winquake). Yeah I doubted the entire Divx suite needed to be installed hah.
Anything you want me to test as far as my black capturedemo issue? As far as the sound issue where there was noise...I think 11k has noise and 41k does not. But at 41k the sound is "airy" for lack of a better word. QS does not exhibit this behaviour but it looks like it uses different method for sound processing? Unrelated but using your advanced demo playback features to watch retrojam5 demos is a godsend. Changes everything! As you can see in this comparison, the texture alignment appears to be off even though we know it isn't (in winquake).
Software Quake and GLQuake treat MDL texture coordinates slightly differently. This is a giant PITA for me, because a model tweaked for one set of engines will have broken alignments in another. I rarely miss an opportunity to rant about it. BTW, it's funny how even a stock id model works better in a GLQuake-like engine. software rendering uses affine interpolation when drawing mdls, because its simpler/faster.
whereas brush surfaces use proper perspective correction by recalculating the texture coords every 16 or 8 pixels (d_subdiv16). (quake2 added perspective correction on its md2s. I believe this to be the reason why quake used bsp ammo boxes while quake2 was free to use md2s instead) glquake has an 'gl_affinemodels 1' cvar setting that asks the driver to replicate software rendering's crappy interpolation. however its one of GL's 'hints', which means modern drivers just ignore it and always use proper perspective. if you have glsl 130 (gl3), there is a 'noperspective' interpolation modifier which ensures the same appearance. I should probably add that I was talking about a different problem. So there are at least two ways for a model tweaked for GL to be screwed by software rendering.
I get a very consistent crash when trying to switch back to DX Mark V after alt-tabbing away, when I am running full-screen with vid_hardwaregamma 0
It does not occur with the GL version, or when using vid_hardwaregamma 1 It also does not occur if I am just sitting in the console before loading a map. It also crashes if I am running it in a window and I try to adjust my windows gamma settings under the same circumstances above. there are at least two ways for a model tweaked for GL to be screwed by software rendering.
That's both hilarious and sad :/ @spike - that is interesting. given quake's initial low resolutions and non-interpolated animations, they might as well have just used sprites. They would've been better looking and probably easier to do. I suppose they pushed the tech knowing that appropriate hardware was just around the corner. The skin application in GLQuake and WinQuake are different. See the argument in the Quakespasm thread (it's buried), the different viewpoints and the final consensus reached by the developer types and mappers.
@re: GL runs fine Awesome! Provides me with a little bit more incentive to build a Windows "WinQuake rendered via Open GL" like the Mac WinQuake Mark V. WinQuake rendered via Open GL
that has a nice ring to it. aside from the mac version, is that a first of its kind in terms quake ports? As someone who is exceedingly detail oriented, I give myself an F-- on the DivX download.
I'm very upset that I didn't investigate the current download (I trusted them!). That download is complete trash, I just assumed since I always used that page that the downloads were quality and not corporate bloatware. I am sorry. When I release Build 1010, I will be updating the Mark V page with 2 proven reliable codecs (Google WebM) and the *real* XVid minimal (fast as hell). On a positive note --- 2 Windows 10 machines --- capturedemo runs with flying colors with a proper codec installed. /Why do some machines --- using Quake 11025 sound hz sound terrible and need 44100 just to sound ok? While other machines original Quake 11025 sounds just fine? Peeve of the day. Not exactly, haha. Read the "Mac Version Based On Fruitz of Dojo" on the Mark V page.
They invented it ages ago (2002?). It's a wicked idea and I've always liked it. I wrote engine tutorials on demo rewind once and made working examples. qbism used it as reference to add demo rewind in Super8.
In Mark V, I went a bit obsessive and redesigned the FitzQuake 0.85 animation interpolation on just the client side to be completely reversible. /Let's just say I like demo rewind Can't reproduce. I used vid_hwgamma 0 and did several different things with ALT-TAB with maps running.
I use Alt-TAB and ALT-Enter all the time. Does happen with clean install? What map is running? What mod is running? What does the Dr. Watson report say is complaint (if that applies in this case)? I don't know too much about the internal wiring of the Direct3D wrapper. Something to keep in mind, may or may not apply here, the Direct3D wrapper has been in use for ages in ProQuake (and it got a lot of use for "Open GL crashes/bad drivers"). I think I always kept the -gamma texture command line parameter allowing opt out of hardware gamma. I'd recommend "developer 2" and then upload qconsole.log and maybe I'll see something. What I do know is this Does this happen when you start game in id1 when there is already vid_hardwaregamma 0 in quake\id1\config.cfg. In windowed mode, with vid_hardwaregamma 0 and gamma set, I can't think of anything obvious.
Windowed. ALT-TAB little different than using the menu or pulling up the console except the loss of keyboard focus. On Windows in really rare situations. Do you have 2 copies of Mark V open? I could possibly see something as possible there, yet I've done that a hell of a lot. Fullscreen. There are more potential things that could happen with ALT-TAB. Are you connected to fvf.servequake.com or running -FVF or can this happen with clean id1? As far as I can tell, in fullscreen mode it would always need to reload all the textures /But you say this happens in windowed mode. It doesn't need to reload textures or recolor skins or anything in that scenario. This sounds like lost device handling somehow got broken.
In D3D terms, a "lost device" is what happens when you Alt-tab away from a fullscreen mode, but it can also happen under other circumstances (power-saving transitions, etc) and Microsoft don't document them all - primarily because it's actually impossible to (3rd-party software/drivers/etc may trigger a lost device for internal reasons of their own). Changing Windows gamma while running in a windowed mode sounds like one of those other circumstances. Changing the screen resolution while in a windowed mode would be another. The important take home is that naively detecting if an Alt-tab has happened is the wrong way to go about this. Instead you check the HRESULT from your Present call, if it's D3DERR_DEVICELOST you issue a bunch of TestCooperativeLevel calls until you get D3DERR_DEVICENOTRESET, then you release all default pool resources, Reset the device, then issue another bunch of TestCooperativeLevel calls until you get D3D_OK at which point the device is no longer lost and you can recreate the default pool resources. Typically you'll get a crash if there is a default pool resource not released (more typically the Reset call will fail). Hopefully that's sufficient info for Baker to troubleshoot. A good test to reproduce might be, like I said, try changing the Windows display resolution while running in a windowed mode. That should trigger a lost device, then trace through the code with breakpoints on the TestCooperativeLevel and Reset calls. MH: Hopefully that's sufficient info for Baker to troubleshoot.
Baker: Gunter He also say for best laptop maintenance, you should run laptop through dishwater once a year to clean keyboard. The drivers I have on Win 7 don't seem to care if I play with the gamma in Windows while DX8 is running. Fullscreen or windowed, vid_hardwaregamma or not.
I even changed the video mode in Windows after ALT-TAB out of dx8 both in windowed and fullscreen -- it didn't care at all and continued on.
My DirectX drivers would be quite different on Windows 7 vs. Windows XP, I would imagine. Ok, more testing.
Started Mark V DX clean, no config.cfg, no external anything. It defaults to a 640x480 window, and the standard demo starts playing (though I find if I stop the demos this behavior doesn't change). Then I click away from the window and adjust my windows gamma = crash. Dr. Watson says "Access violation." If you can tell anything from this, the chain of things Dr. Watson lists are: dx8_mark_v.exe - iglicd32.dll - igldev32.dll - uxtheme.dll - etc. Last couple lines in qconsole.log: Accessibility keys enabled Hardware change detected But those things happen as I switch focus away from the window. Repeat experiment with GL version = no crash. Repeat experiment on older WinXP laptop, and no crash, but I notice a difference -- on my Netbook I am using a system tray icon that lets me select a pre-saved scheme for my gamma (and probably other settings). When I apply that, the whole screen flashes black for a moment. My older WinXP laptop doesn't seem to "Reset" everything like that when I just adjust the gamma. And I find that if I actually go into the video control panel on my netbook, I can simply adjust the gamma slider without anything bad happening too.... So it's not really gamma, but when my display settings get... "reset." I find I get the same screen flash + crash if I alter my color depth or resolution (yep!). Doing all these things on my older Win XP laptop = no crash. Now for alt-tab in full screen testing.... I'm finding that now any alt-tabbing of fullscreen DX (not the more specific circumstances I previously mentioned) is crashing it. And once again my older WinXP laptop handles it fine, as does the GL version. So it seems that my netbook is doing some kind of harder reset of the display settings perhaps? Along with that stuff mh said. Small chance that if you turn off Themes in Windows XP, may avoid the over-protectiveness.
http://www.pcauthorities.com/windows-xp/disable-themes-in-windows-xp/ I forgot/neglected to mention - the Direct 3D driver model is very different on both OSs. Remember back in the dark days of Vista and Direct 3D 10, when Microsoft wouldn't make it available on XP? The different driver model is the reason why.
So it's XPDM (XP-) versus WDDM (Vista+) and WDDM is going to be more robust against crap like lost devices. To make things even more interesting and fun, AFAIK D3D8 or lower don't even natively exist on Windows 7/WDDM (don't know if the same is true for Vista) - they're instead emulated through a D3D 11 layer. Likewise the old fixed pipeline doesn't natively exist anymore but is instead emulated via shaders (this is true even of D3D9 on XP). So bottom line is that of course certain behaviours on XP and 7 are going to be different, and 7 is not a good testing platform for XP clients. microsoft tweaked their video memory routines for vista. before that they'd purge video memory on a whim - without even telling the gpu driver iirc. with vista, their compositor required them to not randomly wipe all gpu memory, which also means that earlier versions of d3d are less aggressive at randomly wiping memory, at least when running on vista+.
opengl drivers worked around it by retaining a copy of all their textures in host memory as well as on the gpu (which comes in useful when there isn't enough gpu ram), hence how they're able to recover properly on xp. you can still get lost devices. opengl has an extension for it (and may still tell you about task switches so other programs can use video memory while you won't need it), and its part of the vulkan spec, but its much rarer that its fatal, enough so that you can afford the extra time taken by a full vid_restart (though you should probably not destroy the window itself). typically it only happens (in vista+) when a driver is uninstalled or reset (the gpu crashed/stalled for 2 secs). Its also quite easy to crash a gpu with dodgy vulkan api use... To be honest, you would at this stage get better compatibility lifting the wrapper to D3D9.
I know that sounds counter-intuitive, I know that you're all about compatibility, and I know that you view the D3D wrapper as a means of providing compatibility in the face of deficient GL drivers, but using a lower D3D version is not necessarily the best way of doing this. It's not necessarily even a good way of doing it. Take note of what I wrote above, paying attention to the part about D3D8 or lower no longer natively existing. That's hurting you and it's hurting your users. Reality is that D3D8 was only a short-lived stopgap version between 7 and 9 whereas 9 was the mature, well-supported version that had a lifespan of over 10 years. Lift it to 9 and you still get compatibility with XP, Vista, 7 or higher. Stick with the fixed pipeline on 9 and you'll get compatibility with hardware that even pre-dates D3D9. A lot of crap like your testing not being valid or your inability to reproduce bugs will just go away. Yeah, why you wanna hurt me with D3D8 Baker??
Heh, well, disabling themes seems to make no difference. But I get inconsistent results in testing.... Now it seems like if I alt-tab from just sitting in the console, it will crash, but if I alt-tab while a map is running, it works? I was trying various things, like toggling the value of vid_hardwaregamma and sometimes it seemed like that was making a difference.... But now I'm not sure if that was it. It works sometimes, and sometimes it doesn't. Currently it seems like trying to do stuff (gamma change or alt-tab) either in console or with the startup demo running = crash, but if I load a map, then stuff works. But I'm certain it has crashed before even when a map was running and I tried to do stuff.... So yeah, this is probably some back-end, obscure DX stuff which mh seems to know a lot about. I fall in the Applied Sciences camp (build bridges, highways). Knowledge for the purpose of building something and only for a specific goal, almost always must be part of the plan. Live by 90/10 rule.
I'm not going invest 6 months of learning Direct3D for (mostly) 1 computer that is 10 years old. Many, many times I do fall into agreement with the Pure Sciences camp (you and Spike) The Open GL is the main hardware accelerated build. The nicest thing about the Direct3D 8 wrapper for old computers I'm not a pure knowledge guy, I'm a "I have well-defined goals" guy. Plus I'm just one guy. My goal is single-minded pursuit of finishing. "Real Artists Ship!" I know that must drive you a bit crazy as a perfectionist, who is probably doubly annoyed that some of these things are your speciality (Direct3D, optimized rendering) ;-) /And those like Gunter will be pretty happy with the results, even if he can't play with Windows gamma while the DX8 version is running. The other nice stuff (next update QMB) will make he not really care that much ;-) I would lean towards it being a sound driver or Windows bug.
I hit a similar problem with SDL2, with just one of its audio output backends (xaudio2) producing distorted audio at 11025Hz; the others (winmm, directsound) were fine. https://bugzilla.libsdl.org/show_bug.cgi?id=2551 I know that's not directly helpful.. Bloughsburgh - if you are up for more testing, it might be worth giving Fitzquake 0.85 and the original id winquake.exe a quick check - both of those will also output at 11025 by default, and I expect they will have the same distortion that Mark V does, if it's indeed a windows / driver issue. I know that's not directly helpful..
Sure it is. Your knowledge of audio vastly exceeds mine. Tells me I'm not going insane when I test on a random Windows 10 machine and that specific one, the audio is horrible and the others aren't. I tried winquake.exe and it appears to have distortion but I felt it to be less pronounced than Mark V. That could be placebo it is hard to tell.
The worse problem is the echo/airy sound when sndspeed is set to 41k. It is hard to explain through text so perhaps I will record a video and you can hear from there! Finally got the Mac build basically caught up
Travail screenshot Except I have some keyboard surprises to iron out. Still, was a relief when I typed "install travail" and no surprises there ;-) I tried to code the downloader as platform neutral, but wasn't quite sure it would work first time, but it did which is unusual when coding in C). Think I'm going to get back to QMB particles before I mess with the Mac input code more. Also didn't test out ipv6, "connect lan" or such and I want to rework startup. I doubt this is involved because you posted part of log before and it looked right, but its 44100 (-sndspeed 44100).
Just pointing this out since you typed 41k. Open GL Mac with QMB option
Quake level networking and direct Quaddicted install (i.e. "install travail" or what not in console) and about everything else is rock solid. But for some reason a couple of enhanced networking items like IPv6 had to be disabled (need to read docs, see if wrong headers or need to manually add some defines). Also, took a pass (for now) on rewiring the keyboard input for international keyboard and never anticipated WinQuake stretch as a feature so unavailable for the time being. The nicest thing about the Direct3D 8 wrapper for old computers
Ultimately, of course, this is your call. I think it's a bad call, and I think your reasons for making it are actually more theoretical than pragmatic: a whole bunch of "what if"s, in other words. Well, I will say this. And no obligation or anything
If you were ever interested either in upgrading the wrapper or writing a new one using Mark V, FitzQuake 0.85 or Quakespasm as the base (*) to do Direct 3D the way you think it should be done. Or implement water warp in whatever way you see fit I would acquire it into Mark V. If I had a huge chunk of time --- and I don't really have time to be doing even this, but it is lifting the regret of non-completion which was a large burden to carry --- I'm more interested in the Spike-like networking things like compression, prediction and peer-to-peer downloads than I am rendering. That's just the kind of thing I have been fond of over time as I have learned more about it. I know you love rendering and performance in a hard core way. So anyway, permanent offer that never need be redeemed nor made with any kind of obligation. Door is always open. (*) Mark V is intermixed with the software renderer. It may or may not be easy or ideal as a modding base. I've also partially reorganized code to be easier to work with (from my perspective) but it also makes it harder to work with (from other's perspectives). Add: Part of this, to me, was reduce all the accumulated bug-fixes ever known from Inside3d, QIP, Enhanced GLQuake/WinQuake, the Quakespasm thread, this thread, plus maybe 2 others I independently discovered (lerping of brush models that get moved in Quake immediately, interpolation immediately after load game) -- into a living engine.
Plus raid all remaining features from the well established classic engines of the past. Add some extra level of compatibility, then throw in a software renderer that can play everything Then most of the very nice engines of the past, with very thoughtful and intelligent authors each with their own specialities and point-of-view (aguirRe, Jozsef, JPG the ProQuake author) /Already then! Back to coding! This lines of code aren't going to write themselves "The nicest thing about the Direct3D 8 wrapper for old computers
Just wondering about this -- what old computer would still be running DX8? My XP laptops are both using DX9c, and Mark V won't even run on my Win98 computer (I tried! -- Mark V only complains about needing a newer OS). From what mh said, it seems the DX8 is already obsolete for any old computer that will actually run Mark V. I mean, I guess it works for the most part... but... I get the crashes. But I guess it would take a lot of work for someone to change it in Mark V.... The neat thing is that Direct3D 8 and 9 are very very similar APIs. A large amount of the work is just changing the number '8' to '9' in types; do that and you're maybe 80% of the way there. 8 has combined texture stage states and sampler states, 9 separates them, but that's not hugely different. That's 95% of the way there, and everything else is just cleaning up.
Tried the macOS version just now...
I have a folder named "id1" with the pak files inside it, right next to the Quake and GLQuake applications. When I run Quake it says it can't find the pak files. First I get a dialog that says this: Your Quake folder should contain a folder named id1 with pak0.pak and pak1.pak. Opening folder... When I press ok, it opens a Finder dialog with the folder that does indeed contain id1 and the Quake/GLQuake apps. Then it raises another error dialog with the usual "W_LoadWadFile: couldn't load gfx.wad" error, and also: Is Mark V in the proper folder? (/Users/iOS/Desktop/Quake) That path isn't where I have Mark V installed, and doesn't really seem appropriate for macOS. :-) Just for double-sanity-check I opened pak0.pak to see that gfx.wad was in there. Not sure where the problem is here. Ha OK, I went ahead and created a folder /Users/iOS/Desktop/Quake and moved id1 there, and it works.
From a quick code check, I think you compiled this with DEBUG active and that forced an unusual basedir. uhexen2/Quakespasm hit this recently: http://lapcatsoftware.com/articles/app-translocation.html
The short version is, you have to use Finder to drag-and-drop the Could be related.. the video mode setting is not saved. At start, it is always set to 640X480 no fullscreen.
My Logitech G13 is not working, while the normal keyboard works. No error or warning message. Within 24 hours there will be a far better Mac version than the early 2015 build.
I'll double check the 2 items (folder, resolution) during testing. Yeah, Mark V can't do Windows 98.
Microsoft added a lot of API functions in later Windows versions for files, network, possibly video. Mark V uses a lot of those. Mac + external keyboard.
I've used external keyboards with my Mac for testing since a Macbook Pro, being a laptop, doesn't have a numpad, was only way I could test behavior of key pad keys. I'm assuming a LogiTech G13 is a keyboard. LogiTech G13 is a small programmable keyboard. It uses Logitech Gaming Software for customising keys. The Mark V´s window version works fine with it.
GL or DX -dedicated still crashes, but not as quickly as before....
Ah, it crashes upon trying to load a custom bubble sprite. The following line never appears in the log if the custom sprite exists, because that's the exact point it crashes: Warning: FindFile: can't find progs/s_bubble.spr_0.tga Getting rid of the custom bubble sprites allows the -dedicated server to run. Minor note: The help info for hdfolder calls the command "hd_folder" Same with help _hd_folder Build 1010 with a Mac version should be available within an hour. I'll mostly waiting on my Mac to do some sort of update, and then make sure the revised code base compiles.
@johhny - in the previous version, I'm pretty sure I just did a Debug build for the Mac because was more convenient. I'm hoping there wasn't some other reason I did that, especially since QMB is slow as hell in a debug build. We'll see. @icaro - I have a couple of theories about your Logitech keyboard. I'll explain later, but both theories mean the Logitech keyboard + Mac may be unactionable by me in the short term. I have newly written input I wrote a year ago which would likely solve issue, but integrating that would be deeper than I want to go right now because might require 50 hours to do. At some point, the Mark V Mac build actually won't be based on Fruitz of Dojo at all. But to get there would require some serious time (200 hours) because I would need to rewrite the sound output code from scratch and some other subsystem which I can't remember right now. @gunter - next version doesn't touch QMB. I want to do that all in a single swing of the proverbial hammer. So yeah, -dedicated bubble issue with Open GL/DX8 will remain for this build. Which will have very short half-life if things go well. The skin application in GLQuake and WinQuake are different. See the argument in the Quakespasm thread (it's buried), the different viewpoints and the final consensus reached by the developer types and mappers.
Regarding Mark V: maybe it could be a cvar? The default value would be GLQuake-like for all exes, and toggling it would switch to software-like behavior, also for all exes. The point is mainly to have consistency between the software and hardware versions of the port. Is there a particular reason that my HUD is different depending on which executable I run? Do they store different config files or something like that?
http://i.imgur.com/Rcdwefm.png http://i.imgur.com/2TP7qzp.png I'll put that on the eventual to-do list. I know I'd like to see what that looks like. I can understand that since you like to remodel that you probably find it quite annoying.
Is there a particular reason that my HUD is different depending on which executable I run
Can you clarify that? Like what executable is A and what executable is B? I can understand that since you like to remodel that you probably find it quite annoying.
Well, one port being flexible won't really fix the situation as a whole, so I'm not sure how useful it will be. Still, I imagine most custom assets were produced with the GLQuake standart in mind, so having a software port that can display them correctly would be interesting. Or rather semi-correctly, since there's also the issue of perspective correction. Mark V has automatic HUD scaling, it is enabled by default and if its value is non-zero it will ignore scr_menuscale, scr_sbarscale, scr_conscale, etc.
scr_scaleauto must be set to 0 for Mark V to honor those settings. It's in the preferences menu, it's primary purpose of defaulting on is to avoid the microscopic HUD thing that has been prevalent in FitzQuake and derived engines. Temp Build
Build 1010 Windows: Open GL | Direct X 8 | WinQuake http://quakeone.com/markv/mark_v_1010_windows.zip Mac: Open GL | WinQuake http://quakeone.com/markv/mark_v_1010_mac.zip May take a minute before the uploads are completed. Sorry, I should have clarified in my post. The first screenshot is from mark_v_winquake.exe and the second from the regular mark_v.exe. Both are running the same config, which is why it seemed odd to me that they looked different.
I think I've figured it out though. It seems to be because I have it set to the Translucent mode, which is supposed to be GL exclusive and just makes the whole thing dissappear in winquake, which made me think it was using the minimal style instead. Ah, WinQuake Mark V doesn't support autoscale at this time.
Although in video options, you can set stretch, which in some ways has a similar result. Mark V WinQuake doesn't have the same type of translucency that Open GL has for menu items and such. WinQuake doesn't really support translucent because is 256-colors. Why is there a separate Winquake version? I'm trying to understand the use case or benefits of having it if it isn't feature complete anyhow.
WinQuake is the software renderer, like the original Quake. 8-bit palette, pixelized rendering, chunky particles, water warping, no brush Z-fighting ever since brush models clip against world, etc.
killpixel -- and some others into the original Quake look -- is obsessed with the original software renderer WinQuake/original DOS Quake don't have a way to scale 2D. But it is on my list to do so it has equivalent autoscale. Because of the prevalence of Open GL engines in modern times, it is usually more hardcore or throwback types or those that want the "out of the box 1996-style" that tend to be aware of the software renderer. As far as I know, when GOG site sells Quake there is a shortcut available to run original DOS Quake in DOSBox as an option. When Sock discovered Mark V WinQuake Sock tweeted: OMG! WinQuake how could I forget you! MarkV Winquake from Baker, #quake pixel heaven! The WinQuake build is there for nostagia or as a "wish WinQuake could run BSP2 or modern maps". /When time permits, there are few more things I want to do to the WinQuake renderer, but it's a short list (autoscale, masked textures, brush model That was one of the things I missed the most when trying my current project out in mark_v_winquake. I have quite a few windows in my map and they look absolutely awful when they're not transparent :(
I can live without coloured lighting, but not without my fancy see through brushes ;-; I wholeheartedly agree. It is something I'm not satisfied with, but also near the top of the difficulty scale to implement properly. I have 95% implementation on my hard drive, but I'm doing something wrong with 5% and I suspect a mental block is preventing me from seeing what it is -- as a result, I suspect one of these times I'll look at it and then be like "Aw hell
But for now, lives on the to-do list. http://quakeone.com/markv/dx8_temp_build.zip
-dedicated fix -txgamma fix related to lightning gun (*) The QMB particles are intended for alpha blending. Due to this texture gamma should not be applied to them, so they no longer receive gamma correction. video
Testing/fixing a lightning gun beam collision issue, which before fixing did not consistently generate sparks (QMB option) At 28 seconds in, discovers original E1M7 bug that wakes a Shambler used for Chthon death gib chunks. qmb bubbles go away like clockwork
Mystery solved: Original code: #define ONE_FRAME_ONLY (0.0001) First, 0.0001 is an irrational number in binary. Second if someone is running 10,000 frames per second in Quake, they have far worse problems than bubbles. Third, the larger the number of seconds into a map, the more that floating point is going to truncate the current time Modified: #define ONE_FRAME_ONLY (1.0/1024) // (0.001) 1/1024 isn't an irrational number in binary. The problem would eventually crop up again at some point (300 minutes +/- or maybe 600 or 1200 minutes+/-). It isn't uncommon for it to take 40 minutes to play a map (and some of the modern maps with 400 or 600 or more monsters There would be other ways to solve the problem, some arguably more correctly, but at the end of the day QuakeC starts getting problems with time calculations after a map has been running hundreds of minutes too. /This is the kind of bug that could literally never get noticed. If you have QMB bubbles on, you wouldn't see them to know they weren't there. I don't think anyone ever noticed in JoeQuake. Qrack might have similar behavior. Could you list each item in the main menu of what you are seeing?
I have - Single Player - Multiplayer - Options - Credits (which goes to help) - Quit And quit works for me. But if I recall there is like a "Nehahra movies" version that lists 6 items or something and has an extra menu -- I don't know what it is labelled. Maybe you are using "Seal of Nehahra" or something? If you can provide me a link to the download of what you have and where you got it from The one currently supported is the Spirit repackaged one, because it is all in one zip file and easy to install. If I recall, before the Spirit repackage, was one heck of a mess to sort out. Download at usual location: http://quakeone.com/markv
Mac Version - Mac Build: Open GL with QMB effects option image - Mac Build: WinQuake software renderer image All Versions - Better lightning gun sparks (QMB option) video - Improved lightning appearance @ Chthon (QMB option) - Solved disappearing QMB bubbles (gunter) - Solved non-lerping QMB bubbles (gunter) - Install command returns (johnny law) - GL -dedicated crash fix (gunter) - Automatic saves named auto_save_0.sav, _1, _2 - DirectX 8 - Malice banshee rendering issue solved with sv_gameplayfix_setmodelrealbox 0 (dwere) - Internal commands removed (c0burn) Mac Note For Open GL For the moment --- to adjust gamma typing "txgamma 0.7" in the console. Contrast adjustment is available in the menu, haven't decided how to handle gamma slider on the Mac yet. Leaning towards 1 second delay after stop moving slider. Mac Quaddicted Support! In Mark V, you can type "install travail" in the console. More important on the Mac since the Quake Injector does not run on a Mac. /Mark V auto-completes the names of 500+ of the highest rated Quaddicted single player releases. Type install and then press Ctrl-Space (Command + space?) for list. i've got
- Single Player - Playdemo - Multiplayer - Options - Credits (which goes to help) - Quit - sp works just fine - playdemo - behaves like multiplayer - multiplayer - options - options I dl'd the N from quaddicted as is , no movie
and just run it via batch file "mark_x -game nehahra -noserial -nojoy -noipx -nocdaudio" Waking up a wall shambler in e1m7 is probably the good old Lighting Gun coding weirdness where the shaft appears way off in totally wrong places when hitting walls just right. So your shaft found its way into the wall box....
I know of one good place to demonstrate the glitch on DM3 -- shafting this position hits person standing to the left: http://imgur.com/a/VALEJ I remember years back when I was looking at this weird code, I made the invisible beams visible, and they are just crazy, heh. I didn't know what the heck they were trying to do with that code, but since the visible beam actually penetrates players, I thought perhaps they were trying to make the damage beam penetrate things as well, so that's how I fixed the shaft in FvF -- the shaft will penetrate up to 2 entities in a row and still damage a 3rd (with a decrease in damage each time 30-20-10). This old post on Quakeone links to a very detailed analysis of the lighting gun glitch: http://quakeone.com/forums/quake-talk/quake-central/2872-lightning-gun-bug.html That's... pretty complicated stuff. The takeaway is that the lighting gun code is pretty borked, and you can end up hitting something way off somewhere else, like a shambler in a wall box. So your shaft found its way into the wall box....
Suddenly I pictured the image of a glory hole in my head... If you want a particle (or any other effect) to only last one frame, set a flag on it when spawned (you should have a "flags" member in your particle struct for this), then set it's die to cl.time + SOME_BIG_NUMBER (I like 666 for the humour). Draw it as normal. Then after drawing, check if the flag is set (and !cl.paused) and if so, set it's die to -1. Done. Works if Quake is running at 10 fps or at 10,000 fps.
dx8_mark_v -width 750 -height 550
= borked up screenshots Why was I running at 750 x 550? Because you told me: "2) Then don't use 800x600 windowed mode ;-) Not engine's responsibility to save the user from his own choices. " ;) Heh, yeah, that issue I was having only applies to the Windows version, but my resolution had been changed when I ran that, and that resolution was applied the next time I ran the DX one, and then my screenshots ended up being borked up. It doesn't seem to affect GL. Now for the issue I was trying to report before I had to stop and figure out why my screenshots were borked up:
Mage in FvF fires 4 vore ball models for his cloudkill attack. If they hit a surface not very far away from the caster (like a wall or the floor), then you fire again (even if you wait like 10 seconds), the QMB purple trails think they started at the last position of the last ones.... http://imgur.com/a/TgR72 Perhaps it's reading the position of the former temp entity which probably has the same edict number as the new temp entity.... Though the issue doesn't occur when a surface is hit farther away from the caster. I believe that's because the former position is too far away from the new position. Ah, yeah, if I shoot a surface far away, then run up next to it, I get the same effect. So the last position must be near the new position. Aren't you glad you have me to report these weird things instead of having to wait 100 years for them to be found? heh Neither 750 nor 550 divide evenly by 4. This is significant for graphics hardware, and even more significant for Direct3D which has less software emulation than OpenGL.
Try 740 x 540. @spy - Create and alias. Like in your command line "<engine> +alias qqq quit". Then if you want to have something like "qqq" do quit, then it would.
Looks like there is a "gamemenu.lmp" in Nehahra, I'll make Mark V use that when -nehahra is used, will make the menu normal instead of the very weird one. @mh - QMB uses tons of inlining and preprocessor macros and initially when I identified problem thought "yeah, let's do a boolean field" and then I looked at the code and thought "Uh @gunter - What MH said about the multiples of 4. Mark V has coding in Open GL and the WinQuake version about that and in screenshots, but Direct3D won't cooperate. Also the Open GL with capturedemo has problems with width not multiple of 4. Not multiple 4 is real pita, but mostly gone in Mark V. With the Open GL version of Mark V, you can actually add -resizable and resize the Window with your mouse. But I haven't tested it lately. Haven't mentioned it -- mostly to keep you out of trouble ;-) Mirror can be solid face only? It doesn't work if it's bmodel, like func_illusionary. Is it possible to implement?
Let me think that through.
I can't have mirrors be a true entity that can moved (like door or wall), otherwise pre-calculated mirror visibility would be issue and even possible map compile tool support couldn't help. However, func_illusionary can't move. Hmmmm. However, is problem I think --- func_illusionary is communicated to client through QuakeC and isn't instantly available upload level load but is still rather early Question: Scale of 1-10 that's just an addendum to spice up the super secret. I placed a mirror, compiled it and found that mirror almost asks me to try to pass through it. I compiled the new version with func_illusionary and found that the magic was gone. If it's really a lot of work than I don't think it's worth it. But if that is implemented, I think it could be used in many new maps, because people love to make fake window secrets, fake mirrors can be the evolution of that type.
This is an important difference in the design philosophy of OpenGL and Direct3D.
With GL the specification is god. That means that if the specification says that something must work, then it must work, even if it's not supported by hardware. Typically this means that the driver will drop you back to some kind of software-emulated path. It's historically been a weakness of GL that you have no way of programatically determining when/if this happens. NPO2 textures were a bitch when the first GL2 drivers came out. With D3D the hardware is god. That means that if something isn't supported by the hardware then the driver is under absolutely no obligation whatsoever to support it either. It might crash, it might give you undefined behaviour, it might give you messed-up screenshots. The downside is that historically D3D has been an unholy mess of capabilities bits and responsibility is on the program to check these and code fallbacks. D3D does provide software emulation of parts of the per-vertex pipeline for older GPUs that don't support hardware T&L, and you can actually do crazy shit like write SM3.0 vertex shaders in D3D9 and run them on an old 3DFX. But that's the limit of what it emulates, and that emulation is provided by the common runtime rather than by the vendor-supplied driver. That's another difference. D3D is actually two separate components. A common runtime is provided by Microsoft, that's what you install on your PC when you install DirectX, and that's the same irrespective of what hardware you have. Then the vendor provides a lightweight hardware-specific driver. Your program talks to the runtime, which talks to the driver, which talks to the hardware. Because the runtime is common, consistent behaviour is easier to achieve. Because the driver is lightweight there's less for the vendor to screw up. There's also potentially less for the vendor to optimize, and D3D doesn't have extensions. With GL the vendor provides everything. That means extensions and potentially better optimizations, but also means more room for driver bugs and inconsistent behaviour. The total absence of GL conformance tests for such a long time didn't help. God only knows what goes on inside some GL drivers. None of this will help anyone fix any issues, of course, but it might help some understand why things are the way that they are. Good news: the new Mac build will appropriately find id1 if it is in the same folder.
Annoying news: if id1 is NOT in the folder, it will crash (after pressing the Play button to get past the args dialog). I can send you the full diag output if you like, but here's the interesting part of the stacktrace for the Quake app: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_c.dylib 0x00007fff9a93809e flockfile + 4 1 libsystem_c.dylib 0x00007fff9a939a66 fputs + 72 2 com.quakeone.mark-v 0x000000010c2d9f1a Con_DebugLog + 266 3 com.quakeone.mark-v 0x000000010c2d9a71 Con_Init + 1249 4 com.quakeone.mark-v 0x000000010c2497f2 Host_Init + 98 5 com.quakeone.mark-v 0x000000010c2d7ff9 -[QController newGame:] + 2249 And for the GLQuake app: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_c.dylib 0x00007fff9a93809e flockfile + 4 1 libsystem_c.dylib 0x00007fff9a939a66 fputs + 72 2 com.quakeone.mark-v 0x000000010e15f40c Con_DebugLog + 266 3 com.quakeone.mark-v 0x000000010e15f018 Con_Init + 635 4 com.quakeone.mark-v 0x000000010e155525 Host_Init + 91 5 com.quakeone.mark-v 0x000000010e1a97f1 -[QController newGame:] + 1209 Maybe Con_DebugLog is unhappy that there's no folder to put the debuglog in. Different thing: I did a quick test of the install and uninstall commands.
For a separate game folder (tested using digs01) everything worked as expected. For a "bare" map that got installed into id1\\maps (tested using czg03), uninstall didn't quite work. Output from qconsole.log: uninstall: folder "/Users/jbaxter/Downloads/mark_v_mac/czg03" does not exist Thanks for giving the Mac version a test.
1) Mark V Mac not in Quake folder with id1 = console debug angry = will fix. I think at one point I decided the binary needed to be in a proper Quake folder, and then I changed my mind (or something to that effect). 2) Uninstall of simple map - Mark V plays it dumb and only looks at what is out there. So uninstall only works on a gamedir. It would have a way to know what maps are part of set and since Mark V doesn't know, it can't do that. /In the future, it is a near certainty that Mark V won't unzip anything and just use single player releases from their zip file. This will allow future Mark V to peer-to-peer transfer a required "install" is very flexible and should be able to install most single player releases or even traditional mods via URL.
Install via URL examples 1) install http://quake-1.com/files/maps/undergate.zip 2) install http://quakeone.com/proquake/frogbots-099.zip Doesn't matter how the Can only do zip files (no Cool lighting gun effects, I also enjoy the jerky+normal setting...fun!
Capturedemo still gives a black video with sound. Upon looking at the You said something about this releasing having a link straight to the codecs? I came to the same site when clicking the codec link. Sounds at 44k is still airy but that's damn possible it is how it is. Maybe it is how QS interacts with my sound driver. The more I try to listen for it the less apparent it becomes. Install this (tested on 2 separate Windows 10 machines to make 2x sure)
Google WebM/vp80 (mirror): http://quakeone.com/markv/mirror/vp8vfw-setup-1.2.0.exe Source page: http://www.optimasc.com/products/vp8vfw/index.html But yeah, install the VP80 codec and that issue should go away. Make sure capturevideo_codec is auto (default value), Mark V will use VP80 as first preference when looks at installed codecs. /Says something about 32-bit only on that site, they are so very, very wrong and apparently the creator of that page is unaware of the WOW subsystem (Windows on Windows). /I'm still mad at that DivX site. I haven't had time to update the page yet --- I'm hoping to clear the queue of outstanding stuff for Release 1.1 tonight.
- QMB particle rework for Gunter. - Alpha channel texture support for 2D replacement elements - Pulsar mirror on func_illusionary request - Nehahra use gamemnu.lmp instead of dumb mainmenu.lmp (spy) - Mac startup if not Quake folder (johhny) - IPv4 address prints strangely on Mac. - Maybe hopefully: WinQuake via GL for killpixel https://youtu.be/MGyxKckTaH0
Very cool, that'd be it. Couple of questions: When capturing the demo, if you open the console it will speed the recording by a substantial amount. I found that whenever the console is brought down it is not recording. Intended? Anyway to jack up the quality...bitrate? (Purple noise and general noise in video linked). Even if there is not, this is a pretty nice feature considering we have here 720p @60fps :) Thanks for your efforts. I think you might have a typo in your command line or are missing -nehahra, because I already coded for this scenario.
Nehahra should be started as: Console: game nehahra -nehahra Cmdline: -game nehahra -nehahra Cmdline: Console: The above should fix. Type "find capture" in console. If you haven't discovered this, it is super-awesome.
You'll see one of the things is "capturevideo_console" When that is 0, it won't capture when the console is open. This is to avoid ugliness if you type "capturedemo" in the console --- you don't want 1 second of console closing in your AVI ;-) I'm very happy it is working for you. MarkV seems to have trouble unpacking at least one release: the new RetroJam5. Example:
http://i.imgur.com/gdIDnK0.jpg It unpacks everything under the id1/maps/ directory, meaning that there is now an id1/maps/maps and id1/maps/source directory. The source folder is fine I suppose, but the /maps/maps seems to be problematic. Typing in the entire path to the map works fine, but tab completion doesn't work anymore... Is there a way to skip the credits when pressing quit from the menu? It's a little thing, but after using QS for so long I'm not used to pressing another key to get out of the game.
I've the "install" so it can figure out
/I always hit ALT-ENTER and then click "X" to exit. Or pull up console and type quit. Quake out of the box and most engines (like FitzQuake 0.85) show the closing credits via the menu route. I think you might have a typo in your command line or are missing -nehahra, because I already coded for this scenario.
yeah, i missed that additional -nehahra argument but for some reason console barks on missed fmod.dll module, and i have one in my quake folder I seems like the func_illusionary mirror support doesn't work so far. I'll experiment more with that when I get from work.
I'll be taking care of that. You need not worry about that. Haha.
Before the night ends in my time zone on the other side of the world, there will be mirrory func_illusionary. When the guy who made Menkalinan, one of my favorite maps of all time, has an idea -- yeah, I think I want to play that map ;-) I thought about putting instructions on the proper way to run nehahra on the page for Mark V. Or even block / warn in the engine.
Then I decided against it. The way I see it --- when knowledgable people like yourself encounter a small issue, it enables the knowledgeable crowd who read the discussion to help the newbies who would mess it up no matter how hard I documented it. And gets the less knowledgeable to read threads to expand their horizons. Also: the awesome thing about func_msgboard is that the participants are expert level and through discussions in threads like this, it educates to create more knowledgeable users. You need that one. One in Spirit's very nicely repackage is not good fmod.dll.
Done for next version, but no time to build on Windows and then the Mac and package and rebuild the installer version, etc. etc.
1) Mirrors for func_illusionary, mirror scanning moved to cls.signon == 2 (after all the static entities received, walks any statics too. Tested by turning an E1M1 door into a func_illusionary as a test) 2) IPv4 printing on Mac fixed 3) Mac startup fixed when Mark V isn't in a proper Quake folder 4) Autosave was saving as wrong name, fixed. 5) Installer can handle zips like RetroJam5 which had unanticipated structure. 6) Non-issue: Nehahra menu (already coded, lack of -nehahra caused issue) 7) Non-issue: Alpha channel 2D elements (already supported) 8) QMB reworked for gunter 9) Something else for the Mac. Forgot what it was. Note to self: Update page with link to the codecs folder. Put a http://www.optimasc.com/products/vp8vfw/index.html https://www.xvid.com/download/ Yes, update! We are the test gorillas who want to beat on your luggage to see if it breaks!
https://www.youtube.com/watch?v=5b1aRop-UbU If you were ever interested either in upgrading the wrapper or writing a new one using Mark V, FitzQuake 0.85 or Quakespasm as the base...
OK, I've done the initial port of the wrapper to D3D9 with a Fitz 0.85 base (actually the original DirectFitz I made years ago). This is just the "do enough to get it working" stage, but it has established that (1) the port works, and (2) it's viable to move forward from. If you have any requests for features to add to it, now is a good time. I'm thinking glCopyTex(Sub)Image and the full set of combine modes would be good candidates. Stencil. Fix polygon offset. Texture matrix stack. Vertex arrays. NPO2. I just mention these but without commitment to do all of them. If you have any requests for features to add to it, now is a good time.
1) Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1) 2) 8x multitexture (which was easy, even for me), GL_TEXTURE_MATRIX (which I have zero chance of doing myself). "Combine". 3) The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one. Mirror func_illusionary doesn't work for me in the latest release as well. I should have mentioned that these are AD func_illusionary, though I doubt they have any difference with the regular ones. I tryied both every side mirror texture brush and one face with with mirror texture and the rest covered by skip texture. Neither of them work.
I'll try to do that in vanilla quake and let you know if it works. No obligation and separate issue - but you've written controller support before and no one else does Microsoft Direct X type of coding on your level
I've looked at the XInput tutorials from Microsoft and my head about exploded all the monotonous steps involved and not necessarily even understanding what is going on for sure. Multiple controller support (hell even single controller) where each controller can be read separately once per frame. ----- No obligation, but since that kind of thing falls in your wheelhouse, I thought I'd bring the topic up as an example of something nigh impossible for me, but that falls into one of your primary strengths categories. Haven't updated the version yet, got to audit the code, etc. I'll do I "New Version" kind of post after I update it. Might be 2 hours.
Exactly! Yeah, everyone's beta testing and the level of detail has been incredible. Best experience as an engine coder ever.
And your unique perspective as an active QuakeC coder running a server has been an invaluable contribution. Very nice that everyone has been bringing some unique perspective to the table. ...XInput is probably similar...
It's not unfortunately; XInput is actually very different. I'm not certain what tutorials you've looked at, but IIRC XInput is just 10 or so lines to initialize, then another 5 or so to read the input. Everything else is translating input data from XInput format to Quake format (i.e. button mapping, etc). Quake's joystick code is NOT DirectInput - ignore what it says in the comments in in_win.c; it's NOT DirectInput, it's actually a totally different Windows multimedia controller API. DirectInput joystick code looks a little like the DirectInput mouse code. I wouldn't touch multiple controller support with a 10 foot pole. You need support for multiple clients first, and that's not a light undertaking. I know you're getting requests for splitscreen, but it's not something you can just easily patch in. I think your time is better spent elsewhere. It's all good. I thought I'd ask.
(@fifth: eta = very murky. I will promise that it will happen at some point. Maybe spring. It's important to me.) /Yeah, I know joystick in Quake isn't DirectInput but multimedia. The feature where you copy the screen to texture (FitzQuake's oldwater). Yeah, I know you aren't fond of that one.
Done. I just need to sanity-check my bottom-left-is-origin to top-left-is-origin conversion, but otherwise - done. An interesting FitzQuake bug arose while doing this, that's specific to a GL vs D3D difference. In GL the current viewport doesn't affect glClear calls. In D3D the current viewport does affect IDirect3DDevice9::Clear calls. So in other words, in D3D the clear is bounded to the viewport dimensions. This came up because FQ sets a smaller viewport to draw the warp images, but doesn't unset it before clearing; that small viewport is therefore the only cleared region. A "GL_SetCanvas (CANVAS_DEFAULT)" was needed in R_Clear to work around this. You could probably also put it in R_UpdateWarpTextures. This wouldn't affect D3D10+ where the clear is done directly on a render target view, and I have no idea if it affects D3D8-. Odd what MH is saying, you had a video with multiple clients and splitscreen?
I don't have much choice but to wait... us non-coder guys are at the mercy of whatever you guys decide tbh. :P pulsar - this doesn't have func_illusionary mirrors. I'm putting that in separate 1012 build in case I messed up something
Build 1011 - Windows only GL|DX8|WinQuake Everything except func_illusionary mirrors, in case func_illusionary mirrors explode something. @fifth - I multitask extremely poorly. Can't get into deep discussion with MH about that without jeopardizing what I'm doing now. If I mess up 1 line of code I also multitask poorly but am less disciplined about it, so I'm heavily dependent on people just backing off. :)
Yeah,
This func_illusionary mirrors thing is cool, but has several points of modification. Don't want to unleash an exploding build. /Ok Hah... it's cool guys, I'm probably one of the few people in the community that is even bothered about that stuff.
If I had it my way every classic 90's shooter with multiplayer would have splitscreen in it ;) So the difference in the QMB particles is that I can turn them off?
Otherwise previous issues still exist. @pulsar - carry on knowing the feature will exist in a few hours ;-)
I'm slowboating a little because I noticed some scenarios I didn't consider and uncovered what might explain why all my attempts at adding alpha masked textures in the software renderer failed while looking through the mirror code, which doesn't matter right now but has me slightly annoyed at myself. So I'm walking through the several pieces to make sure I didn't make any mistakes. Already supported for crosshair 1, but I sense you may know that since you said crosshair 2.
Crosshair 1 is gfx/crosshairs/default.tga, which I am thinking is the same as DarkPlaces, but I can't really remember and I know DarkPlaces supports many crosshairs. I never anticipated a reason that someone would want to substitute for the dot crosshair, but I am guessing you have a scenario in mind like an alternate gun crosshair or something? /If you have a good scenario, I'll put it the eventual to-do list because I suspect even 2 crosshairs would not suffice. As soon I get pulsar func_illusionary mirrors ironed out, Mark V version 1.1 is wrapped and I plan on taking a break for a few weeks (I'm kinda burnt out). So the difference in the QMB particles is that I can turn them off?
Otherwise previous issues still exist. Could you identify which ones? I thought I got them all, but maybe not? Is it just a 2nd crosshair for a gun?
If you tell me what DarkPlaces expects the replacement texture name to be, I'll see if I can add an alternate crosshair 2 to version 1.1 And I'll change the dot crosshair to be crosshair -1 (or something). #274 above -- what should be blue particle splashes sometimes come out as orange sparks (watch the splash.dem in the zip I linked to).
Even when they are not sparks, the blue QMB particles just appear then vanish without moving outward, as they do with QMB disabled. The other issue wasn't really about particles, but about how an effect trail thinks it started where the last one ended if you are near that position; screenshots in #414 above. I found this quirk also happens with the rocket launcher trail, but it's faster moving and harder to reproduce. Try shooting a wall (like the one in the position of the screenshots), then move next to the wall and fire your next rocket, with the point of impact of the previous rocket still in your view. The rocket trail will originate from the previous impact point. Same with the trails from lava balls and knight spikes. 1) The QMB trails. Yeah, those sometimes they get confused. Inherited from the JoeQuake implementation. At some future date I'll fix that. It is hard to reproduce, annoys me too. It is more frequent with non-Microsoft compiler (Mac version has it happen more often).
So could be the compiler doing it. On longer term list. 2) Blue particles become orange Those little nuisances will dealt with at a future, but I think I inherited from JoeQuake implementation or compiler related or compiler optimization. My mana bar is too low for me to take that on right now. The shambler thing doesn't actually look bad....
Wow, super ugly effect in DX with: vid_hardwaregamma 0 chase_mode 2 chase_active 1 and swing the camera outside the wall. Doesn't occur in GL. gl_clear 1 fixes it. Is there any reason why someone would want gl_clear 0 [default]? Decided to add support for multiple replacement crosshair textures.
Dot crosshair (currently crosshair 2), will become crosshair -1. @gunter - gl_clear 0 is faster and you don't have to redraw the status bar every frame (if the status bar is solid like original Quake and not transparent or see through). Replacement crosshair texture names will be named
gfx/crosshairs/crosshair_1.tga gfx/crosshairs/crosshair_2.tga gfx/crosshairs/crosshair_3.tga gfx/crosshairs/crosshair_4.tga Expected 32 x 32 texture with alpha channel. A JoeQuake/ezQuake/Qrack crosshair is likely to work if it is a I named the texture names slightly different than DarkPlaces which doesn't have the underscore, because I don't know what rules/sizes DarkPlaces expects for a crosshair texture and it may suppport things like huge sizes, which I would not be willing to do. Is "gl_clear 0 is faster" just academic at this point, on modern hardware? Even on my ancient netbook, I can't tell any difference in performance.
Yeah, gl_clear 0 is rather academic usually.
@gunter - I may have fixed the QMB trails being jumpy. Maybe. Looks good so far. Crosshairs in next version Changed my mind. Per weapon crosshairs so if someone makes a single player release with a weapon they want special crosshair available, automatically takes effect. Like if someone were to make a crossbow (Drake), could use custom crosshair for that weapon. Crosshair details // Yes, sadly it appears 24 weapons are possible. Quoth plasma gun is 24, as far as I can tell. gfx/crosshairs/weapon_1.tga to gfx/crosshairs/weapon_24.tga gfx/crosshairs/default.tga // user's crosshair scr_weapon_crosshair - defaults on. Use a single player release's crosshairs. Set to 0 to not use them. crosshair 0,1,2 from previous builds continue to work as-is. I've seen some mods that do stuffcmd ("crosshair 4") and it's just bad design. What the mod typically wants is per weapon crosshair anyway. This will let single player releases provide crosshairs for crossbows (Drake) or even a empty texture for axe (no crosshair) or maybe a funky one for a high tech weapon. Build 1013 - Windows Open GL | DX8 | WinQuake
1) QMB trails being jumpy possibly fixed (gunter) 2) Per weapon crosshairs replacement texture support (c0burn) scr_weapon_crosshair, defaults on -- allows single player releases to provide per weapon crosshairs. So if a mod has a crossbow like Drake (A Roman Wilderness of Pain, Something Wicked and a few others right?) or a high tech weapon and wants a special crosshair, it can do that. User can set scr_weapon_crosshair 0 to not use the single player release's crosshair and just use normal crosshair. Player can still use gfx/crosshairs/default.tga to have a texture replaced crosshair. Still tuning func_illusionary mirrors -- func_illusionary mirrors is not in the above build. Another fine catch.
When I rewrote QMB particles, I missed something. Should be able to make the behavior proper. If you are using using TE_GUNSHOT as a particle effect in splash1.dem, QMB modifies that into an effect.
Should be the final temp build
Build 1014 - Windows Open GL | DX8 | WinQuake Addressed some issues mostly reported by gunter and a few small things I noticed, like drawing external crosshairs slightly wrong. func_illusionary mirrors is not in the above build. func_illusionary mirrors will be in next build now that I finally have closed out all bugs reported. Needed to have a clean and stable base before putting in the complex changes for func_illusionary mirrors. AFR setups will generally require gl_clear 1 in order to activate properly, while other setups won't really care too much.
why numbers for crosshairs, and not filenames? why numbers for crosshairs, and not filenames
I'm guessing you mean model names? Like gfx/crosshairs/v_axe.tga or soemthing to that effect? Here is just my thoughts cl.stats[STAT_ACTIVEWEAPON] == (1 << i) cl.stats[STAT_ACTIVEWEAPON] is a bit flag with 24 possibilities (but not 32? Because QuakeC is floating point, can't do unsigned?). I used what sbar.c knows about the weapon, which is the weapon number. Never thought of the idea of using the model name, that being said isn't it true that QuakeC could set anything it wanted as the view model weapon (including none!!)? So QuakeC itself does not know the concept of a view weapon model, as far as I know. Someone could write some QuakeC where a fully charged weapon uses different model? Which just reminded me. There are 25 possibilities, not 24. Because 0 is typically the axe (weapon 1). Makes Quoth Plasma gun weapon #25 (24th bit possibility) and Quoth sword weapon #13.
/Add to the model name thing qc can't change the viewmodel's skin. so they're different models if they have different skins.
the exception being Ok, Mark V
crosshair 0 (none) crosshair 1 (Quake +) crosshair 2 (dot) That's it. I was briefly going to change to implement to number system like DarkPlaces. Then I thought it about some more, and decided to tie it to the weapon number instead. Beats passing around "stuffcmd crosshair 1" -- I hate stuffcmd. Mark V crosshair remains simple system But if a mod contains any weapon crosshairs (scanned on gamedir initialize), it will display the weapon crosshair unless user sets scr_weapon_crosshair 0 to override. No extensions and still pure Quake at the moment.
At a future unknown time, I anticipate making another run at acquiring more Spiked Quakespasm's features. also, STAT_ACTIVEWEAPON is sent as a byte in vanilla quake, and is thus normally limited to 9 different values, only 8 of which might be present in vanilla.
but that doesn't mean that they might be set on the server anyway, or that you'll never have more than one bit set. hacking it to support more weapons is one of the first things that many mods need to achieve. you're better off using STAT_WEAPON. unless you're making a new addition for ezquake anyway. other engines should avoid those hacks like the plague, but its too late for poor ezquake. 2nd reason I implemented the per weapon crosshair system instead.
I very well know some people will end up making per model crosshairs for certain mods because now it requires zero QuakeC support. You could just make a crosshair for the Drake crossbow in Something Wicked and name it appropriately and do it in 30 seconds or so. STAT_WEAPON
Hmmm It's a model index. cl.model_precache[cl.stats[STAT_WEAPON]] A gun model index might be 23 or 47 depending on the precache order, as I understand it. I mean "player.mdl" and "eyes.mdl" --- if I recall are guaranteed to be the first 2 precaches (if I recall correctly, which is no sure thing). So 1 and 2 sure can't be weapons, if I am correct above. Enough that I can do mirrors (stencil plus depth splitting trick - split range into 0 to 0.5, 0.5 to 1)
Stencil is done. I suspect that depth-splitting problems are due to differences in how GL and D3D handle the depth range state. In D3D depth range and the viewport are part of the same state. In GL they're separate states. The current wrapper code just assumes a depth range of 0 to 1 when setting the viewport, so therefore viewport will overwrite depth range. Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up. Stencil is done.
Very nice! Fifth: Mark V already split screen @mh video I literally only need multiple controller support. I'm just pointing that out for clarity. Not trying to get you to change your mind or anything. Just wrapping up unfinished loose end from yesterday. Fixing that needs some rearchitecting of the wrapper, which I intend doing anyway, so this is just an advance heads-up.
Ah http://quakeone.com/markv/older/1016_mark_v_temp_build.zip
Pulsar 1) Can you download this build 2) Alter your map in the following manner a) func_illusionary with 6 mirror sides must go. Make 1 sided. Here is why It looks like all 3 of your mirrors are on the same plane. Which is fine. But the 6-sided mirror is messing things up. By definition, an func_illusionary doesn't block visibility. That means the six-sider is interfering with itself. Truth be told, your map the mirrors can see each other because vis is not actually blocking them from seeing each other, but because they appear to be on the same plane that would be fine. Mark V has r_lockpvs which if you stand somewhere and type r_lockpvs (invented by MH) you can walk around and see what walls are visibile. Anyway, give it a try. Let me know if it works with build 1016. /And if you could, after making those changes could you re-upload the map so I can test some more. Your test map was very useful to me including for some hidden reasons. Extra note: really in order to run a map with multiple mirrors, a map must be vised. Yours was. And they were all on the same plane so it actually wouldn't matter. But a vised map can have mirrors not on the same plane provided they cannot see each other. a) func_illusionary with 6 mirror sides must go. Make 1 sided.
That's absolulely fine, the mirror in the actual map is 1 sided. 6 mirror sides were for test map only. Let me know if I get you right: I need to correct the test map so that each mirror is visblocked from another one. Do I need to move mirror so that they are not on the same plane? I'll download this build and make another version of the test map when I get home (in about 3 hours). Looks like the splash to explosion thing is MOSTLY fixed -- it still occurs at one point in splash.dem (2:44). And the blue splashes still seem to die almost instantly instead of moving outward.
I'm not using TE_GUNSHOT, just a straight drawing of several blue particles like: particle(origin, direction, 32, intensity); 32 is the color (light blue), and I do this several times simultaneously to send particles out in different directions. Giving each weapon number a different crosshair doesn't sound good to me. Of course, in FvF there are different classes, so each class would need a different crosshair, not each weapon -- a cyborg gun #5 is completely different than a mage gun #5. If I were assigning different crosshairs for each class and potentially for different guns within each class, I would need the stuffcmd method for precise control of what crosshair gets used. Didn't you say there were already mods that do this via stuffcmd? Are there any mods that do it the way you are proposing? Pulsar, just make the middle mirror -- the one with 6 sides --- into a 1-sided mirror. Only that.
That should be all that is required. I've just found that can get home late today, so I can't say when it will be. But definitely tonight.
weapon crosshairs
Yeah, that feature is targeted towards mappers and players. Kind of misses your situation as a QuakeC mod creator/server operator, I know. In proper world, a QuakeC extension would be the right tool for your needs like what no doubt DarkPlaces and FTE can do via QuakeC extensions to control crosshair on client directly. splash to explosion thing is mostly fixed It'll have to do for a while. I said I was going to stick with JoeQuake behavior (even if undesirable), but ended up largely discarding that to make an effort to try to fix about every issue you documented. On the plus side, skipping trails should be history, maybe in all cases. And you do at least have the option of turning off the "QuakeC particles" replacement. And you unearthed some great short-comings on the JoeQuake QMB implementation, and precious few remain. I did some testing on fvf yesterday and foq was there. With the QMB lightning sparks, some of the game play was pretty unreal. You argue hard, but you sure do bug test hard. ;-) Quakespasm: Had controller support recently added, I'm wondering if it can be adapted into this?
Mark V does everything natively on both Windows and the Mac. The kind of things you need system access to do. SDL2 is a wrapper, its goal is not providing system access. So a number of the nice things Mark V can do, especially on Windows but some on the Mac too, it wouldn't be able to do. Case in point, add -resizable to your command line and you can resize the Mark V window like any other Windows application. SDL2 would not like that. I could name several other examples, but they are all very boring. Mark V needs low level access to many things. SDL2 makes everything easy, but puts lots of limits in your face. I'm not really a "limits" kind of guy. /I hope that explanation helps. Download at usual location:
http://quakeone.com/markv New - Sparks? Lightning? QMB option greatly enhanced! Video - Mac version improved, both Open GL | WinQuake (johhny law) - Several QMB enhancements (gunter) - Installer enhancements handles more packaging types (Pritchard) - Per weapon external crosshair support (c0burn) - Several improvements to DX8 version (gunter) - Theoretical func_illusionary mirrors (pulsar) - Mark V page links good codecs, not link to bloatware. (Bloughsburgh) Improvements to Nehahra support and many other small polishing/ hardening modifications. Possible final build for 2016. If no issues, this release is promoted to Mark V - Version 1.1 Final. (*) Awaiting on pulsar's map testing results for mirrors. MH is working on creating a heavily updated Direct X 9 version wrapper for the engine. If you have ever seen MH's DirectQ engine -- 5,000 frames per second on 2012 era hardware -- and is still listed on Quaddicted as Spirit's recommended engine of choice for Windows Didn't forget about you --- I sort of underestimated difficulty of rolling up what I was hoping to do (didn't realize how much video code I would have to combine, hadn't looked at it lately). And also had more last minute issues to resolve than I anticipated. I'm very sorry, I was hoping for this version.
Translucent windows don't work in Jump. Is this normal?
Also, I noticed that the Winquake version complains about gl_texturemode (it's in my autoexec) in the console. It ignores other GL-specific commands, even though it doesn't recognize them when they're being entered. Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?
It's like a 30 minute fix, but I decided to procrastinate -- because far too many things are a 30 minute fix and I've pretty burnt out and have been for a week or so. Mark V WinQuake recognizes all the console variables that Mark V Open GL recognizes -- but in Mark V is gl_texturemode is a command just like FitzQuake 0.85, so that's why that message happens. I'll consider making that silent for the future. Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?
Not sure, can't find that discussion. The windows are translucent in QS, but they're opaque in Mark V. Are the windows tranlucent (partially transparent) or masked textures (totally see through)?
Mark V does not support masked textures on world model, if the 2nd case. It breaks vis and several other things including (sv_cullentities). And if it is the 2nd thing, it won't get changed. Spike and other top-tier experts know why it is improper, and I'm ok with things that are broken by improper design not working right in this engine. I'm don't do race to the bottom. I understand that some map authors target broken engines, I'm fine with those things being broken in Mark V. There are 1500 single player releases. I wanted to say it's the former, but now that I looked more closely - it's more complex than that. Though I'm not sure if it changes anything.
A window is made of 2 layers: 1. A translucent texture without any "holes" in it. This is glass. There's some space behind it. 2. An additional masked texture in front of it - to make the frame look solid, apparently. It's also translucent for some reason, though it's not very noticeable. http://i.imgur.com/zcSFt8A.png Masked texture is see-through in Mark V, but both textures are opaque. http://i.imgur.com/qTMSaG9.png It's all good! Don't overwork yourself on my account, I'm simply a beneficiary of your time and skill. In the meantime, I'm collecting various maps/episodes to replay when the new wquake drops... it just doesn't feel right playing in anything else :P
Ok, I've been thinking about custom crosshair possibilities.
Having a different crosshair for each gun? Boring, inside-the-box thinking. What would I do if you gave me the ability to use 24 custom crosshair images? I'd make an interactive crosshair that would act like radar and point in the direction of the nearest enemy. 24 images would be perfect for that: 8 directions x 3 height levels (low, medium, and high) to show you the direction and relative height of the enemy. Yes, this would require the use of stuffcmds. There is nothing wrong with stuffcmds. Sure, they can be misused (but so can anything else in a mod). But in this case, it would be a fine way for the server to send information to the client to update their crosshair image to show the direction of the nearest enemy. However, to maintain compatibility and not mess with people's crosshairs who aren't using Mark V, perhaps the custom crosshair stuff should be moved to a new console variable, like newcrosshair. So you could actually have both the old crosshair AND a new crosshair image active at the same time. And I could be sending stuffcmd only for newcrosshair so that it wouldn't touch their standard crosshair value, if they didn't have my custom crosshair images. To be extra sure about compatibility for other mods that might use stuffcmd to change custom crosshairs with the standard crosshair command, then "newcrosshair -1" would make newcrosshair use whatever setting is in crosshair. So I guess whatever you're doing with crosshair could exist alongside what I want to do with crosshair..... Though I'm not sure how many people will actually make use of the thing you're doing (different crosshair for each gun). But I'm completely certain I would do the thing I am thinking about, if you gave me the ability to select specific crosshair images by use of stuffcmd :D MH is working on creating a heavily updated Direct X 9 version wrapper for the engine.
Timing is good because you've indicated you're coming to a timeout, which gives me more time to get stuck in and get things working well. I want everybody to be realistic about expectations here though. You're not going to get 5,000 fps from this. Part of the advantage of going native with an API is that you can deeply optimize for the strengths of that API. Going through a GL to D3D layer means that a lot of those optimization opportunities just don't even exist. I could talk the hind legs off a donkey about examples, but it would be sidetracking too much. I just expect people to believe me when I say this. So because QS uses lots of external
I look forward to testing this stuff when its ready ... about this port is that it's coming without any external DLLs at all. Also one of the reasons why Mark V is my favorite.
In that temp build func_illusionary mirror doesn't work as well for me. I checked in both test map and the real map.
Here's the new test map: http://www.quaketastic.com/files/test_mirror2.zip @Baker: thank you very much for the crosshair addition, and fixing the dev command crashes! I have to admit to not even realising that MarkV supported crosshair replacements in the first place, but the per-weapon idea is very nice and I actually think my mod could make use of it.
I have a new bug where sprites don't appear. My explosion sprites are fine, but the waypoint sprites in my waypoint editor are invisible. Any ideas? Fine in quakespasm.
Are the sprites bubbles?
Do you have QMB effects enabled? Do the sprites have replacement textures with alpha transparency? Um... we noticed on the FvF server that e5end (from DOPA) does not appear to have properly viss'd transparent water in Mark V, but sometimes it does or used to or something weird. r_novis 1 makes it look transparent, of course.
I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those.... It just doesn't in Mark V. What's up with that? Something weird about that map? @c0burn - Can you provide a way for me to create that scenario, I'll like to check it out.
@dwere - in the jump map where the issue exists, could you type viewpos and post where in the map the issue exists? @gunter - is this easy to find? Next I do an update, I need to make it so any time somoene does a screenshot, it writes the game, mapname and map coordinates in the meta data in the PNG.
I looked at the Jump map, noclipped all around the place and can't find this location in your screenshot, but I'd sure like to check it out and see it. So if you can post the "viewpos" coordinates I'd like to look at it. @gunter - Justed loaded up e5end. The autotransparency detection waits a few frames before beginning to check. Something about being located above the water and immediately falling in is tricking it. Frankly, I don't even remember myself which window it was.
But it shouldn't matter, because all windows are opaque for me. I deleted my config and autoexec in case I screwed up the settings somehow, but nothing changed. @dwere - looks like its just scenario in the engine where entities that are both
I must not have anticipated a scenario where both of those would be going on with the same entity. Excellent engine test case! The map author did everything right and the map is very designed. I'll address that one when I resume working the end. I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those....
Note that quakespasm defaults to gl_clear 1 so HOMs render as solid grey, and transparent water on maps that are vised for opaque water will render as grey-tinted. There's nothing special in QS about detecting water vis, so it was probably rendering against the grey void. Gunter found a automatic water transparency start of map mistake.
Mark V waits a couple of frames before implementing a water transparency check. In the d5end scenario, Mark V discards the fact it already has seen evidence that the map has transparent water because it doesn't start check for a couple of frames. I probably have it ignore a flag or reset the water check data after 0.1 seconds, when it shouldn't. dopa e5end solved.
What's funny about -- Mark V's automatic underwater transparency detection shouldn't ever fail. But due to an oversight, I wasn't letting it do its job. In the renderer: 1) Determine surfaces visible 2) -- If surface in your field of view? Continue 3) ----- Do automatic transparency check Well, for dopa end, you spawn and fall into water and are looking straight ahead. Maybe by dumb luck the water comes into view before you hit it. Corrected version: 1) Determine surfaces visible 3) -Do automatic transparency check 2) -- If surface in your field of view? Continue It was failing in that circumstance because it was checking your view instead of your surroundings. Random sparks.
Set qmb_particles_quakec_count_30 0 I do not know the nature of what QMB is trying to have that do, but it appears to view a particle count of 30 as special. So I made it a cvar. I think it may have been intended to relates to the scrag attack, but can't be sure. I may end up defaulting that to 0 in the engine. Download at usual location:
http://quakeone.com/markv Mark V can now be resized on-the-fly in a complete and autosizing way that hasn't quite been done in any other Quake engine, although FTE may have something close. Video/input rewritten from ground up in 2014, but never quite completed until now. New - Resize window on-the-fly with the mouse (no DX8). - Issue with window in "Jump" by gotshun resolved (dwere) - Missing waypoint sprite resolved (c0burn) - Removed QMB unwanted sparks by QuakeC (gunter) - Automatic water transparency oversight on e5end.bsp resolved (gunter) Each of the above bug reports were very awesome. Often hard to spot, extremely rare (gunter, c0burn) or ones requiring a real eye for detail (dwere) often don't get noticed and reported for long periods of time. Remaining: not in this build, but coming up next -- func_illusionary mirrors fix for pulsar. GL_ARB_texture_env_combine is implemented, with the exception of interpolate combine mode and constant color.
I'm a bit wary of default values for many of the combine states: I don't set them, but then neither does the GL spec appear to give them, so I'm interpreting that as meaning that the onus is on the programmer to be explicit. Fixed a nasty performance-sapping bug with quad particles. The overall performance increase is looking to be quite significant. Unfortunately I didn't benchmark the D3D8 version, but with 9 it's currently running at almost twice the speed of my initial port. Speaking of managing expectations, it will - of course - be entirely up to Baker regarding how he wants to integrate this. I can see one of 3 options: (1) do nothing, (2) drop D3D8 and offer only D3D9, or (3) offer both D3D8 and 9. I'm keeping the same interface to the wrapper so (3) should be possible with minimal work, and I suspect that is what Baker would prefer. Either way I'll probably do an independent release of the modified DirectFitz incorporating the new wrapper anyway. Most of these are things I don't care too much about, but for the sake thoroughness
1) Multisample. Maybe useful if, say, the HUD or the console were drawn with a non-integer scale like 1.88. Or maybe not. But it's a difference. 2) Resizing window real-time. I don't remember what the main barrier was. Of even if there wasn't one in the DX8 wrapper or if it was just on my side. 3) License. It would be nicer if were GPL 2.1 or later. Or maybe even BSD or MIT license. Doesn't really matter, if I recall seemed like there was 1 thing about GPL 3.0 I didn't like, but I don't recall what it was. It's not really a big deal. 4) Built-in full window gamma/contrast. In Open GL 1.2 5) GL hints? If DX8 doesn't do. I bet it already does. I always thought it was great that after making very few changes to the DX8 wrapper, including a little bit of abuse to get to it to accept vsync changes (windowed mode only?), that it did not need any special treatment except in the most minor of circumstances. Multisample
D3D supports this but last time I looked at it the initialization code was horrible. This is an API difference between GL and D3D: if you ask for an unsupported pixel format in GL, it will degrade gracefully; D3D will just fail. It means video startup can involve a lot of "test every possible combination in a loop until you find one that works", which is fun for nobody. Resizing Window Should be possible. I don't think there is a barrier in the API. It does involve mode changes though (when you think about it, a window resize is actually just a mode change). License I'm not a fan of the GPL in any incarnation and prefer more permissive licensing if possible. No decision but that should give you an idea of how I'm thinking. Gamma/contrast I'd need to review how you're doing it in GL before making any comment. Hints D3D, any version, doesn't offer hints. API philosophical difference: in D3D you must explicitly state what you want. The D3D8 wrapper has the fog hint implemented, but no other. Some hints are impossible: e.g. D3D enforces perspective-correct texturing and gives you no control over it. I would probably keep the DX8 build as part of the source, but only distribute the DX9. At least for a while, then the DX8 build would likely be removed
void VID_Renderer_Set_OpenGL (void) { void VID_Renderer_Set_Direct3D (void) { (a few oddball fake Windows functions in the mix like ewglMakeCurrent = d3dmh_wglMakeCurrent, etc.) Note: At one point I did combined Direct3D + Open GL builds. The fake function ChangeDisplaySettings had to be renamed in the wrapper to allow both to co-exist. I cannot recall but if it doesn't already do so, the ability to completely shutdown the Direct X without restarting would be helpful. With Mark V's video code, shutting down a renderer and switching to another one would not be hard at all. Would be one less The Direct3D method doesn't need to be the same as the Open GL.
I use gamma and contrast console variables. If vid_hardwaregamma is 1, uses the Windows screen brightness that affects entire display. If vid_hardwaregamma is 0, Mark V reuploads the textures with the current gamma setting and then at end of frame renders a contrast polygon over the full-screen. Contrast slider adjusts in realtime, but gamma can be only be manipulated via "txgamma" console command because can be a little slow. Open GL/Direct3D8 In the theoretical Direct3D 9 case, at the end of frame vid_hardwaregamma 0 would instead call d3d9_mh VID_Gamma_Contrast (vid_gamma.value, vid_contrast.value) and it would apply both the gamma and contrast to the buffer before swap. /No obligation, I'm explaining my concept of how such a thing would work. One last thing before I try to wrap up func_illusionary mirrors for pulsar
I would suspect that the DX9 would be the main executable for Mark V on Windows. It was only the few missing functions like stencil and CopyTexSubImage2D that caused me to need OpenGL, because I had plans for those. Add: One more missing feature Direct3D doesn't support variable width lines: http://stackoverflow.com/questions/2280077/direct3d-line-thickness
The thing here is that line width is actually not hardware-accelerated, even in GL, so D3D doesn't offer it at all. qmb_particles_quakec_count_30 0
This seems to work. Maybe the thinking was, "if there are 30 or more particles, it must be an explosion," or maybe it also has to do with how my splash particles are spreading out in different directions from a center point, and that kind of looks like an explosion.... But I don't know where something like that happens in standard Quake, where it isn't already covered by a QMB effect. That's the new default value. Now QMB largely behaves in a predictable and non-hacky manner that is friendly to use in QuakeC. About the only exception is don't use colors 73 or 225 unless you want blood effect.
By the way, in investigating c0burn's sprite issue, solved your chase camera previous movetype_none issue. I was never able to find the issue because it was never a movetype issue but an nearly invisible typo in the engine setmodel that only affected sprites that never move. @mh -- I'm not surprised. Isn't like there aren't other ways to do about the same thing. Hm, is it possible my blue particle splashes are being removed because they are created under the surface of the water? If QMB is interpreting them as explosions, it may be
Except in this case, it may be messing up my water splash effect because it thinks its an explosion. requiring a real eye for detail
I don't know. I just saw a vague comment about windows being awesome, but I didn't notice anything particularly special when I was playing. So I checked in QS. Thanks for fixing it, and thanks for all your work. @mh -- I'm not surprised. Isn't like there aren't other ways to do about the same thing.
It can be emulated by drawing them as regular primitives but to be honest that's a place I don't want to go to. Time spent emulating a feature that's not hardware-accelerated or not in the API is time not spent on essential stuff. Hey there, congrats on the 1.0 release. I loved playing through Quake the first time using your WinQuake port. From my research that's easily the best way to play Quake as close as possible to DOSBox on a modern system. Thanks for that!
For some reason, though, the OpenGL port has never worked for me, not with the last beta and not with 1.0. It shows the 3DFX logo and then crashes ("...stopped working."). GLQuake and Quakespasm work, although setting a higher resolution in GLQuake crashes it as well. I suppose the problem is on my end, as I seem to have similar problems (Crash when setting older OpenGL games to higher resolution), but I never figured out a reason. I'm running Windows 10 on a laptop with an i7-5500U with integrated graphics as well as a GeForce GTX 850M, latest drivers. No difference if I set the driver to use either graphics card (although that function doesn't work properly in many games). Any ideas? it shows the 3DFX
Hmmm. I thought that was like a 1990s thing. Google says that company has been dead since 2002 Mark V does not need any DLLs. Anyway, regardless the DX8 should work for you. Maybe in a future version, I put some sort of junky old opengl32.dll (Glide?) detector. Well, for now you can use the DX8 build. Does almost everything. Doesn't use Open GL at all. Let me know how it turns out. I think GLQuake comes with some really crusty/obsolete
One more reason to use MH's upcoming DirectX 9 modification as main Mark V distribution executable. Func_illusionary mirrors on their way within an hour or so.
In next update, any func_illusionary mirror must have one 1-mirror texture, in the case of a cube the other surfaces will not be drawn, just the mirror. This will allow for mirror secrets. Effectively, they will a brush with a mirror on one side, from the other side they don't exist. Makes your original test map work. I'm testing out some other things before I release this. http://quakeone.com/markv/1019_mark_v_mirrors_pulsar.zip
A func_illusionary that is a mirror should have one mirror surface, the other 5 will not get rendered. At this time, shouldn't be sloped up or down. This test build does both of your test maps fine and a test map I made. /This is a test build. It looks like this works for 6-sided brushed only. It works fine in test map, but in the actual map I have func_illusionary with 8 sides (to fit geometry) for example (one face is mirror, others are skip) and it doesn't render as mirror.
While with classic boxes with one mirror side everything seems to work fine. But it doesn't work with boxes with chamfers. Func_illusionary mirrors were very complicated to implement in a thorough way.
I discovers ton of special scenarios I had to adjust for. I kept discovering more issues that caused me to have to re-engineer them. Any example I didn't consider is useful. it works fine in test map with non-rectangular mirror but doesn't work in the actual map. Gotta investigate more.
I do not know what compile tools will do to such a brush, and there are several different compilers that may handle them differently.
That being said, until something very strange is going on, I should be able to examine see what is happening. Upload the one that doesn't work right, it will allow me to make a list of "do" and "don't" for func_illusionary mirrors.
It is also possible what you are trying to do should work (but I failed to anticipate a situation) *or* doesn't work for non-obvious reasons that might not involve the shape. func_illusionary mirrors don't work in AD. I guess it has somethinf to do with it's entity state system. You can download AD 1.5, place the test map there and test it in AD.
Good call with the
Obviously, GLQuake doesn't run anymore, now, so basically that's the culprit. I always just copied the source ports into my GOG Quake directory, guess that was a bit thoughtless. Not that I'd ever want to use GLQuake...
Your best bet is always to copy the id1/hipnotic/rogue folders into a new dir with the Mark V exe(s).
vanilla glquake likes to crash when a gl driver reports over 1024 bytes of extensions. many gl drivers (or at least nvidia) limit the number of extensions reported to anything 'glquake.exe', which means renaming old third-party engines is one way to get them working again...
vanilla also likes to misbehave without the -no8bit arg. GOG includes 3dfx's opengl->glide wrapper, as well as nglide and its glide->direct3d wrapper. I guess markv just doesn't like it when various opengl functions are missing. one way to avoid this issue (including the issue with the gl->glide wrapper with no glide support) is to just directly+dynamically load the opengl32.dll from the windows system32 directory. /me starts to wonder which other engines fail to cope with it. /me wonders what the steam version does to avoid the glquake/winquake crashes. but yeah, if you're not going to run vanilla glquake, one option is to just remove that opengl32.dll minidriver/wrapper. I might be able evade the GOG opengl32.dll by checking for the existence of the
/Mark V hooks up all Open GL functions at startup, so while another might wait to crash until one of them is called, Mark V will crash immediately. Nothing ever gets to be easy does it?
Arcane Dimensions doesn't support static entities. That being said, I'll make it work anyway. I'll have to do a test map, but the way I redesigned it really does not require use of static entities it is just highly preferred. Trying winquake build 1018 with a clean install of Arcane Dimensions, I noticed a couple of oddities... not sure if this is to be expected, especially the transparency part since that discussion got a little involved. So FWIW, FYI, etc.:
Main menu graphic has the AD logo missing: https://dl.dropboxusercontent.com/u/11690738/temp/winquake_mark_v_0000.png "Vine" transparencies (not): https://dl.dropboxusercontent.com/u/11690738/temp/winquake_mark_v_0001.png Loaded it in original id1 Software's WinQuake and it doesn't look right either.
Something about one of the Arcane Dimensions gfx.lmp files isn't WinQuake compatible. id Software's WinQuake screenshot - Arcane Dimensions pink menu item vines - Mark V WinQuake doesn't support alpha masked textures on brush models just yet. It will eventually, it's on the todo list. Clarification: Asking about the startup dialog on the Mac. It should work ok now whether or not binary is in the Quake folder or elsewhere.
@pulsar
http://quakeone.com/markv/media/hall_of_mirrors_test_map.zip The above test map will be a good example to explain - mirrors - func_illusionary mirrors - list of things to avoid func_illusionary mirrors cause hard to avoid issues, but a good mapper can map around their limitations. He is quickly done "video" explaining how to use mirrors
Mirrors Tutorial "Video" Download at usual location:
http://quakeone.com/markv Main Features Compared to version 1.1 - Mac version Open GL w/effect | WinQuake - Support for func_illusionary mirrors (pulsar) - Support for same in Arcane Dimensions (pulsar) - QMB particle effects option - Resizable window at any time with mouse - Several other small features - 100.00% resolution of all issues Thanks to the beta testers! Gunter really went overboard and identified several things that could be improved about QMB; dwere caught a few hard-to-notice issues, in particular an obscure rendering glitch. Thanks to Pritchard, NightFright, johnny law, Bloughburgh, c0burn, spy and several others. Upcoming DirectX 9 Version by MH? Probable Direct X 9 version is in the works by MH (with no obligation on his part), from brief descriptions of enhancements it is very likely to be significantly superior to the Open GL and DX8 builds and will likely replace them as default Windows build. Func_Illusionary Mirrors - "mirror_" textures Tutorial video Test map Requested by pulsar. There are limitations to func_illusionary mirrors, the video tutorial shows how to work within the limits. Arcane Dimensions does entities differently than normal for func_illusionary; those are now supported. /Final build of 2016 There are a few minor issues that still exist, though they may or may not be worth addressing:
QMB Particles - All explosions are stifled when underwater. This is really not correct; explosions are not less powerful underwater, so they should not be made to appear less powerful. And I think this is the reason my splash effect is messed up; the QMB system interprets the splash as an explosion (as before, with the spark effect), and so decreases the power of the effect, but since it's not a powerful "splash" in the first place, the effect is just being stifled into nothingness pretty quickly. The +zoom_key alias -- as a programmer, I can't see such un-optimal code and not want to fix it, heh. I did find it is better to save the values and restore them (as you do) rather than just counting on the math to take care of that, because when banging on the key really rapidly, the math can get out of order and mess things up. However, there is still no need for all the "in between" steps in the your alias. It only needs a start, and end, and an animation in between. So this would be much cleaner: alias +zoom_key "valsave fov 1; valsave sensitivity 2; mul sensitivity 0.1; valsave r_viewmodel_fov 3; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10" alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3" Pressing TAB during "Congratulations" text causes the text to disappear. All pitch values should be cl_maxpitch 79.8269 but the minpitch value would not really need altered from -70. With transparency in effect, teleporter surfaces always render on top of water, and water always renders on top of shadows. Erg. I left out a "wait" in that second alias right after the "fov 70" heh.
Should have been: alias +zoom_key "valsave fov 1; valsave sensitivity 2; valsave r_viewmodel_fov 3; mul sensitivity 0.1; r_viewmodel_fov 0; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10" alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload sensitivity 2; valload r_viewmodel_fov 3" Oh yeah, and that old issue where your name is constantly being changed when you mess with it in Multiplayer -> Setup. It should only commit the change when you select "Accept Changes" or perhaps when you exit that screen.
I've added 1 (one) vertex shader to it.
Now, before you start baying for my blood, there's a good and very valid reason for this. But before I give the reason, bear in mind what I said a good bit upthread about D3D being able to software-emulate vertex shaders. That means that it retains full compatibility: there's no bumping of the hardware requirements involved here. Also - it's a single generic vertex shader that all vertices go through, so it keeps with the philosophy of "one place for everything and everything in one place". Now for the good and valid reason. I lied: there's actually two. First, and the biggie, is the dreaded Direct3D half-texel offset problem. If you've noticed that the 2D GUI widgets look significantly poorer quality in D3D, that's the reason why. Another symptom would be black lines around the water textures with r_oldwater 0 (you didn't see this in D3D 8 because r_oldwater 0 wasn't supported). The thing is, the only way to cleanly and non-intrusively fix this is by tagging some lines of code onto a vertex shader. Believe me, I tried other ways, and they all had the downside of needing (in some cases significant) changes to the base engine code (FQ's GL_SetCanvas thing would have had impact throughout the codebase). Essential reading: http://aras-p.info/blog/2016/04/08/solving-dx9-half-pixel-offset/ Second reason: texture matrix. There are API differences with how the texture matrix is applied, and the only alternative way to work around them was to software-emulate the texture matrix and apply it before copying over texcoords. That ran incredibly slow. Potential third reason: I only mentioned two above, but this is a potential third: there are also API differences with texgen, and if in the future Mark V ever uses texgen for anything, this is the cleanest and most performant way of bypassing them. Anyway, I am willing to back out of this if Baker (or any other key user of Mark V) considers it too objectionable, or otherwise considers the fallback modes acceptable, but I do strongly recommend it as the best and most compatible solution. In particular I consider the half-texel offset problem completely unacceptable; while the others would have viable software fallbacks (at a performance cost), fixing half-texel offset acceptably but in a different way would require re-implementing the entire transform pipeline in software (or invasively modifying the base engine code in too many places). Glad you are happy. Look forward to playing your maps!
Tried to illustrate limits for func_illusionary mirrors in the video. @mh - Any ideas you wish to implement even if they are Direct3D only enhancements are fine.
Many of the boundaries I set for this project have been to allow it to reach completion and keep goals in areas of my knowledge set. Your strengths and interests in the advanced/low-level rendering are far higher than mine, use them how you see fit. Is perfectly acceptable for the Direct3D build to have extra features. @gunter - I agree with some of those. Wanted to wrap up. @bloughsburgh - Thanks! Could be fun, even more so if you could have rotating cameras. Security monitors would require a "use" button, I guess.
@mugwump - That is one of the main questions, how to expose the capability to someone making a map. On the mapping side, clearly camera entities would be involved.
And then the secondary question is should it be done through QuakeC instead. The problem I see with this is the someone couldn't make it work with stock Quake. Most of the questions are just how to make it available in a map editor and to do it for multiple view screens - in a way that allows flexibility. I tried to compile this with CodeBlocks, but im getting TONS of error messages.. Is it possible to release a non broken source?? :/
I use Visual Studio on Windows. XCode on the Mac. Every once in a blue moon, I may check to see if the CodeBlocks compile works, but it is rarely up-to-date.
Linux isn't supported at this, if that is what you are trying to do. The WinQuake Debug, GL Debug, GL Release all compile fine with CodeBlocks 13.12 Full Install on Windows from freshly downloaded source.
Although I use Visual Studio and rarely update the CodeBlocks project, it isn't often that I make changes that would cause the CodeBlocks project file to break very much. But the CodeBlocks project has unsupported builds in it too, like the Linux build. I fixed it myself, it was indeed caused by an older version of CodeBlocks... However, for some reason i cant assign my mousebuttons to a key..
Is it possible to add a simple MD3 loader? I want to use a FitzQuake engine for my game (atm im using an older Mark5 version), but i dont want to use mdl. I tried to play warpb_sw4848 demo from quaketastic.com/?dir=files/demos (protocol 10002). It ends around 2 min 40 sec in with the message:
Host_Error: CL_ParseServerMessage: Illegible server message, previous was svc_clientdata Not sure if it's a bug or expected behavior. I had issues with demos too, if you delete the demos (and keep the lines in the quake.rc) the engine hangs up.. Very unstable...
I only added protocol 10002 to support the Warpspasm demos that come with the game and play when you start it.
But thanks for letting me know it doesn't work with user made demos, because I didn't know. @steve - It's unlikely that I would add md3, Mark V follows "the path of one". One format, one name, one place for all formats and types of files. md3 has no place that in that scheme, would be a 2nd model format.
Mark V also has a software renderer that can do almost everything the GL version, but it sure can't do md3. md3 isn't a Quake 1 format, but I can understand why you would want it from a make a game perspective. You might try to convert the MD3 to mdl with the best and most awesome tool ever created Ultimately, Mark V is not made for total conversion purposes. But I do wish you luck with your project. I'm glad you enjoy the engine. /At the same time, please understand I am not an engine coding help forum. What you may not know is that I have had in the past literally dozens of people attempt to make me their personal coding help guy. I'm pretty good at saying no. ;-) That's what I suspected.
Ironically, the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway :D the Warpspasm startup demos get overridden by the latest Quoth's startup demos anyway
I know Preach didn't do that on purpose, but that's highly undesirable. I never did any testing with Quoth 2.2 back in 2014 when I added support for the Warpspasm start demos. I like Warpspasm enough that I may cause it to load in original form so the start demos play. Thx for the reply, but i think i can add MD3 myself to the old base engine i use (its an older Mark5), i mostly want it for viewmodels only because i need the "details" active on it (iron sights etc..)...
I already managed to add a working sound dsp system (based on crowbars psp engine), which is awesome btw. Wow, I'm not easily impressed but that is awesome. Do you have a link to the source for any engine with that modification?
Engoo has sound modifications, and I can't recall the name of the "open source Half-Life engine", but I'm sure it has sound modifications. I think it would be awesome to somehow expose parts of a map, sound modifications. Quake I have not thought about sound for a while, but obviously since Mark V can do Half-Life I think of mirrors, security camera, portals and such because they could add more complex and richer environments to, for instance, a base map. Plus I have largely completed intermap travel-system which requires no QuakeC support (but offers QuakeC the opportunity to intervene). /I couldn't say exactly when any of the above would happen because there are always so many items on a to-do list. One of the main challenges of moving an engine forward is that there are always choices and with limited time some things have trouble finding their way to the front of a queue. Case in point, splitscreen and Linux build may consume much time in future and integration of possible DirectX 9 version by MH or acquired Spike's optimized network compression. It's always of a sea of choices :( I can give you the sources if you want ;)
I plan to control the DSP with simple triggers and stuffcmd, it adds so much to the levels ;) 8x multitexture (which was easy, even for me)
I'm going to offer 4. Here's the reason why: http://www.nvidia.com/object/General_FAQ.html#t6 Summary, for anyone who didn't follow the link, is that with fixed-pipeline OpenGL NVIDIA only offer 4 texture units. I can't think of a Quake scenario where anything more than 4 texture units would be necessary. I think even 3 may be enough to eliminate to the overbright pass as a separate pass in FitzQuake.
is awesome... no idea how that could be implemented in quake maps... trigger volumes?
Unreal Engine used to allow "zones" to be created by sealing off entire rooms and areas, that was a good technique. If I were to add a modification to that certain areas of a map had special zone modifications zones like Half-Life (echo areas) I would probably be inclined to implement it in the following manner:
- A brush similar to func_illusionary indicates the sound region. Static entities are available to the client. A field of the entity indicates the sound modification. - Although someone like Spike may correctly point that this to some degree does not follow the client/server model I would mostly need to examine a way to make it backwards compatible to non-supporting engines. This would also allow easy editing via external Also makes it so no complex new way of communicating sound zones to a client need be added to an engine and would be compatible with save games and everything else. The Engoo engine has some of sound modification capability. It's one of the software renderer engines like qbism super 8.
But yeah /Isn't a soon thing but more likely a vague "probably some time in 2017" thing -- like security cameras security cameras concept video. So many items in the queue + limited time I can see 5 being used for diffuse+lightmap+fullbright+caustics+detailmaps maybe.
Or add 3 more if you split the lightmaps into their own textures. Then add two extras if you want light directions and deluxemaps for bumpmapping. And add 4 more if you want to ramp up specular to a decent exponent... Although its kinda pointless to worry about it if the engine needs to retain a 4-tmu pathway anyway... or two... or one... But yeah, more than 4 and you really should be using glsl/hlsl, trying to do everything with only an alpha channel for temp data is just unworkable. Yeah, eventually I do have something like a "surface effect texture" planned in my head for possible surface effects.
Might as well ask your thoughts on this question to you Although not soon, I would like to use probably 4-8 QME 3.1 bit flag slots but and would like to avoid any possible with what FTE uses. One example might be to indicate additive blending. /I have not put much thought into this lately, but while discussion about future mapping enhancements ensues hexen2 defines modelflags up to and including 23.
1<<24 is the first undefined one as far as fte is concerned. Not that fte implements all of the hexen2 ones, or that I'm even aware of any models that use them... but hey. that said, for additive, you're probably better off sticking with EF_ADDITIVE=(1<<5). Yes, this can be used by mappers, and does not necessitate any wire change (read: protocol uses a previously-unused bit which permits backwards-compatibility on the assumption that old implementations can safely it). maybe some of the other bits you're thinking of are similarly already implemented in another engine. if (!strcmp(gl_vendor, "Intel"))
I see that Mark V has inherited this from the original code too. The D3D equivalent (which is read from the driver so I don'thave control over it) is actually "Intel(R) HD Graphics" so this test will incorrectly not identify it. Strictly speaking this is also a bug in the GL case because Intel may change their vendor string. Change it to: if (strstr(gl_vendor, "Intel")) dx8_mark_v -width 750 -height 550
= borked up screenshots Fixed. This is actually a wrapper bug, so my apologies for my previous misdiagnosis. @Baker: in the glReadPixels implementation, "case GL_RGB" should also be using "srcdata[srcpos * 4..." because the source data will be 4-byte, even if the dest is 3. I may have mentioned a while back that there are advantages to going native, and screenshots are one such. Baker has implemented PNG screenshots, so in the native GL code he's doing a glReadPixels, then converting the memory buffer to PNG format (presumably via a statically linked libpng or maybe stb_image) and saving it out. A native D3D version wouldn't do half of that work. Instead it could just use D3DXSaveSurfaceToFile on the backbuffer. Give it a filename, specify the type, boom, done, three lines of code. I'm going to add some native exports to the new wrapper for functionality such as this. The DX stuff mh is doing sounds really great.
I don't understand most of it, but I hear things like "improved performance." And bug fixes are always good. And if I'm getting the gist of things regarding more rendering passes, this might allow addressing of some issues: Fullbright textures should not be affected by contrast -- it makes them ugly. Screen Blends should not be affected by gamma or contrast -- I have found this is the main thing that makes them far too intense. When I use vid_hardwaregamma 0 and various values for txgamma, the screen blends look perfect, though if I mess with the contrast slider, it makes the blends too intense again. So yeah, if that's a possibility, the screen blends should be drawn last so they are not affected by gamma or contrast. But I have no real understanding of this low-level 3D rendering stuff. Though it sounds like there will be a great benefit from mh's work. Mark V applies gamma and contrasts to screenshots (only) when applicable.
For instance 1) If you are using hardware gamma/contrast, it will adjust the screenshot accordingly. 2) If you are not using hardware gamma/contrast, it will not apply it to the screenshot. So depending on situation, writing directly to file is not necessarily desirable because screenshots could be, for instance, too dark/etc. Hm, there's an issue that looks similar to the previous QMB lighting texture thing with txgamma, but it appears whether or not txgamma is being used, wherever there is fog.
I first noticed it at very long range when I was zooming in, because I use very light fog, but if you set the fog much denser, like Mark V applies gamma and contrasts to screenshots (only) when applicable.
Ahhh, understood. By the way, here's a sneak preview of something I just did: http://i64.tinypic.com/o6flm1.jpg This was actually taken with the GL version, just to demonstrate that there's no shader trickery or suchlike going on. Mark V seems to struggle with complex maps that are smooth in QS. On my questionable system, I mean.
jam2_mfx.bsp is a good example. Right at the start, looking towards the palace produces a very noticeable slowdown. Fitzquake v0.85 also has this problem. @mh - Haha, your water warp. I suspected you would do that ;-)
--------------- @dwere Especially on older hardware, vertex arrays help achieve a more reliable 72 frames per second in the BSP2 era. I hadn't implemented yet them because there were many other things on the to-do list. I'm prototyping an iPad/iPhone version, which uses Open GLES which requires use of vertex arrays so I actually have to implement vertex arrays here in a hour or so. I'm still sticking with the "that's it for 2016", but version 1.3 will have it. --- @gunter - You are probably right on blending. I'm hoping that MH will provide HLSL shader option for gamma/contrast in DX9 iPhone/iPad - 2017 But since I'm making a prototype iPad/iPhone version right now which will controls similar to Minecraft on the iPad which is very playable on an iPad. (Android is more of a pain because very crude development tools which is like banging rocks together to make fire. iPhone development tools have always been very nice.) /Any new builds will be 2017 and unsure where the priority of an iPhone/iPad version. Now that I have stable release and zero issues outstanding, playing around is a bit more leisurely. May upload a video later tonight after I get it initially running I couldn't not do water warp.
Performance. Vertex arrays help with big maps, but they're only part of the story. What really helps is draw call batching, and vertex arrays are just a tool that allows you to do batching. glBegin/glEnd code is fine for ID1 maps but as maps get bigger this kind of code gets slower and slower. Toss in a few dynamic lights and/or animated lightstyles (which stock Fitz also handles very poorly) and it gets worse. Batching is all about taking a big chunk of work and submitting it in a single large draw call, instead of several hundred tiny draw calls. Each draw call has a fixed overhead, irrespective of how much work it does, and that overhead is typically on the CPU. So if you have, say, 1000 surfaces all of which have the same texture and lightmap, drawing them with a single call will have 1/1000 the CPU overhead that drawing them with 1000 calls would. Stock Fitz would also benefit from lightmap update batching. Again it's the difference between "few large updates" versus "lots of tiny updates" with the former being more efficient. Stock Fitz also uses GL_RGB which compounds the problem by forcing a format conversion in the driver. This stuff is mostly hidden on modern hardware, but you can still find devices (and some scenes in maps) where you get an unexpected nasty surprise. Ironically, one way to make stock Fitz run faster can be to disable multitexture. Try it - pick a scene where it gets the herky-jerkys then compare with running with -nomtex. This will cause it to have fewer state changes between draw calls so that the driver can optimize better, as well as batch up it's lightmap updates (for the world, not bmodels which are still slow). Depending on the scene, the extra passes might turn out to be a lower workload. If the engine itself implemented all of this batching then running with -nomtex would not be necessary. The D3D9 wrapper takes the supplied glBegin/glEnd calls and attempts to be somewhat agressive about batching them up. It converts everything to indexed triangle lists and concatenates multiple draw calls that don't have state or texture changes between them. It also attempts to merge multiple lightmap updates. None of this is as efficient as if the engine did it itself, of course. Going into the actual GL code and doing it right from the get-go is always going to give the best results. Well, I wouldn't care whether "authentic" waterwarp is implemented into the DirectX or rather OpenGL build. But the one that would get it would be my personal default. :P
I'm sizing up Requiem to see what unique things it adds for likely addition
I know it can create items (interesting idea), for instance. jdhack had some interesting ideas in there. A question for you, if you know I can't get Requiem to run on Linux, it says "libGL.so.1 not found". Engines like ezQuake run fine for me on Ubuntu Linux or even super old FitzQuake 0.80 SDL. Could it possibly be expecting a 32-bit If you happen to know Well, I wouldn't care whether "authentic" waterwarp is implemented into the DirectX or rather OpenGL build. But the one that would get it would be my personal default.
What if both were able to get it? :) That would mean you and Baker found a way to solve your epic "conflict" regarding its implementation? Sounds like a great X-Mas gift to me, actually...!
I wouldn't call it a conflict, hehe.
The DirectX version implementing DirectX features is just natural. The OpenGL remaining at 1.2 for broad hardware compatibility is not something very bloody likely to stop MH. To say MH is good at rendering is like saying Isaac Newton was good at calculus or that Einstein was pretty okay at physics ;-) Currently going through the MarkV code to figure how it implements gamma and contrast in the GL renderer.
To be honest, I see absolutely nothing in either that wouldn't work in D3D right now; even version 8. Gamma just sets adjusted gamma ramps, which will also work in D3D. D3D does have it's own gamma functions too, but you're better off using the native Windows SetDeviceGammaRamp/GetDeviceGammaRamp stuff (in particular the D3D functions don't work at all in windowed modes, whereas the native functions do). Contrast is just a load of blended quads over the screen. The only thing I see in there that may be a problem with D3D8 is commented-out code enabling scissor test. D3D8 doesn't have scissor test but D3D9 does. For D3D9 I'm going to do something different. I'm going to do shader-based gamma and contrast using render-to-texture. This is achievable with D3D shader model 2 shaders, broadly equivalent to OpenGL 1.5 with ARB assembly shaders so compatibility remains good. It will enable gamma and contrast in windowed modes without affecting the entire display, and it won't require gamma-and-contrast-adjusting screenshots. The interface will be 1 function: BOOL D3D_SetupGammaAndContrast (float gamma, float contrast) which it will be appropriate to call in GL_BeginRendering. Returns TRUE if it was able to do it's thing (or if gamma and contrast are both 1), FALSE otherwise in which case you need to decide on a fallback - either route it through the GL codepath (which should also work) or do nothing. Everything else will be automagic. Likely future scheme, not that this would have any impact on coding anyway
vid_hardwaregamma (*) - following the FitzQuakian cvar scheme that I rather like such as r_lerpmodels 0 (off), 1 (best), 2 (always)... vid_hardwaregamma (or whatever name becomes) 0 - Never. Use best available non-hardware method 1 - Windowed mode uses non-hardware method (looks better on desktop), fullscreen uses hardware method (faster and hardware method is also brighter, some displays tend towards the dark side no matter what without hardware gamma). Default. 2 - Hardware method always. (*) bad name because also does contrast? Also: may notice the code is biased towards GL_RGBA and I have to switch the bytes around to be BGRA for various operations. It isn't actually an oversight or an inefficiency I didn't correct, but rather that OpenGLES only has GL_RGBA.
Just wanted to point that out because I know you may see that code and think "This is so wrong." /The video/input/system code long ago was entirely rewritten in a way to support devices. In some of the files, there is living device code from back in 2014. Hmm.
So, my reQuiem test builds were done on CentOS 6.4. Looking at that setup now, ldd says that my reQuiem-debug.glx executable is using /usr/lib64/libGL.so.1. rpm -qf on that file shows that it came from the package mesa-libGL-9.0-0.8.el6_4.3.x86_64 I don't remember now if that was something that I explicitly installed for reQuiem's benefit. Also: may notice the code is biased towards GL_RGBA and I have to switch the bytes around to be BGRA for various operations. It isn't actually an oversight or an inefficiency I didn't correct, but rather that OpenGLES only has GL_RGBA.
This doesn't actually matter at all in D3D aside from getting the byte ordering right, because you're writing the data directly to the texture rather than relying on the driver to not screw up. writing device memory using bytes instead of a cacheline-aligned memcpy will be slower, but whatever. modern apis just have you write it into ram and have the gpu itself move it onto the gpu's memory so there's no issues with uncached memory or whatever.
either way, d3d10+(eg gl3.0)/vulkan hardware has proper RGBA texture uploads so its not like modern gpus care. older gpus/apis will still need some sort of conversion but its okay to be lazy and submit only the lightmaps as bgra. streaming is the only time it really matters. oh noes! loading took at extra blinks-duration! *shrug* Ok
#include <sys/cdefs.h> file not found Solved with: sudo apt-get install -y libc6-dev-i386 Then next issue fatal error: X11/extensions/xf86dga.h: No such file or directory Does But is already installed. Goes to /usr/include/x11/extension Looks like future is now. See note about warning include <X11/extensions/Xxf86dga.h> instead. on that same page I Googled. Don't have one of those sitting in /usr/include/x11/extensions either. Hmmm. Hope is not brick wall. @johnny - I'm posting this for informational purposes. I never expect anyone in particular to assist, just fyi. I'm hoping someone reading this thread that knows what the above could be about may chime in. I'm working on my quakespasm-irc engine thingy, and expanding it with more streamer-features.
One thing that I've been wanting to add are the joequake demo features. Rather than reinvent the wheel, and being that quakespasm and mark v share a bunch of code already, I was wondering if I could have a look at the mark v code to steal... uh, borrow from. GL_BGRA was really only ever significant as an Intel performance fix, and even then it also needed GL_UNSIGNED_INT_8_8_8_8_REV (which was probably the most annoying GLenum to type) in order to get the fix; without both it still ran slow.
Both NV and AMD also ran slower without these (with BGRA being by far the most important), but insignificantly so; Intel was catastrophically slower. This is trivially easy to benchmark. Just do a bunch of glTexSubImage calls in a loop and time them. Adjust parameters and compare. Both GL_BGRA and GL_UNSIGNED_thing are core since OpenGL 1.2, with the latter being adopted from GL_UNSIGNED_INT_8_8_8_8_EXT in the old GL_EXT_packed_pixels extension. So if you're targetting GL 1.2 you can quite safely use them without compatibility concerns. Since Microsoft did the world a favour by forcing the hardware vendors to standardise on RGBA in the D3D10 era, I don't believe that any of this stuff is even important for Intel any more. Basically if it's less than 10 years old it probably has good support for RGBA (if less than 5 make that definite) so you can really just use RGBA and no longer worry about this stuff. I obviously don't speak for mobile hardware, where the rules may be different, and anyway there are far more interesting formats such as RGB10A2 which lets you do a 4x overbright blend without sacrificing bits of precision and with only 2 unused bits per texel. I never formally benchmarked this format but tests ran well. What's more important about FitzQuake is that it uses GL_RGB for lightmap uploads. Even in the days of robust RGBA support, that's always going to force a format conversion in the driver. Combine that with hundreds of tiny updates (rather than few large ones) and FitzQuake can still chug down to single digit framerates even on some modern hardware. No amount of BGRA can fix that, and here's where I believe FitzQuake has done the community a disservice. There are lots of interesting things that mappers can do with dynamic lights and animated lightstyles, but because FitzQuake performed so poorly with them I suspect that much of that early potential was never realized. NV and AMD both suffer from this, but if all you ever benchmark is timedemo demo1 (or map dm3) with gl_flashblend 1 you'll probably never even notice. Intel suffers from this AND needs BGRA/UNSIGNED_etc. Again it's trivially easy to demonstrate the perf difference, but to robustly fix in the engine requires more reachitecting than I'm willing to do within the scope of my current work. If you look around in the Quaddicted engines directory, you can find older Mark V versions like this one where I marked things very cleanly
Current Mark V isn't structured like for many reasons including that the WinQuake software renderer has been combined into Mark V, but the source is on the Mark V page. ... how the hell did I not see the source link the first time I looked at that page...
just looking at host_cmd.c
maybe use an external file for the bad words array rather than a hardcoded one, that way it can be user updated Probably at some point I'll do that.
Thinking about host_cmd.c give command extra options give silverkey give goldkey give rune1 // rune1 to rune4 If you already have the gold key and wish to remove it, typing "give goldkey" will remove it if you already have it. Typing "give" in the console will display a list of item names. QMB effects: lava balls or knight spikes do not leave trails when traveling very fast (velocity 2000) when the server is at
The QMB trails work fine at Non-QMB particle trails do work under these conditions, but they tend to "skip" a bit. Most engines assume a distance traveled per update frame of 200 units or more is a teleportation.
That's my guess without looking at the code because 2000/10 (ticrate An entity that is assumed to have teleported won't be treated with any kind of continuous movement treatment. I saw on Quakeone, Dutch mentioned Mark V has "a difficult time playing external MP3" on his WinXP computer.
That's not very specific, but I wonder if he's seeing the same issue I reported, where there is a pretty significant delay loading the MP3s, during which time the game is completely frozen up. We tried LOTS of troubleshooting steps in the old thread, but nothing helped for me on my netbook (though the problem didn't exist on my older WinXP laptop). The only thing that made a difference in the end was me re-encoding the MP3s with certain settings that decreased the loading delay (from 17 seconds to 4.5 seconds!). I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.
Also some occasional flickering/corruption when using GL. I know it's not helpful just to say that so I'm experimenting a bit more to see if has anything to do with my latest NVidia driver update and/or if it happens in other engines. If there's anything you'd want me to do or try that would be helpful in debugging that, let me know. FWIW, latest qconsole.log is at https://dl.dropboxusercontent.com/u/11690738/temp/qconsole.log Hm. Upon startup, my autoexec.cfg sets up some aliases (or runs other cfg files that set up aliases).
But then if I am sitting on the server and I reconnect to the same server (by "connect fvf.servequake.com" -- I was toggling external lit files), many of my aliases are forgotten. But not all of them.... For example: alias zoom_out "chase_active 1;chase_mode 1" Is always forgotten upon reconnecting, but: alias start "changelevel start" is never forgotten. This is pretty inconvenient. It means I have to re-run my cfg files when I want to reconnect or connect to a different server without completely restarting Mark V. QMB effect difference: Particles in Quake are "fullbright" but the QMB blood effect is not fullbright.... So, in Quake you can always tell when you are hitting a monster in a dark area, but with the (more realistic) QMB blood, you can't tell.... Perhaps in this case it would be good to throw in a few standard red particles (even QMB particles are fullbright) in addition to the blood sprites (they are kind of sprites, aren't they?). But this will fall under QMB fine-tuning.... alias zoom_out "chase_active 1;chase_mode 1"
Cannot reproduce. I bound the above exact alias. Connected to a random server. Disconnected. The alias was there. Reconnected. Disconnected. The alias was there. Even connected to your server, disconnected, reconnected, changed the map, disconnect, reconnect, disconnect. The alias was still there. red fullbright blood - monsters in the dark Interesting difference. Although I haven't looked into it, I suspect QMB blood is already fullbright, it just isn't very bright. Something to think about. QMB blood types 1 and 2 have a blend mode of GL_ZERO, GL_ONE_MINUS_SRC_COLOR, so they're not lit, they're just blended with the background geometry.
Probably should change then. At least for the ones that aren't intended as true "ambience" and few of them are.
Ok... There's some weird interaction of FvF + my tricky aliases + Mark V
So in FvF, when a player connects, or when a map first loads, I do: stuffcmd(self, "re-exec\n"); Then I can set up stuff like this, in autoexec.cfg for example: --------------- alias fogon "fog 0.05; bind f8 fogoff; alias fogset fogon; echo Fog On" alias fogoff "fog 0; bind f8 fogon; alias fogset fogoff; echo Fog Off" alias re-exec "fogset" alias blah1 "echo blah1 is set" fogon alias blah2 "echo blah2 is set" ------------------ Yeah, I don't know how "correct" that is, but it works. It lets me toggle fog on and off with F8, and at each level change the automatic "re-exec" alias will run the "fogset" alias which will be assigned to either the "fogon" or "fogoff" alias, depending on which I last toggled with the F8 key.... But I think the problem is arising where I am assigning one alias to another alias like that ("alias fogset fogon" within the fogon alias...). So, as I said, usually all this works fine. Every level change the fog setting will be re-applied after the level starts, or upon first connecting to FvF. But if I am sitting on the server and I re-connect to the server, things go wrong, and ANY alias that was assigned AFTER the "fogon" command in the cfg above will be forgotten (so blah1 above will remain, but blah2 will be forgotten, as will any alias you have manually entered into the console). OHHH, I think I may get it... or part of it.... It seems to happen upon DISCONNECTING from the server. So this may be happening: - All aliases are set up before connecting. - Upon connecting, the server has you run "re-exec" by stuffcmd, which runs "fogset" which runs "fogon" which includes "alias fogset fogon" so now Mark V thinks it's a SERVER stuffed alias, so it discards it when you disconnect from the server....? Maybe? That still doesn't explain why ANY alias set after that point (either in your cfg file or manually by console) is also forgotten.... Let me see if I can trim this example down a bit more.... The above fog setting code is actually useful (to me anyway -- I don't just do this crazy stuff for no reason!), but here's just a proof of concept to show the issue I'm having: ----------- alias setblah "alias blah say blah" alias re-exec "setblah" alias blah1 "echo blah1 is set" setblah alias blah2 "echo blah2 is set" -------------- The odd thing is if you remove the manually running of "setblah" from the autoexec,cfg file above, then everything seems to work, and only the "blah" alias will be forgotten upon disconnecting. Blah2 will remain. Ah, but any alias you set AFTER connecting to the server will be discarded. But if that line is there, then every alias after that point will be forgotten upon disconnecting from the FvF server.... blah2 will be gone, as will any alias you set in the console after that point. That's weird, right? QMB Effects: I think I know why my splash effects are being destroyed so quickly... and also why my chat smoke looks a bit odd.
It seems that most QMB particle effects are quickly removed if they are touching a player. Try jumping up and shooting the floor below you with the shotguns. You will see that the particles vanish as soon as you come back down on them. Perhaps this is an attempt to prevent obscuring the player's view with too many particles right on top of him? Though the explosion effects are what's really bad at doing that, and this doesn't work for them! But yeah, that's messing with my splash effects, which are created at the player's location. QMB particle effects are quickly removed if they are touching a player
They are. In single player fire a rocket an even angle. Type "freezeall". Now with everything frozen except you Walk through the smoke, any smoke you walk through goes away. I've noticed that with the latest Mark V, it doesn't carry over my video settings (from id1 config) when playing a mod.
I used to have Mark V read those settings only from id1. Then someone said, I when "I play a mod, it ignores my settings I changed when I play it next". So I had to iterate through the proper Quake way. Which might describe what is happening in the above. To get it to be ideal (both!) would be bit involved, but I do have a plan for that in version 1.3, it's elegant and simple. It also involves some slight evil, but it's awesome kind people like and some other engine coder will say "Ah, that's ingenious." Story for another time ;-) my latest NVidia driver update Let me know. Is it new for the driver or new for the version of Mark V? They say NVidia's latest driver does flicker, but I'm not going to assume that it also couldn't be the engine's fault somehow in some rendering circumstances. None of the FitzQuake derived engines have a state manager. Which means there can easily be an errant situation where something crazy like a glBegin without a glEnd or two of them or such other possibilities exist. 1) If the problem persists or exists without the current driver 2) Or if a previous version of Mark V doesn't have issue 3) Or if a certain map 4) Or certain combination of options Short version is that at some point Mark V will have state manager, which would reduce the chances of the engine being at fault greatly (but a few other situations would still be possible). Let me know if it persists and if it happens with a certain map or a certain setting on. It happens to me too. It has started once I switched to geforce 1060 videocard. It happens in both old and new versions of mark v on any map. I hope it helps.
And there's one minor issue about mirrors. I want to make a small map about mirrors. I placed two mirrors on the opposite sides of the room (I know it's not the way it should be intended, but it looks soo cool), you can't see them both at a time, they reflect well, but one of them turns off once I stand close the other mirror (touching it with player's back). I supposed that the second mirror somehow got in the view (but it didn't) so I placed a clip brush in front of it, so I can't get close to it. But it happens the same way once I touch that clip brush. And it always happens with only one of two mirrors (the rooms are completely symmerical), while the first one works as it should when I touch it with player's back. I tried it in two different rooms and the problem always occurs with the south mirror. The problems disappears once I get 1 unit away from the wall. It seems that the flame cut-off system for the QMB particles doesn't work on replacement models. I'm using this pack and the flame polygons stay:
http://www.quaketastic.com/files/models/auth_mdl163.zip Another minor nitpick is that only the main Enter/Return key works in the menus, the numeric pad Enter doesn't. backbuffer.clear(depthandcolour);
for (i = 0; i < nummirrors; i++) { scene.addclipplane(mirror[i].surfaces.backplane); //ensures the mirror can only draw what is actually reflected, and not things that cross the mirror's plane. //fixme: set scissor region mirror[i].draw_reflectionof(scene); scene.killlastclipplane(); mirror[i].draw_diffusetransparent(); backbuffer.clear(depthonly); //anything in the real scene should not be obscured by the mirror for (j = 0; j <= i; j++) mirror[j].draw_onlydepth(); //mask the depth so nothing further within the real scene can overwrite. } //fixme: reset scissor scene.draw(); assuming I typoed it wright and you already know which mirrors you want to draw, the above algorithm should allow you to have cubes with mirrors on each face or whatever. if you can make the mirror-list calcs recursive like in FTE(r_portalrecursion > 1), then you can get mirrors reflecting other mirrors. Just beware that if one mirror can see two mirrors then any further recursion will likely be exponential (read: really slow). here's some obscure territory
Quake is originally designed for 320x200 resolution to be run on 4x3 displays (just like Doom). This means, that whole screen should be stretched vertically. The original game nicely adjusts viewport so that actual gameplay window is always at true aspect no matter what resolution is set - 320x200 will look exactly like 320x240. But the UI is not. It is designed to be stetched, so it only looks right on 320x200 and 640x400 resolutions and is "squished" on every other. So what's the problem? Mark V removed id's aspect corrcection and treat every resolution identically. Setting up 640x400 and 320x200 result in stretched in height gameplay window. The ideal solution would be to add an option to make correct UI scaling. Here's some example shots of original winquake and Mark V scaled to 4x3 and upscaled http://i.imgur.com/ZnPksXb.jpg http://i.imgur.com/mJLsJH5.jpg http://i.imgur.com/dWRoC5M.jpg http://i.imgur.com/fj0f4aI.jpg http://i.imgur.com/n8lznjF.png http://i.imgur.com/tmH5eHL.png http://imgur.com/a/jAW3U Right now, I treat Open GL and WinQuake identically (it's biased towards Open GL treatment).
From your screenshots I do see what you are saying. Thanks for providing screenshots. At some point like what Spike hinted at, I would like to improve the mirrors.
There are certain 3D calculations, reworked drawing, even tool support (.vis) and possibly some recursion that could make mirrors better. Blocking a mirror with a brush doesn't necessarily help because Quake map vis truly sucks and does a relatively poor job (play r_lockpvs 1 and walk around and be prepared for surprises). I'd like to put mirrors on 2 sides of a room too. Limits suck and you can hope for better in the future, but right now you can't have 2 mirrors that can see each other according to map vis. And it is worse than that, because in the current implementation there should not be a location where 2 mirror planes can be seen from anywhere in the map. That being said, it still gives plenty of freedom to do awesome stuff with mirrors --- even with current limitations. Yeah, I hear you.
Original QMB as witnessed in JoeQuake or similar engines, would actually override a custom flame.mdl with its own. Allowing for no possibility of using a replacement model for flame.mdl at all. One possibility among many is that I might at some point do the flame drawing more aggressively to not require my "sawed off flame.mdl" method --- the flame would acceptably draw over the part of the model that shouldn't be shown. At the same time, one problem with the QMB flames method is it is tailored to pak0.pak flame.mdl. It is probably easy to resolve in the engine.
In a few weeks, I'll probably have my hands on a NVIDIA "gaming laptop" or 2. All my machines are AMD, including the Mac ones. :/ Random idea: When doing a local multiplayer game in Mark V (basically a listen server), could you make it honor the sys_ticrate setting? "force_ticrate 1" or something.
This would be handy for testing how your mod is going to actually run on a server, which will actually use the ticrate settings, as opposed to just running it on your own computer, where it will run as fast as your FPS allows, which alters the physics.... This could be useful to mappers too, for testing their maps -- the gravity physics behave differently when connected to a server with a ticrate, as opposed to when you're playing it on your own computer. For example, when a mapper creates a jump that is just make-able in the "single player" (local) environment, that jump can become impossible when playing on an online server (examples: playing online -- depending on ticrate -- you can't jump up the stairs out of the shallow water pit on e2m6, or out of the lava under elevator on e3m7). In FvF I actually change the default gravity from 800 to around 700 in order to make the jumping more like it is in the local Quake environment. Anyway, being able to force Mark V use the ticrate setting locally would allow mappers and modders to test their stuff using the physics that will apply when someone plays online. Normally to do this, we have to set up a dedicated server then connect to that on same computer. And I just wanna make sure you didn't overlook my additional report about aliases being discarded above: #657 I understand why one alias would be discarded (interpreted as a server stuffcmd alias), but why's it also discarding every other alias which was set after that point? Ticrate is an endangered species to Mark V.
At some point, Mark V will have fps independent physics, Spike's network compression and, likely, prediction available as an option. Aliases: I took a shortcut and any aliases created on a remote server are purged. Including ones typed in the console while on a remote server (and then forgot I implemented it like that). Since aliases don't save to config anyway in regular Quake, someone would manually have to add them their autoexec.cfg (or what not) anyway. So this reminds that there is a little bit of unfinished business in that sense. That is an interesting question. The answer works like this
There are 2 types of projects: 1) Outside-In. Seeks popularity and attention. Wants to be easy to follow. 2) Inside-Out. Seeks quality. Meritocracy. <----- (you are here) Interested in high quality participants and higher levels of engagement. Each build has a list of changes in the build post so it is documented. Making things easy to follow isn't a characteristic of an inside-out project. So is the name "Mark V", yields useless search engine results ;-) Pre-calculated strategy to limit participation to the most knowledgeable A+++ contributors. Even the dozen 1 or 2 post contributors have contributed invaluable knowledge and insight. /But when the WinQuake through GL build happens, I'll be sure to let you know. Think I'm wrapping things up roundabout now and am getting close to a code handover. I expect to have some further work to do based on feedback from that, but right now I'm pretty damn pleased with how things turned out.
A bunch of perf testing comparing with both the original version of the wrapper (in the original DirectFitz) and that in Mark V (which I wasn't aware used a markedly different version until quite recently) shows improvements on both. It's not going to be earth-shattering with lightweight (ID1) content, but should pull ahead more as the polycount goes up. For the record, here's what's new/changed/improved/etc: * Combine multitexture modes. * Fog is per-pixel only. * glCopyTexImage/glCopyTexSubImage for framebuffer water warp. * Half-texel offset corrected. * Polygon offset corrected. * Scissor test. * Shader-based gamma and contrast. * Stencil buffer. * Texture matrix. * Vertex arrays. * Vsync corrected. The FitzQuake codebase I've worked on also includes sample code for the following (in what I hope is going to be relatively easy to port): * Dynamic lights on moving brush models (Mark V may already have this, I haven't checked). * Underwater warp. These are both implemented using Baker's standard of clearly #defining the code changes so you can quickly and easily find them all. As a nice bonus they also work in the GL build. So I've some work left tidying up the interface and making it more conformant with what Mark V is currently using, but hopefully sometime over the next week I'll be doing a first code drop! Sounds like a very nice feature set!
Is the depth buffer range ability used for mirrors included? The vertex array support will be a welcome addition, as will all of the other new functionality, of course. I did modify the DX8 wrapper, but if I recall the changes were mostly organizational or to have more precise control over certain steps. Dynamic lights on moving brush models Yeah, has had that for a very long time ;-) Depth buffer range should be working correctly now, yes.
Dynamic lights is just a fix for a long-standing Quake bug whereby if a door, plat, train, etc moved, it still picked up dynamic lighting from it's old position, not it's new. Check out the secret at the start of e1m4 for example. Give yourself the RL and fire a few rockets at the plat in it's starting position. Then trigger the secret, let the plat go down, fire a few more at it in it's final position. You'll see what I mean. I knew there was a high probability Baker already had this, but I included it in the hope that other engines would pick it up too (e.g. QS doesn't have it) because it's such a basic feature and genuine improvement. Reminds me of something I should mention now, in the event you are interested in doing this:
A mechanism for rendering verts interpolated between 2 frames (factor of 0.0 to 1.0 between the frames). I can't recall the details of the conversation and insideqc is immune to Google searches. If I recall, you stated this is impossible by any means in Open GL 1.x, but quite possible in D3D. /Mention because if you have thought about it already, I suspect you would later GL_ARB_vertex_blend.
The extension exists but I've never seen any hardware, either for real or in the various registries/databases, that implemented it. I suspect because any hardware that would support it also supports vertex shaders, which can also do the job. D3D since at least version 8 has also offered the capability to do fixed-pipeline vertex blending, and hardware/drivers do support it. I did write code that used it once but don't recall the details. It was easy enough though. IIRC stock Fitz does a lot of multipassing on MDLs and even if you didn't go all the way to hardware blending it wouldn't hurt to blend once only in software & cache the results for subsequent passes. Actually on reviewing the GL extension it doesn't seem to provide "tweening" capabilities, being limited to blending matrices instead.
So this seems to be another of the ARB's "we don't need the telephone, we have plenty of messenger boys" moments of glory. Sigh. Isn't something necessary or anything, just wanted to raise the thought. There may be a lot to test anyway ;-)
Looking at the code there is a per vertex color component that comes from a table depending the lightpoint value (dynamic light color where player is standing). I don't know how that easily gets into a color array, haha. IIRC stock Fitz does a lot of multipassing on MDLs
I think the fitz0.85 MDL code actually gets away with one pass, if you have the extensions: if (gl_texture_env_combine && gl_mtexable && gl_texture_env_add && fb) //case 1: everything in one pass - Looking at the code there is a per vertex color component that comes from a table depending the lightpoint value (dynamic light color where player is standing). I don't know how that easily gets into a color array, haha. Yeah - what I concluded when planning QS's r_alias.c updates was that, if I was going to go to the trouble of lerping in a vertex shader, the color calculation had to go into the shader as well. Otherwise, I figured having the CPU still calculating lighting on every vert per mdl per frame (and still uploading data to the GPU every frame) would mean low performance gains for a lot of programming effort. So what I ended up doing is passing in "shadevector" to the vertex shader - that's the fake light direction calculated from e->angles[1] and quantized, as well as the color sampled from the lightmap, and the lerping fraction. Then the shader replicates the lighting calculations that the Fitz code does on the CPU (except using MH's reverse engineering of anorm_dots, instead of the table itself, for convenience). aye, lerping verts on the gpu is kinda pointless if you're not also calculating lighting based upon it too.
ideally, use drawelementsindirect and throw 512 ents at the gpu per draw call, with atlasing/texturearrays or whatever for textures and SSBOs for the vertex data. you should get some awesome framerates that way at least when compared to other engines trying to render 10+k knights at a time. actually using it without breaking everything else is more of an issue. yay compat... Makes sense, in the past I've wondered how much that calculation matters for objects other than the view weapon or extremely close items. In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation.
In fact, I've wondered for interpolation whether or not floating point (0.0 to 1.0) is overkill for interpolation.
Floating point is likely going to be faster than alternatives on modern CPUs. By which I mean anything in the past 10 or so years. http://www.quaketastic.com/files/screen_shots/DirectFitz_D3D9_WindowResizing.jpg
Knew you'd be pleased :) As it turned out the wrapper supported it anyway (aside from changing a window style to allow for resizable borders in the reset code), it was just engine code changes that were needed.
The version of the wrapper used by Mark V also lacks one function (other versions of it had that function) that can reset the mode without having to recreate the window, but that can easily be provided if Baker wishes to retain D3D8 for any reason. #define R_LIGHTPOINT_ON_BMODELS
Include brush models in lightpoint calcs so that if you stand on a plat, train, etc you pick up light from that bmodel rather than from the underlying world geometry. http://www.quaketastic.com/files/screen_shots/DirectFitz_D3D9_r_lightpoint_bmodels.png I've been fiddling around with some batch files that could use Mark V and its install command as an "easy button" for getting some popular Quake SP content installed. I've come across a bug/quirk in the command behavior:
Sometimes a zipfile does not have any top-level folder, and also does not have any pak or progs, but does have things other than maps (so it likely does need/want to be in its own mod folder). arcanum.zip and mapjam6.zip are examples of this; they contain lots of content aside from the bsp files, but the installer just puts the bsp files into id1\maps and throws the rest of the zip content away. There's a few different ways to fix that if you want to. FWIW my own preference would be for the install command just to always put installed content into its own mod folder (or have that option available). Also something interesting I just noticed with installing warpspasm.zip. I see that there an "FMOD.DLL" file in the original zip that gets extracted as a file named "dll" into the warpspasm gamedir.
Haven't really investigated this yet, but this may be because most of the extracted files are in the "warp" subfolder of the zip, but FMOD.DLL is not. So when doing path-munging to get the base file name, Mark V may incorrectly skip over too many letters of the path. I wonder if there is a tutorial somewhere to add a better modelformat to FQ?
Im thinking to add a (simple) MD3 loader based on JoeQuake or even IQM.. Would it hard to add IQM to FitzQuake? I added IQM to the RMQ engine, which was based on a much older build of QuakeSpasm that was nearer to FQ.
The big constraint of IQM in the context of Baker's stated goal to not go beyond GL 1.2 is skeletal animation: it's just far too slow to run this on the CPU. Even as few as 3 to 5 moderately complex models in view will pull your framerate down to a significantly low percentage of what it was. Stock FitzQuake is already CPU-bound and the last thing it needs is even more loading. MD3 should be easy enough I think (I've never coded it up myself so can't comment more) and MD2 should be very doable (it can even share data structures with MDL). @mh -
true lightpoint I would be interested in using your implementation of getting the light from brush models as a cvar or a worldspawn key to activate it. There are existing maps that this change alters the lighting in an undesirable way so it was removed from Mark V, but also I never quite 100% trusted my 2012 implementation. But I can remember pulsar wanting such a feature and activating it via a worldspawn key (name? "true_lightpoint" "1"?) would be ok for sure for a map wanting it. dx8 build after dx9 Yeah if you have an enhancement for dx8 I've been slowly trying to wrap up implementation of the other platforms I want to have builds available for one example. @johhny Thanks for the heads up on how certain specific files that don't contain primary playable Quake content or that weren't planned for in the installer. About batch files, this reminds me that I should make sure Mark V can play demos via file association c:/quake/mark_v.exe +playdemo "c:/path_to_file/mydemo.dem" Same for mark_v.exe +capturedemo "c:/path_to_file/mydemo.dem" @steve - Mark V won't be doing IQM, etc. and isn't suitable for total conversions, etc. Why not use an engine like FTE which does fancy model formats and can even run in a web browser and is built to support total conversions? @Baker:
Why im currently using FitzQuake is because my current project is based on an abandoned psp project which uses a customized engine from crowbar and porting it to pc would be basicially just copy/paste/modify my own modifications (so it basicially becomes a stand alone game using fq). Using FTE would be a nice alternative ofc, but i dont know anything about csqc.. If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?
Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well. No obligation, of course. ;-) /I figure since your knowledge of the @gunter - I made a stab at making the blood fullbright dark red, but the existing particle texture is not suitable :( Not even reversing the colors, etc. The textures in question are rather hard-wired for "subtractive blending". So that imperfection is likely to live a while, unfortunately.
@steve - I hear you. And empathize. There are csqc tutorials at insideqc, I suspect you already know this. If even mh has trouble fully implementing iqm at a good framerate, any mere mortal (including myself) has a 0.0000000000 chance (plus my interest in iqm for Mark V is also 0.0000000000). If I were in your position, I'd start learning csqc and switch to fte. If you could, could you also have your alternate truelight point throw the (msurface_t *) it hit to a pointer and the distance?
Without looking, I think lightpoint has to return at a minimum the color rgb (which I think it puts in a global). It would be preferable for it to also return the distance, the model (model_t *) and the surface (m_surface_t *) to globals as well. They're all trivially easy & I took the opportunity to clean up the code a little too. Interesting thing: this should also work for putting shadows on bmodels (because "lightspot", used for positioning shadows, also comes from R_LightPoint) but currently it doesn't. I'll need to debug that a little. There's room for substantial optimization in all of this code. With r_shadows 1 R_LightPoint is actually run twice for each entity; cull tests and a few other things are also run twice. There's a whole block of work that should basically be done once only much earlier in the frame. Again, this stuff is such that it's not going to grossly impact ID1 maps, but start ramping up the entity count and it will make it's presence known. o.O
the engine supporting csqc doesn't mean it MUST be used, you can still get quite far without it (eg: smc, tenebrae etc). Thanks, MH!
They're all trivially easy Then here's a quick question. Would you be interested in making SV_RecursiveHullCheck return the (m_surface_t *). I have a hilariously awesome and clever idea for traceline and SV_Physics. But I need traceline to return the surface because if it does, the check is "free" (no extra cpu). /If this is possible. Also obviously, no obligation, now or ever. Keeps engine coding more fun ;-) Would you be interested in making SV_RecursiveHullCheck return the (m_surface_t *)
Not quite the same; the server code doesn't have access to this data, it just uses clipnodes and planes in the hull, not even touching regular nodes. So the reason I was looking at the install command: I was thinking about building a "Quake singleplayer newbie quickstart" package around Mark V and the Simple Quake Launcher. It turns out there is still a LOT that has to be explained, but the menus and install feature of Mark V do help a little. A quickstart package would be a nice thing to have handy for sharing if for example Quake goes on sale in the Steam winter sale tomorrow.
I wanted to provide batch scripts that would help install a sampler of custom Quake content. I laid some ground rules to pick highly-rated and/or influential or classic stuff from Quaddicted, rather than just trying to pick my personal favorites, and ended up with almost 30 selections. I thought the batch scripts would be pretty simple buuuuut it turns out not so. There are sometimes mod patches to install, sometimes other things to fix about the mod (like if it includes an autoexec.cfg file that overrides your own), etc. And then there's the Mark V install command issues. At this point I'm not sure if the effort was worth it :-) but it's done and it is what it is. The Mark V issues so far are just in the two buckets that I mentioned in previous posts. Either 1) failing to install all the files (because no progs.dat or pak file in the zip), or 2) mangling some file names because of subfolders. Of the content I tried to install, these were in the first bucket: arcanum, apsp3, func_mapjam2, mapjam6 and these were in the second bucket: nehahra, warpspasm The second bucket is fixable from the batch files just by doing file commands. Although in one case a file with a short name actually gets completely nuked by the path issues, but that's OK because I didn't want it anyway (the fmod.dll in nehahra.zip). The first bucket I can also fix in the batch files by extracting the stuff from the zipfile myself instead of letting Mark V do it, but to unzip files I'm using a feature of Anyway that's a lot of typing about install issues. To help break up the wall of text I'm going to stop this post and then have two short posts with some questions. OK so FYI, here's the installer batch scripts as they currently stand. The "installers" folder should go into your Quake folder next to Mark V: https://dl.dropboxusercontent.com/u/11690738/temp/installers.zip
The If anyone wants to try them out I'd be curious to hear about problems you encounter. I probably will share these around during the Steam sale, likely bundled with Mark V and the Simple Quake Launcher and a bunch of readme files. I'm sure only a few people will make use of them, but even so it would be cool to get a tiny bit of advance testing. Even if you are on an earlier version of Windows and don't have So if anyone gives these a try, please let me know if they work or if they don't. If it's an interesting issue you could post it here, or otherwise to avoid cluttering the thread you can email me. Use the email address that's in the page footer of http://neogeographica.com/ Last thing for now, a question:
When trying to give people a foolproof way to run Quake content, the major gotcha I'm left with is how deal with a mod that needs a base game. Like how warpspasm needs Quoth. I can install Quoth for them but I can't make them specify Quoth as a base game when they launch Quake to play warpspasm. I know that Quake Injector solves this, but getting people to correctly install and use a Java program has turned out to be a hurdle. It's kind of bad that the mods and engines themselves don't declare and enforce base-game requirements. Has there ever been any discussion of standardizing on a way to solve this? Some metadata that the engine would recognize and honor? Forgive me for being an idiot here, but the Quake Injector is open source right? Is there any particular reason why its method of handling unpacking and installation isn't used by MarkV?
Obviously it's not something you can convert (It's java, after all), but surely the logic that it runs can be reproduced. If that were the case I imagine the only compatibility issues would be ones shared by it as well, rather than all these new ones that seem to have cropped up here... I'm sure there's a perfectly good reason why this wasn't done, but I don't know it and this question has been on my mind a lot recently. Mark V can unzip most zip files properly just by itself.
The Quake Injector, as it is currently written, cannot. A brief discussion with Spirit, he was like "Ah, why didn't I think of that?" when I told him the secret sauce. So the short version goes like this http://www.gamers.org/pub/idgames2/partial_conversions/ The goal of the Mark V is to not be dependent on a database to give independent parties the potential of possibility of creating their own archives. Also I view the Quake Injector as too permissive in the unzipping, I also think it does it slightly wrong -- a small gripe -- but engine developers worry about "the little things". The "installers" folder should go into your Quake folder next to Mark V
I hate to have to say it, but this is where "n00b-friendly" breaks. My experience was that getting stuff into the right folder(s) is the number 1 difficulty people have. Yeah, that's why I will probably bundle w/ Mark V and SQLauncher already in the correct folders if I share outside of this forum.
Although they will still have to understand folders to some extent in order to put pak files in the right place. Hmm maybe I should bundle in Baker's ez-installer for Mark V instead of just the Mark V exes, since I believe that will go fishing for pak files in Steam or GOG installs of Quake. In the end though you're going to have to deal with files and folders at some point if playing Quake mods. There's eventually always going to be some sort of gotcha that an ez-installer can't solve. Might be possible to get past the initial hump though. having never looked into how the Quake Injector works, I didn't realize that it had specialized instructions to unpack troublesome archives. Darn.
Perhaps if it were possible to reference that database where possible? That way you could maintain compatibility and not rely on it for unpacking, but also benefit from the effort put into making it work. I'll do some thinking.
I like to do thing in slow motion, particularly during this time of the year. I thought of a reply, but I'm going to hold off related to theme of the movie "The Prestige" (the trick impresses everyone, revealing secret impresses no one). I like the night and the cold and being there is an actual winter this year (awesome!), and this being the longest night of the year means that to be a decent person according to my standards must involve beverages of yuletide merriment. ;-) /That being said, one of the folders of the source code doesn't seem to utilized much by Mark V. ;-) I wonder why it is there?!?!? Hmm maybe I should bundle in Baker's ez-installer for Mark V instead of just the Mark V exes
Copy the URL of the Mark V ez installer to the clipboard. Backspace out the extension (remove Now you have the Mark V ez installer source code to play with as you please so you can make somethign to your liking. I know you have an interest in user-friendliness.
You may find this 3.5 year old Mark V build intriguing R8 build from 2013. In it, type "tool_menu 1". Pressing the Windows key activates the menu. Mark V R8 2013 - Menu Prototype Screenshot 1 Mark V R8 2013 - Menu Prototype Screenshot 2 I'm not sure where this fits in to any conversation. I downloaded an old build of mark v which mentioned a ghost demo, do you have a version with this code? I may want to incorporate it into my speedrun/irc mod.
//#define SUPPORTS_GHOSTING_VIA_DEMOS // Baker: Older Mark V had this. Ditto. Race a ghost from a demo. The R8 build above (#716) has that feature and contains the source code. Although I liked the feature, there are situations that can arise that are impossible for "race your ghost" to handle. Was a cool concept.
All I want is for the demo player position to be played, I don't want him to interact with anything in else the world.
I'll have a look. I want a better understanding of how demos work anyway. cheers. http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2016-12-22.zip
I expect that you'll have some feedback and I'll have some work. Direct3D 9 SDK June 2010 is correct SDK?
https://www.microsoft.com/en-us/download/details.aspx?id=6812 June 2010 should do, yes, although I wrote it to work with any version (so long as it includes D3Dcompiler.h)
Incidentally, I did all of this work using Visual C++ 2008 Express, and I do recommend that you build the initial DirectFitz project before trying any integration to Mark V.
Finished compiling
MH Direct X 9 - FitzQuake 0.85 ---- @mh 5 minute mark comments 1) Wow! That's a nice framerate! 2) Adjusting the brightness moves the pixels on-screen by 1 pixel up and by pixel 1 left. Presumably gamma != 1. 3) vid_vsync sure works. I had to turn it off to check it out 4) I see you took a different and more organized approach, implementing several C++ instead of the single file approach. Not that this makes any difference at all. 5) Didn't see any 6) Haha, it resizes! 7) Surprised no contrast cvar, you used to be very insistent that any decent engine must have contrast ;-) /I agree with that, obv. 8) Haven't checked the contrast/gamma ranges. Initial comments. May be a few hours or possibly even tomorrow before I have more comments or a may change my mind and investigate it a lot more before then Main reason: I was coding something which is 85% of a complex change and if I don't strike while the iron is hot, I may forget the subtle details. But needless to say, I'm liking this Direct3D 9 wrapper quite much! There should still be one #pragma comment (lib), for d3d9.lib, but since that only exports a single function I could very easily dynamically link instead. Everything else is dynamically linked at runtime, primarily to resolve problems caused by different versions of the d3dx9 and d3dcompiler DLLs.
I didn't implement a contrast cvar because I wanted to keep intrusive changes to the original engine code at a minimum. Of course I then went and made a lot of intrusive changes elsewhere! Anyway, the brightness/contrast setup does support contrast, but the engine just hard-codes it to 1; I took the calculations from Mark V's gamma tables (used for applying brightness/contrasdt to screenshots) so they'll be consistent with those. I understand what's happening with the "adjust brightness/shift by 1" thing but I'm not sure I understand why. Need to look into that more. Yes, I found the single-file approach quite difficult to work with when making wide ranging changes. I switched to C++ quite late and mostly on account of a comment you had on wglMakeCurrent in the old wrapper - so that part is your fault! After fixing that up, I found that I wanted a "context" struct to keep things better-organized than using a lot of standalone globals, then found that I was passing this struct as the first param to a lot of functions. That's the point at which one needs to consider switching to C++, for code-cleanliness and robustness if nothing else. On the other hand I do see a huge appeal to the single-file approach. I love stuff like stb_image where you just drop in a single header and you've got everything - so easy! But at this stage I don't think I'm going to switch back. I'm going to let you chew over things for a short while before I pick it up again; currently debating what the best way to deliver new versions of this is going to be. Obviously you'll need to change some of the public API stuff "from "gl*" to "d3dmhgl*" or whatever) and I seem to remember that you're comfortable using WinMerge so I think I can just bash ahead with the internal stuff and leave it up to you to work out the diffs? took the calculations from Mark V's gamma tables
Cool, now I don't have to look into that. I was messing with the contrast just 30 seconds ago to play with it. Quakespasm uses Mark V's gamma/contrast system and Mark V's gamma/contrast system is backwards compatible to WinQuake. I put a lot of thought and planning into Mark V's gamma/contrast system and I was, for instance, very pleased when ericw implemented it same in Quakespasm. Also noticed some other things, like colored lights "option" for scrag/wizard attacks and such. And a possible dynamic light calculation correction in r_lightpoint not related to the concept of getting the light from inline models (*5 or *10 models, etc.) R_LightPoint was actually the last thing I worked on, earlier on today. I'm really pleased with how that turned out, but still annoyed about shadows.
I just really love adding those extra dynamic lights. I can understand that they might have been slow in 1996, but in 2016 they're so cool to have and add so much to the game. Reminds me that I haven't corrected the stock Fitz support for > 32 dynamic lights; that's very badly broken. Reminds me that I haven't corrected the stock Fitz support for > 32 dynamic lights; that's very badly broken.
I have 128 dynamic light support that was based on a tutorial you wrote, but whether or not you'd like tutorialize within DirectFitz 9 for, say, Quakespasm or other engine without feature is obviously up to you ;-) For reference the easiest map to see where the change matters is the Warpspasm secret map, but I suspect you had to have a test map in mind yourself, otherwise how would you know if it works? Hehe still annoyed about shadows This 2007 build of DarkPlaces has correct shadows https://icculus.org/twilight/darkplaces/files/darkplacesengine20071120.zip Just pointing this out. Obviously, the source is in that Shadows, a pestilence that annoys engine developers ;-) What's annoying is because "lightspot" (or my equivalent of it) is calculated in R_LightPoint, and because that's what used for positioning the shadow, it should just automagically work - no extra code needed.
That tells me that the likelihood is I'm doing something else wrong, but right now damned if I can think of what. It'll come. Thanks for the reminder that I had written a tutorial about the lights. No, I didn't have a map in mind, it was just obviously broken (trying to fit 64 light bits into a 32-bit int isn't going to happen). If you ever get a chance, this block of code has me somewhat confused:
(Water warp area #ifdef DIRECT3D9_WRAPPER #else #endif I know Direct3D uses a different 3D matrix than the "mathematically correct, but somewhat inconvenient and annoying OpenGL 3D matrix especially when you want to do 2D". But none of the other glOrtho calls are treated in that manner? Something I'm not seeing here, I'm sure The other glOrtho calls are set up in a way that they cancel out. This one isn't, because I'm using normalized device coords and identity matrices (those glOrtho calls are really the equivalent of identity with D3D being vertically flipped) so I need to correct for it.
Ummm - did that make sense? Mentioning something, even though it doesn't really matter.
With dx8 Mark V in windowed mode, if someone alt-tabs out of it, I do something sneaky and minimize the window -- to obfuscate the fact that the window must stay on top of all others. May be an unchangeable characteristic of Direct3D. I hadn't thought about this in quite some time. But since DirectFitz 9 doesn't employ a trick like that, for a moment I wasn't quite understanding why it was staying topmost when it lost focus. /This behavior does not much matter, but I'm just pointing it out. Actually my suspicion was correct - that was nonsense. NDC goes -1..1 but I'm going 0..1 for starters. What's relevant here is glCopyTex(Sub)Image copying from bottom-left, but D3D StretchRect copying from top-left.
Unless I am somehow doing something wrong searching the source code, WS_TOPMOST returns 0 results.
Although I know far less about Direct3D, I have always been under the impression that a non-topmost window in D3D is impossible. /Also, this isn't something important. Sweet, new goodies to play with. And I can ruin it all by injecting something to give Quake all those features it was always missing, like hacky SSAO, awful Vignette effects and dumb colour grading.
Honestly though, even though I don't have anything technically useful to say, I feel like both Baker and mh need to be thanked and congratulated for making cool things for Quake like new engines and renderers. So thanks and congratulations for being cool! I'm just not able to reproduce it: http://www.quaketastic.com/files/screen_shots/Topmost_window.png
I suspect something localized on your PC. @baker: any chance that you could post a tutorial to implement md3 support to fitzquake?
I saw you started one at insideqc, but never finished it. It could be my Direct 3D drivers. I notice that DirectQ does the same (minimizes it). So apparently the behavior of Direct3D 9 is subject to some sort of variance, since clearly yours is different (and more likely up-to-date). I may end trying to grab the Window style flags -- is it GetWindowsLong --- and see if I can detect the behavior.
I did end up trying Mark V on a GeForce high-end gaming laptop -- I think the driver version was (372.70). Did not experience flickering, but the driver wasn't (372.75) and didn't have time to do an update.
However, the display was high DPI and Mark V likely needs the DPI awareness attrbrite because even the experience in the WinQuake version was rather "unpleasant" on a high DPI display. d3d9_glcontext.cpp - line 206
if (mode.Format != d3d_Formats[i]); Note trailing semi-colon. Good catch.
I was like, "Uh, that doesn't look like intentional code. MH wouldn't do it like that, I don't think. He'd probably have empty brackets" integration glEnable (GL_STENCIL_TEST) GL_ARB_texture_non_power_of_two not found. Since I think you actually wrote this, I'll probably just improvise. Have some plenty more integration to do, but it's going pretty smoothly ;-) It runs and plays at the DX8 functionality level, but of course that isn't the goal here and I have about 45 instances of slightly different treatment that I did for DX8 which I have to recode/tune/etc. I did change the name of the autosaves to auto_save_0.sav, auto_save_1.sav, auto_save_2.sav (they used to be named a0, a1, a2)
Type: load auto_save_0 Example: Type: load (press ALT+Space Type: load a (press TAB) Let me know if everything is ok. btw -- Better than even chance "shadows on platforms, lifts, etc." will be available as an option to put in worldspawn at some point. At one time you expressed interest in "true lightpoint" and is something being discussed as an mapping opt-in. I made a quick and unknowledgable run at making glEnable for GL_STENCIL_TEST work. But was unsuccessful.
Mirrors work though -- this means that glDepthRange is working quite nicely! (The current implementation of mirrors doesn't need stencil very much. I use glColorMask (0,0,0,0) /*don't write color*/ mostly to do a depth write where the mirror surface lives instead. ) Spirit and a few others (mostly of the engine development variety) may remember this.
Baker's Visual Concept of a Built-In "Quake Injector" Take that and then consider the Undergate and becomes possible to see the vague direction it is ultimately heading. And explains some of Mark V feature set very well. /Note: I actually made something like the Quake Injector before the Quake Injector existed screenshot. Only a few people were interested in it, was harder to get people interested in single player at the time. Plus engine coding was more interesting to me. Was happy when the Quake Injector came out, promoted it quite a bit. OK, I've pretty much fixed all of those items.
I currently don't have a test case for stencil because the stock Fitz code doesn't use it. What I'll probably do is add stencil buffer support to r_shadows 1, because it's quick and easy to do and was in a well-known QuakeSrc.org tutorial too, so it's well-known to the community. Adding the enable/disable for stencil should have been easy and more or less self-explanatory: just follow the pattern of the others, using GL_STENCIL_TEST and D3DRS_STENCILENABLE. There are a number of reasons why this might not work though, including if a pixel format was selected without a stencil buffer. I'll fix all that up and make it nice and robust. Hah, nice screenies there Baker.
It's kind of hard to get a handle on all the Quake content out there and how to use, but at least partially that's a "nice problem to have" sort of situation. The fun thing about MD3 loading is: where do you stop?
You see, MD3 is more than just a model format. Once you have that done, you're going to want textures too. And because content creators always want maximum flexibility, you're going to want the full Q3A shader system. And you're going to want to draw it from vertex arrays because that's the way the format is designed. But by that point you've more-or-less reimplemented the full Q3A renderer in the Quake engine. This is a design goal of engines like DarkPlaces and FTE. It's not a design goal of other engines, and because time isn't an infinite resource, time spent doing this is time not spent doing other stuff. Back when I quit working on DirectQ, part of the reason why I killed the engine was because it was being pulled in too many different directions. The SP guys wanted one set of things, the MP guys another, content replacement people wanted something else, modders, mappers, QC people, low-end people, high-end people - all different and sometimes overlapping but sometimes conflicting requirements. Meantime there was only one of me. You absoluetly do need a laser-sharp focus and you absolutely do need to say "no" and be non-negotiable about it. DirectQ is a cautionary tale of what can happen when you don't. If I had 5 $/€/£/¥ for each time somebody asked me "can you just implement $PET_FEATURE, I'm sure it will only take you 5 minutes and it would be so cool" - I wouldn't need to work for a living and would actually have time to do this kind of stuff! As it stands I don't have that kind of luxury, so I have to cherry-pick what I spend my time doing, and also mix it in with beer/friends/other hobbies/eating/sleeping/entertainment/etc. While the very same specifics may or may not apply to Baker, it should be obvious from his prior posts that he is similarly time-constrained. So, options. If Baker has 1 week between now and June, is it better spent writing an MD3 tutorial or is it better spent doing other Mark V work? That's all working now.
One point to note in Mark V: 32, // 32-bit z-buffer 8, // 8-bit stencil buffer This is actually bumping your hardware requirements to D3D10 or higher class hardware. Hardware typically doesn't actually have separate depth and stencil buffers, but rather a single interleaved depth/stencil buffer. The common options are: * 16-bit depth. * 24-bit depth, 8 bit unused. * 24-bit depth, 4-bit stencil, 4-bit unused. * 24-bit depth, 8-bit stencil. * 32-bit depth. I'm not sure how prevalent 24-depth/4-stencil/4-unused is in the wild, and I think 32-depth had issues on older hardware (I recall some Intels actually giving you 16-bit depth if you requested 32), but the other formats are robust and compatible. So if you require a stencil buffer you should always request an 8-bit stencil buffer and always drop depth bits to 24. Because they're interleaved, you should always try to clear both depth and stencil at the same time too. You'll get a faster clear that way. Anyway, in it's current state the wrapper just sniffs for the presence of stencil bits in the PIXELFORMATDESCRIPTOR and if present it gives you a 24-depth/8-stencil format, irrespective of how many bits of either you request. Otherwise you get 24-depth/8-unused (which I might change to 32-depth sometime). This behaviour may change in future versions to better reflect what you actually ask for, so I don't advise relying on it. I know about the stencil, at least on a subconscious level, switching areas of the engine quite often (IPv6 --> input --> system messages --> etc.) I lose sharpness.
mh: Back when I quit working on DirectQ, part of the reason why I killed the engine was because it was being pulled in too many different directions. I don't want to beat this to death, but you always have to tell someone "no" to "help me with my engine coding" 3 or 4 times because are in above their heads in something. And if you help them, you have created a cycle of dependency, like giving a homeless person some food. They'll be back on your doorstep tomorrow if you help them. I already said explicitly I am not an engine help forum, but I knew I would need to say "no" more times because I have been in that situation dozens of times. Someone who exhibited the capability to truly engine code would be able to take what is in JoeQuake (the MD3 code in that engine is quite easy to understand) and do it themselves. Plus they would not be using CodeBlocks on Windows, they would be using the vastly superior Visual Studio. Anyways /Enough said. Much to do! Plus also, if you don't have Visual Studio that means you never tried to compile JoeQuake which is in Visual Studio.
Therefore, by definition, you aren't trying very hard to begin with. And engine coding is hard as hell and such laziness disqualifies you from having what it takes to engine code. /Ok, I lied a little last post. Enough said. Like this time I really, really mean it. Unless I change my mind. ;-) Much to do Dude --- you've told me
1) My source code was broken. 2) 5-6 instances of "engine coding help" type questions, with 2-3 of "other model format" after a politely, but clearly worded "no". Did you not eventually expect get the "Are you hard of hearing?" version? I sure would have ;-) You probably have a great project, but by all appearances you simply don't have what it takes to do engine coding. Whether or not that is "rude" or fair or even not fair, it just is what it is. It is important for someone in your situation --- the "I'm in over my head situation" --- to get a reality check. As someone who has been the beneficiary of "reality checks" by other engine coders (mh and Spike have given me "reality checks" in the past, especially when I was very new. Bet you didn't know that! They were very helpful reality checks. It wasn't what I wanted to hear, it was what I **needed** to hear) In low-level coding this is someone doing you a favor. Direct X 9 Version | Source Code
If started with -nostencil And no switching between full-screen and windowed mode, and no alt-tab in full-screen mode, should work ok. Doesn't have r_waterwater integrated yet, not shader based gamma/contrast isn't available yet either. More work to be done in the mode changing and ALT-TAB department. ALT-TAB in some instances has issue with gl_oldwater 0, seems to be full-screen mode only). Likely an incomplete implementation on my part, it appears something subtle is missing and I'll have to do a deeper examination to see what it is. DirectFitz9 video mode changing issue
bind y "toggle vid_fullscreen; vid_restart" Switch to the largest resolution available. Then press "y" a couple of times. The window positioning acts up. I remember with the Direct3D 8 wrapper there may be been an issue with windowed resolutions that overlapped with the window taskbar (the bottom of the screen bar showing applications running). With the Direct3D 8 wrapper, I believe that since I completely destroyed the window and everything else upon switching between fullscreen and windowed mode, it wasn't a problem. From all appearances, doesn't look like the Direct3D 9 wrapper supports that. And maybe it shouldn't. (*) Note: I don't know what version or versions of Windows you run, but at one point Windows 8 was rather displeased with changing Window borders and attributes without DestroyWindow even with Open GL. Since DestroyWindow and ReleaseDC and then recreating the window in Open GL, and then reassigning the context (HGLRC) typically works, not much of an inconvenience. I haven't checked Windows 8 SP 1 or Windows 10 to see if Microsoft "fixed" that behavior that Windows 8 introduced in a later update. The "always on top" window issue I experienced works like this:
1) Only if dx9 starts up in fullscreen mode, it seems that Direct3D (not in your code) gives it the topmost attribute. In d3d9_glcontext.cpp, adding this (trivial) statement before Sleep (10) in ResetMode solves the issue: if (windowed) SetWindowPos (this->PresentParams.hDeviceWindow, HWND_NOTOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); The issue is not immediately experienced in DirectFitz 9 because it starts up in windowed mode, then executes config.cfg which contains a vid_restart command. However, switching to fullscreen and then back to windowed mode, the window will exhibit a permanently topmost behavior. Beer for Baker, that's good detective work and useful info for me! Hope to have a new release over the next few days.
I did change the name of the autosaves to auto_save_0.sav, auto_save_1.sav, auto_save_2.sav (they used to be named a0, a1, a2) </a>
ah, see. I used to type load a0 without tab and was suprised when found that file is missing. I have not yet ever experienced the "off by 1 pixel" issue with shader gamma in Mark V.
I wonder why it happens in DirectFitz9. Haven't implemented resize-window-on-the-fly. I'm hoping that the "off by 1 pixel" oddity doesn't surface there either. More to do. Sorry, Pulsar. I should have done a better just communicating the change.
Wanted to make the autosave names more clear and obvious to a newcomer. Are you guys making a DirectX engine that can play Arcane Dimensions, right? My low-end netbook can barely play it on Quakespasm sometimes but with the DX9 engine it stays mostly on 60 fps on the few maps that can support it, most still crash.
That would be a miracle. Direct X 9 Version | Source Code
Requires -nostencil in the command line. Stencil buffer is not yet operational. Does not yet have WinQuake-like r_waterwarp integrated. c:/quake/DirectMark5.exe -nostencil Does have fully resizable window capability. vid_hardwaregamma Set to 0 = shader gamma (looks nicer in windowed mode) Set to 1 = hardware gamma [default] (in high resolutions, can be very much faster than shader gamma) @mh - Some issues exhibited in DirectFitz 9 prototype do not seem to happen in DirectMark5.exe Build 1022. Will do some more testing, but Mark V handles video mode changes differently than FitzQuake and I rewrote small parts of the wrapper. I think the issue list may have gotten smaller, but more testing will tell. /Source code link will probably work in 10-15 minutes. vid_vsync 1 works in windowed mode, but apparently not right away. If I press ALT-ENTER a couple of times, windowed mode doesn't take it.
As a work around for now, I feed it into the command buffer as such Added into end of setmode for now // Vid_SetMode // Window already created or recreated Vid_Vsync (); // Fullscreen fine, windowed mode no effect though #ifdef DIRECT3D9_WRAPPER // ensure swap settings right if (vid.screen.type == MODE_WINDOWED && vid_vsync.value) #endif // DIRECT3D9_WRAPPER Wanted to make the autosave names more clear and obvious to a newcomer.
Any particular reason you inserted an extra underscore in auto_save, then? autosave_0, autosave_1 etc seem more obvious to me since I've always read it as a single word and not two words separated by a space. Or even autosave0, autosave1...: the underscore is more of a programmer thing that isn't intuitively used by n00bz. Plus, the less characters to type the better IMHO. There are some single player releases with autosaves built into them. So I don't want to use a name like "autosave", for instance.
In Mark V, someone who used it any length of time would just type "load a" and press TAB. 1) So no one would be typing more stuff ;-) 2) You just need to remember the "a", you don't need to know the name. Mark V auto-completes even 1) skybox names (!!!) 2) key names 3) demo names 4) save names 5) map names 6) game folders 7) Several other things. Mark V can auto-complete in the middle of line! If you have a long line, you can backspace in the middle of it and press TAB or ALT-SPACE and it won't mess anything up. In fact, Mark V even has undo and re-do! You can press CTRL-Z or CTRL-SHIFT-Z (redo) in the console. That's in addition to being able to hold down shift and select text in the console and copy it or paste it. And in addition to being able to press CTRL+PGDN and CTRL+PGUP to resize the console. Mark V is user-convenience engine ;-) Direct X 9 Version | Source Code
Requires -nostencil in command line, as stencil buffer isn't ironed out. 1) r_waterwarp 2 is WinQuake style waterwarp 2) Resizable window at any time 3) Shader based gamma available (vid_hardwaregamma 0), look nicer in windowed mode. Hardware gamma is faster, especially in high resolutions. 4) The renderer is faster. Startup and Alt-Enter are astonishingly fast. Haven't been able to get a complete handle on the speed increase, but certain highly complex maps seem to render at least twice as fast. @mh - I've taken it about as far I can go ;-) Aside from some outstanding testing situations I've thought of and some polishing up ideas I've charted out. Stuff: 1) stencil 2) non-power of 2 texture sizes 3) Technically, vid_vsync 1 + windowed mode doesn't immediately work at video mode change time, but I did a workaround putting some commands in the command buffer. 4) Without thinking too hard, I do not believe there are any other outstanding issues. I don't have any known mode switching issues ever nor the off by 1 pixel shader gamma issue either. I have the engine use the provided Direct 3D screenshot method when the buffer already has gamma/contrast applied to it (if shader gamma is on, for instance), since it seems to be at least 3 times faster when writing PNG (PNG is a notoriously slow format to write). I have no time for testing with a house full of visiting mini-ogres. And it looks like there's still work to be done before exhaustive testing really begins.
Been sick the past few days so I'm a little behind schedule, but all of the items mentioned by Baker above are now fixed. I haven't yet integrated the changes Baker made to the wrapper.
There's some weird interactions I want to shake out between video startup, mode switching and window resizing, but if it takes me too long I'll just do another upload of the current version with window resizing flagged as "potentially unstable". Current vsync behaviour is a bug in my code.
What's happening is that the vsync setting is not holding across a device reset. Now, sometimes (e.g. if creating a new context or doing anything else which reverts all state back to defaults) that's the behaviour you want, but other times (mode change, alt tab, etc) it's not. The quick and dirty fix is to find the line "this->PresentParams.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;" in context_t::SetupPresentParams, remove it from there and put it into context_t::context_t *above* the call to this->SetupPresentParams instead. That should be enough to get you going and you can remove your workaround. :) A bit more about the flickering:
I played through DOPA using mark_v_winquake.exe and didn't notice any flickering. I switched over to using mark_v.exe for playing ad_mire, and I noticed flickering pretty regularly (played up to the point of turning the first valve). Switched to quakespasm_sdl2.exe and played through the same part of the map, no flickering. I'm using a GTX 1070 with latest drivers. Let me know if you ever want some additional system info, or for me to try anything out. A couple of things about autosaves:
- I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional? - The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves. It looks like the autosave names are not recognized, at least for autocomplete purposes, until you after do a manual savegame. http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2016-12-30.zip
You'll need to do a diff with the original wrapper engine code for this too, because there are some subtle changes required engine-side relating to Alt-Tab handling. I dropped your "ResizeWindow" and rewrote "ResetMode" to handle switching from Windowed to Windowed without other changes. There's a changelog included so you can see what's different/fixed/broken/etc since the last release. Cool! I'm kind of sporadic during the holidays.
Look forward to checking out the code! @johhny I noticed they don't show up in the load-a-saved-game GUI menu. Is this intentional? Yes, at least for now. FrightNight and I didn't like non-user based save games in the menu. Doesn't mean that is a "final answer" or that couldn't change, but unwanted "randomish" save games in the menu seemed wrong. The first time you play in a particular gamedir, "load a" will not autocomplete any autosave names even if enough time has elapsed to create one or more autosaves. I'm rather certain that is perception only. While I haven't checked, one thing I do know is that any save game forces an autocomplete update. The first save has a bit of different interval because who really cares about a save game when you've played less than 2 minutes, if you see my point. An autosave is a "Help! I forgot to save and played for 45 minutes!" feature as a safety net for the player. The "I died 100 seconds into the map" isn't really what autosave is there for, you know ;-) Also, you have hit on a fine-tuning weakness.
I usually start coding something "too conservatively" and then gravitate it towards what the user would expect. Which is fine and the right way to do things. You make it work efficiently first, then you relax it to conform to user expectations and figure out how it fits into the user interface correctly. It is ok for something to be over-efficient at first, but not user-tuned. If something is written over-efficiently, that is the right kind of problem to have as a starting-point. Give it a try. :-)
The issue is that Lists_Update_Savelist is only invoked on new game or on manual save (in Host_Savegame_f). That being said,
void Host_Savegame_f (lparse_t *line) { Lists_Update_Savelist (); <--- } It don't think I'm wrong about this, but even if I happen to be right (at a quick glance looks to be the case) don't stop telling me about things you think I overlooked. But actually you are right. That is the user-initiated pathway. The auto-save mechanism never hits there.
+1 I ported Q3A's r_shadows 2 mode to DirectFitz.
http://www.quaketastic.com/files/screen_shots/ShadowsThatSuckSlightlyLess.jpg I guess not many people are aware of this mode (I'm certainly not aware of any well-known Q1 source ports that use it), but it uses a simplified variant on stencil shadow volumes to resolve many of the major annoyances of classic Quake's r_shadows. Just to manage expectations a little, it's not real-time lighting, it doesn't give you arbitrary shadows from any number of lights, it doesn't fix dynamic light shine-through; what it does do is fix cases where classic Quake r_shadows 1 breaks down, such as on steps, at edges, on angled surfaces, etc. I was aware of this mode in Q3A, but I couldn't enable it on my latest system.
Am I seeing self-shadowing on the shot? I think I would prefer just a kind of simple blob shadow under the monster ala turok or something like you see in severance
I implemented Rich's shadow tut years ago in Qrack,(the un-interpolated version) and works fine enough, yet it's BASIC openGL v1.1; no vertex arrays. Combined with applying an alpha value based on how bright the surrounding light brightness can make it look someone real, hard-edge yet conforms to stairs/walls/slopes.
I'll have to look at Q3A's method for a quick and dirty CPU-driven shadows vs the stock shadows in Quake. The pic you posted above imho is what Quake should have had from day one. It just makes the scene more immersive :)! The Q3A shadow code doesn't use vertex arrays, but just to correct a misconception: vertex arrays are also basic GL 1.1.
Some of us like to refer to documentation. Let me guess... it's built in? Well how and I to know that? 8-P
Next version will have a worldspawn option to increase sound distance. As an experiment to see if it is useful. Mostly because of issue you mentioned about sound cut-off being undesirable for what you are working on.
re:readme - this thread mostly serves that purpose for now. The "find" command in the engine is also helpful (like type "find sky" in the console ). This is more of an interactive project with those that want to participate and help test and refine and such. @rook - Yeah, I quite like what MH did with the shadows and your "what Quake should have had from day one" is what I think about that awesomeness. ;-)
--- mh - regarding window borders. aguirRe back quite a while ago now, made a "fullscreen windowed mode" and every engine I worked on since emulated that behavior. If the window size is the desktop size, no borders. So that is one reason why I wanted the engine to say what the borders should be. Also want to preserve resizable borders as an option (the D3D wrapper may end up encasing the software renderer in an optional build that uses a texture as the frame buffer, which I don't feel like implementing resize for the software renderer right now since is moderate hassle) or keep the option of no borders as a possibility even in windowed mode (because some external video capture tools capture window borders). So that's what is up with that and my comment in the code. If that seems reasonable. 1) Noticed Requiem engine (by jdhack, I've referred to it as "Spirit's engine", and johhny law as I understand it has put some work into it too) --- uses "force char as unsigned char" option during compilation. Tried that option with Mark V, about 5 fields of code inherited elsewhere had to be changed from char to int.
Any proper C code is going to treat char as both signed and unsigned simultaneously (C specification allows both as valid treatment) but when debugging I don't want to see -40 or -128 or even -1 as a value for a char field. Slows down debugging to have to think ;-) 2) Newlines in Con_Print, etc. I view newlines and quotes in a printf as a source of fragility and an ease-of-reading nuisance. And as an example, Google's Android platform debug logging expressly thinks in terms of fully-formed lines and you don't supply the newline. I used a tool to "robotically" identify and replace Con_Printf to Con_PrintLinef where applicable and then examined what remained. Most of the Con_Printf without a newline at the end, it was unintentional, as I suspected. Anyway, in the next version, that behavior has largely been expunged in the entire engine barring obvious circumstances that must persist like QuakeC or messages from the server or the reverse. Makes code easier to read and more maintainable. 3) Speaking of Con_Printf Con_Printf has always been borderline undesirable, especially with vsync because it causes an immediate rendering of a frame --- but since using vid_vsync will pause engine operations until it is time to render a frame, can be quite undesirable. In some circumstances you do want immediate feedback. Like "Connecting But most of the time, you simply do not want Con_Printf at all. It the opposite of an optimization. In unreleased Mark V (grabbed Windows DPI awareness from Quakespasm) tested on GeForce with driver version 373.19
No flickering. Driver version 373.19 = ok And didn't see flickering for 372.70 in previous test = looked ok Will see what results are after next Mark V update. Next version will have a worldspawn option to increase sound distance. As an experiment to see if it is useful. Mostly because of issue you mentioned about sound cut-off being undesirable for what you are working on. That's great news. I had the same issue in my Retrojam map as well. A very large chamber and the doors and plats were silent. In reality you'd hear the sounds echoing from a distance.
I think adding dev tools like your inspector are a great help. A suggestion: Can the console text be resized separately from the in- game text? I usually have in-game text at a legible size but that limits how much you can display in the console. Just an inquiry. @dumptruck_ds I'm pretty sure this is possible, in Qrack I have the realtime ability to resize the console text using ctrl+mwheelup/down which doesnt affect the mesagemode text size.
@dumptruck_ds I'm pretty sure this is possible, in Qrack I have the realtime ability to resize the console text using ctrl+mwheelup/down which doesnt affect the mesagemode text size.
haha what's Qrack? I downloaded but there's no readme????? Website is pretty minimal. Well I guess I could just try it. :)
I do understand where you're coming from, but...
There are architectural and internal differences between GL and D3D, and how they interact with the windowing system. This is compounded by WDDM on Windows Vista or higher. GL doesn't specify any interaction with the windowing system. You use GDI and native API calls, you have full control over everything, but also full responsibility to do everything yourself. D3D has tighter integration and interaction with the windowing system is defined as part of the API. For example, you don't use ChangeDisplaySettings and a window resize to set a full screen mode; instead you specify a backbuffer size then Reset the device, and D3D will do this automatically for you. That's why there are other differences too, such as the changes I've made to AppActivate. I don't make those changes for the jollies, or for some idealistic crusade for cleaner or nicer code. I make them because they're required. Full screen is different between GL and D3D. D3D has a concept of a cooperative level, which is how (and if) your program cooperates with others. Windowed modes have non-exclusive ownership of the graphics hardware, meaning that other programs that also have non-exclusive ownership can run and use the hardware. Full screen modes have exclusive ownership, only one of those can use the hardware, and no non-exclusive programs can use it. (That's why lost devices happen - something else starts using the hardware that blocks your program's access to it). GL has absolutely none of this. If a full screen mode has any meaning in GL then the driver is going to have to apply heuristics to detect it, perhaps by sniffing at the window styles or by comparing the window size to the display mode. What you think is a full screen windowed mode might actually be being converted to a proper full screen mode by the driver (another reason why it might seem to work in GL). That's all background intended to help you understand that you just can't always do a 1:1 mapping between behaviours and that API differences go deeper than just syntax. Differences are architectural, and D3D is a whole driver model as well as just an API. Regarding borders and full screen windowed modes - I tried it and it didn't work. I actually spent about 2 weeks at it over a year ago, and 2 weeks spent toggling between modes, setting breakpoints, printing out window and backbuffer sizes, then change something and try again, is enough for anyone. The most common problem was that Windows wouldn't let the program window cover the taskbar. I don't have a direct link for this, but I believe that this is a deliberate change in newer versions. Coming right up behind it was that the backbuffer was sized differently to the window client rect. This could be really subtle, but it was enough to cause the driver to need to do a stretch blit instead of just a buffer swap, and performance fell off a cliff. Other problems included window positioning, not actually going full screen windowed at all, and issues around Aero styling when toggling modes. In other words, when I say "I tried it and it didn't work" I'm quite satisfied that I did make a comprehensive enough attempt, and when I say "don't do this" I do expect you to believe that there are reasons for it. I'm not saying "don't do this" because I'm too lazy or don't want to make the required code changes, I'm saying "don't do this" because you really shouldn't. Got it. It's all good ;-)
I know D3D is wired differently and I've read your comments. I was trying to express why I even would even want to do such a thing. I'm rather good at working within boundaries ;-) I rather cleverly worked within the limits of the DX8 wrapper and I can do that here too. No worries! Aero styles is one of those things that every time I do this it messes up in some way, so I spend a few days "poking it with a stick to see if it moves", until eventually I get there.
I should have probably added - none of this is that way that real cross-platform/cross-API games are written. What we're doing is taking code written around the way GL works/the requirements of GL, then mangling it to work with D3D. A real cross-API game isn't written like that at all. Instead it would have "SetModeGL", "SetModeD3D" and use the correct native code in each. Much of this is from the perspective of pre-empting queries along the lines of "but game X does it so I don't understand why you can't". its at times like this that I apprechiate vulkan's WSI (windowing system integration).
its a bit like gl (in that its simply attached to the client part of a window), except with explicit swapchains like d3d (but cleaner and less annoying. its just much more sane than either. fte now uses the same gl_vidnt.c file for both gl and vulkan. one renderer creates a wgl context attached to the window, the other a wsi surface. which is much nicer than having d3d doing random poorly-documented things to your window thereby breaking things. vulkan's backbuffer is actually an image just like any other, which means you can blit true-colour software-rendered images to the backbuffer using only simple buffer copies, no glsl required. unfortunately the queues and stuff are kinda annoying. when everything uses compositors anyway, there's not really any difference between the backbuffer and a texture nowadays - render-to-texture for all! I assume d3d12 is similar, but I've never really looked at that. From what I've seen of D3D12 it's much the same DXGI interfaces as D3D11, so you've got the same swapchains, texture with rendertarget view, and arseways crap of running in one of two modes: "we control everything and nothing works the way you actually want it to" or "we control nothing and you have full responsibility for all of the pain and suffering" - neither of which are the way you'd actually like it to run.
My idea of doing a chdir to id1, forcing the opengl32.dll to load, then chdir back failed.
Had to revert to Spike's LoadLibrary/GetProcAddress suggestion. Wasn't a big deal, since Mark V is already setup to rewire rendering functions (OpenGL vs. Direct X 9, etc.) A call to getenv("COMSPEC") /* should be highly retrocompatible*/ obtains the system directory where the correct opengl32.dll should live. If it doesn't find the It also prints a few lines of bronzed text complaining. Why does this matter? Because GOG.com --- the DRM-free game buying site --- distributes GLQuake complete with a toxic OpenGL32.dll provided. qboolean CheckOpengl32(void)
{ FILE *f; char ogname[1024]; Q_snprintfz (ogname, sizeof(ogname), "%s\\opengl32.dll", com_basedir); if ((f = fopen(ogname, "rb"))) { fclose (f); return true; } return false; } /* =================== VID_Init =================== */ void VID_Init(unsigned char *palette) { int i, existingmode; int basenummodes, width, height, bpp, refreshrate, findbpp, done; HDC hdc; HGLRC baseRC; DEVMODE devmode; extern void VID_Menu_CalcConTextSize (float cw, float w); if (CheckOpengl32() == true) Sys_Error ("Please delete the opengl32.dll from the Quake folder."); I've had one that similar to that in ProQuake for ages.
I wanted one that doesn't require any user action at all and simply ignores it, haha ;-) Mission Accomplished. Qrack is an old engine based on joequake
It requires at a minimum using /DELAYLOAD:opengl32.dll in visual studio
Or I guess simply not linking to the opengl32.dll at all is also an option. nice, "**warning Mark V detected an evil troll, killed it with the glowing sword, you may proceed.."
"The Troll Room This is a small room with passages to the east and south and a forbidding hole leading west. Bloodstains and deep scratches (perhaps made by an axe) mar the walls. A nasty-looking troll, brandishing a bloody axe, blocks all passages out of the room. Your sword has begun to glow very brightly. The troll swings his azxe, but it misses. >swing sword Whoosh! The troll swings, you parry, but the force of his blow knocks your sword away. >get sword Taken. The troll hits you with a glancing blow, and you are momentarily stunned. >kill troll with sword The troll is staggered, and drops to his knees. The troll slowly regains his feet." I've always wanted to make a QuakeC console version of some kinda Zork clone hehe to play while wiating for a multiplayer game to start. ;)
A fair number of the Arcane Dimensions maps are BSP2.
Spike added BSP2 in this patch: http://triptohell.info/moodles/junk/markv_bsp2.zip I'm sure I've posted you a link the above before. BSP2 is way easier than protocol 666. There is also the Quakespasm acquisition of that BSP2 patch at https://sourceforge.net/p/quakespasm/patches/11/ which has a diff file. I do have a working version with bsp2 support but somehow it broke my normal quake skys. Sky boxes work fine. Spike made suggestions yet i havent had any time to fix :S
In 24 hours or less, some fun stuff to play with
* A very nice Direct X 9 build, with mirror support. * Ubuntu Linux Open GL build * Ubuntu Linux WinQuake build * GL builds have MH WinQuake-style water warp. Default setting. Setting r_waterwarp 2 will get the FitzQuake look. * Windows WinQuake through Open GL for KillPixel. I also happened to need to make this for Linux purposes. * GeForce/Nvidia issues and DPI annoyances should be gone. This feature is somehow a super-perfect fit with Quake. You don't quite realize it is missing until you have it available, and then not having it feels wrong. * A rather extensive changelog, but I couldn't say for sure what is in it. * I do know it has a worldspawn option for dumptruck_ds to set the sound distance. * WinQuake version now also has resizable window in real-time like the Open GL and Direct X 9 versions. * Mac mouse acceleration fix (The "SleepWalkr" fix, as I think of it). * IPv6 tune-up on non-Windows platforms giving it all the nice features available in the Windows version. Linux versions have about 99.5% of the Windows feature set, with the main omission from my perspective being video capture -- which the Requiem engine has and I haven't had time to get "X Windows"-ish with the code base. Oddly enough, the Linux build requires SDL 2.0.5 Many people think that any engine using SDL needs to have external dlls. It's not true. Just for fun, I'll throw in a Windows SDL build that requires no DLLs. To keep things relevant, I guess I'll make this SDL build a WinQuake Through Open GL SDL build for Windows. @fifth/@kp -- Trying to fill my mana bar for final gauntlet.
I actually have a list of 24 separate individual items on a sheet of paper to apply what I hope is the right level of polish to this. Engine coding is all about the small ball. Testing 4 or 5 Windows builds (GL, DX9, DX8, WinQuake, WinQuake via GL), 2 Mac builds, 2 Linux builds, making sure the Debug and Release builds are right and then in Windows making sure it works in Visual Studio and CodeBlocks is a hassle. But if all goes well /Sometimes I ask myself "Ok what is the reason to do all of this again?" Usually the answer is "Because it is there." Or something, haha ;-) No seriously, should be quite worth it. ;-) Mark V - Version 1.25 Beta
http://quakeone.com/markv/older/1025_mark_v_beta.zip http://quakeone.com/markv/media/ubuntu_linux.png http://quakeone.com/markv/media/ubuntu_linux_winquake.png Ubuntu Linux Open GL Ubuntu Linux WinQuake (software renderer) (* Requires SDL 2.0.4, only tested with Ubuntu Linux 16.04 LTS.) Direct X 9 Renderer Direct X 8 Renderer Windows Open GL Windows WinQuake (killpixel, it may work good 4 you now) Windows WinQuake via GL (killpixel, if above doesn't this one should in theory be a sure thing) RARE: Windows SDL 2.0.4 Open GL build (***) (*** Does NOT require ANY DLLS - just to demonstrate that Windows engine builds using SDL2 need not have external DLLs). @fifth - "He needs to add 4 player splitscreen coop yet" --- Yeah, exactly! Hahaha. MH Waterwarp All the Open GL and Direct 3D builds have MH WinQuake Waterwarp (except DX8) and it defaults on. r_waterwarp 2 is classic FitzQuake waterwarp in those engines. (Mac version is resisting me at the moment. I'll upload source codez after the Mac version is owned.) Using openSUSE 42.1 linux here.
Will try compiling for my distro. when source code is available. Will there be a MAKE file? Maybe a configuration file? I haven't spent that much time in the non-gl version to say for sure, but the stuttering seems to be gone as well. How'd you do it?
minor bug in WinGL: the prompt isn't visible after selecting new game (reminder, a game has to be in session to get this prompt). nice work, baker. this is definitely my go-to engine. I'll have more time to test it out in the coming days. *eyeballs last few mapjams* So many versions to choose from!
This will rightfully become the standard Quake client for everyone.... Well, the DX9 version no longer makes my fog look worse when gl_overbright 1 is set. vid_hardwaregamma 0 behaves differently in DX9. When using it, the gamma slider still works, and it does not affect my desktop gamma (just the Quake window gamma). That's nice. But txgamma does not work, so I'm getting gamma-adjusted polyblends again (which makes them too intense). In DX9, changing to a 800x600 window causes the Quake window to... vanish completely (netbook res = 1024x600). If I start up having previously set to 800x600 window, it works but tells me I'm actually in a 800x578 window. The window looks the same as with the DX8 version when I tell it to use an 800x600 window. It seems the SDL version doesn't play the MP3s. So right now, it's Baker vs. 24 pack of beer. Which is fine, I usually win that war by attrition.
Case in point, it is now Baker vs. 14 beers. ;-) The beer is clearly losing, haha. Anyway on to important things A) @Damage. Rotation. The next burst of energy I get and that goes down in flames. I have some planning on paper, other gremlins have kept me at bay. For now. B) @JimBob. I don't have a makefile plan at the moment but have invested some time in trying to figure out to integrate that into my workflow (depending on what someone defines as as a platform I do 7 to 10 of them). But yeah, I'm actually quite the Linux n00b. So no answers at the moment --- only questions. I do have some experience with Linux, but it isn't very deep. And I'm the kind of guy who understands that growth comes from awareness of ones own limitations -- but yeah, although Linux isn't new ground for me, I do not claim expertise. C) killpixel - thanks for the feedback and please provide more as I continue. What frame rate do you get in the normal build? d) Gunter - this tells me that MH's Direct3D9 gamma shader doesn't work on your computer -- but also I have not fully had the chance to integrate all of MH's recent work. Maybe next build some of the other things will work. Thanks for the feedback identifying that the gamma shader doesn't work on your hardware. Wait. Are you saying the DX9 gamma does work or doesn't work?
With the DX9 build, the DX9 shader supercedes "txgamma". /Anyway, tonight its Baker vs. 24 pack of beer and now its down to a mere 12 (good job Baker!) --- but yeah, I think my next post is tomrrow, hahah. GG! http://i.imgur.com/1oq2pya.png
Same with mark_v.exe. Old (stable) mark_v.exe works, and the SDL version works. I should probably mention that my video driver is from 2009, because using anything newer means using a generic driver, and that would likely break something (laptops are painful). The gamma shader is conservative in that if it doesn't load nothing else will fail, and it reports back to the engine so that a fallback can be implemented.
That said, I understand from the comment that "the gamma slider still works, and it does not affect my desktop gamma" that it actually is working. There's nothing in the gamma shader that prevents texture gamma from also working. We discussed the 800x600 window before, and at your desktop resolution this is just something that you have to accept is going to happen. I've reproduced this behaviour at 1366x768, 1440x900 and 1920x1080. In every case you get weird behaviour if you set height of a windowed mode the same as desktop height. THIS IS NOT SOMETHING WE HAVE SOFTWARE CONTROL OVER. Sorry for shouting but I've already written a number of lengthy posts about D3D vs GL differences, driver and runtime behaviours, and the message isn't getting through. Reporting the same bug over and over again won't make it any different. If the driver or runtime takes control and imposes it's own behaviour, you're stuck. D3D is not GL. You can try to fight it and create a bigger mess. Or you can accept it, say "well just don't do that then", and move on. OMG... proper water warp effect in the GL builds at long last! I can die in peace now! This year starts really well. Amazing job, Baker (and probably mh, I guess)!
Alright, I wouldn't be able to code in this state but Quake and indeed FitzQuakeism (metlslime's code was the Rosetta stone of modern Quake) flows through my blood just by nature so
a) @dwere -- kinda of weird since my Windows 7 machine is in perma-stasis lock since 2012. I'm not a Microsoft trusting sort and my primarily machine has not been updated in any way since April 2012. So I'll meditate on this more tomorrow. In fact, I'm rather annoyed at the moment ;-) b) @MH - Your work is nearly perfect like usual. Meanwhile, I'm still made out of a human. I did the currently release without 8 of my "must have" list -- just because I hit my human limits and needed to have something to show for my integration efforts Knowing I can sneak in a 1.26 tomrrow with few people being the wiser. ;-) So enjoy! Your work is eventually completely safe with me, especially since it is awesome! ... the next version will be: Mark V - SPIKED
with beerzzz :-P Comes with a free sax pick on download! Quick question - is there a hard limit to the number of surfaces WinQuake/WinQuakeGL will display? I tried raising r_maxedges, r_maxsurfs, but it seems after a point it makes no difference (try jam6_ericwtronyn hehe)
But yes very very nice so far! What frame rate do you get in the normal build
In both win and wingl: 320x240 stretch - ~1k 640x480 stretch - 400 - 600 minor bug: setting fullscreen/res via options menu sets to 640x480 stretch. @Baker I was surprised to find that mark_v.exe (Windows GL) runs remarkably well under WINE, so I'll just use that in the meantime.
I don't have in-depth knowledge of Linux either, though I too have used it before. Fortunately these days I think most anyone can figure out most of the user-side stuff by googling. Anyhow, thanks for all your efforts to bring Mark V to Linux! Not certain if this is confined to my PC or not.
On first run, MarkV fails to exec my config.cfg. On exit however it successfully saves and overwrites it, then subsequent runs work. This is a pretty standard "generated by Quake" config and works fine with other engines. I can provide a pastebin if necessary, but I don't think it's relevant because... What I've also observed is that on such a failed run it will create a new directory, at the same level as ID1, but named with a random character (e.g. "Î", "a", etc) within which there is *another* ID1, that containing a config.cfg. default.cfg runs OK indicating that it's loading quake.rc and default.cfg fine from the PAK files. autoexec.cfg and all other PAK file content loads OK, and screenshots/etc are created in the correct folder: i.e. it's solely confined to config.cfg. This is on Windows 10 64-bit, fully patched. The only thing unusual I do is that I have a separate directory for each engine and I use mklink to create hard links/directory junctions for the PAK files and Music directory. To try and be clear, in DX9 with vid_hardwaregamma 1, the gamma slider affects everything -- both Quake and my desktop.
With vid_hardwaregamma 0, the gamma slider only affects Quake, and not my desktop. But txgamma does nothing. It doesn't even return a value. I'm preferring to use txgamma, since it does not affect the polyblends, and so makes them look correct instead of gamma-adjusting them, which makes them too intense. About the 800x600 window, it may be related, but it's not the same bug I've ever reported before. The Quake window just completely becomes invisible. I can hear it, but I don't see anything. If I can mange to change the window size back to something else, the window re-appears. And again, if I restart Quake after having previously set to 800x600, then I get an 800x578 window, which is fine, and apparently what DX8 does automatically without turning my window invisible. Though vid_height still reports 600 in both exes -- it's only in the Options menu where DX9 (not DX8, which shows 800x600) reports my resolution at 800x578. So the main point is: on my 1024x600 netbook, using the menu to set DX8 to 800x600 window works fine, whereas trying to set 800x600 in DX9 via the menu causes Quake to become completely invisible -- no visible window at all, though it still is running, and shown in the task bar. But if there's nothing that can be done about it, then there's nothing that can be done about it.... I also get a similar glitch if I try to alt-tab away from a full-screen mode in DX9. When I try to go back to Quake, I get invisible Quake with no way to bring it back without restarting it. If I try to change the resolution without restarting it (by sound) it freezes up (it gets stuck repeating a menu sound). @kp - In the WinQuake through GL build, I capped the stretch because I was having frame rate issues at certain larger sizes, which apparently is a total non-issue in your case it would seem.
@kinn - I have to check that out. Haven't thought about it in a while. Seems you have found a map that challenges that limit. I'll investigate at some point. @dwere - I'll have to take another look at that. I did change Mark V to bypass an openg32.dll living in the Quake folder --- do you normally need an opengl32.dll in your Quake folder? @damage - Winter + cold and a bit of elation of wrapping up a very complex set of builds sometimes leads to ideas that the next day don't look quite as smart, haha. Anyways --- I haven't forgotten about rotation. @gunter - Like MH said, nothing about the Direct3D relates to texture gamma at all -- so DX9 doesn't have texture gamma at all because 3 different gamma systems in the same build would have been a headache for me. I could have coded texture gamma in Direct X 9 build.
I didn't because of the complexity of having to figure out how to make 3 different gamma systems interoperate. I wanted to get a build out. texture gamma will likely be available in a future DX9 build when I have more time to plan it out. It is important to note that the Direct X 9 build is not "final".
I have outstanding improvements from MH that I have yet to integrate. I marked this build "Beta" -- suspecting there would be some things that need ironed out. The bad config.cfg is coming from %appdata%\MarkV\caches; every other cfg file runs from com_gamedir but for some reason config.cfg is running from there.
Is the pure WinQuake build performing nice enough that the WinQuake through GL build is basically not needed?
/It'd always be available as an option, besides it can do one thing that the pure WinQuake build can't --- it can do vid_vsync ;-) This block of code in Cmd_Exec_f is where it's happening (based off 1023 source, 1025 seems to have no source release & may be different):
if (String_Does_Match_Caseless (line->args[1], CONFIG_CFG)) { const char *check_string = va("// %s", ENGINE_FAMILY_NAME); cbool is_our = String_Does_Start_With (file_text, check_string); //int len = strlen(check_string); // cbool is_ok = false; // Baker: Make sure it is a Mark V config if (!is_our) So my reading is that Mark V is attempting to detect if the config was created by itself (using the presence of a comment at the start as an indicator) and refusing to exec it if not. I can't get it working with any version of Mark_V. Seems to work fine with Quakespasm, not sure what seems to be causing it. I'm sure this was fixed at one point.
@fifth - you're probably using ogg, try mp3.
@baker - winquake seems to run great. the stuttering issue from before is gone. however, there may be a brief "hang" that seldom happens that I didn't detect in the wingl build. Don't hold me to this, I haven't found time to sit down and really test them. @mh - Yes, exactly. Mark V writes a backup config to prevent a loss of settings.
I need to revisit it and double-check everything there and combined with what Johhny Law identified as a scenario --- give it a thorough look over. Source code http://quakeone.com/markv/older/1025_mark_v_beta_source.rar re Linux: I use CodeBlocks with SDL 2 Dev 2.0.4 package installed to compile. /It is possible that at some future date, a Linux makefile may become available if I can determine a way to automatically have CodeBlocks generate it via a plug-in. OK, so I played around a little more with windowed modes in the DX9 wrapper; this is my own development version which is a coupla steps ahead of what Baker currently has.
First thing to check was window resizing. Is it possible to resize a DX9 windowed mode to something equal to or larger than the display resolution? The method used to test this was to drag the window down so that it is partially offscreen, then attempt to resize via the top border. Answer is "no": either the driver, the DirectX runtime or the OS are intervening and clamping the window size. I cross-checked this with MarkV GL and I get the same behaviour there. I then cross-checked with MarkV software and confirm the same there too. I then checked a Notepad.exe window and got the same there too. My conclusion is that clamping the size of windowed modes is totally outside of the control of the application; most likely the OS is enforcing that. On a 1920x1080 monitor, I attempted to start with heights ranging from 1000 to 1080. From -height 1054 onwards I got a grey screen instead of the standard window with the game running in it. On this PC the taskbar is 40 pixels high, so I think we can rule that out. So within 36 or fewer pixels of the destop vertical resolution, you cannot run a windowed mode. I used AdjustWindowRect and determined that with a client rect height of 1053, top was -31 and bottom was 1061. I cross-checked with some other D3D9 code I had, which contains debug assertions that verify the window client rect is the same size as the requested mode. In this code the client rect is clamped to 1053. I removed the assertions and did further testing which determined that Direct3D was indeed setting the backbuffer size to the requested mode, but was clamping the window client rect. I cross-checked with some D3D11 code I have and determined that the client rect was likewise being clamped to 1053. Finally I tested some OpenGL code and determined that the same clamping behaviour existed, but in that case to 1063. For the sake of completeness I attempted running with height 1080 and 1090, both of which clamped to 1063. Finally I wrote a skeleton Windows program (just WinMain and WndProc), created it's window at 1080 height, and observed it being clamped to 1041. It's notable that there were differences between the window styles of all of these programs - I could repeat the tests using the same styles but I don't feel too inclined to, because the data I have is sufficient. However, and just to be absolutely complete, I modified the last program to use WS_POPUP where the window height was not clamped, but was occluded by the task bar. So there you have it. I can spend more time testing other combinations, different Direct3D versions, other OpenGL programs, but I honestly think that at this stage it's not a productive use of my time - I'd be better off watching Japanese porn. Final conclusions. Above certain values the OS *will* clamp the size of a window, unless you use specific window styles, but even in that case it *will* be occluded by the task bar. So to repeat: don't do it; just don't. don't you have a virtual drive installed? it used to be the cause of the si,inlar problem with mp3 playback in mark v
Maybe a naming issue? e.g. track_002 as opposed to track_02.
I had an issue with music too that ended up being something simple that I overlooked, can't remember what it was though. I just have C: and D: drives (both SSD's, quake is on D:) E: is my blu-ray and F: is my removal mechanical.
I use
User setups at error here? If you haven't already, check out the music section of the readme and see if you can spot a discrepancy between what you're doing and what it says. Music works for me. Strange :/
"My conclusion is that clamping the size of windowed modes is totally outside of the control of the application; most likely the OS is enforcing that."
The clamping is fine. I don't really mind if I tell it to set Quake to an 800x600 window and I actually get an 800x578 window. Close enough. Also, I found that if I set -width 800 -height 600 in the command line, I don't get the strange behavior. I just get the nice, clamped window as usual. The problem I am seeing is actually a bit more interesting than I thought.... My Quake window isn't being made invisible -- it's being moved WAYYYYY off screen! I downloaded this tool so I can keep track of my window position: http://www.catch22.net/software/winspy-17 (Chrome throws a fit over that file and won't let you download it... but it's legit. I'm sure there are other tools to do this as well). So I run DX9 Mark V and select its window to keep track of in WinSpy++ (though it doesn't track the position in real time -- you have to hit F5 on WinSpy++ to get an updated window position after moving it). No problems so far. I can move the window around and refresh WinSpy++ and it will tell me the position of the DX9 Mark V window. Now I go into the Quake Options menu and change the resolution to 800x600 windowed... and Then I can right-click on the DX9 Mark V indicator in my windows taskbar and select "Move" then tap an arrow key to grab it, then move the mouse up, and pull it right back onto my usable screen area... (it jumps to the mouse cursor position). So that's weird, right? Let me test to see if this is what's happening when I alt-tab from a fullscreen mode.... Wow! Even better, when I do that, Quake gets sent to limbo at -32000,-32000 And I can't seem to make it come back.... Though it may be a bit different, because I can't refresh my WinSpy++ when the fullscreen Quake has focus... way off in limbo where I can't see it, I assume. What is the specific reason that people want to have the game run in a window that's the same effective size as the desktop resolution? I feel like I must have missed a post explaining the need for it.
In any case, I don't personally know much about it, but many games support a "borderless window" mode that is almsot indistinguishable from fullscreen, but is techincally a windowed application. Would that be an acceptable solution, assuming it can be implemented? Some people like to play and get steam messages or popups etc without having to alt-tab. I guess.
A screenshot is worth a thousand words:
http://imgur.com/a/URhKC My netbook screen res is 1024 x 600. I either run Quake fullscreen at 1024 x 600 resolution, or (as the screenshot shows) in an 800 x 600 window (which gets clamped to 800 x 578) when I want to be able to switch away from Quake easily so I can look at other things like QView or Func_Msgboard or when I need to make notes in notepad about bugs I encounter, or any other kind of multi-tasking where I can see both Quake and something else at the same time. Is there a guide to compiling this with Code::Blocks ? I'm not a developer, and I've only dabbled through the years. I've successfully compiled maybe 4 different engines before, but only via make files.
So far I've installed CodeBlocks 16.01 on openSUSE 42.1. I assume SDL 2.0.5 library is okay. Or does it specifically have to be 2.0.4? And what compiler should I choose? It gave me options on first-run, but I only had GCC available. Not even 100% sure what project to load. borderless fullscreen means alt+tab is quicker as it doesn't necessitate a video mode change, so textures don't get purged by the os, etc, and yes, its less hostile to other programs too as it doesn't result in the registry saying one resolution and yet currently displaying another.
there's also less risk of windows randomly moving desktop icons around... big negatives sounds like its using an unsigned negation, eg: ypos = ((unsigned)screenheight-desiredwindowheight)/2; side note: with d3d, make sure that your d3d backbuffer actually matches the size of your client area. if it doesn't then d3d will be a little more expensive whereas opengl will just resize the backbuffer for you. this also makes handling WM_SIZE much more annoying in d3d. mark.cbp is the CodeBlocks Project File.
You open it in CodeBlocks then 1) Click "Build", "Select Target" ->"Linux SDL GL Release" screenshot 2) Click "Build" -> "Build" to compile. screenshot 3) Then it compiles and you get to read about 12 warnings that don't apply and get to see about 100 developer comments of mine. Requires SDL2 2.0.4 Dev (or later) installed to compile. To run the engine, you'd need SDL2 2.0.4 (or later) installed. I hope it works for you. But I have no idea if it will work for you on a different distribution. I also don't know what version of GCC I used. I used whatever version was already there after I installed CodeBlocks, which I installed out of the Ubuntu Software Center screenshot, which of course is Ubuntu thing. I hope that helps! mark_v.cbp is the CodeBlocks Project File.
You open it in CodeBlocks then 1) Click "Build", "Select Target" ->"Linux SDL GL Release" screenshot 2) Click "Build" -> "Build" to compile. screenshot 3) Then it compiles and you get to read about 12 warnings that don't apply and get to see about 100 developer comments of mine. Requires SDL2 2.0.4 Dev (or later) installed to compile. To run the engine, you'd need SDL2 2.0.4 (or later) installed. I hope it works for you. But I have no idea if it will work for you on a different distribution. I also don't know what version of GCC I used. I used whatever version was already there after I installed CodeBlocks, which I installed out of the Ubuntu Software Center screenshot, which of course is Ubuntu thing. I hope that helps! I'm able to reproduce this undesirable behavior in the DX9 build.
I haven't incorporated all the MH changes yet, I had too many builds/platforms I was juggling around. I'm generally an ALT-ENTER user and didn't think of testing DX9 with a fullscreen windowed mode. What you independently verified and what Spike is suggesting as the likely mechanism sounds right. Short version: I'll see if I can tune up the DX9 version to get to use the all the latest MH 12/30/2016 changes. Keep in mind, mh is saying that some of this stuff D3D is very touchy about --- so Remember --- you might not actually be able to have everything exactly the way you want it. Thanks, Baker!
Turns out I had everything right, except that I didn't know to "Select Target." Unfortunately, with this build I'm still getting the instant "Segmentation Fault" crash I was with the Ubuntu binary. :/ Ah well. Ah, too bad. I wished it worked for you, obviously. At least the Windows version runs under WINE for you on OpenSUSE.
I knew to specifically call it a Ubuntu Linux version. install valgrind, drop to a terminal, start via valgrind, eg:
LIBGL_ALWAYS_INDIRECT=1 valgrind then publically shame baker with each and every stack trace that it spits out on its way to crashing... then you ask baker how to re-enable debug info (if you're lucky then 'make clean && make CFLAGS=-ggdb' will do it), then repeat... valgrind is so much easier to debug linux programs than gdb, at least if its simple enough that a stack trace is all that's needed. if nothing else it'll give baker somewhere to look. the libgl_always_indirect thing is to keep valgrind from tripping up over the graphics drivers poking user-memory from kernel space. you may see similar false-positives from sound drivers. It might also point out a whole load of other things that someone's overlooked which have so far failed to crash anything, so probably just focus on the last one or something. @kp - awesome
@spike - I have a todo-list you know. ;-) Like my main priority is DX9 integration because MH's time and effort is important to me -- and it is a voluntary surprise contribution on his part, which I appreciate and clearly many others do as well. I'm also just one guy. And this is a free and open source project for a game. Despite disagreements about multi-game, I think it is rather clear that on most topics we are in complete agreement. No obligation or expectations, but if at any point you wanted to contribute as much or as little as you chose, it would be welcomed and used. And if not that, that's ok too! You've more than done enough to help me over the years, and never think I don't appreciate it. Anyway, that door is always open and you are always welcome. And like my interactions with MH and his interactions with me --- it's all about developer fun. So The Winquake version resolves an issue I reported way upthread -- if I set it to an 800x600 window, it now behaves like the GL or DX8 versions and doesn't cut off part of the HUD at the bottom of the screen (along with the usual clamping behavior). Nice.
The Winquake-GL version just shows me a solid white screen no matter the resolution setting, but I can hear the demons running. Thanks for the info.
Yeah, the WinQuake GL was not targeted to your machine. If it doesn't have non-power of 2 texture support, it'll explode. Rare case where I was writing an engine build almost exclusively targeted towards killpixel's machine -- which with that 3840x2160 screenshot shows is pretty decked out. This is all valgrind spit out on the binary I compiled, if anyone is curious:
http://pastebin.com/JcTPtmFu @Baker. Please disregard :P Next update, I'll have the option to disable pthreads.
And tell you what to do to take another swing at this. Mark V does not use pthreads very much. Now this doesn't guarantee that even with pthreads disabled that it will work. But maybe it will work. ;-) /Either way, I'd say you fit in here just fine as a beta tester! (And thanks to Spike for providing the suggestion.) I believe I know the issue.
I use pthreads. I normally don't do SDL builds, I try to go native. SDL has some sort of threads feature. SDL's threads feature and pthreads fight. I'm about ready to upload the new source for JimBob. http://quakeone.com/markv/older/1025_mark_v_beta_source_no_sdl_pthreads.rar
Also when you compile, instead of selecting the Build->Select Target->SDL release you might select SDL Debug instead, which will keep the debugging symbols intact (more information becomes available). Hey! It runs now! And looks great! Thank you, Baker :)
Only problem I see now is mouse drift (or looseness). It's like I have an uncalibrated joystick, except I don't have a joystick or gamepad at all. It keeps spinning or drifting even when my mouse isn't moving. Clicking a mouse button will stop it (until I move the mouse again). Windowed mode didn't help. Tried this command line to no avail: Tried a different mouse -- same issue. Tried darkplaces again (just to be sure) and it's not happening in that engine. Anyhow, I'm just reporting this to report it. This could be a rabbit hole for all I know. So whenever/if-ever you (or another coder) can find the time to look into it is fine by me. Type nomouse 1 in the console or add -nomouse to the command line for now to disable the mouse.
Out of curiosity are you using Gnome or KDE or something else? I think using SDL_SetRelativeMouseMode(SDL_TRUE) will fix JimBob's mouse issues.
This will hide the cursor for you and start sending the application relative mouse events read from the system's raw input API's on linux and Windows (I started a mac implementation which I need to polish up and get the SDL people to merge..), it's the right way to get mouse input for FPS games with SDL2. I'm currently putting together a Windows "skeleton app" which will just create a window and initialize Direct3D. This will enable me to do another bunch of testing and determine which issues are coming from Direct3D (which we don't have control over) and which are coming from the engine (which we might have control over).
I see from your screenshot that your netboot is running XP. I have access to an MSDN subscription so I can spin up an XP VM in VMWare Player which should be representative of your netbook's hardware, then do a bunch of testing there too. I do know that behaviour of so-called "fullscreen windowed" modes, interaction with the taskbar, etc changed at some time in the post-XP timeframe. It may be the case that special-case code is needed for XP versus post-XP. I assume that nobody gives a toss about Vista, so establishing the behaviour on XP and 7 seems like a good place to start. I have doubts about the best way to handle this. Right now I have a bunch of code that checks the window size and will throw errors, but I wouldn't seriously propose that as a solution. I'm not even certain that it's appropriate to handle it in the wrapper, although if the D3D behaviour is sufficiently different to GL, it might be. If you have any suggestions I'd be interested in hearing them. Assume for the moment that I can't get it working - what would an acceptable fallback be? Until then I suggest run it with -height 560 or thereabouts. Here is what is funny -- back in 2012 when I wrote the "single frame mouse code" for Mark V, I had SDL 1.2 and Linux in the back of my mind.
SDL2 either didn't exist or was a concept or upcoming project. And the undesirable "grab the pointer position" and "center the mouse in the window" method was what most Linux Quake engines did. Current code isn't very accumulator friendly. Haha. @JimBob -- just tried with KDE/Plasma --- yeah KDE sure hates the mouse code. I can switch between Gnome and KDE rather easily, if you are able to load up Gnome it may work. KDE no like the current mouse code. Hmmm
So look at the moment that the SDL2 library only supports some of the new functions in 2.0.4 and 2.0.5 on Ubuntu's Unity? As a Linux novice this is my interpretation of what I am seeing. More work to do. Well, I can say this the Ubuntu Linux version is quite nice running on Ubuntu with Unity -- has a resizable window and about 99% of the Mark V niceties. But at present time, the other desktop environments and current SDL2 do not seem to play nice with the current implement of the Mark V SDL2 mouse code. Well, I guess if I get too impatient I can try this:
http://download.opensuse.org/repositories/X11:/Unity/openSUSE_Leap_42.1/ But I'm afraid I'll break something if I do. I'll wait till Baker releases a new version to see if he fixes any of the issues (Spike put him on to a possibility).
Just to try and be clear, since everyone seems to be talking about different things, I am not using one of the borderless windowed full-screen modes. That mode actually works fine for me (1024x600 windowed, my desktop res). I can alt-tab away and back to it with no issue. Oops. I spoke too soon.... Ok, if I have JUST set it to 1024x600 windowed via the Options menu, then I can alt-tab away from it and see any other window, then alt-tab right back to Quake with no issue.... However, if I close and restart DX9 Mark V so that it starts up in that mode, then Mark V seems to be "always on top" and it blocks the view of any other window that I give focus, unless that other window is also set to "always on top." I can see the Start menu if I cause that to pop up via the Windows key, but DX9 Mark V blocks other windows that I give focus to.... All kinds of fun weird things happening.... This doesn't happen in DX8 Mark v. Anyway, if I am in any fullscreen mode in DX9 Mark V, an alt-tab results in my Quake "window" being sent to -32000,-32000 and it won't come back when I try to give it focus again. If I then exit Quake (I can hear the menu sounds to navigate to "Quit") I get a "Quake Error" popup that says "context_t::CreateTexture: unable to create a texture" But as far as using an "800x600" window, That works fine as long as I don't try to change it to that setting using the menu in DX9 Mark V (ie, if I set it by command line or just restart after having changed it to that, it works as expected, just clamping my window at 800x578). However, If I use the menu to change it to that, it does create the window, clamped at 800x578, but the window gets repositioned at 108,32767 -- way off the bottom of my screen, but now that I know this, I can use right-click commands to move the window back onto my screen, as I mentioned in my previous post. Anyway... I guess I'll wait for Baker to release a new version to see if any of this has been addressed.... I'll just reiterate that the problem isn't about the window being clamped to 578 height when I tell it to set to 600. That's all fine. 578 fits my screen res (1024x600) well enough (shown in the screenshot above). And Mark V seems to handle the window just fine at that size. The problem is that when I try to set that windowed mode (800x600) via the menu, the window gets sent to limbo way offscreen at coordinates 108,32767. This only happens in the DX9 build. It looks like it should be created at 108,-17 (that's where it appears at startup using the same settings). So (this issue anyway) just to be a matter of window positioning.... Can you replicate this by setting your virtual WinXP to a resolution of 1024x600 then trying to set windowed 800x600 in DX9 Mark V by the menu? SDL2 with Relative Mouse Mode accumulator, as ericw suggested.
http://quakeone.com/markv/older/1025_mark_v_beta_source_no_sdl_pthreads_relative_mouse.rar Better than even chance this solves the mouse problem for KDE + company. Ok, actually there is more happening than just window position. It seems that after changing the resolution to 800x600 windowed via the menu, not only does the window get sent to limbo offscreen, but it looks like this (top image):
http://imgur.com/a/3NLCg And it THINKS it's at 800x600, even though it's not.... The screenshot comes out at 800x600 resolution, even though the game window size is exactly the same as the earlier desktop screenshot (Oh... that must be why the menu text looks wrong in the former case, though I didn't capture that text, but it's definitely missing some rows of pixels). And I bet the added black bar at the top makes up the extra pixels from 578 to 600. The lower image is how it looks after restarting Quake. No weird black bar at the top, and the image resolution is 800x578. So it seems to me that upon startup, DX9 Mark V checks the resolution stuff and sets everything correctly (even when clamping the window size is needed), but when changing it via the Options menu, it does not perform the same checks or something, and stuff gets messed up. And the window position gets sent to limbo. I believe Spike mentioned something possibly related: "side note: with d3d, make sure that your d3d backbuffer actually matches the size of your client area. if it doesn't then d3d will be a little more expensive whereas opengl will just resize the backbuffer for you. this also makes handling WM_SIZE much more annoying in d3d. " So it seems things are correctly set at startup (even if I set -height 600 on the command line and clamping is needed), but not when changing the resolution in the menu if window size clamping occurs and you get a window smaller than expected. EDIT: Added a 3rd screenshot (desktop rather than in-game) that better shows how Quake thinks it's in 800x600 when it's really in 800x578, as described above. You can see it's chopping off rows of pixels in the menu text.
http://imgur.com/a/3NLCg Ok, now I'll shut up until a new version comes out. ;) That works for me, too. Thank you for taking the extra time to sort that out!
Quake feels new again with a new engine to play with ^_^ Thanks for your help and feedback.
I tried it on Unity, Gnome and KDE Plasma just now. Unity was an A+++, Gnome was a A-, KDE Plasma was mixed for me --- but my KDE Plasma may not be update to date plus I rarely use it so I have no idea on how to tune KDE Plasma settings -- so hopefully is just me. If you don't mind, could you tell me if these binaries happen to run on your machine
http://quakeone.com/markv/older/1025_linux_binaries.zip May need to chmod them first, obviously. Ok, I was wrong. I have more things to report.
Ehhh... but I am having trouble doing testing now. Mark V won't let me delete my config.cfg file in the FvF folder to blank out my settings. It keeps re-loading the cfg from some backup place. I dislike the loss of control over my cfgs! heh Something like that necessitates a prompt for user control, "do you want to load cfg from backup?" It seems I can delete the config.cfg file in id1 just fine though, without the settings persisting. Mirrors do not get along well with skyboxes in DX9. Just activate a skybox and go peek in the Start map window mirror from various angles and you'll see.... Hm, and mirrors don't work at all if you use a different game dir.... For example, make an empty directory called "none" Run DX9MV and start a new game. Go look in Start map mirror. Then change "game none" and start a new game and repeat. No more mirror. Change back to "game id1" and the mirror works again.... Results are the same when starting with "-game none" (or any other game dir -- I noticed the mirrors weren't working when I was running FvF). Those 2 binaries appear to run just fine (with my 5 minutes of testing for each heh).
The only *potential* issue I notice in those (as well as the ones I compiled) is minor, being the apparent lack of mp3 music audio. But that's not a game-breaker. @jimbob - There are few things I have to do research into for the Linux build.
It's not too bad for a build that is not quite 2 days old yet, haha. Make it run first, make it great later. It's how coding is done. @gunter - I have various homeworks to with some of the things you've pointed out. With some luck, I'll have DX9 current and test things and see where everything stands with up-to-date code. True! It's not bad at all. And I'm happy to have something that's playable.
"mirrors don't work at all if you use a different game dir" - Gunter Just want to confirm that this quirk also occurs in mark_v_sdl_gl_gcc . If someone makes a map pack and they want mirrors
One of the Arcane Dimensions maps by pulsar has a mirror in it, for example. The window02_1 in the start map and E1M5 in standard Quake is an homage to the original GLQuake with the feature. But if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell That makes sense.
Guess I got confused by the r_texprefix_mirror cvar. Also I blame Gunter ;P Config.cfg
This is the same as the problem I reported. If you do: * Start * Run * %appdata% You'll find a "Mark V" folder which also contains a config.cfg; delete that too. Display modes/etc I'll need to take time to reread your posts more carefully. It seems to me that the most probable cause is that when changing modes, alt-tabbing, etc, GL requires you to write your own code for some things that D3D doesn't, and D3D requires you to write your own code for other things that GL doesn't. What that means is that there is going to be something where either (1) in-engine code is fighting against an automatic behaviour, or (2) in-engine code is missing for something. I'm inclined to suspect (1) from experience. For example, in GL the AppActivate function vontains code to explicitly restore display modes and minimize the window on Alt-Tab events. D3D requires none of that, and in fact changing the display mode this way will cause trouble for D3D. In the most recent code I gave Baker I rewrote AppActivate, and provided new wrappers for ChangeDisplaySettings and EnumDisplaySettings, designed to avoid all of this. I'm not sure how completely he's integrated these yet, but if he still has work to do with them it would be consistent with your experience. the alternative is to support EGL+GLES2 on windows and grab the dlls from ANGLE(or chrome/firefox), and get it running in either d3d9 or d3d11.
how angle works around d3d9/dxgi quirks I've no idea - maybe it just creates a nested/child window and does all its rendering to that... I've got MH's latest DX9 integrated.
Annoyingly the shader gamma off by 1 pixel has returned -- but instead it stretches, hard to notice except when in options. At first I was thinking it might be a matrix calculation issue in the menu canvas somehow, sometimes the 2D matrix needs a 0.5 kick to get the rounding right -- if I recall. Perhaps something in that ballpark is happening here? Had to address 1) A border painting issue. 2) Made the window centered on ALT-ENTER and video mode switch. 3) The windowed mode window was staying topmost after a fullscreen. Baker addressed. 4) Made resized window stay in the same place during resize. Need to double-check the ALT-TAB modifications MH made and ensure I did them right in the engine code. Everything else looks great except if stencil was anticipated to work -- I don't know either way -- does not seem to work for me (doesn't in DirectFitz either) So I made a single #ifdef in the code near the top of quakedef.h to toggle compile with DX9 stencil on or off. I need to double check some things before I do a DX9 version update, but it very close. Mark V Build 1026 - Direct X 9 | Source
A screenshot of a few things combined together as a test Screenshot Mirrors, non-power of 2, external textures, particle effects, alternate HUD, lightning gun sparks, QMB flames, DX9 depth test level, gamma shader, vid_vsync, resizable window, combine, alpha, texture matrix. The (* about 9 things the DX9 wrapper does that DX8 didn't) @gunter - the sky will not show up in mirrors in DX9 in this build, stencil isn't seeming fully operational. I did a trick or 2 to obtain most of the effect ;-) This is becoming an engine to my liking. I'm already using it for the inspector tools (the texture inspector is more handy than DP's in that it highlights the faces instead of just displaying the texture names) and that awesome ffwd/rewind feature in demo playback, but if you keep on "spiking" Mark V like that, I might actually start using it to play, at least for the maps that DP doesn't handle well.
What's the name of that QMB lightning texture? When I try to activate this option in DP, it reverts back to the original polygon lightning, so I guess it's because it lacks the texture and I need to copy/paste it into DP. In JoeQuake or Qrack, the name is zing1.tga living inside a pak0.pak somewhere if you wanted to obtain that file.
Mark V has it built-in, the same way Mark V doesn't need any Just done some stepping through a debug build of the latest Mark V and I think I know what's wrong with stencil.
In OpenGL glClear is affected by the various write masks (glColorMask, glDepthMask, glStencilMask). In Direct3D the equivalent is not. However, in Direct3D clears are clipped to the viewport rectangle, whereas in OpenGL they are not. Therefore, if you make a glClear call through the wrapper, and if the previous glViewport was to create a partial viewport, the full window won't be cleared. This was a very real problem caused by FitzQuake's render-to-framebuffer water where it updates the warp images before calling glClear. The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer) sets a partial viewport, then we come along and call glClear and only that partial viewport is cleared. Result is that only a small square in bottom-left (or top-left, can't remember) of the window gets anything drawn in it during the main 3D render. To work around this I added code to my implementation of glClear which reset the viewport to the full window before clearing. This was done in the expectation that there would only be one glClear call per frame which would clear all required buffers. That's obviously not the case in Mark V which clears the stencil buffer before drawing it's mirror sky stuff. Added complication: in D3D viewport rectangle and depth range are combined in a single state. In GL they're separate states. So resetting the viewport also messes with the depth range. End result is that both the viewport rect and the depth range are messed-up as soon as you make that glClear (GL_STENCIL_BUFFER_BIT) call. I'm going to fix this by putting the viewport back to the way it was after making the clear call. With hindsight I should have done this from the outset, but you know what they say about hindsight. I haven't had time to load up Windows 8 or Windows 10, but I did testing on Win 7 with and without Aero and so far everything looks ok --- at least in Windows 7 with whatever Direct X drivers came with Win 7 -- I know they aren't the same as, say, XP which may behave radically different.
You may have noticed I added on-the-fly resizable window to WinQuake to make the "let engine decide window borders" into irrelevant issue. The DX9 build was my main reason for wiring up WinQuake to resize-on-the-fly. The GL_SetCanvas stuff (which IMO needlessly complicates the 2D renderer)
Don't have much of an opinion on that But I can say it was hard as hell to make WinQuake 2D render identical to FitzQuake. So when Gunter was saying "original Quake centerprint" it somewhat follows I wasn't that big on the idea initially. @Stencil clear -- Open GL should have done it that way, which is the better behavior This is a case where I think no API gets it right.
Clears being affected by the write masks and the viewport rect are both IMO undesirable behaviours. GL adds the scissor rect to bound the clear, D3D9 lets you specify an array of RECTs but they're clipped to the viewport too, D3D11 has none of this crap so it gets partially there but in the end it fails because it doesn't let you specify a subrect to clear at all. The ideal API would look something like: Buffer->Clear (RECT clearRect, int clearMask, int ClearValue); In other words, you explicitly specify what you want cleared, how much of it you want cleared, and what you want it cleared to. No side-effects from previous state. I'm dubious about having a clearMask but one feature it does give you is the ability to clear RGB without clearing A (or vice-versa) in the color buffer. I don't personally have a use case for that but others might. Man, that %appdata config saving shiz is annoying.
I was trying out the new DX9 build but still had the skybox error as with previous version... took some time to find that and delete it so I could get a fresh start. Which solved it. Is this by design, cause it takes such a simple concept and fucks it up, imo. I mean, I just want a config file, saved in my id1/mod directory. I know other games/apps do this but I don't try out 35 different flavors of those games/apps like we do with Quake ;) Damage, this is beta at the moment.
When it works properly, you wouldn't even know it was there because it was meticulously planned. It was there for 2+ years, not even super-picky Gunter noticed. Until I slightly broke it recently. I'm very against advanced-enginitis disease. /Keep in mind that only in this last week was anyone even aware of convenience that made life easy street for 2+ years in Mark V. ;-) I do hate when control is taken away from me without my consent, even in an attempt to "protect me." As I mentioned, a feature like this NEEDS a prompt for user control. It's not necessarily a bad thing... except that it takes away (easy) user control of the cfg file. It would be better with just printing something like, "Your config.cfg file has been altered by outside sources. type 'exec backup.cfg' to load last Mark V cfg settings." But apparently this feature is not currently working as intended or something.... How exactly is is supposed to work?
Ok, looks like we're moving in the right direction. My window no longer gets sent to limbo in any of the previous situations. But I still have the issue I reported above, where the window gets clamped to 800x578 but it thinks its at 800x600, resulting in some ugly stuff happening. (seen in the 1st & 3rd screenshot I had posted: http://imgur.com/a/3NLCg However, if I press alt-enter, then alt-enter again, that issue goes away and then DX9MV knows it's actually in a 800x578 window again (just like if I start it up in that res to begin with). Then the window looks all correct, like in a previous screenshot I posted: http://imgur.com/a/URhKC Ok, it looks like the issue is only occurring in the (admittedly unusual) situation where my window has been set to 800x578 (due to the automatic clamping) and then I reset it to 800x600 windowed mode in the Options menu again. It does not appear to happen if I am making any change from a completely different resolution, whether windowed or not. And it looks like the "full screen borderless window" mode of 1024x600 no longer works the same. Now it does have a border.... which is causing the clamping of the height to 578 as well, which means I can reproduce the same issue (when already in window 1024x578 then trying to set to windowed 1024x600). And it seems the full screen modes are... um... not correct. They are displaying the same chopped text as when it THINKS it's in a 800 height window but it's actually in a 578 height window.... So it seems like the full-screen modes are accounting for there being borders or something.... I get this effect even when I first start up DX9MV at the fullscreen res of 1024x600 without any weird res changing Here's a screenshot: http://imgur.com/a/v5i5h My scr_conscale is at the weird 1.5 but that alone previously didn't cause the issue, as the 2nd screenshot from DX8MV shows. Oh, it appears the previous DX9 version had this issue as well, so I guess it's not new to today's release. But with this new version, I am getting a long delay when starting a game -- about 13 seconds. I don't have MP3s enabled. It only takes about 5 seconds to start a game in DX8MV. This delay happens regardless of my resolution settings. Ah, it seems to be taking extra long for HQ textures to load.... If I disable them, then it loads a new game in about 4 seconds. This delay did not happen in the previous DX9 version. About r_waterwarp: Console variable: Toggle the use of the screen warping effect when the player is submerged in liquids. Set to below zero for water warp in GL version, but not in WinQuake version. r_waterwarp 2 in Open GL is FitzQuake style waterwarp. I find that information confusing, and it doesn't seem to work. In GL or DX9, you can ONLY get the new effect no matter the setting (though "0" is "off"). In DX8 there is only the old GL warp effect (I understand the new effect isn't in this version). And in the Winquake version, the water warp is so subtle/slow you can BARELY notice it. Addendum:
If I start up DX9MV with 1024x600 windowed having been previously set, it correctly appears to be the borderless window that takes up my full screen, but the distorted text is still occurring. If I change to 1024x600 windowed mode from any other mode (including just hitting alt-enter twice after starting as above), then the window borders appear and the window gets clamped to 1024x578, but then the text is no longer distorted.... ... when can we expect the Vulkan version, baaaahahahahha
Why should modern day Quake be relegated to such archaic API's!!! http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-12.zip
Stencil is fixed, tested & confirmed working in latest Mark V release too. THIS DOESN'T INCLUDE ANY FIXES FOR ISSUES REPORTED BY GUNTER I'm still in "investigate mode" for those. I considered the stencil issue sufficiently important to release a new version fixing that, since it affects everyone and currently has ugly special-case code in MarkV. @Gunter I asked you above if you had any suggestions for an acceptable fallback if it does turn out that the 800x600 behaviour is something that we don't have control over in software. I'd really appreciate an answer to that, because I really cannot change the way Direct3D works. I am willing to put significant work into tuning this to meet your requirements, but I do need to be seeing something coming from you too, and right now I'm not. Really good to see things like true lightning in, and I could mention a whole series of other features I like about the engine, but I can sum up by praising the user convenience it provides. That manifests itself mainly in the console, where all the features like text editing shortcuts, find, help and shift-tab to reverse cycle are incredibly handy for anyone who uses the console frequently. Also good to see mh helping out, since DirectQuake was always my favourite engine prior to Mark V.
While fiddling around with it I've found a few issues you may be interested in. I hope these haven't all been covered already (I did ctrl+f a bit through this thread, but it's coming up on 1000 comments now and tricky to track everything said). My system is an up-to-date Windows 10 64 bit; i7 870; Nvidia 970 with driver 376.33. 1. Just confirming 2 things mentioned above - the r_oldwater crash mentioned by Baker in comment 761 is still present. The vid_hardwaregamma 0 alt-tab issue mentioned by Gunter in comment 335 seems to no longer be present in v1026. Some other points about alt-tab/alt-enter/fullscreen stuff which I think Gunter has discussed, but I may as well give my own experience of it since I made some notes. I use a 1920x1080 display. In v1025 + v1026 the game always seems to start in what appears to be fullscreen borderless mode even when vid_width 1920; vid_height 1080; vid_fullscreen 1; vid_restart are in autoexec.cfg in that order. In the dx9 builds, an alt+enter at this point gives you fullscreen exclusive. OpenGL works as might be expected with this cfg - ie providing fullscreen exclusive behaviour immediately. On v1025, continuing to toggle alt+enter results in switching between 1920x1080 fullscreen borderless and 1920x1080 fullscreen exclusive. On v1026, toggling results in 1920x1080 bordered window and 1920x1080 fullscreen exclusive. 2. It seems vid_multisample has no effect in dx8, dx9 and OpenGL. I also noticed vid_fsaa doesn't work for me in Quakespasm, though DirectQuake's vid_multisample does. Mark V - https://i.imgur.com/DYPxBwE.jpg DirectQuake - https://i.imgur.com/OHQcKnh.jpg 3. It seems r_showtris 1+2 both do the same thing. The description indicates that one shows triangles visible to the engine, whereas the other shows those only the human eye can see, yet they both seem to only draw the engine's view. 4. Mirrors don't function correctly in dx9 when reflecting the sky. dx8 - https://i.imgur.com/B9ZtwLp.jpg dx9 - https://i.imgur.com/UpBVC0b.jpg 5. Noticeable input latency in dx8. When testing the dx8 build I had the sense that the game was feeling much less smooth generally than the other builds, almost juddery and with what felt like a significant difference in input latency. I borrowed a 120fps camera and did the following test - record the mouse and the screen simultaneously -> press mouse1 to fire -> count the number of frames from mouse button depression to response on screen. Not perfect, obviously ideally you want an LED attached to the mouse, but I think the test gives a good enough indication. On dx8, on a mouse with a polling rate of 500, host_maxfps 500, a screen refreshing at 60hz and vid_vsync 0, the average number of video frames from button press to screen response was 4.7 On dx9 under the same conditions, it was 1 No idea if this is simply a limitation of dx8, but thought it might be worth knowing. The point I mentioned earlier about the game always starting windowed in dx9 is also relevant to this, since subjectively I noticed windowed has greater input latency, which is usually (always?) the case when playing any game windowed. I'm not really sure what you're asking, mh.
Acceptable fallback? Just make it work correctly like it did in the DX8 version, heh. I'm pretty sure I've provided enough detailed feedback for Baker to start hammering away the problems. And I'm pretty sure this IS something controllable by software, because, as I noted: I've found the problem (Mark V thinking it's at 800x600 when it's really clamped to 800x578 window) only occurs when I try to change to 800x600 windowed via the menu when it's currently at 800x578 windowed (I know, there's never actually any reason to do this, other than testing). New bit of info: at that point if I do vid_restart I get: "Video mode request is same as current mode." So again, it THINKS it's in 800x600 but it's actually in a clamped window of 800x578, and that is causing rendering issues. But the problem fixes itself upon mode change by hitting alt-enter twice (going to fullscreen then back to windowed mode). So when it knows it's changing modes, it sets things up correctly. The problem also doesn't happen when starting with -width 800 -height 600 by the command line (I get a correctly clamped and rendered window). So it just seems that it needs to go through the proper steps after each mode change *even if it thinks a mode change is not occurring* So, it needs to do something like: -set new mode -check for window clamping altering that request -adjust video stuff to correctly reflect clamped size Instead, when I am currently in the 800x578 previously-correctly-clamped window (when DX9MV has correctly detected it, it shows that in the Options menu, even though vid_height reports 600) and then I tell it by the menu to change to 800x600 (for texsing...), it does something like: -set new mode -don't notice the window was clamped back to the previous setting (meaning no window size change actually occurred) -draw things at the non-clamped setting (800x600), causing issues, and report that the video mode is 800x600, which doesn't match the window size. Perhaps the glitch is occurring because the actual clamped new window size is the same as the old window size, so it does not think anything was adjusted... so it doesn't realize the window is not the size it was requested to be. I'm not sure what more info I can give as a bug tester, heh. I think Baker should be able to address this with the info provided. But if you can be more specific in what you're asking, mh, I will, of course, try to provide any help I can. Assuming you're not just asking me for something you know is impossible for me to provide? ;) Further info:
The reason my little glitch can never occur in DX8MV is that it reports I am at 800x600 in the menu even when the window is correctly clamped to 800x578, so it won't let me try to change to 800x600 since it thinks I am at 800x600 already. Whereas DX9MV correctly reports 800x578 in the menu, so it WILL let me try to change to 800x600... which confuses it, apparently. This glitch has become pretty minor though, now that Baker fixed the window positioning thing (I previously thought they were related). Another new wrapper version probably coming up soon, depending how many fixes I can get in over the next hour or two.
Alt-tab from fullscreen modes loses the warp images and occasional device reset fails - fixed. Again, it's just a single fix but it is important enough to warrant an update. Perfect mirrors + stencil shadows.
Direct X 9 - Build 1027 A Once I saw the source code, I knew this will be followed by Revision B with the "2017 HOLEEFUK feature of the Year" The source will appear in the folder http://quakeone.com/markv/older here just a min, in case MH needs sooner rather than later. With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness - https://i.imgur.com/ywSXIWm.jpg
Can confirm skies now reflect correctly in mirrors. I think at this stage I'm more confused about what's happening than anything else.
Anyway... now that I have an XP VM I have Pix and the DirectX control panel back - WOO-HOO! - I never realised how much I missed them. I already have a fix for one issue coming in... With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness
Fix in next version. http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-12-v2.zip
Fixes "With 1027a, r_oldwater 0 + alt-tab when in fullscreen no longer causes a crash, but does produce the following strangeness " I didn't get Gunter's stuff in although I now have one solid lead for what's going on. Thanks to the DirectX control panel and the debug runtimes I can see that I'm getting a lot of "viewport is outside the render target" errors when running at the same height as the desktop mode. That needs to be fixed as a first priority, and the reason why it happens is that the display mode clamps. I can't right now see a good way of handling this without adding more code that's going to percolate back up to the engine. So rather than take the time to work it through and delay the required alt-tab fix, I'm releasing now so that Baker can get that fix. Direct X 9 - Build 1027 B
Latest mh revisions addressing issues. Source will soon be in the same place as last time. /MH shadow volumes awaits in revision C. You guys are crazy productive sometimes. I really appreciate all the work that various Quake-dudes put into this little hobby.
I'll check the latest builds tonight to see if the flickering has gone away on my system. Should I also check autosave behavior? Anything else? Multisample in Open GL, at least for Windows, has been disabled for
mh is down on the idea on adding to the Direct3D build. There's a post somewhere in this thread where he discusses why. I could re-enable it in the Windows Open GL build with some effort of rewriting some things slightly, but in the age of 3800 x 2600 monitors, multisample is going to be hella hard to notice. Looming as a larger factor -- the Direct 3D build has 1) superior frames-per-second performance 2) superior compatibility on older hardware Direct3D 9 is going to become the main build hardware accelerated build for Windows eventually. Thanks!
If you want to join in the fun, grab the current source code and try to compile the Linux version in CodeBlocks on your CentOS and see if it runs ok. Requires SDL 2.0.4 dev. I haven't had time to raid Requiem for the goodness in the Linux build like video capture and such. I'll check the latest builds tonight to see if the flickering has gone away on my system. Should I also check autosave behavior? Anything else?
Lots of irons in the fire lately, I still have more on my todo list --- and I need tackle MH shadow volumes. I don't even have the Mac version quite up-to-date. /And pesky little issues like ones reported by dwere, yourself (config read order, built-in Quaddicted installer unpack with certain file names like your dll example) and nuisance gremlins remain -- hence it's beta. Autosave should be fixed. And any information on whether or not the flickering is gone for your machine (and pulsars) would be great! The shadow volumes aren't robust, by the way. You're going to find places where they leak through geometry or fly around at odd angles. In terms of shadow volumes they're probably as good as you can get without going towards a realtime light/shadow setup.
So I'd advise them as an additional option rather than an outright replacement for planar shadows. That means the choice comes down to one of two imperfect shadow types, or no shadows. Not ideal, I know, but different imperfections drive different people nuts in different ways, so hopefully it covers enough angles. http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-13.zip
This one resolves one of the problems when running a windowed mode the same height as your desktop, and where the mode gets clamped. That being viewport/rendertarget size mismatch. Extra code is in GL_BeginRendering and the #define name should come with a smiley - it's meant to be humourous, not insulting. ;) This one also resolves a second minor issue where a rendertarget used as a texture needs to be unbound before it can be set as a rendertarget again. Not such a big deal because D3D will detect this and unbind it for you, but still nice to have it done properly. The wrapper now gets a totally clean run on the Direct3D debug runtimes. Hm, I am finding that since version 1.26, activating id1 mirrors will completely freeze me up. r_mirroralpha 1 prevents it from happening.
That's in addition to the weird extra-long delay when loading external textures, which also showed up in 1.26 Might it have to do with these new warnings I get as of 1.26? Warning: texture_env_combine not supported Warning: texture_env_add not supported I also get this one, but it was always there in DX9: Warning: texture_non_power_of_two not supported And it looks like the env_combine warning is also present in DX8. But there are no mirrors in DX8, and it loads external textures without an extra delay. Also, as of DX9 version 1.26, the fog got uglier again when gl_overbright 1 is set....
It's an issue I reported on the old page (#1217 of old page, if you wanna see the screenshot), but it was improved in DX9 1.25, and now it's back to the previous, a bit uglier, behavior (fewer fog bands on lit wall areas, making a rougher gradient).... @johhny - awesome.
@gunter - So DX9 1.25 was good, DX9 1.26 fog less good. Right? @railmccoy - r_oldwater = no issues now, right? I'm sure mh is gonna want to know more about the specifics.
I get 700 peak frames per second with basic FitzQuake settings in some areas of the start map just wandering around. And my machine is rather average. @gunter - As the DX9 had more capabilities enabled, I disabled DX8 limitations that I had imposed on DX9.
In the case of external textures, I have Mark V using glMatrixMode (GL_TEXTURE) to perform scaling for texture coordinates to align it with the original texture, a feature which DX8 did not have. I'll wait for mh comments before delving into it, I noticed changes to the mip-mapping process, etc. The AD quake.rc sets max_edicts 8192 for Fitz/QS/Mark V but apparently dx9_mark_v doesn't recognize the command.
Also, textures are still blurred while I have GL_NEAREST_MIPMAP_LINEAR specified in both quake.rc and autoexec.cfg. Combine/Add/Fog/Performance
So I don't have to do a new release for Baker to get this fix. Bug in d3d9_glcontext.cpp, line 409, in "if (D3DSHADER_VERSION_MAJOR (d3d_Globals.DeviceCaps.PixelShaderVersion) > 2)" change ">" to ">=". Oops. That will fix the engine reporting combine and add not available, and I believe that it will also fix the whole ugly fog business. With gl_overbright 1 and without combine the engine will do multiple passes blending in coloured fog with black fog. Where combine is available it will do it all in a single pass. I now believe that the multiple pasees are the cause, rather than per-vertex vs per-pixel or API differences. This should be reproducable with original FitzQuake or with QuakeSpasm by running -nocombine. I'd encourage further performance testing after that. D3D9 being sluggish should go away: it would explain why Baker and I get good perf but some others don't - because you're being incorrectly dropped from single-pass to multi-pass the renderer is obviously doing at least twice as much work. I've a hunch this may also fix Gunter's reported issue with mirrors. It's the Quake equivalent of NASA's minus sign. Changes to mipmapping/Textures I decided that default glTexImage behaviour was insane. You can specify miplevels in any order, with different formats, textures can be incomplete and the whole thing can't be validated until draw time. So what I did was ignore every miplevel but 0, using that to build the texture. A full mipmap chain is always built and sampler states are used to control level selection. I have to take over mipmap level building myself here too as a result of all this. So what this means is that the engine is building mipmap levels twice. Once in the regular code, which the wrappper just discards, and once again in the wrapper. I suggest just calling glTexImage for level 0 in the D3D9 build and everything else will just work. textures are still blurred while I have GL_NEAREST_MIPMAP_LINEAR specified Because you have anisotropic filtering set to higher than 1. Nothing I can do about that; D3D defines 3 texture filter modes: point, linear and anisotropic. If anisotropic filtering is higher than 1 then point filtering (the equivalent of GL_NEAREST) is ignored. A workaround might be to ignore anisotropic filtering for GL_NEAREST modes but I suspect other people would complain about that. Both Mark V and Quakespasm use max_edicts 8192, although in Quakespasm you can change it and in Mark V you can't.
GL_NEAREST_MIPMAP_LINEAR specified in both quake.rc and autoexec.cfg Sounds like a bug in Mark V related the currently slightly borked config execution. When the beta gets closer to being a stable, I'll make sure your example is ok. Mark V uses the stencil buffer for sky draw and the stencil sky draw is in the middle
So stencil sky draw is going to wipe it and it looks like you draw shadow volumes at the tail end. I'm rather stencil rusty at the moment and you're in the thick of it, if you have a quick thought on how to adjust the stencil calls to only use maybe a certain bit, would be greatly appreciated. I've always read that at least in Open GL, I should be wary of trying to do anything other than 0 or ~0 (-1). But there's 4-8 bits of stencil available. Meanwhile, I'll just come up with a workaround because I want to get the next release out. Then the other school of thought is just firing off the shadows before drawing sky and we'll just say alpha entities don't have them ;-) And shadows on water is just tough luck. R_DrawShadows (); //johnfitz -- render entity shadows R_DrawEntitiesOnList (false); //johnfitz -- false means this is the pass for nonalpha entities Sky_Stencil_Draw (); // Baker: This will draw the sky if there is stencil. R_DrawTextureChains_Water (false); //Baker -- solid warp surfaces here R_DrawEntitiesOnList (true); //johnfitz -- true means this is the pass for alpha entities R_DrawTextureChains_Water (true); //johnfitz -- drawn here since they might have transparency Yeah, I have to say I like the shadows quite a bit. They may not be completely perfect, but they're still a mighty nice upgrade. Unfortunately the shadow volumes need all 8 bits because they increment/decrement rather than just marking specific bits.
What I'd do is split the R_DrawEntitiesOnList (false) call into two. First call before sky and only draws bmodel entities. Second call after sky and draws alias model entities. You then need another clear of the stencil buffer after drawing sky too, but I think that's the simplest and cleanest way to do it. Mark V Build 1028 - Direct X 9, Open GL, DX8
The Direct X 9 build should be fully up-to-date with everything including the latest tweak suggestions from MH and all the revisions. I often get triple or higher the fps with DX9 vs. the Open GL build. Fifth and gunter had issues with some sluggishness in DX9, but the latest version should make those problems go away. Volumetric Shadows Most easily experienced typing in the console: chase_active 1; r_shadows 3 // 3 = volume Volumetric shadows are in the DX9 and Open GL builds, as is MH waterwarp. There is a DX8 build in the zip, mostly for beta testing use as DX9 gets hammered and molded. Linux Build - Although I didn't include binaries, the CodeBlocks project should be up-to-date for building and would have all the above features. Source code is in the same folder as the download in this post. The new shadows look really cool, especially on rotating items.
Anyway, it doesn't look that cool in certain situations such as this (regarding the casting location of the shadows). However, I think that problem already existed with the old shadow system, so I guess we have to file it under visual glitch. Heh, yeah that's what I said above about where they leak through geometry.
In order to solve that you'd need to start casting shadows from all brush and world geometry, and next thing you know you've got a full-blown real-time lighting engine. Personally I always run Quake without shadows anyway, on the basis that no shadows are better than bad shadows. This just offers shadows that are bad in a different way. Because you have anisotropic filtering set to higher than 1.
OK, I set it to 1. Fixed the blurriness but now my liquids umm... scintillate? (don't know the exact word for it) in the distance, a bit like old TV static. I suppose this is an either/or situation? ow my liquids umm... scintillate? (don't know the exact word for it) in the distance
Original FitzQuake doesn't mipmap water textures and this is inherited from that. On the one hand that replicates the behaviour of software Quake. It also makes the render-to-framebuffer waterwarp easier because you only need to render a single miplevel instead of the full chain. On the other hand it causes sparklies in the distance. 'Scintillating water!'
Put it on the back of the box. No issues with fullscreen alt-tab and r_oldwater 0 now. Gonna play around with the new builds now and see if there's anything else to report. Mirror freezeup = fixed!
Window clamping resolution glitch = fixed! New shadows = neat! Old stencil shadows = now working too. fugly fog = less fugly! Fantastic work, mh! Issues that still exist: Delay upon first starting a game still happens. Using external textures and a skybox, no MP3s, all settings the same, upon first starting a new game (starting Quake fresh before each test), time between telling it to start the game in the menu and when the game actually starts: DX8 = 3.16 seconds Dx9 1.25 = 3.17 seconds Dx9 1.26 = 7.17 seconds Dx9 1.28 = 6.89 seconds DX9 1.28 with no skybox = 6.45 seconds DX9 1.28 no external textures = 2.87 seconds DX9 1.28 no skybox + no textures = 2.42 seconds DX9 1.25 no sky + no textures = So the skybox causes a slight delay, but it's the external textures which are really causing the delay, as of version 1.26 The above tests are running id1. The delay gets worse when I'm running FvF, which may be loading other things like monster skins: DX8 1.28 = 5.96 seconds DX9 1.28 = 12.59 seconds So it seems like it is taking very close to twice as long, which may be a clue, like maybe it's loading the textures twice.... Also still happening as of 1.26, when first setting a full-screen windowed mode that matches screen resolution, I'm instead getting a clamped, bordered window (1024x578) instead of the previous 1024x600 borderless window. But the text in the bordered window looks correct.... Upon restarting Quake after making that setting, I get the 1024x600 borderless windowed mode, but I can tell the menu text is distorted (using scr_conwidth 1.5 -- I previously showed screenshots of this effect). I seem to be getting that distortion in any full-screen mode (this was happening as of 1.25, but not in any of the DX8 builds), which seems to indicate it's still not quite got its rendering resolution just right in full-screen mode. Ah, I think it's only happening when it's a full-screen mode with height equal to my resolution (so 800x600 or 1024x600 full-screen modes). It seems like it's drawing at a resolution equal to the clamped window's screen height (578), even when that's not needed because it has the full-screen mode height (600 with no borders) to work with.... I may be tripping, but everything seems taller.
Thinner ogre legs are weirding me out. Old issue has popped up. Well, it was an old issue in DX8, but it was fixed in that. It exists as of DX9 1.25:
gl_fullbright 1 = most weapons opaque when using ring + transparent weapon models (but not axe) unless using custom textures (must be as metlslime said, and the custom textures don't contain fullbright pixels). Illusionary ent guy is also opaque. gl_fullbrighs 0 = everything transparent, including illusionary guy. Interestingly, I can see my shadow through the otherwise opaque illusonary ent guy IF I set r_shadows 3. r_shadows 3 looks cool, and works fine when I'm running around a map by myself, but my little netbook cannot handle it when there are lots of other things casting shadows! Yikes, kills my FPS hard.... And it can make some weird effect, heh, like this: http://imgur.com/a/8zbT5 But as the 2nd screenshot shows with standard shadows, weird shadows were always a thing in Quake! @fifth - If you have a chance, could you let us know if the 1028 build DX9 works ok now?
@jimbob - thanks for info. Awesome. "Thinner ogre legs are weirding me out" @rail - nice to see r_oldwater issue is put to rest. @gunter - I'm getting this too. I type map "dm3" with r_viewmodel_ring 1 (it's in the menu by setting "Invisibility: Draw Weapon") I grab the ring and the weapon is fully visible, instead of translucent. Also in some cases, transparent entities are more transparent than in Open GL. Putting this e1m1 external That elevator example wasn't of enough interest by itself, but since Gunter pointed out the invisibility weapon draw, I thought now was a good time to mention it. However, I didn't want to point it out until I had time to verify that the state of all the gl capabilities is correct --- i.e. I cannot be 100% that it couldn't be a Mark V mistake that shows no symptoms in Open GL. Shader gamma - stretch looking
What I think could be going on there relates to how 2D matrix calculations often need a 0.5 nudge for even numbers. The menu canvas in that scenario should be 320 x 200. I don't see the "stretch effect" in the console at 640x480 in Mark V, but the stretch impact might be too minimal. If I were to type vid_hardwaregamma 1, instead using display brightness adjustment and not the shader, the menu text appears normal. Comment you made elsewhere was insightful -- "It suits me as well to work on the rendering layer and let other people deal with the other stuff."
Since the inverse has been helpful for me, since I've been able to focus on an entirely different set of objectives, like concentrating on get some extra builds ironed out (linux, trying to address killpixel's now deceased issues with WinQuake, etc.) The fact that waterwarp and shadows work on these other platforms like linux is awesome, clearly. /Time for me to attack outstanding issues, Mac build and see if firewalled Although I have no need to use it. Is there a reason why gl_texturemode is always linear?
Baker and MH, you two are just incredibly passionate workers.
DX9 version is of interest to me because ShadowPlay(Nvidia recorder) can hook with it. Water warp is a great effect and I get smooth gameplay with the latest beta release. r_shadow 2 looks great, with 3 having strange issues like the shadows being cast on the geometry below. Is there a reason why gl_texturemode is always linear? From my brief test, I also noticed this! mh on how d3d filtering is different
Because you have anisotropic filtering set to higher than 1. Nothing I can do about that; D3D defines 3 texture filter modes: point, linear and anisotropic. If anisotropic filtering is higher than 1 then point filtering (the equivalent of GL_NEAREST) is ignored. At some point, I'll add an FAQ or some way to convey that information because I can see that continually getting asked. Shorter version: Disable anisotropic Ah, Baker identified the distorted text issue I was talking about above, when in fullscreen modes. If I go back to vid_hardwaregamma 1 then the text looks correct.
vid_hardwaregamma 0 makes it distorted again. Note: though the help info says "2," "r_waterwarp 3" is the setting needed to revert it to the old GL style (the new waterwarp kills my FPS in GL, though it works great in DX). @Baker: I remember gl_overbright_models would affect how transparent the illusonary ent guy appeared, but he is a player model.... That setting probably wouldn't affect the elevator. Well, I just know that you fixed what seemed to be the same issue for DX8 back in build 1009. Random feature request: Many modern mice also have a left/right motion for their scroll wheels (and trackpads do too), used for sideways scrolling. You could make those actions bindable: mwheelright mwheelleft 1. Alpha masked texture support is buggered in dx9 - https://postimg.org/image/my3kopu9t/
2. Getting really bad framerates in OpenGL. Noticed it most severely in final fight on ad_fenrir, where I dropped to 40s. Thought it might be just AD mod, but it's id1 too, as I was getting framerates of only 100 in areas with a wpoly count of 1000, which isn't normal (I usually cap at 72 obviously; just host_maxfps 250 to test). Input latency felt worse in both OpenGL and dx9. I can measure that again with a high fps camera if necessary, but I'm pretty sure about it. 3. Engine still seems to start fullscreen borderless in dx9. 4. On shadows - it's nice to have another method, and they do look a bit better than standard glQuake ones certainly, though I agree with others in that my tendency is to use no shadows rather than ones which frequently display in weird ways. I'm aware that mh pointed out that blob shadows have the same issues as the ones currently present, but in some ways they are less conspicuous in their flaws, simply as a result of being smaller and not projecting as far. They also serve a useful gameplay purpose in aiding depth perception, especially when using rockets to fire at the floor. I don't remember those in Quake 3 having glaring flaws, and FTE has its own blob shadows that seem to work very nicely in my experience. I'm also kind of curious about how games like HL2 did its shadows (the first game, not Episode 2 and later versions of the engine that added real-time shadows from flashlights etc). That game relied on lightmapping and yet had pretty good projected shadows for characters and props. They weren't flawless and did clip through [i]very[/i] thin walls in some circumstances, but they were generally very good. 5. Multisampling - I'd certainly defer to mh if he feels it's not worth the hassle in D3D. I did use it without issue in DirectQuake, though that is only a data point of 1. If you were to consider implementing it in OpenGL, I suppose the arguments for it vs using simply using very high resolution would be firstly, performance, and secondly the fact that not everyone will have a high res monitor to run 4k etc, with downscaling tending to produce a blurrier image. If you're going to support dx8, you may as well also cater to those who have older monitors. I don't mind either way, just discussing the hypotheticals really. Maybe the solution to this is to have the engine reset gl_anisotropy to 0 or 1 if gl_nearest is activated for the DX9 version then, and maybe print something or notify the user.
[@fifth - Yeah that is what I decided
Mark V dir command - an obscure feature In Mark V, the dir command will list all the files in the current Quake folder (recursively) and sum the sizes. Examples: 1) dir 2) dir retro*.bsp // Find map beginning with retro 2) dir *.tga 3) dir "*.tga;*.png" // semi-colon requires quotes 4) dir a?*.* // ? is means any single character 5) dir *a*.* // Anything with an a in it 6) dir "<reject>*.dem;<accept>*.*" // list all files that are not demos The above system is kind of a byproduct of the auto-completion system. The auto-complete abilities need to be able to filter through lists of files with Gunter-like pickiness to match the ones that apply. /End obscure feature I have started a list of Linux issues and feature requests (and observations?), available upon request :P
Don't want to just dump more stuff onto your pile, though. And it will probably mostly be stuff you know about already... THERAILMCCOY, I can only replicate the issue you are having (starting in borderless fullscreen window rather than true fullscreen) when I start with command line options like:
DX9_Mark_V -width 1024 -height 600 Normally if I exit the game when running a fullscreen mode, it starts up next time in that fullscreen mode.... If I use the above command line, it starts up in the borderless window mode every time (or a bordered window if I'm setting like 800 x 600). -fullscreen command line option doesn't help (if that's valid). But if I also add autoexec.cfg settings like you described (vid_width 1024; vid_height 600; vid_fullscreen 1; vid_restart) then it correctly sets me to true fullscreen mode... Dump away. I want to know what works well, what doesn't work well, etc.
I may not be able to act immediately, but when I know about things it helps plan. GL_NEAREST modes and anisotropic filtering
This is one of those cases where you have to balance correct behaviour vs expected behaviour. D3D doesn't allow you to have both set at the same time. Previously I had erred on the side of anisotropic filtering as the expected behaviour. I was wrong. If people set a GL_NEAREST mode it's because they want crunchy pixels, and anisotropic filtering be damned. I'm prepared to be pragmatic about this. I've a coupla things to test but if it turns out to be the case that GL_NEAREST needs to take priority, then so be it. Multisampling Some day I'm going to work through this and see what's reasonable to do. The fact that I haven't done so yet doesn't mean I'll never do so. This is one of those "API differences" things. GL lets you throw some numbers at it and the driver does the right thing. D3D exposes more of the ugliness that actually lies beneath the covers. Get it wrong in D3D and the driver will crash. I'm just saying that it's much more work than people probably realise. Off-by-1 crap In my own tests this only seems to happen in the menus. I set gamma to 0.7 and press ESC to toggle the menu. You can clearly see the rendered frame shifting. This makes absolutely no sense whatsoever to me. I still suspect GL_SetCanvas though. Borderless modes The wrapper actually always starts up in a borderless mode and then switches to proper fullscreen as soon as Direct3D is initialized. This was very deliberate and intentional. This behaviour is required by DXGI on Vista+. If anything goes wrong during startup you get to still have control over your desktop this way. It plays nicer with other programs that may be using the graphics hardware. This one is non-negotiable. If there are glitches as a result I'll make a best effort to fix them, but the behaviour itself is not going to change. Issues:
1. gamma and contrast appear to do nothing (No big deal in my case, cos I have a desktop workaround). 2. Toggling external textures in windowed mode crashes cleanly to desktop. 3. When I go fullscreen, it always reports that it has set Quake to my desktop resolution (1680x1050), and refuses to stretch out lower resolutions to full screen. Not sure if by design, but frankly, it's so fast that I'm not sure it matters. Requests: 1. support for 6+ mouse buttons (seems limited to 5 right now). Not sure how mwheelup and mwheeldown factor in, so I might need up to 10? 2. MP3 emulation of CD music (Is it missing in Linux, or do I just need a workaround?) 3. "Restore" printing of console messages to Linux terminal too (minor, but would be nice). This is something that crops up from time to time. "How come HL/HL2 can do XYZ but Quake can't?"
On the surface it seems reasonable. Both HL and HL2 are ultimately derived from Quake. The difference isn't technology. The difference is content. If you're starting from scratch with entirely new content you get to be able to say things like "brush models don't exist" or "I only have one directional light and that's the only light that casts shadows" and whole classes of problems just go away. If you're retrofitting new technology on existing content you often don't have that luxury. As always, a best effort will be made, but Thou Shalt Not Break Existing Content. vid_hardwaregamma 0 should give you control over gamma/contrast. Use the "txgamma" console command to change gamma. I haven't taken the time to fully integrate it into the menu.
mp3 music. At the moment, no Linux music option. I've had my eye on a few different methods including what VideoLAN does to unlock mp3 hardware accelerated decoding on Linux already built into your processor (Intel, AMD, /So the quick ones are out of the way ;-) From what I've read, only the video decoding part of video playback is hardware accelerated, since it takes very little CPU power to decode mp3, but I am curious anyway. Some link dumps:
https://trac.ffmpeg.org/wiki/HWAccelIntro https://www.remlab.net/op/vlc-vdpau.shtml https://en.wikipedia.org/wiki/Video_Acceleration_API Wonder if gstreamer would be an option? It's a big bloated API, but I think it handles sending audio to the OS mixer itself.. so maybe you could get away with no changes to the Quake sfx mixer. Wouldn't be great for Mac though as it's more of a Linux library. txgamma works!
IDK if this helps at all, but Darkplaces for linux has working MP3/CD audio. I tried doing "dir" just to see it...
YIKES. I'd say it's a bad idea to do a complete listing of every file contained in every subfolder in the current directory... (I have a lot of content folders in my fvf directory...). Make it like DOS does. Only show the names of folders, and not a full directory listing of each of those subfolders. Also, just thought, can that fugly fog fix (and other stuff) be applied to the DX8 build? Some, but not all, could be applied to DX8. I'm not sure there's any really huge need to, however.
The "fugly fog fix" isn't a one-line-of-code thing.
It means implementing GL_COMBINE modes, close on 100 lines and a complete re-architecting of how texture environment modes work. Then you get to do the one-line-of-code thing. Given that the DX9 build will run on downlevel hardware I don't think it's a productive use of time. Then perhaps have this work so that whatever is set last take precedent. So if anisotropy is already set and then nearest is chosen it undoes anisotropy. And vice versa, that way you get a visual feedback back that you can't have your cake and eat it
At least from my point of view that seems like an improper request.
Let's focus on the future. There is only so much time in the day, let's use it wisely. iirc nearest+anistrophy is undefined in opengl, so fte only enables anisotropy with mag=linear so you know what you're going to get.
should probably force mip filters too... :s GL_EXT_texture_filter_anisotropic
GL actually does define GL_NEAREST + anisotropy, but it modifies the behaviour of GL_NEAREST from being a "crunchy pixel" mode to being a "select the type of anisotropic filtering used" mode. The extension notes that such hardware actually does exist. Maybe it did back then but I'm not certain that it does any more. Cross-checking this extension with FitzQuake's checks for anisotropic filtering, I'm not sure what the intent behind the latter is, but the extension notes that 2 is minimum value so it would be sufficient for FitzQuake to just check for 2. Setting to 1 disables anisotropic filtering. I'm not sure how well-known that is; disabling anisotropic filtering is a value of 1, not 0. Setting to 0 will actually throw a GL_INVALID_VALUE. D3DTEXTUREFILTERTYPE enumeration Direct3D 9 doesn't clearly define how anisotropic filtering works at all. You need a bunch of trial and error to figure it out yourself. It does state that you cannot set an anisotripic mip filter, but you also cannot set an anisotropic mag filter - the D3D debug runtimes will throw "unsupported mag filter" errors. So anisotropic is for min filter only. Setting max anisotropy to any > 1 value without also setting the min filter will not give you anisotropic filtering. Setting mag filter to point/nearest and min filter to anisotropic will actually give you a blurry mag filter. What a mess. Decision time I'm going to do the same as Spike and only enable anisotropy with mag filter = linear. It's clear from upthread that expected behaviour is "if I ask for crunchy pixels I want to get crunchy pixels". I think setting them in the order that commands are issued is just going to create a mess that will eventually explode in your face. I do understand the visual feedback element, but that only applies if you're entering commands manually in the console. Whatever is chosen must also give expected behaviour with config files. The OpenGL build should also fail because this is common to both.
I'll override ChoosePixelFormat for DX9. FitzQuake's GL_SetCanvas (CANVAS_MENU) was leaving the viewport smaller than the full render target when doing the gamma/contrast pass. That's what caused it to be off-by-1 and that's why I saw it shifting while toggling the menus.
I've a nice body of fixes built up again now so may do another code dump soon. Thanks for the shadow explanation, mh.
Gunter - I did stress that it seems to be in fullscreen borderless mode. It gives the impression of being so due to the appearance of a mouse cursor on the screen, that then goes away if I alt+enter. Once the game is definitely in fullscreen exclusive mode, alt+enter always triggers a switch to bordered window mode. Not sure if this was of any use to determine if what you describe in comment 991 is working correctly, mh. Regarding the OpenGL performance issues I mentioned in comment 985 - it seems they actually started appearing from 125 on. I tried a few builds prior to that - 1001, 1016, 1017, 1019 (1019 being the last Windows OpenGL build I could see before 1025) - and they all performed well on ad_swampy. 1025 + 1028, the 2 Windows OpenGL builds I could see since 1019, both peform very poorly on the same map. So I'm testing LAN play at the moment!
It seems I have to connect using the connect command with IP addresses. I have tried using the 'local search' function but it doesn't seem to find the games being hosted. I'm not an expert on LAN stuff so maybe I am missing something important? Also, I wanted mirrors. You can fake reflective water, a mirror teleport, you can do a lot of cool stuff... =~) So happy now.
1) See post #8 in this thread http://celephais.net/board/view_thread.php?id=61375&start=8
Computer #1: In console: maxplayers 4; coop 1; map start Computer #2: In console: connect lan // you're done! 2) @breezep - What are your computer specs? Like operating system, video card. I would guess that the DX8 build is a sure thing, but I would think all of them should work so this bugs me. 3) @rail - This bugs me just a little. I'll have to check and see what I changed since 1020 in the Open GL, but its not been anything deep. The 'dir' command seems to work fine, lists all the files inside the current game directory and its sub-folders.
The other commands you listed all seem to work fine too, though they only apply to the game directory itself, not its sub-folders (ie id1, but not id1/maps). So one can find *.pak but not *.bsp, for example. Not sure if this is as intended. It's actually a potentially handy feature if you have a ton of maps inside a folder but can only remember a partial name for one. Quicker than scanning through the results of 'maps' command anyway. The ultimate would be a dir type command for Quaddicted files. =) Bloom
I just wanted to see what this would look like. Almost requires darkness and a base map with bright lights. Medieval wouldn't be a fit. I was engine-mining and this wasn't what I was after, just incidental (what I was after is rather obscure and is likely on the verge of forgotten). It's been assimilated, although the code is not exactly efficient. I was engine-mining and this wasn't what I was after, just incidental
I would stay away from engine-mines that contain bloom. Apparently such places are known for motion-blur cave-ins, and also contain noxious quantities of chromatic aberration gas that can cause explosions of film grain and vignetting. I hear, however, that there are mines out there with much better health and safety rules that contain copious deposits of framerate independent physics. http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-15.zip
Several fixes and improvements, including: * GL_NEAREST takes priority over anisotropic filtering. * Off-by-1 crap with gamma != 1 in the menus is fixed. * Performance improvements in texture loading and mipmap generation. Are all features born equally?
FitzQuake has fog, coloured light, external textures, interpolation, skyboxes; none of which were in 1996 Quake. FitzQuake was never claimed to be "faithful to 1996". http://www.celephais.net/fitzquake/ My primary focus is fixing a lot of the rendering bugs which made glquake inferior to the software renderer. My secondary focus is adding conveniences for mappers and general users. I am also slowly adding support for new modding or mapping features such as skyboxes, fog, and colored light. I did make an assumption that the engine goal was to modernise while retaining the original games feel. I assume that Baker would try not add too much bloat
I'm trying to get my head around something in the shadow volume code.
I can reproduce test cases where they do and where they don't leak through geometry. What I need to figure out is: is this happening because the volume isn't projected far enough (only 512 units) or is it happening because the draw order is significant? If the latter then shadow volumes may be about to become about 2 billion times more robust. One of my goals is acquire key features from great engines of the past
The authors contributions to Quake lives on And the unmaintained binary form of their work can rest in peace. There have been several dozen brilliant engine authors who have made great contributions, often adopted by other engines. Engine developers tend to have awareness of this kind of thing. Maybe it is extended form of developer courtesy saying thanks to them. Perhaps similar to how the best mappers are very aware of great mapping innovators of the past. Build 1029 - DX9 enhancements only
mh tuning of DX9 - "Crunchy pixels" gl_texturemode GL_NEAREST should just work now. - Should resolve a PixelFormat issue in some situations (breezeep) - Faster mipmap generation for some setups (gunter) - vid_hardwaregamma 0 (dx9 shader gamma) scrunched pixels fix. I quite liked how pre-1029 dx9 builds provided smoothed console text with 'gl_texturemode linear_mipmap_linear' and gl_texture_anisotropy set to any value above 1. It ensured improved legibility. Is the loss of this smoothing simply an unavoidable consequence of ensuring gl_nearest works as expected?
1028 - https://imgur.com/DZBpFVQ 1029 - https://imgur.com/wHUWGo9 Looking good. Previous issues are indeed resolved (distorted text fixed, longer loading times gone).
The following issue still remains, and did not appear until DX9 1.26 borderless full-screen windowed mode (at your desktop res) only works if that mode was set before starting up (set from a previous run, or by command line) [**let me refer this this as Situation A] Attempting to change to that mode after starting Quake (even just by toggling alt-enter twice) produces a bordered window, which obviously doesn't cover the full screen. Ah, I see this also happens in the Windows version, but that has probably always been the case for that version, and that applies even if the setting was made before startup. **Hm. and it looks like alt-tabbing away from Situation A is touchy.... Sometimes it seems to freeze up, and Quake never comes back (not even any menu sounds)... and I have to close it by right-clicking it in the taskbar. It doesn't happen every time I alt-tab, but it seems like about a 50% chance of it happening. Alt-tabbing in true fullscreen works fine, as does it when using the bordered window. But alt-tabbing in Situation A seems to behave as if it's full screen -- the Quake window seems to minimize, whereas alt-tabbing from a bordered fullscreen window leaves the window behind whatever I have given focus. THERAILMCCOY, try alt-tabbing a few times when you start up in the borderless window, just to see if this also affects you. @gunter - Glad to see loading times for you are fast again.
@railmccoy - In your 1028 screenshot, Mark V at least with automatic 2D scaling enabled shouldn't allow "smooth text" (I'd be a little surprised if the Open GL version behaved the same). The super-crisp text like in the 1029 screenshot is how text in Mark V is intended to be with automatic scaling. I suspect viewport MH's fixes caused that to go away. Although it sounds like you thought of the smooth text in your 1028 as a feature, although my intent was integer-only scaling ;-) /If you are not using automatic 2D scaling, then the above wouldn't necessarily apply. /Forgot to add: source uploaded to usual folder where the download lives. Wanted to check all the builds before uploading to ensure they still compiled.
Pre-1029 it seems to smooth text regardless of the value scr_scaleauto is set to - 0, 1 or 2.
scr_scaleauto 0 - https://i.imgur.com/GpbB9P6.jpg scr_scaleauto 1 - https://i.imgur.com/ei9oAMk.jpg All my scr_ settings are included in the above images. Also, yes, I've only seen this in dx9, it never appeared in dx8 or OpenGL. It did sort of feel like a feature, yeh, in fact I think I've seen cvars in other Quake engines for controlling the smoothness of console text. Gunter - I can't reproduce alt-tab issues in the scenario you describe. @rail - yeah, I get that and I've had smooth text in other engine projects. But wasn't intended here as I hope to at some point in the future have integral scaling in the WinQuake build (but it's rather low priority, especially since Mark V WinQuake's stretch mode in video options to some extent provides a similar flexibility).
mh closed the book on that with the latest DX9 fixes in 1029. The other flavors of Mark V are good, hope I'm not reporting something that is known or ongoing ;)
Arcane Dimensions start.bsp - alpha masked vines screenshot
DX8 screenshot start.bsp, which has no combine DX9 screenshot start.bsp Arcane Dimensions 1.50 download link: https://www.quaddicted.com/filebase/ad_v1_50final.zip 1) c:/quake/dx9_mark_v.exe -nocombine (perfect!) 2) c:/quake/dx9_mark_v.exe -nomtex (perfect!) 3) c:/quake/dx9_mark_v.exe (doesn't look right If I type r_fullbright 1 in the console they become proper masked textures. Typing fog 0 or gl_overbright 0 or gl_fullbrights 0 appears to have no impact. ----- So it looks related to combine + multi-texture + lightmaps. It's a very complicated case. The one thing that always annoyed me about QMB -- which has effects for many things --- the Enforcers had no laser effect.
YouTube - Laser Effect in upcoming build Modelled a bit after AMFQuake, which is a forgotten engine. Alpha masked textures must have always been there in prior versions. Or at least I don't understand how the latest wrapper changes could affect it. It sounds like a combine alpha mode is not set up correctly. Combine RGB is, that would be immediately obvious.
Sharp text actually goes back to original GLQuake, and was retained in Quake II. I believe the reason is technical rather than aesthetic: adjacent characters would bleed into each other with bilerping. Nonetheless, it was a very deliberate feature of the original code. My gut instinct on this is that it is probably not a wrapper issue.
I'd make the assumption that it isn't a wrapper issue until there is evidence that it is a wrapper issue. I couldn't say with any level of confidence that the engine is hitting those draw functions in the same state every time, because there is no state manager. Nor could I say for sure that everything that should be set, is being set. Remember in prior time when the DX8 wrapper was new and you tested it on TyrQuake and discovered there was glPopMatrix with no push in the code (or something to that effect)? Is something like that happening here? It is possible. I always assume something "not known to be under quality control" should be assumed to not be under quality control. It's possible that the bug is outside the wrapper although I'm not 100% clear on that owing to the following:
* I only see comparison screnshots with DX8 which didn't have combine. * I only fixed the wrapper bug where combine wasn't reported for PS2.0 hardware quite recently. So I consider there being some likelihood that it is in the wrapper. If -nocombine fixes it and if it's related to alpha masking, then alpha combine modes seem a possible first port of call to me. Does anybody have a good test map for these? Preferably something that doesn't require BSP2 or a custom progs? Here is a bsp that'll load in Fitz 0.85 without a progs.
http://quakeone.com/markv/media/start_ad.zip You'll have to noclip up the vines. I played around with the function in Mark V's gl_world.c:R_DrawBrushModel_DrawSequentialPoly if (renderer.gl_texture_env_combine && renderer.gl_mtexable) section And made a number of attempts to explicitly set everything and it looks like somehow D3D isn't honoring the GL_ALPHA_TEST on first texture in the combine. somehow D3D isn't honoring the GL_ALPHA_TEST on first texture in the combine
This is what I suspect, yes. The combine mode should be passing through the alpha channel from the diffuse texture to output, ignoring the alpha channel of everything else. It looks as though it's configured to not do so. Perhaps passing through alpha from the lightmap texture instead, although without a closer examination of the code it's only speculation. tmustate_t doesn't look like its initialising the combine_alpha.
which means that tmu0 == disabled, instead of selectarg1(texture) you can probably fix it by overwriting its non-defaults with the following in the engine: glActiveTextureARB(GL_TEXTURE0_ARB); glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE0_ALPHA_ARB, GL_PRIMARY_COLOR_ARB); glTexEnvi(GL_TEXTURE_ENV, GL_SOURCE1_ALPHA_ARB, GL_TEXTURE); qglTexEnvi(GL_TEXTURE_ENV, GL_COMBINE_ALPHA_ARB, GL_MODULATE); the proper fix is of course in the wrapper. After doing what Spike said about setting GL_SOURCE0_ALPHA_ARB and GL_SOURCE1_ALPHA_ARB
I built the Open GL build on accident. Yeah, the wrapper isn't aware of those constants.
Quakespasm in AD 1.5 randomly changes my average fps between 10 and 30 when doing nothing at ad_start. Will this solve such problems?
Specs: Underclocked Celeron N2806 with Bay-Trail iGPU. Aero disabled in W7. Maybe I should whine in QS related threads instead. I suspect that QuakeSpasm will run faster for a number of reasons.
Story from ancient history. One of the reasons why I moved to D3D9 originally was that I was fed up of poor Intel driver quality (the other reason was to stop people behaving as though they had a god-given right to demand Linux builds but that's another story). The thing I found however was that, if you write your OpenGL code in a similar style, you'll actually get the same end result. Faster, more stable prformance. The trouble with Intel drivers was actually programs doing horrible things that NV and AMD were more robust with. But the things that programs did were still horrible: writing to the front buffer, GL_RGB texture formats, lots of tiny lightmap updates. QuakeSpasm has picked up lots of my old code (or code similar to it) that actually resolves many Intel problems. Example: QuakeSpasm draws directly from vertex buffers whereas MarkV via the D3D9 wrapper needs to shuffle data around in memory and mangle it from glBegin/glEnd calls to something D3D9 can use. That's a lot of extra overhead that QuakeSpasm just doesn't have. Intel Bay-Trail is a DX11-class iGPU and QuakeSpasm is capable of taking advantage of newer API features to run faster and more stable (it's a complete fallacy that older API features are more low-end friendly). MarkV doesn't even try. For sure download it and try it though. I'll have to dig into this one, but if I press the Windows key + D (show desktop), DX9 does an error ResetDevice::failed.
A bit odd since minimizing the window by clicking minimize doesn't have a similar issue. I'll have to dig into this one, but if I press the Windows key + D (show desktop), DX9 does an error ResetDevice::failed
Windows-D seems to have different behaviour to minimizing. Specifically, Windows-D sets the window client rect to 0/0/0/0 so it looks as though device reset is failing by trying to create a 0-dimension back buffer. You can add code to check for attempted mode changes to 0 width or 0 height and just not change the mode if detected; that should do it. Just stepping through a frame in PIX to determine states/etc when drawing a '{' texture, and came across something fairly astonishing.
About 80% of the Direct3D calls in a frame are spent on sky. It's clear what's happening here: the FitzQuake code is changeing state after each quad used in the sky render, so D3D is unable to batch. I'm going to rewrite this a little to be significantly more efficient and it should hopefully be easy enough to pick up in MarkV. Meantime back to PIX traces for '{' textures.... You may already have this fixed, but I'm finding it useful to step through the calls made and textures used and get a full picture of exactly what's going on.
It's also good to have a record of problems hit and bugs fixed along the way. FitzQuake is incorrectly identifying palette index 255 as fullbright. This needs fixing in two places: first in the check for fullbright texels (add a continue if we find index 255), second in the actual palette building (revert index 255 to being alpha rather than solid black in both the fullbright and nobrights palettes). The first fix will get the general case of most '{' textures. The second fix is needed for '{' textures with fullbright texels. Quakespasm in AD 1.5 randomly changes my average fps between 10 and 30 when doing nothing at ad_start. Will this solve such problems?
This must be lightmap uploads. If I turn on "r_speeds 1", every 5-10 frames there are 5 lightmaps updated from the flickering torches. However, when a lava ball pops up, that causes 5-10 lightmap uploads every frame. QS is using GL_RGBA / GL_UNSIGNED_BYTE for lightmap uploads, iirc MH reported that BGRA and/or the unsigned int 8888 format are needed for faster uploads on some GL drivers. (our batching of uploads is also slightly weird... QS does all uploads for the world, then draws it, then for each bmodel it does the lightmap uploads, then draws the surfaces) let's continue in the QS thread, if you don't mind trying a test build or two we can probably improve it. Btw how does MarkV GL perform for you? Alpha mask textures are now fixed.
It turns out that D3D texture stage state defaults (which I was setting) are slightly different to GL combine mode defaults (which I wasn't). A bunch of glGetTexEnv calls in a GL engine and I had the correct defaults, then set them up, and everything works. I'm going to wait a day or so before doing a code-drop in case anything else comes up. Yeah, the sky is slow. ;-) I know. I know that you wrote several sky speed up tutorials in the past (Z-fail skys, etc, etc.) . ;-)
Also frames per second is funny topic. Quakespasm gets a large speed boost from using vertex arrays. In highly complex scenes, it gets a lot more frames per second. With gamma 1 and contrast 1. Then cashes in much of the gains via shader gamma (33% fps loss sometimes) that gets more expensive the higher the screen resolution Somewhere in a thread, ericw and I once discussed this topic and I raised the theoretical idea of real-time changeable texture gamma. Which of course is now a Mark V feature, one that gunter thinks looks better than hardware gamma or shader gamma. So what on the surfaces looks like apples and apples, is more like apples and oranges ;-) It's not a straight road, but more of a curvy road. And engine coding is mostly about pioneering new ideas and having fun. Any code that I write, I hope someone takes that and uses it --- qbism added automatic underwater transparency from Mark V last year, for instance, I told him how it worked and where to look. I coded the texture gamma system in Mark V to see what it would look like, after the insideqc discussion ericw started and also see if it could be done. However, when a lava ball pops up, that causes 5-10 lightmap uploads every frame.
I love you how you worded that ;-) Lavaball shows up, ruins the day. FitzQuake is incorrectly identifying palette index 255 as fullbright
Keep in mind that color 255 is standard Quake is, in fact, a fullbright color. The Kurok engine that I once used to enjoy playing around with forced 255 to transparent full-time. And when playing standard Quake with that Kurok engine --- would notice maps and mods that actually used color 255 in textures. Particular if you hit up conversions http://www.quaketerminus.com/addon.shtml At the time, that discovery was a real kill-joy for me. Because I loved alpha masked textures and the Kurok's simple treatment of all 255 is transparent was easy as newbie engine developer to work with So let's just say I was disappointed when I found actual maps and mods using color 255 on purpose. Hm, I was just comparing FPS in various builds....
I found I am getting significantly better FPS in DX8MV than in DX9MV, which I think is mainly because my FPS drops significantly when I use gamma or contrast, and this affects DX9MV much worse than DX8MV. And it looks like DX8 1.28 really improved my FPS by like 15-20 points over the previous DX8 1.25 release (and earlier builds)... although the txgamma looks darker/uglier/washed-out starting at 1.28 Just standing in the start map facing forward, 800x600 window, and vid_hardwaregamma 0, mirrors off (and freezeall to prevent lava balls from affecting it): DX8 1.25 no contrast adjustment = 74 FPS with contrast adjustment = 70 FPS turn and face wall, no contrast = 125 FPS facing wall, contrast applied = 114 FPS DX8 1.28 no contrast adjustment = 91 FPS with contrast adjustment = 86 FPS turn and face wall, no contrast = 142 FPS facing wall, contrast applied = 130 FPS DX9 1.28 no contrast adjustment = 90 FPS with contrast or gamma adjustment = 55 FPS turn & face wall, no contrast/gamma = 150 FPS facing wall, contrast/gamma applied = 100 FPS So, yeah.... With the previous DX8 build I could just use txgamma and even a little contrast and the FPS would be decent. In the new DX8 1.28, the txgamma just doesn't look good, but darn, the FPS is better! What did you do, Baker? In DX9, I must use gamma so I get the bad FPS hit. Oh, I guess I do have another option: I can use vid_hardwaregamma 1 and then my FPS is no longer affected by adjustments..... But my desktop is. In that case I get pretty much the same performance with DX8 and DX9, though DX9 does 8-10 FPS better when I'm facing a wall, heh. Eventually DX9 will have texture gamma.
I would conduct the DX8 vs. DX9 speed comparisons using vid_hardwaregamma 1. Otherwise, you are throwing an unfair speed penalty on the DX9, because shader gamma isn't free. Also, the start map isn't a good choice of maps.
DX9 supports mirrors. DX8 doesn't. The mirror draw is expensive, haha ;-) I also have a lot of I's to dot and T's to cross.
I'll check out whatever I did in DX8 1.28 that affected txgamma appearance. @gunter - DX9 1029 build is current one. MH did a lot of fixes based on your comments.
"The one thing that always annoyed me about QMB -- which has effects for many things --- the Enforcers had no laser effect.
" Ya I added an effect to the enforcers and those laser, though I like the little lines around the effect of AMFQuake... btw speaking on QMB effects Ralf and I added the lightning effect which JoeQuake added later, just the image/splash not the cl_true_lightning. (i cant remember Ralf's Quake name hmm).. Mark V - 1030 Beta Build
- QMB Enforcer Laser when QMB is enabled Lasers video - Bloom option in only Open GL build (r_bloom 1) Bloom Video - DX9 alpha masked textures temp workaround until mh patch r_bloom 1 doesn't save to config. I view bloom as a bit of novelty. It is also a performance killer and I think the code is probably inefficient -- but since its a toy around feature that's ok. Tonight, might see if I can resolve some of the issues others have noted and maybe get out a 1031 build. And if mh has a patch tomorrow, do that. Then comes an extended break with the hopes that will be able to do more updates in the spring some time. Ah, I had no idea you did that in Qrack.
Do you have a link to your current source code? I'd like to compare notes. The lack of a laser effect always ticked me off about QMB, haha. But until very recently, didn't have an engine with QMB available, so never thought about it. Re-reading
http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-17.zip
Then comes an extended break with the hopes that will be able to do more updates in the spring some time. I guess a code drop is in order then. This one includes: * Alpha mask texture fix. * Sky polygon batcher. * Guards against 0-dimension video modes. if you compare jq0.13dev to any qrack you'll see what's diff, that was the base i started on; and the first file I focused on was gl_rpart.c ;)
1) MH's revised sky draw is a pretty decent speed boost for the scrolling sky.
2) I needed to know whether or not MH was right about color 255 not supposed to be fullbright. Original WinQuake color 255 In the above screenshot, notice I took care to stand next to a wall with lighting. The brownish color on the walls is color 255, which is surrounded by fullbright white (color 254) and the black area is non-fullbright red (color 79). Color 255 isn't generally a very useful color. It is rarely used. But in WinQuake it is acting as a fullbright color. I haven't checked but I have a good degree of confidence that the colormap has it as a column of 255. So from the perspective of the colormap it is fullbright and I'm probably wrong.
Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture. It's also the case that in all of ID1 no BSP texture uses index 255 (I checked). There's also this in the colormap generation code in qlumpy (https://github.com/id-Software/Quake-Tools/blob/master/qutils/QLUMPY/QUAKEGRB.C#L233): note: 254 instead of 255 because 255 is the transparent color, and we don't want anything remapping to that So I can say with a good degree of confidence that even though 255 is represented as fullbright in the colormap, it is not intended to be actually used for anything other than transparent. Where things get tricky is how you interpret index 255 because '{' textures should be able to have fullbrights on them too, and 255 cannot be both fullbright and alpha in a '{' texture.
I think it has to be transparent, otherwise fence textures would cease to exist as a feature. Since it's transparent, it should not be added to the fullbright mask. And alphaedgefix should be used to fill it in with neighboring colors. On non-fence textures, it should be fullbright since that is how it works in all versions of the game (software and accelerated) that support fullbrights. @mh - It disturbed me that such a behavior difference occured.
I wanted to know exactly why Windows + D caused a problem. Here is the reason. Dumping system messages: WM_WINDOWPOSCHANGING wparam: 0 lparam 18fab0 WM_GETMINMAXINFO wparam: 0 lparam 18f7b0 WM_NCCALCSIZE wparam: 1 lparam 18fa88 --------- (Windows + D show desktop, Quake will run a frame here because the message queue is empty -- we have not received a WM_SIZE message yet so we don't know we are minimized.) --------- WM_NCPAINT wparam: 1 lparam 0 WM_GETTEXT wparam: 1fe lparam 18e580 WM_ERASEBKGND wparam: 5011197 lparam 0 WM_WINDOWPOSCHANGED wparam: 0 lparam 18f890 WM_MOVE wparam: 0 lparam 99016b WM_SIZE wparam: 0 lparam 1e00280 (Minimized runs frame here, we received WM_SIZE already so we are ok!) Beta Build 1031
1- Correct alpha masked texture support in DX9 2- MH faster scrolling sky rendering (DX9, DX8 and Open GL) 2- Resolves a DX9 + "Windows key + D (show desktop)" issue. Should have one more build later. Just been doing some testing comparing texture gamma ("txgamma") to shader gamma (which will have the same result, if not the same perf, as full-screen desktop gamma, which I didn't test).
Visually they're not identical. This should have been obvious, but wasn't, at least to me. With texture gamma the calculation is pow (texture, gamma) * lightmap With shader gamma the calculation is pow (texture * lightmap, gamma) Shader gamma feels more "right" because it applies gamma as a post-process after the entire scene is composited. You can't deny the performance of texture gamma, and it does give a richer look which can be more visually appealing. To make texture gamma give the same result as shader gamma, you should also gamma-adjust the lightmaps. pow (texture, gamma) * pow (lightmap, gamma) because exponents are distributive over multiplication. Thanks for the calculation comparison analysis.
Yeah, texture gamma and shader gamma have differences. You'll notice Gunter perspective that the polyblends look better with texture gamma. Meanwhile, I wonder about transparent brushes/models which is a "double application" scenario with texture gamma. Ironically, with texture gamma, I had to modify the FitzQuake texture manager to be aware of textures intended for blending and exclude them from texture gamma (example: the optional QMB particles are blended) to avoid "double application" (although I doubt the final color is technically "gamma-correct" according to the calc). I'm not all that caught up in this topic.
I think frames per second is important, but I also think fps above 72 in single player is a bit superfluous. Because Quake physics acts up around 250 or 300 fps (killer lifts, missed triggers on maps like E3M2. 144 fps Anyway, like I said, I'm not caught up in this Here is Mark V DX9 and Quakespasm (Mark V Open GL would lose substantially). Quakespasm is set to gamma 1 and contrast 1 to keep shader gamma out of the equation. But we'll have mirrors on in DX9 just too give DX9 some extra work to do http://quakeone.com/markv/media/dx9_and_quakespasm.jpg For fun, here is Mark V DX9 and FTE. DX9 Mark V is using external textures. Spike's FTE is probably the fps champion of all Open GL engines. http://quakeone.com/markv/media/dx9_and_fte.jpg MH's DirectQ? Yeah, DirectQ smokes all of the above in a curb stomp which not even close. http://quakeone.com/markv/media/directq.jpg My Win 7 laptop has rather modest specs, anyone with an actual "good" graphics card is going to see way higher fps than above. Anyway, anything above 72 or arguably 144 fps in single player Quake isn't too useful anyway. Has anyone ever tried to disconnect the rendering from game logic in Quake? I feel like that'd be a nice thing to have, then we'd be able to run at any FPS we liked and avoid the bugs mentioned above.
I also feel like it would be a giant pain in the ass to figure out and actually implement... DarkPlaces has it.
DirectQ had it with a tiny inconsistency that someone picky like me or Gunter would notice, otherwise I almost acquired it from DirectQ and inside Mark V is a partial implementation of retaining some of the improvements from the attempt (more consistent clock timers). All modern Quakeworld engines have it. FTE has it on steroids. At some point will happen in Mark V. Mark V 1032 Beta - Windows, Linux, DX9, DX8, Open GL, WinQuake
Source Code Features Vs. Mark V 1.2 - Very fast "triple the fps" DirectX 9 build courtesy of MH - WinQuake looking water warp in Open GL/DX9 (MH again) - Volumetric shadows - r_shadows 3 (MH again) - Sky speed up in Open GL/DX8/DX9 (Yeah, MH) - Linux Open GL build (thanks to JimBob for testing, Spike for debug tips) - Linux WinQuake build - Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded. - QMB enforcer lasers available video - Improved performance on NVidia cards - 2 Extra options in video menu for convenience. - Other things, no doubt. But what were they? Scroll back in the thread ;-) Hopefully resolved the remaining significant issues, like dwere's context creation failure message. Attempted to add texture gamma to DX9 and then ended up with a blank screen and plenty of wasted time, killing the opportunity to add true rotation and even get the Mac build running. :( Engine coding sucks like that sometimes, but I won't pretend to not be irritated about missing a few items I very much wanted to get done. /All feedback and any issues reported do get read. Next update is likely in the spring. In DX9 only, models with fullbright pixels still can't handle transparency (like an illusionary player model, or the gun view models except axe). gl_fullbrights 0 makes them transparent again.
Hm, there is still a big difference in the water warp effect in the Winquake version as compared to DX & GL. The Windows one just doesn't warp as much, and is less noticeable. Software Quake waterwarp is resolution-dependent. Run it at 320x200 and you'll see a very different effect to if you run it at higher res.
The waterwarp code I wrote is resolution-independent. IMO the software Quake behaviour is undesirable. More discussion, test cases, etc here: http://forums.insideqc.com/viewtopic.php?f=3&t=5827 You'll notice that my warp code reverses the X-axis direction but is otherwise good. That's something I intend to fix some day (the X-axis bit, not the otherwise good bit). Binaries still work on KDE without need for re-compilation.
The laser effect is neato -- kinda like they're being squeezed out of the gun. Would make for a decent "shooting star" effect. Might be nice if they could be toggled off for the player (like the FVF Laser Android class), while still being enabled for the enforcer. But not a big deal *shrug* Winquake crashes (seg. fault) when I try to drag-expand the window too much. Appears it may be trying to snap to fullscreen (like a snap-to-edge behavior). That doesn't bother me, though, cos I likely won't be using Winquake, and that's an easy situation to avoid anyhow. Otherwise runs fine. Anyhow, please ignore that until the spring. And thanks again for bringing Mark V to Linux. I will enjoy playing Quake with it in the meantime :) I had the same reaction as Gunter that the GL waterwarp effect has a surprisingly strong distortion. I guess I was used to running WinQuake at a non-minimum resolution back in the day.
It's not a big deal, but out of curiosity: how feasible is it to expose "warp amount" as a console variable? how feasible is it to expose "warp amount" as a console variable?
There are a few hard-coded numbers in it and I even have a comment on one of them: "tune it or cvarize it all you wish". I'm actually working over this code at present fixing up a few issues with it, but I don't feel that I'll be the one adding cvars: it's really up to Baker, how or even if he wishes to expose this. Hm, yeah, the FvF Laser Android uses the same laser-firing function as enforcers do, but apples various flashing colored skins to the laser projectile.
The QMB effect now has every Android laser shot look just like the enforcer's laser. And it really hits my FPS when firing the Super Spread Laser (8 simultaneous laser shots, heh). It's too bad the effect color can't be made to match the laser skin color.... I suppose a quick hack (which I'm not at all sure how it would end up looking, since the Laser Android does use the standard laser color too) might be to only apply the QMB effect if the laser projectile is using its default skin 0. Or I suppose have the effect only apply if launched by an enforcer, as JimBob suggested. Though I always thought the laser android could use some kind of QMB-type effects too (when such things are enabled).... OK, I'm pretty much done working over the code. It's a shame I didn't get this in time for Baker's release, so you're just going to have to be patient until his time frees up again.
Picked up the latest vkQuake code adjusting the water warp for screen aspect. Yes, my water warp code was based off vkQuake. Made it as close to consistent as I can get with Mankrip's tests at http://forums.insideqc.com/viewtopic.php?f=3&t=5827 Mankrip has criticised the vkQuake code before, but I think he's being unfair. vkQuake is actually 99% there; the only things it needs are a sign-flip ("(x - (sin (y" instead of "(x + (sin (y", likewise for y/x) and a tweak to the value of AMP (2/300 instead of 1/300). This is not based on any rigorous code analysis, just tweaking values until it looks right, but it's close enough for me. Mankrip's: http://www.quaketastic.com/files/misc/testing/waterwarptest_Retroquad_1280x960.png Mine: http://www.quaketastic.com/files/misc/testing/waterwarptest_DirectFitz_1280x960.jpg There's a bug where if you change resolution when underwater, water textures get turned to binary garbage. Don't bother reporting it - I'm aware of it. Oh my.... The Ninja also uses the laser model (skinned) for his throwing darts, heh... and now they look like laser effects in QMB.
for some reason waterwarp in both opengl and directx seems to be down-ressed? is that correct?
Yes, I downscaled it.
This is essentially the same kind of problem and same kind of tradeoff as we have with shader gamma. Because it needs to run as a post-process it's slower, so I downscaled it to compensate. It's a no-win situation because if I didn't downscale it people would complain that it was slow. My expectation is that cvars could be provided to tune the size, so that you could select downscaling or not, based on your own preferred tradeoffs (and hardware capabilities). But that's not my decision. For comparison, this one is full res: http://www.quaketastic.com/files/misc/testing/waterwarptest_DirectFitz_1280x960_noDownscale.jpg
Just kind of a note, anything that MH wants to do will end up being added to the engine when new builds happen again.
@gunter - if I would have known about the fullbright pixels + alpha, I could have coded a temp workaround. Spring will be here before you know it. Time flies. @Baker: twas reported above in #977 and verified by you in #978 ;)
I might have mentioned it again, but I was waiting to see if it would be resolved along with other transparency issues that were being worked on. It's not a big deal in any case. I would request that you make the most recent zip package available on the site at quakeone.com/markv since that's where I always send people to download it. The link here will quickly get lost in the posts on this page.... I know it's "beta" but it's still the best version so far, containing numerous fixes.... I also like having all the platform versions in one zip file. Ok, I see you did link to here at the top of the page on Quakeone.com/markv
Is it me, or are monsters sort of transparent to the sky?
Like if I look up through a monster at a sky brush, I can see the edges where the architecture meets the sky. http://imgur.com/a/hTQnc Not sure if I have some setting enabled to make this happen. Hopefully resolved the remaining significant issues, like dwere's context creation failure message.
The message is still there, I'm afraid. Verified: you can see the sky (kind of) through monsters, starting DX9 1.28
You can also see shadows through monsters, if r_shadows 3 @dwere
@gunter I am sort of mixed on doing that considering that dwere, as an example, has an issue and I'm a compatibility hawk and that's like a having a thorn in my boot. On the other hand, the current build solves compatibility issues on the other side of the spectrum (killpixel, johnny law, pulsar's machine presumably). /Grumpy cat face! I'll read the comments every once in a while, all feedback gets read, this Func_Msgboard is awesome in how the layout is conducive to that. I suspect you're actually using an older build.
In all of this I'm assuming that you're using DX9. In the most recent code I provided a replacement ChoosePixelFormat that never fails. I need to cross-check the MarkV integration of course, but it seems you're describing something impossible. Shadows through monsters with r_shadows 3 is a known issue, that's part of what I meant when I said "it's not robust" and "shadows leak through geometry".
If it can be fixed it will. If it can't be fixed you'll have to take it in the spirit of Carmack's original comment on GLQuake's novelty features: "not very robust but cool to look at". Let me know if these work and/or what happens.
http://quakeone.com/markv/older/1033_dwere.zip (Open GL, WinQuake version). If it solves your problem, I'll have a lot more piece of mind. Let me know! He was using mark_v.exe --- the Open GL.
In the above 1033 dwere test, I did 2 things: 1) I requested a 32 bit Z-buffer and an 8-bit stencil to mirror what Mark V 1.20 did. In later versions, I changed to Z-buffer request to 24-bit with 8-bit stencil. 2) Mark V Open GL will route around an opengl32.dll living the Quake folder, largely to avoid the GOG.com crappy one and the fact that a opengl32.dll in the Quake folder is almost always some 1997 relic. If that is what is going, the dwere build will do a messagebox saying that's what's up. Hm. it gets more interesting....
If r_shadows 3, then you can no longer see the sky through monsters. But that's when you can see shadows through monsters. It's not just shadows leaking through anything -- you can see the shadows through the monsters at a distance, in a very similar way as you can see the sky through the monsters when not using r_shadows 3.... I would suspect a relation, since both these issues appear starting in DX9 1.28, when the new shadows were added.... Yeah. Really I think it's more like the sky is shading the monster, rather than the monster actually being transparent to the sky. Er. It's confusing.
Shadows & sky is an understood problem.
Both have weird interactions with the depth/stencil buffer, and are therefore interacting with each other. Fixing individual problems as they occur is not going to solve this, so everybody - please stop reporting bugs with it. I know what the solution actually is, and it involves decoupling the shadow pass from the MDL passes so that the former can be done in isolation and without affecting other stuff, then figuring out the correct draw order placing for it (which will be one of two options). If you look upthread you'll see that I already said this, but in a bit less detail. Right now giving me the head space to actually do this is a lot more helpful than piling on the bug reports. Let me know if these work and/or what happens.
The same message appears, sorry. mark_v_winquake.exe works, but it always worked, unlike mark_v_winquake_gl.exe. @dwere what about the normal mark_v.exe? Does that work ok?
The mark_v_winquake_gl.exe is a discontinued experimental build, it's just like the mark_v_winquake.exe except it uses Open GL to put it on the screen. Interesting thing (maybe?) about build 1032.
Occasionally I use a Windows 10 VM on my Macbook to check out Windows things. I've run past mark_v.exe versions in there without problems. This one though fails to run, as does dx9_mark_v.exe. dx8_mark_v.exe and mark_v_winquake.exe work fine. This doesn't matter much to me since I don't actually play Quake on this VM, but maybe it's an indicator of something you might want to know about. So, FYI: mark_v.exe fails with this dialog: --------------------------- Quake Error --------------------------- Could not initialize GL (wglCreateContext failed). Make sure you in are 65535 color mode, and try running -window. --------------------------- (I did try using "-window" for the heck of it; same error.) dx9_mark_v.exe fails with this dialog: --------------------------- Quake Error --------------------------- R_LoadD3DX : failed to load D3DX Please update your installation of DirectX... --------------------------- This is a VMware Fusion VM, and in the Display settings under the "Accelerate 3D Graphics" switch (which is on) the description of that option says "Supports DirectX 9.0EX with Aero and OpenGL 2.1". Perhaps the wglCreateContext invocation in mark_v.exe has been changed to require something unsupported in OpenGL 2.1, and dx9_mark_v.exe is requiring something beyond DirectX 9.0EX? (It looks like if I were to spring for an upgrade to the latest Fusion version I could get better graphics API support, like DirectX 10 and OpenGL 3... hmm.) @dwere what about the normal mark_v.exe? Does that work ok?
I was talking about mark_v.exe when I said that the message still appears, so no. Oh hey I guess the wglCreateContext part of my post is the same thing that dwere was reporting. FWIW, the "dwere build" 1033 behaves the same way as 1032 in my VM.
The DX9 build requires the latest DirectX runtime installed. There are components of DX9 that were added in subsequent releases but which are not included in DX10+ on a fresh Windows install. This can be safely installed without affecting DX10+.
https://www.microsoft.com/en-ie/download/details.aspx?id=35 For OpenGL startup problems I suggest grabbing the OpenGL Extensions Viewer from Realtech VR. This is a great way of verifying your OpenGL driver. http://realtech-vr.com/admin/glview Down the left-hand side of the Viewer you'll see a list of links, with the top one ("Summary") selected. Please report what it says for "System Info | Renderer" and "OpenGL | Version". Third one down is "Display modes & pixel formats". Unfortunately they don't provide a way to search or filter these, but look for pixel formats with WGL_ACCELERATION_ARB set to FULL_ACCELERATION, WGL_COLOR_BITS_ARB 24 or 32, WGL_DEPTH_BITS_ARB 24 or 32, WGL_SUPPORT_OPENGL_ARB True and WGL_DOUBLEBUFFER_ARB True. Can either of you post a qconsole.log where the error occurs? Mark V automatically does a qconsole.log. I'm trying to walk through all the small differences between 1020 and 1025 builds.
OpenGL Extensions Viewer quits silently in the middle of loading extensions.
Maybe my system just sucks - I had to "temporarily" install a shady Win 7 distro with some features disabled. The list of disabled features looked innocent, but I had some video driver installation problems. In the end, I just reinstalled everything with a driver that I knew worked fine, and left it at that. All 3D games I tried so far worked fine, including Quake source ports (Quakespasm and mark_v.exe dated 2016/12/03). I tried to reboot from an old HDD with Vista installed, and the latest mark_v.exe started without any problems. But I have different drivers there. Can either of you post a qconsole.log where the error occurs? Command line: [ ] Log file: D:/Games/Quake/id1/qconsole.log Fri Jan 20 00:02:40 2017 Mark V Windows (Build: 1033) Exe: mark_v.exe (1327 kb) Exe: 00:44:32 Jan 19 2017 Caches: C:/Users/User/AppData/Roaming/Mark V/caches UDP4 Initialized: INADDR_ANY, 192.168.1.67 IPv6 Initialized: [fe80:0:0:0:9459:106d:2bee:97d8%12] Exe: 00:44:04 Jan 19 2017 256.0 megabyte heap Maybe my system just sucks
If an earlier Mark V worked, I'm not going to be happy until this one works. I did install DirectX June 10 SDK, which may have changed some libraries. Need to meditate on this a bit. Fitz 0.85 works fine on my XP VM but MarkV fails with the same error.
It's XP on a Windows 10 host, but I believe the core guts of the driver are the same: VMWare Tools provided Mesa/Gallium driver. I have a full development environment on this VM so I'll have the fix identified soon! Another thing going on here, you also have the problem with winquake_gl -- which doesn't even use Visual Studio to compile, it uses CodeBlocks/gcc/mingw and winquake_gl is an SDL build, so it uses SDL functions to set the pixel format and create the opengl context.
The DX9 version works after installing that runtime package.
In the OpenGL Extensions Viewer: - "System Info | Renderer" is "Gallium 0.4 on SVGA3D; build: RELEASE" - "OpenGL | Version" is "2.1 Mesa 8" - In the pixel formats, WGL_DOUBLEBUFFER_ARB is sometimes False, for some values of number in the spinner there (don't know what that number is). For 7-12 it's True, for 19-24 it's True, stopped looking at that point. For some of those, color bits or depth bits are 16, but others match all the desired values you mentioned. Let me know if there's other digging around I should do in the extension viewer. I copied the text from the Report pane to https://dl.dropboxusercontent.com/u/11690738/temp/extensions_report.txt qconsole.log from trying to run mark_v.exe: Command line: [ ] Log file: C:/Users/joel/Desktop/Quake/id1/qconsole.log Thu Jan 19 13:16:05 2017 Mark V Windows (Build: 1032) Exe: mark_v.exe (1327 kb) Exe: 10:00:00 Jan 18 2017 Caches: C:/Users/joel/AppData/Roaming/Mark V/caches UDP4 Initialized: INADDR_ANY, 172.16.229.128 IPv6 Initialized: [fe80:0:0:0:a48d:1a8a:5eb0:7e8b%8] Exe: 09:59:32 Jan 18 2017 256.0 megabyte heap Fucking awesome!!
Yeah, since I can't experience the problem firsthand, I'm not able to get my hands dirty as I would like. An obscure change is that current Mark V uses /J compiler option - make char be unsigned char.
Wanted to mention that, although I do not believe this relates to the issue. Another small change is that Mark V uses /DELAYLOAD:opengl32.dll
I can't see how that would relate to this, but anything is possible with something odd like this. It's because you're delay-loading.
See https://groups.google.com/forum/#!topic/comp.graphics.api.opengl/AVqQjWFAIBI for a prior example; wglCreateContext fails with error 2000 which is exactly the same as MarkV does. The quick 'n' dirty fix I did was to pop in this little line of code before setting up the pixel format: GetProcAddress (LoadLibrary ("opengl32.dll"), "glBegin"); You'll probably want to #define it for the GL build, but that forces opengl32.dll to be loaded and then everything works. Build 1034 with DelayLoad fix.
http://quakeone.com/markv/older/1034_mark_v_opengl.zip Let me know! Thanks! I put it just before the call to WIN_SetupPixelFormat in VID_Local_SetMode, but you could put it earlier if you wish.
I assume that you're delay-loading so that you can test for the 3DFX opengl32.dll? Maybe immediately after your test would be a good place. Do you need a new wrapper code drop for 1034 or would integration delay you at this point in time? I'm rather relieved that this obscure problem is resolved.
I hate it when I can't experience an issue. And this one ranked up there in the obscurity department. Fucking delayload. Beer for MH! http://www.quaketastic.com/files/tools/windows/engines/Direct3D9-Wrapper-2017-01-19.zip
It's just the underwater warp stuff so no sweat if you can't get it in. I'll be integrating it here in a few minutes. Probably within an hour I'll post 1035. Need to update a zips, installer, etc.
This issue being resolved gives me great peace of mind! @dwere - Awesome!
@fifth - Is there is any particular reason you want the WinQuake GL build? The pure WinQuake performs better. I dont think it did when I checked it last, weird...
You dont need to support it on my behalf tbh, I'm not likely to use it anyway I forced 640x480 stretch in WinQuake GL for higher fps than it would have had otherwise to somewhat compensate.
Still killpixel said every once in a rare while that it would stutter a little. one thing i have noticed recently on almost all Quake engines, is if I specify a full-screen resolution that is not the monitors native (1920x1080) there is a black border around the screen. So it looks like a 640x480 window ontop of completely black desktop. At first I thought it was a Qrack issue, but MarkV does this too. So i think it's an nVidia/Windows 10 thingy. My windows xp machine doesnt have this effect.
Any ideas? http://i.imgur.com/KpBMXGz.jpg
its a setting in the control panel now, why they changed the default behavior i have no idea... :S Download at normal location:
http://quakeone.com/markv The Mac build remains version 1.20. New Features vs. Mark V 1.20 - Very fast "triple the fps" DirectX 9 build courtesy of MH - WinQuake looking water warp in Open GL/DX9 (MH again) - Volumetric shadows - r_shadows 3 (MH again) - Sky speed up in Open GL/DX8/DX9 (Yeah, MH) - Linux Open GL build (thanks to JimBob for testing, Spike for debug tips) - Linux WinQuake build - Resize on-the-fly windowed mode in all builds (except DX8). Yes, even Linux. Tried to make the Linux build fancy. May have succeeded. - QMB enforcer lasers available video - Improved NVidia cards experience (killpixel, Kinn, johnny law, pulsar) - 2 Extra options in video menu for convenience. - Automatically bypasses GOG.com's ancient opengl32.dll (Syrion) - Warpspasm correct startdemos by overriding Quoth 2.2 (path0gen) - MH solved context creation issue in version 1.25 (dwere, breezep, - MH added extra control over r_waterwarp in 1.35. Type "find r_waterwarp" in console for details. Next update hopefully some time in the spring! All feedback, comments, etc eventually get considered, a nice thing about the Func_Msgboard layout. Should have noted Gunter, railmccoy did a lot of testing of DX9. Maybe others. I've been updating page, installers,
Instant crash when attempting to launch any form of 1035. dx8,9 and good ole mark_v.
Apologies if I missed something in this bustling thread regarding this. You two deserve many beers. Other reporting issues or feedback during latest development spree:
Fifth, Damage Inc, mugwump, nightfright, pritchard, adib (hope I didn't miss anyone, had to glance through hundreds of posts). @damage - Sorry, if I couldn't implement true rotation. Ran out of time. Will have to hit that up next development period (likely the spring). You can always use the RMQ engine or presumably DarkPlaces or FTE for such experiments in the mean time. then remember to delete your
Thanks. Can I get a copy of your autoexec.cfg, okcam.cfg and config.cfg so I can examine them?
I'd still like to know what settings would cause the engine to actually crash.
If there are settings that can cause the engine to crash, I would want to make the engine handle that without crashing. Do you have to okcam.cfg? I'm looking through things. I can say I don't crash with the config.cfg and autoexec.cfg you provided, but the okcam.cfg wasn't in your download.
/Is looking through settings Does the following:
cl_bob "0.012" cl_bobcycle "0.55" cl_bobup "0.7" Just a cosmetic tweak. I'm going to make a guess here
Does http://quakeone.com/markv/builds/1032_mark_v_windows.zip work ok? Ah, model is causing crash. Makes sense! Thanks for letting me know!
I couldn't find anything that made any sense, DX8 doesn't even have most of the new features, haha. Well, just for testing I completely removed dwere's pak and I still receive the same crash.
Just to clarify it's simply: "Has stopped working" prompt. This is testing on 1032. If I misinterpreted the above
Other than how you have an unusual resolution like 3440x 1440 My only thoughts --- 1) NVidia driver issue? 2) Borked mp3 sound track 3) Does work with reset config and clean id1 folder. I'm just not seeing anything that would cause DX9, DX8 and regular Mark V crash? What is most recent that works for you? I'd try Mark 1.20 http://quakeone.com/markv/builds/1020_mark_v_windows.zip And if you aren't having some sort of content specific issue somehow Ok, is a "has stopped working".
What was previous version that worked? All the builds: http://quakeone.com/markv/builds/ If you can tell me the last one that works, I might have something to work with Okay, so I believe the last version that worked was 1028...when performance was improved on dx9.
Clean Quake folder runs 1035. Placed my mp3 tracks and it still runs fine. Placed dwere's pak and runs fine. However, I went to change texture mode to '3' and it crashes to desktop with "Has stopped working" That's the only thing in my autoexec. I apologize I sent you the wrong one as I have numerous quake directories for engines.
I can run on my "dirty" installation just fine when I removed that entry. Downloads at the usual place
http://quakeone.com/markv -Mistake in gl_texturemode corrected (reported by Bloughburgh) Which is one of the 2 new items in the video menu added in 1032. Thanks for the help getting this polished up!
All the downloads are up-to-date and no compatibility issues! Thanks to Bloughsbough for finding that issue 5 minutes after Build 1035. ;-) Way better timing than something like that happening a week from now. /Next updates in the spring! Thanks a lot for the menu choice between filtered and non-filtered (pixellated) texture filtering modes. I had been asking for that for a long time. ^^
Two questions: 1) Is the option "GL_NEAREST" equivalent with the filtering mode gl_nearest_mipmap_linear? 2) I guess having this option in the menu now means that it's not necessary any more to put it into autoexec.cfg? @mukor - Thanks! Yeah, "Time for beer" is quite literal and I'm doing the mfx right now ;-)
24 hours ago, I was left with the prospect of taking a timeout with flaw of unknown origin affecting dwere, and compatibility stuff ticks me off, compatability is #1 on the list for me and is a major reason why I engine code. Obv, I also do not like engine crashes (so couldn't rest until Bloughsburgh's problem was resolved). Some timely insight by Johnny Law, a dev note by myself and then MH actually being able to experience the problem @nightfright --- I added the "pixelization" option to the video menu because I honestly didn't know which one was the "right one" -- I like my FitzQuake gl_linear_mipmap_linear and if I want crunchy pixels I use therailmccoy (WinQuake version). I found a thread where Spirit and MH discussed the issue So: 1) gl_nearest isn't gl_nearest_mipmap_linear, it's different 2) gl_nearest_mipmap_nearest is better according to mh. I don't think about this topic often, but the "too much detail math" is here https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexParameter.xml I fall into the gl_linear_mipmap_linear preference camp, so I don't think about this topic much but I understand the appeal to those that do. Perhaps this will be followed up with a better explanation by those more familiar with the topic. Since I'm a gl_linear_mipmap_linear (trilinear) guy @rook - Thanks!
R00k -- you know what sucks? When Bloughsburg had a crash issue, I ended up booting both my Windows 8 and Windows 10 machines -- because I thought the issue could involve Win 10. I enjoyed playing Quake on Ubuntu more than either Windows 8 or Windows 10. On Windows 10 I hit some fucked up key that activated a narrator (fuck you Windows 10!). Meanwhile, the Linux experience was dreamy --- and in no small part because I juiced the Linux build with all the Windows-ish goodness I possibly could. /Also, for a while I wouldn't turn on my Windows 8 machine because I feared it might be a Windows 10 machine the next morning. Windows 8 sucks compared to 7, but Windows 10 sucks 5x more than Windows 8 because the next update it might undo all the customization and cleaning out garbage out of the menu you spent time doing. According to a definition on the Quaddicted site, it's like this:
GL_NEAREST: Point sampled. Lowest quality, highest performance. GL_NEAREST_MIPMAP_NEAREST: GL_NEAREST but with a bit more quality for far objects (software-like). GL_NEAREST_MIPMAP_LINEAR: GL_NEAREST but with even more quality for far objects. Personally, I also think mipmap_linear offers better quality than mipmap_nearest, and that's why it was the mode I had been using all the time. Are there any chances to add this mode as well (maybe as "Pixellated/Smooth")? gl_X_mipmap_Y
X = how close-up textures are rendered. Y = how different mip levels are blended together as objects move closer or farther away. Nearest_mipmap_nearest is closest to software Quake because software Quake used mipmaps. It's as simple as that.
If I'm in a crunchy pixel mood I use nearest_mipmap_linear which avoids banding between the mip levels. I can post screenshots later on that demonstrate this. It's one of those things that you might not notice, but once you do it drives you nuts. Nearest on it's own disables mipmapping, which causes distant textures to shimmer and sparkle as you move around. Sometimes people mistake noise for detail, but this is basic sampling theory stuff. There's a weight of mathematical papers on it, including articles in the Mike Abrash Black Book, and I'm not going to get bogged down rehashing what others have said better elsewhere. You don't want to disable mipmaps, that's all. The last thing is relating to mipmapped water, which Fitz and most derivatives don't have. As the water warps it can subtly shift between different miplevels. Again, drives you nuts once you notice it. Solution is to use ddx/ddy (GLSL dFdx/dFdy) on the unwarped texcoords then a tex2Dgrad lookup. You can't do that without shaders. Not sure if vkQuake or any other publicly released engine does it though. https://streamable.com/4an03
This was recorded in 1.00, so it's pretty out of date. I died, rapidly clicked and started the map again like this. That's all I have to say - I haven't tried reproducing it yet. Thanks Baker, I just happened to pop on at the right time I guess. Cool to see those options be included in the menu as well!
I found it strange that it crashed after trying to set a mode...then I went to the correct autoexec and saw it ONLY had the texturemode command hah. I really need to conform all of my directories with my master config. Looking forward to trying when I get home! Yeah FWIW I use nearest_mipmap_linear too. And with some anisotropy set (so I really need to go re-read that discussion above about those interactions).
Obviously that's not the pure Winquake look but I likes it. :-) You two rock as I have said, more beer!
No problems running 1036 from a quick test around! Love to be able to change the water warp...it is a bit intense at 3440x1440! Each of us working on different set of features at the same time in way that allowed asynchronous development which covered quite a bit mileage in short span of time.
A very enjoyable experience, indeed. Looks like I should have picked gl_nearest_mipmap_linear instead of nearest/nearest for the option. @bloughsburg - type "find warp" in the console. I doubt that gl_nearest is a mode many people will use. My suggestion would be to simply replace it with nearest_mipmap_linear and use that for "Pixellated" mode.
Any luck on Intel graphics 3x performance? So far DX9 runs stable at 15-40 fps and is definitely better than QS.
Mark V has a bug with the rewind feature in demos. when you rewind, the clock go forward instead of backward.
when you pause (down arrow) and unpause, the time is resynced. this is scr_clock @topher - thanks for reporting that. Must have wired up the wrong clock when absorbing some JoeQuake/ProQuake features back a couple of months ago.
/+1 to do in the spring update A workaround in the meantime, if you are interested. Add +pq_timer 0 to the command line or throw it in autoexec.cfg
QuakePone, if you're interested I posted 2 builds in the QS thread here to check for a potential problem that affected some versions of Intel graphics.
Additionally, as MH mentions, try benchmarking "gl_flashblend 0" vs "gl_flashblend 1" (this may be faster; it stops the lava balls from casting dynamic lights and just draws a fake glow instead.) I tried this in my own engine, on a nvidia 960gtx, and it really didnt matter. yet as I like you are using gbra uploads, but then in the most classic settings, im getting 2200+fps with playdemo demo2 on Qrack vs 1600 in Mark V using really close effects; no motionblur, no r_novis, classic particles, etc. in DirectQ / RMQ i get 3000-5000fps.
maybe lightmap uploads matter? An NV 960 is irrelevant unless you can get a test case that goes below about 500 fps.
Gimme the Intel benchmarks, that's the interesting stuff. There's probably things I can do for lightmap updates but I'm not willing to gut the code unless I'm satisfied that there will be payback at the end of it. I might also make one of my experimental GPU lightmaps engines available, because I'm interested in how that might perform. I'm cautious about not creating expectations in the community though.... Map = ad_magna
In console type: "setpos 2496 56 -292" And you'll be at the mirror. screenshot /In Mark V, you can type "viewpos" to see your current x, y, z -- which also sets the default setpos. So if you type "viewpos" at a red armor, walk away and then type "setpos" you'll be back at the red armor. If it is lightmaps --- and that's an if --- slowing things down.
Type: r_dynamic 0 Then dynamic lighting is simply turned off. In Mark V, do the following after starting up Arcane Dimensions.
Type: temp1 0 // Turn extra ad particles off r_dynamic 0 // Turn off dynamic lights sv_cullentities 2 // Strict visibility tests on all entities map start // Restart the Arcane Dimensions start map Play See if your fps improves. These commands helped a lot in previously barely playable maps like ad_tfuma and ad_swampy. I might leave temp1 on 1024 and r_shadows on 1, still.
Cool! Glad it helped out some.
In the Quakespasm thread, mh, ericw and myself and others are discussing performance related issues related to Arcane Dimensions. I'm starting to warm to the idea of doing some kind of release of one of my GPU lightmap experiments. ericw has expressed interest in how parts of it work and I'd be fascinated to learn how it performs on QuakePone's machine.
I've basically got 3 engines: Quake/OpenGL/assembly shaders, Quake/Direct3D 11 and Quake II/Direct3D 9. The Quake II engine is probably the most developed but it misses D3D 11 enhancements and draw call overhead does pile up. The Quake/GL engine is very barebones and I'm not sure where the code is. The Quake/D3D 11 is most likely to be let out. Huh. About the issue where models in front of the sky look "darkened"
(see my post on Old Page #1321 with screenshot illustrating that fullbright textures get ugly and washed out when contrast is applied) Here's a screenshot showing this effect: http://imgur.com/a/2C4Ez Shaft looks better with sky behind it! Maybe something like this could help all fullbright textures to make them not as ugly when contrast is applied.... Starting with -nostencil removes the sky effect, though it still lets you see r_shadows 3 through models (second screenshot above shows a distant grunt shadow visible through a dog's butt, heh). I know you're aware of the stencil issue, mh, but I just had to display these interesting screenies ;) On your server with JimBob and ORL.
Hadn't played Frostbite in some time, that map and the rest of the "2005 Wintery Map Pack" are always great experiences. You might talk JimBob or even yourself into delete all maps and extra sounds in your Quake folder to watch the map/model/sound download in action. JimBob wondered how I had the maps and the music, haha ;) Well, I didn't until I connected. They downloaded automatically, of course. Mark V has the best stay-connected http map/model/sound download this side of FTE. The auto-downloading is great. And I have noticed the
I just wasn't sure if you actually got the music. I don't mean the intermission dance loop WAVs. Rather, I mean the soundtrack MP3s I selected to match the edited Also, I'm not sure where it all comes from, since I think the FvF server is still Magic Proquake? I do vaguely seem to recall you talking (once upon a time) about having downloads come from a 3rd-party source like QuakeOne or w/e? Locs are for team deathmatch and such (dm3, etc.) like "At the red armor with 87 health"). You can turn off downloading locs. Type "find loc" in the console, you'll see a cvar that can be set to turn that off.
/mp3 don't download, mp3 tend to be large, aren't needed to play. It's a player preference anyway. of also moving r_shadows and r_waterquality variables into config.cfg?
I find it a bit complicated to set them externally through autoexec.cfg. And since texture filtering has already been moved... I've been really enjoying the winquake build, it runs very well. I ran into this little guy after I disabled mips. He's harmless but has worn out his welcome :)
just found "showram".
Whenever I get stuck on something I just make a forum post or drop a message on irc so 30 seconds later I can figure it out myself :P never fails. ever. Don't know, but I'll think about it.
I worry about mods changing obscure things, causing niche settings to write to config. Examples: 1) quake.rc, autoexec.cfg 2) QuakeC Case in point, Malice messes with untold numbers of weird cvars like viewidlescale that most users have never heard of. Imagine if you exited and everything saved, all those peculiar settings would be part of your config and short of reseting/deleting your config, you wouldn't know how to reset them. I'll think about it. But my instincts tell me that no matter what, someone with very specific tastes is always going to find something that needs to be an autoexec.cfg Mods should be properly set "gamedir" and yes everything saved, including
that's true except, when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to.
Some people use game command (i.e. "game travail"). Some people like R00k probably use gamedir capability more for CTF.
And although no small number of people use the command line either from habit or because of the Quake Injector -- there are those that use "game travail" way. And these different set of circumstances have to be factored in. when implementing the command in fitzquake, i considered writing the config to current gamedir, clearing all values to default and then loading the config in the new gamedir as a way to resolve this, but it could have negative results such as changing your video mode or mouse sensitivity, or other settings that the player doesn't expect to be per-mod.
The core problem is that some settings are global user settings and some are mod settings and there is no formal distinction between the two. Most experienced players don't feel too much pain from this since they have autoexec.cfg files that force the correct settings (of course this breaks down when a mod includes an autoexec!) These are major things that, in addition to the topics noted above and earlier in the thread, are likely to be goals in the spring.
List of some different future possibilities 1. Coopable 3D "Quake Injector" built-in, concept Undergate screenshot About everything needed to finish the concept is in the engine already. 2. iPad/iPhone/Android versions with Minecraft-like controls (Minecraft is very playable on an iPad). I played the awesome Kurok mod for Quake FitzQuake version on a PlayStation Portable and am not likely to be satisfied until I can play Quake on at least an iPad and also like it. I also did tons of engine modding of PSP Quake engines, so yeah I'm not pleased about not being able to Quake on devices. 3. Kurok capability screenshot. I have added almost every required capability into Mark V, but a small few remain. 4. Multiple-players, same computer. working prototype demonstration. This means studying Microsoft's XInput for game controllers, because the working code does not have the needed input support. 5. Spiked Quakespasm's super-compressed protocol. I like demo rewind and will have plan out right way to achieve it. 6. Playing 7. LAN Co-operative peer-to-peer multi-threaded download of required files (Like the client downloading "travail.zip" from the server). Would make LAN co-op setup even easier and Mark V already has a ton of co-op capabilities. Mark V actually has a beta form of capability disabled in the engine for polishing. (Note: Even a 70 MB download is nothing on a LAN. Over LAN that file could have downloaded hundreds of times while I typed this sentence.) 8. A re-written sound caching system to allow changing sndspeed between 11025, 22050, 44100 at any time. 9. Native Linux without SDL. Will add better support for video capture, hardware gamma. (Might adopt Spirit/jdhack's Requiem Engine decision to use fmod for mp3 playback, but I still haven't explored all the mp3 options, including some of ericw's thoughts.) 10. Other things mentioned elsewhere in the thread, I'm sure. "when you switch gamedirs during a session, the cvars and aliases and keybinds are retained, and when you eventually quit that session they will be written to the last gamedir you switched to."
Uhh, I just tested, and Mark V does not actually do that. Well, I mean, it does carry over settings, but all config changes seem to save to the directory you started in, always, not the last dir you were in when you quit. But if that's the way you are starting the mod every time, I guess you would end up with all your config settings each time you play anyway.... Though I don't think that's the correct way to go about it. I'm with Rook on this -- let each game dir house its own cfg stuff for that mod. And I still say it should automatically exec that config stuff upon changing to a new gamedir. This would allow the user to keep settings for each game truly separate. And if someone changes to a new dir, it won't carry over config stuff from a previous dir that perhaps shouldn't apply (assuming there's a setting for the mod that should supersede an old setting -- just retaining defaults is fine). And it wouldn't (shouldn't) save config stuff you change while playing that mod back to the base id1 folder (as it does now if you start in id1 and manually change to the new dir). So yeah, each game dir should have its own configs, really, which override anything from outside that game dir. And when you quit, the config for your current game dir SHOULD save within that game dir. I could illustrate a problem with the current approach: Start Quake normally (plain id1). Let's say you have normally bound "shift" to cycle weapons. Then you want to play FvF or something with a grapple, so after you change "game fvf" and "bind shift +hook" then you quit the game, it saves that binding back in your id1 flder.... Now if you want to play normal Quake again, you have to rebind the shift key. If it saved your (now altered) bindings in the fvf folder, you wouldn't have a problem. And if it would exec all the configs from the folder you changed to, it would all be set up automatically the next time you change to the gamedir.... Then that would make everything work consistently in the same manner no matter what method someone uses to select a gamedir: starting: "marv_v -game fvf" would behave identically (loading configs) to typing in the console: "game fvf" Wouldn't that consistency be better? If someone uses the game console command (i.e. "game travail" or such), they start out in id1.
Then switch to travail. Obviously, if you always start up in id1, you would want any changes to video resolution or setup to also apply to id1. Since id1 is the config run on startup, yeah, that's where it should save too! If someone uses -game whatever from the commandline or the Quake Injector, the config saves in game whatever just like you would expect. Mark V saves settings every time you exit the settings menu or the console.
So if you wonder why no matter what happens, everything is always saved the console history is always up-to-date. That's why! /I prefer to not mention these little niceties and polish-ups because I just consider it part of polish. Like how Mark V forces a WASD default key setup and makes the mousewheel do previous weapon/next weapon by default. makes me want to rip out my autoexec cfg and do some gamedir testing... i think if i do a gamedir AD then my current gamedir should save config.cfg first switch dirs then load config.cfg from there, and vice versa. I hope this is the case already if not i'll have to change it. I have added a writealias command that dumps an alias.cfg for each gamedir but the user then has to make an autoexec.cfg to exec alias.cfg or maybe i should make it do that automatically...hmm
my levels menu doesn't work in the quakespasm folder. I have the quake HRP and the menu graphics change. What does this? In the DP folder works fine.
DX9 version is great, it kills on my R9 280. Also what graphical things are supported? Just unpacked textures? Can it ever support things like dp pretty water? "Single"
"New Game" "Load "Save" "Levels" (Only appears if nothing above graphically replaced) ----- So if an exceptionally rare mod (X-Men, for instance) replaces a graphics there Or if a user is using high definition graphics for those menu items Rather than present the user a "Levels" graphic that clashes with the appearance of the menu, it simply disables itself ;-) I'm just rather picky and I'd rather have menus that look nice than a menu with an item that clashes with the rest of the items on-screen. Mark V can save multiplayer games, including co-op games which was the main target.
/If it isn't working, let me know. Also what graphical things are supported? Just unpacked textures? Can it ever support things like dp pretty water?
QMB particle option in menu, MH waterwarp (defaults on), MH volumetric shadows (r_shadows 3). The Open GL version (not DX9) has a raw test implementation of bloom that needs more work in the future. Eventually, it'll be run through the gauntlet, maybe possibly sometime in the spring, but not necessarily because isn't high priority item. External textures use the same names as DarkPlaces. Mark V only supports That would need a VERY significant overhaul of the entire renderer.
It might not be immediately obvious, but DP pretty water needs shaders. Then you're in a position where, in order to have other effects be consistent, you have to implement *everything* in shaders. Another thing is: the reason why DP runs slower is because it does all these effects. If you start with another engine that runs faster, port DP's effects to it, then I've always been of the opinion that it's a big world and there should be room for lots of engine options in it. Each engine has different goals. If you want to "pimp my Quake" then DarkPlaces is the engine for you, but other engines don't share that goal to the same extent. DX9 version is great, it kills on my R9 280.
MH did an incredible job with the DX9. One of the rare (and fun) examples of something going from simply non-existent to polished in just over 3 weeks. The awesome beta-testers here who help out and provide fast, high quality feedback is unimaginably helpful to engine development. Most incredible beta-testers ever! Engine development is hard, but smart detailed-oriented testing can take quite the edge off! Lol, I had no idea. I thought it was like standard quakes implementation. Plus the save option sits under the single player menu
Stuff like DP dies on AD, down to 7fps. Other games, ie Q2, Q4 run much better at the same resolution with HD and extra effects cranked.
I've had the best luck with this engine and quakespasm spiked. For instance ad_fuma... markv/dp = slowdown right at the start by the lift. markvDX9 = smooth. >QMB particle option in menu, MH waterwarp (defaults on), MH volumetric shadows (r_shadows 3) I found the particles and if waterwarp is on by default I just have to try the shadows. My transparent water in QSS has issues rendering, wrong things or distant things will show up. >>Rather than present the user a "Levels" graphic that clashes with the appearance of the menu, it simply disables itself ;-) I wish I could override this. Typing map is somewhat of a substitute. I do 1080P on a 42" screen so I really like the high res. See your point on shaders though; I remember playing quake and quake2 on voodoo2 back in the day and to see it keel over with a quad, 16gb of ram and a card faster than the original PC is shocking. Remove or rename gfx\sp_menu.tga (or gfx\sp_menu.lmp) and will probably load, if that is what is going on.
Possible (non-ideal) workaround. Hm, I would say the information and function is more important than the aesthetics.
It's no big deal if the "Levels" menu looks different; it's no less useful, and it's not like people are going to be staring at the menus for long periods of time. A menu isn't there for artistic value -- it's there for functionality, just as a way to get to the setting you want. Oh... AND it makes it even worse with your force-choosing what map to stick me on when I go to start a New Single-Player Game (oh how
I hate that feature). I tested with FvF3 (a later version, not the version my server is based on) which contains custom menu graphics. If install the custom maps from FvF4 (which contains one called fvfstart.bsp) along with, say, the iikka, terra, and dopa maps, then your map-forcing feature (which I hate so, so much) decides to ALWAYS stick me on fvfstart rather than the default start.bsp when I use the default menu option to start a single-player game. Furthermore, since there are custom menu graphics, the "Levels" menu is missing, so I cannot even use the menu to work around the feature (which I truly, truly hate) to start the standard start.bsp. So, the "Levels" menu should always be there, even if it's ugly, but more importantly... (you can imagine me shouting this loudly to properly convey the hatred I have for this feature) THE DEFAULT MENU OPTION TO START A SINGLE-PLAYER GAME SHOULD *ALWAYS* START THE DEFAULT SINGLE-PLAYER GAME. heh. I know, you probably spent time and effort coding this feature thinking it was a great idea, but it's just not. This is as bad as all the "toxic settings" you hate so much when some servers or mods force upon the user. This is just as bad as a mod containing an autoexec.cfg within a pak file that force-starts you on the same map every time despite what you, the user, want to do, because just like in the case of an autoexec in a pak file, it cannot be disabled in Mark V. And no matter if I am wanting to run the dopa, terra, or iikka maps, I will get forced to start on the fvfstart map every time, because it is first alphabetically, so it's not like the feature is working well to begin with -- you can't read the mind of the user, and selecting a map alphabetically is no substitute. So just go back to the default function for the default menu, and if the user wants to do something non-default, the wonderful "Levels" menu lets him run whichever non-default mission he wants. Well, assuming you don't hide the "Levels" menu because it doesn't match new menu graphics.... But as I said, I feel the functionality is far more important than the aesthetics. 1) FVF running (-game fvf)
2) Single Player->New Game 3) fvfstart.bsp loads 99 of 100 people would call that perfect behavior ;-) IF U Have a starting map in your own gamedir then just call it start.bsp, like everyone since 1997 does it? ;)
Select and rotate pitch and yaw by selecting a single pixel on the screen and dragging it.
Video Initially was a bit frustrating, then the slightly rusty 3D math kicked back in. Have to imagine the frustum as a sphere. Combining and project and modelview matrix, the center of any pixel on the screen has an exact "pitch" and "yaw". There are shortcut cuts methods that wouldn't achieve pixel-level selection precision, but I wanted the real one. heh. for me the key to that feature is the convenience of the list. renaming the graphics isn't the worst thing. I don't have as much passion about is as gunter. I'd just start from the command line if it was picking the wrong map regularly.
lots of stuff, ie the mapjams never even had a start map. not sure if "maps" works in any other engine but it would have saved me alt_tabbing at least. AD has mod folder selection from a menu but no maps. the r_shadows 3 looks good, I would have never found it. recommended behaviour would be for mods to create startmap_sp/startmap_dm aliases that specifies exactly what to do, and for engines to invoke that instead of doing 'map start'.
that way you're not getting randomness... if only more engines+mods used that... more seriously though, what kind of weirdo actually uses the menus? :o (especially if the console's maplist dump supports clicking) Stuff like DP dies on AD, down to 7fps. Other games, ie Q2, Q4 run much better at the same resolution with HD and extra effects cranked.
I've had the best luck with this engine and quakespasm spiked. For instance ad_fuma... markv/dp = slowdown right at the start by the lift. markvDX9 = smooth. I can see why that might happen - polygon counts are absolutely insane in this part of the map. There are a combination of things going on here. Insane polygon counts. MarkV GL makes no attempt at draw call batching. That's going to mean that bigger more complex scenes will bog down more and more. MarkV D3D9 takes those GL calls and batches them, so it can handle those scenes better. It's still transferring a LOT of data to the GPU every frame though. Quake 1 map formats are working against you. There's actually not a whole lot visible in that start scene, but Quake 1 lacks the vis format enhancements that even Quake 2 had, so it's pulling in a LOT of hidden surfaces. DarkPlaces + huge data set + bad vis format + bling is not a good combination. Quake 2 doesn't have the bad vis format, so it's data set is smaller, so you can bling it without as much slowdown. Likewise more modern formats. Putting your data into vertex buffers so that it's already on the GPU rather than needing to be transferred every frame helps a LOT with bigger data sets too. It's like the Quake equivalent of death by a thousand cuts. "1) FVF running (-game fvf)
2) Single Player->New Game 3) fvfstart.bsp loads 99 of 100 people would call that perfect behavior" Maybe, but I complain louder than those other 99 hypothetical people combined! :D And the problem is that this same thing would happen no matter what mod you were running in "step 1." You'd get fvfstart.bsp no matter what mod, because it's first alphabetically.... Actually, in the FvF4 full version package, the mod is programmed to always start the fvfstart.bsp map when a player goes to start a new single-player game. Probably somewhere in the QuakeC it does that.... This is more like what Spike suggested. If the mod actually specifies a map to run, that's fine -- you give control of such things to a mod when you run a mod. Though the automatic start map picking does not seem to occur when you are just running id1 Quake.... Why is that? That actually seems backward, in a way.... I mean, if you're running a mod, the mod itself will usually contain some way of starting whatever map it want to start, if it doesn't want the default start map. But if you're running just plain Quake and you have a single-player map pack installed... then you DON'T try to select the start map via the engine ? Well, I don't understand the reasoning behind that, but I dislike the feature in either case. I do love the "Levels" menu though. My perspective most closely aligns with Spike's above about how mods should supply the information on the proper start map.
In a perfect world, that is the correct solution. I can think of only one case where "start.bsp should always be the name of the start map" doesn't apply, and that's where a mod has only one map.
If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp). We're conditioned to think of "New Game" as being the equivalent of "map start" but if you step back and think: "is it really?" you might get a different perspective. " mods should supply the information on the proper start map. "
Agree. But if they don't do that, then the default start.bsp should be used instead of just guessing at it. "Anything else is asking for trouble. " Completely agree. I have been running into said trouble in actual practice -- though it's not that it can't be worked around but manually changing levels after I get dropped in the wrong map; it's that it is a major change from Quake's expected default behavior. "If a mod has only one map, and if a player selects "New Game", then IMO it's obvious what the player's intention is (hint: it's not to load ID1's start.bsp). " Actually, I don't agree with that, due to something I have done with FvF.... I have a modified DM6 map that contain an extra area which has nothing but a deadly lava pit with ledges above it, referred to as "The Purifier." When players vote to start a new Quest, I first transfer them to The Purifier area to kill them off before starting. The reason for this goes back to before I had the source code, and couldn't just strip everyone's weapons and frags from then without killing them... so the solution was just to kill them in a deadly trap before starting a new Quest game. At first, I had a separate small map for this, but later Orl modified DM6 to contain the Purifier in an extra area. This allows all players connected to the server to not be stuck in the console when The Purifier is called -- instead, if they don't have the modified map, they just feel like they are floating in space above DM6 while they die (the map on the server has the lava area, so the players can be in the DM6 map, inside that area, even if they can't see it). Of course, now I have the source code and could just strip the players' weapons and frags away before restarting Quest mode, but The Purifier became a traditional part of FvF, so it remains and is included with the FvF download files. So, long story short (too late!), even though FvF has only one map included with it, it should never use that map by default when I go to start a new single-player game... because (before I had installed other maps in my FvF folder) I get put on DM6 when I try to start a new single-player game! That is something that should never, never happen.... So yeah, default menu function for starting a new single-player game should start start.bsp EVERY time. There are many different ways a mod can control that if it's not what is desired. Mark V's first priority is to play single player releases at Quaddicted and those released here. That first priority will never change.
FVF is not a traditional single player release like ARWOP, lunsp1, Travail, Marcher Fortress, Once Upon Atrocity, Grendel's Keep, Warpspasm, Soul of Evil, The Colony, GMSP1, Middle Evil, Rubicon 2, etc. So yeah, maybe you have to add +map dopastart to the command line. Oh the horror! Mark V - #1 priority is Quaddicted/Func_Msgboard map releases. Feature is well suited to those. But yeah, you can argue this until the cows come home and it will never change, because it is conflict with the stated goal of supporting single player releases conveniently. If I install
1) "game cda" - Castle of Dark Ages - Single Player new game should play the release. 2) "game lunsp1" - Single Player new game should play the release. 3) "game coagulatest" - Single Player new game should play the release. I could name 200 more examples. Now maybe someone like Gunter doesn't play single player releases off Quaddicted. That's fine. But you have to remember that this engine is built to work in harmony with single player releases. Arguing something in conflict with the #1 stated goal of the engine is just a waste of time. All that being said, what Spike said #1244 has been a low priority item to examine and possibly implement.
Not even close to the first time Spike has conversed about such a feature, it has come up at insideqc in the past on multiple occasions. So possible future ability to specify what you think the start map should be for FVF via quake.rc or such doesn't seem like a stretch. No, I'm not familiar with all the single-player releases, but I have to ask, of those you mentioned, are they actual mods that should be installed to their own folder? Or are they just map packs?
Mods should have their own method of starting the correct map. Map packs (like Terra and Iikka that I know of) are just installed to the maps folder, usually in id1. In the former case, your map guessing isn't needed, and in the latter case it apparently doesn't function. Let me check all the ones out you named, to be sure I thoroughly examine the issue. CDS - pak file with progs included, so it's a mod, but it contains a readme with instructions: "3. Then load the map by typing 'map cda'." lunsp1 - same, with instructions, "type 'map lunsp1'." coagula - instructs user to use command line "-game coagula +map cogstart" ARWOP - has instructions "Start a new game, and you will be taken to the start level of 'A Roman Wilderness of Pain'." So it's done the correct way, within the mod itself. Travail - same, mod does it correctly/automatically. Marcher Fortress - contains instructions to use command line "-game marcher +map marcher" Once Upon Atrocity - starts the map in the included autoexec.cfg Grendel's Keep - instructs to start map + mod by command line. Warmspasm - looks like it does it automatically by the mod. Soul of Evil - also done correctly by the mod. The Colony - well, there is one "Colony" that is just a bsp with instructions to copy into id1\maps\ and run with "map" command, but there's also: The Colony GMSP1 -- gives command line to start mod + map. Middle Evil - instructs to use "map" command. Rubicon2 -- apparently does it correctly in the mod. So let me just tally this up. Of the 14 potential things you mentioned (there were 2 Colonies): 5 of them do it the most correct way, within the mod itself, when you start a single-player game. 1 of them does it by an included autoexec.cfg, which is the second mostest correctest way to do it, I'd say. 1 of them is just a bsp which is placed in 1d1 with instructions to use "map" command (noted separately since the map-guessing feature doesn't work unless a mod is running). 3 of them have instructions to use "map" command. 4 of them provide a command line for the user to start the map + mod (oh, the horror of having to use the command line ;) So, is the feature REALLY well-suited to these things? In half the cases it either is completely unnecessary or won't work. In the other 7 cases, if the user is following the instructions, it will never be used, (even though it would function correctly). I'm sure there are many, many more map packs we could examine, and we could each look at the examples that either make it look good, or unnecessary, or bad. But the feature is completely necessary in 0% of the cases, since all the map packs provide instructions for starting the map. The feature is useless in 50% of the cases, because the mods either do it correctly already, or the feature doesn't work for maps in id1. The feature is actually bad in some cases, such as ones I have mentioned.... So you've got a feature that's 0% necessary and only 50% useful, while sometimes actually being detrimental.... It's just not an overall good feature, even for the intended purpose of single-player maps. Do I expect you to remove the feature? No -- I can tell you love it as your special child which you put time and effort and thought into creating ;) But I'm sorry, even though you love it, your special child is a tard XD Even the people who aren't complaining as much as I am have said that start.bsp should always be the default (with mh's note that this may not necessarily be the case if there is only one map). Me? I'm a Default Purist. I still am bothered that your pitch settings are off by But this -- changing a cardinal menu function? That's so much worse to me.... But no, I don't expect you will remove it. What I ask is please, please, PLEASE for the love of cake give me the option to disable it! A console variable, a menu setting, heck, a command-line option, ANYTHING so that I can have my Quake and eat it too! Er, I mean, so that I can have my Quake default functionality restored to it's proper functioning like it did back in 1996! Let me just quote you the words of a wise man, please consider them carefully ;) "Mod authors almost never intentionally did wrong things, they only sought to provide a good user experience for their mod. Nonetheless, there are toxic quake.rc and autoexec.cfg files out there. And playing single player release with the player in control of his settings is #1 for Mark V." I know you didn't intentionally do the wrong thing, but this setting is toxic to me, and you have taken away my control to even disable it.... ;) I would definitely count all instances where the user is instructed to use the "map" command as instances where automatically launching the map is desirable/necessary. Mark V is designed for a plug-and-play experience - you aren't supposed to have to leave the game/engine to read readme files, just like you don't have to with the Quake Injector.
Don't know. I'm not going to be doing more engine coding until (probably) the spring, except anything I decide to do as a leisure activity or experiment for my own satisfaction.
I won't be making any kind of decisions right now. Nor thinking about the "to do" list. If I code something before then, it will be a leisure activity or solving a complex 3d math puzzle or something. Wallclimbing mod Found the old pubdm mod pretty much written by R00k. https://www.youtube.com/watch?v=AFtK36d4tpc I'd personally discount those that give instructions. People don't read readmes. Never have, never will, you can keep your credit card details in a file called "readme", perfectly safe.
Discount a mod that provides an autoexec. That's the LEAST acceptable method to me (of those you list, there are worse). The mod author is making a statement here: Their preferred settings are more important than mine. That kind of thinking can fuck off. I'm the player, the autoexec belongs to me. So I make that 9 that are player-hostile (1 actively so) vs 5 that do the right thing. Almost two-thirds. Now, I'm not saying that Baker's approach is the best. One useful purpose it has served is starting a discussion around this problem, because despite what you claim, it IS a problem. People have trouble getting the Quake executable into the right folder, so you cannot claim that installing and using a mod is an intuitive trouble-free experience for everyone. Personally I'd love to see something built into the Quake Injector. Maybe something built around Spike's suggestion, or something else, so long as it can be standardized and adopted. What do you mean "built into the Quake Injector"? I thought that already handled loading maps without a startmap.
I'm not familiar with the Quake Injector -- I've heard it mentioned, but have never used it. But I was just thinking, "maybe a good solution would be a stand-alone Quake runner, much like QView, but for running mods + maps.... Maybe that 'Quake Injector' could be made to do something like that."
So yeah, you could have a program that looks like Qview, only it scans your Quake folder for mod folders and asks you which one you want to run, and maybe it scans that folder for map files, and if there is only one it runs that, or it could use a similar "guessing" algorithm to select the most likely start map, perhaps showing a list of those maps with the default one selected. Then you click run, and bingo-bango, it automatically runs your selected Quake exe with command like automatically tacked on (similar to how Qview does it to connect you to a server), with -game +map automagically set for you. (Though Qview just tacks on "-exec Qview.cfg" and puts its settings in that). Heck, someone should make an updated Qview that can both handle running local mods and connecting to online servers, perhaps with a master server list setting included.... You have a point about people sometimes not reading the readme.... Though I'd think in general if they were downloading the zip files manually and unpacking them, they know what they are doing and would likely check the readme, or would just check the map folder and see what's there. Though the Quake Injector thing might bypass that? in which case, yeah, the user may not check the readme. Though, in that case, there is the wonderful "Levels" menu in Mark V so they can run the included map (I really like menu, and feel it is the correct and best way to handle maps). In regard to mods including autoexec.cfg, that actually seems like one of the best ways to handle it to me (even better than just having your map named start.bsp) for the very reason you mentioned, mh -- "the autoexec belongs to me." Meaning I can edit the file easily to include or remove whatever settings I want. I don't mind the mod author putting his suggested settings in there, because, again, they are easy to change (assuming they don't commit the terrible sin of sticking the autoexec in a pak file, but that is rare). It actually seems handy to me that the mod author would include an (easily editable) autoexec which will automatically start the intended map. But yeah, I agree that it would be nice to have something for noobs built into Quake Injector for running mods/maps (if it doesn't already?), or just a new version of Qview with that functionality included, or just a new little stand-alone app (which would be pretty simple, really) that could run mods and/or maps with a few mouse clicks. Just a couple unrelated observations because I was starting up the Soul of Evil mod while testing the map running stuff. This mod uses its own start.bsp map.
I use an old version of Fitzquake (.85) for comparison, and I noticed two things: 1. Mark V is smart enough to not use the default start.lit file from my id1 folder.... Fitzquake does use that file, resulting in some... unusual colored lighting effects, heh. It doesn't look bad, it just look different, with strange colored lights splashing on the walls from no apparent source. But yeah, Mark V is probably correctly doing this. 2. Even upon first running the mod (by command line), so there would be no cfg files to read from in the mod folder, Mark V carries over some settings from id1. This can be good or not so good.... It doesn't seem to carry over the resolution settings -- that would actually be a good one to set.... It does carry over controls I have set up, which is good for basic movement controls, but not so good in that it keeps keys bound to aliases which are now no longer set (by the autoexec in id1). It also grabs the settings I have made in the menu, including disabling the demo playing... and in this case that turns out to be bad, because the mod has a little "intro screen" demo that runs by default. This is a tricky thing, because it's either "all or nothing" using the settings from id1 (or its hidden cfg file somewhere?) as the defaults in a case where you run a new mod... (weren't me and someone else complaining about that previously? heh). On the one hand, it's handy to not have to set up your controls again, but on the other hand, generally you should be starting from scratch (with the actual Quake defaults) when you run a fresh mod (or delete your cfg file).... Of course, knowledgeable users will have their basic keybindings in a separate cfg file which they can exec to set up all their default controls and preferred settings.... I think in this particular case, despite the user setting his id1 Quake to not run demos (because he's seen those 1000 times before), upon running a mod where the setting has not been previously made, the demos should default to play (it's actually an intentional part of this mod's experience). Hm, yeah, this is tricky. There are good and not so good points about it... in which case I start to lean toward sticking to the default behavior (no cfg? default settings apply). Perhaps there would be some middle ground where keyboard bindings were retained (not much problem with that), but default settings such as "play demos" are not taken from id1 when a new mod is ran. so the shadows(3) sometimes go through walls and floors. bug or a byproduct of the mentioned overdrawing by quake?
I could take SS if needed. For instance dead ogres on top of a bridge are casting shadows on the ceiling when you walk under. Bit of both.
It seems possible that this is related to the draw order, and I'm going to work out what the possible best compromise is. Assuming it can be fixed it will be in one of Baker's spring updates. Until then you need to accept it as a choice between 2 imperfect shadow options. I think this is the fifth time I've said this... :) sorry, i tried going through the whole thread and must have missed it.
Documentation is a little sparse, maybe I'd have a better idea of all these things if I checked the source. I thought I would raise this subject here because it seems like Mark V is one of the few engines currently under active development that isn't DarkPlaces.
What do people think about supporting lighting on water surfaces? Personally, I think it's a very nice visual effect and I'd quite like to see it in more engines *wink wink nudge nudge*. As far as I know compilers like ericw's tyrutils suite fork can support it, but I've never played with an engine that actually renders it... Sorry if this has been brought up before. The other thing I thought of asking about is if it's possible to disable the Gamma Protector Clock? It makes my screens flash when it fights with f.lux.
I'm currently using Mark V 1.20 (not sure if that's the latest version), there's only 4 options under Video Options - Resolution selection, Fullscreen on/off, and apply and test buttons. The only thing I've seen relating to gamma is the slider, but that doesn't sound like what you mean.
That menu item was added in the current version, 1.36. You'll probably prefer the DX9 build over the traditional Open GL version since it is much faster (nearly 3x faster in many situations), but both are available.
Woah, what happened to my framerate? I tried the dx9 build and it was fine, but the GL build tanked. I was getting a perfect 72 on my map before, but now I get something in the range of 22-23 fps with the standard mark_v.exe.
At least dx9 works. Is another topic that pops up occasionally. I'd like to see support for it. May be tough due to the way water morphs and deforms though
As far as I know light maps are blended after textures are drawn, so depending on where the textures are warped it wouldn't be too much of an issue? I'm not sure how the water warping is done though.
Pritchard, gl_subdivide_size 32 should get rid of the ugly seams, if you're talking about what I think you are, related to r_waterripple.
Something to try which might improve frame rate (GL or otherwise): r_mirroralpha 1 Using non-hardware gamma will also decrease FPS, unless the gamma and contrast sliders are all the way down (basically disabled). r_shadows decreases my FPS, so if you happen to be using that setting, try disabling it. I was thinking....
So, Mark V keeps a (somewhat hidden?) backup config.cfg file to prevent bad things, such as other Quake engines blanking out a lot of settings and such. This is both good and not so good.... The good part is obvious. But it can be not so good for some situations, like if I WANT to blank out my settings in my FvF folder... (they just get re-loaded from somewhere), and like above where I noted that when you play a new mod for the first time, things like "disable demo playing" should certainly revert to its default value (play the demos). So part of this behavior is taking away user control, and part of it is altering a default behavior that can sometimes be better to not alter. Anyway, here's my suggestion: Instead of using a hidden config.cfg file, just have Mark V create its OWN config file in the current game directory, perhaps named something like Mark_V_config.cfg And Mark V will automatically load the standard config.cfg file, then after that load it's own Mark_V_Config.cfg file. This is an improvement in my view, because: - The Mark_V_config.cfg file is easily editable/deletable by the user. - Mark_V_config.cfg settings will not be altered by another engine which messed with the config.cfg - Loading that file after the config.cfg will mean Mark V's settings will override settings that other engines have made (or erased) in config.cfg Mark V would still alter the standard config.cfg file (as is standard Quake behavior) so that any applicable changed settings will apply to other engines. Probably the special Mark_V_config.cfg file would be nothing but a duplicate of the standard config.cfg file... (which is probably functionally equivalent to your special backup config.cfg file, but it's stored in the same game directory now). And if a new mod is ran which does not contain a config.cfg or Mark_V_config.cfg, then the default settings should be applied (such as playing demos). If you wanna get fancy, then save all BASIC keybindings and aliases somewhere and let them carry over even if no config exists for a new mod. Extra fancy would be some menu option for this -- "Save basic config settings," "load basic config settings," "always retain basic config settings," or something like that within the Customize Controls menu (though I know how much you hate extra menus). Or perhaps some of this this might mean making another config file, much like R00k was suggesting in #1224 (which sounds like a great way to do it all around -- saving aliases and such automatically, and automatically switching to new configs when changing mod directories). So Mark V could write it's Mark_V_config.cfg which is basically a backup of the config.cfg, and also a Mark_V_user.cfg which will always be written to id1 and read no matter what mod is ran, which will just contain basic key bindings and aliases which would be unlikely to change from mod to mod. Though the Mark_V_user.cfg from id1 should load first in case the user has set up special key bindings for a mod -- such settings would then be read from the gamedir config files and override the basic user controls. Hm, then, of course, any key bindings made while playing a mod wouldn't carry back to the basic user settings stored in the Mark_V_user.cfg in id1, but that's actually correct behavior, in my view -- UNLESS the user uses that hypothetical menu option "Save basic config settings". Of course, if the user was just running id1, those settings would be saved automatically. So... in summary, and in order of loading: Mark_V_user.cfg (always in id1, contains key bindings and aliases, loaded every time even when running other gamedirs. Saved automatically if running id1, or by user selecting a "save config" option when he's running a mod) config.cfg (standard function, for cross-engine compatibility when possible) Mark_V_config.cfg (saved alongside the config.cfg in current game directory, backing up all Mark V settings and overriding settings that other engines made to config.cfg). All files are easily user-accessible. And like R00k suggested, configs should be automatically saved/loaded upon switching gamedirs. It would be better to discuss lit water after a couple of single player releases have the feature.
Would be proof that mappers will use the feature, that the compile tools work reliably, that another engine has achieved a stable implementation. When these maps exist in the wild and after the rank-file can play these maps and potentially report/discuss issues in engines that current support them, it isn't out of the "idea stage". Where are these maps? Until they exist, from my perspective they exist this is the same as talking about leprechauns or the Loch Ness Monster. Methinks the reason for the absence of such maps is exactly the fact that there's no proper engine support.
Right now - what, Darkplaces has it? FTE, maybe? I'm not even sure. People don't work with advanced engines here. And it's not exactly the kind of feature that you could squeeze in as an optional bonus for special engines. It affects the way the level looks a bit too much. I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler. But it is a chicken-egg situation; I don't have any way to know how my map actually looks with such an effect, since I know of absolutely 0 engines which support it.
I'm sure you can imagine that authors may have reservations about releasing a project with something that is "maybe it works and looks good here, but I have no idea since I'm practically blind". It's totally fair to not want to be the first/only engine with support for something, even if that is a little disappointing. I'm just concerned that someone will have to take the plunge with support, and given features like mirrors, I had hoped that Mark V might finally do it. the latest version of gl mark v runs really slow on ad_magna, while it ran fine on previous version that i had (mid december). dx9 version of the latest build runs it fine. what fps killing features did i miss previous month?
Just checked, the DP dev build render lit water:
https://icculus.org/twilight/darkplaces/download.html Add "-splitturb" to the tyrutils-ericw qbsp command line to get it. @pulsar - I guess I'll be double-checking the Open GL build come spring time to see if I did something that inadvertently caused a performance drop in Open GL.
Lit water is one of those things that seems like a great idea until you go poking at all the edge cases.
Yes, I implemented it, saw what it looked like, and got rid of it. I'm willing to add it to my DirectFitz thingy but please be aware of the following. An engine can 100% reliably detect if a map has lit water. An engine cannot 100% reliably detect if a map has not. That's because a surface not having a lightmap doesn't mean that the surface isn't lit in Quake. It means that it's in total darkness. This is the kind of "let's save maybe 200 bytes per map" thing that matters when you're trying to run on an 8mb MS DOS machine but that causes untold pain and suffering later. So a map with no lightmaps on water can mean one of two things: either the map doesn't have lit water (draw it fullbright) or the map does have lit water but the water is in total darkness (draw it with black lightmaps). Do you light lava? Slime? Do you add a warp effect to lightmaps? The lightmaps are a combination of (1) still, and (2) darkening the original texture, so the warp effect on the original texture is lessened. What about translucent water? Darkening the water will make it appear more translucent. Maybe we should decide that because light goes through translucent water it doesn't get lit. Should a map with unlit water still have dynamic lights added to it's water surfaces? And if so, is it OK that this would make the light seem brighter than on surrounding solid surfaces? -------------- These are probably questions that people can't answer until they see it and start exploring around it. Like I said, I'm willing to add it to my D3D9 FitzQuake port if anyone wants it that badly, but don't expect it to be a 100% robust implementation at present. I'm not a mapper and am crap at and with tools, so I quickly added lit water to something else I'm working on, just so you can see what it actually looks like.
http://www.quaketastic.com/files/screen_shots/LITWater/e1m2_litwater.jpg http://www.quaketastic.com/files/screen_shots/LITWater/e1m5_litwater.jpg http://www.quaketastic.com/files/screen_shots/LITWater/e1m6_litwater.jpg http://www.quaketastic.com/files/screen_shots/LITWater/e2m5_litwater.jpg http://www.quaketastic.com/files/screen_shots/LITWater/e4m6_litwater.jpg Mankrip said maps like e1m4 don't compile with lit water. This was months ago, maybe that changed.
Until someone steps forward proving any of this stuff works and is polished I would like to include lit water in my map - as far as I know doing so is as simple as setting a flag on my compiler. Man up? Maybe find the courage to actually use the compiler option? Maybe find the courage to load the map in DarkPlaces or existing engine that supports it? http://www.quaketastic.com/files/screen_shots/LITWater/e1m4_litwater.jpg
This, of course, is not compiled by any light tool. Do you light lava? Slime?
Should be up to the mapper. Do you add a warp effect to lightmaps? I wouldn't, but it depends on how you perceive the warping. Does it only represent horizontal movement of the substance, or does it also imitate vertical waves to a certain degree? Distorting the lightmap can help with the latter, I suppose. Maybe we should decide that because light goes through translucent water it doesn't get lit. Then it will glow on its own. So some of the HD backs from here: http://quakeone.com/forums/quake-mod-releases/works-progress/11588-hd-textures-sp-maps.html
fail with Only type 2 and 10 targas are supported message. I get thrown back to windows until I find the files and delete/rename. Of course I had to extract them from the pk3s but even re-extracting doesn't help. Example is +1wall58.tga from arcanum HD textures. I'll look at having tga files that aren't type 2 or type 10 just do console prints instead of errors in the future (next updates likely in the spring).
Erroring out to windows seems like overkill. Thanks for point this out. I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water. And yes, the turbs were split.
Man Up? It wasn't/isn't an issue of "manning up", at least not from my perspective. I'm fine with turning on a compiler flag. I just like to be able to see the results. Imagine compiling lighting for a map in general and never ever looking at it. Doesn't that seem like a daft idea? Perhaps you got the values all wrong, everything is too dark or too bright. But because you never look and see what the results are, you'll never know and your map will suck. untold pain and suffering Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case? The other way to handle that that I can think of right now would be to change the result based on whether there is ANY water with light data or not. If there is some, you could pretty safely assume that all water is supposed to be "lit", and so water surfaces without light data could be rendered black. If there is no light data for any water surface, then you could assume that it is not supposed to be lit. There may be a few edge cases there, but that would, I imagine, cover support for correct water rendering in 99% of maps, as well as allow for it in the rare pre-existing "lit water" map and all future ones. Also, I'd be interested in finding out why some maps refuse to compile with lit water? I've never had any kind of lighting setup outright refuse to compile on me. @Pritchard try this map in DP: https://www.dropbox.com/s/p0ixun0h0ajr4zy/lightstest1.zip?dl=1
Here is what it looks like for me: http://i.imgur.com/9rWWeR6.jpg I just like to be able to see the results. I couldn't figure out how to get the Darkplaces Autobuild from ericw's link to display the lit water.
Understood. ;-) I'd want to be able to see the results too. @ericw - that map works; the water is bright, and then it gets darker... and it's glorious. *hint hint, nudge nudge @Baker*
Now the question is why can't I get it working for my map? But that's something for your compiler tools thread, I imagine. Would it be possible at all for a compiler to actually write that data? Obviously it would increase file sizes, but would it necessarily break compatibility with engines if that were the case?
What I'm actually talking about is the 20+ years of existing maps that have this behaviour. Yes, of course, but if you could look at a map and say "none of these water surfaces have any light data, I should not apply lighting effects to the water", that'd be fine, wouldn't it?
Should water have fullbrights? The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.
Should water block light? It's possible for a surface to receive light but not block it - that's what doors & plats do. But if water blocks light it means scenes like the lava pit in start.bsp would be almost full dark - most of the light entities are inside the lava. I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting.
I don't think water should block light - it's unrealistic and would make extra work for mappers that they probably wouldn't see a point to doing. Perhaps lava should have fullbrights though - it might look good for that. I also think the issue with lava looking bad if it's lit can be counteracted with surface lights, although it is something that would trip up noobs... The stock ID1 lava texture is actually mostly from the fullbright palette ranges, a possibility that ID themselves had considered but rejected lit water.
I think the orange fullbright range is just the best color range for lava in the palette. I wouldn't be able to give advice on fullbrights for water without having seen it, but I imagine the answer is no. It would probably look like very ugly specular highlighting. It can be a problem with existing texture sets, since they were developed with an assumption that liquids are never lit (therefore there's a greater chance for bad fullbright distribution on liquid textures). But what if someone actually wants fullbrights on liquids? I'm a big fan of the idea of lit water
http://i.imgur.com/9rWWeR6.jpg That looks pretty good - although it's hard to tell from such a small blurry image, but I'm pretty sure it looks a ton better than regular water. should light block water The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea. What about directional considerations? In this shot, the water looks bad because light is coming up from below the surface, lighting the rocks, but the surface of the water doesn't receive it, so the water/rock transition looks bad: http://www.quaketastic.com/files/screen_shots/LITWater/e2m5_litwater.jpg To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think? Kinda like quake's window textures - if the light is coming from either side of the window, you'll expect to see light on the window surface. With tools like defullbright out there, it might not be such an issue with existing texture sets. Perhaps it would be best to render fullbrights for liquids.
Water would definitely have to be lit differently to normal surfaces, like Kinn describes. Again, that's on the compiler, rather than the engine...
was mentioned last time this topic came up, but the lightmap on water should probably get blurred a bit too - hard shadows would probably not look good.
I'm not sure how much this is a consideration, but...
To look better, the water surface would somehow need to be lit taking into account light coming from both above and below the water surface, I think? I don't use -soft, I'm not keen on that look nowadays.
On water though of course it's a different story. The only way of blocking light that would look correct, is if it affects the attenuation of the light trace as it travels through the water volume. That's probably a bit of a faff? Or could be easy, I have no idea.
Thinking about this it's probably not too bad. I'm not ericw, but I think when you do a raycast you can note the point when the ray hit a water surface and take that into account when lighting geometry under the water. I have raised this to "probably would want it" because consider an outdoor pool/lake - you have sunlight lighting all the geometry outside, but you want to dive into that pool and see the sunlight penetrates the water to light objects just below the surface, but as you go deeper, the sunlight fades to black... meanwhile all the fish at the surface are pitch black because they get their light from the floor trolololoool
I decided to stop talking and start doing.
http://www.quaketastic.com/files/screen_shots/LITWater/GPU_Lightmaps_Lightmapped_Water.jpg I think Baker's gonna need to make the judgement call on whether or not MarkV gets it, because it's pretty much all renderer front-end work. I'm 99% certain that the current back-end will support it without modification, but I'm willing to commit to any modifications that may be required should Baker decide to go for it.
Just various random thoughts
1. Mark V has optional stain maps (defaults on), like FTE, which uses the lightmaps. 2. I'm sure you already have this one taken into account, rotated and moved brushes. 3. Here's a more complex one --- fullbright colors in water texture + software renderer :( This isn't necessarily as annoying as it sounds and in-engine conversion of a water texture's pixels from fullbright blue to non-fullbright blue at map load is likely an option. I guess I'll need to look at the textures/palette, I hope there isn't a fullbright blue without a non-fullbright equivalent. 4. Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage. 5. Would be very helpful if ericw could mark the Did a quick palette conversion test of the traditional blue water to a non-fullbright palette. It's fine. Non-obstacle.
Lava will have to be fullbright because the software renderer doesn't have a choice except to use the Quake palette, and there are no non-fullbright versions of bright red. I don't really have an opinion on lit water.
I guess it looks ok in those screenshots. What I really wanna see is reflective water! But r_texprefix_mirror doesn't seem to do anything when set to a water texture.... About corner cases:
- Winquake.exe seems to be fine with the example lit water map I posted.. it doesn't have a problem with liquid faces missing TEX_SPECIAL. - The qbsp options "-splitturb" (and "-splitspecial" which is older) unset TEX_SPECIAL on the affected faces. The main problematic case I can see is a face with: - texture = "*water" - lightofs = -1 - styles = {255, 255, 255, 255} - TEX_SPECIAL is unset in the texinfo Do you render that fullbright or solid black in an engine with lit water? I think it needs to be rendered fullbright; faces with those settings will exist in the wild if anyone ever used the "-splitspecial" qbsp option. It would be worth checking how Darkplaces handles this corner case since it's the first released implementation afaik. So to fix this case, the light tool just needs to avoid writing those "implicitly black" faces for lit liquids. IIRC, mankrip requested that a while ago but it looks like I didn't implement it yet in my light tool. I think if I do that, we don't need any other kind flag to mark the map as using lit water. (presumably the engine should support mixing lit water and non-lightmapped lava) - Other rendering stuff: imo fullbrights should be rendered normally (for fitz engines, respecting the gl_fullbrights cvar), the lightmap should not warp (I'm imagining it as a shadow cast on floating leaves that are swirling around; the shadow shouldn't swirl). - Light tool stuff: there is already some handling in my tool that mankrip contributed; lit water faces can receive light from either above or below, and they don't cast shadows. This part I'm not so concerned about, it's easy to tweak with features as they are needed. Here's a more complex one --- fullbright colors in water texture + software renderer
That didn't even occur to me, but yeah - a GL/D3D engine can just not draw a fullbright, but software doesn't even have the option. Rather than remapping I think if it was me I'd probably do an extra colormap. Do non-supporting engines load lit water maps ok? It is sounds like they do, which would be an advantage Not a problem. Most of the work is actually changing various cases of "if (surf->flags & SURF_DRAWTURB)" to "if ((surf->flags & SURF_DRAWTURB) && !litwater)" at runtime, so load time is fine. Would be very helpful if ericw could mark the I think the don't know case was me being nitpicky more than anything else. It is possible but the probabiility is so low that I don't think you'd ever actually see it. What would be more worrying is bad tools setting surf->samples for a drawturb surface in a map that shouldn't have lightmapped water, because that's really the only way you have of checking, but I don't know if such bad tools even exist. Either way, providing an r_lightmappedwater cvar that the user can set to 0 can help with that. Water with garbage fullbright pixels is a texture pack problem, as it always was with garbage fullbright pixels. I don't think it should be solved engine-side. That would only complicate things.
Although not an official texture, *tele teleporter textures should probably be fullbright (not lit). Both Mark V and Quakespasm treat *tele textures differently.
dwere: Water with garbage fullbright pixels is a texture pack problem Sounds logical. tell the mapper to put liquid brushes in a func_group and then set all the different liquid lighting options on the func_group.
The idea isn't to annoy the mapper by making him manually set the rules up on each func_group - I assume there would be default liquid lighting settings that are used if nothing is specified, but...if you want custom light behaviour on a certain liquid body then you can func_group the liquid and set some options...
Beats having hardcoded arbitrary rules for teleport textures and whatnot imo. Do it like surface lights - have an entity whose sole purpose is to specify the light properties (aka override the defaults) of a particular texture, which then applies to all instances of that texture in the map. No need to use func_groups.
I only thought of this because with custom liquid textures used for random things like teleporters or energy fields, the texture names can be unpredictable (I think Knave has a *starfluid texture or something) I think the special entity could work, although I don't think it's ever been done before - with surface lights, it's a single key that specifies that the light it's on should be duplicated and spread across all instances of that texture. It's not specifically a custom entity that does anything different to a normal light.
This is quite offtopic, anyway... I'm slightly tempted to add an (optional) auto-jump feature where a player at an edge will automatically jump *only* if they can make the jump at the current speed *and* they are running.
If they can't make the jump and are running, the option would work like "edgefriction 999999" (if you don't know what it is, you might try it) and make it very difficult to fall off an edge. And perhaps have the option have an "automatic jump up" if forward progress requires a upwards jump that can be made. (Because pressing "jump" seems to be an annoying burden if you aren't using a mouse + keyboard). But is it similar to quake 3's awesome stair clipping. I hate q1's momentum loss around short floor variances
I can understand that this might seem attractive on accessibility grounds, but (and unless I'm seriously missing something) wouldn't it totally fuck with your game if you were playing with "always run" enabled?
I don't fully get it, but it sounds like a terrible idea.
Why don't you just make it a full bot so the player doesn't have to press "attack" in addition to not having to press "jump?" Because "aiming" is an annoying burden if you aren't using mouse + keyboard... or, you know, if you just suck at Quake :p heh. I know you're probably thinking about Gamepad controls, but still, meh. mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]). I know you're probably thinking about Gamepad controls, but still, meh.
I think he's talking about things like phones and tablets. Gamepad users don't have a problem with jumping. Touch screens is exactly what I thought it was too, where you might have left thumb to move, right thumb to look, tap to shoot, and ideally you'd like to be able to jump while moving and shoot while jumping but you're out of options for how to handle it.
mh, the "always run" menu option already fucks with my game by borking up my sidestep speed... AND Mark V changes it to default ON (that's an old complaint of mine, heh. [oldpage #1154]).
I'm not sure about the details of how MarkV implements this. I like the Quake 2 method which maintains a separate cl_run cvar and just multiplies the speeds by 2 if it's set. Seems less messy to me that Quake's faffing around with cl_forwardspeed. Any reasons why that hasn't been adopted (aside from "iiiiit's nottttt Quaaaaaakkkkkkkke", that is)? @Gunter - found your discussion of "always run" in the other thread; repeating here for info:
This is not a good setting to default ON. It's weird. It doesn't actually do what you'd think (make it like you're holding down the +speed run button) -- it just messes with your normal "walking" forward and back speed, but not your sidestepping speed, exactly. So you end up being able to run forward fast, BUT when doing so you sidestep slowly... EVEN AFTER you press the run button or use +speed in the console. Always Run must be switched off to get proper sidestep speed when running, even when using the +speed option (unless you make other settings, I guess?). Please default it back to off. A better fix would be to change the "Always Run" menu option to actually lock +speed on instead of whatever weird thing it currently does. This is basically what Quake II does. It's "always run" option, via the cl_run cvar, is exactly the same behaviour as the +speed key. In addition it has the following nice behaviour. If "always run" is off, pressing the +speed key will speed you up. If "always run" is on, pressing the +speed key will slow you down. Even nicer, it's basically (aside from cvar declarations and removing the old cl_forwardspeed behaviour) a one-liner: https://github.com/id-Software/Quake-2/blob/master/client/cl_input.c#L304 I'm coming more and more strongly in favour of this being something that should be standardized across Quake engines. Thus far, I've only seen one control scheme for touchscreen that was "ok" (Minecraft) but have some thoughts for improvement.
The difficulty of "getting it right" somehow increases the appeal to me. Mark V merely defaults always run on. Like what happens in the original Quake if you toggle it.
Gunter is arguing it should do more than that because turning on "Always run" in original Quake didn't also increase backspeed or sidespeed. Which I didn't do in Mark V because in my opinion it should use the FitzQuake definition of always run. So Gunter is arguing against the original Quake behavior, saying Mark V's "always run" should do more (ProQuake's always run sets all 3, for instance). +speed - I myself have never found a scenario where I would want to walk instead of run in Quake. Not in any of hundreds of single player maps. Not in any of countless of multiplayer games/maps. But I can describe scenarios where changing it to Quake 2 style is a behavior change in original Quake. I might be a bit of bad person in that I find both of the above kind of topics on the "boring side" of the spectrum. OK, I suspected that didn't come across as clearly as intended.
Just to summarize: Quake has two run behaviours, and they're both different. "Always run On" via the menus just bumps the values of cl_forwardspeed and cl_backspeed. +speed applies the value of cl_movespeedkey uniformly to all axes of movement. Quake II's behaviour is identical to +speed in Quake 1. Let's not get the idea that anybody is advocating for porting "Quake II movement" to Quake 1, because that's not happening. What Gunter is arguing, and I am supporting him in this, is that the Quake behaviours should be consistent. This is a simple matter of player expectation and principle of least surprise. If you have a "+speed" key, you expect it to have the same behaviour as "Always run On". I prefer the mark_v and fitz implementation of always run. I find quakespasm is too quick to judge when you strafe
@fifth - Agreed. And because Mark V is intended to preserve the feel of FitzQuake. Modern ProQuake does what Gunter advocates and it doesn't feel exactly the same to me. So I stuck with the FitzQuake way.
@mh - The behavior of +speed is described here Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg? My thought is this is already available to a user if they decided to do so. So it is not necessary to break defined and known Quake functionality like what, say, Quakespasm does. QuakeSpasm, Fitz and MarkV are all the exact same so far as strafing is concerned. No difference whatsoever in the code.
Devil's advocate: Why mess with a defined behavior? Couldn't someone who wanted +speed to slow them down instead set cl_movespeedkey 0.5 in their autoexec.cfg?
Sigh. That's not what I'm saying. That's a side effect, not the main thing. The main thing is an "Always run" option that's the same as +speed. You don't have to have +speed slow you down. Just change the "^" to "||" in the one line of code and it won't. Again: the main issue is that "Always run" and "+speed" behave differently. I am saying that they should behave the same. That is all. And incidentally, the Quake wiki is wrong. That's not what +speed does; all you have to do is look at the code to see that.
https://github.com/id-Software/Quake/blob/master/WinQuake/cl_input.c#L313 What +speed does, in the original Quake code, is adjust all 3 axes of the final movement. It doesn't modify cl_forwardspeed or cl_backspeed. What's described in the wiki is what "Always run" in the menus does (with the exception of the cl_movespeedkey part). You see - two different behaviours. One modifies all 3 axes: forward/back, up/down, left/right; the other only modifies forward/back. One modified after the full movement is calculated; the other modifies before. One applies the value of cl_movespeedkey; the other just doubles. if that's the case why does QS feel a bit twitchier on the strafing than Mark v?
I feel like I hit strafe in QS and I feel I have less control cause I shoot off so fast. I'm not trying to be an ass about it, genuinely feels different to me. I think I'm seeing where you are coming from now. Quake has a number of inconsistencies in that department.
Like how +jump is slower in water than +moveup. Quake is crazy like that :( I almost inserted the word "allegedly" when describing the +speed entry.
(As an engine coder, I don't trust a non-engine coder's description of what something does because they didn't use the code as reference. Although that page was made pre-source code release). Here is the "fucked up" thing.
Client movement is "normalized" (vector math). So if you mess with the sidespeed max, it affects your diagonal movement speed. This is (probably) why that behavior in Quakespasm doesn't feel like FitzQuake, because I think Quakespasm uses the same increases "all of them" that modern ProQuake does. Which to me doesn't feel like FitzQuake, which in turn is why I didn't do that in Mark V. And when I say "normalized" --- I mean that increasing the sidespeed max has the consequence of decreasing the effective forward speed max when moving diagonally.
So even slight diagonal movement feels different than original Quake/FitzQuake/Mark V in an engine that increases all the speeds like Quakespasm or modern ProQuake. I have used QS more frequently recently and that's due to the music not working again in mark v and also the twitch integration in one of the QS forks.
Currently using Mark V off-cam and QS on cam. So there's that I guess. I also have a "pure" quake folder with winquake and various folders with pretty much each engine. But I do have to re-adjust my thinking when playing in QS due to the strafe differences. It's probably not noticeable to most people but it's fairly jarring to me for some reason QS changed some stuff in 2013, I think it now behaves like you suggest (+speed and "always run" both affect forwardmove/sidemove/upmove, +speed with "always run" slows you back down to walking speed):
https://sourceforge.net/p/quakespasm/code/797/ (I don't understand why that "cmd->forwardmove /= cl_movespeedkey.value;" line was added though.) Baker, I play with always run on and do use shift to walk sometimes (e.g. useful for navigating narrow ledges to get to secrets). But I can see where you're coming from regarding keeping winquake / Fitz behaviour identically. I have a hard time noticing the difference between sidespeed 350 and 400. I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed.
FifthElephant, look on the old page ( http://www.celephais.net/board/view_thread.php?id=60831 ) at post #1154. That will explain why the strafing feels different in Quakespasm (or if you are using a +speed key instead of "always run"). I believe that's actually the correct behavior -- you SHOULD sidestep fast if you are running, so you can avoid rockets and stuff. I really dislike my sidestep speed suffering when "always run" is on. I know Baker has resisted making an adjustment to this behavior (which I believe is a flaw or oversight in Quake's original coding -- and I would much prefer it to be consistent as mh suggests), but my plea in that case it to leave the menu option defaulted to OFF (as it was in original Quake). It ends up being more config settings for me to return to Quake default behavior: cl_forwardspeed 200 cl_backspeed 200 +speed And I actually have a key bound like this: alias +slow -speed alias -slow +speed bind b +slow because sometimes I do want to return to walking speed, like if I want to position myself carefully to take a screenshot, or to get just the right sniper position, or if I want to build up a massive fireball for the Mage in FvF (his Delayed Fireball attack travels at walking speed, so if you are moving forward and firing them, you get like 4 of 5 of them all piled on top of each other, heh, for a massive explosion when they hit something). Touch-screen controls? Yikes. That would be tricky. If someone really wants to play Quake on their phone, I'd say, "get a bluetooth gamepad," heh. Like the Ipega 9055 that clamps around your device.... Yes, my bad, that was indeed changed.
It looks as though that line was added to prevent cl_movespeedkey from being applied twice, once from the menu code and once from the following block. Quake II drops the side speed default to 200, then when always running it goes to 400. I wonder how all of this behaves with values of cl_forwardspeed set in configs? Hey, what about a sort of compromise where the "Always Run" menu option would have 3 possible values:
Off Forward-Backward All Directions Regardless, anyone who doesn't like autorun behaving exactly like +speed can just set some cvars instead of using the menu item. Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg.
A reminder: cl_forwardspeed 400 cl_backspeed 400 cl_sidespeed 350 cl_upspeed 200 Those are the values for when autorun is toggled ON from the menu in the original game. If you want to be able to walk, set cl_movespeedkey to less than 1 and use +speed to slow down. Though you might want to set cl_upspeed to around 400 if you don't want to swim like crap. Being picky about EXACTLY how something behaves is experienced users' lot, and experienced users shouldn't have any problems creating an autoexec.cfg
When I first started engine coding I discovered "expert user bias". I was building modern ProQuake, I added a field-of-view slider that went from 90 to 110. Spirit said "I use 130 and the slider doesn't go that far". I wasn't for or against anyone's particular settings but it didn't take long to realize that accommodating all preferences while keeping things simple for the average user. Expert users can already do what they want. There are engines that try to appeal to all possible settings. ezQuake has a ridiculous settings menu with several pages and each of them scroll. Likewise, DarkPlaces has menus galore. I think this flies in the face of the KISS rule --- "Keep it simple, stupid!" "Keep it simple, stupid!" -- is why conservative engines rule and why advanced engines are frustrating. I probably shouldn't harp on this, but this is what I believe
Bad engine design expresses itself in the form of menus. Well, the thing is: an average user would probably prefer autorun to behave in a modern, convenient way. The problem here isn't even the fact that there are subtle movement angle differences. There are more jarring symptoms of hackery.
Like, turning the autorun ON doesn't invert it. In other words, you can't slow down anymore. I can't recall any game made in the last 20 years that would behave like that. Another thing is that the strafing speed is locked at 350, which means that you can't strafe slowly at all. Bad engine design expresses itself in the form of menus. This I agree with. Doom source ports are a great example of what happens when you pile up engine modifications and try to be flexible about them. Though the game was always at a disadvantage when it came to extending the gameplay functionality. There are also certain mod concerns with how the menu always worked.
Malice is probably the only example, but I consider it fairly important. Toggling "always run" forces certain speed settings upon the player, which is fine in Quake, but what if the mod wants different values? Having a separate variable would allow mods like Malice to have a (somewhat) working autorun toggler that wouldn't break anything. Just my two cents. Since I'm aware of the problem, it doesn't really affect me. But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.
Mark V is meant to be an equivalent drop-in replacement for the original Quake, except that it has Quake's definition of mouse look and always run on (instead of requiring a user to go to the menu). Mark V does not change any of the Quake cvars from their default -- aside from the always run defaulting on. But the behavior of Quake's always run is hardcoded in menu of the Quake engine. So whether or not Malice has different settings that option in the menu changes it just the same.
I know. That's the problem. I hope that at least QS will implement the Q2-like functionality (I think there were some plans for it), because what's there right now clearly isn't that. I actually kind of like EZQuake's menus, I remember installing it and spending a good 30 - 40 minutes messing around with all the different options to see what changed. Should totally add a 15+ page menu with every possible cvar on it to Mark V. /s
I thought ezQuake was the possibly the greatest Quake engine ever the version before they did that with the infinite menus and the laggy mouse driven cursor.
When it was like a FuhQuake with extra features, it had a simple menu that let you do many general settings. So at one point, ezQuake was quite a nice engine that was laid out so cleanly it was arguably the model of excellent engine design. Then they decided to add "Cool features" or something and it got all dorkulated. That Baker even added the extra menus that he did. I never expected much more than standard
I hated every second of it. I felt like I had failed.
WinQuake gun position as an option forced me to do it. I still try to think of ways to kill the preferences menu. Having additional menu items is fine, as long as the menu as a whole stays concise and organized. Not adding important things that regular users might need is about as bad as adding unnecessary junk.
For example, adding "previous weapon" to the controls menu is helpful. It's funny that you say that cause I agree, despite using that menu myself. Unreal had a little known secret menu hidden from the casual user. I think that is a good way of having a clean look but allows power users to tinker
The benefit of menus is that they provide the user with visible options that they otherwise won't know about (because they are hidden in obscure console variables).
Experienced users are mostly aware of these options, but Mark V has so many more options (with not-so-great documentation) that even I am uncertain I know all the options I may want to fiddle with. The "find" option in the console is certainly very helpful, but you have to know what you want to search for before you can search for it.... With a menu, it's like, "oh, that's an option? Neat, let's see what it looks like..." I don't think being "automatically anti-menu" is really the best approach. The problem may be that you've encountered some BAD menus, but that doesn't mean all additional menus are bad. It would be nice to have the Basic menus for the basic user, then perhaps some deeper level of Advanced menus for people who really want to tweak their settings (sounds like that secret menu FE just mentioned). I'm against "bad menus" myself.... I don't want things to get too cluttered up when I am trying to change some basic options. But I am not against having advanced menus with tons of settings in them, as long as they are clean and easy to understand and navigate. I think Quake is in a unique position because a lot of it's defaults are actually no longer sensible defaults.
That's at least partially on account of it's heritage - moving from a mostly-keyboard setup with no free looking, nobody actually had a clue how the game would have been played. It's obvious that ID had expected joysticks to be the predominant control mechanism. Just look at all the joystick setup cvars, the existence of a dedicated readme for joysticks, sample The existence of sensible defaults means that menu options are not really such a huge necessity. In Quake you need to either change the defaults or give the player an easily discoverable way of doing so themselves. "I do like the option to have +speed slow you to walking speed if "always run" is on -- it seems like I've encountered that behavior in one of the other engines, maybe Quakespasm or FTE. It's like, "why not?" because +speed effectively won't do anything if you are already running, so go ahead and have it toggle your speed."
I also have this behavior in Qrack, if your speed is > 300 then it will cut your speed in half, if its less then it will double it, both forward back, side as well. I'm used to pressing shift in modern games to "sprint" so it helps. Your quote of gunter -- that's actually probably the strongest argument I've seen.
Not the "other games" part -- I'm indifferent about that -- but the +speed "doesn't do anything if you already running". I somehow missed seeing that in the thread until now. Probably because where lots of comments in a short period of time. The core issue is that all of the cl_*speed cvars relating to movement have defaults of 200, with the exception of cl_sidespeed which is 350.
Most people are used to "always run" just doubling forward and back speed, so it becomes forward 400, back 400, side 350 and up 200 (up is rarely used). Doubling the speed on all axes, either via +speed or a Quake II-ish method, will increase cl_sidespeed further and cause it to dominate. Quake II changes cl_sidespeed to 200 and removes cl_backspeed. I'm not sure when cl_sidespeed was changed but I do know that cl_backspeed was removed in the last month before Quake II went gold, so that was a change made after Quake II was it's own engine rather than just an experimental branch of Quake. Quake II also changes cl_forwardspeed to not be saved to your config. I believe saving it was just a hack in Quake 1 so that the always run setting would be saved, but have no evidence either way. All of this is discussion points. I know which behaviour I personally prefer but I'm not trying to convince anyone else. So, does capturevideo only work when watching a demo? Or can it record "live" gameplay? I set my codec and FPS but it complains about them not being set when i enter the command. If it only works on demos, adding that explanation to the error text would be useful.
You can capture in real time, but capturevideo is intense and not necessarily a good fit for real-time capture --- it's going to be an fps/cpu hit and at higher resolutions the penalty gets stiff.
bind x "capturevideo toggle" Make sure you have the other capturevideo settings the way you want: capturevideo_codec xvid // I'd recommend this at least at first capturevideo_fps 15 // You can always increase it. Smaller resolutions like 640 x 480 are going to work better than larger ones because pixel count increases drastically. You may also wish to consider something like Bandicam which works great with DirectX which Mark V DX9 obviously is. Someone earlier in the thread said how great Bandicam is. "Quake II changes cl_sidespeed to 200 and"
no wonder i always though sidespeed was weird in quake 1. I played Quake1 freeware version all the way through, then later played Quake II extensively. Then came back to Quake 1. //R00k: i didnt want +/-speed with 'always run on' to eventually STOP the player, but instead toggle the speed from walk to run, or run to walk. if (cl_basespeedkey.value && cl_movespeedkey.value) { if ((cl_forwardspeed.value > 200) && (in_speed.state & 1)) { if (!(in_klook.state & 1)) { cmd->forwardmove += 200 * CL_KeyState (&in_forward); cmd->forwardmove -= 200 * CL_KeyState (&in_back); } } else { if (!(in_klook.state & 1)) { cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward); cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back); } if (in_speed.state & 1) { cmd->forwardmove *= cl_movespeedkey.value; cmd->sidemove *= cl_movespeedkey.value; cmd->upmove *= cl_movespeedkey.value; } } } else { if (!(in_klook.state & 1)) { cmd->forwardmove += cl_forwardspeed.value * CL_KeyState (&in_forward); cmd->forwardmove -= cl_backspeed.value * CL_KeyState (&in_back); } if (in_speed.state & 1) { cmd->forwardmove *= cl_movespeedkey.value; cmd->sidemove *= cl_movespeedkey.value; cmd->upmove *= cl_movespeedkey.value; } }//Phew! only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P no wonder i always though sidespeed was weird in quake 1.
Probably to make dodging easier for keyboard-only players. Once again, only somewhat relevant in 1996. Useless trivia: Chasm made itself look like even more of a Quake clone by copying this behavior. only issue i have with above code is when you set your speed cvars to something like 180 then you will go in the opposite direction with +speed :P Uhhhh, I have them at 160... So is that "reloading the level dead" bug specific to Mark V? I've been getting it a lot lately. Don't remember ever seeing it with QS.
<p>if (scr_center_lines <= 4)
y = vid.height*0.35; else y = 48;</p> This code always puzzled me. At modes larger than 320x200 the result is that centerprints more than 4 lines (including the e2 entrance message in start.bsp) will be rammed up near the top of the screen, whereas centerprints of 4 lines or less will be more accurately centered. This looks awful. There was some kerfuffle over the whole thing in the old thread. I believe I know the reason why. It's for the slow finale printing at the end of an episode. The give away is the positioning of the gfx/finale.lmp banner in Sbar_FinaleOverlay - it's at a y of 16, and when we add the banner height of 24 we get 40; 8 more pixels for a blank line between the banner and the centerprint and there's the 48. Why did Carmack do it this way rather than checking for cl.intermission == 2? Probably the same reason he did a lot of other crazy-seeming things in the Quake code - a rush to get things done and get the game shipped. Some further evidence: Carmack's
https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_year/johnc_plan_1996.txt#L3436 Interestingly he was also working on items relating to level transitions and boss/finale stuff on that day. "end of e4 text crash" was an item. So the evidence definitely correlates this change with work on finale messages. Well, like you said, he could have easily made it only apply to the "Congratulations" messages and not other Centerprints if he wanted, but he just notes in the changelog:
"changed center print position for very long text messages" And I'm sure he would have noticed the E2 entrance message being affected by this, since it's right on the Start map, so it's no accident. It just makes sense to me that any "very long" message would be moved up, out of the direct center of your view. I actually didn't know that the Congratulations messages were considered Centerprints -- they use different functions in QuakeC, but I guess the engine funnels them through the same printing method. I tested it and, indeed, an end level message of only 4 lines will be centered lower on the screen. Weird. If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do! Picked up a couple of new Mark V users last night -- some old returning FvF players (I'm talking old players from the 90s).
They said Mark V works much better for them than GLquake (obv!), but they were still having some connection problems -- and I've seen another player who has this issue on the server too (I think it's Mr. Burns who has this issue, maybe): When the level changes, they get stuck in the console and never reconnect to the server. We still see their names as connected players, but their frags are shown as "0." I believe we told Mr. Burns to try typing "ping" in the console when this happens, and that sometimes allows him to connect and get back in without having to totally reconnect and lose all his frags. I don't have any control over the server (Polarite does that), but it appears to be running "Magic ProQuake Server Version 3.90" in linux. I really can't provide much more information about this issue.... I assume it's one of those things where it gets stuck doing the "keepalive" messages in the console. I'll ask more specifically the next time someone encounters this -- it's only a few players, but it affects them consistently. Also, one of the returning players asked about mirrors -- he wanted to be able to see his reflection (mentioning that it was a pretty big deal/cool feature back in the day), and I told him mirrors only worked when running plain ID1... but I realized that it really SHOULDN'T be this way, as it violates what I think should be a pretty important aspect of Quake engine design: you shouldn't take away user control and force your own preference on the end user (even with good intentions). I mean, there are already various mirror variables that the user can set if he wants mirrors to be on or off (and actually, they should probably be off by default). If the user wants to turn them on, even in a mod or map where it might not work well, he should be able to do so. Also, for those users that want to play with mirrors, how about an easy way to set a mirror texture. Specifically, something like (probably used in conjunction with tool_texturepointer, but not necessarily): if you input "set_mirror" in the console, it will assign the mirror effect to whatever texture you are pointing at (manually typing in those texture names for the mirror texture prefix is a chore and prone to typos, heh). Of course, there's the issue of having to restart a map before it takes affect, but it would still be handy for people that want to play around with mirrors. I suppose it would be handy to be able to feed the pointed-at texture into any of the tex prefix variables, actually.... Not sure how that could be implemented, other than copying the selected texture name into the console and allowing tab to autocomplete the various things you might want to apply it to. Ah, yeah, it would work if you just had it stick "r_tex [copied texture name]" in the console and positioned the cursor right after r_tex, then tab will autocomplete all the various r_texprefix things with the selected texture already filled in. If he were just trying to position those end-level messages only, counting the number of lines would be a very hacky way to do it. that sounds like something *I* would do!
This is actually exactly the way Carmack coded a lot of things in Quake. How did he test to see if you were connected to a server and therefore the status bar should be drawn? By checking the number of console lines drawn. How did he test to see if a map was running? By checking if the console was fullscreen. Quake is full of crap like this. Sure, here you go: https://github.com/id-Software/Quake
Well that was unexpected. :/
The "semi-official" 32-player deathmatch map death32c, still available on ID's FTP server (ftp://ftp.idsoftware.com/idstuff/quakeworld/maps/) has lightmapped water. And the lightmaps are messed-up: http://www.quaketastic.com/files/screen_shots/LITWater/messed-up.jpg I guess this means that other maps with messed-up lightmaps on water surfaces may very well be out there in the wild, but in the absence of engine support for lightmapped water nobody was ever aware of them. You could control this with a cvar but that's pushing responsibility back to the player, which I don't like. Since lightmapped water is a new feature I suggest a worldspawn key indicating it's presence. That way engines that don't support it can ignore it. Engines that do support it can pick it up. Maps like death32c aren't subject to false positives. I wonder which compilers were writing that junk data? Worldspawn key has my +1. I've already forgotten all the discussion we had a while back, so I'm a clean slate on that (except for the point that it'd be really cool, that still stands).
check the styles. if there's multiple 0s then its clearly uninitialised.
while its possible for a light util to write multiple of the same style, 4 of them is basically pointless as it would oversaturate everything. check the styles. if there's multiple 0s then its clearly uninitialised.
Bingo, buy the man a large beer. I believe that these maps may have been lit with ID's then-unfinished qrad tool. DarkPlaces shows the same problem on death32c: http://i.imgur.com/vZjyDXC.jpg
I would lean towards a worldspawn key now as well, since there are no released maps using lit water yet. From the video code:
vid_modenum. vid_realmode. vid_default. windowed_default. vid_mode. DIBWidth. DIBHeight. WindowRect. mainwindow. dibwindow. _vid_default_mode. _vid_default_mode_win. vid_config_x. vid_config_y. window_center_x. window_center_y. window_x. window_y. window_width. window_height. window_rect. vid.width. vid.height. vid.conwidth. vid.conheight. r_refdef.vrect.x. r_refdef.vrect.y. r_refdef.vrect.width. r_refdef.vrect.height. glx. gly. glwidth. glheight. These are all global variables that are used to store what is essentially the same information. I don't even think I have all of them here. But all that you really need to store is the window handle and you can derive everything else from it. Sure you can potentially optimize by caching some stuff, but this crap reads like any time something was added to the video code, a new set of globals was added just for it. Of course they all have to be kept in sync and consistent, so any work on the video code is a tangled mess from the outset. I'm trying to host a dedicated server with this and anyone outside my network can't connect..
I love how faithful this client feels to the original Quake and I know netquake is tricky and not as ideal as QW but honestly QW feels OFF to me.. Any ideas on why folks can't connect? Tried dedicated.. noipx.. My ports are open, no firewalls.. I hosted a QW server last night without a hitch. Mark V should launch a single port server just like Quakeworld. Only port 26000 needs to be open. (Feature is essentially courtesy of Spike).
It could be the clients other people are using. By default, Mark V uses FitzQuake protocol 666 --- this means DarkPlaces and ProQuake cannot connect, for instance, since they don't support protocol 666. sv_protocol 15 is regular Quake. What you should do is try to connect to yourself from another client through your public IP. Also you may wish to do sv_public 1. ericw: I lean towards worldspawn key
If that's the best way to do Mirrors
https://www.youtube.com/watch?v=BSSnY9DfZ9Y If you want to play on that quickly assembled test map: http://quakeone.com/markv/media/hall_of_mirrors_test_map.zip Pulsar threw a mirror into Arcane Dimensions ad_magna map, but it is very difficult to find it because the map is huge. http://quakeone.com/markv/media/ad_magna_arcane_dimensions_1_50_setpos_2496_56_-292.png In Mark V, type "setpos 2496 56 -292" in the console with ad_magna loaded and teleport directly to the mirror ;-) Yeah, folks were using Mark V and could connect to my QW server just now.. haven't tried SV_public 1
The server does list my local IP rather than external, anything I need to do there? Also super weird... I can't connect to my own server anymore using localhost, 127, or my network address.. but I CAN join through the multiplayer public menu. No one else can see my server though.
Holy shit. I would love to read a compilation of "quake code nightmares" like this.
It's turtles all the way down. Add -noudp6 to the command line to disable ipv6.
See if that solves the problem, what operating system and version are you using? Like is this Windows XP or a certain version of Linux? I'm using Windows 10, it's definitely attaching to an ipv6 address so I bet that will do something. I'll try it later, thanks for the help!
I've seen that ipv6 oddness before, but not on Windows -- ironically, the iPad example doesn't like ipv6 when connecting to a server.
The next time I load up Windows 10, I'll see how it reacts to ipv6. Something I noticed with Mark V - Release 1.00.
When I first get into the game, my frames are all over the place for like 5 seconds and then it goes to normal, anyone know why? I'm on an AMD 480, Freesync with windows 10. Also an FOV adapt feature would be nice, Like the one in QuakeSpasm. Also an FOV adapt feature would be nice
Mark V uses a similar algorithm to fov adapt, although if I recall it is an mh variant (640/432?). Even the software renderer uses it. It can't be turned off, but since it is aspect ratio correct, I can't think of why someone would want to turn it off. If misunderstood what you meant, let me know. Cool I'm fine with that!
Also...being able to change mods/maps in game would be great...instead of just being able to change the levels. Something QuakeSpasm doesn't have, you have to use Injector. Injector works but seems it will never had a final version. Something QuakeSpasm doesn't have, you have to use Injector.
QS and MarkV both have this, the "game" command: game xxx exec quake.rc (optional.. loads the configs from the new mod.) In Mark V, you can type "install travail" or "install rapture" in the console and it will install Travail or rapture off Quaddicted.
You can type "install b" and press TAB and it will autocomplete one of the about 530 Quaddicted mods recognized. I'm just lettting you know these things. Like ericw pointed out, the "game" has existed for a very long time in FitzQuake and derived engines like Mark V and Quakespasm. there's a mirror in my explore jam 2 map as well. it's big and right on the mandatory route.
I do love this feature. I remember the mirror corridors section in Prey (the old one, who the hell decided to call the new game the same as the old one that did not have any siquel). I wish it could have been done in mark v, but it's impossible so far with one mirror at a time limit.
I still wish it will be possible one day. The calculation I used originates in a gamedev.net thread at https://www.gamedev.net/topic/431111-perspective-math-calculating-horisontal-fov-from-vertical/ and an online FOV calculator that used to be at http://www.emsai.net/projects/widescreen/fovcalc/ - the latter can probably be picked up at archive.org nowadays.
I just lifted the calculations over to the Quake engine. 640x432 was chosen as a baseline aspect ratio which everything is calculated relative to. This is GLQuake's default 640x480 less 48 status bar lines. Arguments can be made for and against different baselines. QuakeSpasm uses a different widescreen FOV calculation standard, and I'm not going to argue that either is more correct than the other. The great thing about standards is that there are so many of them. Still no one will comment on my bug :( should I try and make a demo of it or something? Do those even work when the issue occurs when restarting a level?
I think it's safe enough to say that nobody else has even seen that bug.
You might give a little more info. Map? Custom progs? Etc? I first mentioned this happening in post #1182, here's the link I posted back then: https://streamable.com/4an03
That's a RJ6 map, and I'm pretty sure that pack used original id1? Anyway, what happens is that if I die and click lmb to restart the map, I start the map "dead" like in the video. Except I can swing my invisible axe and make particles, also shown in the video. I'll see if I can make it happen again soon and try collecting more evidence. Here is me playing that map
http://youtu.be/JjmY5L5kROY Kinn was playing that map in WinQuake and he didn't say he had a problem with dying and spawning wrong. There are tons of QuakeC bugs (i.e. the progs.dat). A demo and a savegame would be something to go ;-) Yeah, I'll try playing some id1 maps tonight and see if I can get it to happen. I've had it happen both in that map and one other which I forget the name of. The other one was a mod though so it's not as useful.
I've experienced this numerous times (can't confirm the axe thing, never tried) with vanilla quake. I was unsure if the behavior was intentional and too busy to check.
The two new Mark V users played again tonight, and both experienced the disconnecting issue when loading a new level. One of them had fiddled with his firewall and thought he'd maybe fixed it, but nope. It only happened to them one time each. It's odd that both of them are having the issue, since they have different setups.
One is from Texas, one is from Canada. One is Win7, the other Win10. The error they said they got was "level load failed" One said he usually spams the console with "ping" to sometimes get back in... but I guess it didn't work this time. I told them to try and come here and post any more details if they could figure out anything else. Other than that, they really like Mark V, heh. You might need to adjust your server's connection timeout, and to be honest as a non-server operator I'm not 100% on how that's done.
Are they using external textures or lots of external fluff? (If they using the really high res versions of an external texture pack, the impact is going to be multiplied.) During reconnect, if someone is using a lot external textures it increases the load time and can increase it beyond the connect timeout. I've played a number of multiplayer games on your server. Never had any level change problems ever. But I don't use external textures except if I am doing testing that needs it. I think I found out how to repeat the bug: it happens when you die after reloading a save. Or at least a quicksave, I haven't tested with regular saves but I'd assume it's the same. Can anyone else make this happen, or just me?
https://www.youtube.com/watch?v=RO3WH0RL1kI&feature=youtu.be #1385
The "semi-official" 32-player deathmatch map death32c, still available on ID's FTP server (ftp://ftp.idsoftware.com/idstuff/quakeworld/maps/) has lightmapped water. And the lightmaps are messed-up [...] other maps with messed-up lightmaps on water surfaces may very well be out there in the wild, but in the absence of engine support for lightmapped water nobody was ever aware of them. [...] Since lightmapped water is a new feature I suggest a worldspawn key indicating it's presence. That way engines that don't support it can ignore it. Engines that do support it can pick it up. Maps like death32c aren't subject to false positives. #1389 DarkPlaces shows the same problem on death32c Just because mh, lordhavoc and others don't know how to reliably detect lit water, it doesn't mean it's impossible. Retroquad never accepts false positives. Cluttering the tools and engine code with a worldspawn key for this is pointless, and only serves to hide the fact that the engine's support for lit water is done poorly. Also, let me rectify Baker's false statement @ #1285: Mankrip said maps like e1m4 don't compile with lit water. This is false. What I said is that a few ID1 GPL maps such as e1m4 has countless leaks. This means that their VIS data can't be compiled, which has nothing to do with the lighting. I've already compiled it with lit water and no VIS ages ago, but I wanted to be able to get the VIS data compiled too. Until someone steps forward proving any of this stuff works and is polished The solution in Retroquad works flawlessly, is robust, clean and polished. But I try not to care about proving stuff for others. Nobody ever asked me about it, it would just make me seem bitter, and I'm sure I've already mentioned ages ago that the Retroquad implementation of lit water was finally perfect. Also, <a href="https://twitter.com/mankrip/status/774418444523606016">by the end of last September, EricW's implementation in the light tool was already perfect too. I've done extensive testing for him and showed it when the final problems got fixed. I always have net_connecttimeout set to 45 seconds, and I know the players with the connection trouble aren't using any external textures (I keep telling them they should try the external textures, heh).
It could very well be some issue with the server. It's just odd how it only affects certain players, and it affects them repeatedly, but nobody else. Extra odd how it affects BOTH these two new players.... Though the fact that it's known that typing "ping" in the console can sometimes get around it, would indicate that it's been a Quake issue for a long time.... I can't really provide enough information about it to really troubleshoot :/ I didn't know the GPL map sources for e1m4 had leaks. I thought when you mentioned the problem that it was a tool issue when using lit water.
Anyway, the conversation evolved a lot since then and yeah But my non-belief was largely due to the apparent non-existence of any known test maps. When avirox, myself and gb were working on true rotation, we made a number of test maps with QuakeC sources, engine sources, I guess if one of them could play using "developer 1" and also record a demo, then the next time they get the problem zip up the demo + qconsole.log, there would be some information to go on.
From your description about how typing "ping" helps, it sounds like a message got blocked by a firewall in a non-NAT fixed client. If I had a qconsole.log where developer 1 was enabled where one of these players had the problem, I might be able to learn more. I just now connected to your server, I don't experience this problem. And apparently you don't. At the moment, there really isn't enough information to speculate. I obviously can't speak for Mankrip, but I adopted Spike's suggestion of checking the styles too, and confirmed that they were all 0. Lightdata offset for these surfaces was also 0, so whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1.
My current tests looks like this: 1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces. 2) Check lightdata offset as standard; if it's -1 there's no lightmap so none of the rest applies. 3) As an additional check test all styles for 0 and lightdata offset for also 0; if this check passes then we have an uninitialized surface so also no lightmap. 4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true. 5) Finally when building the surface polys and lightmaps, I set surf->litwater to the value of m->litwater. It's clear what happened here; the code that correctly initializes the face for no light (https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L489) must have been removed from whicever tool was used for lighting this map. ericw: Detecting maps compiled with lit liquids.
mh: whichever light tool was used clearly left the surface uninitialized rather than explicitly setting offset to -1 That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above. My current tests looks like this: 1) Initialize loadmodel->litwater to false at the start of Mod_LoadFaces. That is bad. Non-lit surfaces are defined on a per-texture basis, and it's perfectly possible for a map to be compiled with both unlit slime and lit water, for example. The engine should not use a global setting for this. 4) Otherwise there is a lightmap; at this stage check if the surface has a water texture and if so loadmodel->litwater goes to true. There's no need to tie the engine's lightmap usage to texture naming conventions. One of the potential ideas I have is to implement support for non-subdivided unlit surfaces with regular textures: for example, surfaces using fully black textures (or textures with fullbright texels only) could be rendered much faster this way. the code that correctly initializes the face for no light (...) must have been removed from whicever tool was used for lighting this map. It was not removed, because what truly defines the lack of lighting on specific surfaces is not the face data. The map was correctly set to use no lighting. TEX_SPECIAL works cleanly. I guess the fact that it's unused in the engine made it easy to miss.
That's not a problem, because there's no need to initialize the surface cache parameters since they should be ignored on non-lit surfaces. See my code on the link above. I'm actually talking about the face having been left unitialized by the light tool, not by the engine. If you check the link I posted to LightFace (https://github.com/id-Software/Quake-Tools/blob/master/qutils/LIGHT/LTFACE.C#L489) you'll see that what it does is first set offset to -1 and all styles to 255, then does the TEX_SPECIAL check. A face with TEX_SPECIAL should also have offset -1 and styles 255. death32c has faces with TEX_SPECIAL and offset 0, styles 0. The only concern I have about using TEX_SPECIAL is that it's set by the bsp tool, not the lighting tool. This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL? nice catch, those water faces in death32c have the TEX_SPECIAL flag set on their texinfo. So I agree there should be no need to have special handling for styles = (0 0 0 0) and lightofs = 0; seeing TEX_SPECIAL is enough to indicate that they are meant to be rendered fullbright.
Lest my questioning be thought of as criticism, I'm actually really happy with the outcome of this. I was able to simplify a bunch of horrible code and the case where one liquid type is lit but another unlit just falls out naturally from it.
It's rare in Quake that the right solution turns out to be so simple, but this is one of those moments. Pritchard, awesome beta testing work you did in identifying the situation causing the problem.
I've identified and solved the issue. @mh @mankrip @ericw - pretty cool discussion sorting out the inner mysteries of lit water. It's nice to see lit water look like it getting closer to go "prime time" from the bsp editor to the compiler tools to the engine. I guess the only real outstanding questions I have are (firstly) relating to dynamic lights.
Specifically: should unlit water surfaces receive dynamic lights? Now, I would LOVE to put dynamic lighting on all water surfaces, lit or not. But it's admittedly easy for me because I've decoupled dynamic lights from lightmaps - it's just commenting out one line of code. (This also made it easy for me to add dynamic lights to BSP brush models.) The other one is interaction of lightmaps and translucent water. I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency. I think this has been brought up before, and I stand by what I said back then. Lighting translucent surfaces is the way to go. I think it would look more accurate, considering that surfaces which are semi-opaque (i.e. 99% of water/brush alpha uses) will still catch/reflect some light in real life.
Also, having to choose between lit water and transparent water would suck. This may be purely theoretical: are there any bsp tools that don't set TEX_SPECIAL?
The only one I know of is the -splitspecial flag from TreeQBSP (which is in tyrutils, as well as Bengt's TreeQBSP). TxQBSP (as well as id qbsp) always set TEX_SPECIAL for texture names starting with * or sky in map.c:FindTexinfo. I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again, but it seems pretty unlikely. The SQLauncher is AWESOME.
I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title. Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. The SQLauncher is AWESOME.
I've been renaming all my map titles in the Quake folder to the actual name of the maps, and I can just use SQLauncher to play them. It takes a bit more time renaming everything, but it's much neater. And you will actually the map title. Quake Injector is a bit buggy, I just prefer to download maps from Quaddicted one at a time so I know what I'm getting. mh: should unlit water surfaces receive dynamic lights?
In the software renderer, that's impossible; surface caches needs surface subdivision. ericw: I guess if someone happened to compile a map with TreeQBSP/tyrutils and used "-splitspecial", and then used whatever light tool was used for death32c.bsp, we could have false positives again It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces. The only problem would be the lack of backlights, which can be solved by recompiling the lighting alone, without modifying the BSP data. Specifically: should unlit water surfaces receive dynamic lights?
I'd say it's up to each engine. I'd personally leave unlit water without dynamic lights. I've pretty much decided that translucent objects of all kinds (water, glass, etc) don't get lit - they're translucent so light goes through them rather than reflects off them. So instead they're drawn fullbright but with translucency. I'm with Pritchard, IMHO semi-transparent glass and lit water should still get lightmapped. Fitzquake 0.85 does lightmaps on func_'s with the alpha key < 1, though I'm not sure how many maps make use of lightmapping on glass, Fifth & I exploited it in ad_tfuma.bsp for example: http://i.imgur.com/rhO6awC.jpg The logic, I guess, is that you can see shadows on dirty, scratched up windows. It wouldn't be a false positive. It would be a true positive, because the lack of the TEX_SPECIAL flag would make the light compiler treat liquid surfaces identically to regular surfaces. Ah right.. in that case, even the vanilla id light.exe would generate lightmaps for the water/sky. I guess a better question is, how many released maps (e.g. in quaddicted, or idgames) used TreeQBSP's -splitspecial option, and thus have lightmaps for their liquids? This would be a time when it's handy to have a mirror of quaddicted and run a script across all of the maps. I'm guessing the answer is "0". translucent water *has* to get lightmapped. In fact, the translucency is going to be essential to sell the lightmapping as convincing, otherwise water is going to look like pea soup.
If you can see the surface, then it reflects light. A certain amount of light passes through it, but not all of it.
Besides, like I said earlier, translucent objects (or any objects, really) glowing in the dark doesn't make any sense in a lot of cases. Wondering if this is even possible from an engine perspective? One of my answers in sock's recent survey post:
5. Are you put off by certain monster (horde) setups? No. I don't love excessive in-fighting though. It's frustrating and I wish modern source ports could have a "slider" for in-fighting. Perhaps: "never>rarely>normal" That would get very buggy very fast. Play a map like ad_tfuma, it opens with a bunch of infighting. If that was disabled it wouldn't be the same.
Infighting doesn't come from the engine anyway, it comes from the QC. It would be totally inappropriate to put any kind of control over it into the engine.
I was asking if it was feasible.
re: ad-tfuma Not sure if it would keep you from playing the map though? Also not really necessary in AD as mappers can add a key to suppress infighting. So it would really just be for vanilla Quake. As I asked: Wondering if this is even possible from an engine perspective? mh - why would it be "inappropriate" to add this feature to an engine? is planned and set up using triggers.
I'm not sure why you would want to alter this behaviour as this is my vision for the map. the logic of the game is in QuakeC
the monsters are in QuakeC the infighting rules are in QuakeC the only thing that the engine can do is put the slider in the menu I mentioned above this would be for vanilla Quake not AD and it's just an inquiry. Not trying to destroy your art. ;)
@topher yeah I get that's how it works. It was more of an academic question. Wondering if you could modify QC behavior through the engine. Apparently not. my guess is that it's possible but it will be hacky, bug prone and harder than modifying and recompiling a new progs.dat
Wondering if you could modify QC behavior through the engine. Apparently not.
Well the engine can change the QC, but that's not really the point. The logic that deals with infighting is all in the QC, so all you could really do in the engine is do something like a truly disgusting hack such as preventing self.enemy from changing on an entity if certain conditions are met. However, you could only reliably guarantee it working for id1 (the assumptions you make in the engine to make it work for id1 wouldn't necessarily be valid under any other mod), and any other mod being run under it could break in all sorts of subtle ways. mh - why would it be "inappropriate" to add this feature to an engine?
First read Kinn's answer just above - that covers the technical reasons why. Then read Fifth's answer because it covers the gameplay/modder perspective. I know you said that you were asking about vanilla Quake, not AD, but it's still relevant. Infighting is a designed behaviour of vanilla Quake - it's even mentioned in the Quake manual: Q: Did I really see two monsters fighting each other? A: Probably. Some monsters hate one another almost as much as they hate you. You can use this to your advantage (exercise left up to the reader). Infighting is game logic and the correct place to modify game logic is in the QC code. The engine should not try to inject modifications to QC code. I'm actually shocked and appalled that this even has to be explained. If you want to modify the QC code, the correct thing to do is... modify the QC code. Make a mod with reduced infighting and play that instead. If you really want such a feature then make your own progs or throw money/sexual favours at someone to do it.
I'd do it if you threw money at me ;)
I actually previously modified this behavior in FvF. I think my monsters only have a 50% chance of getting mad at each other if they hit each other by accident. If they get hit intentionally by another monster, then they immediately retaliate (they just check to see if the owner of the attack is a monster, and they sometimes ignore the attack if it was not intentional -- if the owner of the attack has you set as its enemy, then it was intentional and you return the favor). This cuts down on the monster infighting, so they can focus more on killing the FvF players >:D But it's still fun to try and get the monsters to fight with each other instead of them all turning their attention on you! Buy yeah, this is not something the engine should really be tinkering with. Except MAYBE as a secret hidden setting which is defaulted off; like a new, harder difficulty mode or something. But I think there are plenty of other issues Mark V can be addressing before adding something like that.... I could be mistaken but I think the infighting behaviour is slightly different in AD and they don't instantly change target unless you do a certain amount of damage.
could someone sent a config with basic graphics to to improve the fps (dx9_mark_v.exe)?
My notebook isn't very good, onboard video and etc. what's the command for save a config? My email: hmdbrandao@gmail.com
How can i put the Time (with high size) on the center of the screen? Tks everyone! The only major default thing that might help FPS is to disable mirrors (which really should be disabled by default):
r_mirroralpha 1 To always show the clock, set: scr_clock 1 (Baker, the help info for scr_clock is incorrect. It says 0 = deathmatch only, and -1 = never. That info is reversed). I think the only thing you can do to make the clock bigger is to make your HUD bigger, like: scr_scaleauto 0 scr_sbarscale 2 Onboard video is actually capable of running fast without needing to compromise on quality. The problem isn't onboard video, the problem is how the engine is coded.
One of FitzQuake's claims is "if you can run glquake, you can probably run Fitzquake". Unfortunately that means that it tends to brute-force certain things on the CPU where a more elegant, faster approach often exists. MarkV has inherited that tendency, so hence it suffers from the same problems. No amount of "go faster" config options can fix that; it needs a complete rewrite. It's a fallacy to think that the older API is faster with low-end hardware. Low-end hardware these days supports shaders and VBOs; really old low-end hardware still supports shaders and VBOs. Shaders and VBOs allow a faster renderer. I recommend that you run QuakeSpasm and run it with all extensions enabled; odds are that it will run substantially faster than DX9 MarkV, even on Intel hardware. Thank you Gunter!
With the command r_mirroralpha 1 improved something. My notebook is a Lenovo E520 - I5.2410 CPU 8gb ram, 128gb ssd with Intel HD Graphics 3000. Thank you mh too! I downloaded the QuakeSpasm, but the QuakeSpasm FPS is similar than MarkV FPS (200..300). what do you mean "with all extensions enabled?". Could you send to me some config? Thanks in advance! With an Intel HD 3000 that's going to be the best framerate you'll get. The only option you have is to lower your resolution.
"With all extensions enabled" means don't disable multitexture, don't disable combine, don't disable shaders, because hardware will run better with these enabled and QuakeSpasm is more sensibly coded than most. If you're doing nothing to disable these then you don't need a config, just keep things the way they are. I'm currently working on an engine that will probably run twice as fast, but it's not suitable for general use yet. Has anyone seen baker in the past week or so? :/
In other news, has this "transparent models" issue been seen before in any other engines, or is it unique to markv? Noticed it while playing today and I wasn't familiar with it at all beforehand. YouTube's video encoding is bad for analyzing such things, but it seems that there's a conflict with the skybox renderer, maybe related to the Z-buffer.
Thanks everyone for your answers. It really was just a curiosity and I learned a lot in just these few answers. The reason I asked here is that Mark V seems to be the engine with the most "out of the box" and unique features. I will look into a progs version. Maybe something exists or can be gleaned from AD dev kit.
Ya know, if you want to play Quake with the monsters being smarter, more dangerous, and not in-fighting as much, you should come play FvF ;)
We usually gather to play on Sunday nights.... http://fvfonline.com connect fvf.servequake.com Ok.... Another complaint about the secret cfg files overriding expected behavior:
I installed a clean copy of Quake and Mark V into a completely separate folder ("Quake1"). I ran it and got everything set up how I wanted it for THAT folder only. Then when I went back to my original Quake folder ("Quake") and ran Mark V, the resolution settings I had made for the separate folder were loaded... (perhaps other settings too). I do not like that, no I do not. All cfg settings need to be kept separate for each folder, and for each mod. This goes back to the stuff I was commenting about in #1276 with ideas for a better setup with these config files -- too much behind-the-scenes stuff not matching user expectation. It would be better if the Mark V config files were saved alongside the standard cfg files, and were user-accessible. I made mention awhile back about the overwriting of my configs and the "secret" area as well.
What if custom engine wrote their own "branded" config.cfg? EX: markv_config.cfg, fte_config.cfg, qs_config.cfg etc etc That way no one engine writes over another's config file. Also, there really is no need to complicate such a simple execution of saving a players configuration settings like this: C:\Users\damage_inc\AppDataRoaming\Mark\Vcaches\id1\config.cfg Especially given most are not even aware of it and simple browsing of folders doesn't even reveal it. All I want is a way to save video settings and only video settings. Having a mod load in 640*480 and move all the windows on my 3 displays one display across (apparently... Idk, it just gets weird) is beyond frustrating. I guess I should just force my res through launch args but still...
Has anyone seen baker in the past week or so?
Real life. ;-) You might have noticed "update sometime in the spring", "update sometime in the spring", "update sometime in the spring" Yeah, let's just say I have some action-packed awesome fun battles going on in real life, the kind of scale that makes my eyes light up for battle (heheheheheh). And that's where my attention is going to largely be quite a bit for the foreseeable future. But back on topic Here's something to look forward to in the spring!! Mark V - Mouse Driven Menu Video Mark V - TouchPad Tap Fire/Drag Look That plus whatever mh cooks up and whatever bite I have time to take out of Spike's Quakespasm Spiked apple. I still want to get 4 Player support going I always read all the posts. I said spring because spring is vague is allows lots of room for interpretation, hehe ;-) /But yeah, expect me to not consistently be around. But it doesn't mean I don't care. When time comes, I'll deep probe all the feedback. When the time comes I'll be thinking of your persistence in 3 weeks when I'll have 2 XBox controllers on a specific weekend and digging into XInput tutorials.
A year ago, I would not think I would be doing such a thing. ;-) Sometimes I also question what reality I am living in where I can actually do these things on a whim. A few years ago, I was quite the novice and I still don't entirely understand how I acquired the level of expertise I now have nor what induced me to make a software renderer version nor how I did the majority of it in 3 weeks. It's like "Flowers for Algernon". I blame hanging around mh and Spike. 5 foot away, there is a beer that needs drinking. I now must attend to this urgent matter /End slight ramble. But incredible things are in the pipeline for the next Mark V. Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic
Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic
I have the same trouble others mentioned with the app not launching on Mac. My Quake folder is in Applications, and has the id1 folder in there alongside Mark V Quake. When launched, I get a dialog that reads
"Your Quake folder should contain a folder named id1 with pak0.pak and pak1.pak. Opening folder and then I get "W_LoadWadFile: couldn't load gfx.wad Game data files are required to run; usually this means you need Quake shareware or registered version. Is Mark V in the proper folder? ()" Other Mac Quake files work (Fruits of Dojo, Tenebrae), so I'm confounded. It looks like the problem is with the Sierra Quarantine Attribute
Followed the instructions here, and all's working now. https://derflounder.wordpress.com/2012/11/20/clearing-the-quarantine-extended-attribute-from-downloaded-applications/ Suggestion: something that saves your most recent previously-used resolution.
So like, if I was in 1024x600 Full-Screen and I used the menu to change to 800x600 Windowed, when I press ALT-TAB it should take me back to 1024x600 Full-Screen (it takes me to 800x600 Fullscreen). I note that this already works in the other direction -- starting in a Windowed mode and changing to Full-Screen in the menu, then using Alt-Tab will toggle me correctly between those two modes. I'd like an actual permanent saving of the previous mode used (when it's a change from full-screen and windowed -- like save it in a CFG file) so that this behavior will persist even upon starting a new game. Then I could easily toggle between the windowed and full-screen modes I want to use, automatically. Hopefully in the next release, there will be better rendering for transparency...
http://i.imgur.com/myVGUmA.png on C:\Quake and the music is working on the game again. It doesn't like being on D:\Games\Quake for some reason.
Music is on mp3. I have an E:\ blu-ray drive and an F:\ backup external. ...despite being well under the vertex limit.
@Baker I posted a thread addressing the issue over at Quakeone, R00k sent me this way to get a hold of you. Did all the troubleshooting I could initially think of. Thought you might find this interesting: http://quakeone.com/forums/quake-help/quake-clients/13277-mark-v-crashes-certain-model.html#post174852 When this model is converted to strips and fans it comes in at 4284 vertexes, which overflows an internal buffer that's particular to MarkV and was introduced by the shadow code I contributed.
@Baker: increase MAX_LERPED_VERTS to 8192 seems to be one way of handling this because it's consistent with the other counts in gl_mesh.c; at least it means that if a model crashes this it will also crash other engines. Thanks for the reply mh. I had a feeling the culprit was right in front of me while scanning through gl_mesh. I'm more on the QC side of coding though, so I wasn't entirely sure what all I was looking at.
I just tried out Arcane Dimension for the first time, and I'm just blown away by it. I really want to play through each and every level of that mod, but there is something preventing me from enjoying it.
Up until now I've used the winquake version for playing quake, and while that is perfectly fine for the official quake content and my own maps it doesn't get along with high-caliber stuff like AD very well. On one hand there are graphical issues with transparency that are to be expected, but the performance also takes such a drastic hit from all the cool effects and increased polycount in every level that it's just not playable any more. The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse. Because unless I want to stare at a blurry mess, I need to render in my laptops native resolution of 1336x768 instead of stretched 320x240, which more than nullifies the benefit of hardware rendering in terms of raw performance. Why is stretching only supported in the software version? I know that most gl-based engines only support 640x480 as the lowest output resolution you can select in the menu, but it's clearly possible to render the actual game in resolutions much lower than that since you can adjust the screen size in the menu to achieve just that. I took a screenshot of the smallest screen size in hardware mark v at 1366x768, which results in the actual rendering resolution only being slightly larger than 320x240. If you would implement a feature that scales this window to fit the screen borders again, that would have the same effect as the stretching feature in software mark v, right? Is that how the feature works in that version? I can't judge how much work implementing this would be, or if it's even possible at all. It seems like it should work to me, but there very well might be hard limitations preventing the feature from being in hardware mark v in the first place that I'm unaware of. I just want to let the devs know that this feature would be huge to me and everyone else who loves chunky pixels coupled with smooth performance. I'm surprised so little people seem to play quake this way to the point where there is pretty much no support for it, software mark v being a rare exception. Most players seem to prefer resolutions that utilize every pixel of their screen, but I just can't enjoy quake that way. It has nothing to do with nostalgia in my case, I missed the pixel-period of gaming by quite a bit since quake is actually slightly older than me. It just feels so much more alive in low resolutions. It has to do with how everything is constantly changing shape as you get closer or farther away from it, for example how particles blend seamlessly with the chunky environment, choppy animations seem to flow naturally, flames look like hand-drawn sprites at some distances or how you sometimes can't even tell what monster is waiting for you at the end of a dark hallway. Viewing lava and water at an angle also look incredibly organic due to this, even though they're just a single texture tile repeated over and over. If you look at all these things on a high resolution with interpolated textures and lerped animations, that magic feeling completely fades out of existence. You suddenly see everything very clearly for what it actually is: simple brushes, blurry textures, and crude animations. It feels like looking behind the stage even though you're actually still looking at the stage. That is apparently just what happens when you force a game two decades old to conform to today's graphical standards. It should look objectively better due to the modern improvements, but it just doesn't, not to me at least. I don't want to bash on everyone how enjoys quake at normal resolutions though, even if I'm coming on pretty strong here. I'm really happy that quake has evolved into something that can be so many things and has an engine for pretty much everyone and their personal preferences, and I'm thankful that even less popular ones like mine are represented to some degree in the community and in mark v, even if just in the software version. I'd happily do the work of porting the feature myself, but I lack any kind of knowledge that goes beyond the very basic level of fiddling with quakec and have no idea where to even start tackling things related to rendering, making this plea to devs my best shot at getting the quake engine of my dreams for now. I'm gonna keep learning more about quake development and programming in general though, it's just going really slowly since I'm far from being a John Carmack and feel like I'm up against something my puny brain can barely comprehend whenever I look through the source code. Guess that concludes this wall of text, thank you for sticking with it me the end. :) This makes me want to try playing at that resolution. I hope you get your wish for increased support!
setting these cvars:
r_lerpmodels 0 r_lerpmove 0 gl_texturemode gl_nearest should make MarkV/Quakespasm closer to what you want, other than the resolution. Yeah, this is a good request. So to summarize, the ability to render at a res like 320x240, and then scale (unfiltered) to a higher resolution (lcd native res). there is a gl version of Mark V winquake which has resolution scaling.
I didn't read the wall of text, maybe I'm missing something? I read the whole text and @killpixel, yes, boristhesp1der did try running Mark V in Winquake mode. But that didn't run fluidly in AD. He's looking for a Winquake alternative that runs AD fluidly while playing in a Winquake 320:240 resolution. This is essentially what you wanted to say @boris?
320:240 is my thing as well, at least when I play the original maps from ID. I use the Mark V Winquake for that because it supports folder-music instead of CD. As for modern maps I use Quakespasm with gl_texturemode GL_NEAREST_MIPMAP_LINEAR because everybody knows that GL textureinterpolation looks rubbish with Quake's low-res look. bummer. Well, he could try Darkplaces. HEAR ME OUT.
there's a retro shader for DP floating around. along with that try these: r_viewscale gl_texturemode gl_nearest force r_lerpmodels 0 r_lerpsprites 0 should give him a fairly retro look until he find a more faithful alternative. The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse.
This is the way things are going to be so long as MarkV uses glBegin/glEnd code. In an ideal world scenario: MarkV would move to vertex array and VBO code, the D3D version can be scrapped (because bad GL drivers are no longer an issue once you start coding sensibly to begin with) and better GL ES compatibility would come about as a bonus. Resolution scaling won't help much with this. It will help with fillrate but with glBegin/glEnd code it would still be pushing the same amount of vertexes and draw calls irrespective of resolution, which is where the real bottleneck is. Call to action: get on Baker's arse and get the glBegin/glEnd code killed. Since rendering is the current topic, what are the chances of getting proper transparency depth in Mark V?
http://i.imgur.com/eMcO57f.png It's thankfully not too obvious in my map yet but it is pretty annoying. @boris - I've been impressed by your ability to self-solve issues (main reason why I am posting since I'm mentally not here, yeah you really impress me). Open GL can't really scale pixels when rendering, although since I'm not AAA+++ in rendering someone may mention a frame buffer trick or shader trick with 6 asterisks next to it.
@pritchard - you didn't state the problem and I'm not level 25 at mind reading, only level 22 although I aspire to be level 25 some day. If it is depth sorting, the answer is yes! because that is on my list. @mh - "glBegin/glEnd" It kills my soul somehow. I've actually not eliminated glBegin/glEnd for Open GL ES. I created an extra renderer Open GL ES "wrapper" that throws them in VBO. ;-) That being said, yeah I agree in principle. (Insert: I'm probably 6 weeks from doing an update even though technically I have one ready, is there is an update to remedy alpha entity for D3D? No need for an immediate reply, just planning ahead a bit). @adib - "just a matter of turning on "pixels" mode? Forgot how to do it." --- It's in the video options menu. @fifth - When Spike sees what I did, he'll fucking hate me. Spike's skill > Baker. Baker's creativity > Spike. I admire Spike. I plan to smoke him a bit. It's not all what your powers are, it is also what you can do with your powers. @Spike - "oggs" --- In real life, no one has ever heard of an "ogg". It's a technically inferior poor man's mp3 used in a few Quake engines --- no where else in any game or any medium is an "ogg" a format a ordinary user has ever heard of. The mp3 patents have expired. Ogg have no future. The Unreal Engine doesn't support ogg. The iPhone can't play an ogg. The Anroid phone doesn't do oggs. There is no future for ogg. The question isn't why DarkPlaces doesn't do mp3. No actually that is the question. I like it when someone complains about the lack of ogg support in Mark V. When the next Mark V comes out, I expect mega-tons more complaining. Complaining is awesome. Because complaining is the backbone of progress. that makes OTP and Shambler the most progressive people on this forum... ;)
Nah seriously, can't wait to see what stuff gets added this year. I agree about Ogg. I used to be a fan when the MP3 patent was restricting people but it's served it's purpose now. Yeah, there will be "mega-tons" more complaining.
Because the next release Mark V will be the first true "5 platform" engine. The iPhone/iPad and Android. And for anyone who has watched any of the videos, yeah Mark V just happen to run on a mobile platform --- it will run fucking awesome on a mobile platform -- in a way no one has ever done. And it will be a stealth release. A. Like the past versions of Mark V, I will make nominally a zero effort to promote it. I'm not looking to mainstream Mark V, this engine is meant for those few of us left that enjoy Quake for what it is. B. iPhone App Store. Yeah, I'm not doing that. Someone with a Mac doing a self-compile and share amongst friends is how that is going to work -- in a best case scenario. /Six to Eight Weeks Probably a Ground Break Release. Six to Eight Minutes -- my ETA for a beer run. Ill-advised post? Aren't they usually? Haha. Cheers! Shambler is a complainer who has put blood and sweat and intellectual sophistication and effort into his passion. I once got into an argument with Mugwump and he said "You are the opposite of Shambler" and I was like "Well, I hate to say this but I probably agree with him on nearly everything
/I now resume my end-of-night beer run. but it's usually the way things are said rather than what is said that can be irk-some. :P
I think if you're doing mobile platforms it will be interesting to some but control is definitely going to be the biggest hurdle to overcome. is there is an update to remedy alpha entity for D3D?
Remind me again of what the issue was? There's quite a bit of chatter about alpha stuff in this thread, with the most recent I recall being depth sorting issues, which aren't API-specific, so I'm unclear on this. Kind of a bummer that scaling on hardware is out of the question though. I'm still gonna share the mockups I made though, so you can actually see what I had envisioned for yourself.
https://drive.google.com/drive/u/0/folders/0BzKtjR7p3BXdRnRHVTd1QVVhak0 I just scaled screenshots from regular mark v down to different "integer fractions" (sounds weird but I don't know the proper term for that, I mean scaling in such a way that the resulting resolution contains no decimal numbers in both axes) of 1334x768 to make them look software-rendered. The result is actually pretty different from the real thing for a number of reasons, the most obvious being atmosphere. Coloured lighting and fog really make a world of difference, and this screenshot alone doesn't even do that statement justice. In the unlikely case anyone is actually interested in this, I noticed a few interesting things making these mockups. Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software. The skill pillars and everything at their distance looks noticeably worse at 3x in reality because software quake starts to blur out the textures at a certain distance from the player, which is unfortunately not quite far enough away for the transition to happen seamlessly. (Fixing that would be a fun project, eh?) You'll notice that as the scaler increases, there start to be more versions of the same mockup with numbers attached to them. Those signify how the picture was scaled from the original, which can make a world of difference in the end result. 1 means scaled down in 1 step from 1344x768, 2 means first down to half at 672x384 and then to the end result, 3 means first half, then third, and then end result, etc. Most of the time one step looks the best, but sometimes multiple steps actually preserve some details that would otherwise be lost, like the metal edge on the lower step of the stairs. I also had this anomaly for the 6x scaler where no matter whether I scaled from 1x or 2x, the result was exactly the same down to every last pixel. That doesn't happen in any other scaling scenario. Thought it had something to with scaling from an even to another even scaler at first, but it didn't work for 4, 8, 12, or 24. I used GIMP to scale the whole image without interpolation, so If anyone can explain what happened there I'd be interested to hear. On somewhat of a related note, and since problems with transparency are hot topic right now, I'd like to present you the following: http://imgur.com/gallery/zqaX5 Is there a way to get software mark v beefed up to deal with this? I don't know if the crash is actually caused by those transparent textures, but that level (foggy bogbottom) runs (for a few seconds at least) far worse than all the others and is the only one filled with them, so it's probably not that far fetched. is a feature I wouldn't mind included if it was ever possible. I like the blocky aesthetic
Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software.
Heh, the candles don't change because hardware/software - they change because the candle entity is deliberately set up to spawn a random version each time (they come in many variations of tall/short/thick/thin) The skulls changing size though is some funky shit - why is that happening? For what it's worth, hardware resolution scaling is possible. Never said that it wasn't.
You do need render-to-texture to do it with best performance, which means OpenGL 3.0 or GL_EXT_framebuffer_object. A slower GL1.1 path involves a glCopyTexSubImage call. The point that I need to be absolutely clear about is that MarkV's bottleneck is elsewhere, so hardware resolution scaling would give marginal improvements to it. With e.g. QuakeSpasm it would be worthwhile for cases that are fillrate-bound, but MarkV isn't fillrate-bound. MarkV is CPU-bound. Is regular Mark V also rendered on cpu? I just assumed a gpu was a requirement for opengl. So Mark V essentially emulates gpu-features on a cpu? Is that correct? I don't know enough about this stuff...
That certainly would explain why performance is so bad. Apparently my poopy laptop isn't at fault after all, I just tried running those levels in quakespasm and they run at a stable 60. I hadn't even considered that to be a possibility, mostly because my laptop struggles to run just about anything that came out in the last 15 years. By CPU-Bound, mh means (I think) that the performance limiting factors in markv are operations that are always done on the CPU in all games.
I'm no graphics programmer, but as I understand it, the CPU has to explicitly ask the GPU to draw each frame. If it takes too long, it won't matter how fast your GPU is because it's just sitting idle a lot of the time. Quakespasm sends it's draw calls in a different way to markv which means that the GPU can always be busy, or at least busy more often to the point where upgrading your GPU will make a difference. I might be wrong about all this so take it with a grain of salt. Thanks Pritchard, that explanation seems a lot more likely than mine. The difference it makes on my system is batshit crazy though, that's why I thought it had to be cpu rendered. While mark v sometimes dips down to less than 10 frames in busy areas you won't even notice as much as a hiccup in quakespasm.
I guess I'll have to switch engines for now, I'm gonna miss you zoom button... :( Pritchard has the right of it.
When drawing objects, every single component of every single vertex has CPU overhead in MarkV that doesn't exist in QuakeSpasm. For any given scene this overhead is based on the number of polygons and number of vertexes in the scene, so it's fixed irrespective of resolution. Small scenes - like in ID1 maps - are barely affected, which is why it won't be noticeable if all you ever do is e.g play DM3. As the polygon count goes up the overhead gets more and more. Baker what features and stuff do you think you might want to implement in Mark V's next release?
(Crazy and Stupid) Ideas: Atleast try to support orl's Zeangala map or what ever its called.Who knows,someone might make an adin1 like bbin1 Create feature like in reQuiem (Might need to check this one) Music command like in QuakeSpasm Some proper coding! So far I know 4 coders doing engine stuff 1.MadGypsy 2.Baker 3.Spike 4.LordHavoc Does anyone know why the skull models change size between the different resolutions? That's some crazy beans...
Sort of, at least. In a proof-of-concept way.
https://www.youtube.com/watch?v=aJJ8005Ig0A&feature=youtu.be The video makes it look pretty crappy and stuttery, but it actually runs and feels awesome. The only real downside to this method is that you have to be incredibly careful not to make any sudden mouse movements, that causes the borderless window to stop capturing the cursor for a fraction of a second and the magnifier will register that movement, jerking the viewframe in whatever direction you happened to be aiming. Keyboard aiming it is then! I can handle that. Probably. So you mentioned that 4-player splitscreen is a thing you want to implement in the future? How about 4-player splitscreen that also allows people to join from the internet?
I have been playing a bit of the remastered Turok 2 from Nightdive and this has the same feature. It's a good way of getting people online and playing! ... is also good at that: I created some custom sounds and background loops a while ago with it.
It is not a freeware, but it has a lot of interesting features. How about a Text Contrast adjustment that will only affect the text (maybe like the texture baked-on gamma/contrast).
The dull text can be hard to read in front of all the other dull colors in Quake.... I don't want to universally ramp up the contrast for everything, so it would be nice if I could just adjust the text contrast alone. I was running an ancient version of dp then fte before mkv. in those I was using a conchar file that had black outlines and cleaned up characters, the diamond grip numbers, and conback from qtest. I had obtained these from gfx.quakeworld.nu quite some time ago all for clarity and legibility sake. Is there any way to have mkv load external wad assets, or does it perfer certain fyle tipes such as pcx?
Mark V only supports
For instance, throw this file in quake\id1\gfx folder (conchars.tga). Random comments: Gunter should be using a custom charset ;-) He could adjust the contrast in an image editor and self-serve. If your custom gfx are in
DP/FTW will use a loose id1/gfx/conback.lmp (conchars, etc.) in preference to the one in id1/pak0.pak, but vanilla engines including MarkV require you to put them in a pak file (e.g. create a pak2.pak) in order to override the stock ones. Everything was in a portable network graphic format so I just used gimp to patch them over to targa. I also increased the color saturation levels of everything and added black borders to the hudnumbers as well. Another thing I noticed after this was if you disable the start demos it just dumps to console, is there any way that it could pop the main menu up as well? I also saw a sort of custom start demos command but I couldn't get it to operate.
Akira, just put "menu_main" at the bottom of your autoexec.cfg file if you want it to pop up automatically upon game start.
Wow, that custom conchars.tga is definitely high-contrasty-more-legible in the game... buuuuut it doesn't look like Quake, heh. I guess I can mess with the contrast and make my own custom conchars, but it would still be nice to have such a feature built in. this is the one i use, and Gunter will approve!
http://gfx.quakeworld.nu/details/196/original-conchar-simplified/ edit: what you CANT see by that image is that the characters have a thin black outline around them.
Unless I selected the wrong file. Or just look in Qrack's pak0 for charset-3. Not bad... (had to convert to TGA for Mark V, but it works). That's more Quake-like than the one Baker linked, but I'm very picky in that regard, heh, and it's still not quite right.
I came up with this one by just ramping the hell out of the brightness/contrast so the text really stands out, but it's otherwise still the original Quake characters: http://fvfonline.com/conchars.tga Just a heads up, Baker. Looks like the cvar scr_clock still allows the game time to be drawn when set to -1 if playing DM (it does disable in SP).
Wouldn't normally bother me but it overlays on top of the player colors (the mini-scoreboard when viewsize is set to 120). I've come across a few bugs. The first one is in mutiplayer the ping command doesn't seem to work, I tried ping 100 and ping +100 but I don't see any changes on the scoreboard or latency. It seems to be in there though as it doesn't come up as an unknown command. The second is single player that when you die and instantly hit space to respawn your view remains sideways, I'm not sure if it has any relationship with quicksav or being splattered. The last one I've had happen a couple times first on some map from 1996 then in ad monsters spawned like brushes I was using quake injector.
1) There is a loadgame + death bug reported by Pritchard. Will be fixed in the next release (already fixed in unreleased code). Results in the deadness issue you outlined above after loading a save game.
1) ping +x is not supported (ability to lag yourself). Feature exists in ProQuake/DarkPlaces/Qrack, but adds some complexity/ugliness to maintaining the network code. Possible it may get added at some point. Doesn't have such a feature, which AFAIK is intended for real time lighting.
Arcane Dimensions quake.rc has r_useportalculling 0 and Map Jam 8 users needed to turn off r_useportalculling to avoid issues with DarkPlaces. Arcane Dimensions finds it necessary to turn off r_useportalculling in the quake.rc file for gameplay or visual compatibility reasons. yeah, "r_useportalculling 2" breaks map if you have some Warnings/clipped portals during VIS. It's very annoying, but 50% of fault lays on mappers side ;)
I was just curious if there are any VIS improvements in your engine, or do you plan any? As we know VIS in Quake is very primitive and does it's job poorly, so you have to do tricks etc. to limit r_speeds. The idea the engine would do the same thing as vis (which can take untold hours to run in some circumstances), and do it better and do it instantly on map load doesn't make sense.
I'm just saying Yes Quake vis sucks terribly, especially at open maps. Kills frame rate, makes demos huge --- like the 10 GB "I played Arcane Dimensions!" demos, makes QuakeC slows, makes map uncoopable with enormous network traffic. The correct solution is improvement of map compile tools. /Maybe you should get together with other interested parties and raise a $2500 bounty and try to induce someone who writes tools either in Q1 or in Q3 or at id Software or for another game engine to get Quake vis right or vastly improved. /One idea. I'm often wrong about these kinds of things. I agree Baker, the only problem with vis, IMHO, is the thing where certain uses of func_detail can cause vis to see through your map where it shouldn't. I'm not sure exactly where the problem lies (qbsp or vis) but I'm sure it's fixable.
Unless the problem I mentioned leads to exaggerated PVS in AD maps in a lot of places, vis is not really to blame for large demos in AD and the large unreliables, that's just the particle system based on entities and lack of use of static entities combined with protocol 666. Yeah, my main complaint are open spaces. I know how to optimize vis for indoor maps.
I did hedge maze and of course everything is rendered, because of open space above it... I'll have to add some obstacles to separate sectors better, or try some hint brushes, but I think hint won't help in this case. Best option would be occlusion culling like modern engines do, but of course it's impossible with BSP. Anyway thanks :) PS Btw. how different is Q2's VIS? (except doors blocking it) and how much we can borrow without a need to upgrade BSP ? :D ericw, you've done awesome work with the tools so this isn't directed at you. It isn't your responsibility to fix vis. You are a volunteer. This isn't a reflection on people that do the great work on the tools.
But yeah vis is certainly to blame. It is supposed to block faces and entities from being drawn. That includes things like AD particles. http://quakeone.com/markv/media/ad_mountain_r_lockpvs.png http://quakeone.com/markv/media/ad_mountain_r_lockpvs_directq.png http://quakeone.com/markv/media/arwop_roman1_r_lockpvs.png http://quakeone.com/markv/media/r_drawworld_0.png /I don't like thinking about it because it is very disappointing. Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy. Dead horse, I don't wish to beat it. I won't be bringing up, and I didn't raise the topic this time either. Nor do I seek to bring it up. Kreathor brought it up, haha. He's the bad guy.
Yeah but I haven't brought it to blame you guys, but to ask if there are some better solutions on the horizon and what can we do to improve this situation. I saw that Mark V has some nice features, so I thought I'll ask if there are some features supporting VIS... Speaking of raising a bounty I'm in, but... Considering I'll give $100 I'll have to find other people willing to pay $$$ to get $2500 in total, which probably is impossible, so I think it's time to finally dive into code and see what we can do in that matter. Reporting problems is only a good thing in my book.
Wow, ad_mountain's vis looks really broken. Assuming the player was in-bounds and then you used lockpvs and noclipped outside? The ARWOP screenshot doesn't look too bad to me.. assuming the player was at the start position when pvs was locked? Also I am 99% sure ARWOP predates func_detail being used commonly so it would be immune to the bug that can cause total breakage (vis seeing into entirely separate areas). The last one of ionous/pulsar's map, I'm not sure there is much unneeded stuff, that's a big open arena type area. Another point to remember at least with Quakespasm, it has the anti-flickering patch so if an entity exceeds MAX_ENT_LEAFS, the server will always send it. So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render, and it'll look like VIS messed up but it's just a server quirk. So testing in Quakespasm, large bmodels that exceed max_ent_leafs will always render
Yeah, I wasn't trying to draw attention to the bmodels. Although those aren't Quakespasm screenshots Mark V uses the same mh/spikey solution. @kreathor. Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch (files on the Mark V page).
Mark V supports sv_cullentities 2 -- which on poorly vised maps can cut-down on network traffic substantially and (sadly) increase rendering speed. sv_cullentities from essentially borrowed from FTE (although I may use R00k algo?) and DarkPlaces has a similar feature. It also has r_lockpvs and r_lockfrustum borrowed from DirectQ which mh said he borrowed from Quake 2. I think I mentioned before that there should be some kind of brush that mappers could place that allows more freedom over culling.
Unreal Engine used to have "visibility culling" that you placed a brush to give hints for vising purposes. Maybe Quake has something similar (is this how hint brushes work??). I would assume that if they're supported at all, hint brushes work like described here:
http://tastyspleen.net/~panjoo/rust/tutorials/hint/hint.htm I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile. Mark V supports external vis which allows, for instance, true transparent on id1 maps without vispatch
Thanks, I'll have to check this feature out I do wonder if using such brushes would improve maps... It's another layer of work on top of what is already required but with some bigger maps it could be worthwhile. If you do it correctly then yes. Problem is if you have big open spaces, then it won't help you much... although in my case I used it to cut portals behind big building standing in center of open space. I like this "tutorial". Explains it properly: http://omnicide.razorwind.ru/wiki/index.php/Tutorials:Understanding_a_VIS_and_Hint_brushes What did more modern engines such as Source do to improve their VIS? Half Life 2 has plenty of huge open spaces that run well.
So how is PVS (Potentially Visible Set) different from VIS? The Valve Dev wiki describes PVS as a collection of visleaves which might be visible from a given location. Isn't that just how VIS works?
VIS is just a tool/process of creation of PVS, so to be 100% correct with nomenclature, we shouldn't use it to describe PVS ;)
Anyway we are OT a little, maybe we should move with this conversation to Mapping Help, before Baker gets mad :P For the curious: https://developer.valvesoftware.com/wiki/Visibility_optimization
By the way, Source uses vvis.exe. I needed to look at a modified FvF player model in a mirror today, but could not do so because Baker took away the mirror control from the user....
"The Id1 Mirror Texture Only Works With Id1 -- It's Intended Behavior if someone is playing Soul of Evil or Travail or something and some random texture is pointlessly a mirror because it is window02_1, that would be annoying as hell But r_mirroralpha is a user-controlled variable, and if a user wants it on, it should be on, no matter what mod they are running. It should also be defaulted to "off" ("1"), so if it IS on, then it's definitely intended to be on. I had to load up FTE to look at myself in a mirror in FvF, and even that engine wouldn't let me activate it in Multiplayer mode, telling me it was a cheat. Boo! (I'm the server operator -- I am the one who should decide what is or isn't a cheat on my server, and I don't feel mirrors are a cheat). But at least I could use mirrors to look at the modified player.mdl in FTE Single Player mode. I dislike when engines decide for me what settings I am allowed to use in what modes. sv_cheats 1; restart;
then you can do whatever you want. and so can other users on your server, so have fun with that. unfortunately nq doesn't do serverinfo, so that'll only work with an fte server. use mirror_* for mirror textures in future. those should always be mirrors, and need not be considered cheats. window02_1 on the other hand is present on many maps, and in many of those it potentially exhibits serious graphical glitches that allow it to act as a wallhack or whatever. so yes, its generally considered a cheat unless the mapper explicitly intended it. for similar future needs, you might want to consider using chase_active or equivalent (most engines support it to some extent), or maybe try fte's splitscreen. its generally easier to look at it from other angles then. His server coops existing maps. He doesn't have any choice in what the texture names are so he doesn't have the option to change the texture names to mirror_ *
I've tried to test it by entering "r_texprefix_scrollx wizmet", but it didn't work. I'm using the version 1.36.
That feature was slated for removal, looks like is broke. I probably was working on mirrors and removed it, but forgot to nuke the cvar and friends.
It works in this ancient build binary + source. The reason that feature is slated for removal is largely because: 1) I can't imagine a scenario where it could be turned into a standard. 2) This method has no ability to control the speed. 3) You can do animated textures in maps using the +[texture name] animated textures method in regular Quake and it works on everything, although it is jerky and has a 10 frame limit. 4) Low interest in porting scrolling to WinQuake, hehe. There's also probably better ways to do it too. Was a nice experimental feature back at the time, I just wanted to see what it would look like. Retroquad uses the [ and ] characters to prefix parameters for scrolling.
[ is negative ] is positive The first of them in the texture name indicates horizontal scrolling. The second one indicates vertical scrolling, and it's optional. The second one must be followed by a number indicating the speed. The first one only must be followed by a number if the second one is omitted. If the speed value is omitted in the first one, both will use the same speed: ]1 horizontal scrolling, 1x speed [1 horizontal scrolling, -1x speed ]0]1 vertical scrolling, 1x speed []1 diagonal scrolling, -1x horizontal & 1x vertical speed ]1[2 diagonal scrolling, 1x horizontal & -2x vertical speed Retroquad's texture naming parser can also recognize parameter prefix characters anywhere in the texture name, allowing for multiple effects to be combined. The water in this video uses 20 textures named from *watersa]0]1+00 to *watersa]0]1+19 . The parser reads it as: *water it's a water texture sa the texture's individual name ]0 zero vertical scrolling ]1 horizontal scrolling at 1x speed +00 to +19 animated frame index The only thing I couldn't decide is whether the speed value should be in units per second or in loops per second. In the first case, big textures would need big numbers to fully scroll, and in the second case, small textures would need fractional numbers to scroll slowly. However, the first case also makes it easier to sync multiple scrolling textures with different dimensions. The reason for all these is to make texture naming as economical as possible while still being flexible, since vanilla Quake only allows 15 characters per texture name. 4) Low interest in porting scrolling to WinQuake, hehe.
Getting it to work properly in the software renderer takes a lot of work, so it's understandable. A cheap way would be to scroll the texture per-texel in the surface cache. WinQuake uses a similar method to scroll the sky overlay, which is why its movement is so jerky. This would only look good on fast scrolling textures, but at least it would work. By the way, Retroquad animates sky & liquid texture frames at 15 fps, rather than the default 5 fps of regular animated textures. Alphamasked "fence" textures are animated at 20 fps. This was hardcoded just for that demo, but a standard for custom timing of texture frame animations would also be a good thing.
However, the 15 character limit for textures makes it a pain to add more customization. The name "*watersa]0]1+19" is 15 characters long already, and even if we remove the "sa" characters from it, there would be no room to define a 15 fps interval, which would require a special character plus two numeric characters (e.g. *water]0]1+19,15). By the way, sorry for hijacking the thread, but I'm just trying to encourage more coders to implement such features, and maybe define some standards for them.
Engine issues and engine support of mapping enhancements are always on-topic. Not sure what you are apologize for.
Your results look nice and are smooth. It seems wrong to put the timing in the text name, yet with Quake we do water, alpha masking, animated textures, etc. by the name The naming convention you are using seems quite sensible. In my config file, I use:
r_texprefix_scrollx z_exit Though in some places where the mapper uses the texture somewhere else (like the start of terra4) it looks... odd. Like only the fullbright part is scrolling, and not the rest of the texture. Not that I'm complaining -- I like experimental features to play around with (as long as they default off!) And yeah, I used chase_active, but I wanted to see myself from the front too. Mirrors were (well, they should have been...) the quickest way for me to do that, heh. I did not know about the various FTE features (splitscreen, eh?). Oh, something else....
I found that my player.mdl in \fvf\progs\wasn't even loading in Mark V, because there is a player.mdl in the fvf pak0.pak file..... But the replacement player.mdl did load in FTE when running FvF. I believe, no matter what the original default was in this case, that if a user has replacement content in a folder, unpacked, it should override anything in a pak file. FTE seems to have made that choice, and it's a good choice. I remember the complaints about "toxic settings" in an autoexec or other file inside a PAK file, and how that completely takes control away from the user (and placing those settings inside a pak is like the worst case scenario). Well, giving preference to any unpacked files, rather than what's in a pak file, would fix that issue too. It seems obvious that if a user places some files into folders in their mod/id1 directory, they want to use THOSE files rather than anything that might be in a pak. And a pak is the hardest thing for a user to actually modify... so it's hard to work around. Is your current mission to make FvF no longer work with traditional style engines?
If you want the best of both worlds, do what Arcane Dimensions does and simply not use pak files at all! Then you won't even have the issue you are describing, haha ;-) Do you see what I mean? You are mixing pak files and free standing files, but no one is making you use pak files at all! That's a choice. The logical thing is to not use pak files if you don't like Quake's loading order. Sock never has this problem because he doesn't use pak files. All you have to do is make a FVF2 folder with everything unpacked, and you can play around as much as you like. You could be living the high life in 5 minutes! It's not an FvF issue. It's a Quake issue.
The same problem exists if someone wants to use a replacement model in their id1 folder. The pak file overrides the unpacked replacement stuff, and that's not what should happen, because if a users puts a new model in his id1\progs folder, he WANTS to use THAT one. Why make it more difficult for him? Would your suggested solution here also be to unpack all the id1 pak files, then remove the pak files, so only the unpacked files exist in id1, so a user can then use replacement content? Or make them run a separate mod just for 1 replacement model? What a hassle. FTE does it correctly, in my view, and allows the user-content to take precedence. Can you explain why is it better for pak files to take precedence? They are the most difficult for the user to modify. I can understand why they may have made it that way back in 96 -- maybe they didn't want the user to be able to easily mess with Quake.... But we are way beyond that now. People created programs to get to the goodies in those pak files. There's no reason to make it so difficult anymore for people to drop in replacement things. When a mod has a lot of files, sticking then into a pak file is the most convenient and tidy way for a modder to package the mod. If a modder chooses not to do that, it may be for the very issue I'm describing here! Of course a pak file does take control away from the user, though, which is mostly fine, because that's what mods do -- they change stuff. But then if a user WANTS to change something himself, it would be nice if he could easily do that -- like in this case, if he just wants to replace a certain model by dropping it in (a player created a new player.mdl just for FvF). In summary: giving precedence to unpacked files ----------------------------------- pros = More convenient for the user to drop in replacement content. Protects against toxic settings in a pak file overriding user cfg files. cons = None ? giving precedence to pak files ------------------------------ pros = None ? Slightly helped id keep Quake from being altered back in 1996? cons = prevents easy drop-in replacement content. You have to use a new pak file instead. If a mod contains toxic settings in a pak file, there is no way to prevent them from being initialized. Am I missing something? If files in a folder override pak files, why have the pak files at all?
Quake for 20 years has had pak files have the precedence. FVF is fully under your control. If you don't like the behavior of pak files, do them free standing files like Arcane Dimensions. Arcane Dimensions, because it uses no pak files, doesn't have the issue. If you don't like the behavior of pak files with your mod, then don't put the files in a pak. 1) Doesn't require anyone to do anything. 2) Compatible with every engine! ...Quake for 20 years has had pak files have the precedence...
To me this reads as: ...Quake for 20 years has done things the wrong way... It seems pretty obvious to me that whatever is included with the game (pak0.pak, pak1.pak) should be overridden by any new content. It's 100% true that if you really want to solve this problem in your own mods which use their own folders, you should not use But why make using them so difficult in engines which are under active development? pak files keep things neat and make it harder for unwitting users to break your mod and so on, but the penalty a mod author incurs when using them is unnecessarily great. Where do you stop?
DarkPlaces loads every single Others want things simple. Like the Quake way. Spike will say with pride that FTE loads external replacement textures from, I believe, 132 different possible folders -- supporting all the various replacement texture schemes. There are also different replacement model schemes.
A conservative engine wants 1 folder where something goes and one set of rules where that set of rules = QUAKE. There isn't a right or wrong. Just an approach. A conservative engines wants to stick with simple. It's Quake.
For every one person who wants something done one way, there's going to be five others who want it done five different ways. The only thing you get by asking multiple people is multiple answers. The closest thing to any kind of community consensus is "do it the way [Popular Engine X] does". Gunter in particular has a very bad habit of "what I want for my mod is more important than anything else", then causing drama and outrage over it. I'm not certain that's useful feedback. Quake already has an established way of allowing standalone content take precedent over pak files - put it in a gamedir of it's own. Multiple gamedir support is trivial to add to engines (and far more useful than arguing the toss back and forth over things like this). A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy. The PAK file precedence is part of Quake's copy protection. One of Quake's selling points was: if you want to play custom content, you must buy the game.
PAK0.PAK has its CRC value verified by the engine. If the proof-of-purchase file (from PAK1.PAK) isn't found in the path, Quake refuses to load anything but the unmodified PAK0.PAK file, which contains the shareware episode. The PAK file precedence also served to prevent users from creating custom maps using the same names of the original maps and complaining that the original maps didn't work anymore... And to prevent users from going full "FreeQuake" and replacing the episodes 2-4 with custom maps. id Software already had people selling shareware Doom CDs full of custom content, and they decided to prevent that from happening to Quake. Is there any particular reason why this behavior should be continued today in engines, aside from respecting id's desire to, y'know, actually sell a game and make some money from their hard work? In the modern world of filesharing, it's such a lackluster form of copy protection that it may as well not be there at this point.
DarkPlaces has its own set of special rules for content, which you have to learn. Many modders for DarkPlaces struggle to make Quake compatible mods because they have habits that don't work with Quake.
"Where do you stop?"
You stop at making unpacked files take precedence over pak files. That's it. Don't use a fallacious "slippery slope" argument like, "but if I make a reasonable change, then I'll also have to make every unreasonable change everyone else wants!" This has nothing to do with supporting all the formats Darkplaces or FTE uses. You still haven't explained the benefit of leaving it "the way Quake has done it for 20 years?" That's not a reason. How many other non-optimal Quake behaviors have you already changed? "It's Quake. For every one person who wants something done one way, there's going to be five others who want it done five different ways." Well, so far you've got more than one person wanting unpacked files to take precedence, and NO ONE wanting it the other way, other than people just saying, "that's the way it has always been" without providing any benefit for that approach.... How many other non-optimal Quake behaviors have you already changed? Will anyone step forward and say they prefer pak files to take precedence, and give an actual functionality reason for that? "Gunter in particular has a very bad habit of 'what I want for my mod is more important than anything else', then causing drama and outrage over it. I'm not certain that's useful feedback." Oh, bite me, mh :P I just said this isn't an FvF issue -- it's a Quake issue. This would be better for everyone. I have laid out my actual arguments for why, and you have not provided a single counter argument to support your position other than, "I don't like when people want different things and I don't like Gunter because he always out-argues me" ;) "A general-case solution that's more useful to everyone is always better than a special-case solution that just keeps one person happy." I completely agree with you, mh! But that supports my (and others') position in this case that the behavior should be changed, because it would indeed be a general solution that would be useful to everyone! I am dramatically outraged that you would think otherwise!! :D Can you explain who it's useful for to leave pak file preference in place? Modders who want to inflict unavoidable toxic settings on the user? I'm aking the same question as Pritchard here, "what benefit is there to keeping this behavior?" Nobody is answering except to say, "it's always been that way and I don't like the complicated things Darkplaces does." We're not taking about Darkplaces. We're talking about this ONE behavior. That's where it stops (in regard to this issue). This isn't a change that's going to cause any compatibility problems either.... Please describe the benefits of pak file preference. mankrip did a pretty good job of describing the benefits id saw back in 1996.... Now what is the benefit in the modern day? Isn't the whole point of engine development to improve on the original things that might not have been optimal for the users? I mean, why didn't we keep id's original network code? ;) Would it still serve any useful purpose today, or would it just make things more difficult for the user? In regard to why I, as a mod author, use a pak file to distribute the FvF client files? Because it's the most tidy, convenient way to distribute a mod, instead of using multiple files and folders. AND it also keeps the user from easily being able to nose around in the files to swipe them for their own use! Heh. So yeah, a pak file still serves as a slight (very slight, really) deterrent for pillaging my content, however, I don't mind if the user wants to use other replacement content on top of mine, and I see no reason to make that a difficult process for them. Again, this isn't just for FvF -- it's for anyone who wants to use replacement content for Quake with or without mods. If you're looking for some form of consensus, why not run a poll on Quakeone? Then maybe someone would give an actual functionality reason for preferring pak file precedence.... You are new to a discussion about this topic.
I've read or even participated in this same exact discussion 6-8 times, including a couple of times at Inside3D and a couple of times at QuakeOne. I used DarkPlaces before I ever engine coded and experienced firsthand the pros and cons of the functionality. I also like DarkPlaces as a total conversion engine and both Mark V, and before it, ProQuake acquired several gems from DarkPlaces. It is safe to say my opinion of that DarkPlaces feature is due to knowing a lot about it works. Typically, the those arguing for the DarkPlaces way of doing things is inexperienced with using the the feature, and unable to describe the downsides because they don't have the experience to understand the other side of the coin. And perhaps I'll try to explain again. But probably not today. Seems like no one is reading or making an effort to understand what I am trying to communicate in my replies. I may be typing this post just "for fun" as it seems the other ones went unread. But I hope it does get read OK, I'll bite.
The upside of having loose files take priority is that the user can easily replace PAK file content. The downside of having loose files take priority is that the user can easily replace PAK file content. Think about that - and if you don't have a Zen moment when it becomes clear, you haven't thought about it enough, so think about it some more. This isn't just about copy protection, it's also about protecting users from malicious (or just plain old badly designed) mods and from themselves. Whether you like it or not, the way Quake has done it for 20 years is the EXPECTED behaviour. Mods are made and released on the assumption that this is the way it behaves, experienced players run Quake on the assumption that this is the way it behaves, experienced players help out struggling newbies on the assumption that this is the way it behaves. If it's in a PAK file it takes priority. This isn't about advantages of one vs advantages of the other. PAK files taking priority may even be the inferior option but that doesn't actually matter (I have an opinion too but it's irrelevant). It's about what everybody expects to happen. You may have a different expectation but don't be so arrogant as to presume that your expectation should overrule 20 years of everybody else's experience. The way Quake works, if you have a mod with a pak0.pak in the folder (let's say -game zer) you have 100% assurance the mod will behave properly.
With the DarkPlaces way, a user will say "I don't know what is wrong? I have pak0.pak in place, but some weird model is showing up!" Later they will say The DarkPlaces way takes away the security of knowing a pak file containing a mod is a complete and full assurance of proper installation and running. I should add.
I do understand your frustration to a certain extent. I am the person who fought, and lost, the stuffcmd wars a few years ago, and stuffcmd is actually potentially dangerous to your PC, never mind just being a squabble-fest over file loading order. @gunter
just stop using paks. you complain that paks taking precedence makes it hard for users to replace files, but you forget that any paks make it hard for the user to know which files they need to replace (and the form of that data too). that's not to say that I agree with Baker, frankly I see his argument as user-hostile that further discourages people from grouping their content thereby making it MORE likely that people will be stuck with content that they forgot to delete on account of not being able to separate it so easily. quakeworld downloads often REQUIRE files outside of paks, or at least maps. The singular exception is when you have md3s or q3bsps that depend upon shaders and external textures that the client won't know to auto-download. In these cases, pk3 is a superior format that offers compression and is easier for people to open. Essentially, such content should be treated basically like q3 content is treated. But until then, just don't use paks. PAK files also serves as a versioning system.
If your mod is fully contained in a PAK0.PAK file, you can make an update for it by storing the updated files in a PAK1.PAK file. And then, you can revert to the previous version by simply removing the PAK1.PAK file. I've actually done this in one of my mods, because it gives the advantage of knowing that the PAK0.PAK will likely always be the same, no matter the version of the mod. Loose files doesn't use a cascaded versioning filesystem, so they require you to remove all previous versions of the files, which makes it impossible to rollback a bad update. Anyway, a command-line parameter to control the precedence could be nice for development purposes. Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual.
We are reading what you write, Baker, but you're just talking vaguely about Darkplaces. I don't use DP. I just happened upon the functionality in FTE, and I liked it -- actually, I didn't even realize it was different; I just knew that FTE did exactly what I wanted/expected it to do -- it used the player.mdl file that I dropped into a folder.
Now you're saying that pak files are good because they let the modder know 100% that the mod will work for the user, but you've previously been talking about how Arcane Dimensions installs everything unpacked, so it doesn't have the issue of pak files overriding user content.... It's like you're telling me I should do it two different ways! Why can't I have both the convenience of putting my mod files in a pak to ensure easy/correct installation, and also have the ease of letting more tinkery users drop in their own content if they want to? Sure, they might mess things up, but this is the same issue as any other piece of software you give to a user. The user might mess things up. If they do, they can just delete and re-install the thing.... What I'm now hearing from you and mh is, "protecting the user from himself." Like if the user installs some replacement content, then later derps out and forgets he installed some replacement content, and can't figure out why there is replacement content in his game.... Would not the same thing apply if he were using extra pak files? Is Quake 1 really a game for derps? Is that the kind of user you are designing Mark V for? Everyone derps out sometimes, but unpacked replacement content would still be easier for a derp to find/remove than stuff in a pak file, because it's all easily visible unpacked. In a pak it's hidden.... "What is this pak4 thing I have in my folder? I do not know. And why is my player model so weird?" vs. "What is in this progs folder? Oh, there's a player.mdl in it. Oh! That's why my player looks so weird!" So, mh says for both pro and con, "it makes it easier for the user to change things." I don't know why you're not having a zen moment about that yourself.... You strike me as the kind of person who would use linux because you'd hate Microsoft always "protecting you from yourself" and not allowing you to change things you want to change.... This reminds me of an old commercial: https://youtu.be/FxOIebkmrqs So do you think it should be easier or harder for a Quake user to change things? Apparently "harder?" So you're a Windows guy, eh? :D (I'm actually a Windows guy myself, but I'm a superhacker, so I make it do what I want ;) Ya know, the whole reason that Quake is still alive after 20 years is because it was relatively easy for users to modify stuff.... Zen moment? Should it be easier or harder for users to modify stuff in Quake? You also throw in that it's about protecting from malicious/badly designed mods... Uh, isn't that backward? Unpacked file preference would help protect from bad mods, because the user could easily see/change unpacked files or replace stuff in a pak file with their own stuff (a bad autoexec in a pak file, for example). As far as "expected behavior," well, it's "expected behavior" (how it has "always" been) that you must put the Quake CD in the drive to play the soundtrack. But now we can drop mp3 files into a folder and play the soundtrack.... That "expected behavior" was changed to make it easier for the user. This is the same concept: let the user easily drop in files for Quake to use. Should we not allow that because some derp might drop in the wrong mp3 files and then wonder why Ace of Base is playing when they start Quake? :D And I have to ask, "expected behavior" of whom, really? Certainly not any new players, or other people who have never messed with this stuff in detail. Heck, I don't regularly mess with it in detail, and I actually expected a player.mdl to be used just by dropping it in a folder! Then I was like, "Wait, why is this not working? Oh crap, the pak file overrides it." So I ended up having to stick my single replacement model into a pak file. What a hassle. I can't imagine that's good for anyone, no matter what they expect. And being that many experienced users will be using other engines like Darkplaces and FTE, well, their "expected behavior" would not conform to the 20-year-old way either. So maybe some old Quakers are "expecting" it, but I bet if you gave them the option, they would prefer it to work in a different, more convenient, way. Actually, Baker, if you have links to the multiple discussions of this issue you've had in the past, I'd be glad to look them over to see what else I may be missing. mh, I'd probably be against you on the stuffcmd issue, heh. It is a useful tool for modders -- aure, abuse is possible, but I use it to bind the FvF chat impulse so players lower their gun and blow smoke while chatting. But I think Mark V has some cfg protection for stuff like that. "just stop using paks."
Sounds so easy, but in practice that means I'd have to completely unpack my id1 pak1 and pak0 files. That's a mess of files! (I'm not just talking about my mod, but every mod with a pak, and also standard Quake.) And just because I might want to use a replacement player.mdl ? Heck, it's actually easier to complain a lot about it and hope Baker might consider changing it ;) (But really, it's not just to make things easier for myself, but for other people as well). There are low-brow engines and high-brow engines.
Low Brow Engine - Your TV remote has 4 buttons (Mark V) Favors an uncomplicated and reliably smooth and enjoyable experience and will sacrifice options, capabilities and preferences to get there. Assumes the user knows nothing, has guard rails. Caters to the user that knows nothing -- protects them. Most features are obviously exposed, few features beyond core feature set. When no one has any questions or problems, the Baker feels like "Mission Accomplished!" It's reliable and intuitive! High Brow Engine- Your TV remote has 106 buttons (DarkPlaces/FTE) FTE/DarkPlaces. Caters to advanced users. Plenty of settings. Plenty of capabilities. Support for cutting-edge techniques. Boundless depths, options, abilities. Assumes the user knows everything and caters to the user that knows everything. Has layers and layers of features beyond the obvious ones. When a user has something sophisticated they want to do and realize that FTE can do it, Spike feels like "Mission Accomplished!" It helped someone with sophisticated needs execute their idea! (This is why Spike and I seem to argue a lot about some things, but agree about others.) "Clearly it makes no sense to change this behaviour except to keel to the whim of a single individual."
Uh, no. I've laid out clear, concrete reasons why it "makes sense," which have nothing to do with my whims. And I'm going to count at least 3 people here that might prefer it the way I am advocating for. Make that 5: Myself Pritchard mankrip (for a command line parameter to allow the option) And I will count: FTE Darkpalces (their creators obviously preferred this functionality) You see me arguing for it, but I am arguing as "the user" and not just for myself. This would make it easier for every user.... It's just that every user doesn't read this forum. Do as I have suggested -- make a poll on Quakeone where there are more users, and see what everyone else actually thinks. Count me in with mankrip re: the command line switch to change the behavior. Why not give the user the option? I don't see the downside.
I hadn't really considered the "versioning" aspect of pak files, but it certainly does make it easier when, on the rare occasion, I update the contents of the FvF client pak file, to know that all the user will have to do is replace their pak file with the new one and they will be correctly updated. If I were handing them the mod as unpacked files, that could be messy and tricky if I ever removed some of the files.... I'd have to give special instructions to delete certain files during the copying of the new files.
So that's another reason why I use a pak file for FvF -- easier/more foolproof updates for the user. And I too would be happy with a variable to alter the file/pak precedence. That would still make it easier for people, because I could tell them, "you need to set this variable to let your replacement model work correctly." A command line option doesn't seem objectionable. I'll consider it without making a promise as to when.
So it is very likely to happen, unless it somehow interferes with something else. Which doesn't seem likely. Having the option available would be nice, there are sometimes it is nice to change things on the fly easily. I just don't like that as normal default behavior. Excellent. Thanks for considering it.
I'd also hope it will includes a console variable for easy setting, even knowing that would be something like, "this setting will not take effect until you restart Quake/the map/whatever is required." I wouldn't dare suggest a menu setting, knowing how much you hate menus ;) But then again, a menu setting would make it easy for the low-brow derps who Mark V is intended for! *Throws an FvF ninja bomb and runs away* Stuffcmd("screenshot")
Nice denial of service you have going there. You see Gunter - you need to think beyond what you immediately want. Yes, I already agreed that abuse was possible. I just said so.
But do you remove all the potential valid, good uses of the command because of hypothetical bad uses? (Has your example ever actually been used in a mod?) Hey Baker, I think mh is asking you to prevent screenshot from being used in a stuffcmd! Mark V already protects your cfg file getting messed up by stuffcmds. I can't think of a legitimate reason to allow stuffcmd screenshots.... So that's something that could be prevented. But removing the whole stuffcmd functionality would be throwing out the baby with the bath water. There's no simple way to implement a cvar for it, because config files are only loaded after the filesystem is initialized. It's impossible to make a cvar change the filesystem initialization behavior.
Now, if such a cvar would be used to change the filesystem behavior on the fly, that would open a can of worms, specially on engines that supports changing the game directory on the fly: Set a mod dir, change the precedence, and add another mod dir; the precedence of the previous paths gets screwed. And that's why you wouldn't make a good engine coder.
In the end, Baker is interested in improving his engine for the users, and not just winning an argument for the sake of winning an argument. Actually, that's why I post here too -- not to "win arguments" but to improve Mark V for the users, of which I am one! My ideas of what might be an improvement may not be the same as other people's ideas, so we argue about it, but it is not personal, not even with mh for me (he's done great things for Mark V), though sometimes I can't tell if he gets caught up in just wanting to win the arguments or not ;) In the end it would be silly to stubbornly refuse something that several people are stating a preference for, if the only reason is "don't give in to Gunter." Baker is not that petty! And I'm certainly glad other people do speak up to state their preferences here, so that mine is not the only voice. It's not about whether I would make a good engine coder. I probably wouldn't but not for the reasons you gave.
It just appeared, from an observers POV, that you basically bullied and harassed Baker into adding a feature after he gave you plenty of well-reasoned answers as to why it wasn't a good fit for the engine. I mean, I have asked him to include stuff from time to time but I am in awe of the relentlessness of your stubborn pleas. Maybe I am just better at taking no for an answer. There were wins here.
Gunter did argue annoyingly hard. Then again, he did eventually suggest a viable solution -- which no one has ever done before -- in the idea of making off by default but with ability to opt-in. mh signaled he had complicated feelings on the subject and I've used DarkPlaces before for some deep modding where the functionality was helpful. I've also seen DarkPlaces beg and scream for help because they messed up something so terribly bad and no ones wants to reply to them because usually it's a super-newb who barely can find their Quake folder so they get the "leper treatment" or insightful advice like "delete your Quake and reinstall". So /Gunter has found some very, very obscure bugs in the past. And spotted inconsistencies few would notice, allowing them to be resolved. There is a Linux version available on the Mark V page for those interested in provided feedback and willing to experiment.
A few people have said it works very well. One person had some audio issues with their sound system. Tested on Ubuntu, told it works fairly nicely with Debian. Your mileage may vary. I may have missed something in the avalanche of posts, but when Gunter started talking about having to unpack the id1 pak0.pak and pak1.pak files I started to wonder if there's a fact being overlooked...
The pak file precedence over loose files only applies within a game directory, right? I believe it is the case that a loose file in a game (mod) directory takes precedence over any file in id1, regardless of whether the id1 file is in a pak or not, correct? Is everyone on the same page about that? I believe you understand correctly how it works.
But say you want to only replace the player.mdl when paying standard Quake... with the one contained in this pack: http://quakeone.com/forums/quake-mod-releases/works-progress/9573-authentic-model-improvement.html That becomes rather annoying to do, since it's not as simple as just dropping the replacement model into progs\id1\, because the pak file will override it. So you end up having to create whole new "mod" folder just to use one replacement model, then you have to create a batch file to run quake -game whatever, or you have to type "game whatever" in the console if your quake engine supports it.... What happened with me is that a player took that model and applied the FvF skins to it, so I wanted to try it out. The problem is that FvF already contains a reskinned player.mdl in its pak file in my FvF mod folder.... So again it was not so easy to just drop in the player.mdl and try it out. So Spike suggested "stop using pak files" and that's why I described having to unpack the id1 pak0 and pak1 files too, because even if I'm not playing FvF (or any other mod with a pak file) I'd still have the same problem if I were trying to just replace the player.mdl (or some other model) for standard Quake. OK I'm going to try this one more time.
The way Quake has always loaded content goes like this: - Gamedir 1/PAK files/Loose Files - Gamedir 2/PAK files/Loose Files - Gamedir 3/PAK files/Loose Files - Etc. (And yes, even stock ID Quake can load more than one extra gamedir; try -rogue -hipnotic -game XXX"). Here is the Quaddicted Single-player maps archive: https://www.quaddicted.com/reviews/ This is a repository of content all authored under the implicit assumption that certain Quake engine behaviours are consistent. I say "implicit" because I'm absolutely certain that none of these authors (or at best very few of them) ever sat down and actually thought about this. But nonetheless the assumption is there, so please don't try to play silly buggers about it. Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't. So they'll have to be tested, somebody's going to have to go over them and check that there's nothing in them that breaks. What you have is one case, and it's not even a gameplay case - it's a test case. And you're behaving as though you believe that one case should take priority over everything else. You're jumping up and down shouting "I WANT I WANT I WANT" like a child, and not showing any awareness whatsoever that there is a whole body of existing content and Thou Shalt Not Break Existing Content. One test case in FvF does not get to take priority over the body of existing content. Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you. I don't think anyone has put much thought into that compatibility angle before.
Considering the volume of single player releases, it would require an enormous amount of effort to find the ones with conflict situations. This is the kind of thing I've been bitten by before.
Even what seems like quite simple changes, say something related to behaviour of the viewsize cvar, can explode spectacularly if a mod uses it in an unexpected manner. I think the key phrase there is "in an unexpected manner". The definition of an unexpected manner is that you actually cannot predict in advance what the impact is going to be, so it's no good someone asking for a list of disadvantages to a proposal. "When in doubt do what ID Quake did" is a good maxim for certain classes of changes. With the SP community having converged around FitzQuake and derivatives, "when in doubt do what FitzQuake does" is also a good maxim. We're not just talking about engines either. I've seen enough content made with buggy tools that just happens to work because engine behaviours or quirks accept it. I've been in a "put the bugs back" situation more than once. The onus is on the person asking for a change to demonstrate that the change is benign, or at least that's the way it should be. Changes to very fundamental behaviours of core subsystems should always be approached with extreme caution. Ok, I see it is IS personal for mh. I think he just dislikes me because I consistently out-argue him. Well, he's going to like me even less after this.
mh, you are just being a crybaby now, but let me address your actual "arguments." "The way Quake has always loaded content" Yes, that's been pointed out repeatedly. But as Pritchard said, that's like saying, "Quake for 20 years has done things the wrong way" Or, if not strictly "wrong," then certainly in-optimal. "Change the content loading order and do you know what is going to break in those maps? Because I sure as hell don't." I do know: Not a single damn thing. Nothing. Do you know what kind of contrived situation would have to exist for the loading order to break map packs? The mod would have to install both a pak file AND unpacked files with the same names, yet with the files in the pak being the only ones that are supposed to be used, because for some reason the unpacked files with the same name are not the same files.... Seriously, HOW ELSE could the file load order mess up a map pack? You probably can't even come up with a realistic situation where it would, without your user do really weird stuff (which could happen no matter the load order). Maybe if the map installs as a pak file in your id1 folder and you already, for some reason, have different maps with the exact same name unpacked in your id1/maps folder?? The fact that you don't see it wouldn't cause a problem except in an extremely contrived circumstances shows that YOU are the one who isn't thinking this through. Your flimsy argument amounts to trying to whip up fear of a boogeyman which would never actually occur unless you intentionally tried to make it happen. "But something might break! You just don't know!! Think of the children!!!" You're grasping at straws. Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"? No? I'm not surprised. "What you have is one case, and it's not even a gameplay case Uh, no. I said it could impact anyone playing any mod or standard Quake if they wanted to easily use replacement content. I've pointed that out repeatedly. Do you not comprehend? "Not even a gameplay case?" What? This isn't some hypothetical thing I came up with out of nowhere -- I never would have brought up the issue if it had not IMPACTED MY ACTUAL GAMEPLAY. Do you not comprehend? You characterize me as crying like a child, but it's you, mh, being the crybaby. You're just being ANGREH. You don't have actual good points to support your position -- just hypothetical boogeymen which it's clear you didn't even think through (or you would have realized how ridiculously improbable it would be to actually break any of the maps from Quaddicted). "When in doubt do what ID Quake did" See, that's rich, because in the past when I have argued for using Quake's Default Behavior instead of some change Baker has implemented (centerprint position, or start map guessing), you have thrown the same whiny bitchfit over it. So it seems it doesn't matter whether I'm advocating for Default or not -- you're just against whatever I suggest. (Normally I like Default presentation to the user, but this is behind-the-scenes, to make replacements easier) "Feature requests are always more likely to be listened to and taken seriously if the person making the request gives some indication that they've thought it through and that they understand the implications. I'm not seeing that from you." I can only laugh at this :D You're not seeing a LOT of things, mh. So don't even worry about it. If some weird, obscure issue pops up because of this change, you can bet *I* will be the one to find it! I'm the one who has been finding the weird, obscure bugs that result from the changes Baker has made, because I have an extreme eye for detail and a meticulous mind for thinking on many different levels. So just because you "sure as hell" can't see what might beaffected, don't worry -- I can. ;) Now, was any this necessary, mh? Nope. Baker already decided to leave the default behavior in place and add an option for the user to change tit. Yet you still felt the need to make a fuss and post at me with silly arguments and insults, because, apparently, you are a sore loser. And like FifthElephant, you just didn't want to see me get what I want. Now, I normally do not post at people in such a demeaning manner as I have at you here, but this is certainly how I respond when someone insults me the way you decided to. So, if you don't like this, then refrain from making such petty characterizations of me in the future :p and then I will stick to addressing your actual arguments as I normally do. Baker, don't let the "compatibility scare tactic" dissuade you from this -- you know if it produces any unexpected negative issues, I WILL find them! ;) mh is relating his experiences involving the development of DirectQ. He is not referring to you at all.
I watched some of the DirectQ users "carp" on mh with insisting DirectQ must do certain things. Something unseen here is that very few engines end up surviving compatibility. I could tell you things that crash qbism super8 hard. I could tell you things that don't work right in FitzQuake. I can tell you things that don't work in Quakespasm. mh and I work well together because we view compatibility as #1. /So please leave mh alone. I already said what I plan to do. Might add that I also know single players that have problems with Mark V's automatic impulse 12 support. If you are serious about compatibility, you know your own engine's weaknesses as well.
Seriously, are there any maps/mods on Quaddicted that say, "this will not work with Darkplaces or FTE for some reason"?
https://www.quaddicted.com/engines/darkplaces Remove: "single players"
Substitute: "a couple of (rare) single player mods" /Premature submit strikes again! Now, was any this necessary, mh? Nope. [...] And like FifthElephant, you just didn't want to see me get what I want.
I wish someone wanted my naked body that hard. Now I'll feel jealous of Baker too. @Baker "He is not referring to you at all."
Ah, well, then I must have misunderstood when he used my name ;) But it's no big deal for me, really. I approach internet arguments like a Quake Deathmatch: whether you win or lose, it's all for fun, and it's not worth getting legitimately upset over. :D @mankrip Yeah, I guess I really should have specified I was talking specifically about compatibility with Darkpalaces due to the unpacked file preference is has. I have no idea about all the many other differences in Darkplaces, and what compatibility issues they may cause. Actually (side story), I remember several years back I tried using Darkplaces for the FvF server, but I encountered compatibility issues.... I think I emailed LordHavoc about it, and it was something about either checkbottom or some other way to see if something was on the ground, and what I was doing in FvF wasn't working in DP. LH said that code never really worked right in standard Quake or something.... In any case, I went back to proquake server, and I don't know if the problem would have been fixed by now or not. So yeah, I understand compatibility issues are indeed important, but "compatibility problems have been caused by other things" isn't a valid argument in this specific case. Do we never try to change/improve anything due to fear of incompatibility? No, but of course, we do tread carefully. "I wish someone wanted my naked body that hard."
Well, just make a quake player.mdl with a skin of your naked body, and it will be REALLY EASY for people to drop it into their game once Baker makes the setting available! (And NOW I see the downside!! What have I done!??) It may be sunny now, but not for long!
Anyone else going to catch that full eclipse in August? It is passing DIRECTLY overhead for me -- I am right in the center of its path. I guess all those sacrifices to Shub-Niggurath are having an effect! "But it's no big deal for me" - Gunter after 3 scroll pages of bitching.
Please don't include me in your diatribes either, I was poking fun at you light-heartedly. Baker clearly got this. Ok, got it. You are allowed to "poke fun" at me, but I'm not allowed to mention what you said. That's a reasonable expectation.
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |