2010-01-29, 15:47
While writing my visualisation I have noticed some limitations with the xbmc viz api that could maybe be solved in a better way.
1) The VIS_ACTION_UPDATE_ALBUMART action when the album art changes, gives me a char* to the path of the .tbn file xbmc uses. For one, I have no clue what a .tbn file is supposed to be, as far as I know it is a container for several possible formats. If I want to render it to the screen, I need to find out what format it is, and write an opengl method to render that as a texture. Now for me, the solution was to just use xbmc functions, in my case a CGLTexture (more exactly, a derived class from that, since I needed to modify the LoadToGpu method), essentially tying my viz completely to xbmc - if the classes change, my viz breaks.
Solution: maybe pass an uncompressed bitmap to the viz, or a pointer to a texture I can upload when needed.
2) I would like to render fonts in my viz - to display info about the track. Again I am trying to use xbmc functions, because I can use fonts the xbmc FontManager knows of. (which isn't too easy, since my viz changes the projection with glOrtho to make it easier for me to center and place stuff, and this messes with the TextLayout:: DrawText method, causing it to render stuff upside down in my case. There is like a fix here, that I don't comprehend yet though).
Solution: Maybe give me the possibility to render stuff ontop of my viz with the internal xbmc methods - although I am not sure how that can be acomplished in an easy way, respecting my glOrtho stuff. But at least it would untie my code again from directly using xbmc classes that weren't designed to cope with my glOrtho changes.
1) The VIS_ACTION_UPDATE_ALBUMART action when the album art changes, gives me a char* to the path of the .tbn file xbmc uses. For one, I have no clue what a .tbn file is supposed to be, as far as I know it is a container for several possible formats. If I want to render it to the screen, I need to find out what format it is, and write an opengl method to render that as a texture. Now for me, the solution was to just use xbmc functions, in my case a CGLTexture (more exactly, a derived class from that, since I needed to modify the LoadToGpu method), essentially tying my viz completely to xbmc - if the classes change, my viz breaks.
Solution: maybe pass an uncompressed bitmap to the viz, or a pointer to a texture I can upload when needed.
2) I would like to render fonts in my viz - to display info about the track. Again I am trying to use xbmc functions, because I can use fonts the xbmc FontManager knows of. (which isn't too easy, since my viz changes the projection with glOrtho to make it easier for me to center and place stuff, and this messes with the TextLayout:: DrawText method, causing it to render stuff upside down in my case. There is like a fix here, that I don't comprehend yet though).
Solution: Maybe give me the possibility to render stuff ontop of my viz with the internal xbmc methods - although I am not sure how that can be acomplished in an easy way, respecting my glOrtho stuff. But at least it would untie my code again from directly using xbmc classes that weren't designed to cope with my glOrtho changes.
