Pixel Movement

by Forum_account
Pixel Movement
A pixel movement library for isometric and top-down maps.
Before BYOND had native support for pixel movement, the Pixel Movement library had its own pixel movement implementation. When BYOND added native pixel movement, I made the library have two separate modes:

NATIVE mode - This made the library use BYOND's native pixel movement feature instead of its own. This improved performance but limited the features.

LIBRARY mode - This was the old implementation that was slower, but had support for additional features (3D movement, ramps, etc.)

The v4.1 update adds a new mode - HYBRID mode. This new mode uses some built-in procs (like obounds) to improve the performance of library mode. This means that hybrid mode's performance is on par with native mode and it supports features that native mode doesn't.

The reason why library mode was slow was because every time you moved, the library had to look for nearby obstacles that you might hit. It checked your move against all atoms in oview(1). Most of those atoms you were certainly not going to hit but it checked anyway. Hybrid mode doesn't check all atoms in oview(1), it uses obounds(src) to check your move against atoms in a much smaller area.

Hybrid mode's performance is on par with native mode for 2D movement (because native movement only supports 2D). To compare performance I ran the benchmarks\demo-1 demo five times in each mode until pixel_move was called 100,000 times. I dropped the best and worst runs for each mode, then averaged the remaining three trials. I also ran it in library mode to show how much better the other two modes are:
proc         Time (s) Calls     Avg
pixel_move   22.970   302277    76.0
set_flags    17.571   302277    58.1
set_pos       9.941   302277    32.9
TOTAL                          167.0

proc         Time (s) Calls     Avg
pixel_move   18.279   302073    60.5
set_flags    12.037   302073    39.8
set_pos      10.430   302073    34.9
TOTAL                          134.9

proc         Time (s) Calls     Avg
pixel_move   55.521   301180   184.3
set_flags    30.207   301180   100.3
set_pos      32.841   301180   109.0
TOTAL                          393.7
The "Time" column is the value shown in the profiler for "Real Time". The "Calls" column is the number of total calls to each proc. The "Avg" column is the average time per call in microseconds (millionths of a second).

These are the main pixel movement procs and both modes are significantly better than library mode. Hybrid mode appears to be the best, but the results are a little deceiving. The results fluctuated greatly.

Hybrid mode had four decent trials and one good one. Native mode had three good trials and two bad ones. I dropped the best and worst to help balance it out. Native mode's total value (the last row in the table) was around 130 for each trial, where hybrid mode was around 140. Native mode had a trial with a total of 247 which pulled its average up. I tried to keep the fluctuations out of the results but that's part of the performance.
Out of curiosity, does anyone use the documentation that comes with the library in _reference.dm?

The content in there tends to lag behind the updates, so I'd like to know if that's okay or if I should be more diligent. I'd also like to see if it'd be worth adding similar documentation to the sidescroller library.
I really am impressed with what you do. I could never code something like this, and you are doing it not just well, but professionally great. Thanks. :D
Gaining is right. Also does hybrid mode come with all the features such as jumping and so on?
Anime HQ wrote:
Gaining is right. Also does hybrid mode come with all the features such as jumping and so on?

Yep, hybrid mode supports ramps and jumping. The isometric-demo doesn't work with native mode but it works with hybrid mode.

If you're not going to use those extra features, you can disable them in _flags.dm by including this line:


Which will make hybrid mode run in 2D mode.
ok great. Thanks...