;) 

I'll be thinking of your persistence in 3 weeks when I'll have 2 XBox controllers on a specific weekend and digging into XInput tutorials.

A year ago, I would not think I would be doing such a thing. ;-)

Sometimes I also question what reality I am living in where I can actually do these things on a whim. A few years ago, I was quite the novice and I still don't entirely understand how I acquired the level of expertise I now have nor what induced me to make a software renderer version nor how I did the majority of it in 3 weeks. It's like "Flowers for Algernon".

I blame hanging around mh and Spike.

5 foot away, there is a beer that needs drinking. I now must attend to this urgent matter ...

/End slight ramble. But incredible things are in the pipeline for the next Mark V. 

Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 

Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 

Is literally a dream scenario for me. I host regular game nights and buy a lot of MP games for it. Being able to make death arenas for my friends would be epic 

Sorry for the spam. Currently at work posting from my phone 

 

I have the same trouble others mentioned with the app not launching on Mac. My Quake folder is in Applications, and has the id1 folder in there alongside Mark V Quake. When launched, I get a dialog that reads

"Your Quake folder should contain a folder named id1 with pak0.pak and pak1.pak.

Opening folder ..."

and then I get

"W_LoadWadFile: couldn't load gfx.wad

Game data files are required to run; usually this means you need Quake shareware or registered version.

Is Mark V in the proper folder?

()"

Other Mac Quake files work (Fruits of Dojo, Tenebrae), so I'm confounded. 

It looks like the problem is with the Sierra Quarantine Attribute

Followed the instructions here, and all's working now.

https://derflounder.wordpress.com/2012/11/20/clearing-the-quarantine-extended-attribute-from-downloaded-applications/ 

Suggestion: something that saves your most recent previously-used resolution.

So like, if I was in 1024x600 Full-Screen and I used the menu to change to 800x600 Windowed, when I press ALT-TAB it should take me back to 1024x600 Full-Screen (it takes me to 800x600 Fullscreen).

I note that this already works in the other direction -- starting in a Windowed mode and changing to Full-Screen in the menu, then using Alt-Tab will toggle me correctly between those two modes.

I'd like an actual permanent saving of the previous mode used (when it's a change from full-screen and windowed -- like save it in a CFG file) so that this behavior will persist even upon starting a new game. Then I could easily toggle between the windowed and full-screen modes I want to use, automatically. 

Hopefully in the next release, there will be better rendering for transparency...

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

on C:\Quake and the music is working on the game again. It doesn't like being on D:\Games\Quake for some reason.

Music is on mp3. I have an E:\ blu-ray drive and an F:\ backup external. 

...despite being well under the vertex limit.

@Baker

I posted a thread addressing the issue over at Quakeone, R00k sent me this way to get a hold of you. Did all the troubleshooting I could initially think of. Thought you might find this interesting:

http://quakeone.com/forums/quake-help/quake-clients/13277-mark-v-crashes-certain-model.html#post174852 

When this model is converted to strips and fans it comes in at 4284 vertexes, which overflows an internal buffer that's particular to MarkV and was introduced by the shadow code I contributed.

@Baker: increase MAX_LERPED_VERTS to 8192 seems to be one way of handling this because it's consistent with the other counts in gl_mesh.c; at least it means that if a model crashes this it will also crash other engines. 

Thanks for the reply mh. I had a feeling the culprit was right in front of me while scanning through gl_mesh. I'm more on the QC side of coding though, so I wasn't entirely sure what all I was looking at. 

I just tried out Arcane Dimension for the first time, and I'm just blown away by it. I really want to play through each and every level of that mod, but there is something preventing me from enjoying it.

Up until now I've used the winquake version for playing quake, and while that is perfectly fine for the official quake content and my own maps it doesn't get along with high-caliber stuff like AD very well. On one hand there are graphical issues with transparency that are to be expected, but the performance also takes such a drastic hit from all the cool effects and increased polycount in every level that it's just not playable any more.

The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse. Because unless I want to stare at a blurry mess, I need to render in my laptops native resolution of 1336x768 instead of stretched 320x240, which more than nullifies the benefit of hardware rendering in terms of raw performance.

Why is stretching only supported in the software version? I know that most gl-based engines only support 640x480 as the lowest output resolution you can select in the menu, but it's clearly possible to render the actual game in resolutions much lower than that since you can adjust the screen size in the menu to achieve just that. I took a screenshot of the smallest screen size in hardware mark v at 1366x768, which results in the actual rendering resolution only being slightly larger than 320x240. If you would implement a feature that scales this window to fit the screen borders again, that would have the same effect as the stretching feature in software mark v, right? Is that how the feature works in that version?

