On 10/19/2022 at 6:52 AM, Roy Eltham said:
Hi, I'm new around here, but I want to dive in to programming for the X16 using the emulator.
I program in C++ for my job, and am familiar with a lot of modern and old languages and some microcontroller stuff like Propeller 1 & 2, and their languages.
I've scanned through this thread, and I think I want to try using Prog8 for my retro game for the X16. What I am posting for is to ask if there are any gotchas or things I should be aware of like maybe X16 features that are not fully support (if at all), or just common things newcomers to the language stumble on?
It seems like you've done a pretty nice bit of work on the X16 target/support, so I expect I will like using Prog8 for my game. Thanks for doing this, and for any reply to my question above.
Welcome to forum and to the Prog8 thread.
The main issue with the low level code is that it's a lot easier to shoot oneself in the foot. I.e. nothing preventing you from setting a random memory location and breaking everything. Expect to spend time looking for weird bugs that are hard to pin down. Prog8 is low level so it's more like C than C++. On the other hand, it's a compact and neat language that is easy to learn. Especially if you know anything about the 6502 processor.
It's easy to add in some function implemented in assembly if you need to speed up some critical parts which may be needed if you are coding a game. I you want to look at longer code example feel free to check out the source of my game Petaxian, which is written in Prog8 plus a bit of assembly
: https://github.com/cyborgar/Petaxian. Feel free to steal.. I mean borrow from there. There are certainly parts here that was "inspired" by the example programs from desertfish in the first place.
Most gotchas are probably just related to the the CX16 platform and not so much about Prog8 though I have a couple things I will mention
First Prog8 currently doesn't support short-circuit evaluation, i.e. for something like
if x >1 and x < 128 { ...
all parts of the express is evaluated even if the first fails. Using something like
if x > 1 {
if x < 128 {
...
may yield faster code. And if you have side effects in the evaluations you could even get bugs if you are to careful.
Sometimes the compiler also struggle with more complex expression (though complex has more to do with the compiler evaluation than the complexity of the statment). E.g. right now something like this
test_fun( arr_one[i + 1], arr_two[i + 1] )
will give a compiler error ("it's not possible to use more than one complex array indexing expression in a single statement; break it up via a temporary variable for instance").
In that case I extracted out the array index calculation to
ubyte tmp = i+1
test_fun( arr_one[tmp], arr_two[tmp] )
Often if you run into trouble with the compiler, breaking operation down into simpler steps tend to solve issues.
And also, reporting issues here will usually get you help quickly from the Prog8 developer himself
?