Custom Query (105 matches)
Results (67 - 69 of 105)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #27 | wontfix | Raise Oni's particle class limit to 2048 | Iritscen | |
| Description |
Oni's maximum particle class limit is set to 2048, and a warning will appear if the game exceeds that. However, the actual limit is 1024, per Neo. Why? Because apparently there's a 32-bit variable used to link particles to classes ("particle reference"), and it has the following space allotted:
Version - 4 bits Particle Index - 10 bits Class Index - 10 bits Block Index - 7 bits Validity - 1 bit Of course, this means that the Class Index only provides 2^10^, or 1024, spaces. My guess is that when Oni's classes got close to 1024 during development (they're over 900), someone at BWest increased the particle max number from 1024 to 2048 and forgot about this link that still had a 10-bit index. Anyway, regardless of how it happened, Neo suggests stealing a bit from Version to add to Class. I guess that means moving Particle Index back one bit: Version - 3 bits Particle Index - 10 bits Class Index - 11 bits Block Index - 7 bits Validity - 1 bit I'm a bit out of my element here, but just conveying what Neo told me. He said that Version is essentially the unique ID of a particle within a certain class, assigned sequentially as new particles in that class are spawned. So I guess that taking a bit will mean reducing the number of particles that can be active in one class from 16 at a time to 8, but Neo doesn't think this will be a problem. I'm a bit less convinced myself, but perhaps there's another, better solution here. Perhaps there's no need to worry about bit stealing if we hook the function that reads the 32-bit particle reference and replace it with our own. Why not replace the 32 bits with separate variables of our own for each element? Then we can make them whatever size we want. However, I'm not aware of what math that might be done on this reference bitmask, so maybe this isn't a good idea. |
|||
| #148 | invalid | Reflective texture conversion fails | s10k | Samer |
| Description | Vago fails to correctly convert a texture with envmap through the Textures tab. | |||
| #52 | fixed | Refresh list fully | Alloc | Samer |
| Description |
If you have Local selected in view and All filter .. and delete a local package and use the rescan .. the package is still listed under local .. the list should be refreshed and be removed from the list ..
also if you have show only Downloaded selected and delete a package and press rescan .. the state does change but it's still showing under downloaded until you change view to All for example and then back to downloaded ... what i think is best that the list should get blank and regenerate as if you're reopening the installer. |
|||
Note: See TracQuery
for help on using queries.
