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 .app to a different directory (this clears some security metadata), in order for the application to load things from its current directory (i.e. find an id1 directory along side the .app).

Could be related.. 

Interesting! I'm on 10.11.6 though, so that's not hitting me, but might affect other people. 

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 

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