waterwarp size is 1024

This is just a notification that should only happen at startup and when/if the video mode changes. If it's happening more often (every frame) it's a bug. It's nothing to do with water surfaces but is rather used for the underwater warp effect.

It happens even if the current map has no water because the next one (or the previous one) might.

The alternative is to destroy and recreate the texture each map, which could lead to extreme video RAM fragmentation, or to create it on-demand which (in addition to fragementation) could cause runtime hitches and stalls. So I decided instead to burn a little extra memory in exchange for performance.

gl_nearest_mipmap_Linear

This should be fully supported; I've reviewed both my original wrapper code and the MarkV implementation and can confirm that. 

I actually checked explicitly for that. The only options for the pixelated look are gl_nearest and gl_nearest_mipmap_nearest. Just like in the previous (OpenGL) builds.

Smooth mipmaps transition ftw! ^^ 

It should be settable from the console though. If something's missing from a menu option it's nothing to do with the API used. 

Egads. I version 1.36, I had gl_nearest_mipmap_nearest. Then I knew it needed to be the "other one".

So I switched it to gl_nearest_mipmap_linear. Then I forgot I did it.

Then I worked the todo list and switched it to the "other one" again and since it was gl_nearest_mipmap_linear in the source, I changed it to gl_nearest_mipmap_nearest. 

Then basically you switched it twice so it was effectively as if you had never changed it?

Well, now please just change it ONCE again and I can die happily. ;) 

I'm trying to cause this developer 1 + r_waterwarp message, but not having any luck. 

Line 812 of gl_texmgr.c is where it happens. 

Direct X | WinQuake - Windows rebuilds
(killpixel's winquake gl in there too)

Got rid of dumptruck's warp message printing in developer 1 and another message that was spamming some, gl_nearest_mipmap_linear replaces gl_nearest_mipmap_nearest and fixed noticed the menu being drawn during QuakeC or demo playback or disconnect go to console. 

That was a really fast fix. Thanks a lot, Baker! Another proof that Mark V should be anyone's favorite vanilla-style port since it's handled so well! :) 

thanks for the update! 

 

Mk V DirectX 1081 crashes to desktop without error message (just the usual Windows notification that the program "stopped working") when trying to use the remade ogre model by Chillo:

Download (1.0 MB):
http://www.quaketastic.com/files/models/Ogre_2.zip

Tested in E1L2, crashed right away. The model is quite big, but I dunno if that's what's causing the crash. 

What engines is it known to work in? It looks like DarkPlaces and DirectQ.

Mark V supports 3984 verts, the maximum possible in WinQuake according to a note by aguirRe.

If it works in Quakespasm, for instance, let me know. 

It also works in my original FitzQuake implementation that I built the D3D wrapper on. 

Model loads without issues in latest Quakespasm 0.93 x64 build. According to QuarK, it has 1290 triangles. 

Number of triangles in a .MDL file can be very differrent to number of triangles in an engine. Most engines will unpack them to strips and fans for drawing whih can change the counts quite dramatically.

Basically, it's completely unsafe to limit the verts in a GL engine to the same limit as is used in software.

@Baker: running a debug build should tell you exactly where this crashes. 

Another of Chillo's models, the Shalrath, gives an error message when trying to load the model:

"Skin taller than 480"

Package with model (shalrath.mdl):
http://www.quaketastic.com/files/models/chillo.zip 

Ignore my last report. Just took a look at the Shalrath skin file, it's obviously a placeholder. It's just still about that ogre model, then. 

E4M6 crashes with the Authentic model improvements pack. This used to work with previous (OpenGL) builds of Mark V.

Download model pack:
http://www.quaketastic.com/files/models/auth_mdl163.zip

I could not identify which of the models is causing the problem. 

There are more maps that crash. I checked all maps of the original campaign and the model improvement pack does not work in these levels:

E1M5
E4M3
E4M4
E4M6 (as reported above) 

These maps likewise work fine in my original codebase.

It's obviously a model that's common to them all overflowing an internal buffer that's differently-sized in MarkV. 

I found the model that causes the problem. If you remove the Fiend model from the improvement pack (demon.mdl), the maps stop crashing.

This leaves two models to be investigated, demon.mdl from the existing improvement pack and ogre.mdl from Chillo's release. 

The only thing I can find as a possibility is mipmap generation for non-power-of-two textures.

In my original code I let D3D take over mipmap generation, whereas MarkV retains it's own mipmap generation.

These models have unusual texture sizes: odd numbers, not multiples of 4, etc. So when you go down a miplevel you need to be aware of whether you are going down exactly to half size, or if rounding down is involved, and depending on how the engine handles memory allocations for this, it may trigger a crash. 

Well, curiously the models won't work with Mark V 1.36, either. I just tried. However, they should since I remember playing through the entire game at least with the demon model since it is already in the improvements pack. 

I just tested various DX9 builds from previous Mark V releases. The last one that works with BOTH models without crashing is 1.27 rev. B:

http://quakeone.com/markv/builds/1027_mark_v_dx9_revision_b.zip

Starting at 1.28, the crashes start:

http://quakeone.com/markv/builds/1028_mark_v_beta_dx9_opengl_dx8.zip

Hopefully that narrows it down for Baker to find what's causing this.