Digesteroids On Steroids
Community Forums/Showcase/Digesteroids On Steroids
| ||
| Anyone familiar with the BlitzMax samples/demos, will have seen Digesteroids, by Rob Hutchinson. This is the same game, but compiled as a 64-bit native application using a WIP BlitzMax compiler. For the moment, we only have OS X and Windows builds. You can download and try it out for yourself using the link(s) below : * digesteroids64_osx.zip 2.7 meg * digesteroids64_win.zip 2.6 meg Linux is working too, but I need to put a build together. The source is almost as the original, but I incbin'd all the resources (graphics/sound), just to keep things tidy. Technical Stuff The BlitzMax-GC has been replaced with the Boehm GC, which although not as fast as a BlitzMax-specific-hand-coded GC, it is better than having none at all. All compilable code is generated as pure C, in the same object-oriented C style as the core BlitzMax modules use. The parser/generator is a BlitzMax port of Money's trans program, extensively modified to support all the things BlitzMax has, but Monkey does not (like pointers, function pointers, more primitive types, etc). Various BlitzMax modules (BRL and Pub) had to be tweaked/fixed to work in 64-bit, as many references were assuming 4-byte pointers (and being used as Ints), which isn't really compatible. Most of these were replaced with Byte Ptrs. Since we moved to a new GC, we were able to streamline some of the low-level structures that BlitzMax uses, doing away with things like the reference counting. So far, things seem to be working as expected. There are still some issues with the parser, but it can now compile all of BRL and PUB modules for x86. As mentioned previously, we are still working on getting Windows issues sorted out. Since I was rather disappointed with Monkey in regards to it being an even more game-oriented language than BlitzMax was, and it's modularity basically sucked compared to BlitzMax, I opted to take the path of most resistance, and try to get myself to a point where I could write 64-bit (and perhaps other architecture) native BlitzMax applications. I'd say I'm very happy with the progress so far. Anyway, if you have OS X, it's worth trying it out, just to see if it works. Comments, questions, and criticism welcome :-) |
| ||
| Initial reaction was disappointment- I was expecting a suped-up version featuring chocolate coated biscuits. It does run nicely on my system, however. ...but seriously folks... This is a great achievement! This is the 'Monkey' I would liked to have seen too and this direction puts Max on a much firmer grounding for the future updates, assuming it is open source (and to some extent even if it is not). Questions: -What you calling it? -Will it be open source? -Do you have a paypal for well deserved donations? |
| ||
| What you calling it? Being not very creative when it comes to names, it is currently just "bmx ng". Will it be open source? Completely. Everything is licensed under the zlib/libpng umbrella, in the same way that the BRL and PUB modules are. |
| ||
| Congratulations!!! BlitzMaxNext is ready for the future :) |
| ||
| - currently the project name is BCC-NG. - It is open source (github for it) - at http://www.brucey.net/programming/blitz/index.php you could find a donation link Maybe I will add a linux-compilation tomorrow. bye Ron |
| ||
| Wow! Works very nice and smooth here. That's a huge step and very good news for BlitzMax. |
| ||
| Can't test the demo, but it sounds like an amazing piece of work to get it this far! |
| ||
| Edit: well done! |
| ||
| Can't test it yet but it is motivating to see that bmax is still alive ! |
| ||
| Runs sweet on my Mac. Congratulations on this epic achievement Brucey! |
| ||
| works smooth here on mac mini Brucey: I've got a heavily modified freeadudio mod that give full audio synthesis + effects would you like to text on it? |
| ||
| I can't test this, but I do want to say congratulations. You have done an awesome job on this. |
| ||
| @Adam Brucey hosts brl.mod and pub.mod projects: https://github.com/maxmods there you can try to pull requests to enhance/fix BlitzMax' vanilla modules - maybe try it there. (They are not the projects used in BMX/BCC-NG). @Linux demo of digesteroids ronny@RonnyPC ~/Arbeit/Programmieren/BlitzMaxNG/digesteroids $ file digesteroids digesteroids: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xec7394b50a804e95f91fdcf271dcfff811715b44, stripped First of all: the download link [Linux 64Bit]. (the file is stripped to reduce size newer GCCs add to binaries, no incbin used like Brucey did, I also disabled startup fullscreen as fullscreen apps tend keep screen resolution settings at the changed values if they crash) But I am sorry to inform you: currently the linux compiler does not compile vanilla digesteroids code ... there is ONE line which needs to get still adjusted: digesteroids.bmx Type EndingScene Extends T2DDynamicGameScene ... Field TEXTS_COUNT = 23 Field Texts:String[TEXTS_COUNT] needs to get Type EndingScene Extends T2DDynamicGameScene ... Field TEXTS_COUNT = 23 Field Texts:String[23] So this means, during creation of properties you currently cannot rely on previously created "field"-properties. Using "CONST"-properties works as intended. (@Brucey: I opened an issue for you to keep it tracked :P) I did not check Win64 yet but I assume there is surely some work needed (adjustments in modules and compiler) as both, Brucey and me do not work on Windows as main dev/test machines (it is Bruceys child, my work can be called "minor" but I am a willed tester :D). bye Ron |
| ||
| As this is not a 'small' work, I think BRL (or Brucey/Derron) should place in the 'news' page something about it AND to create a proper forum thread (for possible bugs, solutions, features and so on). The 'evidences' of your work is here and there (look at the worklog, or at some questions in specific forum and so on..). If anyone is interested in BCC-NG 64 have a little difficult to find it. (yes I know you put immediately a link to git...) It just to 'keep in home' your efforts. |
| ||
| I think BRL (or Brucey/Derron) should place in the 'news' page something about it AND to create a proper forum thread Brucey you meant, surely. And nice work by the way. |
| ||
| Great work! Do you feel that other targets might be good candidates? Mobile maybe? |
| ||
| Great work! Do you feel that other targets might be good candidates? Mobile maybe? Wouldn't this just turn BruceyMax (TM) back into another Monkey, with all the associated limitations of catering to the lowest common denominator? |
| ||
| Great work! Do you feel that other targets might be good candidates? Mobile maybe? Well, I presume you need to do a big work to write the proper 'drivers' for Android/iPhone/etc... not a simple task and no guarantee to work out. And at this point better to use Monkey X that's ready and tested for this. |
| ||
| Wouldn't this just turn BruceyMax (TM) back into another Monkey, with all the associated limitations of catering to the lowest common denominator? Not necessarily. I have been experimenting with an ARM Linux build for the Raspberry Pi, although I've been fighting with the cross-compiler. Basically you can just add new ?arch flags where required. So, ?arm and ?x64, and extending that to things like ?linuxx64, ?macosx64, etc. Which is backwards compatible with the current bcc/bmk, which simply ignores ones it doesn't understand. I opened an issue for you to keep it tracked And then there's things like this, which is directly related to the way "trans" works. If you write the equivalent code in Monkey, you get the same error. :-) |
| ||
| Mighty achievement. I shall have to donate something. -Henri |
| ||
| Great work! Good to see the possibility of a Win x64 compiler on the horizon as well. :-? (Just made a paypal donation too) |
| ||
| Thanks very much for the interest and generosity. I hope, once things get stable, that people will be able to get a lot more life out of BlitzMax using these tools. Good to see the possibility of a Win x64 compiler on the horizon as well. :-? Well, horizon may be pushing it. Working with Windows is a nightmare ;-) This evening I did a bit of overtime in an attempt to get *something* out of my 64-bit Windows 7 VM... 64bit_Demos_01.zip 250KB (Windows 64-bit) Apologies in advance for the lack of anything really interesting in there. Just the spintext and glblur samples, I'm afraid. But they are 64-bit native - you can open an exe in Dependency Walker, if you don't believe me :-p They are also OpenGL-based, because it's the part that seems to be working for now. One step at a time, hey? Thanks again. <edit> I should note that they were built with the latest 64-bit TDM MinGW compiler. Everything is meant to be compiled in, so it *should* just work. Please let me know if it doesn't, of course ;-) |
| ||
| Nice. Demos run smoothly. |
| ||
| Just for the matter of smalltalk: Mail to Brucey: "BlitzMax Future", 19/12/2013 So the idea was "planted" (edit:"became manifest") or less 6 months ago (but I think Bruceys brain had it in already :D). ------ @win64 IMHO Windows adds the hassle of installing 2 MinGW packages as the 64bit-build cannot compile for 32bit (-m32 does still build 64 bit). On the MinGW-Page they mention TDM as being incompatible with other builds ( ... so the following should be adjusted accordingly). Maybe some ugly hacks like: http://ascend4.org/Setting_up_a_MinGW-w64_build_environment are needed then. bye Ron |
| ||
| 64bit_Demos_01.zip 250KB (Windows 64-bit) Works like a charm here. (Windows 8.1 Professional, x64) |
| ||
| Brucey, Awesome, awesome, awesome! The windows demo worked great here. Will you be able to support DX? I know you are early on in this project but support for DX and especially support for Col's (Dave) D3D11Max2DDriver() would rock. Just awesome! If I can be of assistance let me know. :) |
| ||
| Mac samples work great here. whenever you have a specification of compilation toolchain for windows (compiler parameters, etc) let me know it as I would love to make BLIde compatible with your compiler too. |
| ||
| Currently the compiler just needs a param "-g x64" to compile for 64bit targets. So the calls stay the same ./bmk makeapp -x -r -g x64 /path/to/file.bmx The only problem I see is the coexistence of 32bit MinGW and 64Bit MinGW (as you have to copy "libs" over, same for ld.exe, ar.exe ...) if there is no "nice" solution it might be possible to tweak "bmk" to do some renaming before compilation (bruceys bmk allows LUA-scripting so this might come in handy then). Another option is to use "ld64.exe" and "ld32.exe" (similar things for the other parts) but this then adds clutterness the "config.bmk"-files do not add ... Think it depends on how deep the integration takes place (are the modified pub.mod/brl.mod still compatible to vanilla bmk/bcc etc.). As long as the compiler still has some small issues (oddness of some language "hacks" and differences to monkey) this will have top priority. Getting it run on Win32/64 is more a matter of arousing interest (to keep Brucey "hungry" :D) @DX Looking at the changes done in brl.mod and pub.mod, most of the commits can be shortened to "Use pointer instead of int". Means: replacing specific code lines to use a byte pointer instead of a simple int. Time will show if this are the "only" modifications needed for DX. Maybe there is a day NG is ready to get used by "many" - and one of those "many" then pushes a little commit reactivating the directx.mod. bye Ron |
| ||
| The only problem I see is the coexistence of 32bit MinGW and 64Bit MinGW (as you have to copy "libs" over, same for ld.exe, ar.exe ...) I introduced a lib64 for it, and bmk uses the appropriate one depending on your choice of build. Really, it probably just wants to use the "system" MinGW installation (I suppose, whatever you have set MINGW to), rather than relying on having stuff in bin and lib. Then it doesn't really matter. You could then, in theory, have two installs (if I can't get 32-bit to come out of MinGW64), and just switch your MINGW over to whichever one you need (either by hand, or via the IDE). Having nothing in bin/lib would be my preferred option for this. Unless someone can think of a better reason why you'd want to keep those files in there? ;-) Time will show if this are the "only" modifications needed for DX. All of the Windows stuff is built on Externed Types, which may, or may not be an absolute nightmare. Since I'm only scraping the surface at the moment, I don't have a definitive answer yet. @The -g flag This is basically what drives things. Without it, you get your native (as per the architecture of bmk/bcc) build. So, normally that would be x86. Then you can choose things like "-g x64" or "-g arm", for example, and source will be compiled up appropriately, using the usual suffix notation (eg. ..release.win32.x64.a, or ..release.linux.arm.a) 64-bit compilation on OS X and Linux is quite transparent, as if you have the tools installed already, it should just work with the change of flag. In fact, it's *easier* to build for 64-bit Linux that it is to build for 32-bit Linux on a 64-bit system... *sigh*. Anyways, there's still lots to do, as you can imagine. I'd say, "go here and try it for yourself", but I don't have time to support a million bug requests. It's hard enough getting them drip-fed by Derron every few days :-p |
| ||
| Basically you can just add new ?arch flags where required. So, ?arm and ?x64, and extending that to things like ?linuxx64, ?macosx64, etc. Which is backwards compatible with the current bcc/bmk, which simply ignores ones it doesn't understand. Wait really? That makes some things a whole lot simpler... You can effectively have completely arbitrary block annotations? Handy. *distracted by the irrelevant detail* |
| ||
| Damn Brucey! You're the balls! |
| ||
| The Boehm-GC is an acceptable tradeoff. I initially didn't care for it in multithreaded BMX, but I use Blitz as an event-driven application language, so speed isn't super critical. |
| ||
| The nicest thing about the Boehm GC is that since it's designed to be used from regular C code, it doesn't insert any extra instructions directly into the machine code (as opposed to the original refcounting engine, or a custom solution) and is thus very easy to replace, which is one reason why so many languages use it as a bootstrap GC until they can engineer a precise one. If everything hooks in at runtime, you can always replace it with something else. (OK, a precise collector does generally require more information too - but since it only requires more information, not more instructions, it still becomes something you can hack into place in the background without disrupting execution or runtime performance, leaving Boehm in place until the time is right.) I haven't really looked into the source at all, but there's an implementation of a real-time garbage collector as part of RScheme, which is apparently designed to be retargetable to any language (RScheme is another C-backend one). Might be a good future project for someone to hack into this once the compiler is stabilised. It supports both hard- and soft-real-time collection. |
| ||
| Windows demos worked a treat here on Win7/64-bit! |
| ||
| Super-kudos from me, too! This instantly killed all thoughts I had about having to change platform for the forseeable future as it gives me hope to stay on BMX. Very, very nice indeed! But I still hope you change the name, perhaps to "BMX+"... ;-) |
| ||
| Nice. Tried it on Win7 x64 and works fine. But: Can anybody explain to me why when I ran the exe's for the first time they where trying to modify a Protected Registry key?? |
| ||
| Can anybody explain to me why when I ran the exe's for the first time they where trying to modify a Protected Registry key?? No? What key? |
| ||
| Well, after a couple of hours of debugging, *sigh*, I finally have digesteroids running on 64-bit Windows, albeit without sound for the moment. The MAV turned out to be a FILE* to int cast in the Win32 part of pub.stdc that I'd missed. Sound seems to be loading, but not making a noise, so probably something broken in FreeAudio... Skid?!! :-p |
| ||
| For Audio, BlitzMax windows will likely default to Mark's DirectSoundAudio. I'm going to take a look this weekend anyhow as I'm interested in having a play with what you have done with BlitzMAX so far. |
| ||
| For Audio, BlitzMax windows will likely default to Mark's DirectSoundAudio Ah, yes! You are quite correct. Disabling the DirectSound driver, and instead using your FreeAudio (mm), it works! (although it sounds a bit clicky from time to time). However, I'm happy enough with that for the moment :o) |
| ||
| Sorry, Im not a big knowledgeable about 64bit systems but didnt ppl asnwer in my topic http://www.blitzbasic.com/Community/posts.php?topic=102708 that there is no problem running blitz max on 64 bit? so what did i miss? |
| ||
| so what did i miss? BlitzMax creates 32-bit binaries. These run on 32-bit and 64-bit systems. A 64-bit native binary is something else entirely, gaining access to more resources (like RAM), and not requiring any system emulation - as happens on Windows 64-bit systems. Since the world in general is moving away from 32-bit and towards 64-bit, it's nice to be able to create 64-bit native binaries in the language of our choice ;-) Update I've added a link to a Windows 64-bit build of digesteroids in the first post. It's all working properly (here) except that the sound is a bit laggy, as I haven't been able to get the DirectSound module working yet, and we are instead using the mm driver from FreeAudio. But some sound is better than none at all, and you can get the gist of things coming together :-) Please let me know if you have any issues other than with the sound. Thanks! |
| ||
| Digesteroids runs fine on Windows 8.1...only lag I see is a code problem - it should give more drift as Asteroids did. :) |
| ||
| @Brucey: No clue which key. The message of Comodo Firewall came up briefly for both the executables. I chose to block the action and it still ran fine, so I dunno. If no one else had the same experience then perhaps there's something on my system(oh-oh), but Avast didn't sound an alarm or anything.. |
| ||
| @Jean-luc re freeaudio A 64-bit Wave? Sounds intriguing. Drop me a line about it ;-) |
| ||
| That Comodo issue sounds a lot like DXSetup calling home. To check, run dxdiag and make sure Check for WHQL digital signatures is not selected. |
| ||
| Hi, The windows demo of Digesteroids ran great, although my CPU fan immediately went in to high volume mode and stays that way as long as the demo is running. I wonder why that is? My CPU load was about 60% average. Perhaps it is my crapy system. ;) I have never ran a 64bit game on it before so maybe it is normal. I have to say seeing the demo run sound and all on Windows is impressive. :D Great work. |
| ||
| Just tried 64-bit Digesteroids -- ran fine, no sound lag (though very slightly crackly). my CPU fan immediately went in to high volume mode and stays that way as long as the demo is running. I wonder why that is? My CPU load was about 60% average It was using 17% here on a 6-core processor (so 100/6 = 16.666) -- 100% of a single core -- and running the original 32-bit version gives exactly the same result, so there's just no waiting in that demo. |
| ||
| Hi, I ran Digesteroids in 32bit Blitzmax 1.48 and about the same CPU load (about one core 100%) but the fan on the CPU stays in normal mode. My system has on board (on motherboard) video and I am wondering if that has something to do with it as it uses system memory for the video card. Sound on my end is great and that too is on board audio. |
| ||
| Digesteroid windows demo works here, although the sound is extremely crackly the entire time it's playing... Almost like walking down a gravel road in the background. |
| ||
| @Brucey - check your mail ;) |
| ||
| Hi, I would like to know what I need and how to start test compiling some test code using this new compiler. I went by github and have the latest commit so what do I do now. :) Or is it just to soon? Thanks, |
| ||
| @crackling: I had this when I did not properly reused the buffer/assigned memory block ... so wrong "values" created odd sounds (like scratches on a record changed sounds). The other day I had cracklings was when updating "streams" less often so the interval got bigger than the buffer (so 10ms or so of the "old buffer" got repeated before new one was filled in). Maybe the driver does translate things wrong. Hmm, think Brucey/Skid will get rid of that bug really fast (when tackled). @100% CPU this is the code of digesteroids, it uses no cpu+fps-limiting. Put in a delay(x) in the mainloop to lower it down the "easy" (and not perfect) way. |
| ||
| @Daerron this is the code of digesteroids, it uses no cpu+fps-limiting. Put in a delay(x) in the mainloop to lower it down the "easy" (and not perfect) way. See post above yours. ;) I just need to know how to get started and compiling. Unless you ment do it in 1.48 . |
| ||
| - DL bcc-ng, bmk-ng, pub.mod, brl.mod - copy your vanilla BM -> call it hmmm blitzmaxNG - replace blitzmaxNG/mod/pub.mod and brl.mod with the one you downloaded (delete old first) - open up bmk-ng in vanilla BM, compile the new bmk (like you do when using Bruceys improved bmk) - open up bcc-ng in vanilla BM, compile the new bcc - copy new bcc and new bmk to your blitzmaxNG/bin - open up maxIDE in the copied BM and recompile all modules (or do it by hand: ./bmk makemods -a -r -g x64 ./bmk makemods -a -r -g x32 Afterwards you should be able to compile with the new bcc/bmk-combo. Please pay attention to the issues/pull requests I just opened - some small issues are still there (or functionality might be missing - see the commit about "sgn()" I did some minutes ago). PS: Adjust config files if needed if you run Windows (minGW -> libs/ar.exe ld.exe ...) bye Ron |
| ||
| @Derron Cool. I will give it a try and I just got the email from github about the issues/pull request. I will also need Mingw-64/32 ( http://mingw-w64.sourceforge.net/ ) ? |
| ||
| I've been using TDM, so I can't vouch for any others : http://tdm-gcc.tdragon.net/download But note that I can't support Windows-specific issues at the moment. Saying that, I think there are some patches I need to commit for bmk for the windows build - but I can't do that 'til tonight. The OS X/Linux build is much better supported at the moment. |
| ||
| @Brucey/Derron Which Mingw flavor do you recommend for linux? Running debian 7. Thanks, |
| ||
| ? Just install gcc ... MinGW is "gcc for Windows". @Brucey and "drip feed issues" As you wanted more: you got more :D bye Ron |
| ||
| Derron. I think Richard means for cross compilation. @Richard Betson I never bothered do cross compilation as it's more efficient compiling on the correct OS and saves messing around. There is the MinGW cross compiler that you get in the repositories. You will have to look around on how to use it. but this should give you a start. And then there is M cross environment. |
| ||
| @dawlane Yes your right;) and I think I'll just compile it in Linux for now. :) I will checkout your useful links. Thanks. @Derron I tried to compile bmk-ng.bmx and got an "unable to covert from 'byte ptr' to int" error on line 205. I was not able to find a bcc-ng.bmx Is it in bcc-master? The bcc.bmx file compiles though. I am using the Linux version of BlitzMax (1.48) to compile on Debian 7 64bit. |
| ||
| bmk.bmx is the main file for bmk. bcc.bmx is the mail file for bcc. You *may* want to wait for a while until things are more settled, and there are docs/binaries available? |
| ||
| ^Right on... Just wanting to poke around a bit. I will play around with it and await more 64bit goodness. |
| ||
| @bmk I just recompiled the current bmk (no ng appended to the filename, I append "NG" to distinguish between vanilla and "custom") using the vanilla Blitzmax (extended with the custom bmk brucey already provided). So there is a "custom bmk" available from Brucey - which runs on vanilla BMX. Cannot say if this is really needed but this is what I have installed here (Mint Petra, 64bit) @bcc-ng.bmx see above (and see bruceys post). Your compiled bcc should state to be version 0.12. @MinGW Ok, so I misunderstood things there. Sorry. Do not forget to replace modules (and then recompile them) else you get odd errors (like the ones you get with wrong MinGW versions). Think the most "important" things for now are language bugs - like missing inbuilt-commands, behaviour differing to vanilla BMX (eg vanilla allowsto have "<=" for comparison _and_ "=<" - while the documentation only allows the first one). Also take into consideration: BCC-NG defaults to "strict", there is no "non-strict" mode. IMHO the best is to use "superstrict" at all. bye Ron |
| ||
| @Brucey- Given that this is based on Monkey tech, does it follow that certain Monkey language features could be pretty easy to introduce down the line? |
| ||
| Things like "overloading" should be possible because the compiler is more a "translator" to C. so if you have myfunction:int(a:int) myfunction:int(a:string) myfunction:int(a:int, b:string) this could be translated to int myfunction(BBINT a) int myfunction_string(BBSTRING a) int myfunction_int_string(BBINT a, BBSTRING b) This is in my opinion the exact way Yasha used for his nifty C-Wrapper-Generator. So I assume new language features (read "sugar") should be possible, but surely not the most important things at the moment. But it is one of the things I cannot await too (as it simplifies things regarding 3rd party developers and documentation). Another thing I would like to see in the future: subdirectory module loading ... this is similar to the current "import file.bmx" but allows placing modules directly in your projects folder - this is important if you work in an open source way, saves the tedious work of collecting modules, copying that modules to the specific blitzmax directory etc. . Things Brucey already is improving (and also has improved) are compilation flags and other things - see the customized bmk adding a big bunch of flexibility (LUA scripting). bye Ron |
| ||
| Oh I agree- basic Max functionality before the sugar. I was wondering if things like templates, which exist in Monkey could be added just by adding the equivalent Monkey trans lines back in? |
| ||
| I'm looking forward to testing out the Windows version when it's more stable. I wonder what it would take for Brucey to be doing this full-time... ;) |
| ||
| Nice work guys ! Very nice ! ;-) |
| ||
| What I would really like to see is a Blitzmax that can compile to many of the targets Monkey can. I like Monkey quite well but BMX is what I keep coming back to when I'm programming for fun. |
| ||
| While I respect this work, I have some reservations which I posted here: http://www.blitzmax.com/Community/post.php?topic=102713&post=1230765 |
| ||
| What is the fuss about 64bit.It just means you have more memory to play with don`t it.Or am i missing something here. |
| ||
| While I respect this work, I have some reservations which I posted here: "reservations" ? Newsflash: different people have different wants/needs. You may think the monkey syntax is better, others greatly prefer Blitzmax. The more choice, the better.  |
| ||
| What is the fuss about 64bit. It's not just about 64-bit. By moving away from an asm-only code generator (we are now generating C), I now have some more freedom to build on different architectures and platforms like 64-bit, ARM, (Open/Free)BSD, and so on. Choice is good. I've always said that. Everyone can have their own opinions about what they like or don't. If you don't like the idea of a BlitzMax that can compile to 64-bit then that's fine. I don't like liquorice, but I don't mind if you do :-) As a language, I like Monkey. The new language-stuff is cool. I really dislike the build-system, and all the low-level stuff it took away from me because it needs to cater for the lowest-common-denominator (which I suppose is HTML). Also none of my stuff works with Monkey without a complete re-write, which I simply don't have the time for - that and everyone in Monkeyland seems to prefer to port *everything* to Monkey, rather than wrap. I'm pretty sure that is *not* the most efficient way... Anyway, I'm just doing this because I want to. It has certainly been interesting learning about object-oriented C and all the nitty-gritty Boehm GC stuff. Learning is fun, they say ;-) |
| ||
| That's it! Time for Brucey to stop all this programming nonsense and start a candy company. Specialty: liquorice! Oh wait, I don't like it, either. Nevermind. :) |
| ||
| What is the fuss about 64bit.It just means you have more memory to play with don`t it.Or am i missing something here. It is a matter of necessity. Not all versions of Windows are capable of running 32-bit software on default installs. |
| ||
| @Brucey/Derron* I really like the fact that you're spending so much effort on the re-creation of the BlitzMax compiler. I'm none nonetheless afraid that the result of your work will move BlitzMax (far) away from the All-In-One Land into the install everything yourself by commandline abyss (lives next to the install 10 tools you don't need and configure them abyss). Since you said you are open for critique/comments on your mammoth task I would like to ask if any of you could take the time to google for C-compilers that can be bundled directly with BlitzMax so that the original Open/Type/Build+Run workflow is uninterrupted. I also have concerns about the function_int_string syntax. This is equally painful as the BB_ prefix imposed by BlitzMax. The Reason: I will never able to compile a Plugin for anything (e.g. Windows Dll) because the program will look for a InitLibrary() Function and will only find a InitLibrary_int_string one. It would be nice if you could introduce a prefix/method of handling such a case before you realize the dust has settled and there is no room to move anymore. I simply see no reason in duplicating errors in a successor product. I'm aware of the fact that this is Brucey/Derron*-Max but I hope you can at least think a second about it before you regret bad design choices later. Thank you. *Alphabetical order |
| ||
| I'm none nonetheless afraid that the result of your work will move BlitzMax (far) away from the All-In-One Land into the install everything yourself by commandline abyss I don't see why. On OS X and Linux, you need the usual developer tools installed anyway if you want to compile anything. As for Windows, I'm seriously thinking we would all be a lot better off if the MinGW files were removed from bin and lib, and you just used those directly from whichever MinGW you happened to be pointing to (say, whatever MINGW is set to). This way, you immediately do away with the issue of having to get those files in sync. I'm sure, if required, one could create a binary distro of the BlitzMax parts which included a version of MinGW so the "Open/Type/Build+Run" would work straight out of the box. This is equally painful as the BB_ prefix imposed by BlitzMax. I'm afraid we haven't moved away from prefixing things, and in fact I decided to go a step further to ensure slightly more unique naming. Perhaps in the future we can look to having a way to specify exported functions have a given name internally, much in the same way "extern" currently works for external stuff. For now, I'm just looking at getting everything working. Then we can think about applying tweaks - things like generics and so-on. In other news, today I managed to get all the MaxGUI examples running on 64-bit OS X, which was kinda cool. Has some initial issues with Skid's use of the underlying object structures (presumably to save lots of wrapper code), but once that was fixed it all kind of just worked :-) MaxIDE, on the other hand, is a different ball-game altogether, as it is highly likely to do its own things with "handles", which need to not be defined as int... so I'll need to have a rummage through the code and see how we get on with that. Things are moving forward though, so I'm reasonably happy with general progress. Derron though, likes to write his code somewhat differently, which really (really) tests the abilities of the parser/generator... :-p |
| ||
| Thanks for the update Bruce! I think it would be a great to remove the MinGW files from the distro. As I still haven't figured out how to make your BRL and PUB modifications run properly on my system. And btw: Your example from the first post runs fine on the 2 machines (Win 7 + 8.1) I tested. |
| ||
| Hi, How goes is? I am following you on Github and you all look busy :) |
| ||
| Things are going reasonably well, I think. We (Derron and I) had a good bug-squashing session on Saturday, and solved some problems. So-much-so that his game framework "demo app" was working by the end of it :-) Yesterday I discovered "loop labels" ! I've been using BlitzMax for how long, and I'd never come across them. I knew there were labels, but I thought they were only for Goto, which isn't supported with the new compiler (minimum of Strict required!) So I've been busy implemented loop label handling for Continue and Exit. Seems to be working fine in the tests. Will just need to review and revise the Exception handling code for Continue and Exit at some point. Windows support hasn't progressed much, as I've been mostly concentrating on "bugs" - of which there have been plenty! I was testing MaxIDE on the Raspberry Pi after our bug-squashing, and it is much more stable now. Almost useable (insofar that it crashes less often than it doesn't). (that's MaxIDE built with my GTKMaxGUI modules, rather than FLTK - which I dread to even think about trying to build.. ack!) so, all in all, I think we are progressing well :-) |
| ||
| I am excited too how "good" it works currently. Seems my odd coding practices (we better call it "quirks" :D) seem to have benefits: they throw up bugs when compiling/in the compilates: Sometimes they show off that some of my thoughts were to basic ... but in other cases the uncover little bugs under the bcc-carpet. Think when some test their "samples" under win32 other bugs might get exposed. @game framework "demo app" My little framework contains some portions of code I extracted from our game - it is available at github.com/GWRon/Dig . Demoapp is a sample showing off some features like GUI/sprites/Spriteatlas/bitmapfonts/interpolation/XML ... so it handles quite many things (bruceys libxml, pixmap modification). the Lua sample (samples/lua) works too. So what hinders testing more? BCC-NG is superstrict and even more: eg. in BlitzMax-Vanilla you can write "function test:Int()" and override it in an extending type with "function test()" - this is not allowed anymore. So some modules (like maxmod2.mod) need some overhaul - same for parts of my code (I code in a normal text editor "geany", so no assisting help like with Blide). I am really glad that Brucey sacrifices that much time to narrow down sources of crashes (some are - like said - my fault, so I cannot blame BCC-ng for it). Would like to know if Mark (v2 :D) already had a look at the changes to "NG". bye Ron |
| ||
| Awesome to read. :D |
| ||
| Question: as bmax ng seems to use superstric everywhere, it seems logic to have an IDE that helps the user during typing, adding :int when you type Function or adding Return 1 and so on. So 'transition' would be easier even for new users. |
| ||
| I do not think that this is the only thing needed for a "better" or "more helpful" IDE. MaxIDE fails even on "undo" (using the linux fltk-build). The only thing I use "MaxIDE" for is pressing "compile" on debug builds because my normal text editor "Geany" has no "BlitzMax Debugger" available. bye Ron |
| ||
| as bmax ng seems to use superstrict everywhere No it doesn't. Wherever you read that, is entirely incorrect. It uses a minimum of Strict. It's not the same thing. With Strict, you don't need to declare Int types if you don't want to, and functions/methods default to Int return types if you don't specify something else. Anyone that writes BlitzMax code with no strictness is just making their life over-difficult, as the compiler doesn't even know what types you think you are using, and has to magically work it out on-the-fly at runtime. Anyway, you should all be using SuperStrict ;-) |
| ||
| Wherever you read that, is entirely incorrect Well, I just read one of the latest Derron's post... Maybe I misunderstodd the meaning. So the 'lower' level is STRICT for Bmax-ng. In any case my idea is to 'hide' to the final user the 'lost of time' to write :INT and RETURN (for functions or methods)... I've just hacked MaxIDE to automatically 'close' when I type FOR, FUNCTION, WHILE, etc... with the corrispondent NEXT, END FUNCTION, END and so on...Yes I'm lazy! Technically I write everything in Bmax with SuperStrict... just tried on my skin what means to run OLD code I wrote in 'plain' Bmax... |
| ||
| I've rewritten BRL.DirectSoundAudio. Now DirectSound is working on both 32 and 64-bit Windows builds. The Windows digesteroids64 link in the first post has now been updated with the new DirectSound stuff. Here at least, the crackling that is apparent from the FreeAudio driver appears to be gone now. If some of you would like to test it and let me know if you have any sound-specific issues. Thanks ! |
| ||
| Hello, Sound quality is perfect on both my laptop (Windows 8) and my desktop (Windows 7). A slight, propably meaningless observation. The menu.ogg in the original plays a bit different interval/tempo then the 64 version. -Henri |
| ||
| The menu.ogg in the original plays a bit different interval/tempo then the 64 version Oh? I tried it on OS X and Windows, and it sounds the same on all of them here. |
| ||
| worked great here, win7/64. ya, the menu song loops at an odd place for me too |
| ||
| the menu song loops at an odd place for me too The funny loop thing? It's always done that for me regardless of the platform. |
| ||
| I'll try to send a sample in your email. Hope you can receive over 5 megs. If not give a shout. -Henri |
| ||
| Works perfectly here on Win7 64-bit, sound too! |
| ||
| Wow! this is amazing It works well on Windows 8.1 x64 congratulations Brucey! I have been testing bmx-ng - using the current bcc 0.30 & bmk 2.23 & tdm mingw 64 4.9.2 which works great by the way and I have a quick question in case anyone knows the answer: Is anything in particular needed to perform static linking with digesteroids 32 & 64 bit compiled binaries as I currently need the following dll's alongside in order to run, which in itself is not really a problem, I am just happy to be able to test this out and provide feedback. Thanks you so much for this, it is really awesome being able to use ?win64 libgcc_s_dw2-1.dll libgcc_s_seh_64-1.dll libgcc_s_sjlj-1.dll libstdc++-6.dll libstdc++_64-6.dll |
| ||
| For whatever reason, and despite TDM's notes to the contrary, it appears that TDM MinGW links to the dynamic libraries instead of the static ones. The only way I've found to "fix" this, is to (re)move the files with the suffix ".dll.a" from the distribution. Builds then have no option other than to link statically. (there are 15 such files in the TDM64 4.9.2 distribution) There may be a more programmatic way to fix this, but I've yet to discover it, so for now the removal of those .dll.a files is the current workaround. |
| ||
| Thank you so much Brucey! I thought it may have been my setup at fault. I was also testing the tempest sample, and noticed that vectorfont.bmx generates a compile error: labels must appear before a loop or defdata statement - however if you remove the comment it then happily compiles. vectorfont.bmx - Line 108: #letterdata ' spc DefData 0 |
| ||
| Guess you've seen/tried this already. LDFLAGS=-static And found this. In the past there were issues in MinGW with direct linking to *.dll, so it was advised to create a static library lib*.a with exported symbols from *.dll and link against it instead. The link to this MinGW wiki page is now dead, so I assume that it should be fine to link directly against *.dll now. Furthermore, I did it myself several times with the latest MinGW-w64 distribution, and had no issues, yet. You need link flags -Wl,-Bstatic and -Wl,-Bdynamic because sometimes you want to force static linking, for example, when the dynamic library with the same name is also present in a search path: gcc object1.o object2.o -lMyLib2 -Wl,-Bstatic -lMyLib1 -Wl,-Bdynamic -o output The above snippet guarantees that the default linking priority of -l flag is overridden for MyLib1, i.e. even if MyLib1.dll is present in the search path, LD will choose libMyLib1.a to link against. Notice that for MyLib2 LD will again prefer the dynamic version. NOTE: If MyLib2 depends on MyLib1, then MyLib1 is dynamically linked too, regardless of -Wl,-Bstatic (i.e. it is ignored in this case). To prevent this you would have to link MyLib2 statically too. |
| ||
| Hi Ole JR, Thank you, unfortunately I did try them and quite a few others without any success, they seem to be ignored. The per application compiler options feature that Brucey has implemented is pretty awesome. ' @bmk addldopt -static-libstdc++ ' @bmk addldopt -static-libgcc ' @bmk addldopt -static |
| ||
| Post was more intended for Brucey, but me think he knows about it already :-) |
   |