What are the benefits.
BlitzMax Forums/BlitzMax NG/What are the benefits.
| ||
| Of BlitzMax NG over the Origanal BlitzMax. |
| ||
| Primarily, native 64-bit binaries, and support for new platforms, such as the Raspberry Pi. Other useful additions include Interfaces, method overloading, and overloading of New() - allowing you to provide arguments to New. It can also take advantage of advances in compiler optimisations, which can result in code that runs significantly faster than that of BlitzMax 1.50. (YMMV, etc) |
| ||
| Are all your modules working with NG Brucey? |
| ||
| Are all your modules working with NG Brucey? Not all, but many do. Raknet hasn't compiled for me (on windows) for a long time, just to name one. Same for magick. dbsqllite compilation errors out and states that the library won't work when compiled with gcc using the -fastmath flag, which is enabled by default in NG. Many others like wx, regex, registry, volumes, escapi, freeimage, etc. all compile and appear to work OK. |
| ||
| dbsqllite compilation errors out Oh? Sorry. Will patch that. |
| ||
| I noticed image magick fails to compile all the way, but freeimage seems okay. I am missing otus.lzma at the moment, it fails also. |
| ||
| dbsqllite compilation errors out Oh? Sorry. Will patch that. Thanks, compiles & works now. |
| ||
| Are all your modules working with NG Brucey? FWIW, I have 58 modules under bah.mod that all compile without errors with the latest version of NG. Don't know if they are all compatible with 64 bit. |
| ||
| Does NG have Networking and access to 3d, I know you minib3d don't work. |
| ||
| Does NG have Networking Depends on what you need with networking -- you can (down)load files from network resources (http:: ) and there's brl.gnet, but bah.raknet doesn't compile. |
| ||
| was thinking of things like sockets etc |
| ||
| I've rewritten a chunk of stuff to support ipv6. Unfortunately, GNET is ipv4 only, as the version of enet it uses is very old - I'm currently unsure of ipv6 support in enet (which is half of a problem, as enet has changed considerably since the version we are using anyway, so porting may be non-trivial). The code is barely tested - insofar as I am able to read specs and migrate the modules, but my experience of socket programming is very limited, so I'd expect there to be some issues outstanding. As far as I am aware, I have Pub.stdc, BRL.Socket and BRL.SocketStream ipv4/ipv6 capable now using the latest APIs to do so. I've only tested on OSX so far, which may mean some tweaks for Windows/Linux, but I believe most platforms are using the same APIs for this stuff. Given the APIs I've broken to implement it, user code will probably require some changes, even if they are not interested in ipv6. I've tried, like everywhere suggests is the the way to go, to make the functionality protocol agnostic - that is, you as the programmer may not care if you are getting v4 or v6, as long as you get your socket, and everything just works. |
| ||
| Good to know.. Brucey: Do you happen to have any info yet on how to use GCC higher than 5.1 with NG? (What installer, ...?) |
| ||
| brilliant stuff :) |
   |