I would pay for...
BlitzMax Forums/BlitzMax Programming/I would pay for...
| ||
| ... Blitzmax 2 - updated blitz3dsdk, updated oop gui framework, integrated database support (postgresql, sqlite,...) Blitzmax is a beautiful language (Syntax), but I think its a dead end, I would love it if it would be more suitabe for application programming and has an updated game lib. I don't need game programming that much, but thats the purpose of blitzmax... The whole Blitz product range looks to me like its about to die. Monkey could be named Blitzmax 2, but its so... game only :( What do you think? |
| ||
| Monkey could be named Blitzmax 2, but its so... game only :( Yep... |
| ||
| Since blitzmax already does most of what you asked for via certain user mods i don't know how you've come to the conclusion that its dead. |
| ||
| Blitzmax is a beautiful language (Syntax), but I think its a dead end Bit like saying C# is a dead end. I know what your saying but if you want to do applications there are much better choices out there. But then the focus has always been games.There are lots of modules (a large number by brucey) that do most of what a application would need. As with any programming language though it can be done if you write your own modules to do it. What your asking for is more to be done for you out off the box. The whole Blitz product range looks to me like its about to die. I wouldn't say that, Monkey looks like its growing nicely and max is a well supported language still, the forums are still quite busy so nothings dead yet. |
| ||
| Just got there before me Gfk ;O) |
| ||
| Monkey is great for ease of development of phone apps... |
| ||
| Although I'm only interested in games, Monkey still involves too many platform details for me. I'm waiting for: Press one for iOS, Press 2 for Android, etc. Mark is correctly focusing on the future of electronic gaming which is mobile. (Won't comment on developers chances for mobile profits). BlitzMax is a mature, near-perfect Basic PC language. I'd gladly pay $40 (US) each year just to keep it current for Windows 8+ and OSX (Intel) 10.7+. Dropping Mac PPC and Linux (ouch) would be OK by me. Perhaps Mark could assign BMax to someone else and just act like a consultant on tricky issues. The idea suggested for a BMax store for free/paid modules is also interesting. Individual module makers would be responsible for keeping compatible with latest BMax versions. I don't see BlitzMax stealing any Monkey customers. Mark may not have time for both! |
| ||
| I wouldn't call it near perfect but yes it's good. and I wouldn't mind paying an updating charge as I think it has a lot of use left. |
| ||
| The main thing I would like improved with BlitzMax is the debugger. I'd pay for it. Ability to set breakpoints at run time, ability to change values in varaibles. |
| ||
| Yes better ide features like better debugging would have been nice but i think if they were going to happen they would have already. Plus there's some nice 3rd party ones out there. |
| ||
| I was just discussing this the other day. I am not particularly fond of Monkey- I wish BRL would not have spent the resources on it and instead made BliztMax 2.0 with: - Integrated (and officially supported) MiniB3D. - Better debugger and IDE. - The ability to compile to iPhone and Android. I think it is critical to support mobile platforms, but was it really necessary for BRL to develop an entirely new language to do it? If I am going to spend the time to learn a new platform for mobile development, it's going to be Unity, not Monkey. For the record, I would have gladly re-purchased BlizMax 2.0 for twice the price of Monkey if it had the above additions, |
| ||
| My biggest gripe with Monkey - or certainly the biggest issue preventing me from moving to it, is that I have a huge Blitz3D/Blitzmax codebase - the two are vaguely interchangeable with MiniB3D, but Monkey doesn't have that luxury. I wouldn't write a Windows/OSX game with Monkey, nor would I want to write the whole thing twice to cover all platforms. |
| ||
| -Get rid of GC and use C++ style memory management. It would make it faster and easier to work with. -Decent multithreading. See previous point. -Debugger that's better at tracking down those random mem bugs that move around when you try to find diagnose them. -Officially supported MaxGUI. Doesn't need any new features I can think of, just make sure it is part of the official package. -Less intrusive BRL mods. -Better support for C++ code import. -Always require Framework and Superstrict. -Case-sensitive! -Official support for DLL, DYLibs, and static libs. -Generally more professional, less game makerish. I'd pay $1000 for it. Last edited 2011 |
| ||
| -Case-sensitive! No! NO! NOOOO!I would pay, too if it would guarantee that it will keep up2Date on at least MacOS and Windows (x64). There would be some changes I'd like to see, but in general it is a beautiful - but by now slowly dying- language. C'mon Marc, keep support u for this Jewel. |
| ||
| Get rid of GC and use C++ style memory management. It would make it faster and easier to work with. C# approach is much better than C++ one. You can decide if a class is managed (with GC) or not, so you can leave GC for high level and use unmanaged classes (like c++) for fast/lower level stuff. |
| ||
| Blitzmax to LLVM. |
| ||
| @AdamRedwoods: +1 |
| ||
| No! NO! NOOOO! Yes, yes, yes: Local image:Image=New Image You can decide if a class is managed (with GC) or not, so you can leave GC for high level and use unmanaged classes (like c++) for fast/lower level stuff. BlitzMax's problems with DLL support and multithreading arise from the use of garbage collection. It was fashionable a few years ago, but time has proven that GC is a dumb idea. |
| ||
| You mean proven in the Salem Witch Trials sense of the word, right? |
| ||
| GC is a dumb idea. Making life "easier" for the programmer is the stupidest reason to introduce a slow non-deterministic paradigm into software design. Managed languages will never become popular for building critical systems or AAA games for that matter. Last edited 2011 Last edited 2011 |
| ||
| Josh, so you can name one(!) image like the class ist is, but you will get an error or warning for every time you missed to hit shift when typing a varname. Thats not good in my opinion, and the benefit ist far lower than the disadvantages. I gladly have only one var image in TImage, be it typed iMage, Image or IMAgE, as this gives me an easy-to-use language. Superstrict is very good, as it prevents from making errors, but case sensitivity isn't as it opens the door for much annoying typos. Last edited 2011 |
| ||
| It seems C++ does everything you need already, and you've got a lot of C++ code to boot. Why pay for C++ Basic Syntax Edition? Remember the target audience. Not everyone is as good a programmer as you. I've seen professional C++ programmers make stupid memory leaks all the darn time. Imagine the trouble for beginners. Optional manual management for certain types could be useful. But GC is one of the main reasons I want to stick with BM. |
| ||
| absolutely agree to this. I love BMax for it's basic-like approach. That's why i bought it, and I only would like minor flaws removed and it kept up2date. |
| ||
| If you're a bad programmer, you should agree with me, because garbage collection makes it harder to keep track of your memory. Without GC you can just watch the program's mem usage and see right away if something is wrong. With GC, your mem usage dances all over the place, and you never really know what is happening. It seems C++ does everything you need already, and you've got a lot of C++ code to boot. Why pay for C++ Basic Syntax Edition? Because I can put out cross-platform windowed applications in 10% the time it takes anyone else. Virtually no one makes windowed applications in C++ anymore, and C#/WinForms isn't cross platform. The fact that no one can see the potential here is absolutely mind blowing. If this was my product, I know exactly how I would craft the message to the public, and I could have it covered in all the major tech magazines. |
| ||
| double post Last edited 2011 |
| ||
| I want a function that takes arrays which are sometimes managed elsewhere and sometimes will need to be deleted inside the function and I want this to happen automatically. If your language can do this I'm happy. But no case sensitivity. |
| ||
| Don't some ides correct case errors for you, for languages that are case sensitive? wouldn't this be the answer? |
| ||
| No. Visual Studio C++ intellisense is absolute..... rubbish. At the very least, after typing the name in lower case you then need to press ctrl + space to get it to correct. It's not like Blitz IDE where you type "if" and it becomes "If" all on its own. It also won't help if you have two things with the same letters in the name but different cases. But that's bad practice and frowned upon. It's super-important to have that ability to hand though, just in case. Maybe? Last edited 2011 |
| ||
| I'm not really arguing for or against anything because I feel programming languages are like flavors of ice cream.... we all have our particular wants. If you're a bad programmer, you should agree with me, because garbage collection makes it harder to keep track of your memory. I am a bad programmer BECAUSE I don't care about managing my own memory. :D All aside, I thought one could disable the GC in Blitzmax. |
| ||
| Not really. You can suspend it from collecting objects, but that means dead objects will pile up until you run out of memory or resume the collector. |
| ||
| You can suspend it from collecting objects Does that mean even if you set an object to NULL we still need the garbage collector to do the real work of disposing it? |
| ||
| I think so ? |
| ||
| Yes, we don't have a functional Delete or FreeEntity\Sound\Image\Bank like in Blitz3D. |
| ||
| GC is a dumb idea. Making life "easier" for the programmer is the stupidest reason to introduce a slow non-deterministic paradigm into software design. Well, it's deterministic and honestly, with multi-core processors it's fast and reduces development time and costs. Automatic memory management cuts your development time in half all by itself - not only because you write less code, but also because you never have to track down "double free" problems and you don't have usually memory leaks. Also, managed languages prevent buffer overflows or other C-related security vulnerabilities. Additionally, in managed languages strings are handled the same way in all code (no more converting between various string representations) The .NET standard libraries ("BCL") have more capabilities than those of C++, and the STL is more cumbersome (object->my_vector.erase(object->my_vector.begin() + index), anyone?) As an example (now talking about C#) Unlike C++ templates, C# generics are guaranteed to work for all type parameters, do not bloat your code size, and can be used by modules linked dynamically (mind you, C++ templates can do some things that are hard/impossible for generics, but advanced use of templates is difficult) Also, managed languages with JIT based such as Java, C# or languages targeting the LLVM can target a mobile device (ARM) and run the same binary on your desktop PC Additionally, on managed languages you no longer have to manage *.h files and write every declaration twice. Well, you can leave short"inline" functions in the .h file, but you'll pay it later with slower compile times. Also, The need to use a different syntax for member functions in the header file than the in the implementation is horrible. Consider the difference between the header file declaration "virtual std::string Name(bool longForm = false);" and the cpp file equivalent "string ClassName::Name(bool longForm) { ... }". Not to talk about modern managed dynamic linking and reflection that makes it easier to develop and support plug-in architectures, and to use 3rd party libraries without compiling them. Also, on managed languages, no more dependency-detection glitches where you change a struct or virtual function table but not all dependencies are recompiled, leading to bizarre and unpredictable run-time behavior. In C# I never see such glitches, and if they did happen you would get a run-time exception rather than weird crashes or strange behavior. |
| ||
| @Kryzon Thanks for clearing that up :-) |
| ||
| GCSetMode( mode ) obj = New Object ''do stuff obj = null GCCollect() |
| ||
| I mean with dead end: I don't believe that there will be further development in blitzmax itself. Sure, the community supports with forum activity and modules, but where could be blitzmax in 10 years? In long term i don't see a future in this language. |
| ||
| I don't believe that there will be further development in blitzmax itself. Sure, the community supports with forum activity and modules, but where could be blitzmax in 10 years? In long term i don't see a future in this language. I think it's open enough to grow as long as the target architecture is supported, so I think it still has a great future. |
| ||
| Adam, that is not manual memory management. When you call GCCollect, any dead objects may be collected. You cannot choose just one. You also cannot forcibly delete an object which still has references to it. Even in that example, there is no guarantee that the dead object you just made will be collected that call. Last edited 2011 |
| ||
| I think it's open enough to grow as long as the target architecture is supported, so I think it still has a great future. The (current) lack of the ability to create 64-bit executables may start to become an issue at some point though, as can be seen under Linux where many of the 64-bit installs no longer come bundled with the 32-bit libraries that Blitzmax needs. |
| ||
| I would vote to keep BlitzMax pretty much the way it is. Basic+. Drop Mac PowerPC and Linux (1%, nothing personal). Adapt to Windows 8 and OSX 10.7. Improved debugging might be helpful. Sure hope Mark assigns (donate/sell/merge/other) BlitzMax future development to someone else while he focuses on Monkey/Mojo. Brucey? Would love to see BlitzMax around in 5 years -- if my mind still sorta works! |
| ||
| Drop Mac PowerPC and Linux (1%, nothing personal). Drop Linux? No way! 1% does not mean that 1% of the community uses the Linux. Last edited 2011 Last edited 2011 |
| ||
| Where is this 1% stat coming from? When I beta tested my game the OS ratio for the testers was Windows 77%, Mac OS X 13%, and Linux 10%. I wouldn't be too happy if I suddenly lost 10% of my potential customers. |
| ||
| Where is this 1% stat coming from? When I beta tested my game the OS ratio for the testers was Windows 77%, Mac OS X 13%, and Linux 10%. I wouldn't be too happy if I suddenly lost 10% of my potential customers. But how big was your demographic and where did it come from? Is it really indicative of your average consumer? |
| ||
| There is no point arguing about whether Linux should be supported or not. This is to collectively fantasise about new features, not get rid of them! |
| ||
| @GfK: The testing pool was ~3,500 sourced from twitter, reddit(r/roguelikes), indieDB, and indiegames.com. In all 10,000 people have downloaded the latest beta of my game and their OS ratio is similar to the testers. I think they are probably indicative of my target audience. |
| ||
| @outsider: I thought Linux was only 1% of all installed PC operating systems. Plus, aren't Linux folks naturally averse to paying for software? Again, nothing personal. Love the idea of Linux, however... @Czar Flavius: I think BlitzMax users are more likely to see BlitzMax 2 or even BlitzMax 1 maintained for a few more years if the scope of the job is pared down. Was going to suggest Mark also support WebOS in Monkey. Ouch. |
| ||
| We count on continuity of the existing BMAX on all platforms. They reason why we changes from VB to BMAX was the chance of porting code to OS-X in combination with fast speed on canvases and the big amount of modules (god bless brucey!!!) Therefore we buy since years any software from Mark (independent whether we need it or not :-) ) only as a tribut to his work and in hope that he will continue to update the code to new requirements. For us it is not so important to upgrade to new features, because we "can live" with the actual state. But we need the support of BMAX for WIN 8 and OSX10.7 in coming months. Of course we also bought a first MONKEY, but we think at the moment it is not in a state of replacing BMAX. to much bugs, to less modules, to many restrictions, to slow speed. So we see no chance, then to keep BMAX up-to-date. And I think there is no statement from Mark, that we will not continue with BMAX, or? In the forum we listen to voices, whispering of an end of BMAX, but is this really planed? Our current level of knowledge is: BMAX has a future and Mark will still support it. Or am I wrong? Perhaps Mark or Brucey could say something definite to this! Mark, please continue in BMAX! And yes, we would pay for this! p.s. excuse my bad english... |
| ||
| I'd pay money for a new debugger!!! Other things I can live with, but this is slowing me down the most. I'd also like lists and maps of specific types. It doesn't need templates, just automatic casting when I use First() etc would tidy up my code. |
| ||
| But we need the support of BMAX for WIN 8 and OSX10.7 in coming months..... Mark, please continue in BMAX! And yes, we would pay for this! YES, and thanks for BMax! |
| ||
| I believe, I read somewhere, a while back that Mark had no intention of making Blitzmax work on 64 bit compilers that he didn't want to go through all that work to do that. I am obviously paraphrasing but it was something like that. I would definitely pay for the upgrade, if he made it compile for 64 bit processors. |
| ||
| What would be difficult about it? (Genuine question, I don't know about that stuff) |
| ||
| The compiler writes assembler for the x86 architecture, it will have to output AMD x64 architecture, wich is different. This affects from instructions used to mem allocation, etc. I won't say it would be as rewriting the BlitzMax compiler from scratch, but it's close to it. Maybe a better approach would be to use the Monkey compilation strategy to output C++ code and use the GNU compiler on any target. But this is just my small 0.02 cents comment of the day... |
| ||
| Maybe a better approach would be to use the Monkey compilation strategy to output C++ code and use the GNU compiler on any target. But this is just my small 0.02 cents comment of the day... Top idea!!! Blitzmax is a beautiful language (Syntax), but I think its a dead end, I would love it if it would be more suitabe for application programming and has an updated game lib. I don't need game programming that much, but thats the purpose of blitzmax... I like Blitzmax, it does (with 3rd party mods) everything I ask for in regards to desktop game development... When it comes to that, the only limitation I have is me! :D And that only boils down to my iffy artwork! :) If Blitzmax doesnt float someones boat, or isnt 'enough' (Which is insane really), then there are plenty of other options out there, more importantly, nowadays, they are probably free too. Though, if they are'nt enough either, then does this really boil down to a language related problem? Dabz |
| ||
| @Oddball Just a clarification regarding Linux. Is your experience of 10% 'market share' regarding downloads or sales? Cheers. |
| ||
| output C++ code and use the GNU compiler on any target. because you need objective C for mac/ios , java for android and C# i believe for xbox so C++ isn't an option.Or did you mean to get round the 64bit issue? Last edited 2011 |
| ||
| I meant for the 64 bits issue, but it was a dumb idea. It would be much better to port the brl libraries to monkey, even if only mac linux and windows are supported. |
| ||
| the problem I can see for monkey is that only the basics which it already has covered will work on all targets, anything more advanced like collision detection and some graphics stuff will need to be platform specific. So you will still have to know a bit of the language that the sdk of you target uses to fill in the gaps or add advanced features. So porting the modules of max over to monkey can't really be done because they use platform specific api calls. Last edited 2011 |
| ||
| John G wrote: @Oddball That is purely the data received from the beta testers. The download stats are similar but I can't account for re-downloads and failed/cancelled downloads so I didn't post them. I have no sales data yet as the game isn't released, but I'll happily provided it once I do. It is entirely possible that the stats may be skewed due to things like Linux users being more likely to help with feedback so don't take my data as gospel. Just use it as another perspective.Just a clarification regarding Linux. Is your experience of 10% 'market share' regarding downloads or sales? Cheers. Last edited 2011 |
| ||
| I like the 'Game Dev' focus of BRL products. I bought B3D and BMax for that. Monkey will replace BlitzMax, within a couple of years, even on desktop platforms domain. Atm is well far from being a mature product, and I'd never begin a demanding project relying on it, but I rely on Mark and his skills. :) Anyway I'd like having more professional features in its IDE, such as runtime debugging, with dynamic breakpoints, watching expressions and a more interactive inspection of variables and objects involved in the process, so that all the effort provided in development could simply and swiftly apply to all targets with a single magic click on "deploy for..." button, just like happens on Unity and Shiva. Developing games is not a game, so having a serious tool to assist me interactively in my task is a strong requirement. If Monkey implemented a full featured debugger, I'd just be an happy developer. 64bit and multitasking support may eventually come in a near future but, focusing on mobile markets, they're not strict priorities, you know. |
   |