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. 

Thanks Pritchard, that explanation seems a lot more likely than mine. The difference it makes on my system is batshit crazy though, that's why I thought it had to be cpu rendered. While mark v sometimes dips down to less than 10 frames in busy areas you won't even notice as much as a hiccup in quakespasm.

I guess I'll have to switch engines for now, I'm gonna miss you zoom button... :( 

Pritchard has the right of it.

When drawing objects, every single component of every single vertex has CPU overhead in MarkV that doesn't exist in QuakeSpasm.

For any given scene this overhead is based on the number of polygons and number of vertexes in the scene, so it's fixed irrespective of resolution.

Small scenes - like in ID1 maps - are barely affected, which is why it won't be noticeable if all you ever do is e.g play DM3.

As the polygon count goes up the overhead gets more and more. 

Baker what features and stuff do you think you might want to implement in Mark V's next release?

(Crazy and Stupid) Ideas:
Atleast try to support orl's Zeangala map or what ever its called.Who knows,someone might make an adin1 like bbin1
Create feature like in reQuiem
(Might need to check this one)
Music command like in QuakeSpasm
Some proper coding!

So far I know 4 coders doing engine stuff
1.MadGypsy
2.Baker
3.Spike
4.LordHavoc 

Does anyone know why the skull models change size between the different resolutions? That's some crazy beans... 

Sort of, at least. In a proof-of-concept way.

https://www.youtube.com/watch?v=aJJ8005Ig0A&feature=youtu.be

The video makes it look pretty crappy and stuttery, but it actually runs and feels awesome. The only real downside to this method is that you have to be incredibly careful not to make any sudden mouse movements, that causes the borderless window to stop capturing the cursor for a fraction of a second and the magnifier will register that movement, jerking the viewframe in whatever direction you happened to be aiming.

Keyboard aiming it is then! I can handle that. Probably. 

 

You could always use a joypad?