Bug Tracker – Bug 792

Bullet puffs do not need 32 bit fixed-point precision

Last modified: 2019-06-17 00:10:38 CDT
Bug 792 - Bullet puffs do not need 32 bit fixed-point precision
Summary: Bullet puffs do not need 32 bit fixed-point precision
Status: NEW
Alias: None
Product: Odamex
Classification: Unclassified
Component: Server & Client (show other bugs)
Version: (old) 0.6-dev
Hardware: All All
: P1 trivial
Assignee: Odamex Bug Reporter
URL:
Depends on:
Blocks:
 
Reported: 2012-02-25 19:03 CST by Dr. Sean
Modified: 2019-06-17 00:10 CDT (History)
1 user (show)

See Also:

Attachments

Patch (2.26 KB, patch)
2012-02-25 19:03 CST, Dr. Sean
Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dr. Sean 2012-02-25 19:03:59 CST
Created attachment 342 [details]
Patch

Accuracy for bullet and blood puffs is not particularly important at a resolution greater than 1 map unit.  A great bandwidth savings can be had by sending bullet puff positions as 16 bit instead of 32 bit fixed-point coordinates.  The angle the puff is facing is also of no importance and can be disregarded.  For a super-shotgun blast, the position and angle of bullet puffs current use 16*20 = 320 bytes.  By not sending the angle and sending the position as 16 bits instead, a super-shotgun blast would use 6*20 = 120 bytes.

I have attached a patch that implements this.  I feel it can be implemented better in the future as part of a more robust network serialization scheme that determines what level of positional accuracy an actor needs based on certain criteria.
Comment 1 Ant P. 2019-06-17 00:10:38 CDT
I like the idea. It'd be straightforward to improve this even more by sending a "diff" object to the client when the change between the current and previous MObj is small enough.

In the best case a SSG is going to put down 20 MT_PUFF objects all clustered together (on a single wall), which could be encoded as an initial set of these 16 bit coords, followed by signed-8-bit offsets for the rest, for a total of 63 bytes. In the worst case (which requires some truly awful map design) it's still only 120 bytes.