Can someone confirm that WebGL works with node-webkit on Linux distros?
I can make WebGL run on Google Chrome after enabling the flag Override software rendering list on chrome://flags/, but I'm getting errors regarding Three.js when trying to execute the same application on node-webkit.
To answer my own question:
It just depends if the system has a video driver installed that supports:
hardware acceleration and
OpenGL ES2.0
(the requirements for WebGL)
Node-WebKit or not, WebGL is gonna run smoothly, if the above requirements are met.
Related
I want to implement a hair filter app for Linux, so for the first steps, I tried to implement and run this video project. How can I run it on my Laptop without an android or iOS?
Are there any frameworks like ARcore and ARkit for face tracking in Linux?
(It's preferred to run it on Linux because I want to run it on an embedded system.)
These are the frameworks that I can choose in Unity, but I think that all of them need a VR device so I can't use them.
I am running Qt 5.4.2 on a Tegra 3 with a Yocto compiled Angstrom image. Unfortunately the Tegra only has proprietary drivers and they are forcing me to use X11 for hardware acceleration. I therefore had to build Qt with XCB instead of EGLFS.
My problem is that I am seeing tearing on some QML 2 animations on the device that are not visible on my PC. I am wondering if there is anything I can do to try and get rid of this tearing? I have read that QT_QPA_EGLFS_FORCEVSYNC might help but unfortunately I can't use EGLFS and doubt if it will be of any use.
EDIT:
I have noticed that "QSGContext::initialize: stencil buffer support missing, expect rendering errors" as well as "Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable." come up when the application is started. Could they be related to the problem?
As I understand it, Chromecast runs a modified version of ChromeOS.
Hackers examining the device have "concluded that it’s more Android than Chrome OS," adding, "to be specific, it’s actually a modified Google TV release, but with all of the Bionic / Dalvik stripped out and replaced with a single binary for Chromecast."
With this in mind can one conclude that Chromecast can only run HTML/JS code and that it can't run any Native C code?
What if I have a Native C library which already runs on Android and iOS, what will be the best approach to port it so that it could be run on Chromecast?
No, there is no provision for supporting a native application.
I was doing some cross compiling of a Qt5.2 application for an ARM based target (TI AM335x EVM) and it was failing to display anything on my platform. After doing some google’ing I found that if I launched it with:
./helloworld -platform eglfs
it would show up (full screen, but it worked)!
I started looking at all the platform options, I found:
android, eglfs, linuxfb, minimalegl, windows, xcb, cocoa, ios, offscreen, qnx, directfp, kms, minimal, openwfd
I’m wondering what they are for. I assume, for example, that if I wanted to run my application on an Android device I’d have to pass -platform android, but they’re not all obvious to me.
Is there a listing anywhere of when each of these parameters should be used?
For example, what does eglfs stand for? And why did I need to use that where as linuxfb didn’t work? (I would have thought the linux frame buffer was how I wanted to launch my application since it was running on embedded linux)
If the linuxfb plugin doesn't work, then possibly you didn't correctly configure the framebuffer device on your system. Maybe a directf layer is already running, so you may want to try the directfb plugin instead.
If you wish to avoid having to specify the platform option when you run the executable, you can pass the default one to configure when you build Qt.
The plugins can be described as follows:
Linux plugins - those use Linux-specific input devices and various output devices
eglfs - Uses the OpenGL ES in fullscreen mode. There's no other way since OpenGL has no concept of a window manager.
directfb (not directfp) - Uses the linux frame buffer with OpenGL ES via the directfb layer (see also wikipedia). Integrates into the directfb windowing.
linuxfb - Uses the linux frame buffer in fullscreen mode. There's no other way since linuxfb has no concept of a window manager.
kms - Uses linux kernel modesetting API in fullscreen mode. There's no other way since DRM has no concept of a window manager.
openwfd - Uses an openwfd Wifi display in fullscreen mode. There's no other way since openwfd has no concept of a window manager.
Platform-independent plugins - could be made to run on any OS
xcb - Runs on an X11 server and is integrated into the X11 windowing environment. Generally it won't behave correctly without a window manager running as well. Can be made to work on Windows, given a Windows implementation of xlib, if you want to, say, serve applications from a Windows server to X11 thin terminals (typically Unix boxes).
offscreen - Renders to an offscreen buffer. Useful for rendering to custom displays.
minimal - A minimalistic backing store that optionally dumps the virtual screen to a file. Implements the bare minimum of functionality just to demonstrate how to start writing a platform plugin.
Other platform-specific plugins
android - Uses the Android APIs and is integrated into the Android environment.
windows - Uses the WINAPI and is integrated into the Windows windowing environment.
cocoa - Uses the Cocoa APIs and is integrated into the OS X windowing environment.
iOS - Uses the iOS toolkits and is integrated into the iOS environment.
qnx - Uses the QNX APIs and is integrated into the QNX photon windowing environment.
I just replied in the TI forums to the same query. If eglfs is functional and linuxfb is not, please file a bug in JIRA with qt-project.org, as both eglfs and linuxfb in AM335x use the linux framebuffer. eglfs (when used with a widget application) uses dirty-rectangle approach with a fullscreen display. Also move to QML if possible when on Qt5.
PS: you can export QT_QPA_PLATFORM=eglfs (or linuxfb) on the target to avoid setting the platform everytime you invoke the application. (http://doc.qt.io/qt-5/embedded-linux.html)
Probably the most noteworthy addition since the accepted answer was written is Qt's wayland platform, apparently since Qt 5.11 (in official binaries). Enabled now by default on Fedora 31+... which can be a little troublesome for some apps. Red Hat had to implement a fallback list.
I'm some familiar with Cocos2d and Cocos2dx.
But only I worked in Mac, I know which is possible work with this engine (Cocos2dx) in Windows, but I don't know if is possible develop a game on Linux.
By the way:
I'm not talking about a port, I want develop a Videogame multiplataform on Linux.
Would be great know the way of how start my game on Linux.
Thanks!
While I haven't tried it, cocos-2dx is, according to their documentation, is usable on Linux although my understanding is that this means one can build android projects using cocos2d on Linux.
In terms of where to start, I've used both SFML and SDL as both are well supported on Linux. Both are cross platform although SDL supports a wider range of platforms - I have an SDL2 game in progress that runs on Linux and android for instance whereas SFML does not yet have android or iOS support. Coming from cocos2d though I think you'll find the SFML API easiest to pick up.
As a fair warning, the landscape is a bit confusing at present because both SFML and SDL have a popular stable release (1.6 for SFML and 1.2 for SDL) with one API along side a popular development release (2.0 for SFML and 1.3/2.0 for SDL) that has a similar but not identical API. This is particularly noticeable with SDL where the documentation for 1.2 is much better than the documentation for the development API. In terms of choosing one over the other, the stable releases are precisely that - stable. In both cases the development releases have been under way for some time so if you are willing to dig for documentation a bit and ask questions it's worth getting the new features.
There is book that provides a nice introduction to Linux game development that, while dated, might be a good first step if this is your first outing with games on Linux, especially if you decide to use SDL Programming Linux Games.
Update:
I saw the directions here and after (roughly) following them cocos2dx does build on my Ubuntu 12.04 x64 machine. The "Set up Environment" directions seem sound but the makefile information appears to be out of date as there is no build_linux.sh instead there is a make-all-linux-project.sh. After this finished pulling in missing deps and building I changed into the samples/HelloCpp/proj.linux directory and ran make. This created a HelloCpp binary in samples/HelloCpp/proj.linux/bin/debug. Running that popped a HelloWorld cocos2d screen. According to the output the verison is:
cocos2d-x debug info [cocos2d: cocos2d-2.1beta3-x-2.1.0]
That said, I don't see a lot of documentation for the linux port and most of the related community entries seem to be out of date so you may find more support from using one of the libraries I already mentioned.
Download cocos2d-x project there is a test sample games which compiles on all platform android, windows, iOS , Windows Phone ...See you are going to code in c++ that's it then whether you build it in linux or any other platform doesnt matter for cocos2d-x kind of engine
so i suggest start with the sample projects of cocos2d-x .... and as you want to do it in linux ...make something then compile it in linux like I do ...