I've been using SDL for a while to prototype small things and to learn more about graphics programming.
Then I saw SFML and wanted to give it a try, saw that it was more object oriented and fixed some issues I felt SDL had.
But since I know little about the library itself, what are it's main flaws and other issues that I should be aware of?
Currently I'm liking it, good tutorial and most things just seem to work.
The biggest issue that has ever affected me is the crash involving the default font when ending a program. This is a fairly well-known bug that you can read about in the SFML forums. As far as I know, this bug is fixed for the 2.0 version of SFML but not for 1.x versions.
For other bugs (along with feature requests), you can check out the SFML Roadmap.
Well, now SFML 2.x is quite standard.
I have 2 main issues with 2.1:
The program can crash when ending with Windows XP, because of a bug in the audio module.
It should be corrected now, but not in the 2.1 and the fix is out of scope for the 2.2 (to come) version.
-> You can compile the last SFML version, or use something else for Audio (OpenAL, SDL...).
RenderTextures don't work correctly on Mac : I haven't found any workaround, so I just don't use RenderTextures now.
Related
GNOME has chosen to not support server-side decorations under Wayland. That's okay, but I'm making a game in SDL, and I'd like first-class Linux support, including supporting running natively in Wayland (with SDL_VIDEODRIVER=wayland) under the biggest desktop environments (including GNOME).
Currently, when I run my game with SDL_VIDEODRIVER=wayland, no decorations are drawn. How am I supposed to integrate with the rest of the system? What's the story for non-GTK/Qt applications in practice?
The SDL2 developers are working on this right now: https://github.com/libsdl-org/SDL/pull/4068 So while there isn't an easy solution as of now, the good news is that you'll probably not really need to do anything than wait a few more months and then just use latest SDL2.
In general, the situation for non-Qt/GTK stuff is like this:
GNOME is currently not willing to introduce the decoration code into GNOME's compositor Mutter mostly from what I can tell are technical reasons: GNOME's decorations are GTK+-based, but Mutter has apparently zero GTK+ code right now so it's apparently not as easy to integrate as one would hope.
So non-GTK/Qt applications have three options: 1. they can manually implement it, or 2. they can use something like libdecoration as SDL2 is apparently going to do, or 3. pull in GTK+ as a dependency purely for the window and decorations which e.g. Electron/Chromium uses it for. It seems like in the medium term at least, GNOME will not fix this so these are the only options I'm aware of.
I have been programming on DirectX12 since last year, and I've experienced DX10 and 11. There is something bizarre I found in my application DX12 and i am not able to find why or a solution. I cannot show my original code, but it's ok, because it happens in any simply DX12 sample.
We can use directly the Triangle Sample (provided by DirectX12 officials) for example. I integrate it without modifying anything basic in a MFC SDI application, and until now everything works fine. But after I change the Swap Chain format to DXGI_FORMAT_R16G16B16A16_FLOAT, the application produces flickers when other windows or apps are staying/moving on the top of it but without entirely covering it. You can find here the video I made (sorry for the quality) to show the flickering, and also here the visual c++ 2015 mfc sample.
I tried something like changing erasebackground method, but still can't find a solution... Is this a programming level problem? but in which level, MFC, DirectX12, or DXGI? Or is this a os or hardware level problem??
I have already give the whole project vc++, so i suppose I can jump the step of giving the "Minimal, Complete, and Verifiable example". I dont show the code, because I dont know which part of code may be the cause of the problem, and also I am not sure if it is coding problem. And I would like to mention that the problem arises only when I replace the DXGI_FORMAT_R8G8B8A8_UNORM by DXGI_FORMAT_R16G16B16A16_FLOAT. And by the way, the flickering does not happen with DirectX11 if i do the same "integration to MFC" thing.
PS. There is no error or warning when debugging in VC2015.
PS. the same thing happens when I integrate the sample (by making it dll) into an C# Winforms apps.
Although I know how to create a VST plugin today, I still don't understand the GUI part of it.
I've been playing around with Steinbergs samples and what I can see is that they are using some default sliders in the exapmles, but am I supposed to use these when designing my own and apply some graphics to them? Or should I create my own completly? How should I think around the GUI approach to make the GUI code also work for both PC and MAC later on?
I've been searching my rearbehind off but can't find anything about these questions anywhere. Please give my a lead or guide me to the light so I can grow my hair back.
How should I think around the GUI approach to make the GUI code also
work for both PC and MAC later on?
If that is your ultimate goal, then I strongly suggest you check out the JUCE library. The plugin wrappers are very good and it is completely cross-platform.
I recently tried to lay my hands on OpenGL. Trying to grasp the API, I am using MinGW along with OpenGW. Now, I learned (or was given the advice) that I shouldn't use glBegin and glEnd anymore, since those are deprecated, but should start with OpenGL 3.1, instead. As I didn't know that the version used makes such a difference, I didn't pay much Attention as to which version I actually have installed on my computer. And, as far as I can see, there is no glVersion or similar call that I could use to determine that version.
Since I am using MinGW I went to its respective include folder and found in c:\MinGW\include\GL\gl.h:
/*
* Mesa 3-D graphics library
* Version: 4.0
[more lines]
*/
[more lines]
#define GL_VERSION_1_1 1
#if !defined(__WIN32__)
#define GL_VERSION_1_2 1
#define GL_VERSION_1_3 1
#define GL_ARB_imaging 1
#endif
[more lines]
#define GL_VERSION 0x1F02
which, to me, indicates, that the installed version is as low as 1.3. Is this the case or how could I verify my suspicion? Also, where would I find a later version (that is working fine along with MinGW) if I have 1.3 (or whatever version it is) only?
So, does someone know, if my suspicion is right and that MinGW comes with an outdated OpenGL version?
Edit I realise that this question might be taken as a duplicate of Which OpenGL version by default installed along with MinGW?, yet, I believe this question is specifically about MinGW and OpenGL, so I think that this fact allows for a (perhaps) more specific answer.
So, does someone know, if my suspicion is right and that MinGW comes with an outdated OpenGL version?
MinGW comes without "an OpenGL", your operating system (the graphics card driver, usually) provides OpenGL.
MinGW provides a header file (gl.h), and a corresponding library (libopengl32.a) which is a wrapper for opengl32.dll, a dynamic library which comes with Windows and contains the handles to OpenGL 1.0 an 1.1 functions... something around that, not sure about exact version numbers.
Then:
Most operating systems allow you to use the whole OpenGL in a similar way.
On Windows, however, in order to access the newer OpenGL functions than what's in the header and library wrapper (which you probably do have available - depending on your GPU and driver), you have to use system calls to load the function pointers to the OpenGL calls.
There are libraries which do that for you and let you use OpenGL 3/4 functionality easily. I recommend gl3w or GLEW. That's the usual way of using OpenGL on Windows.
There's glGetString(GL_VERSION).
Please note this question has been asked and answered before.
http://learningwebgl.com/blog/?p=11#troubleshooting has some good information - WebGL uses OpenGL. You can use http://www.realtech-vr.com/glview/ to confirm your test.
Yes, I hate Objective-c, plus my project will be portable, so I'd like to code as much of it in C++ as possible, ideally 100%.
So I have a regular C++ project made with Xcode, and want to open some OpenGL windows.
edit: Damn, Glut takes over the app's control with glutMainLoop() and I'll like to have more control over the loop.
Will try freeglut, although I can't find OSX binaries, and I always have such bad luck trying to compile someone else's code.
Update:
I tried yet again to link to SDL 1.3 and this time I could get it to work! yoo-hoo!
I always wanted to work with SDL, but using more than one window was mandatory, and that's a feature of version 1.3 which is under development and I never could get it working.
As it is portable to a zillion OSes, and handles 2D graphics as well as OpenGL I'm going with it. Thanks to all!
If you don't want to use objective-c you're going to have to use either the deprecated carbon libraries, X11, or another library like GLUT to create the window. If portability is a concern either go the GLUT route, or you'll need to write your own window management code for each platform you want to support.
If you don't go the GLUT route you will need to write window management code fore each operating system so I strongly suggest you bite the bullet and write the window management in objective-c++. The only thing you really need to know is that a pointer is always a pointer no matter which language it is in, so just store objective-c ids as void* and cast them back to ids, it actually works out pretty easy.
i guess NeHe tutorials could help;
GLUT works fine for your stated purpose, although you will probably wish for a nice C++ wrapper for it. I ended up hacking my own, and although GLUT isn't friendly to wrapping, it was doable.
EDIT: Since you have a problem with glutMainLoop(), you may be trying to do more than GLUT was designed to do -- it is mainly intended for hacks, one-off projects and opengl demos. And freeglut doesn't compile OOB on the mac, at least that was my experience.
For a portable, fuller featured app, Qt may be the way to go for you. Otherwise, design your C++ for portability and use a thin GUI layer on each platform. If getting something running on each platform is most important, go for the former. If the best user experience on each platform is most important, go for the latter. You may find that "thin" is not the most descriptive term for what is involved.
I found this demo to be useful for getting a simple Cocoa/OpenGL window working, even though the code has a number of ridiculous bugs: http://developer.apple.com/library/mac/#samplecode/CocoaGL/Introduction/Intro.html
This question has been asked over 3 years ago, yet remain quite fresh. I just recently went through similar exercise for planning school curriculum, and trying to figure out what's the best portable library to work with on Mac/Windows/Linux/mobile with OpenGL projects. Perhaps my notes will help someone make a decision. I only mention the main options that I've considered.
Higher level APIs, for window management plus additional goodies, like sprites, fonts, sounds, event handling, etc:
SFML and github repo: nice&tidy, C++, object oriented library that integrates with OpenGL natively. Portability for managing windows and OpenGL 3.3 contexts out of the box on MacOS, Win and Linux. Mobile support provided in the 2.2 branch (github).
SDL2: all major platforms, including mobile, supported. The OpenGL context needs to be manually managed somewhat, so use of GLEW for example comes really handy (see below). A bit lower level than SFML.
Lower level APIs, mostly for window and OpenGL context management:
GLWF: This is pretty much a GLUT replacement for modern OpenGL. Rather low level, but portable across: Win, OSX, Lin. In active development.
GLEW: I only mention it for completness. It doesn't manage windows, but helps managing OpenGL contexts and you might use it together with GLWF or SDL for example.
Others:
Freeglut: Open source continuation of GLUT. Suitable for small demo projects. I have not used it myself, but seen good docs and demo code. In active development.
GLUT: old one, discontinued. Legacy demos and code around the net.