Someone Set Us Up The Bomb
#831 posted by Baker on 2017/01/10 01:37:55
Mark V - Version 1.25 Beta
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.
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.)
#832 posted by JimBob on 2017/01/10 04:02:32
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?
Winquake GL Runs Great
#833 posted by killpixel
on 2017/01/10 05:16:51
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*
#834 posted by Gunter on 2017/01/10 06:37:00
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.
I've Been Watching College Football
#835 posted by Baker on 2017/01/10 07:54:57
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.
#836 posted by Baker on 2017/01/10 07:59:22
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!
#837 posted by ＰＲＩＴＣＨＡＲＤ
on 2017/01/10 08:08:02
I'm glad that Baker got this far with the releases before succumbing to alcohol poisoning.
#838 posted by dwere
on 2017/01/10 09:14:39
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).
#839 posted by mh on 2017/01/10 09:31:10
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.
This Is Epic
#840 posted by NightFright on 2017/01/10 09:41:02
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)!
20/24 Beer Defeated -- Guess What? I'm Still Rational
#841 posted by Baker on 2017/01/10 09:56:29
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!
#842 posted by damage_inc on 2017/01/10 13:08:44
... the next version will be: Mark V - SPIKED
with beerzzz :-P
Comes with a free sax pick on download!
Monsieur, With These Rocher You Are Really Spoiling Us!
#843 posted by Kinn
on 2017/01/10 13:55:17
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!
#844 posted by killpixel
on 2017/01/10 18:21:19
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.
#845 posted by JimBob on 2017/01/10 19:11:51
@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!
#846 posted by mh on 2017/01/10 19:58:28
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.
#847 posted by Gunter on 2017/01/10 20:02:09
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).
#848 posted by Baker on 2017/01/10 20:17:40
@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.
@gunter - Texture Gamma Is All Me And 0% DirectX 9
#849 posted by Baker on 2017/01/10 20:25:12
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.
#850 posted by Baker on 2017/01/10 20:29:37
Mark V fails to exec my config.cfg
I thought I noticed that. Will have to investigate.
Ah, I See
#851 posted by killpixel
on 2017/01/10 20:30:41
I get 150-200 fps at 1920x1080 with the win build.
@gunter - Part 2
#852 posted by Baker on 2017/01/10 20:33:00
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.
#853 posted by dwere
on 2017/01/10 20:33:39
I don't need it, and it's not there right now.
#854 posted by mh on 2017/01/10 20:34:26
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.
#855 posted by Baker on 2017/01/10 20:36:16
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 ;-)