Just make sure you upload the changed map regardless of result. ;-) 

Quakespasm: Had controller support recently added, I'm wondering if it can be adapted into this?

Mark V does everything natively on both Windows and the Mac. The kind of things you need system access to do.

SDL2 is a wrapper, its goal is not providing system access. So a number of the nice things Mark V can do, especially on Windows but some on the Mac too, it wouldn't be able to do.

Case in point, add -resizable to your command line and you can resize the Mark V window like any other Windows application. SDL2 would not like that. I could name several other examples, but they are all very boring.

Mark V needs low level access to many things.

SDL2 makes everything easy, but puts lots of limits in your face. I'm not really a "limits" kind of guy.

/I hope that explanation helps. 

r_lockpvs (invented by MH)

Invented by Quake 2 :) 

Download at usual location:

http://quakeone.com/markv

New ...

- Sparks? Lightning? QMB option greatly enhanced! Video
- Mac version improved, both Open GL | WinQuake (johhny law)
- Several QMB enhancements (gunter)
- Installer enhancements handles more packaging types (Pritchard)
- Per weapon external crosshair support (c0burn)
- Several improvements to DX8 version (gunter)
- Theoretical func_illusionary mirrors (pulsar)
- Mark V page links good codecs, not link to bloatware. (Bloughsburgh)

Improvements to Nehahra support and many other small polishing/ hardening modifications.

Possible final build for 2016. If no issues, this release is promoted to Mark V - Version 1.1 Final.

(*) Awaiting on pulsar's map testing results for mirrors.

MH is working on creating a heavily updated Direct X 9 version wrapper for the engine.

If you have ever seen MH's DirectQ engine -- 5,000 frames per second on 2012 era hardware -- and is still listed on Quaddicted as Spirit's recommended engine of choice for Windows ... 

Didn't forget about you --- I sort of underestimated difficulty of rolling up what I was hoping to do (didn't realize how much video code I would have to combine, hadn't looked at it lately). And also had more last minute issues to resolve than I anticipated. I'm very sorry, I was hoping for this version. 

Translucent windows don't work in Jump. Is this normal?

