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
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