BlitzMax .Net ?

I'm sure this has been discussed before, but I can't seem to find a thread that really focuses solely on it. Or perhaps I'm just too tired to work the search engine proeprly, it has been a long day already.

I've taken a tidy chunk out of a very large project this year. It's had a few months of work, and I see at least another two years before it could be close to finished, and quite possibly much longer. With that sort of timeframe, I have to think about making my code futureproof, and it seems .Net is the way we're going whether we like it or not when it comes to Windows. DirectX 10 is already leaning very heavily towards managed languages, and I'm starting to reach the point where I find myself wondering if it's sensible to use anything but a .Net language.

BlitzMax is lighter, faster, much more familiar and it doesn't requite the .Net framework. For all those reasons, I would be a fool to ditch it this far into a project that was due to be finished in a few months. Having said that, I'm starting to wonder if I wouldn't be a fool NOT to ditch it when I'm looking at two years down the line minimum, and almost certainly longer.

I have no idea how practical it would be for BlitzMax to become a .Net language, but I know I've seen people wanting it before. How practical or realistic is it? Moreover, is there any interest from BRL? I know Skidracer has an interest in a PocketPC compiler, but does anyone at BRL have an interest in going .Net? Is it an option?

Working on my shader packs and putting the game on hold has given me a lot of time to think about how it's going, so you can blame that for me wandering off the mental track with this. It is a serious thought though, not a whim. BlitzMax is great now, but if everything is going to go the way of .Net ( and Torque, TrueVision, etc, the big boys already have been for a long time moving towards XNA and managed code ) then I have to think ahead and make sure I don't end up stranded.

I am a big .net supporter [but], I'm sure that sticking with BlitzMax will not be a bad decision. I have faith that Mark will keep the language up to date with the latest from MS for years to come.

[edited to make cause and effect more clear, it seemed clearer when I was writing it....]

DX10 leaning toward managed languages???

From my perspective dot net seems to have taken the backseat at M$ in that it hasn't-

been utilised in vista core in any meaningful way
offered in IE to provide some sort of applet / sandbox technology
huge chunks of directshow and dxutil not available without wrapping
j# support for migrating java apps was added, then removed, then added...

That and the blitz community still seems to be larger than the xna one, i'm sure that will change now 1.0 is out but I was pretty suprised the initial release fell so flat.

.

Writing M$ makes you look like huge dorks. Just FYI.

<obscene reply censored>

.

Inefficient

10 M$ = "Money"
20 PRINT M$;" ";
30 GOTO 20

BrEgOrS,

It would be more efficient if line 30 read:
as the variable assignment has already happened. Warren, you beat me to it!

Gabriel,

The key question to ask yourself is: what would moving to .net actually get you?

.net offers a fantastic framework to rapidly build applications. But future proof? What does .net offer now that you could conceivably need in a few years? COM?

I've invested a fair amount of time writing a multimedia editor / player in C#... and dropped it and went to BlitzMax. The BlitzMax version was smaller, faster, and didn't need the .net framework installed, and thus could run directly from a CD. Everything I could do using the .net stuff was available (in one way or another) from within BlitzMax.

Just because Microsoft wills it doesn't mean .net will be a huge success. The Vista team tossed out all the managed stuff because the performance wasn't there. .net is up to 3.0 now, and it's still huge and slow. You don't want to be the first .net application running on a particular framework if you want it to load fast!

If you're seriously thinking about game programming in a .net language, be very aware how the memory management works. Tom Miller (managed DirectX design team leader) has written a few books about this, and it seems you have the choice of writing code that is easy to maintain or code that runs quickly. A core problem is the way structures are passed around: from what I've read, structures are passed as entire copies (unless you declare vast sections as unsafe, then you get to use pointers), and the memory thrashing is huge. My multimedia program was a memory nightmare, tossing around 100meg/second or thereabouts, before actual graphics were done. TomMiller got around that, but the code was some of the nastiest hacking you'll ever see in a managed enviroment. Basically, you unamage wahever you can, make the rest unsafe, and use pointers. Why not write the damn thing in C if you need to address pointers like that?