Also, I noticed that the Winquake version complains about gl_texturemode (it's in my autoexec) in the console. It ignores other GL-specific commands, even though it doesn't recognize them when they're being entered. 

Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?

It's like a 30 minute fix, but I decided to procrastinate -- because far too many things are a 30 minute fix and I've pretty burnt out and have been for a week or so.

Mark V WinQuake recognizes all the console variables that Mark V Open GL recognizes -- but in Mark V is gl_texturemode is a command just like FitzQuake 0.85, so that's why that message happens. I'll consider making that silent for the future. 

Is that the alpha sorting issue NewHouse was talking about that affects Mark V and Quakespasm in general abuse?

Not sure, can't find that discussion. The windows are translucent in QS, but they're opaque in Mark V. 

Are the windows tranlucent (partially transparent) or masked textures (totally see through)?

Mark V does not support masked textures on world model, if the 2nd case. It breaks vis and several other things including (sv_cullentities).

And if it is the 2nd thing, it won't get changed. Spike and other top-tier experts know why it is improper, and I'm ok with things that are broken by improper design not working right in this engine.

I'm don't do race to the bottom. I understand that some map authors target broken engines, I'm fine with those things being broken in Mark V.

There are 1500 single player releases. 

I wanted to say it's the former, but now that I looked more closely - it's more complex than that. Though I'm not sure if it changes anything.

A window is made of 2 layers:

1. A translucent texture without any "holes" in it. This is glass. There's some space behind it.

2. An additional masked texture in front of it - to make the frame look solid, apparently. It's also translucent for some reason, though it's not very noticeable.

http://i.imgur.com/zcSFt8A.png

Masked texture is see-through in Mark V, but both textures are opaque.

http://i.imgur.com/qTMSaG9.png 

It's all good! Don't overwork yourself on my account, I'm simply a beneficiary of your time and skill. In the meantime, I'm collecting various maps/episodes to replay when the new wquake drops... it just doesn't feel right playing in anything else :P 

Ok, I've been thinking about custom crosshair possibilities.

Having a different crosshair for each gun? Boring, inside-the-box thinking.

What would I do if you gave me the ability to use 24 custom crosshair images? I'd make an interactive crosshair that would act like radar and point in the direction of the nearest enemy. 24 images would be perfect for that: 8 directions x 3 height levels (low, medium, and high) to show you the direction and relative height of the enemy.

Yes, this would require the use of stuffcmds. There is nothing wrong with stuffcmds. Sure, they can be misused (but so can anything else in a mod). But in this case, it would be a fine way for the server to send information to the client to update their crosshair image to show the direction of the nearest enemy.

However, to maintain compatibility and not mess with people's crosshairs who aren't using Mark V, perhaps the custom crosshair stuff should be moved to a new console variable, like newcrosshair.

So you could actually have both the old crosshair AND a new crosshair image active at the same time. And I could be sending stuffcmd only for newcrosshair so that it wouldn't touch their standard crosshair value, if they didn't have my custom crosshair images.

To be extra sure about compatibility for other mods that might use stuffcmd to change custom crosshairs with the standard crosshair command, then "newcrosshair -1" would make newcrosshair use whatever setting is in crosshair.


So I guess whatever you're doing with crosshair could exist alongside what I want to do with crosshair.....

Though I'm not sure how many people will actually make use of the thing you're doing (different crosshair for each gun). But I'm completely certain I would do the thing I am thinking about, if you gave me the ability to select specific crosshair images by use of stuffcmd :D 

MH is working on creating a heavily updated Direct X 9 version wrapper for the engine.

Timing is good because you've indicated you're coming to a timeout, which gives me more time to get stuck in and get things working well.

I want everybody to be realistic about expectations here though.

You're not going to get 5,000 fps from this.

Part of the advantage of going native with an API is that you can deeply optimize for the strengths of that API. Going through a GL to D3D layer means that a lot of those optimization opportunities just don't even exist. I could talk the hind legs off a donkey about examples, but it would be sidetracking too much. I just expect people to believe me when I say this. 

So because QS uses lots of external .dll files it just makes stuff easy for things like controller support?

I look forward to testing this stuff when its ready 

... about this port is that it's coming without any external DLLs at all. Also one of the reasons why Mark V is my favorite. 

In that temp build func_illusionary mirror doesn't work as well for me. I checked in both test map and the real map.

Here's the new test map: http://www.quaketastic.com/files/test_mirror2.zip 

@Baker: thank you very much for the crosshair addition, and fixing the dev command crashes! I have to admit to not even realising that MarkV supported crosshair replacements in the first place, but the per-weapon idea is very nice and I actually think my mod could make use of it. 

I have a new bug where sprites don't appear. My explosion sprites are fine, but the waypoint sprites in my waypoint editor are invisible. Any ideas? Fine in quakespasm. 

Are the sprites bubbles?
Do you have QMB effects enabled?
Do the sprites have replacement textures with alpha transparency? 

Um... we noticed on the FvF server that e5end (from DOPA) does not appear to have properly viss'd transparent water in Mark V, but sometimes it does or used to or something weird. r_novis 1 makes it look transparent, of course.

I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those....

It just doesn't in Mark V.

What's up with that? Something weird about that map? 

@c0burn - Can you provide a way for me to create that scenario, I'll like to check it out.

@dwere - in the jump map where the issue exists, could you type viewpos and post where in the map the issue exists?

@gunter - is this easy to find? 

Next I do an update, I need to make it so any time somoene does a screenshot, it writes the game, mapname and map coordinates in the meta data in the PNG.

I looked at the Jump map, noclipped all around the place and can't find this location in your screenshot, but I'd sure like to check it out and see it.

So if you can post the "viewpos" coordinates I'd like to look at it.



@gunter - Justed loaded up e5end. The autotransparency detection waits a few frames before beginning to check. Something about being located above the water and immediately falling in is tricking it. 

Frankly, I don't even remember myself which window it was.

But it shouldn't matter, because all windows are opaque for me. I deleted my config and autoexec in case I screwed up the settings somehow, but nothing changed. 

@dwere - looks like its just scenario in the engine where entities that are both .alpha and have alpha masking.

I must not have anticipated a scenario where both of those would be going on with the same entity.

Excellent engine test case!

The map author did everything right and the map is very designed. I'll address that one when I resume working the end. 

I just tried it in Quakespasm and in Proquake, and the water looks correctly transparent in both those....
Note that quakespasm defaults to gl_clear 1 so HOMs render as solid grey, and transparent water on maps that are vised for opaque water will render as grey-tinted. There's nothing special in QS about detecting water vis, so it was probably rendering against the grey void.