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. 

shwing 

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 ... these old computers -- the drivers will never be updated, so the Direct3D 8 wrapper can never become obsolete.

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 ... throw in some Nehahra support and some extra level of backwards compatability for QRally, Malice, any other crazy stuff.

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) ... have their additions coded in a backwards looking but future-forward engine.

/Already then! Back to coding! This lines of code aren't going to write themselves ... haha 

"The nicest thing about the Direct3D 8 wrapper for old computers ... these old computers -- the drivers will never be updated, so the Direct3D 8 wrapper can never become obsolete."

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