I've been thinking of a way to increase MOB caps on the 360 from a programming standpoint to allow for more MOB's in the game without causing additional strain on processing resources.
I believe that as it stands right now, MOB action is updated each game tick, which is 20 ticks per second or a duration of about 1/20 of a second per game tick.
If MOBs were queued into the shortest available of 4 MOB management queues (numbered 0-3), then each tick could be similarly sequentially numbered 0-3 and only update new MOB actions for that queue designation. This would mean that MOB action only updates every 1/5 of a second instead of every 1/20 of a second, but players wouldn't notice very much difference in MOB behavior at those rates.
It would allow the game to manage many more MOB's (passive/neutral/aquatic/ambient/aggressive/villager) without adding much to lag to the game.
(Alternatively, the queues and ticks could be setup to execute for 0-7 which would update on every 2/5 of a second instead).
This memory management philosophy could extend to block updates as well and it might even help to reduce or eliminate some of the redstone glitches we are seeing on the XBox 360.
To expand on the block update management queues, blocks could be organized in N - queues by their (X, Y, Z) coordinates using the following queue placement formula:
(X + Y + Z) % N (where % represents Modulo division, aka. 'getting the remainder in integer division').
If N = 2, then updates can be checked on virtually every game tick.
For N>2, this could cause some variance of updates checking on anywhere between every 1 and (N-1) ticks (ie, could be faster going east than west, or faster going south than north), but averaging N/2 in update sequencing.
So for better redstone reliability, we could limit the update variability to crossing chunk space... Assuming each chunk is sequentially numbered with an X-chunk and a Z-chunk coordinate (and possibly even a Y-chunk coordinate, although I believe the lc value is actually a Section division within a chunk for Anvil game file format).
We can now support 4 queues for block updates using N=4 and a block coordinate multiplier of 2 in the following formula:
[ {2 * (X + Y + Z) }+ X-chunk and a Z-chunk ] % 4
In this scheme, blocks update every other game tick (in line with the redstone tick updates) within the chunk-space, and the only variance is when crossing into an adjacent chunk (depending on direction) could be offset by either 1 or 3 game ticks... which shouldn't be too much of an inconvenience in most cases while freeing up system resources for processing other events within the game.
........................Okay i've walked into a calculus thread.. you two have fun
LOLOL.... Whachu talkin' 'bout!!! That's like 7th-8th grade pre-algebra there... I haven't even pulled out the calculus yet... and who is the other of us 'two' that should be having fun here?
Well, at least is explains while I would never make it as a programmer... too much math. LOL I'll just have to take your word for it. Just speculating... would this have an impact on the mobs phasing through block issue (either positively or negatively)?
Well, at least is explains while I would never make it as a programmer... too much math. LOL I'll just have to take your word for it. Just speculating... would this have an impact on the mobs phasing through block issue (either positively or negatively)?
Difficult to say, by handling different block updates on different game ticks, in theory it should allow one update to more likely impact the next update instead of getting lost in mass of trying to do it all at once and keep a relatively normal FPS rate, but on the flip side, they are not all processed at the same time, so some care needs to be taken to make sure that the updates run smoothly in design. So...if done right, yes, it should help prevent phasing, but if not done right, it could cause more of the same or possibly even different issues.
Bugs are to be expected if something is going to be designed or redesigned, especially if done on a large scale.
Greg, you seriously need to contact 4J and give them this recommendation. Maybe they've thought of it or maybe it's new.... this is definitely something you should propose. 100% supported.
WHAT WOULD YOU LIKE TO SEE THE VILLAGER CAP AT?
To expand on the block update management queues, blocks could be organized in N - queues by their (X, Y, Z) coordinates using the following queue placement formula:
(X + Y + Z) % N (where % represents Modulo division, aka. 'getting the remainder in integer division').
If N = 2, then updates can be checked on virtually every game tick.
For N>2, this could cause some variance of updates checking on anywhere between every 1 and (N-1) ticks (ie, could be faster going east than west, or faster going south than north), but averaging N/2 in update sequencing.
So for better redstone reliability, we could limit the update variability to crossing chunk space... Assuming each chunk is sequentially numbered with an X-chunk and a Z-chunk coordinate (and possibly even a Y-chunk coordinate, although I believe the lc value is actually a Section division within a chunk for Anvil game file format).
We can now support 4 queues for block updates using N=4 and a block coordinate multiplier of 2 in the following formula:
[ {2 * (X + Y + Z) }+ X-chunk and a Z-chunk ] % 4
In this scheme, blocks update every other game tick (in line with the redstone tick updates) within the chunk-space, and the only variance is when crossing into an adjacent chunk (depending on direction) could be offset by either 1 or 3 game ticks... which shouldn't be too much of an inconvenience in most cases while freeing up system resources for processing other events within the game.
LOLOL.... Whachu talkin' 'bout!!! That's like 7th-8th grade pre-algebra there... I haven't even pulled out the calculus yet... and who is the other of us 'two' that should be having fun here?
Difficult to say, by handling different block updates on different game ticks, in theory it should allow one update to more likely impact the next update instead of getting lost in mass of trying to do it all at once and keep a relatively normal FPS rate, but on the flip side, they are not all processed at the same time, so some care needs to be taken to make sure that the updates run smoothly in design. So...if done right, yes, it should help prevent phasing, but if not done right, it could cause more of the same or possibly even different issues.
Bugs are to be expected if something is going to be designed or redesigned, especially if done on a large scale.