Bruceys BLitzmax question
BlitzMax Forums/Brucey's Modules/Bruceys BLitzmax question
| ||
Just touching on a post from the Max is now opensource thread... Is it quite possible you can now provide a full, no messing standalone package of your blitzmax "update" Brucey? I am on the understanding that one needs Blitzmax (the original one) to compile your tools, but now it's free, that barrier isn't really needed anymore. Or, are you just going to keep going the source only route? Me just wondering bonny lad! Dabz |
| ||
I am on the understanding that one needs Blitzmax (the original one) to compile your tools No, it is self compiling - you can build it (bcc-ng) with itself. But obviously you need some kind of functioning bcc to begin with ;-) Now that there are fewer bug reports coming for bcc, perhaps it is time to start making releases. Is that what's put you off trying it out? :-p |
| ||
Brucey, remembering Queen's song... the show must go on. I think it's time to see BMX-NG. ps: maybe a proper 'thread' (or maybe a separate page/site?) could be interesting as starting point for all the users. |
| ||
Is that what's put you off trying it out? :-p lol, if I'm honest, yeah, a little! :D I'm not a lazy person by any means, what you've done looks great, and it would be really really nice just to download the thing and fire it up with no messing about thats all! ;) Dabz |
| ||
Heh, I guess I'm the one who's kept this alive... But obviously you need some kind of functioning bcc to begin with And this is why... What exactly is bcc? It's part of BlitzMax and wasn't open source (until now), so I assumed you couldn't distribute a binary of NG. |
| ||
Brucey... I've just emailed you matey on the addy in your profile! Dabz |
| ||
What exactly is bcc? It's part of BlitzMax and wasn't open source (until now), so I assumed you couldn't distribute a binary of NG. bcc is the thing that takes .bmx and converts it into something compilable. The official bcc converts .bmx into assembler. My NG project is a replacement bcc which generates pure C code instead. Obviously it required some other things - rather than just being a direct drop-in replacement - like a new GC and revisions to the core to support different architectures (like 64-bit). Oh, and it is a Strict/SuperStrict-only bcc. It expects *at least* a Strict level of strictness. But it's done in such a way as 99.9% of your BlitzMax code should be compatible with it. Only lower level stuff *may* need some tweaking to bring it into line with NG. Things like reflection, lua, and the debugger all work as before. I'm pretty happy with the fact that it works as well as I hoped it would when I started the project :-) |
| ||
perhaps it is time to start making releases Do you mean binaries? :)I've downloaded and compiled a copy - your last instructions were very easy to follow. I look forward to giving it a spin but I don't generally bother with Strict (yes, I know), so it'll take a bit of fiddling. |
| ||
I've just downloaded the old Pi version there... Time to play! :) Dabz |
| ||
Spot on!!! ![]() Dabz |
| ||
Glad you like! It does work better on the new dual-core Pi :-) |
| ||
I've published a Windows release here : https://github.com/bmx-ng/bmx-ng/releases Just unzip and start playing with it, without the need to install anything else - as it includes a copy of MinGW, and an updated MaxIDE (with 64-bit build options). Note - you should be able to make 64-bit apps even if you have a 32-bit Windows system (except of course, you won't be able to test them!) I tested it here, but you know how things never work properly on someone else's box :-p |
| ||
Win32 release looking pretty good here! Ran into ReadDir needing Byte Ptr now on my first attempt (instead of Int), but easily fixed. Have just found this, brutally hacked out of some existing code just for compile error demo -- fails with "Compile Error: Syntax error - expecting '='" on the line: For v.tblock = EachIn Block.BlockList |
| ||
Thanks James :-) |
| ||
.. I've also posted the bug on the Monkey website. It's good to share :-) |
| ||
Ha ha, weird I haven't stumbled across that then! |
| ||
Bah... At other halfs tonight so cannot get my mitts on it yet... But I will say one thing... That there is what I'm after!!! Yummy Dabz |
| ||
I should also note that Windows MaxGUI module is still to be ported - OS X and Linux (GTK) are already working with NG, and in 64-bit (and ARM on Pi) If you are on OS X, you can also play with iOS builds... Android should work across platforms - but needs more documentation. (caveat being that Android and iOS are still early WIP, so there is still some outstanding things to implement, and you will need to get the SDL modules too) ... things take a bit longer when you're doing it all yourself :-p |
| ||
Lol... I bet! ;) Seriously though, I'll take a look at maxgui, I don't mind porting stuff so you can knock that job off your list... It'll be a bit of practice since im weighing up wxWidgets too... I'd be really lost without that so I don't mind a bit of sleeve rolling... And I do recall how long it took you too bind that to Blitzmax so I'm not going in blind! :D Dabz |
| ||
wxMax works already ;-) |
| ||
Ran into ReadDir needing Byte Ptr now on my first attempt (instead of Int), but easily fixed. There are a few changes to handle the move to supporting 64-bit - like BlitzMax's use of Int instead of Ptrs in places. I also upgraded the streaming to support 64-bit file offsets, and filesystem to support 64-bit large files. I believe I've fixed that For loop issue. If you want to try it out, you can download and build the bcc package from github. Hopefully I haven't broken anything else in the meanwhile... |
| ||
That works great now... so here's another one!a = 0 ' or 1... or 2... or... Select a Rem Test comment! End Rem Case 0 End Select Compile Error: Syntax error - expecting 'Case', 'Default' or 'End'. No 'Rem' in Monkey, I suppose... |
| ||
Is it Strict by default, BTW, like Monkey? Just been trying some old demos and stuff, and a few fail because of: test = 1 ' Undefined Kind of expect it now, but just checking... |
| ||
One more for luck! This highlights the wrong line in the editor (line - 1), due to the commented-out line in Function GetXInputDLL ()...'Local xinput$ Sorry, tried to narrow down to the function itself, but by the time I've removed enough for it to attempt to build, it, er, works! So I guess something else is throwing it off somewhere... If version > hiversion hiversion = version ' Highlights this line, 84 in the IDE, while error reports line 85 xinput$ = f$ EndIf This is old, hence crap/not SuperStrict by default... Done for now, just on a random run-frenzy! |
| ||
I did read somewhere that bmx-ng is strict/superstrict for its strictness! :) Dabz |
| ||
Is it Strict by default, BTW, like Monkey? Yes it is, unfortunately. (Or fortunately if you are like me ;-) just on a random run-frenzy! Thanks for that. If it helps to uncover issues in the parser/compiler then I'm all for it. We may have issues with your "win32" tags though, as I'm not entirely sure what I should be generating there. I presume something to do with WINAPI? In the same way that 'Extern "Win32"' isn't generating the correct interfaces in C... |
| ||
Nah, I assumed it was Strict, just checking -- has been my preference for ages now. (Well, SuperStrict.) Regarding "win32", I'm afraid I have no idea what that does behind the scenes, but it's certainly related to Win32 API calls... presumably sets up the right call convention? Must be somewhere in the new source though. |
| ||
Hi Just downloaded from the above link the BlitzMaxNG package. MaxIDE tooks some times (about 20 seconds) to start (only for the first-run, then it opens immediately). I recompiled all the modules (via IDE menu), both for win32-x86 and win32-x64 Then I decided to compile a sample (from the BMax original folder): simonh/fireworks.bmx it starts, I see the black screen and 'press space to ignite'. I press SPACE, I see the firework explodes and then ...error. MaxIDE show the error in LINKEDLIST.BMX Threaded building is OFF From DebugTree (in MaxIDE) Function NextObject.value=NULL I have not found any configuration file, so I presume MaxIDE will look its own MinGW tools. Other samples I tested (only for statistic and for beta-testing purpouse!) OK : SnowFall OK : TileDrop OK : hitoro/viewport OK : hitoro/shadowimaeg ERROR : Tempest (same error as above, not at the first shot) ERROR : ZombieBlast (same errore as above, at the first shot) ERROR : Mak/RequestGraphicsMode (identified Desktop() not found) ERROR : hitoro/fireworks (EXCEPCTION_ACCESS_VIOLATION at the start) gcc.exe: error: C:/BlitzMax150/samples/hitoro/.bmx/fireworks.bmx.gui.debug.win32.x86.c: No such file or directory gcc.exe: fatal error: no input files ps: I exclude the error due to non-strictness in the code (like: arraysort.bmx) Tested in Windows Seven 64bit NICE & COOL! I don't note any difference (excluding the output string in MaxIDE Compiling:shadowimage.bmx.gui.debug.win32.x86.c...) from the 'basic' version |
| ||
TList Concurrent Modification Ah, yes. This is a new "feature"... basically, it tries to prevent you modifying a list while you are iterating it (via an Eachin Enumeration). The assert only works in Debug mode, as it is there to highlight bad practices. |
| ||
This highlights the wrong line in the editor It was the comment on the ?win32 line that was throwing it out. So I've re-engineered the toker now to strip out single line comments and rem blocks before it even gets to the parser. |
| ||
Ah, yes. This is a new "feature"... basically, it tries to prevent you modifying a list while you are iterating it I hope you also added an easy to to turn that 'feature' off because if it's disabled in debug, might as well be both. (no one writes software in bmax and never uses debug) I use this (modifying a list in a loop) all the time and have for years without problems. |
| ||
Ah, yes. This is a new "feature"... basically, it tries to prevent you modifying a list while you are iterating it (via an Eachin Enumeration). The assert only works in Debug mode, as it is there to highlight bad practices. Does this means that DEBUG mode is no working every time a program interacts with a list? It seems no really useful... a warning in the output could be a solution. |
| ||
h, yes. This is a new "feature"... basically, it tries to prevent you modifying a list while you are iterating it (via an Eachin Enumeration). The assert only works in Debug mode, as it is there to highlight bad practices. Good move I think as well, but for backwards compatibility, maybe an optional way of implementing that, like maybe "SuperStrict" implements the no modify list rule, where as normal strictness doesnt! I use superstrict all the time, and after getting my arse bit with using lists too liberally on mobile platforms, I'm game into being forced not to be silly! :D Dabz |
| ||
I've wrapped it in a compiler flag for now. I'll add the option of enabling it later. |
| ||
Coolio!!! :) I'm having a play... Absolutely adore what you've done mind! Dabz |