Descriptive Problem Summary:
Pixel movement seems to bog down or slow down significantly when a dense number objects are on screen.
The mob shown in question is given a step_size of 4.
When does the problem NOT occur?
Large empty spaces.
Stuttering:
https://i.gyazo.com/2c088236c5605110b0d42700d1f10c86.mp4
Not-stuttering:
https://i.gyazo.com/86cf618503e310232e5fcbd74f749278.mp4
ID:2136565
 Aug 21 2016, 11:29 pm
|
|||||||||||||
| |||||||||||||
|
Aug 21 2016, 11:36 pm
|
|
Lummox JR
   |
Lummox JR resolved issue (Not a bug)
|
The problem is actually the way the internal Move() operates when a lot of objects are on the same tile. This has been identified as an enhancement target.
| |
What I've found is that there is either no, or maybe one object on the tiles where it stutters.
It seems to do it instead when it encounters a lot of tiles to draw on the screen (large forests, dense canyon areas) but not in empty spaces, like open rooms. | |
Lummox JR changed status to 'Open'
| |
Hrm. So you're describing more of a drawing code slowdown than a server one? I'll reopen this for now, but I need some kind of test project to look into. Also we need to narrow this down to being either a server issue (Dream Daemon) or client (Dream Seeker), since it surely is not a DM Language issue.
| |
I've paged you a link to the project used in the description. I tried to reproduce the problem in test projects, but I can't pinpoint exactly what might be causing it.
| |
After fiddling around some more, I think it has something to do with using pixel_z offsets on turfs in iso maps. When I disabled them, pixel movement was buttery smooth.
| |
Hmm, interesting. The pixel_z offset would tend to mark the turf as "interesting" and therefore treat it slightly differently during display. If you had several of these it would explain a lot.
| |
That makes sense, we use pixel_z to generate our hills and uneven terrain
| |