why did u stop BlitzMax and start on different language?

Started by meems, February 27, 2018, 21:42:51

Previous topic - Next topic

meems

I'm just starting blitzmax. Can't see me ever needing more power+utility for my games than this. 'specially sinced its still being deved by brucey. blitzplus was nearly enough, but not quite. So why have most of the community moved off bmax? u all working on cutting edge doom 4 tier shooters?

therevills

At the moment I'm still using BlitzMax for my major projects.

Most of community has moved away because:
* BRL has dropped supporting the language - no further official fixes or releases
* Vanilla BlitzMax doesn't produce 64bit applications - this will impact MacOS development this year!
* Vanilla BlitzMax "only" targets are Windows, MacOS and Linux (with bugs), some users want more targets (especially mobile targets, Android and iOS)

I still like the language, I prefer the syntax of Monkey2 though...

Steve Elliott

Quote
I prefer the syntax of Monkey2 though.

Oh dear, Monkey 1 was bad, this is plain awful.  You must be the one then...And maybe Adam...The language is a kind of torture.  Like Mark got drunk and decided, yeah that would be cool!!  Except it wasn't.
Win11 64Gb 12th Gen Intel i9 12900K 3.2Ghz Nvidia RTX 3070Ti 8Gb
Win11 16Gb 12th Gen Intel i5 12450H 2Ghz Nvidia RTX 2050 8Gb
Win11  Pro 8Gb Celeron Intel UHD Graphics 600
Win10/Linux Mint 16Gb 4th Gen Intel i5 4570 3.2GHz, Nvidia GeForce GTX 1050 2Gb
macOS 32Gb Apple M2Max
pi5 8Gb
Spectrum Next 2Mb

Qube

Quotewhy did u stop BlitzMax and start on different language?
Pretty much for the same reasons as therevills states.

1.. It got abandoned by Mark / BRL for no good reason at all.
2.. MacOS won't support 32Bit apps from next year and BMax only does 32bit.
3.. Eventually Microsoft will drop 32bit app support too.
4.. No mobile support. Mark doesn't like mobile but it very important to a lot of developers.
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

IanMartin

I'm still using BlitzMax.  It's the best platform for Windows/Steam 2D for me at the moment.
If I move to something else it will most likely be for Android support, HTML-5 Web support, or 3D (which would have to be Unity:/ )
There is also no way to publish a BlitzMax game on Switch/ PS4, etc. so at some point you'll have to use something else for those.

But for 2D games on Windows, BlitzMax is still my favorite.  If there was a version of BlitzMax that did those other things, I'd most likely stay with it forever :)


Platfinity (made with BlitzMax) on Steam:
http://store.steampowered.com/app/365440/Platfinity/

Naughty Alien

..because its left to die by developer and prior to that, updates were never done as they should..in main time, better products came in to sight and are in fact very frequently updated based on community request, which is something what is considered SciFi for BRL...in short, B4X and AGK does job perfectly well and very fast..

iWasAdam

stopped with blitzmax because of 2 things.
1. lack of 64bit
2. something (I never found out what) started to act really weird with internal memory being overwritten. whic was starting to cause untold faults across different apps - in a very strange way.
E.G. when reloading images, the font being used would corrupt!
E.G. when loading 3d stuff. the system would completely crash - not just crash but reboot instantly. so there was no debug opportunity...

monkey 1 - enough said...!!!!!
monkey 2 - superb language, very nice and sweet. but unfinished. The thing I cant get me hard around is I am one of the few people writing apps, games that are being used by others (not just complaining about stuff). I tried and tried and tried to feedback to mark, with code, suggestions, all the nice support I could. Anything I suggested or tinkered with - he rewrote so it broke what I was doing. and in some respects was hostile. not a good place.

Derron

I never came across garbaged bitmapfonts. When reloading images you may loose texture context and need to reconnect. Invalidate your object's image, reassign and it shoult do. Similar could be needed when switching to fullscreen/windowed or changing render paths (DX/OpenGL). Maybe AGK and others handle that automatically. Could be implemented in BlitzMax and other languages too. Emit an event, react to this Event.

I get a bit of the feeling that many of you use AGK now - until they find some individual spots in the engine not working as they want, then things get fixed here and there (with your help narrowing down the bugs of course). But somewhen the product will die too. Or evolution stops and revolution takes place (means "AGK 3"). Same to say about "language + engine" somebody is choosing until the language keeps being supported but the engine lacking more and more developers.

Am still using BlitzMax and am tightly tied to it because my "lifetime game" is written in it - and contains sooo much code that porting is something I would really really want to avoid).

I used Monkey once for a compo project on the monkey forums ... and already encountered some restrictions (ever tried to cross fade streamed music on the webbrowser including the needed volume adjustment for channels?). The biggest thing putting me of (aside of the "TED"-editor) was the case-sensitivity. Without proper IDE-support you will have to remind how to write a command properly. And this also means, you cannot just write code in your text editor of choice - as you do not get the "auto-capitalization" there.

I am using BlitzMax for 15 years or so - and for the time being I used "MaxIDE" only for debugging, it really puts me off. Borked undo, ugly looking color scheme (I know, some of you really like that blueish/teal background - with comments in "yellow" - which has nearly the same contrast than active code lines...), missing IDE features (autofill/codecompletition/...). But while I not have written as much library-stuff as Brucey, I have written enough code in BlitzMax which allows me to rapidly do things when prototyping (as I wrote them, I know how to use them, how to achieve certain stuff). On the other hand certain stuff is just missing in the base installation - but needed for today's expected audio-visual presentation ...shaders and so on.