Anyway, my A$0.02

Finish Max3D first!!

.

I have been wondering about something like this as well... I have an APPLICATION not a game that I am coding over from VB6 days... I have been debating (seriously) B+ or BMax... The killer is it HAS to be able to work on WIN98 (and maybe, hopefully WinCE) because of some hardware limitations.

I know B+ can deal with the hardware limitations but the real run is the need to access a dbase file on a CLAN Server using SQL. Modify it, REad it, and deal with it...

I am at a quandry... I have coded some of it up in B3D (without going in to th SQL stuff... What do I do. I may make my own thread about this soon.

Making something a .Net application does not nessecarilly mean it's future proof. One of my old clients just payed me a sizable sum of money to upgrade their .NET 1.1 tools, so that they would work on .NET 2.0, and I have no doubt that in a few years they'll be doing the same to upgrade to .NET 3.0. Then 4.0 and so on. Face it. History tells us that Microsoft need at least 5 versions of something to get it just right (DOS 5.0, DirectX 5.0, Windows 2000 [which was really Windows NT 5.0]). So maybe by the time we have .NET 5.0 it would be worth seriously considering but until then, I don't see .NET offering much, except a simpler (if inconsistant and constantly changing) API than Win32.

Skidracer: Agreed, XNA hasn't been received well, but that's likely because so many people are happily using VS2005 or VS2003, I would suggest. I wasn't particularly suggesting that Microsoft are forcing anyone's hand, more that the tool developers are helping them along. When I think of the first two major 3d engines to be seriously moving towards XNA, I'm thinking of Torque and TV3D, both of whom favour managed languages. ( Torque XNA does, I know previous Torques didn't )

Neilo: Thanks for the important considerations. I'll certainly look into that and see how it might affect me. I have a feeling that the type of game I'm making will have a lot less trouble with the memory management situation you describe than many games, but it's certainly something I have to consider and test out.

FlameDuck: You've brought up precisely one of the situations I had in mind when writing this thread. Being able to pay somenoe a sizeable sum to update the game to the the newest version of the framework is precisely what I want as an option should I not wish to do it myself. Had I written a game in B3D that I wanted updated to BMax, I wouldn't have a clue who to hire, but finding reliable, experienced .Net programmers is much easier.

Agreed on the 5 versions historically, but in the case of .Net it wasn't Microsoft's creation, just their implementation, so perhaps we'll be able to skip a couple of generations ;)

Like directx then

If you say so. I wasn't using a PC back then.

.NET is backwards compatible AFAIK. What changed that they couldn't run their 1.1 tools on 2.0?

I think XNA isn't catching on because, at the moment, there's no way to monetize what you create. You can't sell your games through Live Arcade so I think a lot of people are thinking, "Why bother?" If they come up with some sort of 'indie channel' or whatever it will get a LOT more popular.

> I think XNA isn't catching on because, at the moment, there's no way to monetize what you create.

You can on the windows side, or at least you can distribute it. I have not read the license agreement on being allowed to sell what is written.

You can sell on regular Windows boxes I think but since that's no different than any other programming language there's little draw to use XNA at the moment. You can push to an XBox and share your games with your friends but there's no way to make money yet.

> You can sell on regular Windows boxes I think but since that's no different than any other programming language

It is also XP service pack 2 and higher only. (well Vista support is not official yet either). That is indicative of the one real (to me) reason to not go with MS products - doing so will lock you into the OS upgrade rat race. Where products like Blitzmax will allow not only a large range of MS OSs but also Linux and Mac.

From what I can tell ATM, mostly service and remoting stuff. I'll have to wait until I get my proper copy of Visual Studio 2005 until I know for sure tho', since the express version doesn't do services. At all.

