Windows XP Service Pack 3


Uh... what grey particles? Oh, was that about the chaingun weapons? It would be nice if they made sparks like when a nail hits the wall.


My ninja bubbles are definitely sprites (I did the standard water drowning bubbles in the demos too). I usually use a replacement sprite texture though. Actually, I mentioned in the past, the replacement sprite texture that is included in the Quake Retexturing Project comes out as invisible in Mark V DX, so I had to alter its opacity. In any case, I've tested this new bug just using the standard bubble sprite too, so it's not the previous issue (qmb_bubbles replace the sprites anyway). Yeah, s_bubble.spr is pale blue, usually. When I watch bubbles1.dem I can toggle qmb_active 1 and the bubbles instantly go invisible, but they re-appear as soon as I set it back to qmb_active 0.... In both DX and GL versions. Were the qmb_bubbles invisible for you in the bubbles1.dem? And did they appear to move really choppily in bubbles3.dem?


Oh my... yes, I can imagine the twisty mess of code that's doing transparency in DX, because I'm getting strange results. But transparency DOES work even with gl_overbright_models 0 ... depending on... circumstances.


For example:

r_viewmodel_ring 1
external_textures 0
gl_fullbright_models 0

grab a ring (e4m6 has one at the start) and your gun will be opaque... But not the axe. The axe is alwys transparent. But no other gun.

Unless you activate external_textures 1 (and you actually have replacement textures). Then all your guns are transparent....

Setting gl_overbright_models 1 also makes everything correctly transparent.... 

Maybe there are a few separate particle scenarios. I'll check each one out. 

For clarity, can I get demo name + time into the demo for each separate issue so I don't miss one.

Like bubbles1.dem @ 18:45, etc. 

Here is what I'm going to do ...

If an alias model (.mdl) has .alpha (transparency) ...

I'm going to force fullbright + overbright off for the rendering.

That will make your DX8 transparency look pretty much the same. Will probably add an unsaved cvar to disable the behavior, merely for possible future rendering testing purposes.

But this will effectively remedy the DX8 .alpha entity "looks less transparent than GL, and if overbright_models is off isn't transparent at all if overbrights off" issue. 

The demos are very short, and it's all the same issue -- qmb bubbles being weird. Though there are two different, related weird behaviors.

The issue starts out as the qmb bubbles moving very choppily, and after the map runs for a while, they just become completely invisible. This only happens when connected to a server.

I tested these demos on my older WinXP laptop and I see the same result in both DX and GL.

bubbles1.dem -- shows the qmb bubbles being invisible. This should be dramatically obvious -- just watch it with qmb_active 0 (or qmb_bubbles 0) and you will see that the ninja throws a row of bombs using the bubble sprite. Then turn on the qmb bubbles... and you won't see them anymore.

bubbles2.dem -- just shows that the qmb bubbles work correctly when not connected to a server.

bubbles3.dem -- the qmb bubbles are doing the choppy movement. It's like the engine is struggling to render them or something.... Again, just watch with either qmb_active 1 or qmb_active 0 to see the difference -- the standard bubbles move smoothly. Hmm, I wonder if maybe the qmb bubbles look choppy because they are invisible PART of the time....

Wait a minute... I wonder if this has to do with ticrate... let me test.


Yep, that's it! Mark V's rendering of the qmb bubbles is somehow affected by server ticrate. I can imagine if that gets out of sync, it could be drawing them invisible when it should be drawing them visible, or something....

The standard bubble sprite rendering doesn't suffer from this - they seem to move smoothly.

Yeah, when I'm connected to FvF with a .1 ticrate, the qmb bubbles (only) seem to move as if I'm playing locally with host_maxfps 10

Adjusting the ticrate to .05 or .01 smooths out their motion.


Ohhh, another possibility: since QMB is replacing the bubble sprite with an EFFECT, perhaps the movement of that effect is not subject to motion interpolation, which is why it seems to jump along at the ticrate instead of moving smoothly?

That wouldn't quite explain the complete invisibility though.... And other effects seem to move smoothly.... Like the underwater bubbles from explosions or nails -- they move smoothly. 

These things you are discovering me always aggravated me about QMB back in earlier times.

I'm going to see if I can fix them by rewriting the code to be more precise about what happens.

I may be able to fix the bubble lerping interpolation too, great job thinking about that -- makes a lot of sense.

The problem with how QMB was written is that it wasn't too friendly with what modders like to do and somewhat inconsistently changes the modder's intended particles, and in a way that appears random.

Time to replace that with some sensible consistency that can also be turned off ;-) 

dwere, what Malice monster is the one that you are saying is multipart and only renders consistently in WinQuake and Enhanced WinQuake, but not even Mark V WinQuake.

Is it monster_banshee?

I'm having difficulty locating one in game? Is there a certain map it appears on.

Want to inspect that. 

