Kodi Community Forum
Release 2D Spectrum, visualization - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: Release 2D Spectrum, visualization (/showthread.php?tid=204991)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13

RE: 2D Spectrum, visualization - stourwalk - 2015-05-05

(2015-05-05, 22:49)ironic_monkey Wrote: https://github.com/xbmc/kodi-platform <- that USED to have that file and still does in my fork.
upstream split it in two libraries, https://github.com/Pulse-Eight/platform and https://github.com/xbmc/kodi-platform

Thank you for the simple explanation - I understand now Smile

RE: 2D Spectrum, visualization - un1versal - 2015-05-06

@notspiff
yep that what I thought after having a better look.
According to comments in that PR, it should be merged soon enough. Bee looking forward to test this addon then.

@stourwalk yep never mind the typo on my forst post generated confusion, but yes its not the reason why it fails since my changes were correct in source, not that it matters as whe know what needs to happen now.

RE: 2D Spectrum, visualization - afedchin - 2015-05-06

(2015-05-03, 20:47)topfs2 Wrote:
(2015-05-03, 13:14)rwilleme Wrote: Is there any way of testing this on Windows machine with Helix?

This will most likely be OpenGL only, so Windows will miss out. The core visualizer should be simple to port to DirectX however all the shaders (which I take from ShaderToy) are glsl, and they are _not_ easy to port Smile
Not so hard as you think Smile The main problem is access to pixel coords which is not possible at feature level 9_x (for directx 11) but as I see most of the shaders uses uv coords (fragCoord.xy / iResolution.xy). If I will have time enough I will try to port this to directx 11 Smile

RE: 2D Spectrum, visualization - ironic_monkey - 2015-05-07

i have now fixed it up for libplatform.

RE: 2D Spectrum, visualization - un1versal - 2015-05-07

Thx spiff, will have a look soon as the kodi-platfom changes are merged into mainline

Great work btw.

RE: 2D Spectrum, visualization - da-anda - 2015-05-08

awesome work guys, and thanks spiff for not giving up on us Smile

RE: 2D Spectrum, visualization - ironic_monkey - 2015-05-08

nothing has changed in that regard as such, you won't see any pr's from me.

RE: 2D Spectrum, visualization - topfs2 - 2015-05-08

(2015-05-08, 15:22)ironic_monkey Wrote: nothing has changed in that regard as such, you won't see any pr's from me.

Is it ok if I put PRs towards your project instead? And how do you want it? against master in xbmc-cmake?

RE: 2D Spectrum, visualization - ironic_monkey - 2015-05-08

you can certainly send pulls to my repo if you want, and yes, i only maintain the master branch. the annoying bit is that i don't consider it a public tree, i.e., i rebase on upstream all the time..

RE: 2D Spectrum, visualization - topfs2 - 2015-05-08

(2015-05-08, 16:59)ironic_monkey Wrote: you can certainly send pulls to my repo if you want, and yes, i only maintain the master branch. the annoying bit is that i don't consider it a public tree, i.e., i rebase on upstream all the time..

Hmm I guess thats the easiest way to handle it for you, since your following xbmc. Merging from xbmc might become a nightmare if you do normal merges? I don't want to be a hassle Smile
Currently I'll try to focus mostly on the visualization, which is outside kodi no matter. But after that I could potentially PR the headless and log4cxx stuff I've been working on, if your interested

RE: 2D Spectrum, visualization - ironic_monkey - 2015-05-08

it's just gonna be a hassle on your end (having to rebase the pr's now and then) Smile i'll be lenient and cherry-pick whenever possible.

yes, merging becomes a real hassle. i need my stuff on top, if not every conflict ends up in a merge commit and not the original commit.

i'll gladly carry logging stuff as well - it will be a great improvement. i'm not very interested in headless as i don't think i like the approach Wink rather i think kodi should be split into modules/libraries, then those are reused in a separate binary.

i saw some fixes on the vis api in your branch, those i am very interested in, that thing is a mess.

RE: 2D Spectrum, visualization - topfs2 - 2015-05-08

(2015-05-08, 17:11)ironic_monkey Wrote: it's just gonna be a hassle on your end (having to rebase the pr's now and then) Smile i'll be lenient and cherry-pick whenever possible.

yes, merging becomes a real hassle. i need my stuff on top, if not every conflict ends up in a merge commit and not the original commit.

i'll gladly carry logging stuff as well - it will be a great improvement. i'm not very interested in headless as i don't think i like the approach Wink rather i think kodi should be split into modules/libraries, then those are reused in a separate binary.

i saw some fixes on the vis api in your branch, those i am very interested in, that thing is a mess.

Cool, I'll try to do a logging pr/branch and the vis api too. In my current approach with the vis api I just put locking (and moved start to audio thread), but I'm contemplating moving it so that all calls are on main thread, then fishbmc wouldn't need changes Smile

EDIT: Yeah I'm not overly fond of the approach either with headless, It was a minimal effort to get it working Smile I'd much prefer it as you say

RE: 2D Spectrum, visualization - ironic_monkey - 2015-05-08

by the way, if you're actually dev'ing the viz with my fork, the easiest way is

1) build kodi somewhere
2) configure the addon with -DCMAKE_PREFIX_PATH=<build_dir>/build -DKODI_BUILD_DIR=<build_dir>

that way it will use the platform libs etc from the kodi build dir, and whenever you execute 'make' in the visualization's build dir, it will mirror data and binaries in the kodi build dir for easy testing (just run out of the build dir and test..).

executing 'make' in kodi will keep the add-on bindings up to date, so no need copying those around manually either should you be changing those. it is all very convenient Smile

note that you have to use the cmake buildsystem in project/cmake - i don't update the autotools system at all.

RE: 2D Spectrum, visualization - Paxxi - 2015-05-09

(2015-05-08, 17:05)topfs2 Wrote: Currently I'll try to focus mostly on the visualization, which is outside kodi no matter. But after that I could potentially PR the headless and log4cxx stuff I've been working on, if your interested

Please consider spdlog instead of log4cxx, light weight, does everything we need, no dependencies.
It's been on my todolist to implement but haven't had the time yet to get started.

RE: 2D Spectrum, visualization - topfs2 - 2015-05-09

(2015-05-09, 16:46)Paxxi Wrote:
(2015-05-08, 17:05)topfs2 Wrote: Currently I'll try to focus mostly on the visualization, which is outside kodi no matter. But after that I could potentially PR the headless and log4cxx stuff I've been working on, if your interested

Please consider spdlog instead of log4cxx, light weight, does everything we need, no dependencies.
It's been on my todolist to implement but haven't had the time yet to get started.

TBH I care very little what kodi needs. I moved almost entire kodi logging to log4cpp and tried to have a discussion on it half a year or so ago. I was only met with hostility and bikeshedding making me leave development of it all together. You are ofcourse free to pick and choose whichever library you want and submit to kodi. I will not contribute this to kodi upstream, I do this for me

log4cxx is standardized (follows log4j), is created by a big organization (apache), has pkg-config files, exist on all platforms and is extremely extensible and versitile. All makes it perfect for addons and outside projects.