Defiance/Jim T was building a blitzmax compiler for .net, but he dropped it. Theres a thread somewhere on www.devcrunch.com about it.

I had started on a blitzbasic compiler in c# and codedom a long ways back. Its just a project I pick up for an hour or 2 every so often, but I'm sure if I stuck with it I could have it complete relatively quick.

Weekend before last, just for fun I started on a seperate blitz compiler, this time using blitz. It outputs raw il, and has the mono ilasm.exe tool assemble it into a .net exe. My goal is to eventually have the blitz version compile itself into a .net version( but right now, its pretty much limited to printing expressions ). I'll put up a zip if anyones interested.

Anyways, I think .NET makes writing compilers a bit easier, because of the CodeDOM classes and the stack based nature of il. I was learning il as I went, and got my 2nd version producing meaningful exe's pretty quickly. If the powers that be at BRL would want a .net version, I'd be really interested in helping out.

Not to mention, I would like pick marks brain about how he goes about working on his compilers..

@neilo - Regarding passing of structs, you have to understand that .net splits up the type system into reference and value types. C# structs are value types, and the default behaviour of passing by value is to create a copy( ie, when you pass them into methods ). If you use the 'ref' keyword though, they are passed by reference and even large structs can be fast n cheap. There's no need for unsafe contexts to have speedy structs.

Orca that sounds KEWL!!!!

Orca,

I don't think I have ever seen that mention before.

Thanks!

Wow.. how did I miss THIS thread?

I've pushed for this type of thing for a long time. I believe the Unity engine uses .Net assemblies under Mono to get compilation on the Mac, so it wouldn't be far removed at all for Max to retain cross platform capability even in the .Net world.

Things that have proven challenging to the native code generating Max are already part of the .Net framework (garbage collection, OO concepts, etc)

In theory, it wouldn't be too difficult to use CodeDOM to write a BMax.Net compiler against .Max files. The syntax is similar to most of the .Net languages.

I imagine the tricky part would be the pre-compiled framework files (provided all of those were going to be translated into .Net assemblies rather than linking native code libraries. And really, what's the point of doing a .Net version unless you go to pure or close to pure assemblies.)

Microsoft has already provided a bit of a mapping from Win32 to .Net.
(for those interested...)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/win32map.asp

There might even be an application out there that takes Win32 code and translates it to IL.



I'm not sure that indicates it's taking a back seat.

XNA was a rushed product. From my understanding, you can't even develop a game with it unless you use their free version of C# (why on earth should I need to install that if I have VS Pro?) This is the direction they are going though. They want to leverage PC and XBox. And since PS3 runs (or was it, is capable of) a Linux OS, it's not unreasonable that Mono could possibly run XNA assemblies if open GL is used instead of DirectX.

But you are correct about the Vista thing. After touting for months that Vista was going to be .Net in it's core, there are actually a minority of libraries that are managed code (well, according to things I've read anyway)

Then again, if you think about the hassle Microsoft got with marrying IE too close to Windows, it might be a legal decision to keep .Net deliberately separate from the OS and just make it a provided service.

That certainly seems to be how they've organized their development efforts lately. You KNOW Sun is just looking for an excuse to call their lawyers again ("Microsoft is shipping .Net, but not Java with their OS...")

minority of Vista libraries is .NET, but the whole desktop at least is .NET 3.0 (originally WinFX), so if you want to do anything that "shows something" you will most likely be on .NET :)

But I'm sure more are going to be .NET based at a later date (most likely everything beside the kernel and the fallback integration for stone age programmers who still think API UI hacking is a valid solution in 2006. Would be as if Apple never introduced cocoa lol ... but for some reason Windows programmers believe thats the way to go?!)

which might explain the high spec. requirement.. LOL

For Aero, yes. Shader min. Otherwise you have to use the non-hardware accelerated.

But this makes sense, is no different on OSX ...