"and somewhat inconsistently changes the modder's intended particles, and in a way that appears random.

Time to replace that with some sensible consistency that can also be turned off ;-)"

Indeed.

I added a new short demo to the zip called splash.dem, to demonstrate an example of just what you are talking about, involving a blue particle water splash effect I made. Hopefully this is one of the issues you can address:

http://fvfonline.com/bubbles.zip

Just watch splash.dem with qmb particles disabled, then watch it with them enabled to see..... 

If the monster in question is a banshee.

On map d12, I am at 2812 -668 -104 and looking at one. You can type setpos 2812 -668 -104 after loading d12 to teleport there.

It looks fine in the opengl version and the winquake version.

Is it a different monster with issue. Or a specific map. A save game or demo would be useful, I can't seem to recreate the issue. 

@gunter --- when you were doing the auto-connect test earlier were you using port 26000? Doesn't change that the Spiked Quakespasm networking code prefers Windows Vista and later operating system for best results and certain enhanced features, but server auto-detect requires server using port 26000. 

Is it monster_banshee?

Yes, it's one of them. The other one is called "Takahiro Rider" (don't know the internal name).

Off the top of my head, a banshee can be found on d8.bsp. Cheat yourself keys to speed things up, go to the yellow lift. You'll end up in a big square room. The banshee mech is gonna be revealed when the middle section opens.

Sorry, should've told that earlier. 

The ones in d12 work for me, but on d8 it appears without head most of the time. 

Haha ... yeah that doesn't look right. The top isn't there. 

Yep, default port 26000



I don't suppose these monsters you are looking at have skins with alpha transparency? That caused my replacement bubble sprite to be invisible.... 

You can type sv_novis 1 for that map to make even the top part of the monster visible in that room.

The upper model (banbody.mdl) is highly unusual as it is highly above the model centerpointer ("the origin" in QuakeC).

On the server side, I think it thinks that part of model is in the ceiling.

A can't change how server side visibility works, it would potentially bust modern compatibility with modern map releases.

Mark V WinQuake tries to handle it like the GLQuake engines for consistency.

/At some point, I might do some more thinking since technically "WinQuake is, by, definition actual Quake" -- but in practice, the GLQuake engines have been the dominant ones for 15 years -- which is why I made Mark V WinQuake handle things like a GLQuake engine. It isn't immediately clear if there is any change that could resolve this without breaking something else as a side-effect, but many times after thinking about things for a few days I might get an idea.

I was hoping using NightFright's Malice .vis files might fix, but it didn't. 

Well, thanks for looking into it anyway. 

I also experienced this back then when I was testing Malice by myself. However, I was focussing on the showstopper bugs that had still exited back then.

In case you don't find a way to solve this, it's not the end of the world imho since the addon itself remains quite playable. Which is quite something. 

I've already outlined possible solutions.

I do not like incompatibility.

I want the engine to be able to play everything the way it is meant and the way it worked with original Quake.

I'm hardcore about that. 

The qmb lighting bolt has transparency problems with vid_hardwaregamma 0
The lower your txgamma setting, the more noticeable it gets. Or maybe just modifying the setting makes it stick out more....

Just shoot some lightning and do a freezeall and you'll see what I mean.
Actually, now that I'm looking for it I can see it faintly when using hardware gamma too -- it's just more noticeable using txgamma.


But the view blends... the view blends look PERFECT when using txgamma.... Not too dark, not too light. I guess gamma adjustments really mess with those. 

... and I'm REALLY picky about my view blends.... But these look JUST RIGHT. 

The axe is alwys transparent. But no other gun.

Axe is the one gun without fullbright pixels, so probably follows a different codepath that doesn't use the fullbright mask. 

What metlslime said.

@gunter ... since you can find moving sprites (I honestly don't know of any moving sprites in any mod except yours, makes lerping of sprites real hard to test), the QMB bubble's lerping in next build will be test candidate.

If you say it works, fine -- I'll apply lerping to all sprites. 

I honestly don't know of any moving sprites in any mod except yours, makes lerping of sprites real hard to test
Go into the water in e1m4, the air bubbles coming from the doorway on the right side are moving spirtes, I think? The player makes them when choking, too. 

steam & flame in rubicon 2 are sprites. 

@ericw -- e1m4 .. keep forgetting about those bubbles.

@dwere - sv_setmodelrealbox 0 -- before map load gets the job done.

Is no doubt an ok setting for playing the entire Malice mod. Like "game malice; sv_gameplayfix_setmodelrealbox 0" in console which reverts to ancient style WinQuake culling boxes.

sv_gameplayfix_setmodelrealbox defaults to 1 (1 = FitzQuake culling/physics box, 0 = WinQuake culling/physics box).

That banbody.mdl model is pretty awkward, I don't if it thinks it is in several visibility leafs or just all the ones it thinks it is in are wrong or what.