Ok. I agree that performing Pixel Perfect Sprite Collisions is complex..... but so is driving a stick shift though the main street of town (when you first start to drive).
Just because it's complex doesn't mean it's insurmountable - most of us don't think twice about riding the clutch on a tricky hill start while waiting for the lights to change after you've done it a few times. It's all about looking at a problem - learning the processes and manipulating things to achieve the outcome you want.
Out of the most complex things can come the greatest elegance. And so writing a routine to perform a pixel comparison for two sprites would be better described by its elegance than it's complexity.
SO.
If the reliability of a single command to perform Pixel Perfect Sprite Collisions is too unpredictable..... How about providing us with some better tools to perform the task through our own ingenuity.
How about some lower level commands that could be used not only for that task but also for other things as well.
By this I'm thinking about a new command..... MAKE MEMBLOCK FROM SPRITE.
Making a Memblock from a Sprite is something you could program yourself in DarkBasic.
-Make a new Bitmap.
-Paste your Sprite to the Bitmap
-Make your Memblock from the Bitmap.
-Delete the Bitmap.
But handling this routing through DarkBasic (repeated thousands of times over) is very inefficient. However a DarkBasic command written in C++ (or whatever) and optimised for that specific task alone would not be too inefficient.
So what do you all think about that?
If we can't have a command that actually does Pixel Perfect Sprite Collisions, can we have some tools that will help us to do it ourselves?????
Like my dear old Dad always says....
-----I would rather be given a fishing rod than a fish!
