Utodev
commented
4 years ago Although it would be a good feature, it may be extremely complicated to implement. Basically there is a different RAM free space per each DAAD target, and some of those targets (i.e. all the Spectrum ones) have a variable RAM free space , cause the space depends also in the size of the graphics database. There is no way to know how big the graphics database is when creating the DDB, as the DAAD tools to created DDB and graphics file are completely separated.
Also, DRB and DRC do not compress beforehand, but do it in the fly, so if the first reason to decline this change was not enough, that makes the task almost impossible, at least in a reasonable time, that is what I ever require to start any improvement.
So sorry, but your request, although interesting, it's extremely complicated.
I'd like to request that DRC supports auto-message allocation based on a default (or possibly configurable) algorithm in order to maximise use of available RAM (when used in conjunction with Maluva).
At the moment, authors are responsible for if a message is MESSAGE, XMESSAGE, or SYSMESS.
Adventuron is exporting games from its own format to the DRC format. Currently it only uses XMESSAGE when running out of MESSAGE or SYSMESS slots. Adventuron counts the slots that are available, and even though it doesn't directly allocate message numbers, internally it allocates to a slot number just so it can figure out when it runs out of MESSAGE or SYSMESSAGE.
The problem is that DAAD may run out of RAM before Adventuron runs out of messages. It's impossible for the Adventuron to know exactly what the threshold is for this exactly. If it knew the threshold it could start using XMESSAGE earlier.
When Adventuron does use XMESSAGE messages, it makes the larger messages XMESSAGEs, so as to hold the smallest messages in RAM (where space is tight).
I'd like to propose the creation of a new message called DMESSAGE.
DMESSAGES are essentially messages that could be MESSAGE, SYSMESS or XMESSAGE or LOCATION text. There would be approximately 900 of them to use (depending on how many explicit sysmessages and location texts are provided - something that a code generator such as Adventuron's could keep track of).
DMESSAGEs must end in a line break. When mapped to MESSAGE, then the line break is removed (by the compiler), when mapped to other message types, then it is retained.
Currently when the compiler goes above the 64K limit, it's a compiler error.
On platforms that support Maluva and have disk based storage, the compiler should prioritise MESSAGE, SYSMESS, and LOCATION based messages for the first pass of compilation.
If the 64K RAM limit is breached, then the compiler, should try a second pass where it allocates the 20 longest DMESSAGEs to XMESSAGES. If that breaks the 64K limit, now compile again, allocating the 40 longest DMESSAGEs to XMESSAGEs, and so on, until all 255 (or 256?) XMESSAGE slots are allocated. Only if the 256 longest messages break the 64K limit do you throw a compiler exception.
DMESSAGEs are much easier for authors to use as they don't have to think about if they will store text on disk or not, the compiler decides. It really helps the Adventuron exporter as it's likely that many games will be very large, but the actual threshold point at when to start using XMESSAGES is impossible to know. This decision is best placed in the (DRC) compiler.
Although it has not happened yet, I anticipate that many games developed on Adventuron will not fit in the (approx) 31K remaining in DAAD. With smart XMESSAGE allocation (that can only really be done in the compiler), I anticipate that even larger games will fit..