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. 

@boris - I've been impressed by your ability to self-solve issues (main reason why I am posting since I'm mentally not here, yeah you really impress me). Open GL can't really scale pixels when rendering, although since I'm not AAA+++ in rendering someone may mention a frame buffer trick or shader trick with 6 asterisks next to it.

@pritchard - you didn't state the problem and I'm not level 25 at mind reading, only level 22 although I aspire to be level 25 some day. If it is depth sorting, the answer is yes! because that is on my list.

@mh - "glBegin/glEnd" It kills my soul somehow. I've actually not eliminated glBegin/glEnd for Open GL ES. I created an extra renderer Open GL ES "wrapper" that throws them in VBO. ;-) That being said, yeah I agree in principle. (Insert: I'm probably 6 weeks from doing an update even though technically I have one ready, is there is an update to remedy alpha entity for D3D? No need for an immediate reply, just planning ahead a bit).

@adib - "just a matter of turning on "pixels" mode? Forgot how to do it." --- It's in the video options menu.

@fifth - When Spike sees what I did, he'll fucking hate me. Spike's skill > Baker. Baker's creativity > Spike. I admire Spike. I plan to smoke him a bit. It's not all what your powers are, it is also what you can do with your powers.

@Spike - "oggs" --- In real life, no one has ever heard of an "ogg". It's a technically inferior poor man's mp3 used in a few Quake engines --- no where else in any game or any medium is an "ogg" a format a ordinary user has ever heard of. The mp3 patents have expired. Ogg have no future.

The Unreal Engine doesn't support ogg.
The iPhone can't play an ogg.
The Anroid phone doesn't do oggs.
There is no future for ogg.

The question isn't why DarkPlaces doesn't do mp3. No actually that is the question.

I like it when someone complains about the lack of ogg support in Mark V. When the next Mark V comes out, I expect mega-tons more complaining.

Complaining is awesome. Because complaining is the backbone of progress. 

that makes OTP and Shambler the most progressive people on this forum... ;)

Nah seriously, can't wait to see what stuff gets added this year. I agree about Ogg. I used to be a fan when the MP3 patent was restricting people but it's served it's purpose now. 

Yeah, there will be "mega-tons" more complaining.

Because the next release Mark V will be the first true "5 platform" engine. The iPhone/iPad and Android.

And for anyone who has watched any of the videos, yeah Mark V just happen to run on a mobile platform --- it will run fucking awesome on a mobile platform -- in a way no one has ever done.

And it will be a stealth release.

A. Like the past versions of Mark V, I will make nominally a zero effort to promote it. I'm not looking to mainstream Mark V, this engine is meant for those few of us left that enjoy Quake for what it is.

B. iPhone App Store. Yeah, I'm not doing that. Someone with a Mac doing a self-compile and share amongst friends is how that is going to work -- in a best case scenario.

/Six to Eight Weeks Probably a Ground Break Release. Six to Eight Minutes -- my ETA for a beer run. Ill-advised post? Aren't they usually? Haha. Cheers! 

Shambler is a complainer who has put blood and sweat and intellectual sophistication and effort into his passion. I once got into an argument with Mugwump and he said "You are the opposite of Shambler" and I was like "Well, I hate to say this but I probably agree with him on nearly everything ... my only difference would be that I place a high value on diversity".

/I now resume my end-of-night beer run. 

but it's usually the way things are said rather than what is said that can be irk-some. :P

I think if you're doing mobile platforms it will be interesting to some but control is definitely going to be the biggest hurdle to overcome. 

So another reason to get it sooner. 

is there is an update to remedy alpha entity for D3D?

Remind me again of what the issue was? There's quite a bit of chatter about alpha stuff in this thread, with the most recent I recall being depth sorting issues, which aren't API-specific, so I'm unclear on this. 

Kind of a bummer that scaling on hardware is out of the question though. I'm still gonna share the mockups I made though, so you can actually see what I had envisioned for yourself.

