blitzmax on linux

Archives Forums/Linux Discussion/blitzmax on linux

yossi(Posted 2014) [#1]
after a lot of work I succeed to make blitz max to work with my Linux(mint 15 64 bit) but still it wasn't perfect because on full screen mode
the computer was crashed when exiting programs and games I tested.

I tried to install native drivers of NVidia and it totally killed my Linux.

now I should reinstall Linux but I would like to install distribution that automatically live in pease with blitzmax.

what Linux distribution is recommended for blitz max so it works immediate without extra work ?


dawlane(Posted 2014) [#2]
after a lot of work I succeed to make blitz max to work with my Linux(mint 15 64 bit)
Is no longer supported. Use Linux Mint 13 or 16 64bit, Ubuntu 12.04 (until April) or 13.10, Debian 7.

And read http://www.blitzbasic.com/Community/posts.php?topic=101454. For easy install. The script will get updated just after April.

I tried to install native drivers of NVidia and it totally killed my Linux.
The ones direct from nvida? Read this http://www.blitzbasic.com/Community/post.php?topic=101454&post=1214685

I would like to install distribution that automatically live in pease with blitzmax.
It doesn't matter what the distribution is BlitzMax will have problems.

what Linux distribution is recommended for blitz max so it works immediate without extra work ?
Any listed in the first post or those that are based off of any in those listed. But any that are based off of the main three can be hit and miss.


John G(Posted 2014) [#3]
NoLinuxHere. I very briefly tried installing (USB stick) 4 Ubuntu versions with no luck. Didn't even try BlitzMax! I wonder if it would make sense to focus on SteamOS for BM Games? 2 cents...


Brucey(Posted 2014) [#4]
But any that are based off of the main three can be hit and miss.

I've never had many problems using any Linux distro - once you get the libraries installed, it generally works okay.
Graphics drivers is another thing entirely though, and as I don't use BlitzMax for games, that hasn't really been an issue for me either.


yossi(Posted 2014) [#5]
hello Brucey.

you say you don't use blitzmax for games and i thought that the advantage of blitzmax compare to other options is on games.

i can understand that blitzmax can capable for more then games but why bother.

don't you have more options on other languages like java and c# for non game applications (i mean more libraries options for databases,gui,communications,web,xml and so on...).

what the reason to choose blitz max to non game application ?


Brucey(Posted 2014) [#6]
what the reason to choose blitz max to non game application ?

Because I like the language. It's fun and flexible, and is quick to create working prototypes and applications with.

i mean more libraries options for databases,gui,communications,web,xml and so on...

Sure, if you are using the core of BlitzMax there's only a limited choice of functionality, but BlitzMax is insanely easy to create modules for, so I basically have access to any 3rd-party libraries I want.

BlitzMax is just a programming language, and one which I enjoy using.
For my "day job" I use Java, C/C++, VB, Informix 4GL, and others, but I get most enjoyment from Blitz'esque languages.


dawlane(Posted 2014) [#7]
@Brucey:
But any that are based off of the main three can be hit and miss.
By that I mean, "just works out of the box" experience that we have come to know and love with Linux. You know just for an example, application-X needs the PulseAudio sound system to be installed, but PulseAudio is not installed as default, or not available on that distribution yet, or has to be built from source, or is broken in some way, or just doesn't work correctly. Some one who has never used any thing other than the base distributions like Ubuntu wouldn't know that Lubuntu 13.10 doesn't have the PulseAudio sound server installed as default. Or (the last time I looked) that libxpm on Arch Linux isn't in the default repositories and you have to get them from the AUR and build them yourself. But then if some can install Arch Linux from scratch, then that's not too big an issue.

If a developer is only familiar with one distribution like Ubuntu and not with the Linux world at large and is selling has wares expecting it to just work on Linux. Then they are just asking for trouble. Even applications built with a ubuntu distribution are not guaranteed to work on Debian (GLIBC version issues).

Just to get BlitzMax to work on some distributions I've had to do some research on how to get round problems. And a lot more if it was a 64bit distribution.


yossi(Posted 2014) [#8]
i followed the orders and also needed to add import "-ldl" (found it someware) and it seems to work fine but i still have a problem with the sound even though i ran patch.sh and it seemed to run well.

how can i solve the sound problem ?


dawlane(Posted 2014) [#9]
Which version of BlitzMax? What version of Linux and has it had the latest updates applied. The script has only been tested on version BlitzMax 1.48 and for it to work the modules need to be rebuilt as it say in at the bottom of the post.


skidracer(Posted 2014) [#10]
Yossi, Linux is a huge <pointless> diversion.

Your first goal with BlitzMax should be to finish and release a working piece of software on a reliable platform that 99% of other people use.


yossi(Posted 2014) [#11]
I made a mistake and tried to work with 1.50 version of blitz max.
on 1.48 it works nicely including sound and import "-ldl" is not needed.
on 1.50 it works but without sound and import "-ldl" is needed.

I want to thank very much to all of you.
without you I couldn't make blitz max to work on my Linux side.

hello skidracer,
I agree that most of the users on client side use windows and happy with it.
I agree that the main word of game developing is windows using direct x.

BUT!

the nature of blitz max is multiplatform so why not using it and try to
distribute your staff to other platforms as well.
why to neglect Linux users (to use Linux is legitimate like every other OS).

my only problem is with mac (I will never buy a mac just for blitzmax).
if os x would run legitimate on pc computers like windows and Linux i would probably willing to buy it but to buy a new mac computer only for using mac os x is not justified in my point of you.
apple made a mistake when they move to intel platform but sill continue to ship os x only with their computers which are usually more expensive and less powerful and the options of their hardware staff is limited.


Derron(Posted 2014) [#12]
I did not check 1.50 yet ... but shouldn't there be NO changes to the "gets-patched"-code? Just MaxGUI and the BCC got changed a bit.

Think Brucey already did a diff-check on the sources (he said no changes were done in that parts - see the 1.50-release thread)


bye
Ron


dawlane(Posted 2014) [#13]
There has been no change to the files apart from file line endings. BlitzMax 148 is using DOS style line endings while BlitzMax 150 is using Linux style line endings. Don't know why yet, but the patch is the screwing the files up.


Brucey(Posted 2014) [#14]
Don't know why yet, but the patch ...

Which patch is that?

Linux is a huge <pointless> diversion.

Shouldn't all 3 supported platforms be first-class citizens? Rather than saying, "well we noticed it was there, so gave you a build option for it, but otherwise, you're on your own" ?


degac(Posted 2014) [#15]
@John G
you are right. SteamOS (always Linux...) IS interesting.
Valve is a bigger player, and the game has already started...


dawlane(Posted 2014) [#16]
Which patch is that?
The patch script I wrote. Second script here. That fixes the sound with skids fixes and sorts out the libdl problem. Works flawlessly on 1.48, but not on 1.50.

Edit: After converting 1.50 files to use DOS line endings the patch file works fine. Looks like the insertion function isn't working with Linux file line endings. Or it could be when the file is loaded and line endings are not being detected correctly when set to the array which is more likely. I will have to rewrite that bit to use readline instead.


Derron(Posted 2014) [#17]
All in all it sounds as if Mark moved from Windows to Mac (I somehow doubt that he moved to Linux as we would then have better support for current distros) ... if saved natively line endings of Mac are still CR ? Or dit they switch to LF like linux uses it?


I just saw you are using:
# Load a file into
load_file(){
		IFS=$'\n' FILE_ARRAY=( $( < "$1" ) )
		FILE_LEN=( ${#FILE_ARRAY[*]} )
		return $?;
}


There you declare to split on "\n" which might be generating the trouble.
You could call "read line" - maybe that takes care of line endings already.
Another option is to check the returned line count ... if it is <=1 you may have used the wrong line-ending and should try another one (\r\n, \r, \n).


bye
Ron


dawlane(Posted 2014) [#18]
\r\n, \r, \n
Tried all of that.
The method above is excluding the new-line code. So when it comes across a line that is just a new-line escape sequence. It doesn't add it to the array. Which messes up insertion. I could go for the readarray which should be built into bash.

# Load a file into
load_file(){
		readarray FILE_ARRAY < "$1"
		FILE_LEN=( ${#FILE_ARRAY[*]} )
		return $?;
}

I will have to see if it works.


dawlane(Posted 2014) [#19]
OK. Looks like I have a new patch that should work on both 1.48 and 1.50.