I'm try to see if/how it is possible to make a windows(or even mac/linux for that matter) application that will post process everything that is on the screen. If possible I would like to be able to use glsl shaders to perform things like color inversion and sobel filtering to everything on screen. Does anyone know how this can be done?
The Compiz compositor for linux looks like it can do what you want. It includes many post processing effects already (as included plugins) and allows you to add your own through custom plugins. It looks like these plugins can use GLSL pixel shaders.
According to this site, the following commands should set up the CompizConfig Settings Manager on Ubuntu 13.04
sudo apt-get install synaptic
sudo apt-get install compizconfig-settings-manager compiz-plugins-extra
Hopefully this provides a helpful starting point for your project!
Disclaimer: I have not actually used Compiz. I'm basing my description off of what I can find online.
Related
I am new to the use of typesafe-activator.
I installed it using homebrew on my Mac and tried out the hello-akka tutorial.
Following said tutorial, at the end there is a section about Inspecting the App, for monitoring actor status and other things.
Now I can't seem to find the option to inspect the app in my activator web client (as shown in the image below), while googling for the problem hasn't given me any results.
Now the question is: do I need to install some plugin or something, or the homebrew version of activator is missing some functionalities?
It looks like they have decided to discontinue it:
https://github.com/typesafehub/activator/issues/1067
Although I've just signed up for Stackoverflow, I've used answers.ros.org, pcl-users.org, and other similar sites. I'll try to give as much information as possible because although similar problems come up in Google searches I cannot find an answer to this.
I'm running Ubuntu 12.04 and I've installed PCL 1.7 via their set of instructions here: http:// pointclouds.org/downloads/linux.html
Following the tutorials I was able to get the "reader" and "writer" sample programs to work with the sample PCD's they give. I was also able to successfully use cmake to compile a more advanced program: http://pointclouds.org/documentation/tutorials/normal_distributions_transform.php#normal-distributions-transform
The problem begins whenever I try to make the iograbber or any other visualization programs that involve the Kinect. This is specifically the one I really want to use: http://pointclouds.org/documentation/tutorials/openni_grabber.php#openni-grabber Repeatedly, without fail, this has always been the warning I encounter when using cmake:
-- checking for module 'openni-dev'
-- package 'openni-dev' not found
-- Could NOT find openni (missing: OPENNI_INCLUDE_DIRS)
** WARNING ** io features related to openni will be disabled
It gives this warning several times in a row related to various components checking for it. Now you might say, "silly user, why don't you simply install openni-dev?"
Well when I initially did it with sudo apt-get install -y openni-dev (notice the -y which I soon learned about) it deleted most of my ROS/PCL files. Thread is here: http:// www.pcl-users.org/How-can-I-get-PCD-files-from-a-streaming-Kinect-td4033721.html It broke some packages and long story short I found out about aptitude and eventually I got myself back to square 1.
The thing is, I'm fairly sure I have openni 1.5.4 installed but somehow it isn't being found. When I go to my usr/lib folder it only shows an OpenNI2 folder, and not an OpenNI folder. I know there's a lot of issues with openni-dev popping up for PCL and ROS so I hope this answer will be able to help others as well. Before you ask, I'm copying/pasting the CMakeLists and C++ files exactly as I find it. I don't have a lot of programming experience so I hope I'm not missing something obvious.
If you use kinect v2, there's no OpenNI support.
So you can use this grabber:https://github.com/UnaNancyOwen/KinectGrabber/tree/Kinect2Grabber
I have a problem with installing OpenGL (and GLut) and using it with Ocaml.
I have tried many different packages (under both Linux and Windows) and always got problems
about not found modules or other.
What will be easier : Linux or Windows? What should i exactly do? Which package of bindings is the best? ( are bindings is enough or i need to download some other things?)
Could anyone describe it step by step in a way that can be easy to follow?
Here are the exact steps :
sudo aptitude install liblablgl-ocaml-dev
cp /usr/share/doc/liblablgl-ocaml-dev/examples/simple.ml .
ocamlfind ocamlopt -linkpkg -package lablgl.togl simple.ml -o simple
./simple
I don't have the motivation to walk you through the installation process at the moment, but here are some (hopefully helpful) comments:
You generally want to use OCaml in *NIX because OCaml shows a very clear bias toward it. In particular, its debugger and profiler are not available in Windows.
One issue I randomly run into when installing new libraries in Linux (which may be a sign that I'm doing something dumb, come to think of it; oh, well) is permissions errors causing module loading errors. Try tracking down where the relevant libraries were installed and check that they're accessible (e.g. try lsing them as a user; seeing them in a directory is not enough).
For example, I recently installed OCamlMPI but was getting errors about it not being able to find modules even when I gave full paths to them.
It turned out that the directory it was stored in ($(ocamlc -where)/ocamlmpi) had a modmask of 0744 (i.e. drwxr--r--) when it should have had 0755 (i.e. drwxr-xr-x). After the permissions were changed, the modules loaded and worked just fine.
In fact, that's actually a problem I've run into when installing Python modules, too. Maybe I am doing something dumb somewhere.
Anyway, I hope that helps. :)
http://code.google.com/r/hectorchu-go-windows/source/list
If you could compile it successfully, I like to know the procedures of how to.
Assuming you are using Hector's source tree:
Install MinGW and MSYS, along with MSYS Bison and any other tools you think you'll find useful (vim, etc).
Install ed from the GNUWin32 project.
Install Python and Mercurial.
Clone the [hectorchu-go-windows mercurial repository](https://hectorchu-go-windows.googlecode.com/hg/ hectorchu-go-windows) to C:\Go.
Run an MSYS shell (or rxvt). The rest of these are bash commands...
mkdir $HOME/bin
export PATH=$HOME/bin:$PATH
export GOROOT=C:\\Go
export GOARCH=386
export GOOS=mingw
cd /c/Go/src
./all.bash
Correct errors as it spits them out at you, repeat step 10 until it starts building.
It's the same idea as on Linux or MacOS, basically.
However, I still stand by what I said in my comment above: this isn't necessarily going to generate anything that actually works yet. You'd be better served by waiting until this effort has merged into the main Go tree before tackling it, unless your interest is in assisting with the porting effort.
Update: there is now a mostly-functional pre-built windows port available, for those not interested in building the compiler themselves. However, given the rate of change of the project, the lack of formal releases (other than the hg "release" tag), and the possibility of Hector's changes being merged into the main branch soon, keeping up with development via source builds is likely to produce better results over time.
Just FYI, there is seems official one now.
http://code.google.com/p/go-windows/
Hector said he was only able to get as far as being able to compile and run an empty main. See issue 107:
http://code.google.com/p/go/issues/detail?id=107
There is still a lot of work to do in porting that, especially since the code has lots of dependencies on ptrace and syscall, not to mention the different threading models between Linux/BSD and Windows.
Update:
There's a new thread on golang-nuts (started 26.03.2010) with a link to a recent build and some current building instructions (using MinGW+MSYS).
I'm trying to develop a GUI application for an embedded platform, without any windowing whatsoever and I'm doing that with DirectFB, and it suits my needs very fine.
Since the embedded I develop for is not that powerful, I would really like to try to develop on my own Ubuntu desktop. The problem is Framebuffer is conflicting with X.org causing me to leave the whole desktop, and shutdown X.org just to see the result of my changes.
Is there a good framebuffer simulator that suits my needs? Qt has one, called QVFb, but it only works for developing Qt apps, and the VNC back-end of DirectFB always crash.
So, any ideas?
DirectFB has a X11 backend.
$ sudo apt-get install libdirectfb-extra # for Debian and Ubuntu, anyhow
$ cat ~/.directfbrc
system=x11
force-windowed
Also, DirectFB has a SDL backend, and SDL has a X11 backend. Also, SDL has a GGI backend, and GGI has an X backend. That's a bit circuitous, but it should work :)
I tested it with
$ SDL_VIDEODRIVER=directfb ffplay some_movie.avi
and got a nice 640x480 window with media playing and DirectFB handling layering and input, so I'm sure this works.
The three previous answers are all good suggestions. I'd suggest trying ephemient's answer because it's the simplest. For more details on setting up your .directfbrc file, check out "man directfbrc".
One other possibility would be to switch from X to another virtual terminal (using CTRL+ALT+F1), run your directfb program, and then switch back X (using CTRL+ALT+F7).
I came to use ephemient's solution to run DirectFB applications inside a chroot environment (target filesystem as a courtesy of buildroot) in addition to Xnest, a separate X environment which runs in a window of the current X.
$ Xnest -ac :1 &
$ cd $TARGET_DIR # into the target file system root
$ DISPLAY=:1 sudo chroot . usr/bin/df_neo
This way you can assure not only your directfb installation is correct, but also all the required dependencies are installed inside the chroot'ed file system.
You could use Moblin Image Creator to create a disk image of Moblin, which you can then run inside a VM like QEMU. You can then test your DirectFB application inside the virtual machine.
You could develop (i.e. edit and compile) your application on your Ubuntu desktop, and test your application on the embedded platform that it is intended to run on.
If the embedded platform supports networking, you might be able to reduce the length of your edit-compile-test loop by running the application directly from an NFS share.
Here is a nice example with qemu and directFB:
https://bootlin.com/blog/qemu-arm-directfb-demo/