A BASIC-style syntax should be easy to implement and also be easy to write for the user, but I'm not sure how to implement one of the ZAD system concepts in this style of programming.Ralf wrote: ↑Thu Feb 15, 2018 8:41 pmThe easier it will be, the more users you will have. I understand that "easy for user"="harder for you" so you may want to find your compromise.I am not sure whether to create a C-style programming language, or simply let the end-user program directly in the bytecode language.
Personally I would go after Basic syntax, not C. Most people in Zx Spectrum world have experience with Basic but not necessarily C and may be afraid of all these brackets, not to mentions pointers
You can do it without compression if it's too much trouble. You can go down to 5 bits per letters: 32 combinations for 26 English letters. You can also use prefixes for some rare symbols (5 bits per prefix and next 5 bits for rare character which give you another 32 symbols). You can also have some logic like "after dot symbol there is always a capital letter" as start of new sentence. I have an unfinished game using such ideas so these are actually tricks that worked for me.To start, I've been looking at text compression lately
But don't foget to do some global variables. Actions in one location should be able to influence things in another location.The rooms of the game are split into 'modules',
Good luck with your project! Don' forget to post here
To reduce the amount of time spent in the bytecode execution loop, there is a 'centre point'. This can be set anywhere in the code. The centre point is where bytecode execution begins from on each loop. This means that for an animation sequence, we can set the centre point to start executing the animation loop immediately from the beginning of a new execution loop, and when we're done, we can set the centre point back to the main logic loop for the entire room. I'm not entirely sure how I could implement that cleanly in a BASIC-style syntax. I suppose it could automatically centre at the start of each room module and then loops with their own centre points could be indented to make it clearer that they are separate.
In regards to the compression, I understand the concept of Huffman compression, but it's just trying to implement it. I'll keep picking away at it whilst I implement the other things.
Finally, in response to your note about global variables, the way that variables are allocated within the system technically makes them all global, but the way that the compiler will allocate them abstracts this from the end-user. Local variables are allocated upwards from $00 and global variables are allocated downwards from $5F. There are variables above $60 in the variable page, but these are given a dedicated purpose (object positions and their frame pointers, region information, system flags, etc.).