Closed ioan-chera closed 3 weeks ago
I've talked to you about this. I've told you how it's fixable.
Also Rum and Raisin fixes this too, though I think in a different way than I had planned. Its methodology is probably better than mine so it's likely worth asking GooberMan.
I've talked to you about this. I've told you how it's fixable.
Can you please re-post?
I basically need to do what you did with the cross-portal sprite projection in terms of getting sprite width, but then use the same method to insert it into blockmap style per-sector sprite-touching lists. And then use those lists in rendering instead of the blockmap ones. Or use whatever approach GooberMan cooked up for R&R.
It's worth looking into what GooberMan did for R&R as I think that approach is multithreaded and likely faster. No idea if EE can use it without issues (given portal exist) but it's definitely worth researching.
Is the problem the fact that we're using touching_thinglist
to scan surrounding sectors? That list only checks what sectors the thing is physically touching with its radius. We'd need to make yet another list for the touching by sprite size, and that'll need to be updated on every graphical change, including scaling… not easy.
Seems fixed, by having a separate msecnode_t
bipartite graph, but using current sprite's cached radius instead of thing radius.
Right now I think it needs some improvements, but I'll experiment.
Happens with Eviternity 2 MAP14 with multithreaded rendering, even by having thorough rendering, very wide sprites can get cut off:
Good:
Bad:
Need to figure out if fixable.