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 

@gunter ... nice catches x 2! 

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. 

It also seems that interface scaling doesn't work in the Winquake version. 

 

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 ... 8-bit palette, very pixeliated rendering -- some releases like Kaahoo look obsoletely astonishing in a way that the Open GL engines can't quite do.

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!

.. and included a link to Mark V WinQuake in the Arcane Dimensions readme for anyone who wanted to try it.

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 .alpha). 

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 ... how could I have forgotten that step."

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 ... potentially thinking that a bubble's time has always expired.

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 check the main menu of the nehahra mod
i couldn't select the "quit" parm from there