-
Notifications
You must be signed in to change notification settings - Fork 35
use buffers to process graphics
This specification was automatically generated from a feature request imported into Ares's LaunchPad bugtracker. If you are interested in fleshing out this feature, please update this page.
Use buffers to process graphics. This would decrease slowdowns and lag.
The idea is good, but it involve lots of work.
If decision is made to implant this, I suggest the work to be spitted to all coders.
Just to enlighten everyone who wasn't on IRC when this was discussed: so basically we lag to hell thanks to sprites mhm technically it doesn't lag because it's sprites it lags because those sprites are stored in a very compact way and have to be decompressed and processed before rendering and they don't bother to cache the result of that processing so every frame the engine goes to reindex each shp with its palette and recompute the voxels somehow which I don't quite understand (or want to) I may do not know what I am speaking about, but how about creating a buffert? that requires memory sure we can try that nowadays personally I haven't tried that because there are plenty of other things to do that are less messy to do Of course. how much memery are we talking about? and how big improvment is a buffert? I think you're looking for a "buffer", not "buffet" though that second option is more delicious as for memory usage, needs some math if we want to decompress each shp before use, that's probably 50% more space than compressed shps shps that only use one palette (non-remappables) would need just one buffer, which would be twice the size of the shp itself (16 bit color) remappables, er, would need a separate buffer for each remap
- This needs to be filled by a supporter/drafter of this specification.
- This needs to be filled by a supporter/drafter of this specification.
- Original request by YR M0ddEr/yr-m0dder
- Imported request at LaunchPad
- Blueprint meta-data at LaunchPad