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]

cl_truelightning in JoeQuake 0/1

The implementation is very light, mostly just (A) adding a cvar ...

Code: Select all

cl_main.c(34): cvar_t   cl_truelightning = {"cl_truelightning", "0"};
cl_main.c(1120): Cvar_Register (&cl_truelightning);
cl_tent.c(444): if (cl_truelightning.value)
cl_tent.c(449): f = max(0, min(1, cl_truelightning.value));
client.h(252): extern   cvar_t   cl_truelightning;
host.c(852): Cvar_SetValue (&cl_truelightning, 0);

(B) And then adding an if statement in a single function in cl_tent.c ...

cl_tent.c

Code: Select all

void CL_UpdateBeams (void)
{
   int      i;
   float   d;
   beam_t   *b;
   vec3_t   dist, org, beamstart, ang;
   entity_t *ent;
#ifdef GLQUAKE
   int      j;
   vec3_t   beamend;
#endif

   // update lightning
   for (i = 0, b = cl_beams ; i < MAX_BEAMS ; i++, b++)
   {
      if (!b->model || b->endtime < cl.time)
         continue;

      // if coming from the player, update the start position
      if (b->entity == cl.viewentity)
      {
         VectorCopy (cl_entities[cl.viewentity].origin, b->start);
         b->start[2] += cl.crouch;
         if (cl_truelightning.value)
         {
            vec3_t   forward, v, org, ang;
            float   f, delta;

            f = max(0, min(1, cl_truelightning.value));

            VectorSubtract (playerbeam_end, cl_entities[cl.viewentity].origin, v);
            v[2] -= DEFAULT_VIEWHEIGHT;   // adjust for view height
            vectoangles (v, ang);

            // lerp pitch
            ang[0] = -ang[0];
            if (ang[0] < -180)
               ang[0] += 360;
            ang[0] += (cl.viewangles[0] - ang[0]) * f;

            // lerp yaw
            delta = cl.viewangles[1] - ang[1];
            if (delta > 180)
               delta -= 360;
            if (delta < -180)
               delta += 360;
            ang[1] += delta * f;

            AngleVectors (ang, forward, NULL, NULL);
            VectorScale (forward, 600, forward);
            VectorCopy (cl_entities[cl.viewentity].origin, org);
            org[2] += 16;
            VectorAdd (org, forward, b->end);

            TraceLineN (org, b->end, b->end, NULL);
         }
      }

      // calculate pitch and yaw
      VectorSubtract (b->end, b->start, dist);
      vectoangles (dist, ang);

      // add new entities for the lightning
      VectorCopy (b->start, org);
      VectorCopy (b->start, beamstart);
      d = VectorNormalize (dist);
      VectorScale (dist, 30, dist);

      for ( ; d > 0 ; d -= 30)
      {
#ifdef GLQUAKE
         if (qmb_initialized && gl_part_lightning.value)
         {
            VectorAdd (org, dist, beamend);
            for (j = 0 ; j < 3 ; j++)
               beamend[j] += (rand() % 10) - 5;
            QMB_LightningBeam (beamstart, beamend);
            VectorCopy (beamend, beamstart);
         }
         else
#endif
         {
            if (!(ent = CL_NewTempEntity()))
               return;

            VectorCopy (org, ent->origin);
            ent->model = b->model;
            ent->angles[0] = ang[0];
            ent->angles[1] = ang[1];
            ent->angles[2] = rand() % 360;
         }

         VectorAdd (org, dist, org);
      }
   }
}

You might need to copy over a math vector function or 2,

[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]

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.

Super8 isn't a niche engine. It does more than most of the others, otherwise you wouldn't have a fan base.

But yeah, in the modern era it is okay for an engine to do unusual stuff, but anything retro Quake-breaking needs to have an off-switch.

Look at what DarkPlaces did a couple of years ago, defaulting all the Quake breaking stuff [that has an off switch] to off. It makes mappers angry to make something for general purpose Quake and it breaks in someone's engine that decided to do something that Quake breaks with standard Quake.

[qbism]

Good point, but what IS the expected retro behavior here 20 years out? DP defaults cl_beams_quakepositionhack to 1.

Code: Select all

cvar_t cl_beams_quakepositionhack = {CVAR_SAVE, "cl_beams_quakepositionhack", "1", "makes your lightning gun appear to fire from your waist (as in Quake and QuakeWorld)"};


[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: qbismS8-test-01-02-16.zip

[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]

Looks like Joequake hacks all the beams, not just bolt2.mdl. And why not?

Hacking all beams will break the grappling hook from one of the official mission packs.

A clean way to implement this is to create a new SVC message using angles and a length instead of an end position. Such angles would be cumulative with the origin entity's angles, thus remaining perfectly aligned — even in monsters or in other players.

Baker: HL's GoldSrc engine support for alphamasked textures is rudimentar, it doesn't support overdraw between multiple alphamasked textures. In fact, I suspect it doesn't support multiple overdraws of any kind.

[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]

Also the files are smaller after this.
Updated progs mdls zip: https://qbism.com/download/file.php?id=29

You might let Sock know about that

Qbism, seriously man this is not how you fix stuff! The reason all your converted models are smaller is because Noesis has reduced all the models down to ONE SKIN! This model patch will not work because different monster/items use different skins!

I can understand people want to help and fix stuff for their engine, but seriously contact me, I have email, twitter and a website, there is plenty of people who could even pass on a message to me! I have no problems working with people to fix their engine with this mod, in fact I encourage it!

I am really so pissed off by this, people trust what you say on this forum and you are distributing a zip file which breaks more with the mod than it fixes!?!

[qbism]

That file was deleted two days ago. Sorry that I did not mention it on this board. I was sidetracked by a different discussion. From qbism.com

func_qbism » Fri Jan 01, 2016 10:09 pm
EDIT: link fixed above. Just realized these mdls do not include multiple skins of the originals (like misc_digit.mdl). Looking into it... Loading and saving in Quark worked