bye
Ron

meems

interesting replies. For me, lack of html5 would be the deal breaker. Soooo many people just play games on their browser now, and the game i've deving is well suited to browser.

But why bmax lack of 64bit? I don't understand. If blitzmax was written in C and C++, then why can't just find a 64bit C++ compiler and compile the same source code? Or does 32->64bit C code need to be rewritten upside-down?
Derron insists html5 for bmax is not happening, but surely with all the effort by brucey he'll find time at some point in his life just to press F5 on his 64bit C++ compiler and generate a 64bit bmax....

ENAY

I stopped using Blitzmax after two projects, way back in maybe like 2003, maybe even earlier.
As at the time, Blitzmax made for slower and less reliable executables than Blitz3D/Blitz+ and at the time, a lack of any 3D support was a big turn off. I know that in the end Blitzmax changed quite a lot. But I never went back to it, and stayed with Blitz3D/Blitz+ until about 2010 or so since B3D was better and there was actually documentation and support for it unlike BMax which at the time was flakey at best.. I did use Monkey for a month which felt like an even worse version of Blitzmax from 2001.

Since then it's been C++ and Unity only. Mainly Unity though. Unity is everything I wanted Blitzmax 3D to be, and more. Not only that Unity is now industry standard and it uses C# which is also industry standard. I can tinker with stuff in Unity and know that I have real world skills, in and out of gaming since I also have to use C#. Something which I could never say about any of Blitz Research, which sadly had niche markets, or at the very least no transferable skills outside of indie or hobbiest programming. Blitzmax is similiar to C# and unless you want to use the classic old skool syntax of B3D which I did love. Blitzmax is so similiar to C# that you may as well just use that instead.

Henri

Original Bmax was only 32bit and it was never Mark's intention to make it 64bit, probably due to code ties to both assembler and gcc, and because Monkey was on the pipeline. Lot of the original code was written with 32bit world in mind, so some kind of effort was needed to rewrite those parts.

Bmax NG on the other hand is different, that it is using only C-code underneath created by the Transpiler (not sure of the name) originally from Monkey project. It inputs original Bmax code and spits out C. This is then compiled with gcc. Due to this and great effort from Brucey to rewrite the parts in original code, Bmax NG is 64bit, plus with added language features and targets.

I myself am not a game maker (allthough it would be fun to make one at some point), so I'm not familier with the quarks and needs in that area. Bmax NG has the SLD graphics backend so that one is new. I think development of any tool will benefit from people using it, and finding the time to create issues where they find some, and this way make the product better. When I look at Brucey's history, he has been very consistant over the years, and is currently listening and improving as seen on recent updates.

To many of you AGK seems like the perfect next thing (or Unity), and that is fine. You can decide this yourself :-)


-Henri
- Got 01100011 problems, but the bit ain't 00000001

meems

>There is also no way to publish a BlitzMax game on Switch/ PS4, etc. so at some point you'll have to use something else for those.
this hints that one of the languages around here can compile to ps4 & switch. which is it?

meems

@henri interesting post
it leads to a key question :
why did brucey not just migrate to monkey? what was the deal breaker there? What was it about bmax that caused him to stay? If he was too invested in bmax, could he have written a code-converter so that he could port his code to monkey ? That may have been less work than turning bmax into another multiplatform language. -
If mark could have given bmax a multiplat compiler, i expect he would have, but looks like he saw it easier to start again.

i'm considering 3 alternative languages to bmax
a.) cerberus : seems comfy, and should be the one that most closely resembles bmax, but small community.
b.) AGK : but whats it written in? C or java? don't like style . e.g. x:integer. duh, what programmer doesn't shorthand the term integer ? is this the tip of the iceberg wrt agk mentality? might as well write out programs in plain english.
c.) B4X : looks big and strong. but i'd prefer one written in C rather than Java, for more speed!

also, side-question. why did mark ditch monkey ?

iWasAdam


Derron

@ Why Brucey stayed with BlitzMax
Think it is the possibility to work with C-code. Brucey is coding in C and so it paves the way to go with BlitzMax. There are surely other reasons but I think this was one of the main things he once wrote when this was asked that time.

I assume language designers like Mark always see "flaws" in their languages. Flaws in the design. You cannot easily change the language design without breaking existing code. Also BlitzMax was heavily tied to assembler code and the FASM compiler. 64Bit needs other alignments for numbers, things he would have needed to tackle then. Mac/Linux(on PC)/Windows have had very similar abilities, so the lowest common denominator wasn't that low. But going with HTML5 or (that time) very slow mobile devices (or at least low resolution, slower file access...) made things a bit different.
Thinking of android's way of doing, you need a totally rewritten approach to your "app loop" to make it not drain that much battery. Its not "fire render() all the time" but you need to respect the OS's requirements (render during the renderUI loop or so).

Think after X years doing work on a project you always find things which need a whole rework as they were done in a dumb/amateurish/non-future-proof way.


With Unity and other toolkits you can choose between languages - it's the "workflow" (live preview/hot editing) and "modules/libraries" they offer, not the language.

bye
Ron