Mixing variable types in a numerical calculation

[patters]

Thanks, that mapping using DIM is a very neat trick, definitely an example that would be useful to have on the wiki.
I actually implemented the code I showed above and it didn't really speed things up over and above the addition of each ATTR to a total value.

It true, I am very much veering towards premature optimisation. I think it's because I have already written this game once, and I'm attempting to port it without completely re-designing it. I have some idea of which approaches are optimal, but since I have very little knowledge of ASM and the bare fundamentals of computer science it's difficult. I am a total amateur. I keep on discovering new features of ZX BASIC which lead me to greater improvements. And I'm learning a lot here so it's very interesting.

The attribute scanning seems at face value to be an optimal collision detection approach because it's simple. Wouldn't it be four expensive comparison operations to scan whether I've entered the hit castle hit-box with each PLOT? To my untrained eye, a whole series of greater than or less than comparisons is surely more costly than these POKEs and PEEKs.

I'll send you over my current working prototype. Your compiler, and the fSIN fCOS functions have allowed more than an order of magnitude performance improvement over Sinclair BASIC. I'm spending this on PLOTting the ballistic trajectory pixel-by-pixel rather than via achingly slow DRAW commands. It feels more like a real game now. I can also create a far better terrain generation algorithm than before. Other than that I'm going to be making the same game fundamentally. I'm also keen to implement a computer player too, though that seems quite a big task.

[boriel]

Thanks, that mapping using DIM is a very neat trick, definitely an example that would be useful to have on the wiki.
I actually implemented the code I showed above and it didn't really speed things up over and above the addition of each ATTR to a total value.

It true, I am very much veering towards premature optimisation. I think it's because I have already written this game once, and I'm attempting to port it without completely re-designing it. I have some idea of which approaches are optimal, but since I have very little knowledge of ASM and the bare fundamentals of computer science it's difficult. I am a total amateur. I keep on discovering new features of ZX BASIC which lead me to greater improvements. And I'm learning a lot here so it's very interesting.

The attribute scanning seems at face value to be an optimal collision detection approach because it's simple. Wouldn't it be four expensive comparison operations to scan whether I've entered the hit castle hit-box with each PLOT? To my untrained eye, a whole series of greater than or less than comparisons is surely more costly than these POKEs and PEEKs.

I'll send you over my current working prototype. Your compiler, and the fSIN fCOS functions have allowed more than an order of magnitude performance improvement over Sinclair BASIC. I'm spending this on PLOTting the ballistic trajectory pixel-by-pixel rather than via achingly slow DRAW commands. It feels more like a real game now. I can also create a far better terrain generation algorithm than before. Other than that I'm going to be making the same game fundamentally. I'm also keen to implement a computer player too, though that seems quite a big task.

You're doing what everybody does when coming from Sinclair BASIC to the compiler and it's absolutely normal (I don't pretend to be harsh or anything, sorry if it seems to be so).

Just wanted to point that even not doing the most Byte-optimized solution but a normal BASIC-like solution will be more familiar to you and, considering the notable speed up you will get over Sinclair BASIC you will end up with a very playable game. ;-)
For example, what about using an array of bytes and compare them every time? Surely this is slow in interpreted BASIC, but not that slow in compiled one.

Send me your solution privately if you want some suggestions, but I think you're learning very fast!
I'll be adding soon the automatic-coertion feature (since many people is falling into this pitfall vary often it means I have to look into it, and propose the optimization later by allowing disabling it for example)

People like to use the ASM feature a lot. The idea behind the compiler is not having to use it (otherwise, why translating BASIC code into ASM?)
So I like when people manages to do all the program in BASIC! :-)

[patters]

Don't worry - no offence taken  I guess it's because my game programming experience is limited to BASIC, so I never really investigated typical solutions for collision detection once the horrific performance constraints are removed.

My understanding is that I could define the whole playfield as an array of characters full of 0s, with the castle positions as 1s. Then at each trajectory PLOT I would have to convert the PLOT coords to PRINT coords and looks up against the array. I think that PLOT->PRINT coord conversion is already fairly expensive, and I'm fairly convinced that the whole approach would perform worse that simply reading two UINTEGERS and comparing with a ULONG as I am now doing.

As a clarification, I'm only interested in optimal performance for the actual ballistic trajectory loop (with collision detection) - which is fundamentally important to how smooth this game runs. I'm not chasing byte-optimal methods everywhere else, but I do appreciate being steered towards to more 'correct' way to achieve certain tasks. There is no greater authority than the man who wrote the compiler 

[boriel]

Don't worry - no offence taken  I guess it's because my game programming experience is limited to BASIC, so I never really investigated typical solutions for collision detection once the horrific performance constraints are removed.

My understanding is that I could define the whole playfield as an array of characters full of 0s, with the castle positions as 1s. Then at each trajectory PLOT I would have to convert the PLOT coords to PRINT coords and looks up against the array. I think that PLOT->PRINT coord conversion is already fairly expensive, and I'm fairly convinced that the whole approach would perform worse that simply reading two UINTEGERS and comparing with a ULONG as I am now doing.

As a clarification, I'm only interested in optimal performance for the actual ballistic trajectory loop (with collision detection) - which is fundamentally important to how smooth this game runs. I'm not chasing byte-optimal methods everywhere else, but I do appreciate being steered towards to more 'correct' way to achieve certain tasks. There is no greater authority than the man who wrote the compiler 

Haha, thanks for the compliment. But people (like you in this case) have helped a lot finding bugs, proposing features, and sometimes even ASM code snippets, advice, code, etc...
Please, post any update on this. I'm very interested in seeing the results.