Implement Milkdrop user sprites and add API methods to control them #862
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added user sprites as supported by Milkdrop, with the exception that projectM won't support color keying (which is broken in original Milkdrop anyway as the color isn't properly parsed and always set to black). All other sprite features are supported:
Reason for this deviation is that OpenGL (or any other 3D API except for older DX versions) do not support a color key to be set for textures. In projectM, images with alpha channel support such as PNG, GIF, TIFF or DDS can be used to achieve transparency in blend mode 4. All other diplay modes work fine.
Another change is that projectM will properly keep the sprite's correct aspect ratio, which was also bugged in Milkdrop (it always scales the image as if a 4:3 render aspect is used).
Since sprites are solely user-supplied, these "fixes" should not create any issues.
By default, projectM will allow up to 16 concurrent sprites to be rendered, but this limit can be changed via the API. Setting it to 0 will disable sprites. The implementation uses a factory pattern, using a type nyme to identify the sprite type. This will allow us to add more sprite implementations without changing the API.
One open question: should be also add a method that returns a list of supported sprite types? This would make it easier for an application to detect supported sprite types.
This PR closes #734