And the Req aren't high, really. They sound worse than they actually are for regular users. Radeon 9700 with 64MB VRAM actually performs quite good (128MB and it won't have any problems at all). Pro is that the desktop needs no CPU time :)

.NET ?

Are we going to make another DarkBASIC Max?

Just to clarify, .net IS part of the Vista API. so it has no sense discussing if BlitzMax should or Should not use .net. It will, if it continues supporting the Windows platform.

The real question is, will it be better to support DIRECTLY the .net, and take profit of the .NET run-time compiling? the answer is obviously YES.

Does this means that users will have to download the .net framework? the anser is NO, if they use windows vista. It has become part of the OS api.

So programs would be runable directly from a CD? Yes.

Ok, but programs will be slower? NO, the MSIL compiler generates 100% pure binary source code, optimized for the platform it is running on, at execution time. So in some situations it runs even faster.

But woud it be cross platform compatible? Yes, MONO is the MAC and LINUX implementation for the .net framework. It covers 100% of the .net 1.1 framework, and it is being improved to cover .net 2.0 in a few months. The most exciting thing about MONO is that binaries generated by .net on windows CAN BE RUN DIRECTLY on MacOsX and Linux, an vice-versa, as long as the source code doesn't include Os speciffic API calls.

I think .net or MONO is the way to go...

Just to enlighten us. Which .NET? 1.1? 2.0? 3.0?

Postulate. Why is the answer obviously yes? It doesn't seem particularly obvious to me.

Which I'm sure is nice for the 20 or so people who have Vista. For everyone using XP SP2 the answer is YES, and for everyone using anything else the answer is go fuck yourselves.

They are already runnable from a CD.

Well Neverwinter Nights 2 certainly is. Please elaborate under what possible scenario a JIT compiled binary is ever faster than a natively compiled one.

So when are we getting blide for Linux and Mac then? If it's as simple as you seem to indicate that wouldn't be difficult at all, would it?

Which is absolutely useless as Vista ships with 3.0 and like 2.0 it is not immediately backwards compatible.

What application could you possibly write in .Net that doesn't use specific API calls?

I think Java is a better bet. Not only has it been out longer (and thus more throughly tested), it's also more widely adapted.

Well actually I think BlitzMAX should keep generating native code as long as humanly possible. I'd rather have a cross compiler than a .Net one.

@Flameduck
.net 3.0 is compatible 100% with 2.0, in fact, it is 2.0 with the winFx AddOn. it is absolutely backwards compatible.
It will be better becouse it will not be wrapped by a 'compatibility dll' based system that, in fact, calls the .net framework. so it is faster.
well, I thought we were talking about the future of BlitzMax, not the present. I don't know much people that uses still Windows 95 wich is not supported by BlitzMax. So I assume windows users will be using vista in a not so far future. By the way, MacOsX supports XWindows, wich is the basis for MONO...
copared to what? is there any non .net version to compare it?
And, well, a SML compiled binary is never executed. It is re-compiled by the MSIL compiler TO A NATIVE BINARY just before it is runned. so at this point they are equaly fast, but the fact that a .net binary is compiled in the computer where it is executed, enables the inclussion of some CPU speciffic optimizations that are not possible in a statically compiled traditional binary, unless there are some checks made before (and increasing the size of the final executable). That makes the binarys of .net runnable from a MacOsX or Linux system also, without having to create a final static executable.
A JIT (just in time) is a debuger,not a kind of compiled binary.
That's not true. .net 3.0 i .net 2.0 plus WinFx and it is 100% backwards compatible. (By the way, .net 2.0 was backwards compatible too, except for the network class, that was changed to be even more secure. most of the .net 1.1 applications can be run under .net 2.0 without any change)


