GLHexen2 Warpos.

[Cowcat]

...In fact -nomouse implies in the code, "leave it untouched as the system has it". So....

[BSzili]

I'll ask sezero about the sheep catapult thing, he could know something about what goes on there.

[Cowcat]

BSzili:

It's more than the catapult. The whole level has that issue & this is what I found:

sv_effect.c /SV_SendEffect : After

case CE_WHITE_SMOKE:
	case CE_GREEN_SMOKE:
	case CE_GREY_SMOKE:
	case CE_RED_SMOKE:
	case CE_SLOW_WHITE_SMOKE:
	case CE_TELESMK1:
	case CE_TELESMK2:
	case CE_GHOST:
	case CE_REDCLOUD:
	case CE_FLAMESTREAM:
	case CE_ACID_MUZZFL:
	case CE_FLAMEWALL:
	case CE_FLAMEWALL2:
	case CE_ONFIRE:

Just paste this check:

Con_Printf("sv_effect - %d\n", sv.Effects[idx].type);

That gives "4" on screen everytime you hit a wall and white stuff appears.

Now when you go to that level (The castle key mission), this check shows constantly.

Don't really know if its related, but the frame drop is very noticeable.

[BSzili]

Could it be that the level simply has a smoke emitter somewhere? Raven didn't implement client side effect system until Heretic 2, so effects always go through the C/S architecture. You might want to check SV_SendEffect, also there is a "sv_ce_scale" CVAR which you can set to 1 to do distance culling on the effect I think.

[Cowcat]

Shit, I messed up "showfps"


Good tip with sv_ce_scale & his companion sv_ce_max_size, but nothing seems to change: The framerate drop stills there as well the message.

[BSzili]

Have you tried to set a small value like 0.1 or 0.01 for sv_ce_scale to reduce the cutoff distance even more? It would be interesting to check the coordinates to see where this offending effect is on the map.

[Cowcat]

I was using sv_ce_scale wrong, but now given lower 1.0 values still the same. Just getting closer to the castle there's a good framedrop. Normal in certain circunstances because the animations there but inside or just wandering closer to the catapult you see those problems: The effect never dissapears.

I assume that "4" could be WHITE_SMOKE -> "punching wall = smoke effect". So who is punching ?

[grelbfarlk]

New beta orks well for me but I can't figure out the sequence of events that causes the gamepad to work. One time it will start and lowlevel.library showed port 0 Mouse port 1 Joystick. I was able to bind keys to it and everything was working but on next reboot lowlevel library showed 4 devices Port 0 mouse, port 1 joystick, port 2 and 3 unknown. And it didn't work again. Come to think of it I removed -nomouse too at this time.

[BSzili]

This is what you need to do:
1. Start JoyPortTest and make sure the type reported is joystick/gameport
2. Start the game

[grelbfarlk]

Originally Posted by BSzili

This is what you need to do:
1. Start JoyPortTest and make sure the type reported is joystick/gameport
2. Start the game

I can't follow simple instructions, so here's what I did.
1. I started game gameport is reported as unknown device
2. Started JoyPortTest and it is recognized as joypad
3. Started Game and it works.

Is it preloading lowlevel.library or something that makes it work, do you think?

[BSzili]

Your instructions don't look that complicated either. The problem is that lowlevel.library needs some input from the device to autodetect its type. (Now that I think about it, I should have added "push some buttons" as an additional step.) I originally wrote the joystick code for Poseidon, where the types are available right from the beginning for all of the ports. This is a faulty assumption with the genuine lowlevel.library, so I'll have to remove the startup detection, and simply check the controler type when reading from the port.
So in a nutshell yes, lowlevel.library has to be preloaded and it needs some input from the controller before starting the game for the time being.

[grelbfarlk]

Originally Posted by BSzili

Your instructions don't look that complicated either. The problem is that lowlevel.library needs some input from the device to autodetect its type. (Now that I think about it, I should have added "push some buttons" as an additional step.) I originally wrote the joystick code for Poseidon, where the types are available right from the beginning for all of the ports. This is a faulty assumption with the genuine lowlevel.library, so I'll have to remove the startup detection, and simply check the controler type when reading from the port.
So in a nutshell yes, lowlevel.library has to be preloaded and it needs some input from the controller before starting the game for the time being.

I tried just mashing some buttons before launching the game, that didn't work. So just loading joyporttest isn't a big deal, it works consistently. I could try loading joy2key with no profile loaded to preload lowlevel.library or something if I need to.

[BSzili]

If lowlevel.library isn't loaded, then pushing buttons won't do you any good. The purpose of joyporttest is that, and to give you some visual feedback of the detected controllers.

[grelbfarlk]

Right, anyway the workaround is fine. And actually Hexen 2 has the nice benefit (for me) of seeing the 4 way joystick control as Aux buttons rather than X-Axis and Y-Axis that I had setting up properly on Quake 2, nice job on this.

[Cowcat]

Found the offending effect: It's the vapor coming from a cauldron inside the castle.

The framedrop in this particular level comes from the entities (models) camping around: When you destroy/kill whatever you see, it starts to alleviate.

So no problem (?) -> just a matter of cpu cycles.

Edit: Why this effect is working outside the room/area it belongs ? I did a new wire/line drawing mode & combined with noclip you see the effect some walls before all other models are drawn....

[BSzili]

That's probably the side-effect of the client-server effect code. The server has no idea what the client can see so it always sends it. I'd check why the distance culling doesn't cut off the effect. What's the map name BTW?

[Cowcat]

What's the map name BTW?

Barbican.

Anyways that goes beyond the Amiga port. Still don't know if really does hurt performance.

[Cowcat]

BSzili:

A clumsy & totally irrelevant video on the net just to show what it is all about.

[ Show youtube player ]

Of course "wireframe" function comes from an undisclosed BlitzQuake 6.2 (but not in red background ).

[BSzili]

I just checked and sv_ce_scale works fine, at least in the Windows version. If I set sv_ce_scale to 1 and move away from cauldron on Barbican to the doorway the smoke disappears.

[Cowcat]

Yep. Doing the same check as you & being in the same place as in the video, the effect dissapears just after the first wall.

Ok, It's the way the code does his thing, checking all the possible effects from wherever part of the level, THEN checking the distance & THEN applying the effect.
Mistake from my part, I was seeing the first checks.

Just another useless video & time spent