Problem with DLIGHTS > 32

[Baker]

I've looked at both Qrack and the RMQ engine to try to bump up MAX_DLIGHTS properly above 32, using 128.

1. I expanded dlightbits from int to 4 ints. (32 bytes x 4 = 128 bits) in gl_model.h

Code: Select all

NEW:   int         dlightbits[(MAX_DLIGHTS + 31) >> 5];   // mh - 128 dynamic lights
OLD:   int         dlightbits;

2. R_Marklights clears all 4 ints and sets the appropriate bit if affected by dynamic lighting.

Code: Select all

         if (surf->dlightframe != r_dlightframecount) // not dynamic until now
         {
            surf->dlightbits[0] = surf->dlightbits[1] = surf->dlightbits[2] = surf->dlightbits[3] = 0;
//            memset (surf->dlightbits, 0, sizeof (surf->dlightbits));
            surf->dlightframe = r_dlightframecount;
         }
         // mark the surf and ent for this dlight
         surf->dlightbits[num >> 5] |= 1 << (num & 31);

3. R_AddDynamicLights checks the appropriate bit in the group of 4 ints

Code: Select all

      if ( !(surf->dlightbits[lnum >> 5] & (1 << (lnum & 31))))      //MH

And I get an invalid surface that somehow gets marked on a particular demo on Warpspasm warps.bsp and it crashes with an exception. The surface looks like it has invalid texture information. The above changes are straightforward enough, I'm wondering if something in FitzQuake's gl_model.c might not be allocating memory right or at least in a way that isn't very flexible for surfaces? I'm not seeing anything like that in

msurface_t is the in memory representation of a surface. As far as I know, I should be able to add 12 bytes (3 more ints) and for the most part handle it how I want.

Any thoughts? I'm thinking my problem is related to a memory corruption and looking at gl_model.c to see how msurface_t is getting allocated and seeing how the data is filled in ...

[Baker]

Nevermind!

Wasn't aware there was a tutorial on this.

viewtopic.php?f=12&t=4257

(Sheesh ... I had omitted something stupid. No wonder it crashed .... Grrrr. Dumb mistake. Then again I wasn't using the tutorial, but still ...)

[taniwha]

Ah, but because you tried to implement it on your own, you truly understood the tutorial. And because you understood the tutorial, you know what you did wrong. Maybe next time you'll be able to avoid the same mistake .

I'll have to take a look at the tut

[r00k]

In 1.9 I blindly increased dlights without any backbone to it
Same for lightmaps I need to nix half life map support it's kinda useless and breaks demos
Except in DirectQ and dark places

[Spike]

regarding extended lightstyles and demo/protocol incompatibility, just don't send/write those lightstyles if they're empty, and make sure they're properly cleared on map changes.

[r00k]

I can appreciate that, i opened a book trying to make something of a better client than proquake in 2003 based on joequake. I was focusing on the QRP engine then saw QMB particles, and the flow of quakesource.com additions, and jq encompassed most. and i jumped on that codebase. I am more a quakeC coder and a player. So im kinda biased. I get first hand bitching from the player base. Mostly. mods are focal and player dont care about useability of a feature if its not focused on their game (mod).. i just get caught up with mr jones when no one knows him...

[mh]

Definitely agreed that it's great that you tried to implement it yourself. I learned so much from taking the same approach back when I started out (including when to say "OK, time to stop trying myself and copy what someone else has done!" ). Sure I made some horrible mistakes at the time, but I've no regrets about the experience.