Most of them. BLIde as instance. the framework is powerfull enought to make hardly everything you can imagine. Most (not to say all) of the windows APIs have their corresponding method or even class in the .net framework. And in addition, they are organized and put together in a OO mode. the MSIL compiler translates this, not at run time, but just before run time, to the appropiate APIs of the OS where the application is running. (In case the APIs are not written directly on .NET, then there is no matching API to call, the code is executed directly increasing speed)
Well... just to clarify that Java is intepreted and .net is compiled, the same as BlitzMax... By the way, .net is also cross platform...

As soon as windows version gets stable and MONO 2.0 is released I will begin the beta testing process. (By the way, I will need some help).

I'll use .NET 3.0 and make Blitz.NET for free.....
(Brand name may change due to copyright)

That's a progressing project and we jut switching to .NET 3.0 SDK recently.

This is true to an extent. The difference with run time compiling is there simply isn't enough time to use a lot of optimisations that you can afford with pre-compiled code.

It's also debatable exactly how much benefit can be gained from enabling certain CPU options. Specifically, many pre-compiled programs already include support for MMX, SSE, SSE2, etc. when available but only for parts that can actually benefit from it. Good code for these units generally needs to be specifically targetted to them to, which I doubt the JIT compiler can do.

Not to say MS's JIT compiler isn't good, it is pretty good, but for things like games where performance is critical I would much rather the code was pre-compiled.

If Mono has suddenly become fully compatible with .NET 1.1, I'm not aware of it. Yes Mono supports quite a bit of the 1.1 Framework, but by the same token quite a bit more is missing (or was last I heard.) I wouldn't put my faith in Mono providing full cross-platform support ever, because they simply won't be able to keep up with MS. WINE has the same problem.

But wouldn't the standard optimizations be put into the pcode that gets JIT compiled later? I can't imagine that the pcode that gets sent to the end user is a line by line translation of your source.

What? That doesn't even make sense!

Well that's a somewhat ignorant assumption, considering most people don't even have the hardware to run it, much less use it for anything.

How is this relevant to the number of people using Vista? And saying MacOSX supports XWindows is like saying Windows supports Linux. Which it does if you install cygwin and recompile the applications. It's not exactly what most people would consider "support" tho' and the technical insight required is way, way above the average users.

A JIT compiler is a peice of software that takes an arbitrary language (MSIL or Java Bytecode) and just in time to execute it on the target computer, compiles it to a native binary.

Name one. At the same time, explain why my "C:\WINDOWS\Microsoft.NET\Framework" folder contains the following folders: v1.0.3705, v1.1.4322 and v2.0.50727? Surely if your claims of backwards compatibility where not make believe, only the later of the three frameworks would have to be installed?

Well just to clarify, Java and .Net are both JIT compilled, where as BlitzMAX is staticly compiled. So .Net and BlitzMAX have nothing in common.

And by the way, .Net (and certainly not 3.0) isn't cross platform. It doesn't even work on Windows operating systems, with the exeption of Windows XP SP2, Windows Server 2003 and Windows Vista.

Well you got it. A decent BlitzMAX Developer Environment on Linux would be way cool.

My opinion:

10 M$ = "Money"
20 PRINT M$;" ";
30 GOTO 40

