Imperium Scenario System
Hello, As some of you may recall, I released my first real game/project written in D back in May (https://forum.dlang.org/thread/zuftzvxusvgwqmsnt...@forum.dlang.org), which at the time was known as "Untitled Shooter Game". I'm happy to announce that the project now has an official name, the Imperium Scenario System, and will focus on providing a variety of single-player game-modes or "scenarios". In addition to the name change, a substantial number of features and improvements have been added, the most notable being a fully-functional map editor (though it currently lacks documentation). For those interested, you can visit the project page and follow the devlog here: https://kenny-shields.itch.io/imperium-scenario-system
Re: gamut v0.0.7 ask for what you want
On Thursday, 11 August 2022 at 11:06:43 UTC, wjoe wrote:
I imagined you could allocate internal buffers for
encoding/decoding on the stack but your reply suggests
otherwise.
Yes.
For example, the QOI-10b codec needs an pallete of 256 16-bit
RGBA, that's 2 kb. Is that portable? There is probably a size at
which it isn't that portable anymore.
It also needs two scanlines of 16-bit RGBA, that is O(n) with the
image width, so can't go to the stack.
Now this encoder state is allocated at the end of the encoded
pixels, since it would be too large for a portable stack.
(Regular QOI can be all on the stack though.)
I mean, the primary thing you want is performance, complete
control over the memory is just a proxy for that.
However shouldn't a single function call back be enough?
Something like
``` D
void[] need_more_ram(size_t amount, void[] old_chunk, void*
user)
{
MyAllocator* a = cast(MyAllocator*)user;
void[] result = a.alloc(amount); // MyAllocator would return
an empty slice if amount == 0
if (amount && chunk.length) result[0..chunk.length] = chunk;
// it is assumed that on re-allocation amount > chunk.length
a.free(chunk.ptr);
return result;
}
```
Indeed, that would quite fitting as an API.
Re: gamut v0.0.7 ask for what you want
On Tuesday, 9 August 2022 at 22:02:37 UTC, Guillaume Piolat wrote:
On Monday, 8 August 2022 at 16:07:54 UTC, wjoe wrote:
your lib would not just be @nogc but @no_allocation.
All image decoders in gamut need to malloc more than just for
pixel data.
Even STB allocates for format conversion, zlib buffers, 16-bit
<-> 8-bit, etc. it's not just pixel data.
Single allocation pessimizes the size a lot because since you
haven't encoded yet, you need to prepare a buffer for a large
worst-case.
I imagined you could allocate internal buffers for
encoding/decoding on the stack but your reply suggests otherwise.
However shouldn't a single function call back be enough?
Something like
``` D
void[] need_more_ram(size_t amount, void[] old_chunk, void* user)
{
MyAllocator* a = cast(MyAllocator*)user;
void[] result = a.alloc(amount); // MyAllocator would return an
empty slice if amount == 0
if (amount && chunk.length) result[0..chunk.length] = chunk; //
it is assumed that on re-allocation amount > chunk.length
a.free(chunk.ptr);
return result;
}
```
