I have a bare-bones Linux distro running on a machine connected to a laser. I want to develop an interface which allows me to:
Configure settings for the laser (e.g. toolbars and buttons)
Display the current path of the laser (e.g. graphics window)
Since these are bare-bones machines, I don't have X11 installed. I figured that perhaps I could use ncurses to develop a cross-platform interface to configure the settings for the laser, and use SDL to draw arcs and lines to represent the path of the laser.
While I'm comfortable using ncurses and SDL independently, I'm having trouble figuring out how to embed the SDL graphics within an ncurses window.
Is it possible to embed a graphics window (not necessarily SDL) into an ncurses application? If not, is there a cross-platform alternative to ncurses which will do what I need without X11?
The Ncurses project appears focused on developing a library for the construction of text-based user interfaces. As such, I do not believe there currently is, nor is planned to be, support for embedding an SDL graphical context.
I would suggest looking into other options such as the AGAR library which enables the creation of graphical user interfaces within SDL.
Related
I am working with an existing OpenGL library which needs to be augmented with other UI functions (better keyboard input, mouse handling, etc). I was hoping to use SDL, SFML or GLFW with the existing OpenGL API to facilitate this. Using any of these frameworks, is it possible to hook UI functions from any of these frameworks into an existing window, rather than a window directly created from these frameworks?
-The existing OpenGL window is already created by the library I'm forced to use.
-I'm aware of the SDL_WINDOW_FOREIGN bit set but am not sure how this is supposed to work.
-Is there a better strategy for simply detecting mouse/keyboard input?
The SDL 2.0 function SDL_CreateWindowFrom() can set up SDL for input and rendering from a given native window.
https://wiki.libsdl.org/SDL_CreateWindowFrom
I was wondering what is the difference between the windows that will render images on the screen (such as SDL, SFML or OpenGL) and the classic GUI window (with the gray background by default) where you can implement buttons like in Qt for C++ or AWT/Swing in Java?
What is going on in the background code? Are they the same type? Is there a rendering layer over the graphics window allowing to display such images?
Well first of all they are different APIs. SDL and SFML are libraries directed at making games and quite possibly other applications. OpenGL is a graphics API, it is not a full suite of libraries.
Note also that SFML pretty much uses OpenGL to render to the window. The actual window its self is created via platform specific functions. The Win32 API is used for windows and the X11 Window System is generally used on Linux.
The "classic GUI window" is pretty much the platform specific APIs. The differences in background code is really just defined by the purpose of the API. Note that in the end of the line Qt/SFML/SDL all go down to the platform specific API. OpenGL even requires you to interface with the platform specific API. SFML/SDL/QT essentially do the lower level work for you.
I hope I gave what you are looking for as this question really has a wide range of answers.
I am looking for the ability to open OpenGL contexts and draw native OpenGL in windows, macOS, linux distros with X, android and iOS
I don't want to rely on the "native" device framework for the actual UI, I don't need to use native components, all I want is an OpenGL context to natively draw in OpenGL. Many of the cross platform SDKs like Marmalade and MoSync focus on making use of the native UI components and stuff like that, all I need is an OpenGl context to draw as I intend to, absolutely no native UI functionality is required, however, access to native hardware features like microphone, camera and other sensors is desired if possible, as well as access to audio/video/network.
I don't want to use QT, I want to do something that is closer to the hardware to work on the low level. The general idea is to make a lightweight cross platform hardware accelerated GUI, written on a level low enough to be truly hardware native, without relying on any native software framework. I know for android I may have to use a java wrapper to launch the native code, but the idea is to have this wrapper minimized, with very little modifications needed to deploy the low level and thus hopefully TRULY cross-platform code, that is only dependent on OpenGL hardware and OpenGL context for it to work wit.h
So I need a bare minimum solution to avoid using non-cross platform features as much as possible.
At the time the only library that comes to my mind is SDL, but I am not sure it supports android and iOS property, so besides library recommendations, more information on how SDL handles android and iOS devices and their hardware is welcomed too.
How about:
GLFW
SDL
GLUT (FreeGLUT or OpenGLUT)
Blender's GHOST framework?
Essentially they open a window, create a OpenGL context on it, deliver you the input events and leave the rest up to you.
What you want is nothing more than a platform-specific OpenGL context setup (which is quite simple and well documented: the NeHe OpenGL tutorial provides code for many environments that does just this here (the explanation is Windows specific, scroll down for the code on different OSes).
Once you have the OpenGL context, nothing prevents you from creating a full GUI with all OpenGL elements.
If you want, you could use Qt to only set up an OpenGL context (ie don't use any QWidgets or anything, other than the window showing you your OpenGL scene). It takes care of the whole setup process, but for only that, Qt becomes a huge dependency, as it only really replaces at most 100 lines of code per platform.
With regards to SDL+Android, have you checked the README?
And for iOS check the same file here.
I'm using cocos2d-x to develop an iPhone game and then it just came to my head why not release my game for PC too? The only problem is that setting the window to full screen mode is not implemented yet. Now I'm just stuck with how to create a full screen window? There are some window creation functions that are used but I'm not sure which one and how I should change.
There is the eglCreateWindowSurface function that cocos2d is calling to create a window. I'm not sure which option I should change so that it creates a full screen window. It would also be nice if I can implement a function that switches my game to full screen mode and back while running.
On Windows it's a bit more compilicated. Essentially you have to:
Create a proxy OpenGL context to get access to functionality above OpenGL-1.1 through extensions
Load the extensions required to create an OpenGL-ES compatible context
Create the higher version OpenGL context
Again Load the extensions, now for this context
Luckily all this has been wrapped up in several easy to use libraries. I recomment GLFW for Window/Context creation (it deals with all that proxy context stuff, too), and GLee or GLEW to make the OpenGL extensions available to the code.
http://www.glfw.org/
http://elf-stone.com/glee.php
http://glew.sourceforge.net/
Those libraries are cross platform, so your application/game itself does not use OS dependent functions, it will compile not only for Windows but also Linux, BSD and MacOS X.
I have a simulation software (C++) that runs on the command line. It is platform independent (currently compiling and running on Windows, MacOS X and Linux). When the simulation ends, I visualize the result with SDL; it is a very basic 2d view, mainly color squares next to each other.
I would like to have a user interface on top of the simulation so that I can start and pause the simulation, and change the parameters on the fly. Something pretty simple I guess. Well, ideally I will also add a grapher somewhere to see the evolution over time of some parameters.
Now, I am wondering what direction I should go.
Should I try to use one of the UI libraries for SDL ?
Or maybe wxwidget in conjunction with SDL ?
Or simply wxwidget and get rid of SDL ?
Do you have any experience with this ?
Thanks in advance
Barth
PS: I tried to use AGAR, a SDL UI library. It seemed very promising but I couldn't get it working. Not even the helloworld.
It may be worth you time to look into Qt. It is generally the most mature free Gui framework available. It is cross platform. And it has hardware accelerated rendering if your drawing needs some speed.
Here is a comparison posted on WxWidgets site.
In the end if your windowing needs are minimal you should choose the framework you are most comfortable with.
Probably using wxWidgets without SDL would be the easiest way to go. SDL is a media layer -- it's supposed to allow cross-platform media application development. As you only need graphical display, you only need wxWidgets -- and it will be a lot easier too!
You would benefit from SDL if:
you'd need very fast blitting of very large amount of surfaces (we're talking the 60fps range here)
you'd use RLE, color keying or other graphics operations
you'd use other media (sound, advanced real-time input, etc)
you'd need to run the software on embedded systems (handheld consoles, etc)
If the answer to all 4 is "no", then you won't benefit from SDL, and using wx alone will be much easier.