It means... M$ = BUGS and BUGS! :-(

first of all, I would like to say that I don't like the way things are going on this thread, It seems we are getting nervous. I'm not native english and sometimes I can seem a little rude just becouse I'm trying to find the words to say something, and I tend to be a little, as flameduck says, "postulating". I apologize if that makes my comments a little bit unpolite. that is not my intention. no way.

well, some parts of the Vista API are themselves written in .net, spetially all the aereo library. How could you call this apis without using the .net framewok?
The same was happening when XP was released. My computer runs vista with Aereo and it has two years.
That's not true, XWindows is part of the MacOsX since 10.3.11 on PPC based macintosh. There are very used applications such as OpenOffice that runs on MAC using the XWindows system. I can't imagine a native support for Linux on Windows...
That's right. I was confusing words. Thanks for making it clear.

the best advice is always to install last stable release. BLIde is running on .net 2.0 and 3.0 perfectly. It also runed on 1.1 in the past. All the .net framework are deployed as full instalations by Microsoft, and not as updates. If you want to know why, it would be better to ask them. If you want me to name one application, what about Sony Vegas?

that's not true. I've been using .net 2.0 on a windows 98, on a Tablet PC, on windows XP SP1, on Windows XP SP2, and on windows vista. To be cross platform doesn't mean to be part of the OS, means to be runable on diferent platforms (once installed). I mean, BlitzMax is cross platform, not becouse it is part of any OS, but becouse it can be run in several, the same as .net frameworks.

Actually .net ran fine when I was on windows me, and it runs fine here on windows 2000. Im pretty sure I have it installed on my 98 partition right now as well, but can't remember off the top of my head. Can't be bothered looking.

Now, I personally haven't used mono on anything besides windows-- but what I have tested works. Including game type programs. I've tried running on pc's without .net, and instead using mono. Works great outside of win98( mono doesn't support 98 out of the box, and I couldn't be bothered to compile it for 98. )

Misterx even tested one of my binaries on linux, and according to him it worked right out of the box( not just a commandline app, but an opengl program ). This was a long time ago, mono has progressed soo much since then.

The mono implementation of windows.forms is fairly mature now from what I've read. Everytime I look mono is improving by leaps and bounds.

Now if only the mono guys would make it easier to use the makebundle tool..

@Orca: They are creating a very nice IDE that will make it easier. I can't remember its name, but in the MONO official website it is a link.

About that Basic program thing:-



Wouldnt it be far better just to have:-

10 PRINT "Money"
20 GOTO 20

And call the program "Microsoft.BAS"? :)

Dabz

That's the trouble with Dev forums. There's always someone around to optimize your code for you XD

I would certainly think so. I don't know all the workings of .Net compilation, but I know Microsoft have sunk good money into it, and performance is improving with each new release in my experience.

The thing about pre-optimising the pcode, is that it may limit the other argument about optimising for specific CPU features. If you start tailoring your pcode, then you may lose out on the ability to compile it optimally for a specific platform. In practice this is probably not much of an issue, since they only support x86 CPUs which usually have MMX or SSE.

The more CPU specific level of things, like let's say AMD has a few instructions that execute faster on their CPU than another equivalent set on an Intel, well, I don't think they would do that at all, but I may be wrong.

You must not be using .Net 3.0 then. And I quote:

Your assumption is true, you only need the latest version of .Net installed, and the assembly will compile against that runtime.

However, .Net applications have a "preference" to run on the version they were compiled on. If you happen to have that version on your PC, it will actually compile under that frame work version and run alongside other assemblies. If the version it was compiled under isn't present, it will execute under the latest version of the framework. Or, you can specify via configuration file to target some middle version of the framework if you wish.

That said, it's possible to make applications on an earlier version that are not forward compatible. As far as I know, this is only an issue if you start using methods and classes that are not deemed for public consumption. Unfortunately, unless you have a re-factoring/development tool add-in such as resharper, those "forbidden" methods are not entirely obvious unless you look into the documentation. As long as you're not committing these crimes, you should never have to redirect an assembly to compile on an older version.


Unless you're doing a lot of late binding, or late references on assemblies, all of the compilation will occur at the beginning of the application's life time. Most games already have a "loading" phase for bringing in content.

It probably wouldn't be a bad thing for .Net to eventually have a compiling splash screen (ala java) for this purpose. They could take it a step further and allow it to be customizable.

Also, as multi-core processors become the norm, I'd expect the JIT process to eventaully sort dependencies and multi-thread the compilation process.


I'd be fine with that. Any intermediate byte code "language" that JITs to allow for and eases the headache around deployment to other platforms works. As long as I don't have to program in Java, to leverage their compiler, I'm happy. :)

.