https://drive.google.com/drive/u/0/folders/0BzKtjR7p3BXdRnRHVTd1QVVhak0

I just scaled screenshots from regular mark v down to different "integer fractions" (sounds weird but I don't know the proper term for that, I mean scaling in such a way that the resulting resolution contains no decimal numbers in both axes) of 1334x768 to make them look software-rendered. The result is actually pretty different from the real thing for a number of reasons, the most obvious being atmosphere. Coloured lighting and fog really make a world of difference, and this screenshot alone doesn't even do that statement justice.

In the unlikely case anyone is actually interested in this, I noticed a few interesting things making these mockups. Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software. The skill pillars and everything at their distance looks noticeably worse at 3x in reality because software quake starts to blur out the textures at a certain distance from the player, which is unfortunately not quite far enough away for the transition to happen seamlessly. (Fixing that would be a fun project, eh?)

You'll notice that as the scaler increases, there start to be more versions of the same mockup with numbers attached to them. Those signify how the picture was scaled from the original, which can make a world of difference in the end result. 1 means scaled down in 1 step from 1344x768, 2 means first down to half at 672x384 and then to the end result, 3 means first half, then third, and then end result, etc. Most of the time one step looks the best, but sometimes multiple steps actually preserve some details that would otherwise be lost, like the metal edge on the lower step of the stairs. I also had this anomaly for the 6x scaler where no matter whether I scaled from 1x or 2x, the result was exactly the same down to every last pixel. That doesn't happen in any other scaling scenario. Thought it had something to with scaling from an even to another even scaler at first, but it didn't work for 4, 8, 12, or 24. I used GIMP to scale the whole image without interpolation, so If anyone can explain what happened there I'd be interested to hear.

On somewhat of a related note, and since problems with transparency are hot topic right now, I'd like to present you the following:

http://imgur.com/gallery/zqaX5

Is there a way to get software mark v beefed up to deal with this? I don't know if the crash is actually caused by those transparent textures, but that level (foggy bogbottom) runs (for a few seconds at least) far worse than all the others and is the only one filled with them, so it's probably not that far fetched. 

is a feature I wouldn't mind included if it was ever possible. I like the blocky aesthetic 

Take the skulls for example, which change size in software mark v depending on your scaler. Candles change position and also get a different model on hardware/software.

Heh, the candles don't change because hardware/software - they change because the candle entity is deliberately set up to spawn a random version each time (they come in many variations of tall/short/thick/thin)

The skulls changing size though is some funky shit - why is that happening? 

For what it's worth, hardware resolution scaling is possible. Never said that it wasn't.

You do need render-to-texture to do it with best performance, which means OpenGL 3.0 or GL_EXT_framebuffer_object.

A slower GL1.1 path involves a glCopyTexSubImage call.

The point that I need to be absolutely clear about is that MarkV's bottleneck is elsewhere, so hardware resolution scaling would give marginal improvements to it. With e.g. QuakeSpasm it would be worthwhile for cases that are fillrate-bound, but MarkV isn't fillrate-bound. MarkV is CPU-bound. 

Is regular Mark V also rendered on cpu? I just assumed a gpu was a requirement for opengl. So Mark V essentially emulates gpu-features on a cpu? Is that correct? I don't know enough about this stuff...

That certainly would explain why performance is so bad. Apparently my poopy laptop isn't at fault after all, I just tried running those levels in quakespasm and they run at a stable 60. I hadn't even considered that to be a possibility, mostly because my laptop struggles to run just about anything that came out in the last 15 years. 

By CPU-Bound, mh means (I think) that the performance limiting factors in markv are operations that are always done on the CPU in all games.

I'm no graphics programmer, but as I understand it, the CPU has to explicitly ask the GPU to draw each frame. If it takes too long, it won't matter how fast your GPU is because it's just sitting idle a lot of the time.
Quakespasm sends it's draw calls in a different way to markv which means that the GPU can always be busy, or at least busy more often to the point where upgrading your GPU will make a difference.

I might be wrong about all this so take it with a grain of salt.