-- [ Picked text/plain from multipart/alternative ] Maybe if you incorporate mapster protocols in there too it will help? :^D
http://countermap.counter-strike.net/Mapster Chris Blane wrote: >Had a feeling I might start seeing this topic crop up on the list Zipster. >:) Still no luck with that last bug eh? > >:Tal-N >----- Original Message ----- >From: Skyler York <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Tuesday, April 16, 2002 7:56 AM >Subject: [hlcoders] HLVIS (Warning, technical details and code) > > >>[ Converted text/html to text/plain ] >>I've been working on a few new features for HLVIS, and I have been making >> >good > >>progess. One of the features is a new maximum VIS option. In addition to >>being able to compile the map the first time around with this new feature, >> >you > >>can chose to run a MaxDistVis on an already compiled map. >> >>This is my problem. If you run a MaxDistVis during the initial compile, >> >the > >>the code flags the correct leafs to be invisible: >> >>------------------------------------------------ >>// i = leafnum of first leaf, j = leafnum of second leaf >>offset_l = i >> 3; >>bit_l = (1 << (i & 7)); >>offset_tl = j >> 3; >>bit_tl = (1 << (j & 7)); >> >>for(k = 0; k < l->numportals; k++) >>{ >> for(m = 0; m < tl->numportals; m++) >> { >> l->portals[k]->mightsee[offset_tl] &= ~bit_tl; >> tl->portals[m]->mightsee[offset_l] &= ~bit_l; >> } >> } >> >>---------------------------------------------- >>It basically eliminates leafs before they are even fully VISed. >> >>However, if you run a MaxDistVis on an already compiled map, for the most >>part, the leafs rendered in game are correct, except for a few oddball >> >leafs > >>that aren't "unset" in the code for some unknown reason. The detection is >> >the > >>same, but it doesn't unset them. What I have to do first is decompress >> >all > >>the vis information: >>------------------------------------------------- >>void DecompressAll(void) >>{ >> int i; >> byte *dest; >> for(i = 0; i < g_portalleafs; i++) >> { >> dest = g_uncompressed + i * g_bitbytes; >> DecompressVis((const unsigned char*)(g_dvisdata + >> >(byte)g_dleafs[i + > >>1].visofs), dest, g_bitbytes); >> } >>} >>------------------------------------------------ >> >>I use this code to "unset" leafs: >>----------------------------------------------- >>// i = leafnum of first leaf, j = leafnum of second leaf >>byte* base_vis_l = g_uncompressed + i * g_bitbytes; >>byte* base_vis_tl = g_uncompressed + j * g_bitbytes; >>offset_l = i >> 3; >>bit_l = (1 << (i & 7)); >>offset_tl = j >> 3; >>bit_tl = (1 << (j & 7)); >>base_vis_l[offset_tl] &= ~bit_tl; >>base_vis_tl[offset_l] &= ~bit_l; >> >>------------------------------------------------ >> >>...and this code to recompress the vis info: >>------------------------------------------------ >>void CompressAll(void) >>{ >> int i, x = 0; >> byte *dest; >> byte *src; >> byte compressed[MAX_MAP_LEAFS / 8]; >> vismap_p = vismap; >> >> for(i = 0; i < g_portalleafs; i++) >> { >> memset(&compressed, 0, sizeof(compressed)); >> src = g_uncompressed + i * g_bitbytes; >> >> // Compress all leafs into global compression buffer >> x = CompressVis(src, g_bitbytes, compressed, sizeof(compressed)); >> dest = vismap_p; >> vismap_p += x; >> if (vismap_p > vismap_end) >> { >> Error("Vismap expansion overflow"); >> } >> >> g_dleafs[i + 1].visofs = dest - vismap; // leaf 0 is a >>common solid >> memcpy(dest, compressed, x); >> } >>} >>-------------------------------------------------- >> >>It works at around a 90% - 95% success rate, but those oddball leafs annoy >> >me. > >>Before I forget, here are some pics of what I mean. >> >>This is the map compiled normally: >>http://144.132.16.252/zipster/[2]mdv0.jpg >> >>This is the map compiled the first time around with a max distance of 128: >>http://144.132.16.252/zipster/[4]mdv1.jpg >> >>And here is a picture of the original map being MaxDistVis'd after a >> >regular > >>compile (w/ 128 limit): >>http://144.132.16.252/zipster/[6]mdv2.jpg >> >>As you can see, that blasted leaf in the distance is screwing me over! I >>don't know how many of you know much about HLVIS procedures, but I hope >> >I've > >>given you enough information. I would go into more detail, but there's >> >just > >>too much if you don't have an idea of what's happening. >> >>-------------------------------------------------------------------------- >> >---- > >>MSN Photos is the easiest way to share and print your photos: Click >> >Here[7] > >>===References:=== >> 1. http://144.132.16.252/zipster/mdv0.jpg >> 2. http://144.132.16.252/zipster/ >> 3. http://144.132.16.252/zipster/mdv1.jpg >> 4. http://144.132.16.252/zipster/ >> 5. http://144.132.16.252/zipster/mdv2.jpg >> 6. http://144.132.16.252/zipster/ >> 7. http://g.msn.com/1HM505401/15 >> >>_______________________________________________ >>To unsubscribe, edit your list preferences, or view the list archives, >> >please visit: > >>http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > >_______________________________________________ >To unsubscribe, edit your list preferences, or view the list archives, please visit: >http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- I think...I think it's in my basement. Let me go upstairs and check. -M.C. Escher -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
![http://144.132.16.252/zipster/[2]mdv0.jpg](http://144.132.16.252/zipster/[2]mdv0.jpg){kind=link}
![http://144.132.16.252/zipster/[4]mdv1.jpg](http://144.132.16.252/zipster/[4]mdv1.jpg){kind=link}
![http://144.132.16.252/zipster/[6]mdv2.jpg](http://144.132.16.252/zipster/[6]mdv2.jpg){kind=link}
