This PR is to add 2-bit, 4-bit and 8-bit colour indexing ability to the indexed layer. It's fairly straightforward to use, and not really different to the existing functionality other than the constructors have an option to choose the bit depth for the colour index and that the index parameter in the functions chooses the colour index (as opposed to just setting/resetting a bit). It is backward compatible with existing code that uses the indexed layer, so it should not cause any problems there. The memory footprint should pretty much be the same as before (increasing with the number of bits for the colour index, of course). I've defined a macro SMARTMATRIX_ALLOCATE_INDEXED_LAYER_EXTENDED that will take an additional parameter to set the colour index bit depth, keeping the existing macro for backwards compatibility. The colour index of 0 will always be transparent, and a colour cannot be allocated to it, regardless of the number of bits used for the colour index.
In terms of speed, I've tried to optimise it somewhat and there may be a way to improve on that, but it works pretty well. However, for my application, I needed the screen updates to be faster, particularly as some of the applications don't need to use all the defined layers at the same time. Therefore, I added two functions to SM_Layer: enable and isEnabled. enable will enable/disable a layer from refreshing onto the screen when not needed by the user, and isEnabled gives the status of the layer. This can bring a nice speed increase in processing, should it be required.
Finally, I realised that I made changes to the code with the ability to disable the version messages coming out from the hardware header files. Defining SM_INTERNAL disables these messages.
Hi,
This PR is to add 2-bit, 4-bit and 8-bit colour indexing ability to the indexed layer. It's fairly straightforward to use, and not really different to the existing functionality other than the constructors have an option to choose the bit depth for the colour index and that the index parameter in the functions chooses the colour index (as opposed to just setting/resetting a bit). It is backward compatible with existing code that uses the indexed layer, so it should not cause any problems there. The memory footprint should pretty much be the same as before (increasing with the number of bits for the colour index, of course). I've defined a macro
SMARTMATRIX_ALLOCATE_INDEXED_LAYER_EXTENDEDthat will take an additional parameter to set the colour index bit depth, keeping the existing macro for backwards compatibility. The colour index of 0 will always be transparent, and a colour cannot be allocated to it, regardless of the number of bits used for the colour index.In terms of speed, I've tried to optimise it somewhat and there may be a way to improve on that, but it works pretty well. However, for my application, I needed the screen updates to be faster, particularly as some of the applications don't need to use all the defined layers at the same time. Therefore, I added two functions to SM_Layer:
enableandisEnabled.enablewill enable/disable a layer from refreshing onto the screen when not needed by the user, andisEnabledgives the status of the layer. This can bring a nice speed increase in processing, should it be required.Finally, I realised that I made changes to the code with the ability to disable the version messages coming out from the hardware header files. Defining
SM_INTERNALdisables these messages.I hope you find that useful!