64-bit Support, Reloaded
BlitzMax Forums/BlitzMax Programming/64-bit Support, Reloaded
| ||
| There was no general section for these kind of things, so I'm going to throw this here since I have become a very keen BlitzMax'er (can you write it like that?). It is relatively clear to most of us that sooner or later we will witness the end of 32-bit processors, and thus software. That concerns me a little bit since, as of the moment, B-Max only compiles in 32-bit. Most of us will never ever need those 16 exabytes of RAM - however in order to keep making games on general platforms such as Windows, it may be imperative to make a 64-bit of BlitzMax - just so that it will run on future Windows platforms and chips. Is there any possibility that this will happen? |
| ||
| I don't know what's involved in making it compile for 64-bit, but I did notice Unity recently added a 64-bit build target. I think (hope) 32-bit software will still work for many years to come, but it's definitely going to transition and eventually I would imagine it will phase out. Although that said there is a TONNE of 32-bit software out there so it's hard to see it being killed off so easily. Personally I'd like to see a 64-bit version of Blitz just to ensure it still has a future and will work on future o/s's. Last edited 2012 |
| ||
| I'd love to see a 64-bit blitzmax target for windows, but I doubt it'll be an easy thing to do... I'd think that there are a lot of internal assumptions about 32-bit datatypes and memory addressing that could cause issues, requiring a fairly substantial re-write of many of the core portions of blitzmax. |
| ||
| Unity recently added a 64-bit build target. Unity isn't a language. They use a third-party compiler. Anyway, 64-bit hardware doesn't mean 32-bit software is going away. For the most part, 64-bit processors run 32-bit code perfectly and natively. People naturally progressing away from 32-bit software, in the same way that we don't use 16-bit software any more (even though we still can), is a more relevant issue. Anyway with the way things are going, by the time 32-bit systems are gone from the market, dynamic recompilation will most likely be fast enough that architecture stops being relevant, at least for the kind of high-level code most people write in BlitzMax. |
| ||
| in the same way that we don't use 16-bit software any more (even though we still can) Actually, you can't anymore under 64-bit windows: It just has WOW64 which will still run 32-bit programs for you, but if you attempt to run a 16-bit program you'll just get an error that the program is not compatible with your version of windows. 16-bit programs will only work under the 32-bit release of Windows, which is being phased out. (MS announced at the release of Vista that it would be the last version of windows to be released with a 32-bit version available. They changed their minds after the disastrous market reception of Vista, and released a 32-bit Win7 after all... But the writing is on the wall, only 64-bit versions in the nearby future. The production version of Windows 2008 is only available in 64-bit mode, although there is a 32-bit development edition that's not intended/licensed for production use) |
| ||
| This is the enviable problem 64-bit processors have been out for years and slowly but surely everything is going 64-bit all new machines are being sold with 64-bit windows so it does make sense. 32-bit will go the way of dos applications basically it's upgrade or die. It makes good business sense to add a 64-bit target to blitzmax, monkey and in the end retire blitz3d as it will be at the end of it's life. From what I can glean there is only a 64-bit version of osx lion Last edited 2012 |
| ||
| Under Windows it's currently not that big a deal yet to have only 32-bit, but IIRC it's already causing issues under Linux today in that there's a ton of (32-bit) pre-requisites that aren't present by default on most distributions anymore that are necessary for developing programs... Last edited 2012 |
| ||
| On OSX its much more of a issue, Leopard supported OSX9 with a compatibility layer, Snow Leopard doesnt run the apps at all. I can see this 'transition' happening in the 32-bit era. |
| ||
| 32-bit will go the way of dos applications... It already has on the server version of Windows. If you have 2008 and want to run 32-bit software, you need to download and install WoW64.With the exception of a couple of netbooks and nettops, all systems being sold are 64-bit systems. It is a shame Blitz Max doesn't support 64-bit, but plenty of languages do. |
| ||
| With all that being said, I know there are some Intel chips that are 64-bit-only. That means even if Windows were to support 32-bit through WoW, the OS won't be able to do it as the chip no longer understands 32-bit instructions. It makes sense to provide Blitz[any] in 64-bit. |
| ||
| In the not to distant future I would say 2-5 years all stuff will be 64-bit, heck the processors have been out for years the only reason its not that way now is because of Windows etc. My next OS update will be 64-bit as its good to keep with the times at least until 128bit comes out eventually. We will look back in a decade and go '1Kbit' I remember when everything was 8bit/16bit and 32bit :) |
| ||
| there are some Intel chips that are 64-bit-only. Not ones that are in use in home computers. (There's all kinds of weird stuff in the high-end server field.) Last edited 2012 |
| ||
| +1 for Max-64! It's not an issue right now... but who knows in 5 years? A 64-bit Blitzmax could be extended to work for a really long time :) |
| ||
| It's kind of an issue now on Linux. Would be nice to at least have the option of a 64bit build there. Cheers Charlie |
| ||
| Here's another vote for 64-bit. |
| ||
| +1 |
| ||
| It would be great to have a 64bit version of BlitzMax... Just wondering if you guys would pay for it? (Even though you have paid for the current version of BlitzMax) |
| ||
| Yes I would pay for a 64bit version as its a major rewrite. |
| ||
| I'd be paying for it of course. |
| ||
| It's kind of an issue now on Linux. Would be nice to at least have the option of a 64bit build there. Could you describe the "kind of an issue" you have? Building/Running apps here is no problem here for my xfce/debian 64bit environment - should be the same for other dists/builts. bye Ron |
| ||
| It *should* be, but not everyone has a multi-lib kernal installed on their 64-bit system, or the right 32bit libs even if they do. Some folks don't want 32bit compatibility either, and won't install. Cheers Charlie |
| ||
| I echo completely what jkankie says. The biggest complaint I get from potential customers by far is the lack of a 64-bit Linux build. Either because they flat out can't get the 32-bit build to run, or because they are unwilling to install the 32-bit libs needed to get it working. Last edited 2012 |
| ||
| Hmm ok so your customers wont fit the "target audience" of normal blitzmax apps (also called "games" :D). But at this point you see why Windows keeps the compatibility to 32bit within their system. Back to my question: What kind of unresolvable issues you might run into? It is possible to install the needed libs - so its like saying "We need to get rid of .net framework - some customers are not willed to install it". I don't really understand your point of view - so for not starting a flame on "percentage of linux 64 bit only users compared to all customers" etc. I just finish my post here. bye Ron |
| ||
| Sorry Derron, but I don't quite follow what you are going on about. I get emails every week from 64-bit Linux owners that either can't play my game, or don't wish to install the 32-bit libs needed to play it. If you think I'm imagining this or making it up just look at the Desura comments page for my game. There similar posts on the games forums. If I want to reach these customers then I would need a 64-bit build, it's as simple as that. Last edited 2012 |
| ||
| I got your point and yes it would be nice to have the possiblity to build for 64bit systems. I just wanted to state my point of view, that most potential customers are able to run 32 bit apps fine. If there are serious potential issues (other than missed customers) with 32bit on 64bit linux ... feel free to state them. bye Ron |
| ||
| I've already stated what the issue is, as has jkrankie. |
| ||
| the issue is: loss of potential customers and the dependency of 32bit libs... I see nearly no difference to .net framework (or years ago: vbrun(-times)) as the problem can be solved by installing a piece of software. As jkrankie mentioned "issues" I thought about problems which lead into crashes or so... Like said ... not wanting to start an offtopic discussion, so I will stop stating my opinion about that subject now. bye Ron |
| ||
| The issue is that 32-bit apps don't work for a lot of 64-bit Linux users. The fact that with some effort these users could get the app working is irrelevant as these users are either unwilling or incapable of putting in said effort. I can't make users install the libs and software needed to run my game. I could make this entire problem go away if I was able to build a 64-bit version of my game. It's really that simple. Whether you class that as an "issue" or not I couldn't really care. |
| ||
| Has anyone tried yet? My approach would be to use the Fasm2As utility and add on to it using this reference (maybe add some sse opts while you're in there): http://www.x86-64.org/pipermail/discuss/2000-October/000952.html i'm a novice at assembly, but it seems that most instructions are still 32-bit so you're still using the base set of registers. it's the stack and addresses that have increased to qword[]. Mingw64 is here: http://mingw-w64.sourceforge.net/ ...and then ask Mark to sell it on the site for us$50 and offer him 5% of sales. |
| ||
| +1 As far as I can see, BlitzMax has always been a language without more advanced language features (interfaces, private fields or a real precompiler) for the sake of stability and ease of use. At least that's my guess. Adding 64-bit support seems to be a fitting for BM. |
| ||
| +1 on 64 bit We can dream :) |
| ||
| a real precompiler It's not a "proper" solution, since it makes your code nonstandard, but remember that you can use the C preprocessor with any text file you like (invoke it with gcc -E, more details here: http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html ). Since BlitzMax requires GCC to be present anyway, there are worse ways to handle the issue. 'Course this conflicts with the #GotoLabel syntax... is that used for anything other than Goto? (i.e. safe to abuse in Strict-mode programs?) Hmmm. Maybe on second thoughts that was a terrible suggestion. Oh well. Last edited 2012 |
| ||
| I'm always such a sucker for standard functionality : D Last edited 2012 |
| ||
| Anyone here know how much work would it take to convert bmax to 64bit? This could help with making larger servers with bmax (those might require more than 2gb of ram). |
| ||
| And another vote for 64-bit. |
| ||
| This is like when Apple made PPC apps obsolete! I say to have both 32 bit and 64 bit processors! Its a tat too late for Apple to bring back the old PowerPC units though :( |
| ||
| POWERPC and x86 are fundamentally different architectures (CISC and RISC). It made sense for Apple to move to Intel. The point is that some 3D games might require that extra little space in memory - 32-bit "only" allows for programs to use a maximum of 2 GB RAM. This also is true when running a 32-bit app on a 64-bit Windows. |
| ||
| ..what mr. Sibla have to say about all this, im wondering.. :) |
| ||
| Also interesting about this: Coding Horror: Dude where's my 4 GB RAM? |
| ||
| another +1 for 64bit. |
| ||
| I wonder how much needs to be done that the community can't handle? If BRL did the back end stuff and left us to fix all the mods (heck it'd likely break all of Brucey's mods, but anyone wanting them would have to upgrade them or stick with 32 bit.) It'd be a most welcome start, and still one I'd be happy to pay for. |
| ||
| Well... you need a 64-bit compiler to begin with in order to make 64-bit modules. It's up to Your Siblyness to give us that. |
| ||
| If he can find a way to use a debugger, I would make BMX 2 a C++ pre-processor like Monkey, and just piggyback on the compiler. |
| ||
| If he can find a way to use a debugger This isn't that hard, you just need it to be aware of the original source file instead of the source file received by the C compiler. Might not be very efficient if it means not using an existing tool, but overall not difficult to implement as things go. |
| ||
| You could, as an intermediate solution, have a c++ preprocessor an an extra 64bit C++ compile option. Debug, Release and C++. That way you can debug your program under 32bit, then compile to C++ once your getting ready to release as 64 bit. This would be good to tide us over till a debug solution can be made for the C++ release. option. I'd be happy to help work on a pre-processor. I'm no expert, but I am pretty interested in language design and implementation and have done a few university level courses on it. |
| ||
| But unless there are some 'under the hood' changes to enable the 64-bit, merely throwing it at a 64-bit compiler is unlikely to make any difference... I'm fairly sure that behind the scenes it uses integers for addressing, so even in 64-bit compilation it still wouldn't be able to access the higher memory addresses without changes... (Which that could be a big problem, since under 64-bit mode the program may end up getting loaded to a memory address higher than the 32-bit range can access) |
| ||
| My greatest point of concern of the future of using BlitzMax is 64bit support. We need the architecture in place now so that the wide variety of modules and extensions can be migrated before the issue becomes urgent. I do hold some hope, Mark did pop up out of the blue one day and give us multi-threading when nobody expected it. It would be nice to hear his thoughts on 64bit, although I am sure the lessons of BlitzMax3D would cause him to refrain from promises. |
| ||
| It would be nice to hear his thoughts on 64bit, although I am sure the lessons of BlitzMax3D would cause him to refrain from promises. I would say it was more important for 64bit, then a gimmicky 3D engine, which at the time, there was quite a few about for Blitzmax anyway! If Mark came along and said "Right, I've sorted out 64bit for BlitzMax, but, for the privilege, it's gonna cost £X for the upgrade" I would then say "Fair play!" Dabz |
| ||
| Old soapbox. The original plan for Blitz3D and BlitzMax seemed to be -- buy once and get free upgrades for life. Before BMax I was using FutureBasic which cost $170 plus $100 a year to maintain. There were many faithful 'subscribers'. But then Apple pretty much undermined this PPC Basic when it switched to Intel and stomped on it further by deprecating Carbon. Even earlier, I used a Mac 68K Basic which Apple destroyed with the PPC switch. Now our Mark was right to create Monkey -- PCs are dying and Mobiles are the future. I also suspect Mark relishes a HUGE challenge like he had with Blitz3D and X-platform BlitzMax. However, as a very minor developer I've already lost interest in mobile because: (1) the big boys hold all the marbles, (2) they collude to charge greedy 30% overheads, and (3) have fostered a near infinite amount of cheap competition for each sale. So, some kind of annual subscription or charging for BlitzMax2 sounds fair. to me. |
| ||
| It would be nice to hear his thoughts on 64bit, although I am sure the lessons of BlitzMax3D would cause him to refrain from promises. This is the last I could him mentioning it, 3 years ago: There are no plans for a 'native' 64 bit version as it would be a massive mission compiler wise... http://www.blitzbasic.com/Community/posts.php?topic=83917#947706 Unfortunately, in the long term 64-bit is going to be pretty much mandatory. The Steam hardware survey ( http://store.steampowered.com/hwsurvey ) shows that over 60% of windows users currently run a 64-bit version (which is only bound to increase). I don't think that the recent OS X versions even exist in 32-bit form anymore, and who knows when Apple will drop backwards compatibility for 32-bit apps... :-? But like you said, who knows -- Multithreading support was also added out of nowhere at some point. |
| ||
| There are no plans for a 'native' 64 bit version as it would be a massive mission compiler wise... GLFW is working on 64-bit so monkey seems to be the direction to go. IMHO, blitzmax64 should be monkey+GLFW64 (pc/mac/linux)+debugger+mojo64 No need to support mobile, keep 64bit targets separate and specific. |
| ||
| im in |
| ||
| I'd actually like to see the blitz compile native on a x64 platform |
| ||
| IMHO, blitzmax64 should be monkey+GLFW64 (pc/mac/linux)+debugger+mojo64 No need to support mobile, keep 64bit targets separate and specific. Yes, but what about networking using UDP? Not an option for Monkey at present. I would love to see a 64bit BlitzMax but I just don't see it happening. Plus I think 32bit apps will run on at least Windows for some time. Last edited 2012 |
| ||
| Windows likely yes, but I doubt Apple will support 32-bit for a long time. |
| ||
| IMHO, blitzmax64 should be monkey+GLFW64 (pc/mac/linux)+debugger+mojo64 No need to support mobile, keep 64bit targets separate and specific. Yes, but what about networking using UDP? Not an option for Monkey at present. SFML target instead of GLFW. SFML has a lot of features (supports lots of languages) that are selectable as separated parts, discarding already implemented mojo features. It's updated very often and it's a pleasure to program with. http://www.sfml-dev.org/features.php |
| ||
| @Corum I will have to look that over this weekend. But it does support TCP/UDP and that for me is interesting as a Monkey target. One caveat is it does not support DirectX. Last edited 2012 |
| ||
| Count me in too... |
| ||
| +1 (and I'd gladly pay for it too ofc.) |
| ||
| Me too. But as always its up to mark im sure monkey is keeping him busy at the moment |
| ||
| A quick question that kind of covers the same topic: Do you guys miss unsigned types like UInt or ULong too? Just want to know, if I'm the only one. |
| ||
| +1 for 64 Bit support. I and some users have many problems to run my big server application under Linux 64Bit versions. A 64Bit support would help me alot. Many v-servers and root server hosters have more 64Bit images than 32Bit of Linux versions. On the ubuntu homepage is the 64Bit server edition marked as recommend. So many users can't run my app or it crash many times under 64Bit. But 32Bit works fine. My server hoster have only one 32Bit Linux version and this one is outdated. All newest Linux versions are only in 64Bit aviable. It also doesn't allow me to compile my programms on my server without to install many packages and modify the system. Klin |
| ||
| A 64Bit support would help me alot. technically there is already x64 support in blitzmax because it works on OSX Lion/Mountain Lion which are both 64 bit platforms... |
| ||
| 68bit platforms still run 32bit applications. BMax only compiles 32 bit applications on all platforms regardless of OS revision. Some 64bit OS's don't necessarily run 32bit binaries properly (see Klin's issues with various linux distros). |
| ||
| +1 for BMax 64bit here as well. Just got a brand new pc, Quad core 64-bit with 12GB RAM onboard. It would be a waste not to be able to use it all. :-) |
| ||
| I would like to point out that the 32bit apps on 64bi windows is a compatibility thing, think about it how long before its phased out and its 64bit only apps surely its better to get there now than wait and miss the boat? |
| ||
| @ProfJake you are not the only one I'd love a 64bit version, too, and would be willing to pay for it. (Though an at least slight discount for owners of the current BlitzMax would certainly be nice) |
| ||
| The only fear I have is that Mac might one day drop support for 64-bit apps. I think they will do it before Windows. Other than that, I see no real gain from 64-bit builds. |
| ||
| Mac might one day drop support for 64-bit apps Typo? |
| ||
| The only fear I have is that Mac might one day drop support for 64-bit apps. I think they will do it before Windows. Other than that, I see no real gain from 64-bit builds. I've seen pc's which can use up to 1TB RAM (yes, 1 Terabyte). Checkout http://www.gamepc.com (especially this: http://www.gamepc.com/shop/systemfamily.asp?family=titansli ) Using 32-bit apps only, you could only have apps that can use up to 3 or 4GB of RAM max. How would such a pc be able to use all that RAM? It would need at least 250 separate apps that use 4GB each to use up all that RAM. What about massive databases? Or servers for MMORPG's? Those use ALOT of RAM. I know one gameserver that must be run on a 64-bit computer or it won't run: RF Online. Earlier versions were 32-bit, but the latest use all 64-bit to run. You need 64-bit to be able to address all that RAM. Otherwise, you could only use 3GB of the total 1024GB available. Since games become so large and need alot of textures, models, ..., you're gonna need 64-bit to be able to store it all. Last edited 2012 |
| ||
| Osx dropped rosetta completely in snow leopard so losing 32bit is due |
| ||
| AMD have made some 128bit x86 thingy, so just ignore 64bit, go straight 128bit, BMax will have nice future. |
| ||
| How would such a pc be able to use all that RAM? It would need at least 250 separate apps that use 4GB each to use up all that RAM. And how many BlitzMax programmers are making applications that need that? I am arguably the most demanding user, and I don't need it. Since games become so large and need alot of textures, models, ..., you're gonna need 64-bit to be able to store it all. Except that game technology is moving backwards right now. Games today (mobile) have far lower resolution and specs than games ten years ago (PC). Unreal Tournament 2004 came on like 6 CDs. What is Angry Birds, like 10 mb? Last edited 2012 |
| ||
| @PowerPC603: I agree with you that it would be nice to have 64 bit support in Bmax, but to be honest, people who need that kind of addressable memory are probably not going to be using Bmax. I'm sure someone could do it, but I get the feeling that they would be using something like C++, which is more suited to very large scale programming projects. Again, not that it couldn't be done, just that it's sort of outside the intended purpose of Bmax. Russell |
| ||
| Apart from the memory allocation. Wouldn't native 64bit apps run more smoothly (no emulation required) under a proper OS. |
| ||
| My new PC has 64GB, would be nice to use more than the 2GB app memory that a 32-bit exe can use. :-? |
| ||
| Not sure if it actually emulates 32bit. Processors have that built in. |
| ||
| Not sure if it actually emulates 32bit. Processors have that built in. It does emulate it, using WoW64, a compatibility layer that automagically interfaces the two. More info: http://en.wikipedia.org/wiki/WoW64 |
| ||
| Indeed, processors do their part in hardware, and thanks to the wonders of virtual memory, all memory allocation and access is "emulated" (whatever that means in context) anyway, for all applications. It's really not likely to have a significant effect. |
| ||
| Note that 64-bit windows will no longer support 16-bit executables (WoW64 replaced the WoW32 emulation layer that was used for 16-bit), so it's not a given that 32-bit will continue to work forever either. |
| ||
| that's depressing. what about all the innumerable niche games and applications that are only compiled for 32bit systems? perhaps you'd be able to use special hardware to maintain that compatibility? Last edited 2012 |
| ||
| perhaps you'd be able to use special hardware to maintain that compatibility? Give it a couple of years and pure-software interpretation will be quite fast enough for that. It's already orders of magnitude faster than hardware-16-bit CPUs. Hardware constraints are a dying problem domain. |
| ||
| Hardware constraints are a dying problem. Perhaps, but Software constraints (necessary for emulation) are an increasing problem, with Microsoft being protective of their APIs and at the same time attempting to reel in user freedoms by trying to redirect everything through their own app store and pushing mroe and more for 'trusted computing'. Who knows if you can even install a necessary emulator on your own windows machine in the future, if Microsoft feels like it may not be in their best interest. |
| ||
| Not being able to address all that RAM is not the only problem. Right now, processors are still able to execute 32-bit and 64-bit instructions. If BMax won't support 64-bit, in a few years, you won't be able to even launch BMax anymore. And all apps created with BMax would cease to exist as they won't run either. Processors will become 64-bit only in a few years or so, it's only a matter of time. Anything created using 32-bit code will stop working. @JoshK: that does include your Leadwerks engine (AFAIK, you're the author of it). You WILL need it, or you have to start over from scratch with a new language that DOES support 64-bit code. There may be emulators that can continue to emulate 32-bit code, but with a severe slowdown of course. But then everyone using such 32-bit apps will need an emulator to run your code. Last edited 2012 |
| ||
| It will change eventually, who here remembers 16-bit and 32-bit processors in PC's where are they now? everything is 64-bit now and sooner or later the OS will change to accommodate them, apart from the netbook market I cant think of a PC that is sold with a 32-bit processor at all most if not all are 64-bit now. |
| ||
| My Asus netbook also has a 64bit processor and is almost a year old now. I doubt there are still 32bit only systems being sold? |
| ||
| Windows 8 comes in 32 and 64-bit versions. |
| ||
| I meant 32bit hardware, not software. |
| ||
| I don't think this will ever happen, at least for BlitzMax; currently the compiler emits 32bit assembly code, I don't see it being updated to emit 64bit assembly. The only chance would be if it emitted C/C++ code, and leave the 64bit code generation to the C/C++ compiler. |
| ||
| @Azathoth FASM can compile to X64. It would just require Mark to do so. He might eventually upgrade Blitzmax once he gets Monkey more setup. |
| ||
| That would be a lot of work, something Mark said he wont be doing. The C/C++ approach would be simpler as the 32 and 64 bit code generation is handled by the C/C++ compiler. |
| ||
| Shouldn't be too difficult: http://www.codegurus.be/codegurus/programming/assembler&win64_en.htm |
| ||
| BMax is Mark's product........... if he decides to make one, there'll be x64 version. But I'd prefer a 64bit Monkey. |
| ||
| Monkey would be easier I imagine, since monkey basically generates source code (via translation) and lets the appropriate compiler create the actual machine code. So as soon as THOSE compilers can generate 64 bit code we are more than halfway there. When creating code for the PC or Mac target, I believe the C++ compiler can be set to generate 64 bit code. Someone correct me if I'm wrong, but I believe this is the case? Russell |
| ||
| I believe the C++ compiler can be set to generate 64 bit code. Assuming you ask it to, yes. Has been able to for years now (bear in mind that the very existence of this discussion is because not supporting 64-bit is now the behind-the-times thing). For the other targets, the issue is largely irrelevant (except Objective-C which will almost certainly have the same backend as the C++ compiler anyway), although I'm guessing nobody's really investigated modding it to e.g. compile Java for the desktop, yet. |
| ||
| Does anyone here have an actual NEED to support 64bit, or is it just something that would be nice to have (and I agree, that it would be nice to know it has that capability)? I mean, other than having the ability to support vast, huge, stupendous amounts of memory (Note to self: Remember, not so long ago they used to say that a megabyte was more than anyone would ever really need or use...) and a slight increase in speed for certain types of operations (64bit programs are not twice as fast as 32bit programs as one might think), what need is there for 64bit support in BlitzMax programs, or even Monkey programs for that matter? Maybe if you're planning on writing a 3D renderer, or some engineering app or some such thing... Russell |
| ||
| The biggest issue by far is being able to future-proof your programs, although the ability to access more system resources is an added benefit. |
| ||
| No, people are just worried about their programs being made obsolete. I would mostly be worried about this happening on Mac. I don't know if Windows, for the remainder of its life, will ever drop support for 32-bit programs. |
| ||
| The same thing happened with 16-bit programs. Nobody knew they would drop support for those programs as well. But nowadays, you need an emulator to run them or they won't run at all. Also the same: in earlier Windows versions, you could address the parallel port, serial port and other ports like you wanted. You could just write data to any port as you saw fit and your pc just did that. For Windows NT/2000/XP/Vista/7, directly addressing those ports wasn't supported anymore, as the OS claimed those ports and you needed a specialised driver (example: NTPort) to address the ports with the help/support of Windows (Win API). The same will happen to DX7, which Blitz3D uses. Nobody knew it would still run on Windows 8, everybody thought DX7 support would be dropped. It won't take long before it will eventually fail to run on more modern systems (Windows 9/10 ???). The same WILL happen to 32-bit programs. It's just a matter of time. As soon as most programs are converted to 64-bit code, and 32-bit programs aren't released anymore, support will be dropped sooner or later. Knowing Microsoft, they WILL drop support for 32-bit code as soon as most program/games releases have become 64-bit. Look at what happened with Windows XP when Vista was released. The same day, all copies of Windows XP disappeared from the local computer stores. You were forced to use Windows Vista, or you needed to search the web for a second-hand XP copy or some web-based store to be able to find a copy. I myself went to the store a few weeks after Vista was released and they told me all copies were withdrawn from their stock. Currently, they cannot afford to drop support for 32-bit right now, as most programs/games currently on the market are still 32-bit. But it will become an issue within a few years. Some people also say that DX9 is emulated today on Windows Vista/7. Support for that will be dropped too someday. Having support for 64-bit isn't just to have it, like having a luxury item you won't ever use (but you have to brag about it against other people to make them jealous). Someday, you'll NEED it or you're stuck as a developper, as nobody else will be able to run your 32-bit code anymore (unless they all are willing to install an emulator to run your stuff). It would look really nice to go to a store, pick up a DVD box and see "32-bit emulator needed" when you look at the requirements. I guess your program won't be bought by many people that way. Your customers would just say: "developper, grow up or don't release that stuff that doesn't run natively" and put the box back on the rack. Like I've read on some topics/forums, this is already happening on some systems that will only run 64-bit apps only (no 32-bit support anymore). So don't say it will take many years before it will happen. Last edited 2012 |
| ||
| GLFW is out now for 64-bit. lock n load, monkeycoders. |
| ||
| For me I would like to know if Mark is committed to keeping BlitzMax a current system that works on current o/s's, ie works on 64-bit. I like most people don't have a use for 60 trillion megs of ram. I just want to know that if I work on an application or game it's not going to start running into customers who say `your game doesn't work on my computer` or `it only works on old versions of windows/osx` etc. That would be a deal killer, especially if you have a business built around an app/tool/game and you want to keep selling it for 5-10 years to come only to have it die off due to incompatibility. And even moreso, if I commit to making something with Blitz and put all my effort into writing something in the BMax language, I don't want to have to `port it` to some other language down the line as a result of Blitz support dying off. I don't really know all of what's involved in making 64-bit work, I'm sure Mark is more expert, but could there not be a way to take 32-bit assembly language code, or even machine code, and `convert it` to a 64-bit output through some kind of small tool/converter? Would that make it work or is there a lot more involved? Last edited 2012 Last edited 2012 |
| ||
| GLFW is out now for 64-bit. lock n load, monkeycoders. Too bad a lot of publishers don't accept games in OpenGL on Windows (usually because their wrappers doesn't work with OGL)... |
| ||
| If Windows 7 comes in 32-bit and 64-bit flavors, and generally speaking the entire `windows platform` as a single platform is therefore likely to be `supported` by Microsoft until, let's say, 2020?.. then does this not suggest that 32-bit apps will be supported for at least another several years? That's probably a good thing, right? Although it doesn't suggest what happens when more and more people try running 32-bit stuff on a 64-bit machine... unless Windows 64-bit is supposed to always support 32-bit apps? Or does it not care when you have `only 64-bit`? Anyway, clutching at straws. |
| ||
| If Windows 7 comes in 32-bit and 64-bit flavors, and generally speaking the entire `windows platform` as a single platform is therefore likely to be `supported` by Microsoft until, let's say, 2020?.. then does this not suggest that 32-bit apps will be supported for at least another several years? All it means that 32-bit apps will be supported by windows 7 and windows 8 -- but there are no guarantees that 32-bit programs will work (well) on windows 9. given the large number of 32-bit apps out there it is likely that they'll work, but you never know. Still, if nothing else a 64-bit app will have a longer life expectancy at this point than a 32-bit one. |
| ||
| dupe Last edited 2012 |
| ||
| I'm just trying to be optimistic.. . at least if there's a Windows 8 32-bit out there and lots of people use it that's kind of a good thing for a few years... but yeah, things are going to have to go 64-bit-only at some point and I hope that doesn't mean this marks the end of the life span of BlitzMax because it's a really great language and deserves to live on for years to come. |
| ||
| A year later... any news on this subject? |
| ||
| A year later... any news on this subject? And god is a monkey... bye Ron |
| ||
| As long as people keep posting on the forum and keep using BlitzMax, there is no incentive for BRL to make the move to 64-bit as there is no legitimate demand being shown. If people are happy with the status quo and will keep using it as it is, where is the motivation for BRL? |
| ||
| I don''t think the usage patterns of people who paid a one-time fee five years ago have any effect at all. |
| ||
| As long as people keep posting on the forum and keep using BlitzMax, there is no incentive for BRL to make the move to 64-bit as there is no legitimate demand being shown. If people are happy with the status quo and will keep using it as it is, where is the motivation for BRL? Of course it's hard to gauge how many potential customers don't even bother trying the language due to lack of features like these in 2013... |
| ||
| You know that and I know that. But you can't force BRL to care about the future of their products. |
| ||
| Tbh its a pointless exercise loads of people are moving on to other languages and platforms even max with its three targets is limited these days when compared to the likes of monkey and unity. |
| ||
| A solution for BRL would be to make a revisioned product named Blitzmax64 with enough updates for Blitzmax (and perhaps to MaxGUI) which could be priced on bar with Blitzmax. I would gladly pay for it. -Henri |
| ||
| As Henri said, I'd love to pay for offical updates. Btw: What's the best 64Bit alternative to BMX if you want to code apps, not games? |
| ||
| What's the best 64Bit alternative to BMX if you want to code apps For cross platform Purebasic would be the best bet, but check out http://basic.mindteq.com/ for a list of basic like languages. |
| ||
| I would make BMX 2 a C++ pre-processor like Monkey, and just piggyback on the compiler. Better still, produce an addon for Monkey that gives it all the features of Max for the big 3 desktops. I would pay good money for that. |
| ||
| Tbh its a pointless exercise loads of people are moving on to other languages and platforms even max with its three targets is limited these days when compared to the likes of monkey and unity. Some people have goals other than making lowest common denominator products that run on as many flash-in-the-pan operating systems as possible. With the decline of Windows, the need for a cross-platform language and GUI is more relevant now than when BlitzMax was originally released. If presented properly, I'm sure BMX 64 could raise a couple hundred thousand dollars on Kickstarter, which I would bet is more than Monkey is making right now. |
| ||
| With the decline of Windows, the need for a cross-platform language and GUI is more relevant now than when BlitzMax was originally released. Cross-platform and GUI is by no means something needed as there are a gazillion of options out there that are already better than BlitzMax at this. GTK and Qt are the first two that come to my mind, but there are a lot of them |
| ||
| They're both unsuitable. GTK is not native. It does not give you a Windows or Mac interface that looks like Windows or Mac. QT forces the structure of your application. It's a bloated framework, not a library, and it only works with C++ which is not good for GUI application development. They even try to force you to use their own IDE. Sure, you can do it your own way, but every time you run into trouble they're going to ask they you're not doing everything the QT way. I've never seen any other code try to be so intrusive. |
| ||
| If presented properly, I'm sure BMX 64 could raise a couple hundred thousand dollars on Kickstarter No doubt, unfortunately as we know, BRL 'don't do' advertising. |
| ||
| BRL 'don't do' advertising. or bug fixes or support |
| ||
| Better still, produce an addon for Monkey that gives it all the features of Max for the big 3 desktops. I would pay good money for that. this. to me, it moves in a better direction than sticking with the limited features in BlitzMax. |
| ||
| Gary, why don't you try taking a shit in someone else's yard for a change. |
| ||
| @skidracer Albeit this rant was versus you too so it is your right to feel attacked but imagine this forum is Mark's "yard" - other forums would be other ones "yard" - and you do not know whether GaryV poops there too (if he feels uncomfortable with the current situation). In short: your answer does not raise the level of discussion too. All of us know that the satisfaction with the product BlitzMax has reached its climax some years ago. Each step into the void of oblivion will come in connection with harsh words (which get not better each time). Just wait until "Monkey" reaches the state of dying. There will be multiple users writing phrases like "happening again" or "like I said X months ago". Thought there must be people here on the forum which have good connections to Mark. To kindly ask for some feedback here at the "BlitzMax front" to clear the future (if there is one). But playing "dead man" ... yeahh, gives a warm welcome to new customers! bye Ron |
| ||
| While I can agree to Derron here, you should also consider that, precisely, latest updates in BlitzMax and also in Blitz3D were exactly bugfixes to ensure the product works well on latest OS versions so, while Mark is quite silent here lately, as far as I know, anytime there has been a compatiblity issue to get fixed, it's been fixed. I would also add to this that the BRL modules are now open source, so all in all, I don't think what GaryV said is true. |
| ||
| Gary, why don't you try taking a shit in someone else's yard for a change. How is the bug fix you are working on for Blitz Plus coming along? How are the bug fixes for the Linux issues with BlitzMax coming along? Please prove my comments wrong. You may not like it, but some of us actually like the products, and have not abandoned them for other products, we still use them, even though BRL has moved on to Monkey. You seem confused about who is actually taking the crap in the yard. It is not the users doing the crapping, we are the ones having to dodge the piles. Fix the OpenGL issue with BlitzPlus and fix the Linux issues in Blitz Max and you will have ZERO complaints from me. Blitz3D were exactly bugfixes Actually for the last one, Mark merely implemented the bug fix a user came up with. The same bug also exists in BlitzPlus, along with the long-standing OpenGL bug. |
| ||
| and it only works with C++ which is not good for GUI application development. That statement can also apply to gtk and wxWidgets and many other GUI framework/toolkits out there. I can't even think of any that are built from the ground up without using C/C++ somewhere along the lines. And only a masochist would try to use assembler. There are other language bindings for Qt just like there are language bindings for gtk and wxWidgets. What language and the level of support depends on the persons involved in those particular projects. http://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_4 http://en.wikipedia.org/wiki/List_of_language_bindings_for_Qt_5 http://en.wikipedia.org/wiki/List_of_language_bindings_for_wxWidgets http://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK%2B |
| ||
| They're both unusable garbage. O don't want to be off topic, I just wanted to say how much I disagree with this. Anyway, you know what they say about opinions. GTK is not native. It does not give you a Windows or Mac interface that looks like Windows or Mac. QT forces the structure of your application. It's a bloated framework, not a library, and it only works with C++ which is not good for GUI application development. They even try to force you to use their own IDE. Sure, you can do it your own way, but every time you run into trouble they're going to ask they you're not doing everything the QT way. I've never seen any other code try to be so intrusive. |
| ||
| Lots of love coming from this corner of the forum, eh? |
| ||
| By "unsuitable" I mean GTK alone is not a valid option for Windows or Mac. On Linux, it looks really good and I am extremely grateful to have it. |
| ||
| Sorry all, I'm out of order with my disgust. Although I am no longer in anyway associated with BRL I continue to moderate on a voluntary basis, so should not be lowering the tone around here with my advice. |
| ||
| I'm not to active forum user, but BlitzMax is still my favourite language. I hope we will get 64bit support, the same way we recieved multithreading. |
| ||
| When reviewing this site here: http://basic.mindteq.com/ I didn't find many products that truly support 64-bit systems, at least they are either not advertised or only "64-bit Windows compatible". Personally, I would also need a GUI library similar to MaxGUI and a good mouse-driven GUI designer (not necessarily included by I would pay for one like I did with Logic GUI) - so what product offers both: GUI + 64-bit support. So my question would be, which Basic compilers/systems, preferably multi-platform (unlike PowerBasic), do actually offer that? |
| ||
| I didn't find many products that truly support 64-bit systems, The vast majority of those on that list are also dead. |
| ||
| Personally, I would also need a GUI library similar to MaxGUI and a good mouse-driven GUI designer (not necessarily included by I would pay for one like I did with Logic GUI) - so what product offers both: GUI + 64-bit support. The list there is a little out of date. And finding anything that is still on going is tricky. One place to look is source forge.There are possibly only two contenders that cover Windows, OSX and Linux are... Pure Basic and Basic For Qt. For Pure Basic to compile 32 and 64bit you need to install both the 32bit and the 64bit version (like Blitzmax buy one get all platforms) along with any addition libraries. It is possible to install 32 and 64bit versions and use the either IDE (depending on the architecture) to select the compiler you wish to use. Unfortunately Pure Basic is not object orientated and is a procedural language with use data types. Now I have never used Basic For Qt (this is KBasic V2) and will be having a look at it at some point. EDIT: Basic For Qt has problems. I'm having trouble getting the free version to work on Linux. |
| ||
| please ignore my ignorance... but Wouldn't it just take a 64 bit version of gcc to make bliz 64 bit? Everything would stay the same, except longint (64bit wide) would be native? You would just recompile all the mods and you have a 64bit system? |
| ||
| so what product offers both: GUI + 64-bit support. Oxygen BASIC is 64-bit, IIRC. PureBASIC is 64-bit too. The ones on that list that are BASIC converters (BCX, BACon, etc), you could simply compile the generated C code with a 64-bit C compiler. |
| ||
| please ignore my ignorance... but If it was that simple Linux (and OSX) would have been 64 bit as soon as those OS's came out. The bcc compiler needs to generate 64bit compatible assembler code and there will also need to be 64bit compatible version of fasm to use it. Then bmk would need to be modified as well as any C/C++ code that contains any inline assembler code. Wouldn't it just take a 64 bit version of gcc to make bliz 64 bit? Everything would stay the same, except longint (64bit wide) would be native? You would just recompile all the mods and you have a 64bit system? |
| ||
| Wouldn't it just take a 64 bit version of gcc to make bliz 64 bit? Everything would stay the same, except longint (64bit wide) would be native? As bcc ( the blitz max compiler ) generates the assembly code output from the 'Max code then the whole compiler needs to be rewritten - probably from scratch. The x64 calling convention is different, any code that uses the data type size in a calculation or as a parameter needs to be rewritten. Looking through the blitz run time, quite a lot will need 're-factored' just to work. Unfortunately, in the case of 'Max going 64bit it's actually a massive project by itself, and will need to be bug fixed for a few years to get it as stable as it is now. I'd say it pretty much means starting right back at the beginning. In the meantime... back to my own project(s). |
| ||
| in .bmx folder, there are .win32.x86.s files, isn't that the assembly code that's later compiled into game/app? Is it possible to write some parser, to somehow, replace all 32bit stuff with 64 one? |
| ||
| I can sense that Mark already took this project and turned it into Monkey (no assembler code I presume). I wonder how is native GUI-development front in Monkey for making GUI apps ? -Henri |
| ||
| I wonder how is native GUI-development front in Monkey for making GUI apps ? It doesn't exist. |
| ||
| maybe this is irrelevant, but if BlitzMax added 64-bit support I would feel a whole lot more reassured that making anything with it isn't going to be unuseable in the next few years. It is starting to put me off wanting to use blitz to make anything because its going to limit the shelf life. I would love for BRL to come out with a 64-bit version. Just my 2c. |
| ||
| To be honest.. If you're going to write a translator from x86 to x64 you may as well do it from 'Max to x64. Its the same problem space. |
| ||
| I wonder how is native GUI-development front in Monkey for making GUI apps ? wxMonkey was as close as I got: https://github.com/adamredwoods/wxMonkey ... i'm still working on an updated version of it so it works out-of-the-box. |
| ||
| @AdamRedwoods: Good luck to you, it's a noble effort. Especially if it's only choise for Monkey. Browsing through Monkey forum I get the feeling that it's not a viable option yet for desktop development so have to wait and see. I do like Blitzmax as a product and can live with the current situation as the 3rd party support is quite extensive (thanks Brucey) and for what is missing I can make for myself. If 64-bit option is too difficult of a task then this will have to do. -Henri |
| ||
| AdamRedwoods: Wouldn't IUP be easier to implement than wxWidgets? |
| ||
| AdamRedwoods: Wouldn't IUP be easier to implement than wxWidgets? it doesn't support OSX/Cocoa (GTK does not count). |
| ||
| It seems the development has moving to HTML5 and Mobile... 64/128 bit on Desktops has been not so important because not actually pushed to that limit on today's casual app/game. Although I think the massive memory on 64bit architecture can benefit scientific / video editing / image processing / cloud virtual server, but on my personal desktop, I rarely do this. |
| ||
| Maybe 64bit is not important for people TODAY... but as soon as 32bit support vanishes in the new OSes ... people will start complaining about their beloved games/app not working anymore. So the developers _here_ are moaning (me including) that the future of development in BlitzMax is more than uncertain - which may enforce people to switch to another language. bye Ron |
| ||
| but as soon as 32bit support vanishes in the new OSes It already has on server versions of Windows. 32-bit emulation is optional and needs to be installed, which is not always possible in some restricted server environments. |
| ||
| As well as 64bit, I think that a much better ide would help matters too. |
| ||
| The IDE is replaceable by 3rd parties. The compiler is the problematic part in the chain. The IDE is just a matter for sales. But like said multiple times: most disencouraging thing is the feeling of being left "abandoned" by Mark Sibly. Missing life signs in this forum for ages. bye Ron |
| ||
| Its already forcing me to switch to other platforms... if I write something today in BlitzMax for 32-bit, I can expect it to maybe have a shelf life of a few years at most before people who have bought it this year start finding out that it doesn't work anymore, and then that's a big headache. It needs to support 64-bit NOW not in a few years time. |
| ||
| in Monkey, 64-bit support is a small jump compared to BMax, and some people have already modded their files to achieve this. http://monkeycoder.co.nz/Community/posts.php?topic=5907#67374 most disencouraging thing is the feeling of being left "abandoned" by Mark Sibly. I agree. he is one person supporting a large product. i wish he would hire some part-timers to help him, but i sense he is a better programmer than a business man. |
| ||
| I expect Apple will drop support first and the rest of the industry will follow because they don't have any ideas of their own. We'll probably get about three months notice from Apple. MS decided overnight their entire developer ecosystem was a "legacy app" and torpedoed it, so I know they can't be trusted not to make wide-reaching destructive decisions on a whim. Fortunately, devs in other languages fought back against Metro, but when they ax 32-bit support we will not have the support of the C++ and C# developers. They'll just wonder why we aren't already using a 64-bit compiler. Dropping support for the 32-bit compiler would be absolutely fine at this point. OSX is all 64-bit, Ubuntu offers the 64-bit version by default, and most Windows users are on a 64-bit OS. |
| ||
| Taking into consideration that games are starting to come in 64bit only varieties as well now it wont be long before 32bit goes the way of 16bit or ISA/PCI interfaces. everything is pointing to 64bit and hanging on cause of software is quickly becoming more and more of a pointless exercise. |
| ||
| Correct, and every piece of software that moves over gives MS and Apple less reason to continue supporting 32-bit. We're losing the 32-bit ecosystem that previously kept us safe. |
| ||
| I think internet browsers and device drivers are still slowing the end of 32 bits. AFAIK none of the major internet browser compiles JavaScrit to 64 bits instruction set, and it's just interpreted on 64 bits, which is a lot slower than the 32 bits JIT most of them use now. Also, LuaJit is only 32 bits last time I checked |
| ||
| It seems that the BlitzMax 64bit question keeps being asked year on year for the last 6 years or so. At some point in the future, 32bit application support will be dropped from Windows,OSX and Linux. I cannot see BlitzMax being updated before this happens or even if it will get updated. In my search for how many times this has question has been asked. I came across these from Mark himself.... http://www.blitzbasic.com/Community/post.php?topic=73927&post=825910 http://www.blitzbasic.com/Community/post.php?topic=83917&post=947706 In an alternate reality. Mobile devices that have the power of computers that were produced a few years ago were never invented and BlitzMax has been rewritten for it to remain a viable product in the 64bit world. But I our reality, these devices were invented and the trend now is to support as many kinds as possible. And now that there is Monkey; which will eventually do most of what BlitzMax can do and many things that it will never be able to do out of the box because of the multitude of devices it's aimed at. Currently Monkey still uses a few programs written in BlitzMax, which would be it's Achilles heel in the future. |
| ||
| Also, LuaJit is only 32 bits last time I checked LuaJIT builds as 64-bit now. |
| ||
| I've got news for you: BlitzMax = The Titanic. If you are expecting 64 bit support, it's going to be a long wait. Mark hasn't addressed updates or bug fixes in over a year. Nobody noticed- he was on the first life boat off of this sinking ship. Rumor has it that he landed on Monkey Island. BlitzMax is fine if you are a hobbyist, but if you are trying to run a legit business then you should move over to something else. Eschalon: Book III will be the absolute last thing I ever make with it. It's been good to me, but I can't invest another 2 years into a product that doesn't have guaranteed support for future OSs and hardware. |
| ||
| I've got news for you: BlitzMax = The Titanic. If you are expecting 64 bit support, it's going to be a long wait. Mark hasn't addressed updates or bug fixes in over a year. Nobody noticed- he was on the first life boat off of this sinking ship. Rumor has it that he landed on Monkey Island. BlitzMax is fine if you are a hobbyist, but if you are trying to run a legit business then you should move over to something else. Eschalon: Book III will be the absolute last thing I ever make with it. It's been good to me, but I can't invest another 2 years into a product that doesn't have guaranteed support for future OSs and hardware. These are words from one of the most prolific Blitzers who has created the most complex games with BlitxMax. |
| ||
| Yup and he wasn't the first and wont be the last as yet monkey don't support 64bit out of the box |
| ||
| As long as 64bit CPUs can run 32bit, BlitzMax is fine... (although I would like the bugs to be fixed without me hacking the modules...) |
| ||
| although I would like the bugs to be fixed without me hacking the modules What bugs? |
| ||
| as yet monkey don't support 64bit out of the box I don't think it ever will. I don't think that 64bit compatibility was on Marks mind when he wrote it. Even on a 64bit OS you still have to use the 32bit SDK binaries for some of the targets it supports.I'm currently in the process of writing a tutorial on how to get Monkey installed on both 64bit and 32bit version of Linux. I can think of a number of ways ranging from PPA, update-alteratives and changing system variables. The real head ache is the Oracle's JDK on 64bit systems. Can we get away with just install the 64bit version or do we need to install both 32bit (as it say in the documentation) and 64bit so that it doesn't break the system. Problem I have for Android is that I don't have any android devices to test with. |
| ||
| There are android emulators (multiple choices available) - use the one from the SDK or just build one in virtual box (or use a downloadable image from the two big emu-projects). bye Ron |
| ||
| @Derron: I will rephrase that. Problem I have for Android is that I don't have any real android devices to test with. The emulated versions seem fine. But to take a partial quote from a well know film. "But, as you well know, appearances can be deceiving" |
| ||
| As long as 64bit CPUs can run 32bit, BlitzMax is fine... A CPU alone does not do BlitzMax any good as BlitzMax requires an OS to run. You already have versions of Windows that do NOT support 32-bit out of the box. |
| ||
| If I'm allowed to use compatible syntax and command set of BlitzMax, I can invest some money and time with my friends and make a 64bit clone of BlitzMax, maybe took months... but I'm afraid legally I can't do this. If you guys are interested I'm using SDL2 to make a metaware(GameMaker-ish 2D thingy) that is capable to export Win32/64 and Linux32(no 64 yet), but my final target is Android, that's already tones of troubles to do now. |
| ||
| Another option is to convert blitzmax to run inside Unity3D. I know someone already did some of the graphical parts of blitz3d and some parts of blitzmax would be hard to implement, but I'd rather write scripts in blitz code than java/c# anyday. |
| ||
| I don't think it ever will. I don't think that 64bit compatibility was on Marks mind when he wrote it. Even on a 64bit OS you still have to use the 32bit SDK binaries for some of the targets it supports. i don't see why not. all of the libraries used in Monkey mojo have 64-bit versions. |
| ||
| Its if they are made available as targets in the near future in the out of the box version that will be the question :) |
| ||
| @AdamRedwoods: I will only believe that when I no longer see any BlitzMax source files in the Monkey source directories. @EdzUp: I wouldn't hold your breath for a Adobe to produce a 64bit version of flex sdk for Linux. ;-) |
| ||
| What bugs? http://www.blitzbasic.com/Community/posts.php?topic=71746 http://www.blitzbasic.com/Community/posts.php?topic=96638 http://www.blitzbasic.com/Community/posts.php?topic=96647 http://www.blitzbasic.com/Community/posts.php?topic=93081 A CPU alone does not do BlitzMax any good as BlitzMax requires an OS to run. Fair point :) You already have versions of Windows that do NOT support 32-bit out of the box. Which versions? Are you talking about Windows Server 2008 / 2012... Server versions? They can run 32bit with WoW64... |
| ||
| 2008 R2 and 2012. It is optional and not supported by default. Given some server environments and restrictions, people do not always have the option of installing 32-bit support. What bugs? Plus the Linux bugs. |
| ||
| On the os note osx already comes in a 64bit ONLY version, how long do ya think it will be before they drop 32bit? When that happens blitzmax will lose another platform along with Linux not 100% working out of the box too. with monkey not going 64bit yet the competition is looking better for long term investment. |
| ||
| with monkey not going 64bit yet the competition is looking better for long term investment. Not to mention that monkey is not a replacement for BlitzMax. Max is well suited for cross-platform applications. |
| ||
| On the os note osx already comes in a 64bit ONLY version, how long do ya think it will be before they drop 32bit? When that happens blitzmax will lose another platform along with Linux not 100% working out of the box too. +1. The idea that we must develop software that will require "32-bit emulation on a 64-bit OS" is ridiculous. We are in the 64-bit era *right now*, but we are being told that we cannot evolve along with everyone else. When Windows 9 hits in 2015, legacy 32-bit software will feel antique, just like 16-bit software does for us now. We are developers and we should be *ahead* of the curve, not behind it. In all seriousness, Mark should have had a 64-bit migration route planned for BlitzMax from the start, because even back in 2005 we knew this day would eventually arrive. Unfortunately, even a 64-bit option won't save BlitzMax now. There are way too many other problems with BlitzMax for it to survive long term. |
| ||
| The idea that we must develop software that will require "32-bit emulation on a 64-bit OS" is ridiculous. We are in the 64-bit era *right now*, but we are being told that we cannot evolve along with everyone else. When Windows 9 hits in 2015, legacy 32-bit software will feel antique, just like 16-bit software does for us now. We are developers and we should be *ahead* of the curve, not behind it. In all seriousness, Mark should have had a 64-bit migration route planned for BlitzMax from the start, because even back in 2005 we knew this day would eventually arrive. Unfortunately, even a 64-bit option won't save BlitzMax now. There are way too many other problems with BlitzMax for it to survive long term. +1 i don't think there is anything to do but release a new product but to be honest its to little to late. Even monkey is starting to look dated on the support platform front when compared to the competition which isn't a good thing. i do like BRL products don't get me wrong ive been with blitz since the Amiga days but i do think that currently in wasting my time plugging away at a game that could be more viable on another system. |
| ||
| Plus the Linux bugs. What Linux bugs? |
| ||
| Think they mean the bugs concerning linking problems when using the "fresh installed" blitzmax version (-ldl etc.). Then that there is no out-of-the-box working sound implementation (I do not like other applications getting muted just because there is no switch for pulseaudio or alsa or ...). Then there is a bug in the ide that some crashing applications (in debug build) hang the whole ide so we are forced to run a terminal, "killall appname" and even "killall bmk" and "killall MaxIDE" depending on the level of "crash". Another problem is sometimes building an app just fails - adding a space char (for rebuilding) just works (not reproduceable - happened most times for me on windows xp). Sure, most basic things work - but sound bugs (or "non-features") are a no-go for a "game programming language". Maybe instead of calling the compilation problems "bugs" is leading to misinterpretation, let's call them "errors". bye Ron |
| ||
| my thought is that even if i write something in Monkey now for 32-bit, the backend is so flexible that 64-bit could be swapped in and my Monkey code will not need to be changed (but will require a recompile). i'm not worried about the 64-bit issue on Monkey. |
| ||
| Tachyon wrote: "We are developers and we should be *ahead* of the curve, not behind it." Yes, especially RPG developers who don't churn out whack-a-mole type games in less than six weeks but need a reasonable amount of time. That's why you don't get RPGs with new game consoles but have to wait at least(!) a year. |
| ||
| Think they mean the bugs concerning linking problems when using the "fresh installed" blitzmax version Oh, but that only affects the lua module. If people didn't include all the modules they don't actually need, then most of them wouldn't get it. Not sure why it is so difficult to get sound working on Linux? |
| ||
| Think they mean the bugs concerning linking problems when using the "fresh installed" blitzmax version (-ldl etc.). I posted a script for installing BlitzMax on Ubuntu 12.04 64-bit (which is really the only version BRL should worry about). |
| ||
| What Linux bugs? IDE Bugs MaxGUI Bugs They have been reported every time somebody asks "what Linux bugs?" over the past few years. Supposedly there are some fixes floating around, but they have never actually made it into an official release. The GUI side under Linux (bugs aside) needs an overhaul as it looks horrid on modern versions of Linux. Unfortunately, Seb isn't around anymore to fix the MaxGUI issues. |
| ||
My favorite IDE crash:Repeat Print "Hello" Until GetChar() I reported this years ago (Windows version. Untested on Mac or Linux). Never been fixed. |
| ||
| We are in the 64-bit era *right now* Are we? How many AAA games are 64bit only? I think we are in the middle of 32bit and 64bit, and have been for awhile... (the first 64bit Unix OS was built in 1985). I can understand the concerns about the OS dropping support for 32bit, but I still believe it is a long way off. |
| ||
| @therevilles: I base this comment on the fact that you can't buy a personal computer that doesn't ship with a 64-bit OS unless you specifically request it. Look at Best Buy, look at Dell- they ship 1000's of computers daily and 99% are 64-bit Windows. I have literally not seen a 32-bit OS in years. My family, my friends all have 64-bit Windows that shipped by default with their PCs/laptops. My kid's school gave the students netbooks with 64-bit Windows installed. My wife works for an international tech firm, and every single laptop they've given out in the past 5 years has had a 64-bit OS. I say this with complete honesty: I do not even know where I could go, right now, to see a 32-bit version of Windows. I'd love to stop by your house @therevilles and see your 32-bit Windows 7....oh wait, you run 64-bit too! ;-) |
| ||
| I totally understand what you are saying, but AAA companies are still creating 32bit games and applications. And you are totally correct about 64Bit CPUs... although I do still run a 32Bit Windows XP for testing ;) As long as the OSes are still backwards compatible with 32Bit there will still be software written in 32Bit. |
| ||
| How many AAA games are 64bit only? Major new ones hitting and that just hit. I can understand the concerns about the OS dropping support for 32bit, but I still believe it is a long way off. It is already here in the case of Windows. Heck, with Windows, it has been here for four years. As long as the OSes are still backwards compatible with 32Bit there will still be software written in 32Bit. Since some are not, that is why so many are concerned now. |
| ||
| Major new ones hitting and that just hit Which ones? It is already here in the case of Windows. Heck, with Windows, it has been here for four years. Since some are not, that is why so many are concerned now As we have already discussed server versions of Operating Systems. And did you know, that MS only dropped Win16 support in Vista... something to think on. |
| ||
| Which ones? There is a thread here detailing the 64-bit games. And did you know, that MS only dropped Win16 support in Vista... something to think on. Did you know that until 2008 MS was still selling licenses for Windows 3.1/11 because it was still being used in commercial aircraft? And did you know, that MS only dropped Win16 support in Vista... something to think on. XP 64-bit doesn't support 16-bit either. Just because you do not need 64-bit, does not mean others do not. Not everybody can afford to support legacy systems. Most have to deal in the here and now. 64-bit has been the standard for some time. Currently OSX is the only major OS that still supports 32-bit on all default install of the various versions of its OS. The same can't be said of Windows and Linux. |
| ||
| There is a thread here detailing the 64-bit games. Thanks! That's good to know that there are a few 64-bit only games :) Just because you do not need 64-bit, does not mean others do not And spin that around: Just because you need(??) 64-bit, does not mean others do... All I am saying is that 32-bit compatibility will be with us for quite a few more years... and you never know BRL might in that time release a 64bit language. |
| ||
| And spin that around: Just because you need(??) 64-bit, does not mean others do... Yet. Too bad when they will, right? |
| ||
| Thanks! That's good to know that there are a few 64-bit only games :) The fiscal year just started a couple of months ago, those won't be the last. There is simply not a legitimate reason to release a 32-bit game in this day and age. Games have outgrown the 32-bit memory limitations and since there have not been any 32-bit systems sold since Vista went off the market. And spin that around: Just because you need(??) 64-bit, does not mean others do... Except that would not be true. If you actually want to release something with BlitzMax and target something other than OSX, you do need 64-bit. All I am saying is that 32-bit compatibility will be with us for quite a few more years... Only until OSX drops support. It is already gone for some Windows users and most Linux users. |
| ||
| You can still run Blitz apps on fresh install of 64bit ubuntu 12.04, without any extra installation required. And 64bit Windows can handle 32bit without problem, so argument about Windows/Linux already dropping 32bit is almost invalid. |
| ||
| You can still run Blitz apps on fresh install of 64bit ubuntu 12.04, without any extra installation required. Ahh and what about pulseaudio VS alsa? By default other audio output is muted if you run an app with "default sound". bye Ron |
| ||
| Ahh and what about pulseaudio VS alsa? By default other audio output is muted if you run an app with "default sound". Is rather hard to release a game without sound. But it is also hard to use a programming language without an IDE. |
| ||
| Even with an ide, it needs to work. The linux ide e.g. still has issues with german umlauts in the source code, it keeps crashing. |
| ||
| I know and I mentioned IDE bugs earlier in this thread. Between the IDE, the audio and the MaxGUI issues, BlitzMax is unusable on Linux. As I said a year or so back, the product really needs to be pulled from sale, until it can do what it says. Many of us, bought it wanting to actually use it on Linux. |
| ||
| I do a lot of my BlitzMax stuff in Linux... using the default IDE... on 64-bit Xubuntu... :-/ (although I admittedly don't use umlauts) |
| ||
| If you actually want to release something with BlitzMax and target something other than OSX, you do need 64-bit. Sorry Gary, but why do you say that? I've been releasing games on Windows over the past few years fine using BlitzMax... Just to be clear (again), I would love a 64bit version of BlitzMax... but I don't think it is critical yet. |
| ||
| Si did send me a ide for Linux which is much better than the out of the box ide :) |
| ||
| Si did send me a ide for Linux which is much better than the out of the box ide :) It is a shame this can't make it into the official distribution. |
| ||
| It was over a year ago that i got hold of it, i do agree its a shame :/ |
| ||
| @IDE and @Brucey: Since the days this IDE had a non-working UNDO-functionality (deleted parts of the code) I do not trust it for other things than getting the debug-panel filled. As you are a convinced "ssh -X" user (I guess :D) you are not missing the application theming of local applications - because the ide looks like a unthemed remote app :D. I cannot name what it is - but the current IDE can hardly compete against a normal editor like gedit/geany (exception is the debug-handling - but this is sometimes faulty on my installations - depending on the errors thrown). For each potential new customer this IDE is just a slap in the face - exception your walls are having posters of 90s AOL screenshots. But the IDE is not the topic of this thread and the IDE also was already blamed multiple times. bye Ron |
| ||
| I'd pay good money for a 64bit version..... By the way, Monkey is not really a Blitzmax substitute. |
| ||
| I'd be happy if BlitzMax wasn't tied to anything specific, and could produce binaries for any reasonable combination of plaftorm/processor (Linux/ARM, OSX/PPC/x86/64, Win/x86/64, iOS/ARM, etc). |
| ||
| @Brucey: Think that isn't a that exclusive whish of solely you :D. bye Ron |
| ||
| We're all programmers (I think?), so why can't we do something about it? |
| ||
| Right cant we make a ide that works on loads of things and a translator that takes blitz code ans translates it to C++ with libraries etc. This way we can forgo the whole argument and port to anything and go from there :) Heck i am working on something similar already as tbh i have grown tired of waiting and the current alternatives are good but arent max :) |
| ||
| Adding an additional translator (bmx2language) will disable/decreases the advantage of fast prototyping / fast recompilation - doesn't it? Also albeit we are "programmers", most of us are surely only "app-developers". So I am one knowing nothing about direct opengl access or directx. It wasn't needed yet (I know, there are many tuts online - I even still have NEHE in my bookmarks). Most of us understand the "basic language" of programmers. We can read code - see what it does, but there are parts which are just "magic". Especially if they do something like "result = otherUnknownFunction(params)". Means: most of us will be able to restructure code, improve readability, standardize things ... as long as the basic code is working. This part is the one we paid Mark for when buying BlitzMax. Before not adding it to this post: There is a thread about a FASM-cross-compiler-addon (currently for ARM) which should enable binary builds for Android. http://board.flatassembler.net/topic.php?t=4191 I would really like to see a "improved BlitzMax" - whether based on LLVM or GCC or ... doesn't matter. But like said... most of us are surely not having the knowledge to pave the way. There are people knowing much about compiler architecture or hardware (think we all know which users I am referring to :D), some of them already stated that it is morally problematic to rebuild the bmk-compiler for improvements, so they might have to get convinced first. So while these workers have to build the ground for further development, we the "app developers" are just able to collect ideas, organize things and work out examples or tools like the IDE (but I think UNZ does a great job there already - with a cross platform tool) or integration in existing editors (notepad++, geany/gedit - for fast and easy access on older systems). If there is enough interest in this, it is better to start a new thread about this topic. bye Ron |
| ||
| I was tinkering with Xcode yesterday - its a seriously superb ide for c++, it makes the blitz one look ancient by comparison. Also Apple have just announced that from march next year, ALL IOS apps (new or updated) Must conform to Ios7/mavericks. In short, compiled with xcode5 and 64bit ONLY. I get the feeling that it's only a matter of time (possibly months) that this will be applied to OSX Apps too. So All BRL products become obsolete then. Who said there was no need for 64bit! |
| ||
| Ouch i thought they would do something like that especially as mavericks was given away, tbh not having 64bit in any shape or form is outdated and obsolete in comparison to the competition. |
| ||
| doom and gloom, doom and gloom... What a cheery place this is ! |
| ||
| Yeah I know, it always happens when a product comes to an end of its life. If they do indeed go 64bit only then max will instantly lose 33% of its functionality not to mention the problems with the linux IDE. |
| ||
| not to mention the problems with the linux IDE. And the issues with MaxGUI on Linux. |
| ||
| Blitzmax code to c++ 64bit... sounds interesting |
| ||
| I just want to see how feasable it is to write a translator to take the bmx files and spit out c/c++ source for compiling etc |
| ||
| I would really like to see a "improved BlitzMax" - whether based on LLVM or GCC or ... doesn't matter. Blitzmax code to c++ 64bit... sounds interesting LOL, Monkey does exactly this. What would be faster and easier to maintain: rolling your own BMax64 transcoder or porting BMax code to Monkey? |
| ||
| Monkey is not BlitzMax. BlitzMax has a superior build system and can be extended with native modules. Monkey has a baked in target system and it's module system is only useful for monkey code and very light layers of native glue. For building desktop apps you cannot seriously compare the two. The best thing for BlitzMax users is if OS X 10.9 went 64 bit only forcing BRL to rethink it's position. |
| ||
| I honestly (still) don't care whether Blitzmax is 32-bit or 64-bit. Right now, 32-bit is best because I (and I'd wager most of everybody else here, if they're honest with themselves) does not *need* 64-bit, and it'll work on pretty much everything. Go 64-bit only, and you'll lose a swathe of customers overnight. |
| ||
| Go 64-bit only, and you'll lose a swathe of customers overnight. And don't have the OPTION to go 64-bit, and you'll slowly lose all of them in years to come. Or quickly, should Apple throw their weight and discontinue 32-bit support with little notice. |
| ||
| I honestly (still) don't care whether Blitzmax is 32-bit or 64-bit. Right now, 32-bit is best because I (and I'd wager most of everybody else here, if they're honest with themselves) does not *need* 64-bit, and it'll work on pretty much everything. Some here develop for Windows, so 32-bit simply does not "work on pretty much everything". Go 64-bit only, and you'll lose a swathe of customers overnight. This is silly. With the exception of some early Windows 7 netbooks, there has not been a 32-bit Window system sold in ages. You can't lose what you don't have. You need to remember the end users are NOT the ones with their heads up their asses on this. They are using 64-bit operating systems. They have already made the switch. It is indie developers who have their heads up their asses and refuse to make the move to 64-bit and continue shoveling out 32-bit products because they are too damn lazy to make the move to 64-bit. I just want to see how feasable it is to write a translator to take the bmx files and spit out c/c++ source for compiling etc If you want an existing product: http://ucalc.com/transform.html Another alternative is to fork BCX or BC9 to specifically deal with BM syntax. For building desktop apps you cannot seriously compare the two. Truer words have never been spoken. |
| ||
| This is silly. With the exception of some early Windows 7 netbooks, there has not been a 32-bit Window system sold in ages. You can't lose what you don't have. That's a bit of an exaggeration -- the percentage of 32-bit windows isn't insignificant yet, but it's definitely dying out rapidly. According to the latest Steam hardware survey, of the windows users just 21.4% run 32-bit windows, and 78.6% use 64-bit windows today. http://store.steampowered.com/hwsurvey/ In the same hardware survey, 32-bit MacOS doesn't even show up anymore, it's all 64-bit. Linux: 0.73%, 64 bit 0.14%, 32-bit |
| ||
| That's a bit of an exaggeration No, it isn't. With the exception of early Windows 7 netbooks, there has not been 32-bit Windows systems sold on store shelves. If you wanted a 32-bit version of 7 or 8 on a new system, it was only available on BTOs. For retail systems, 32-bit simply does not exist. Microsoft does not allow it. 32-bit 7 and 8 systems only exist because of clueless people building their own systems and intentionally crippling their system by installing an OS on it that is not made to run on their hardware. |
| ||
| I think most people here will agree that 64 bit operating systems can't be avoided in the long run. There simply won't be an alterative at some point in time. However, even though we have a good, stable 64 bit Windows for regular PC users with good driver support (Win7 and up, XP64 wasn't really there, yet) not all people have made the switch, yet. For example, I know lots of people who still use XP - on old Sempron machines that aren't remotedly 64 bit capable. And those folks aren't poor - they simply don't need bigger PCs. I know medium sized companies with hundreds of PCs that still use XP Pro on the clients. And not all of them use legacy software (my company uses Office 2003 - can you even imagine that, Gary?). Apart from the hardware many people with an 64 bit OS use 32 bit software for compatibility reasons like Firefox or *gasp* Internet Explorer. And I'm not even speaking of legacy software that many people still have. Software always lags behind (except back then with the folks at Origin who did the Wing Commander series ;-)) and while we have multicores for years now both Intel and AMD introduced "turbo modes" for single-core applications. What good is a 64 bit application if it only supports a single core? Also: a) Win7-32 bit licenses have been sold in stores "for ages" here in Germany. Right now you can buy the combined 32/64-bit package "Full Version" (for regular customers) if you still need 32 bit. You can also readily buy a 32-bit Win8 (!) system builder license in stores - as everybody can be a system builder in Germany, you don't need to sell computers to be one. ("Drawback": You don't get telephone/email support from Microsoft...) http://www.alternate.de/html/search.html?query=windows&x=0&y=0 Bottom line is: Not all people need 64 bit, they get it stuffed down their throats by hardware & software companies that want to sell new products to them. That's fine - but people won't upgrade because other people say it's cool. |
| ||
| The only problem as i see it is simply that making games not utilities everything is going 64bit, basically if ya don't support it its gonna run in the short term BUT will get killed off in the long term (Apple's 64bit only stance has been going on for a couple of osx revisions now). it cant be avoided, you cant stick ya head in the sand. There isn't an option to go 'im working on it' when it happens as its been requested for years and all the competition has versions for it. Personally it looks like 'max is dead, monkey will get it eventually' but as everyone has said there is loads of things that can be done in max that you could only dream of using standard monkey code. |
| ||
| but people won't upgrade because other people say it's cool. People won't NOT upgrade because other people say it's cool. We are not talking about people upgrading though. We are talking about properly supporting 64-bit systems which is what the vast majority of people use and not trying to make up excuses to keep churning out software based on deprecated technology. Using your logic, nobody should be releasing 32-bit software or Windows software for that matter, people should still be releasing DOS software. |
| ||
| We could replace bmk.exe source code with some blitz->llvm/cpp translator, and keep our syntax / IDE. But that's probably forbidden by copyrights. I've already tried adding templates to bmx this way. |
| ||
| LOL, Monkey does exactly this. I know, i made a couple of modules for monkey. But monkey can't be compared to blitzmax. but as everyone has said there is loads of things that can be done in max that you could only dream of using standard monkey code That is so true, monkey's core modules is not that extensive as it might look at first sight. It is pretty limited because it is made to fit all the targets. It is a completely different approach than blitzmax, and it will never replace blitzmax. Therefore, I would pay alot of good money for 64-bit Blitzmax :) Mark my words Mark Sibly ;) ps. Someone poke mark on facebook or something, and direct him to this thread please :) |
| ||
| What is "a lot of good money"? [ ] $99 [ ] $199 [ ] $299 [ ] Specify: _________ |
| ||
| @Polan http://phys.org/news/2011-11-language-copyrighted-eu-court.html Another thing is : BlitzMax uses a basic-like syntax - so if there would be a copyright to a language (syntax) it would be there before BlitzMax etc. Beneath the syntax/grammar there is just "logic" (Functions for drawing images etc) which are declared PD or using 3rd party sources. conclusion: copyrightable "parts" of BlitzMax are the functions to do things (as long as it isnt just a "if 1+1=2 then return TRUE"-function). Syntax is like "spoken language" - the agreement of people to communicate. Languages are not copyrightable. That is why Yasha (i hope he was it) mentioned when he wrote about an bmk-replacement. bye Ron |
| ||
| This is silly. With the exception of some early Windows 7 netbooks, there has not been a 32-bit Window system sold in ages. You can't lose what you don't have. It isn't silly at all. There may not have been a 32-bit Windows system sold in ages, but there are still millions of them in daily use, and their owners have cash in their pockets, which I want.I can't be bothered to reply to the rest of your post. |
| ||
| It isn't silly at all. There may not have been a 32-bit Windows system sold in ages, but there are still millions of them in daily use, and their owners have cash in their pockets, which I want. Nobody is saying remove 32-bit capability from BlitzMax. |
| ||
| I think it's better to put the effort into expanding Monkey than to put effort into BlitzMax 64. For building desktop apps you cannot seriously compare the two. ....so no MonkeyMaxGui? Mind if I try porting it? |
| ||
| I think it's better to put the effort into expanding Monkey than to put effort into BlitzMax 64. I don't. |
| ||
| I think it's better to put the effort into expanding Monkey than to put effort into BlitzMax 64. Two completely different products for two completely different purposes. You really can't compare the two. |
| ||
| +1 for max64 |
| ||
| Like I have written some posts ago: If there is enough interest in doing something (64bit or rewriting something to make it possible at least) we should not use that thread for planning/collecting ... discussing pros / cons (before running in a dead end situation). bye Ron |
| ||
| What is "a lot of good money"? [ ] $99 [ ] $199 [ ] $299 [ ] Specify: _________ I would pay up to $600 or maybe even more... I think it's better to put the effort into expanding Monkey than to put effort into BlitzMax 64. I don't. I couldn't agree more with "I don't" |
| ||
| $600 ... seriously? I give away my apps for free, I try to use as much as possible free of cost tools (blender, gimp and inkscape, writing in LO/OO). I know that there are FOSS compilers available. But you know: once fallen in love it is hard to find a new one. I am way more willed to pay in "man hours" than with money. bye Ron |
| ||
| I seriously think it'll be worth it :) It'd be a one time payment for years of development... Doesn't matter for me I also give away most of my creations... |
| ||
| What is "a lot of good money"? [ ] $99 [ ] $199 [X] $299 [ ] Specify: _________ I would pay what I have checked without thinking twice. BlitzMax is one of the most versatile and most productive programming languages I have ever used and it does not sacrifice power. However, I would only pay that if the Linux issues were gone including having something usable for MaxGUI on Linux. FLTK is simply not acceptable. OSX side of MaxGUI would need to be up to date, too. |
| ||
| I would support a Kickstarter for BlitzMax to bring at least 64-bit and built-in streaming OGG support to it. |
| ||
| I think kickstarter is the way forwards, i just feel sorry for the users who just bought it only to find support is non existent for all its faults. |
| ||
| @rs22 I use redis MaxMod (rtAudio) for ogg streaming. It is a bit problematic to setup to work flawlessly, but afterall it seems to work. But yes, a more flawless approach would be nice :D @kickstarter Without enough "buzz" from users a kickstarter campaign just fails - which will lead users to think about it again - which may lead to further "goodbye threads". I cannot imagine the user base of BlitzMax being that high at the moment. Dead horse appearance etc... That is why most of the work on a project seems to be done already when they start with kickstarter (... it _seems_ to be done ...!). So translated to BlitzMax the work should already have a paved way to get finished. Kickstarter is then used to finance the development and secure potential investments. bye Ron |
| ||
| Yeah true, I'm gonna look at making a language translator in c++ and have some c++ include libraries that perform vital functions etc in the end who knows it could be good enough maybe not but its something I would like to have a go at :) |
| ||
| Thanks for answering my question, guys, even though it perhaps won't have any chance to get realized. For those who are interested, I would pay $199 for a 64-bit BMax - and I don't even care if a 3D engine is included or not. I'm not selling any programs so it's only an "amateur budget", but I stand by it, even if it takes one or two years from now. |
| ||
| What is "a lot of good money"? [ ] $99 [ ] $199 [ ] $299 [ ] Specify: _________ $99/yr subscription. |
| ||
| That its reached 255 posts shows there is interest and its something that needs sorting :) |
| ||
| The Game Creators have certainly been successful with Kickstarter and funding development. |
| ||
| That its reached 255 posts shows there is interest and its something that needs sorting :) But all of those posts are made by probably less than a dozen people (I didn't count, but it's normally the case), and not all 255 posts are in favour of it anyway. |
| ||
| But all of those posts are made by probably less than a dozen people I lost count around 46-ish individuals posting. Even then if there was a thousand individuals. I can't see there being a version of BlitzMax that can compile to 64bit. |
| ||
| That its reached 255 posts shows there is interest and its something that needs sorting :) Think of it this way, if BRL makes a 64-bit BMax, then they'll have to support it. Supporting two immense projects by one person will take years off your life and your kids will grow up without you. IMO, I think it's better to accept that there will be no "official" BMax64 unless BRL expands and starts hiring, which probably won't happen. It's a niche product, like PureBasic. |
| ||
| Yeah true, but even purebasic has had a 64bit compiling option for years. Its sad really that BRL seem so far behind everyone else on that one point. |
| ||
| Is there any kind of `converter` that can take a 32-bit application exe/binary and convert it into a 64-bit version? Why doesn't a tool like this exist, or does it? Or are is the complexity of various dlls/libraries/apis etc too much to figure out how to rewire or whatever? |
| ||
| My understanding of it is that 64 bit processors can use 32 bit apps with the registers etc but its the os support that is being got rid of as it were. Its a bit like dosbox can play many does games that we used to play but windows can't as its not a properly supported even though it has a dos like cmd program. |
| ||
| It's a little bit off-topic. But has anyone ever showd interest in publishing BlitzMax on steam? I think it could increase sales a lot. Boosted sales could lead to more support which could lead to a 64-bit version!? -lukasha |
| ||
| So you think the hardware will support 32-bit longer than the o/s? what happens when the o/s drops 32-bit support, what incentive is there for the manufacturers to keep it in their hardware? My thought is that at some point long ago Mark looked at the fact that mobile and other platforms were on the rise and couldn't see an easy way to turn BlitzMax into a more cross-platform solution without lots of compiler writing. I think he saw that it had life in it as it is, but that when it was designed it was in times pre-mobile when all these other platforms weren't so important. I think then he realized his product line had a limited lifetime and that he did not want to put in the effort to 64-bit-ize things either, so instead looked to making it a more abstract system - ala Monkey, to be able to get more platforms supported. That seems to be where his heart is now, especially given he's made mention of work on a 3d module for Monkey which is something that never saw the light of day for BlitzMax. It appears Monkey is the future and BlitzMax will simply remain as it is going forward. That's not to say it still wouldn't be greatly appreciated to see Max's future extended to 64-bit support... but I think it's quite unlikely and that Mark just doesn't have interest in doing it, even if it's possible. I'd like to see Monkey expand to have proper GUI support, perhaps support for pointers (I use them a lot), multithreading, 3d engine, etc... so that it can properly take the place of BlitzMax for application development and then support 64-bit more easily too. |
| ||
| Yeah true using monkey does seem easier (after setting it up) than max in most areas. there isn't a link on the monkeyx page to here anymore either |
| ||
| what incentive is there for the manufacturers to keep it in their hardware? Hundreds of millions of dollars in cost to remove it. This is part of why the Intel architecture is so flawed as it still has instructions from the 8086 chips in it, that haven't been used in decades, but are still in there. Costs too much to remove them. So the way of dealing with the bloat is shrink things. |
| ||
| @GaryV: for once i agree with ya. Its also the reason why things like ARM processors etc are taking off as they don't have to be tied to outdated archaic hardware that tbh is never used these days at all. who here regularly uses a 8086 program? |
| ||
| Could a path to 64-bit max possibly be to convert all the max code into regular C code? |
| ||
| I think that's the path monkey took with its conversion to glfw or msvc |
| ||
| what incentive is there for the manufacturers to keep it in their hardware? Why doesn't a tool like this exist, or does it? Or are is the complexity of various dlls/libraries/apis etc too much to figure out how to rewire or whatever? It is still useful to have the functionality exist as a subset when manipulating smaller data types etc. The big issue is that the abi conventions were changed, which pretty much makes all function code incompatible. |
| ||
| If Blitz Max and it's apps already work on Mac OS 10.7+ and Windows 7/8 x64, doesn't it already support the 64-bit architecture? |
| ||
| CWS: No, Blitz Max only runs under emulation on 64-bit versions of Windows. |
| ||
| If Blitz Max and it's apps already work on Mac OS 10.7+ and Windows 7/8 x64, doesn't it already support the 64-bit architecture? No the OS is 64bit running on a 64bit architecture. Basically on a Windows 32bit program runs with a emulation layer. Read about WoW64.Now as for Macs. I can't find any clear information on exactly how it does it. Whether it uses something like Universal binaries or Rosetta. But you could select which kernel to use at boot-up in Snow Leopard and Lion. Linux is a doddle as long as the core 32bit binaries are installed. |
   |