Finalspace
The only library which works is "libGL.so.1".
Are you sure?
Can you show output of "ls -la /usr/lib/libGL.so"? (or wherever this file is) I expect it to be symlink to /usr/lib/libGL.so.1.
Here's how it looks on my machine:
1 2 3 4 | $ ls -la /usr/lib/libGL.so* lrwxrwxrwx 1 root root 14 Nov 9 00:44 /usr/lib/libGL.so -> libGL.so.1.0.0 lrwxrwxrwx 1 root root 14 Nov 9 00:44 /usr/lib/libGL.so.1 -> libGL.so.1.0.0 -rwxr-xr-x 1 root root 562944 Nov 9 00:44 /usr/lib/libGL.so.1.0.0 |
Is there a way to detect such crappy drivers, so i can try the next one in the list?This is not about crappy drivers. This is about crappy distributions (if libGL.so is really broken). Suggestion is to not use crappy Linux distributions.
mmozeikoFinalspace
The only library which works is "libGL.so.1".
Are you sure?
Can you show output of "ls -la /usr/lib/libGL.so"? (or wherever this file is) I expect it to be symlink to /usr/lib/libGL.so.1.
Here's how it looks on my machine:
Is there a way to detect such crappy drivers, so i can try the next one in the list?This is not about crappy drivers. This is about crappy distributions (if libGL.so is really broken). Suggestion is to not use crappy Linux distributions.
Sure i can do that, i will post it soon.
Yeah ubuntu sucks but most people use this so i cant ignore it. But i will eventually switch to gentoo or arch.
Edited by Finalspace
on
Insane Update on X11/Linux Branch
I changed the entire FPL codebase to C99 in the x11linux branch. (Took me two evenings).
Now my plan is to finish the full window X11/GLX stack.
After that i will merge it into the master branch and remove the C++ version (I dont want to support two codebases).
@mmozeiko: Does this helps?
I changed the entire FPL codebase to C99 in the x11linux branch. (Took me two evenings).
Now my plan is to finish the full window X11/GLX stack.
After that i will merge it into the master branch and remove the C++ version (I dont want to support two codebases).
@mmozeiko: Does this helps?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | final@final-i7:~$ find /usr -name "libGL*.so" /usr/lib32/nvidia-384/libGLESv1_CM.so /usr/lib32/nvidia-384/libGLESv2.so /usr/lib32/nvidia-384/libGLX.so /usr/lib32/nvidia-384/libGL.so /usr/lib/nvidia-384/libGLESv1_CM.so /usr/lib/nvidia-384/libGLESv2.so /usr/lib/nvidia-384/libGLX.so /usr/lib/nvidia-384/libGL.so /usr/lib/x86_64-linux-gnu/mesa-egl/libGLESv2.so /usr/lib/x86_64-linux-gnu/mesa/libGL.so /usr/lib/x86_64-linux-gnu/libGLU.so /usr/lib/x86_64-linux-gnu/libGLESv2.so /usr/lib/x86_64-linux-gnu/libGL.so /usr/lib/chromium-browser/swiftshader/libGLESv2.so final@final-i7:~$ find /usr/ -name "libGL.so" /usr/lib32/nvidia-384/libGL.so /usr/lib/nvidia-384/libGL.so /usr/lib/x86_64-linux-gnu/mesa/libGL.so /usr/lib/x86_64-linux-gnu/libGL.so final@final-i7:/usr/lib/x86_64-linux-gnu$ ls -la /usr/lib/x86_64-linux-gnu/libGL.so lrwxrwxrwx 1 root root 13 Jan 17 16:34 /usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so |
Edited by Finalspace
on
Short Update:
The library (x11linux branch) is now fully C99 compatible and does not use any C++ features anymore, but it still can be used on any C++ projects. I am really happy that i did that transition - i always felt there was no need for C++ in the first place.
Also the Linux implementation is coming along very nicely. The most basic window features on X11 already works (ImGUI sample works). But its still incomplete, so i wont merge it into the main branch yet.
Regarding my X11/GLX problems:
My Ubuntu 17.10 installation uses wayland as default window system, but this seem to support the X11 api - so its no surprise that i get weird behavior. So i am planning to support wayland as well - it may be the linux window system in the future anyway.
The library (x11linux branch) is now fully C99 compatible and does not use any C++ features anymore, but it still can be used on any C++ projects. I am really happy that i did that transition - i always felt there was no need for C++ in the first place.
Also the Linux implementation is coming along very nicely. The most basic window features on X11 already works (ImGUI sample works). But its still incomplete, so i wont merge it into the main branch yet.
Regarding my X11/GLX problems:
My Ubuntu 17.10 installation uses wayland as default window system, but this seem to support the X11 api - so its no surprise that i get weird behavior. So i am planning to support wayland as well - it may be the linux window system in the future anyway.
Technically its not that wayland supports X11 api. What it does, it launches new real X11 server under which your application runs. Simplified explanation is that you render to x11 window, which gets transmitted wayland. Imho pretty bad overhead (more cpu, more memory used, etc...)
But yeah, this is the reason I don't use Wayland. People are saying this is the future for last dunno, 3 or 4 years already. But once a year when I try to migrate to it I get so many weird issues or buggy behavior that I nope back to X11 straight away.
Wayland makes sense for embedded hardware, where you know exactly what you are running and your are controlling full stack - from hardware and rivers to software that runs. Wayland is used a lot in embedded linux'es - TVs, set up boxes, etc..
Also afaik nvidia driver does not properly support wayland...
Btw, Ubuntu 18.04 (released next month) switches back to X11 as default display server: https://insights.ubuntu.com/2018/...-18-04-lts-to-use-xorg-by-default
So yeah, fun times with ubuntu :D
But yeah, this is the reason I don't use Wayland. People are saying this is the future for last dunno, 3 or 4 years already. But once a year when I try to migrate to it I get so many weird issues or buggy behavior that I nope back to X11 straight away.
Wayland makes sense for embedded hardware, where you know exactly what you are running and your are controlling full stack - from hardware and rivers to software that runs. Wayland is used a lot in embedded linux'es - TVs, set up boxes, etc..
Also afaik nvidia driver does not properly support wayland...
Btw, Ubuntu 18.04 (released next month) switches back to X11 as default display server: https://insights.ubuntu.com/2018/...-18-04-lts-to-use-xorg-by-default
So yeah, fun times with ubuntu :D
Edited by Mārtiņš Možeiko
on
mmozeiko
Technically its not that wayland supports X11 api. What it does, it launches new real X11 server under which your application runs. Simplified explanation is that you render to x11 window, which gets transmitted wayland. Imho pretty bad overhead (more cpu, more memory used, etc...)
But yeah, this is the reason I don't use Wayland. People are saying this is the future for last dunno, 3 or 4 years already. But once a year when I try to migrate to it I get so many weird issues or buggy behavior that I nope back to X11 straight away.
Wayland makes sense for embedded hardware, where you know exactly what you are running and your are controlling full stack - from hardware and rivers to software that runs. Wayland is used a lot in embedded linux'es - TVs, set up boxes, etc..
Also afaik nvidia driver does not properly support wayland...
Btw, Ubuntu 18.04 (released next month) switches back to X11 as default display server: https://insights.ubuntu.com/2018/...-18-04-lts-to-use-xorg-by-default
So yeah, fun times with ubuntu :D
Oh thanks for that explanation, i didnt knew that. This explains why i had tons of issues on my system.
So wayland support will come after X11 is done ;-)
Edited by Finalspace
on
Finalspace
This library is C++/11 only.
Noo not C++11 eww!
Finalspace
Its written in C++/98 mostly, but uses a few C++/11 features (constexpr, nullptr, enum class).
Nooo~ But at least a little better.
Finalspace
Important update:Well switching to C++/98 was not that easy as i thought it to be - there are no standard int types, so i had to add one.
Now there shouldn´t be any C99 or C++11 code anymore.
Yayy! :) C++98 is simpler!
Finalspace
Good news people, i am switching to C99. I got sick of all the namespace typing nonsense.
oo wow you really went down the rabbit hole. Namespaces are probably my least favorite feature of C++. But how can you survive without function overloading? Probably don't need it for your library, but function overloading was always my favorite feature of C++ (and wish it were available in C, along with operator overloading).
Anyways, just stopping by! Read the entire thread. Fun to see the progress :) Been following along with your commits on github for quite some time.
Randy GaulFinalspace
This library is C++/11 only.
Noo not C++11 eww!
Finalspace
Its written in C++/98 mostly, but uses a few C++/11 features (constexpr, nullptr, enum class).
Nooo~ But at least a little better.
Finalspace
Important update:Well switching to C++/98 was not that easy as i thought it to be - there are no standard int types, so i had to add one.
Now there shouldn´t be any C99 or C++11 code anymore.
Yayy! :) C++98 is simpler!
Finalspace
Good news people, i am switching to C99. I got sick of all the namespace typing nonsense.
oo wow you really went down the rabbit hole. Namespaces are probably my least favorite feature of C++. But how can you survive without function overloading? Probably don't need it for your library, but function overloading was always my favorite feature of C++ (and wish it were available in C, along with operator overloading).
Anyways, just stopping by! Read the entire thread. Fun to see the progress :) Been following along with your commits on github for quite some time.
Haha yeah i know, it was some adventure switching from back and fort but now its settled.
C99 seems to be the best choice so far and i like it much more.
But yeah i really miss function overloading and i miss enum class too :-(
Update:
1.)
I tried to make FPL "compilable" without the C-Runtime Library on Win32 and succeeded, but it requires a bit more work to get console output and string formatting working. So i am planning to write a replacement for vsnprintf() myself and will use the win32 console api to replace fprintf() and vfprint().
The code for is not in GIT yet, but will be commited very soon.
Disabling CRT will be fully optional and i expect that someone which wants to disable it knows what he is doing.
2.)
Linux/X11/GLX support works great so far, even on my crappy wayland ubuntu - but its still not complete yet.
Stuff i need to implement:
- fplListFilesBegin, fplListFilesNext, fplListFilesEnd (Files/Dirs traversal)
- fplUpdateGameControllers (Joystick/Gamepad input)
- fplSetWindowCursorEnabled (Cursor show/hide)
- fplIsWindowResizable, fplSetWindowResizeable (Window style)
- fplIsWindowFullscreen, fplSetWindowFullscreen (Fullscreen support)
- fplGetClipboardAnsiText, fplGetClipboardWideText, fplSetClipboardAnsiText,fplSetClipboardWideText (Clipboard)
- fplGetSystemMemoryInfos (Memory usage)
- ALSA Audio Driver
- X11 Video Software Driver
Not that much really, but i expect joystick input and fullscreen to be the hardest part.
3.) Merging it to master branch will come very soon as well. I need to update the project descriptions everywhere (Its not C++ anymore)
4.)
I created a project for handmade network (Still awaiting approvement).
5.)
I got webspace and a domain and will host the library on this site as well, including the documentation.
It will be released properly when i got my ass up to write a proper webpage ;)
6.)
And lastly i am planing to make a few tutorial videos how to use FPL on youtube, but this requires a few preparements.
This evening i have plenty of time, so i may nail down everything on the list hopefully today ;)
I need to buy snacks for this evening... (hopefully my kids wont snap it away before i eat it)
1.)
I tried to make FPL "compilable" without the C-Runtime Library on Win32 and succeeded, but it requires a bit more work to get console output and string formatting working. So i am planning to write a replacement for vsnprintf() myself and will use the win32 console api to replace fprintf() and vfprint().
The code for is not in GIT yet, but will be commited very soon.
Disabling CRT will be fully optional and i expect that someone which wants to disable it knows what he is doing.
2.)
Linux/X11/GLX support works great so far, even on my crappy wayland ubuntu - but its still not complete yet.
Stuff i need to implement:
- fplListFilesBegin, fplListFilesNext, fplListFilesEnd (Files/Dirs traversal)
- fplUpdateGameControllers (Joystick/Gamepad input)
- fplSetWindowCursorEnabled (Cursor show/hide)
- fplIsWindowResizable, fplSetWindowResizeable (Window style)
- fplIsWindowFullscreen, fplSetWindowFullscreen (Fullscreen support)
- fplGetClipboardAnsiText, fplGetClipboardWideText, fplSetClipboardAnsiText,fplSetClipboardWideText (Clipboard)
- fplGetSystemMemoryInfos (Memory usage)
- ALSA Audio Driver
- X11 Video Software Driver
Not that much really, but i expect joystick input and fullscreen to be the hardest part.
3.) Merging it to master branch will come very soon as well. I need to update the project descriptions everywhere (Its not C++ anymore)
4.)
I created a project for handmade network (Still awaiting approvement).
5.)
I got webspace and a domain and will host the library on this site as well, including the documentation.
It will be released properly when i got my ass up to write a proper webpage ;)
6.)
And lastly i am planing to make a few tutorial videos how to use FPL on youtube, but this requires a few preparements.
This evening i have plenty of time, so i may nail down everything on the list hopefully today ;)
I need to buy snacks for this evening... (hopefully my kids wont snap it away before i eat it)
Edited by Finalspace
on
Short Update
I decided to let the user provide a vsnprintf alternative when CRT is disabled.
For win32 i got console output/input working without using CRT -> ReadConsoleA, WriteConsoleA.
But the linux implementation is still incomplete and require a lot of work to finish it.
Also i will update all the descriptions of my announcements (C99 instead of C++) today.
And finally i merged the x11linux branch into the master branch and removed the deprecated .hpp file.
I decided to let the user provide a vsnprintf alternative when CRT is disabled.
For win32 i got console output/input working without using CRT -> ReadConsoleA, WriteConsoleA.
But the linux implementation is still incomplete and require a lot of work to finish it.
Also i will update all the descriptions of my announcements (C99 instead of C++) today.
And finally i merged the x11linux branch into the master branch and removed the deprecated .hpp file.
Please do not use ReadConsole and WriteConsole for stdin/out on Windows. Those cannot be redirected to file. For example, if I would want to run your program like this: "app.exe >log.txt", the log.txt file would be empty.
Use regular ReadFile/WriteFile instead.
Use regular ReadFile/WriteFile instead.
Edited by Mārtiņš Možeiko
on
mmozeiko
Please do not use ReadConsole and WriteConsole for stdin/out on Windows. Those cannot be redirected to file. For example, if I would want to run your program like this: "app.exe >log.txt", the log.txt file would be empty.
Use regular ReadFile/WriteFile instead.
Good Point thanks! I will change that.
Edited by Finalspace
on
Small Release
## v0.7.1.0 beta:
- Changed: fplConsoleFormatOut/fplConsoleFormatError is now common_api instead of platform_api
- Changed: FPL uses a keyMap for mapping OS key codes to fplKey for every platform
- Changed: [Win32] Console does not cache the output/input/error handles
- Changed: [Win32] fplConsole* uses ReadFile/WriteFile instead of ReadConsole/WriteConsole
- Changed: BSD Platform is detected as a Unix Platform, but has its own subplatform as well
- Fixed: [Win32] Console was always allocated
- Fixed: No CRT stub defintions such as memset and RTC was added for all compilers which is wrong
- Fixed: Several bugfixes
- New: Added stubs for Unix Platform
*Note: Release is tagged as 0.7.1.0
## v0.7.1.0 beta:
- Changed: fplConsoleFormatOut/fplConsoleFormatError is now common_api instead of platform_api
- Changed: FPL uses a keyMap for mapping OS key codes to fplKey for every platform
- Changed: [Win32] Console does not cache the output/input/error handles
- Changed: [Win32] fplConsole* uses ReadFile/WriteFile instead of ReadConsole/WriteConsole
- Changed: BSD Platform is detected as a Unix Platform, but has its own subplatform as well
- Fixed: [Win32] Console was always allocated
- Fixed: No CRT stub defintions such as memset and RTC was added for all compilers which is wrong
- Fixed: Several bugfixes
- New: Added stubs for Unix Platform
*Note: Release is tagged as 0.7.1.0
Edited by Finalspace
on
Webpage for FPL
Right now i am working on a webpage which will be used to host the full api documentation and a additional mirror for the source -> A simple pure HTML5 layout took me two evenings, due to crap of HTML5/CSS nonsense! Really i am so happy that i left the web development shit behind...
Anyway after i finished the layout i will launch it very soon.
Right now i am working on a webpage which will be used to host the full api documentation and a additional mirror for the source -> A simple pure HTML5 layout took me two evenings, due to crap of HTML5/CSS nonsense! Really i am so happy that i left the web development shit behind...
Anyway after i finished the layout i will launch it very soon.
Edited by Finalspace
on