Nuncabola

[fwp]

Just wanted to let anyone who might be interested know that as of version 0.199, Nuncabola supports clock items.

As usual, downloads are available from the Nuncabola website.

[parasti]

Awesome!

[fwp]

Now that the collectible clocks are an official part of Neverball, it just seemed appropriate to port the functionality. Since calling the game client directly from the game server is not an option in Nuncabola, I reconstructed the gained time from the timer commands in the command stream. It works as long as the time increases are positive integers. Maybe we should consider something like CMD_GAIN_TIME to make things more robust?

BTW, I haven't really been active lately, but I did notice that a number of cool features were added to Neverball in the last year and a half. My favourite is probably the resizable window (and in turn the resizable GUI).

[parasti]

Good to have you back! I feel like I'm doing Neverball development in slow motion, myself, because life just gives me a couple hours here and there. For that reason I haven't thought much about the gained time issue, but, yeah, seems like it should be a (stateless) replay command.

[fwp]

Slow motion or not, not only are you still around after all these years, you continue to move things forward. Not many projects have maintainers like that.

As for the command, if it were stateless, how would the client know how much time was gained? I was thinking of having the command carry an integer containing the accumulated total amount of time gained in either seconds or 1/100ths of a second. This would be similar to the way coins are handled: a coin is picked up, its value is added, and the result is reported via CMD_COINS. Such a time-gained command would then remove the need to call incr_gained from the server.

[parasti]

Yeah, I meant stateless in the way you described: the command would hold the total value rather than a delta value.

[ersohnstyne]

On Windows Terminal, when you try to download with using HTTPS from cURL command, this causes certificate error.

curl: (60) schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt.

[ghost]

I'm still waiting LWJGL 3.3.1 support...

[fwp]

Hello, a small update for Nuncabola is available.

Nuncabola 0.201

• Ported moving entities (Neverball 2024-05-07)
• Ported hierarchical paths (no caching for now) (Neverball 2024-05-15)
• Support clock items in untimed levels (Neverball 2024-01-06)
• Wireframe mode fixes (Neverball 2024-07-12)
• Allow empty lines in sets.txt and level set files (Neverball 2023-11-15)
• Data folder update (Neverball 2025-04-03)

Some technical comments (@parasti):

Replay compatibility

With the introduction of moving entities, a change was made in Neverball to ensure that only a single mover is used for a given path. Previously, new movers were created even if different bodies shared the same path. There was an earlier discussion that touched on this. I think it's a sensible design decision. It does, however, cause trouble with mismatching mover indices in certain older replays. For Nuncabola, I added a bit of code to the game client to remedy this by remapping the mover index as needed.

Furthermore, Neverball no longer supports dynamic item creation based on replay commands, presumably because it would have been hard to reconcile with the mover system. Again, the right decision, I think. However, it affects older replays if the item order in the level has changed in the meantime. To fix this, Nuncabola will try to locate picked-up items by their type/value/position, also accounting for coins that were moved slightly. For newer replays, the specified item index is used as usual.

As an aside, do we still need dynamically created balls? (Were they ever really needed?)

Hierarchical paths

This is a cool feature, too. Should solid_all.c::sol_body_w recursively check for oriented parent paths?

Timer calculation

There's a small bug in game_server.c::game_update_time. For a timed level, when time_elapsed exceeds time_limit (triggering a time-out shortly after), the fabsf call will result in a positive timer value when it should be 0.0f.

Also, in hud.c::hud_update, when a clock item has just been collected in an untimed level, the code path for lost time is executed instead of the one for gained time.

Ball resizing

I didn't adopt the new way of calculating the ball size when resizing because it's dependent on the UPS rate. If the rate were, say, 91 instead of 90, the ball might never stop growing or shrinking.

Particle rendering

With particle rendering in Neverball no longer being based on point sprites, what's the rationale for part.c creating its own VBO/EBO instead of just using the existing billboard renderer? Nuncabola does the latter, and I'm trying to find out whether there's a reason to make changes.

[parasti]

Congrats on the release and a big thanks for the code review (so to speak) - your attention to detail was sorely missed!

Hijacking this thread a bit to respond:

Particle rendering: yes, the right call is to just use billboard rendering. I think I started on that a while ago, but no time.

Ball resizing: oops, I seem to have hardcoded an epsilon in the resize-terminating condition that only worked for UPS = 90. Fixed it now (I hope).

Timer: I fixed the game_update_time edge case, but didn't do anything about hud_update yet.

Hierarchical paths: I gotta admit that I have no idea if sol_body_w should check recursively. It answers the question "can this body ever change orientation". So I guess not doing a recursive check might result in some collision bugs when the ball is in contact with a stationary body that is attached to a hierarchical path that is about to change the body's orientation... It's breaking my brain, but I suppose the answer is "yes, it should check recursively".

Replay compatibility: yes, I was aware of potential replay breakages due to the mover allocation changes. It is annoying me (not much but somewhat), but I don't have time to put into that.

[parasti]

BTW, on the dynamic ball creation commands - that was meant to facilitate some sort of multiplexing of replays so you could do ghost replays during gameplay. I never got around to actually implementing any of it, so it's just an artifact of the past.

[fwp]

Thanks for the fast reply!

Dynamic ball creation commands: Oh, I see. I remember reading a Neverforum thread about ghost replays, but had forgotten the commands were related to those.

Hierarchical paths: Yeah, it was my thought too that the sol_body_w check should be recursive. Following the mover/path/mover/... chain to the end isn't hard to do but there are aspects that complicate things. Like, what are the actual implications if on some level of the hierarchy a path is enabled? It becomes kind of hard to think about. Also there's the case where a body has a rotational mover that's different from the linear mover but the latter has an ancestor that can rotate. Now you have two different sources of rotation when the collision detection only expects one (via bp->mj).

Replay compatibility (movers): The mover change affects replays made with versions from 2011-09-16 (introduction of the mover commands) to 2024-05-07. Funnily enough, replays that are even older don't have this problem since the obsolete body path/time commands reference bodies directly. As for the maps where there's a difference between a non-optimized mover list and an optimized one, I count 23 among the official ones (excluding Misc) and 200+ among contributions. That doesn't mean that every replay of these levels looks broken, though.

Replay compatibility (items): It turns out that the item change has an effect not only on the relatively few cases in which the item order has changed in the map file, but most replays made before 2012-01-06 when mapc started sorting/reordering items. So basically my entire Nevertable career. 😄