Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update projectM visualizer to latest 4.1 release #880

Open
kblaschke opened this issue Aug 2, 2024 · 2 comments
Open

Update projectM visualizer to latest 4.1 release #880

kblaschke opened this issue Aug 2, 2024 · 2 comments

Comments

@kblaschke
Copy link

The built-in projectM visualizer is quite old (2.2.x as fasr as I can see from the build files).

projectM should be updated to the latest stable release (4.1.1 or later), as with version 4.1, the visualizer has become almost fully compatible to Milkdrop 2.0 and gained some stability, performance and API improvements since the previous releases.

The new API is C-based to the currently used C wrapper is no longer necessary - the functions can directly be used from Pascal. Additionally, projectM now also properly builds as a DLL on Windows. All functionality is now available via the API, no more key handler or config struct with unused fonts.

The next release will also feature additional API calls like being able to render to a custom framebuffer instead of the native surface, plus other things. Since 4.0, the API remains forward-compatible within a major release, and minor releases will only add new API functions, but never change or remove existing ones, making updating projectM a non-effort, not even relinking is required.

@s09bQ5
Copy link
Collaborator

s09bQ5 commented Aug 2, 2024

I already tried to update projectM once. It didn't work. There where graphics issues IIRC.
USDX uses an OpenGL 1.x/2.x context. projectM beyond 2.x needs OpenGL >= 3. We don't create a separate OpenGL context for projectM but instead try to save and restore the context state before and after calling the renderFrame method.

@kblaschke
Copy link
Author

That makes sense, sure. Not sure how much work it would be to use an OpenGL 3.3 context for the whole application, but I guess that is more involved as converting the fixed-function pipeline to shaders etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants