BlitzMax or BMAX-NG?
BlitzMax Forums/BlitzMax Programming/BlitzMax or BMAX-NG?
| ||
| If someone was to target only desktop for developing indie game and making some bucks with them on Steam and these kind of sites, which would you choose? |
| ||
| Since you mentioned Steam which is desktop only then go with plain old Vanilla, unless you need that 64bit feature with NG. Not all modules are compatible or not yet supported in NG, that's all I know. In the long run, it's not that hard to convert to NG once you got used to it. |
| ||
| If you start from the "basic" (not reusing framework code of others) you could start with NG as you get overloading support and other convenience-features. Also you benefit from the GCC optimisation (should run faster in some cases). If you are afraid of bugs - use vanilla (even the NG-issue-tracker just got a bug in brl's TMap implementation - so there are surely other bugs hidden in "plain old vanilla"). bye Ron |
| ||
| Grey Alien Games used NG for their 64-bit Linux build of Regency Solitaire... |
| ||
| Thanks for the input. I will try it again. |
| ||
| Oh hey Mike, are you also planning to port your fantomX framework to Blitzmax? just wondering but if that is the case, do it with NG. ;-) |
| ||
| I don't know. But why do you suggest? Is NG different from BMax, means you need to code differently? I already hate the differences MX->M2. |
| ||
| I don't know. But why do you suggest? ah yes, so you can port it to mobile platforms not just desktops. Android and iOS already works, not sure when or have not tested with emscripten. Is NG different from BMax, means you need to code differently? Not different but a few changes/additions and I think some related with 64bit support. Brucey, Derron and the guys can elaborate on that. I already hate the differences MX->M2. same here, MX is still nice though. |
| ||
| Not different but a few changes/additions... I ment this regarding the core language and data handling. Can I handle container and iterate through them the same in NG compared to BMAX? Do I have to set up the app in my code differently to get the same result? For an example in MX you could easily iterate through a container and dynamically add/remove list items while doing so. Not in M2. The app setup and corresponding callback events are changed in M2, so you need to do things differently. M2-Mojo works different from MX-Mojo2. Importing assets works differently. And so on. |
| ||
| Do I have to set up the app in my code differently to get the same result? On a few cases yes, but pretty much it's the same. I don't know about MX container but I think you can do that with NG or Blitzmax I thought you already know a bit about BlitzMax but I would assume now your first BRL product is MX? As for the assets, yes it's different from MX where you put it in data or asset folder. You can pretty much decide and put it anywhere you want, no restrictions there. I have not worked in MX or MX2 that long, so I can't give any detailed comparison. You can read some post regarding Blitzmax vs Blitzmax-NG compatibility issues being reported here, most posts have some info on how to resolve them. |
| ||
| Thanks, I know some of BlitzMax. Used it before for tools. And before that Blitz3D. Guess I should just try to use NG with the old sources I have and see how it reacts. And I wasn't after the difference between MX/M2 to BMax but the difference between BlitzMax and BMax-NG regarding its core language and data handling. Basically can you load up a blitzmax source into NG and it works? I am comfortable with Blitzmax. Never mind, I will just try it out. |
| ||
| Ok great. have fun :) |
| ||
| Basically can you load up a blitzmax source into NG and it works? In principle yes, but it depends. NG is mostly backwards-compatible, but it is also a work in progress and still has missing features and bugs. A small, simple BlitzMax program might run without changes, a more complicated one is likely to require some adjustments and fixes. |
| ||
| Do you know what is missing in NG? |
| ||
| > In principle yes, but it depends. NG is mostly backwards-compatible, but it is also a work in progress and still has missing features and bugs. A small, simple BlitzMax program might run without changes, a more complicated one is likely to require some adjustments and fixes. I can compile my game TVTower in it ... and this is not the smallest game (4.2 mb of sourcecode - ignoring external libs like libxml) The game was kind of a "testbed" to make NG more and more bugfree (seems I tend to do things "uncommon" - which exposed some bugs). It uses: - various image formats - image manipulation - dx / ogl - ogg sound via rtaudio - lua scripting - file access (savegames created by reflection) - OS events (appterminate, appsuspend, ..) - ... What it does not use is "threads" (read: threads from within BlitzMax, not done in C-files). I also do not use joysticks or so (but Brucey used them in the Digesteroids-NG binary for Android). So at the end I use much of the provided brl/pub-modules. "language/base-modules-wise" I use arrays, maps, listedlinks, am iterating over them, directly accessing them ... Same for string manipulation and object exposure to external engines (lua). Debugger works too as it helped getting rid of some problems. What differs: - reflection is similar to vanilla but allows for some more things (similar to "reflection extended" by the user grable) - for android/... other platforms you might need to import some other modules (like "sdl.sdl"), you could do this within ?bmxng or ?android conditionals - there are new conditionals (?bmxng, ?android, ?win64 etc.) - in vanilla they are read as "false" (so not executed) For now I would say: if it runs in vanilla, it runs in NG. If it runs in vanilla but NOT in NG, then it is >99% a bug. What benefits do you get from NG? - 64bit binaries possible (with the corresponding new numeric types) - final code (c-files) is optimized via GCC rather than being just processed by FASM at the end - Brucey eg. converted Marks "Mojo" code to NG (not that easily possible with vanilla because of the following point) - interfaces added (allows to link in things which would not be able by just polymorphism) (-> code not backwards compatible if used) - structs added (eases wrapping of external libs) (-> code not backwards compatible if used) - conditionals are real expressions now ("?bmng and not android"), not possible with vanilla (-> code not backwards compatible if used) - IOS and android support (touch-actions via SDL-module) And disadvantages? - compilation time is a bit higher (at least for me. My game compiles with vanilla in 1min, the latest - and optimized regarding that issue - NG compiles in 1:30) - there might be bugs (getting less and less each time) If you have nothing to loose and are willed to help squashing bugs, then go with NG (use the MaxIDE for NG then, it has support for new compilation flags and targets). If you want to make sure it runs for "everyone" (needed if you think of selling it), then of course use vanilla. If it is a module and you do not bother to provide the sources, you might even use the advantages of NG in your module and just use the precompiled modules then with vanilla (dunno if that works, but it should - if you use the same mingw-libs). bye Ron |
| ||
| Got Defenstar running on it a while back but crashed because of some GC problems. |
| ||
| @ Playniax Try it now - and of course as a debug build. bye Ron |
| ||
| @Mike Hart, There's also a Mojo2 port by Brucey for NG. I'm not sure if it's a complete port but the demos are awesome :) https://github.com/bmx-ng/mky.mod so I think it should not be a big problem at least porting your fantomX code to NG. |
| ||
| I've converted some large projects to NG so i'll just add my 2 cents. PRO: - Runtime speed and GC. the NG GC is effectively just as good as vanilla bmax. I'd say (anecdotal) that about 80% of operations are slightly faster in NG. - Threading. Threading under vanilla bmax is an abomination. NG doesn't have these issues. leaks are rare and you get the full speed of single threaded. Huge plus! - Android. Having the option to make android apps is a nice plus. I've written a few games and even a realtime audio synthesis app with NG for android. The build process is slow and a little frustrating, but it works and it's nice having the option. - Brucey bugs seem to get fixed pretty quickly and improvements are happening pretty steady. (structs, sse, etc..) -vanilla bmax is frozen vanilla bmax is super stable but has no maintainer will likely not see any improvements. CONS: - debugger This is a huge con for me. Globals and constants are missing from the debugger. This is why I mostly prototype my apps in vanilla bmax and later compile them in NG. If I encounter a bug I often have to go back to vanilla bmax to use the debugger or do hacky things like cast the a global to local scope for debugging. this puts a lot pressure to make my programs constantly compatible between the 2 versions. - modules Most 3rd party modules wont compile without error. sometimes the errors are numerous enough that it's not worth it. Most of the time this down to the way modules will import C code which is different between vanilla and NG. - native apis and dlls dealing with the windows api is always a hassle with NG. Compiling dlls with vanilla Bmax is easy, I've not tried it with NG, but I can't imagine it would go smoothly. - documentation (bmk) BMK is wildly altered compared to vanilla bmax and almost all of it is undocumented. It is certainly more powerful though. - Compile times without the '-quick' option, compile tiles are ridiculously slow (40+ sec) for a "hello world" type program. Most of the time is not an issue though. - Not 100% compatible with Blide. release builds work but debug builds have issues. Again, not i huge issue. Even with these cons NG is pretty stable for me and the advantages far outweigh any disadvantages. It's the future. www.bmx-ng.com explains how to build the most current versions. |
| ||
| @ compile times Maybe you are compiling from a slow HDD, the -quick param is there to skip the "auto build modules if needed"-lookup. I once wrote with Brucey about that, because I had longer compilation times than he had, so the result was this -quick param. Latest BCC incarnation had a good speedup on compilation times (truncated 2min compilation to 1:30, this is a 25% speedup). @ debugger Raise an issue for globals so Brucey has it on his "todo" (aka open issues ;-)). @ bmk Has vanilla a documentation for it? Else running "bmk[.exe]" without arguments will shed some light. Also for "documentation" I raised an issue long long time ago - that somone of the community might lend a hand regarding this, to take of some workload from Brucey... someone with a good knowledge of "English", so maybe someone speaking it natively. @ modules if the module is a "bigger one", Brucey often brings them to "maxmods" and adds some compatibility things so it works with NG. Maybe your problematic module is already there? It is in every case a good thing to use maxmods/brl.mod and pub.mod as there were some issues resolved (compared to vanilla one). bye Ron |
| ||
| Thanks again for the detailed explanation. NG will definitely be on my list. |
| ||
| @ debugging with globals and consts They are showing up for me when debugging on Windows... Perhaps you are using an older version? |
| ||
| Brucey, what is the easiest way to get a full current version of BMAX-NG? You have everything split up in its own repositories I think. The complete download I know of is already 8 months old. Any suggestions? |
| ||
| Download everything separately and compile it. Or download latest from Https://github.com/bmx-ng/bmx-ng/releases Then update modules via github (brl and pub and whatever you need) Fetch latest bmk and bcc sources... Compile them with vanilla (at least I do it that way). Copy the new binaries to your release download (copy newer *.bmk files from bmk too). Then recompile all modules (to make sure) and you should have a bleeding-edge-current bmx-ng. Bye Ron |
| ||
| Download everything separately and compile it. No, I wouldn't advise that at all. The latest release is from July. (see https://github.com/bmx-ng/bmx-ng/releases ) If I get some time at the weekend, I'll see about doing a new build - which will add Operator overloading and support for Private/Protected Type members, in addition to some bug fixes. |
| ||
| Thanks Brucey, I can wait. |
| ||
| > No, I wouldn't advise that at all. Which is why I also described the "better suiting" approach. But it only helps getting things like maxide and docmods in one download. Bye Ron |
| ||
| I use the Frisky program from bmx-ng.com to get the latest. I'm currently trying to write a Frisky replacement (using bmx-ng) for my own nefarious purposes, though. I love bmx-ng! |
| ||
| I am at the moment thinking of Bm-Ng or monkey2(hate this name) I have ng installed etc but its a real pain in the ass to get it all going! new people would I think have a real hard time setting it up. monkey has struts/overloading enums etc but no union does Ng have that yet or will it ever? would make using my own libs easier to convert/import. could do with a list of whats in Ng and whats working I don't fancy going all over the place to find details! |
| ||
| I got BMAX-NG to work on my infamous 2-D flight sim called Flyghty. Performed dynamically same as BMX150. However, I required a lot of Brucey's generous involvement. I would definitely recommend building periodic 'Frisky' type updates which don't rely on either GitHub (ugh) or external MinGW. The main target would be Win32 7,8,10 and meant for beginners and older folks. If possible, BMAX-NG should run a subset of existing Examples. I know it's tempting to demo future capabilities like Win64, but attracting new blood is essential. The Blitz Clan would step up support for NewBies. |
| ||
| They are showing up for me when debugging on Windows... Perhaps you are using an older version? -Brucey I just updated bcc and I can see globals in the debugger. Sorry for the false critique. :( One issue with the latest version is that it sometimes sprinkles random, single line "!" around the generated c code, causing gcc errors. -EDIT- I found that <comment><bang> i.e " '! " are getting parsed and dumped into the C code. |
| ||
| One issue with the latest version is that it sometimes sprinkles random, single line "!" around the generated c code, causing gcc errors. I have never seen that on any of the platforms I'm building against. There's certainly no obvious code I can see that might do that. If you can't make something reproducible, perhaps you could please send me an example of the generated C code if it happens again? (and the source that it generated from, if you can). Thanks! |
| ||
Sorry. Here is an example
SuperStrict
Framework brl.retro
Print("Hello world") '!!
#include "untitled1.bmx.console.release.mt.win32.x86.h"
static BBString _s0={
&bbStringClass,
11,
{72,101,108,108,111,32,119,111,114,108,100}
};
static int _bb_main_inited = 0;
int _bb_main(){
if (!_bb_main_inited) {
_bb_main_inited = 1;
__bb_brl_blitz_blitz();
__bb_brl_retro_retro();
brl_standardio_Print(&_s0);
!
return 0;
}
return 0;
}
|
| ||
| Apologies. The latest commit should fix that. |
| ||
| I think NG is definitely the thing that will keep Bmax alive. I tinkered with it a year or so back when Brucey helped me to port over a couple of my old games onto IOS for testing purposes. We had some XCode conversion glitches back then but I suspect they've all been ironed out by now. Will try out the newest version at the weekend and see how it handles those games now. |
| ||
| @Xerra. how about that ipv6 requirement thing, is it still an issue? |
| ||
| I'm currently trying to write a Frisky replacement (using bmx-ng) for my own nefarious purposes, though. Excuse blowing own trumpet, but... woo-hoo! I can now automatically download* and build all the bits needed to put together a full NG distro -- including a full MinGW folder that I can drop in to my existing NG setup... and it keeps working! Just need to piece it all together to auto-generate a full working BlitzMax distro now... * Currently depends on a copy of wget.exe as libcurlssl appears to be broken at the moment (cough, cough) and the TCC-MinGW links are https-only... :/ Anyone got a fast .zip file unpacker for BlitzMax (trying to avoid external tools where possible)? Using gman's zipengine to go through the filenames and extract is really slow, but not sure if there's another way to use it... |
| ||
| Anyone got a fast .zip file unpacker for BlitzMax (trying to avoid external tools where possible)? Using gman's zipengine to go through the filenames and extract is really slow, but not sure if there's another way to use it... There's also Koriolis' zipstream module, Brucey has an NG-compatible version of it on his github account. |
| ||
| Glad somebody already tackled an "downloader". I already hat a look at libcurlssl.mod and planned to do the same but delayed it for weekend. @ BlitzSupport Plans to put in on github.com (so people might collaborate if there is need) ? I thought of also supporting preinstalled MinGWs - so people could [x] tick a checkbox if they want to skip MinGW as they want the installed one to get used (therefor you need to run a "process" with "gcc -v" or so - to check if MinGW is installed properly regarding %PATH% setup). Once MinGW ist found or downloaded/unzipped you should not only build BCC/BMK but also download the 3rd party stuff: docmods etc. Do not forget to remove the tmp-files afterwards aka clean up - except the user kept "[x] keep downloaded support files" checked. Next to the [Install] I thought of having an [Update] too (only available once it was installed and bmk[.exe] and bcc[.exe] exist. This [Update]-Button downloads most current bcc/bmk/brl/pub (whatever is needed). If the tool now saves the "hash" of the commits/revisions (if you download stuff from github, the filename contains that hash) you could easily check if the "most current" one differs from the last known one. After finishing the process, the new hash has to get saved (eg. into "config/yourtool.ini") Advantage of doing it that way: at the end even [Install] could be replaced by a [Install|Update] button doing all of the work. If the updater does not found a "installed-hash" of one of the tools on the list, it just downloads the most current one. And everything which is downloaded, needs to get installed too. - no mingw or outdated mingw found (therefor you might host your own "bmx-ng-support-pack-repos")? download, unzip - no bcc or outdated found? download, build, copy to bmxng/bin - ... - no maxIDE found (attention, this needs maxgui - and for linux bah.gtkmaxgui) ? download, build, copy to /bmxng So the routines for basic install and "update without installed packages" are the same. To make that updater work "for all components" you might even create a github repo "bmxng-updates" containing various text files leading to the most current revisions of MinGW, bcc, bmk ... So if you want to have the updater recognize a new update, you need to update the files in that repo. This might be needed if you do not want to host the MinGW-Downloads yourself (eg. on github) but rather download it from "tdm" itself. Advantage of such files is, that you define when an update it worth to get used - or if it might break runnability. So you define "stable" revisions instead of "nightlies". Of course "later" we could switch to an "official" github.com/bmxng/bmxng-component-versions.git-repo which is maintained by brucey itself (so he defines what is "stable"). The updater could then get a config-line telling the "repo-url" which allows to run individual repos if you do not like what Brucey then defined as stable). bye Ron |
| ||
| Hi Derron, yes, once I have it working I'll be making it available, probably via Github. At the moment it's another command-line tool, but I may try and GUI-it up (it started that way but I was having trouble getting tool output into a text area -- think I should be able to do this now). I might just leave it as a command-line tool and do a GUI that runs it, grabs the output, etc. I'm grabbing all of the parts including MaxGUI and MaxIDE (ng), do intend to provide x86/x64-type options, rebuild bmk/bcc with the downloaded MinGW, etc, and maybe deal with checking for already-downloaded stuff -- just starting over each time at the moment, which suits me. I'll be doing stuff with it tonight because it's Friday and I'm a loser. Good idea about sticking the URLs on Github! Anyway, whatever I end up with, you'll be able to take the code and do your own thing. I wouldn't make much of a project maintainer anyway... |
| ||
| This is gonna take a bit of mind-bending thinkery! Eg. to build a new bcc/bmk/maxide that's compatible with the latest pub.mod/brl.mod means creating a temp distro and then building a brand-new distro from that... I think! Otherwise it's built with my own pre-supplied bcc/bmk... Inception-level "ouch"! |
| ||
| Auto updates type of thing sounds really cool. This is gonna take a bit of mind-bending thinkery! Eg. to build a new bcc/bmk/maxide that's compatible with the latest pub.mod/brl.mod means creating a temp distro and then building a brand-new distro from that... I think! Otherwise it's built with my own pre-supplied bcc/bmk... They call it 'bootstrapping' :-) Use the legacy bcc to build the new bcc and bmk. Use the new bcc and bmk to build the maxide and ng modules. Easy... *cough* *cough* O_o |
| ||
| You could always upload a "bootstrap"-package to github and use that to build every download with it (didn't I suggest that already? Seems I missed that). You then of course need to provide bootstrapping packages for all supported platforms. This would also allow for an "raspi-updater" etc. bye Ron |
| ||
| A while back I tested the Defenstar source code and after removing some low level code I got it to work except for the GC crashing the game after 30 seconds or so. I will give it a go soon with the latest version. Who knows, after some optimisation it could run on iPad. That would be sweet! |
   |