qbismSuper8 builds

[qbism]

AD runs but maybe it's getting too late for tonight... I think I saw a ghost in the Firetop Mountain start map...

There's a hack, from quakeworld I guess, that locks beam origins to client view. Lightning looks smoother in multiplayer but it's not moddable. cl_beams_quakepositionhack (from DP?) would allow it to be turned-off for custom positioning. Seems pretty easy to implement. I may also try 'cl_beam_position_x' , y , and z to allow the hack AND custom position. Maybe exists already in some form in DP or FTE? The logic needs to be a little unusual for compatibility: If any c_beam_position cvar is set, cl_beams_quakepositionhack will be ignored.

Probably too early to poke the mappers yet. I'll see if anyone else can confirm the fix, or if it's an hallucination.

[Baker]

JoeQuake has r_truelightning 0/1 or some such thing.

It sounds like it is the togglable implementation of what you have going on here.

/Me personally, since true lightning is a lie especially in multiplayer where you are not seeing the actual result of the lightning but a fabrication, I don't like it. That plus I intensely dislike game options and cvars and menus, but that's just my personal approach. I reluctantly added a "preferences" menu in Mark V, mostly to expose controversial choices where no right answer exists (gun placement Fitz vs. WinQuake, etc.) --- and hated every second of coding that menu.

[Spike]

aye... cvars are just a nightmare. Sure, they're useful for a quick tweak, but now you have undocumented behaviours that may or may not be enabled that either breaks your mod, or has to be changed in order to fix that mod, and just to make life more fun, different engines have different cvar names and even values to do the exact same thing in a slightly different way.

so yeah, cvars are evil.
there's not really any way around them though, other than providing gamecode with a way to do whatever it wants and completely bypass your added cvars. which makes those cvars pointless of course.


qbsim, the only two things I can think of that could cause that sort of issue are 1) incorrect frame bounds, with the model being half offscreen. 2) degenerate triangles resulting in nans and negatives in your span code.

removing degenerate triangles would be one explaination for noesis writing smaller files, although there are other possibilities like the previous exporter generating a load of redundant junk verticies (which would likely carry a higher risk of degenerates too, to be fair).

[Baker]

[qbism]

Looks like Joequake hacks all the beams, not just bolt2.mdl. And why not? I also take Spike's point on cvar creep. Besides the quantity of cvars, this is an example of different engines with slightly different behaviour (and cvar names) for the same general function.

Yet to stay in-the-game nowadays an engine must chase mod and mapping trends. With the goals of simplicity and relevance at odds, there is a price to be paid for a niche engine like super8. Therefore, for every new cvar added, an old one will be sacrificed.

[Baker]

[qbism]

[Baker]

3 of the Arcane Dimensions maps don't work in DarkPlaces.

Sure the beams cvar has nothing to do with that, but the thing is that engines that deviate from standard Quake behavior are placing a heavy burden on map authors to try to figure out why X, Y or Z doesn't work.

Hell, I remember back in 2006 playing single player maps in DarkPlaces and silver key dropping out the maps --- I didn't notice this until I couldn't finish the maps.

[qbism]

The deviations from standard have been catching up recently. I haven't thought about it, but looking back, this is represented in most of the few super8 commits in 2015. -sndspeed and entity alpha come to mind.

I've fussed occasionally about map/mod deviations which should not be supported. Engines should avoid bad-behavior, which is anything that is hard to code for software-mode A nightmare example that emerged from Rubicon Rumble Pack is entity alphatest (fence texturing). Really should only be set per-texture with texture flags. Texture flags in Quake means naming conventions. We might could use a simple shader system. starting to get off-topic...

Test build with cl_beams_quakepositionhack cvar:

[Baker]

I do know Half Life 1 had alpha masked textures all over the place.

And the original Half Life had a software renderer.

So it's been done in Quake derivative engine in a software renderer.

A quick peek at https://github.com/ValveSoftware/halflife --- I guess they never put the Goldsrc engine on github.

[mankrip]

[Baker]

I'll have to play it in software mode sometime and look around.

[qbism]

super8 supports alphamask, or more specifically colorkey textures, but no overdraw.

mankrip: that explains the 'bolt2.mdl' bloody hack! I expect there is a dp extension or similar. Beams look smooth in the Quake 1.5 project as shown in Seven's video. There's a thread at quakeone.com.

[sock]

[qbism]