note: dirty page bitblts to a screen are increasinly expensive for larger buffers
bitblts to vram are "free" (no budget, no energy)
note that any direct component call has a minimum .001 budget cost
We've discussed a large variety of options for the gpu
I've reviewed our options and suggestions. Ultimately - users want faster graphics. Most of the ideas are relating to what api is meaningful to the user. The core issue we have in making graphics faster is an increase load on the server.
For example
Tier 3 GPU and Tier 3 Screen has a max resolution of 160x50
If you set the viewport (via gpu.setViewport) to 160x25 the bottom half of the buffer will no longer be shown. All gpu.set, gpu.copy, and gpu.fill calls into that space have no cost
Overlaps are calculated for partial cost. Half in and half out will have half the power cost.
closes#779
the openos io buffer in utf8 mode can splice inside a utf8 sequence
this code prevents that by reading the next chunk to complete the sequence
in the case the stream actually has bad utf8 sequence, the io buffer decides to return
more data than it was asked, rather than corrupt the stream
closes#1207
this delays calling ae.getItemStack until user code calls it for individual
items. this is vey helpful for servers with huge numbers of craftables
otherwise, all serializing calls happen on the main thread
closes#2964
drops. The core problem here actually is that OC agents try to
pull items directly out of killed/destroyed blocks via capturedDrops,
and the robots also pick up items from collision.
The collision code was written to always destroy the drops.
The code that tries to pull items out of capturedDrops spawns items in
world when there is no room in the robot.
Mob drops cause collision pickup AND run the capturedDrops code. When
collision doesn't take anything, and kills the drops, the items are lost.
The best fix would be to stop taking items directly from capturedDrops,
but this code has been here for some time, and we'll leave it for now.
The next best fix is to not always destroy drops on collision, but let
mc code handle collision cleanup as it was designed. Then, when taking
capturedDrops directly, first check if there is an inventory.
This solution leaves one last loop hole, collision doesn't find a place
in inventory and thus has valid world drops.
We can't ignore collision for attacks because the mobs are putting items
in the world. But instead, we need to stop capturedDrops action from
spawning in the world.
closes#3172