I can't judge how much work implementing this would be, or if it's even possible at all. It seems like it should work to me, but there very well might be hard limitations preventing the feature from being in hardware mark v in the first place that I'm unaware of. I just want to let the devs know that this feature would be huge to me and everyone else who loves chunky pixels coupled with smooth performance.

I'm surprised so little people seem to play quake this way to the point where there is pretty much no support for it, software mark v being a rare exception. Most players seem to prefer resolutions that utilize every pixel of their screen, but I just can't enjoy quake that way. It has nothing to do with nostalgia in my case, I missed the pixel-period of gaming by quite a bit since quake is actually slightly older than me. It just feels so much more alive in low resolutions. It has to do with how everything is constantly changing shape as you get closer or farther away from it, for example how particles blend seamlessly with the chunky environment, choppy animations seem to flow naturally, flames look like hand-drawn sprites at some distances or how you sometimes can't even tell what monster is waiting for you at the end of a dark hallway. Viewing lava and water at an angle also look incredibly organic due to this, even though they're just a single texture tile repeated over and over. If you look at all these things on a high resolution with interpolated textures and lerped animations, that magic feeling completely fades out of existence. You suddenly see everything very clearly for what it actually is: simple brushes, blurry textures, and crude animations. It feels like looking behind the stage even though you're actually still looking at the stage. That is apparently just what happens when you force a game two decades old to conform to today's graphical standards. It should look objectively better due to the modern improvements, but it just doesn't, not to me at least. I don't want to bash on everyone how enjoys quake at normal resolutions though, even if I'm coming on pretty strong here. I'm really happy that quake has evolved into something that can be so many things and has an engine for pretty much everyone and their personal preferences, and I'm thankful that even less popular ones like mine are represented to some degree in the community and in mark v, even if just in the software version.

I'd happily do the work of porting the feature myself, but I lack any kind of knowledge that goes beyond the very basic level of fiddling with quakec and have no idea where to even start tackling things related to rendering, making this plea to devs my best shot at getting the quake engine of my dreams for now. I'm gonna keep learning more about quake development and programming in general though, it's just going really slowly since I'm far from being a John Carmack and feel like I'm up against something my puny brain can barely comprehend whenever I look through the source code.

Guess that concludes this wall of text, thank you for sticking with it me the end. :) 

This makes me want to try playing at that resolution. I hope you get your wish for increased support! 

just a matter of turning on "pixels" mode? Forgot how to do it. 

setting these cvars:

r_lerpmodels 0
r_lerpmove 0
gl_texturemode gl_nearest

should make MarkV/Quakespasm closer to what you want, other than the resolution.

Yeah, this is a good request. So to summarize, the ability to render at a res like 320x240, and then scale (unfiltered) to a higher resolution (lcd native res). 

there is a gl version of Mark V winquake which has resolution scaling.

I didn't read the wall of text, maybe I'm missing something? 

I tried it and I got a headache :( 

I read the whole text and @killpixel, yes, boristhesp1der did try running Mark V in Winquake mode. But that didn't run fluidly in AD. He's looking for a Winquake alternative that runs AD fluidly while playing in a Winquake 320:240 resolution. This is essentially what you wanted to say @boris?
320:240 is my thing as well, at least when I play the original maps from ID. I use the Mark V Winquake for that because it supports folder-music instead of CD. As for modern maps I use Quakespasm with
gl_texturemode GL_NEAREST_MIPMAP_LINEAR because everybody knows that GL textureinterpolation looks rubbish with Quake's low-res look. 

bummer. Well, he could try Darkplaces. HEAR ME OUT.

there's a retro shader for DP floating around. along with that try these:

r_viewscale .5 (or .25)
gl_texturemode gl_nearest force
r_lerpmodels 0
r_lerpsprites 0

should give him a fairly retro look until he find a more faithful alternative. 

The funny thing is that the obvious solution of switching to hardware mark v actually makes things even worse.

This is the way things are going to be so long as MarkV uses glBegin/glEnd code.

In an ideal world scenario: MarkV would move to vertex array and VBO code, the D3D version can be scrapped (because bad GL drivers are no longer an issue once you start coding sensibly to begin with) and better GL ES compatibility would come about as a bonus.

Resolution scaling won't help much with this. It will help with fillrate but with glBegin/glEnd code it would still be pushing the same amount of vertexes and draw calls irrespective of resolution, which is where the real bottleneck is.

Call to action: get on Baker's arse and get the glBegin/glEnd code killed. 

Since rendering is the current topic, what are the chances of getting proper transparency depth in Mark V?
http://i.imgur.com/eMcO57f.png

It's thankfully not too obvious in my map yet but it is pretty annoying.