BlitzMax life expectancy?
BlitzMax Forums/BlitzMax Programming/BlitzMax life expectancy?
| ||
| Hi, My question primarily goes to BRL about how long BlitzMax as a product is expected to live. (Estimates about B3D and B+ are secondary but still interesting.) Why I ask is because the Blitz3D-SDK was suddenly discontinued as a product, without previous notice (afaik at least). Now the Blitz3D-SDK thing is no biggie from my point of view as I didn't use that very much anyways, but the handling of that product raises a little concern about what we can expect from BRL when it comes to other products. What I look for here is some kind of reassuring message that BRL will announce ahead of time before they stop providing their products, so that we, your customers, can adjust our work/plans accordingly. Please don't take this as critique for things in the past but rather as a possible point of new direction for the future. Best regards, Mattias Hansson |
| ||
| I don't think Blitzmax will ever just 'stop working' one day. The only issue might be one of progression of DirectX, but even if that goes pear-shaped there's still OpenGL. The product is, in terms of Win/MacOS/Linux flexible enough to survive by itself. Blitz3D was probably abandoned (was it?) because there are already several much better options available that BB3DSDK could never [or at least, not for a long time] compete with; MiniB3D, Ogre, Irrlicht, TV3D, Leadwerks to name but a handful. You might also read this: http://marksibly.blogspot.com/2010_08_01_archive.html |
| ||
| i hope some of these improvements make it to blitzmax too (overloading and private) |
| ||
| Considering that Blitz3d and BlitzPlus are still 'living' products I dont' see any valid reason to see an early death for BlitzMax. BMX2 (or whatever will be its name) is not considered as a replace of Bmx, just another language-rapid kit targeted to mobile computing and mainly for 2d. And we don't know if and how BMX2 could be expanded as Bmax with modules or wrapper for other libraries. Blitz3dSDK is an anomaly: it was released as an SDK too late (in my opinion) when on the market there are more modern (=shaders and shadows) engines than Blitz3d... |
| ||
| B3D-SDK was a bit of an odd one out -- the only reason it was created in the first place was a bunch of people who very vocally kept asking for it... But it had some functional shortcomings ( e.g. with the sound implementation) that were causing headaches for people. It was mostly a wrap of a subset of B3D into a library form so it could be used with other languages. Blitzmax, on the other hand, was written from the ground up and has been actively receiving many updates over the years. Of course you *never* have a guarantee that it won't be dropped or replaced by something different, but B3D and Blitzplus have both received a good number of bugfix updates since Blitzmax was released... |
| ||
| Given that BlitzMax comes with the majority of its own source code (eg: all the modules) and that it links to c/c++ code, it's hard to imagine that it could ever be made obsolete, regardless of what BRL did or did not do. If the FreeAudio module stopped working, someone would rewrite it, or fix it, or make a brand new one. |
| ||
| B3D-SDK was a bit of an odd one out Not really, remember Max3D? Anyway, that is little consolation to those who shelled out for B3D-SDK. |
| ||
| As Gabriel pointed out, with the source, even if DX issues arise in the future, you can easily write your own rendering routines as several users have done already. The only issue that will kill BlitzMax in the future is when Microsoft stops supporting 32-bit software under Windows. Even if MS does not release a 32-bit version of future versions of Windows and even if MS removes 32-bit emulation from future versions of Windows, XP mode will still be around in the future for another couple of Windows versions and will allow legacy 32-bit software to still be run. This is really a moot point, as the real question is will there even be a demand for the 32-bit software you write with BM in a couple of years? And for now, that is a game of wait and see. |
| ||
| True, although I don't really see MS yanking 32-bit compatibility away: There is a LOT of 32-bit software out there, and at this point the majority of NEW software released is also still 32 bit. |
| ||
| Unfortunately, other that a handful of netbooks, systems are not shipping with 32-bit CPUs. Windows does not have to lose compatibility (WOW64) to lose a 32-bit version. Windows 8 should only have a 64-bit version (leaving WOW64 in for compatibility) as by the time it hits there should not be any 64-bit systems being sold at all. Unfortunately, Windows 8 will have a 32-bit version because it is based on the hardware available at the time of its development. Once you see MS do what is right and only release a 64-bit version of Windows (leaving WOW64 in for compatibility) you will see developers recompiling their software and releasing 64-bit versions just as they did when Windows 95 hit. 16-bit software disappeared and was replaced very quickly. Even though 16-bit versions of Windows died with Windows 95, look how long WOW provided 16-bit compatibility. Although Windows 8 will hopefully be the last 32-bit version of Windows, 32-bit compatibility will be here for a long time in the form of WOW64 and XP Mode. Your BMax programs are safe for a long time ;) |
| ||
| As Gabriel pointed out, with the source, even if DX issues arise in the future, you can easily write your own rendering routines as several users have done already. You say easy, but surely many customers of this type of product bought it precisely because they don't have the skill or inclination to write such an engine themselves. Relying on some random user to provide bug fixes is hardly what you sign up for when you purchase a product. |
| ||
| but surely many customers of this type of product bought it precisely because they don't have the skill or inclination to write such an engine themselves. Many bought BM because the source was provided so users could tweak it to meet their needs. What you describe is the reasons why people buy closed-source products like Blitz3D or Blitz Plus. Relying on some random user to provide bug fixes is hardly what you sign up for when you purchase a product. Why rely on a random user? Do it yourself if you need it! This is one of the main reasons you buy a product that comes with the source code.Perhaps you would prefer that BM was closed source and you could not expand it and maintain it if BRL decided to drop support for it in the future? |
| ||
| Sounds very good indeed. I've read very little about it so far but will it support 64 bit? Even though 16-bit versions of Windows died with Windows 95, look how long WOW provided 16-bit compatibility. Although Windows 8 will hopefully be the last 32-bit version of Windows, 32-bit compatibility will be here for a long time in the form of WOW64 and XP Mode. Your BMax programs are safe for a long time ;) While I agree that most 16 bit programs ran for very long with MS excellent backwards compatibility, almost no developers wrote any more 16-bit code once Win95/NT4 hit the market. Win95/NT4 was the era when early Pentiums came (60, 66 and 75) och by then 2 generations of CPUs (386, 486) had supported 32-bit code. I expect that in a quite near future when all computers sold are chewing 64-bit code, there will soon be a massive migration of developers over to the 64-bit camp. |
| ||
| I've read very little about it so far but will it support 64 bit? It does not compile programs, wouldn't that largely depend on the capabilities of your target compiler and platform? While I agree that most 16 bit programs ran for very long with MS excellent backwards compatibility, almost no developers wrote any more 16-bit code once Win95/NT4 hit the market. Because there was no need or market for it. You have reaffirmed my point. Once 64-bit hits, 32-bit software will disappear just as quickly (although you will be able to run existing 32-bit software for many years). |
| ||
| I'd like to post to "en-rail" this thread a little again, since it derailed a little (with my help too) to a discussion about how far the users of BMX could hold BMX alive with CPR after BRL stopped the respirator. :-) My original question was more in the lines of this: Can we as BMX customers trust that BRL will announce the end-of-life in good time before dropping support for it? (because that's not exactly what they did with Blitz3DSDK.) What happened back when BlitzBasic (yes the one before B3D and B+) stopped? Did BRL say ahead of time that BB support would stop within 1-2 years to give customers good time to transfer and start new projects on new platforms? Or did they just tell people retroactively that BB was dead? |
| ||
| From reading the old forums, BRL had little say in the demise of Blitz BASIC as that was caused by Idigicon. BRL quit supporting it since they were not selling it (Idigicon was) or getting any money from it. |
| ||
| I thought 64-bits operating systems have been out for a while. I remember when I used to write my code in c and assembly how limited it was to do a simple program and how many tricks I had to do to get what I wanted my code to do. When the 32-bit came out it was an instantaneous success. I went and bought Watcom c & ASM so that I wouldn't have to deal with the limited set of instructions any more and never looked back. The Thing dough is that I don't find myself with the need to move up to program in 64-bit. 32-bit suffices all my needs and I think that is what keeps most every body else from wanting to move to 64 bit. I do think that 64-bit is the future but I can see a very slow migration sense a lot of money have been invested in current applications and if they are serving the needs why switch. I suspect that 32-bit system are going to be here for a long time still. I don't see the same motivations from the public to move from 32-bits to 64-bits as from 16-bit to 32-bit processing. |
| ||
| I thought 64-bits operating systems have been out for a while. They have been -- but it hasn't been until this year or so that it accounts for a majority share of new computers being sold. (If you look at the big box stores like best buy, or even walmart, you'll find that the 'typical' computer now comes with Windows 7 64 bit, although there are still plenty of 32 bit systems for sale as well) 16 bit code continued to work under 'modern' Windows versions until the switch to 64 bit -- which has been close to 15 years since 32 bit windows came out. Blitzmax creates 32 bit binaries, which work without problem under both 32 and 64 bit windows. 32 bit is likely going to be around for quite a while, simply because there appears to be much less of a need for 128 bit than there was for 64: a 32 bit computer can only access up to 4GB RAM (which is common now), but 64 bit can access up to 16 exabyte (16 billion gigabyte)... I seriously doubt we'll need to break that barrier in the next decade... And with the *enormous* amounts of 32 bit software in active use, I seriously doubt that Microsoft will remove 32-bit compatibility from 64 bit windows in the near future either... |
| ||
| Are you sure? According to projections, even Windows Notepad will require 10 billion gigabytes by the year 2020. |
| ||
| I've read very little about it so far but will it support 64 bit? I expect so. I can't speak for Windows, but 64-bit Mac support is a non-issue. |
| ||
| Perhaps you would prefer that BM was closed source and you could not expand it and maintain it if BRL decided to drop support for it in the future? You do talk some tosh. Sure, open-source is a big plus point, but if I equated 'open-source' with 'the developer will drop it without notice' for a paid product, I would steer well clear. |
| ||
| Why rely on a random user? Do it yourself if you need it! This is one of the main reasons you buy a product that comes with the source code. How is tweating the BlitzMax standard modules source code going to give 64-bit capability to the compiler for which we DON'T have the source code? |
| ||
| How is tweating the BlitzMax standard modules source code going to give 64-bit capability to the compiler for which we DON'T have the source code? Unfortunately, that has nothing to do with my quote which was discussing bug fixes and new rendering APIs. |
| ||
| The SDK was a strange situation, cos if you remember Mark hadnt really wanted to do it, and was talked into it. And I get the feeling that he felt it was as "as is" product and recented time it was taking him from other products. It would be nice for a "time table" of Bmax lifetime, but I dont see it being discontinued asap. Bet updates stop the week after a manual lol A re-availability of the SDK source would be nice tho ;) |
| ||
| Mark is a genius and he's developing the new Blitzmax2 which I'm sure will be the best games programming language ever. That's because that guy is really passionate about what he does. |
| ||
| byo wrote: Mark is a genius and he's developing the new Blitzmax2 which I'm sure will be the best games programming language ever. That's because that guy is really passionate about what he does. *fanboi warning* :-) Just joking, I agree that Mark is a exceptionally skilled developer, and the fact is that he provides the most professional, fast and stable compilers that I know of for the indie market establishes that fact. But while I'll buy BMX2 as soon as it is available this thread was more of a request to BRL to give us time-tables or end-of-life indications before discontinuing products. |
   |