 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
@NightFright/dumptruck_ds
Didn't feel like posting a technical post Eventually I will implement a big coordinates protocol (for maps like Ter Shobelth) like FTE-999, which takes the weaknesses of protocol 999 and fixes them. I wouldn't be able to implement the very flawed and incomplete protocol 999, which cannot do co-operative play at all, because it would gross me out too much and I'd feel like vomiting. Co-operative play is important. Any "big coordinates" protocol must be one that do co-operative play. And 999 sure cannot, but FTE999 sure can. A large maps protocol like FTE-999 is on the to-do list. A 2019 item. But I also want prediction, framerate independence and something else I want which is boring and technical. /End snooze fest technical post If you do a co-operative game, do you want to
1) Be killed by invisible monsters? 2) Be killed by vore balls you can't see? That is what broken protocol 999 will offer you in co-operative play. It also has "scale", which doesn't work on 2/3 of entity types (.bsp, sprites) and also doesn't work right on the other 1/3 of entities (.mdl) and would result in Ogre feet in the floor and bad collision. So it is just loaded to brim with the brokesters upon more brokesters. Wanting large-coordinates is a valid thing! And those needs will be met in the future, but more in a FTE-999 manner that doesn't offer invisible monsters and being killed by vore-balls you cannot see. I'll go through and retest everything I've reported in the past....
First thing I checked: Looks like unpacked pak files now work. Hey, Proquake 4.93 seems to have nicely-populated server browser (finds 36 servers).... Mark V only shows like 5 servers. How about reading Proquake's protocol to help populate your server list? lenovo e480 win10-64
intel uhd 620 latest drivers dxdiag seems good, still no dx seems to be present, all versions of dx-mark5 prompt an error, even older ones from 2016. Good news is the last gcc version does run fine, nno errors seen while playing +5hrs. Older versions/Win7 does work all of time by now. Tested 1.99 on various hardware btw, all fine. Congrats Baker! Get DX9 runtime here: https://www.microsoft.com/en-ie/download/details.aspx?id=35
all versions of dx-mark5 prompt an error
You know, I really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, really, HATE it when people do this. At least you could say what the error message was. Those things don't exist for bamboozlement or amusement, you know. They exist to provide useful information on how the error might be fixed. Saying what the error message was can enable people to say things like "ah, you got that error message, that's caused by situations A, B, C, and to fix it all you need to do is X, Y, Z" I won't really be testing the SDL version... (it likes to freeze up or crash on me), but I will point out that it appears to be printing bronze text where it should be printing white text (like for player names and the FPS digits).
I don't want to be the bearer of bad news... but the "QMB_BLOOD 0" bug is still there :P
if you set "QMB_ACTIVE 1" and then "QMB_BLOOD 0" to deactivate the QMB blood, it doesn't work, the command only mix qmb_blood with red particles :/ I'm using a clean install and testing lots of old things. I find that a lot of my suggestions have indeed been implemented. Excellent.
Here are some initial issues: - Using Shader Gamma (the default), switching to any full screen mode that is not at my netbook's native resolution of 1024x600 causes Hardware Gamma to be used. It still says Shader Gamma in the settings, but it's definitely Hardware Gamma - everything gets darker and my desktop gamma is altered. Switching back and forth to full screen 1024x600 from a windowed mode does not cause the issue, and Shader Gamma stays in effect. - I'm seeing something new: CDAudio: drive ready test - get status failed Oh, I guess that's because the "External Music" is ON by default. Ah, the error message does not appear if I disable external music, or if I actually have the music tracks in place... AS OGGs RENAMED TO MP3!!! because you won't allow OGG to be detected by Mark V.... PLEEEEEEEASE do this! I and others prefer to use OGG, and for me it addresses the issue with MP3 freezing up my game for unreasonable amounts of time as the MP3 song loads.... I'm sorry an OGG file killed your dog and burned down your house when you were a kid, but it's time to let it go, man! - The mouse sensitivity slider now goes to 21, though that's right at the value I feel is good, around 20, so that doesn't leave much range for increasing it any more. The slider should probably go higher to account for users who might like it a bit more sensitive. I'd suggest at least 30 or so. - Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.... Should that happen? I mean, I know it should fire my gun, but not when the console is down. ALT also has this behavior (I tried binding ALT to +jump to test it). Be sure you're in a multiplayer game when you test this, as the console fully pauses a Single Player game. - Old issue that really needs addressed: the Multiplayer Setup menu, when you are changing your name, the name should not be committed until you are fully done changing it. It's like, for every letter you delete or add, it's doing a complete "name" command (which, among other problems it gives me, spams the console with name change messages). - Speaking of old issues, r_noshadow_list contains bolt1.mdl which does not exists in Quake.... It's just... not... right! - Known rendering issues: water surface is drawn on top of shadows, teleporter surfaces are drawn on top of water when viewed through transparent water (see #142 #147). And r_shadows 3 are visible through entities. Fullbright textures can't be transparent, and are made ugly by Contrast adjustment. (I know: all known issues -- I'm just noting that they still exist). - chase_mode - I know it's an experimental feature, but it should really behave like other console variables. It's confusing because just inputting "chase_mode" causes it to cycle to the next mode instead of reporting the current mode. "inc chase_mode" should be the correct way to do that (though it wouldn't wrap back to 0 after... whatever the max value is). (I've got a much larger list of preferences/defaults/suggestions I'm working on) I was running 1099 and found out in the "customize controls" menu, that "mwheeldown" binding doesn't display in the menu.
I have "mouse wheel down" bound for "next weapon" and it does allow me to bind it just fine, but the menu still displays it as ???, as if nothing wasn't bound (or if I have an additional alternate binding, it only displays it. Both bindings still work). Anyone else have this problem? Well, thanks gunter/mfx/tribal/esrael/jl for the polishing tweaks I need to do! Much appreciated!
I guess going into hibernation mode will have to wait a bit! But also why I did the (Stable?), thanks for the quality testing guys!! @Tribal: yeah, I lost the stamina to do it. I hear you and it is important. Can't promise I'll do it immediately, I'm tapped out a bit. But I do appreciate your testing. "r_noshadow_list contains bolt1.mdl doesn't exist in Quake"
maybe it exists in hipnotic, rogue, zerstorer or something like that. metlslime put in FitzQuake 0.85 for a reason, but I don't claim to know what single player it is intended for. hardware gamma I don't know. It's your computer. I assure you if says "shader gamma", it's using shader gamma. I'm still rooting for you to spill coffee on your computer, haha. I suggest creating an incident at Starbucks! ProQuake server list Dunno. I'll think about it for a Christmas-time release. I want to tune up anything small and take a break. I'm running on empty. Hm, pressing CTRL when the console is down (for ctrl+v) causes me to fire my gun.. (must be connected to a multiplayer game) Wow, that's interesting. It sure does! I was going to post "cannot reproduce" and then re-read about connecting to a multiplayer game so I connected to shmack and tried, and yes. That's a hell of an awesome catch!
I'd like to think I spot stuff like that. Baker fail +1. Now But I was "too clever by half" http://quakeone.com/markv
Download: Windows - DirectX | WinQuake Revision: 1) mwheeldown wasn't showing due to a <= vs < typo (esrael) 2) Link to DirectX 9 drivers on homepage (mfx) Experimental/requested extra builds: Alternate Builds Question of the day: Is DirectX Mark V faster than VxQuake (Vulkan)? I have reason to suspect DirectX Mark V is faster than VxQuake. (start.bsp beginning has a mirror there that Mark V uses so that is not a good test spot). Screenshot: DirectX Mark V sometimes 3x speed of FitzQuake 0.85
And from what I have seen, VxQuake using Vulkan is only about 15% faster than its source base. But the mh DirectX wrapper is offering a frames per second jump that is vastly greater than 15%. There's no point benchmarking an engine in small tight corners with very few polygons visible. This is the same syndrome as "50,000 fps in dm3 - woooo!!!!" - it's a meaningless statistic.
Benchmark it under heavy load, then do a comparison. You'll likely find that D3D9 MarkV is substantially slower than either QS or VkQuake (but substantially faster than Fitz) because it still hand-feeds all vertices to the GPU every frame, whereas QS or Vk store them in on-GPU buffers. But that all depends on where the bottleneck in your system actually is. For the record, I make absolutely no claim whatsoever that my cobbled-together wrapper is faster than properly written native code, and I would always recommend properly written native code over a wrapper. It's OK for Engine A to run at 200 fps in dm3 whereas Engine B might run at 5000 fps.
What matters is how they run in a map like sepulcher. If the same Engine A runs at 150 fps in sepulcher whereas the same Engine B runs at 30 fps, then Engine A is clearly the better performer. Waiiiit, Fitzquake had a noshadow list? Hmm, must have been inaccessible to the user, and only existed in the engine code? Ok, in that case, if you grabbed your list from Fitzquake, then it was Fitzquake that had an error in its list. Way back on the old page, I first reported that bolt.mdl was missing from the list, then I clarified that "bolt1.mdl needs to be renamed to bolt.mdl" See, that was just a typo in the original list: it did not contain the actual bolt.mdl but it did contain the non-existent bolt1.mdl (simply, the "1" should never have been there). So that's the reason Fitzquake had it there: a typo, not some intentional inclusion. Of course, even if it was an intentional inclusion to account for some specific mod, I would be against that too (it's not the engine's job to account for every custom model that a mod might use -- the correct option would be for the mod to include an altered noshadow list).... But it sure looks like it was just a typo. You did add the bolt.mdl that I pointed out was missing, but you didn't remove (or more correctly, rename) the bolt1.mdl which was there in its place, so now both bolt.mdl and bolt1.mdl are there... which is just building upon the original mistake instead of fully correcting it.
It looks like Quakespasm copied your early noshadow list (as stated here: http://quakespasm.sourceforge.net/Quakespasm.html#ss6.5 ) and never fixed the error (they don't have their own Gunter to point these things out to them!), as you can see in its code (i.e., bolt1.mdl instead of bolt.mdl): https://sourceforge.net/p/quakespasm/code/HEAD/tree/trunk/quakespasm/Quake/gl_rmain.c Hardware Gamma: Ok, then it is still using Shader Gama when it says Shader Gamma. The problem is that switching to any non 1024x600 fullscreen resolution resets my desktop hardware gamma setting just as if I were using the Hardware Gamma setting in Quake. i.e., normally my desktop gamma setting is adjusted up a bit, and that applies to Quake as well, so I don't have to adjust Gamma in Quake up by a lot. Using Shader Gamma in Quake in a window or fullscreen at 1024x600 doesn't alter my desktop gamma at all. Using the the Hardware Gamma setting in Quake, either in a window or in fullscreen, resets my desktop gamma, meaning I have to ramp up the gamma in Quake to make it brighter, then I have to reset my desktop gamma when I quit Quake.... The same gamma reset happens when using Shader Gamma, but only for full-screen resolutions other than 1024x600 (native). And just a note: you don't have to connect to an online server to test the CTRL/ALT buttons in console; just do New Multiplayer Game locally. Hey, would it at all be possible to allow mouse selection of text in the console for CTRL+C (copy text)? Oh, and there's little chance of me spilling coffee on my netbook... I don't drink coffee ;) Who would want to deal with a caffeinated Gunter?? And on the Second Day, Gunter posted his long list of feedback over here: http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3811
FitzQuake's no-shadow list was indeed hard-coded into the engine.
Compare it with the tempent parsing code and it seems evident that progs/bolt1.mdl was a typo/bug; the tempent code (correctly) has progs/bolt.mdl but does not have progs/bolt1.mdl; meantime the no-shadow list doesn't have progs/bolt.mdl; I don't think we need to debate this one. Hi,
first of all I'd like to say a big thank you for this excellent source port. I love playing the WinQuake version. A few months ago I made the following changes to the old 1036: * Fixed a bug in single player where a saved game wasn't properly reloaded after death (you fixed this too in 1050) * Changed all the defaults to make WinQuake look and feel exactly like the original * Hid all the customization menus but without removing the variables, so if a mod needs them, it will work * Limited the maximum resolution to 1280x1024 Ever since I made this, I've been following your changes and keeping my little fork updated, but I haven't uploaded it anywhere yet. Since Mark V isn't on github or a similar site, I didn't want to just upload it and make it look like I'm the author so I wanted to ask if you're planning on uploading Mark V on github or a similar site, so I can fork the project and give you the credit that you deserve. Heyyy, I like the idea of having a fork that "Changed all the defaults to make [Quake] look and feel exactly like the original"... to a certain extent; I mean, I see no need to remove menus that allow for easy customization, and if a user wants a higher resolution, there's no need to prevent them from selecting it.
I have no problem with making all kinds of changes (I enjoy tweaking and playing with settings... which is why I break so many things in bugtesting!), but the default Quake look and feel should always be the starting point (which was the vast content of the post I just made on my forum -- all the actual reasons why I would like many settings to be reverted to the Quake Default, as they produce unwanted behaviors for me). In any case, no disrespect to Baker, who is the true mastermind behind Mark V, but I (and others) would absolutely prefer use a fork which addressed all the issue I have with altering Quake defaults. AND maybe dosse91 would remove the intentional blocking of OGG support! :D Don't worry, I'd still bugtest here ;) Though I might run into issues with dosse91's fork trying to make everything like WinQuake whereas I prefer hardware-rendered Quake.... MAKE YOUR OWN github repo call it sporkV or something then not its a test fork of markV with a link to Baker's website. or make your github private and only show it off to baker? or no just compare notes.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |