I did a search but I can't see an up-to-date mention of running GLB compiled apps on Linux. I am fairly sure I have every SDL lib under the sun installed on my Kubuntu 14.04 system but I get the old SDL error messages:
Can't init SDL.no input method could be opened
timer
rbow
rbow init
VSync unsupported on old SDL versions (before 1.2.10).
SDL_init video
SDL_GetVideoInfo = 2560x1024 @ 32 bpp. Screen 640x480
Requested SDL_OPENGL = 2
Requested double buffer
set up SDL for OpenGL mode
Setting video mode: 640x480x24 fl=2
SetVideoMode failed: Couldn't find matching GLX visual
INIT: Unable to create BPP -> trying 16.
Couldn't set GL mode: Couldn't find matching GLX visual
Segmentation fault (core dumped)
Am I missing something? I have installed everything mentioned in the manual and that I could see mentioned in these forums. :giveup:
Edit: I am primarily compiling for GP2X (which is fine - presumably because the libs are the same as they have been for ages now) at the moment but I will need some desktop running ability in the future.
Did you try to check the dependencies (command: ldd)?
The result:
paul@CodeBear:~/GLBasic/Linux/XPlatTest1$ ldd xplattest1.linux
linux-gate.so.1 => (0xb7770000)
libGL.so.1 => /usr/lib/nvidia-304-updates/libGL.so.1 (0xb766a000)
libSDL_mixer-1.2.so.0 => /usr/lib/i386-linux-gnu/libSDL_mixer-1.2.so.0 (0xb7618000)
libSDL-1.2.so.0 => /usr/lib/i386-linux-gnu/libSDL-1.2.so.0 (0xb757f000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7539000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb738a000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7385000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7369000)
libnvidia-tls.so.304.117 => /usr/lib/nvidia-304-updates/tls/libnvidia-tls.so.304.117 (0xb7364000)
libnvidia-glcore.so.304.117 => /usr/lib/nvidia-304-updates/libnvidia-glcore.so.304.117 (0xb565e000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb552a000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb5517000)
libmikmod.so.2 => /usr/lib/i386-linux-gnu/libmikmod.so.2 (0xb54d6000)
libfluidsynth.so.1 => /usr/lib/i386-linux-gnu/libfluidsynth.so.1 (0xb5400000)
libvorbisfile.so.3 => /usr/lib/i386-linux-gnu/libvorbisfile.so.3 (0xb53f6000)
libFLAC.so.8 => /usr/lib/i386-linux-gnu/libFLAC.so.8 (0xb53c2000)
libmad.so.0 => /usr/lib/i386-linux-gnu/libmad.so.0 (0xb53aa000)
libasound.so.2 => /usr/lib/i386-linux-gnu/libasound.so.2 (0xb52b4000)
libpulse-simple.so.0 => /usr/lib/i386-linux-gnu/libpulse-simple.so.0 (0xb52ae000)
libpulse.so.0 => /usr/lib/i386-linux-gnu/libpulse.so.0 (0xb525f000)
libcaca.so.0 => /usr/lib/i386-linux-gnu/libcaca.so.0 (0xb5193000)
/lib/ld-linux.so.2 (0xb7771000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb5171000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb5065000)
libjack.so.0 => /usr/lib/i386-linux-gnu/libjack.so.0 (0xb5012000)
libsndfile.so.1 => /usr/lib/i386-linux-gnu/libsndfile.so.1 (0xb4fa0000)
libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb4f55000)
libreadline.so.6 => /lib/i386-linux-gnu/libreadline.so.6 (0xb4f17000)
libvorbis.so.0 => /usr/lib/i386-linux-gnu/libvorbis.so.0 (0xb4eeb000)
libogg.so.0 => /usr/lib/i386-linux-gnu/libogg.so.0 (0xb4ee1000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb4ed8000)
libpulsecommon-4.0.so => /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-4.0.so (0xb4e69000)
libjson-c.so.2 => /lib/i386-linux-gnu/libjson-c.so.2 (0xb4e5e000)
libslang.so.2 => /lib/i386-linux-gnu/libslang.so.2 (0xb4d2e000)
libncursesw.so.5 => /lib/i386-linux-gnu/libncursesw.so.5 (0xb4cf7000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb4cd5000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb4cbb000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb4cb7000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb4caf000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb4c71000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb4b88000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb4b6b000)
libvorbisenc.so.2 => /usr/lib/i386-linux-gnu/libvorbisenc.so.2 (0xb49f3000)
libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb49e8000)
libasyncns.so.0 => /usr/lib/i386-linux-gnu/libasyncns.so.0 (0xb49e1000)
libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0xb49c8000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb49b0000)
Does this offer any clues?
Thank you.
No, seems to be fine, at least I can see no unsolved dependency.
Do you use a 32bit or 64bit linux? Im not 100% sure, but I think 64bit did not work properly with GLBasic.
Some graphicscards and OS does not like 640x480 resolution. Have you tried to uses a windowed mode rather than fullscreen, or try to set a higher resolution?
Are you using an emulator for Linux ?
No - desktop linux is my main system on most of my PCs.
I will try what spacefractal said to see if it works.
Its usually a display problem - a GLBasic wants either 32 or 16 bit display. Yours isn't allowing that or is fixed to either 24 or 8 bit display.
I presume you can run glxgears ? There was a command that can display what resolutions and BPP's are available, but I cant remember what it is.
glxgears is fine, yes. I remember this problem in the past now with some games and the solution was usually to set the config for specific resolutions and bitdepths.
Is there a way to specify bitdepth in GLB?
Between this problem and some disheartening chat on the GP2X forums I think I am on a losing streak for cross-platform utopia. Perhaps I will have to look at desktops as my target and and pygame or similar as my dev kit. I think I missed the boat between discovering the GP2X series platform and GLB and then not having the time I had hoped to use them and now having a lot of time on my hands. :giveup:
My ideas are still good and I am enthusiastic about them but the indie dev scene seems to have shifted a lot in the past couple of years.
Sorry to be a downer - reality is biting the past couple of days >:D
Quote from: HamishTPB on 2014-May-23
...some disheartening chat on the GP2X forums...
Don´t bother that, my game goes fine on Caanoo and therefore probably fine on Pandora, we have both users around here if test is needed.
Some forums have strong fan boys, not worth letting them getting on your plans. :good:
I still have enthusiasm for the game ideas I have but I am not sure about which IDE / language is best for me now. I can't see a faster and easier way to dev for GP2X/Pandora targets though. I have started looking at the other cross platform tools but they are all either very pricey (like Unity) or don't support the platforms I want. I know GLB nominally supports Linux but if I have hassle getting stuff to work then "normal users" just won't bother with my games. If the GLB compiler worked under wine as well as the editor then I would be happy to use GLB for the handhelds and maybe PyGame for the desktops but having to have a windows system for compiling is a total pain. I think there just isn't an ideal solution, GLB could have been if I had time when I first discovered it but some of the SDL stuff is out of date and causing problems. It is a real pity but I can only imagine the vast amount of work needed to keep something like this truly cross-platform over time.
EDIT: Of course I realise the OS and libs on GP2X platform series is still the same so GLB has no out of date problem there.
I will sleep on things and regroup tomorrow. I just don't want to start on a project then have to switch dev kits / language etc to achieve things later. :bed:
Quote from: HamishTPB on 2014-May-23
...
I will sleep on things and regroup tomorrow. I just don't want to start on a project then have to switch dev kits / language etc to achieve things later. :bed:
This you definitely don´t wanna do.
Keep in mind every dev kit comes with its troubles, including the more expensive (though they have more money to hide it :D).
The more you know, the more you can do around on dev kits that allow you to do so.
Some communities would have just said "fine, bye" - not you guys. :-[
Thanks for the encouragement and counter-balancing the other stuff :)
You are right, of course, GLB *is* the right tool for the job I actually want to do, I got waylaid and distracted by discussions with people with different needs and desires from myself.
EDIT: Not having a computer shop any more means not having virtually unlimited upgrades and spare parts. Back after computer breakdowns and salvage and rebuild operations.
:offtopic:
Back on to the original topic - even on totally different PC with different distro I have the same issue. Now that i think about it more I seem to recall it is an issue with NVIDIA drivers and SDL around the bit depths. I will need to try on my laptop (pretty sure that has Intel GFX). Nvidia hate me.
You do usually need proper drivers - the default used by Linux usually dont always work well.
Yeah - this is the proper NVIDIA drivers, going to put this issue to one side for now. :shit:
As long as things run on the handheld and android targets that's fine for now and I have a windows computer with GLB / JAVA /Android SDK etc installed for the coding/compiling. :whip:
Quote from: erico on 2014-May-23
Quote from: HamishTPB on 2014-May-23
...some disheartening chat on the GP2X forums...
Don´t bother that, my game goes fine on Caanoo and therefore probably fine on Pandora, we have both users around here if test is needed.
Some forums have strong fan boys, not worth letting them getting on your plans. :good:
Erm... That "fanboy" was me. And I was speaking as a realist, not as a fanboy. The GP2X machines are excellent, but getting on a bit now and the GP32X.com community has all but disappeared - there are still loyal supporters, but they rarely post on GP32X.com now. Pandora still has really strong support and will continue for another year or so. The Pyra arrives next year (the successor to the Pandora), which *should* be backwards compatible with Pandora and a hell of a lot faster, so that will be a great target.
I love the Caanoo and wouldn't hesitate for a nano-second to recommend it.
I would also recommend coding in GLB for the Caanoo (and the other machines of course, but the Caanoo is the best of the bunch - shame your is borked). Unless you have a Pandora of course (although some games run better on Caanoo than Pandora as the extra screen real-estate slows down rendering).
Anyway, I highly recommend handhelds - they will help you to learn optimising techniques, require less graphical work as the screen are smaller and offer full control of your game, unlike touchscreen only mobile devices. GP2X etc. Users are also far more tolerant of amateur artwork and they understand that the game was created for the love, not the money.
Want to get a Pandora when I can afford one, maybe the second hand market will be a bit cheaper when the Pyra is out. I am supposed to be getting a new board for my caanoo within a couple of weeks from ED :nw:
I admit my poor wee GP2X will wonder why it isn't getting much love after the caanoo is back :-)
For now back into Nicholas' GLB books and get some work done!
EDIT: Your comments have been greatly received (as have everyone's here and on GP32X.COM) and I think my past experience with 8 and 16 bit computers and the limited resources and resolutions is one of the reasons I am keen to try coding for the handhelds.
Thanks again chaps!
Haha I diden´t mean you to be a fan boy Ian , :D
It took me a while to read things on other posted forums.
What I actually meant for Fan boy, is pretty much the way it sometimes happen on the pandora forum, you ask for something and get a disheartenning response in return, you offer something or an idea and you get pitch forked. I got my shares of let down there but I really don´t care.
I agree with your views of the gp2x and pandora community and with the path for android.
While I´m targeting desktops and android, I´d like to keep it gp2x and pandora compatible but there will be times and projects that just won´t workout that way.
It would be nice if there was a simple handheld (like the caanoo) with an on going hardware production and a medium community to boot.
QuoteIt would be nice if there was a simple handheld (like the caanoo) with an on going hardware production and a medium community to boot.
Now that would be ace. If only SONY opened up the PS Vita to real homebrew...
Quote from: Ian Price on 2014-May-25
...
Now that would be ace. If only SONY opened up the PS Vita to real homebrew...
Exactly what I thought, Sony and Nintendo are the only players on that market nowadays, would be cool if any or both would actually open up.