Mark has spoken

http://www.blitzbasic.com/logs/userlog.php?user=1&log=1043

Why must you torture us so, with gxLib?
(Although it is good to know you aren't directly competing with your own UI library :P).

The update sounds really good.

Reflection support?

Ah, must be some OOP term.


I don't think Mark realizes he's selling this thing to people who may have only very limited OOP experience. It is basic after all. If I knew how to code in C++ I would be coding in C++. As such, I can't get very excited about this new reflection thing as I have no understanding of what it does, and his examples don't make it any clearer.

I'm afraid too much of this OOP stuff is gonna out the language completely out of the reach of the sort of folks Blitz was originally aimed at. Hobbyists who just want to get to the meat of the game. I haven't even gotten into using the Extend stuff, because the way Max works now it is unweildly to use my sprite system by extending the type rather than just storing the sprite in a field in a new type. Partly because of the memory management, and partly for other reasons I don't remember exactly that had to do with creating new instances requiring you to recreate the create function.

Even if it makes the code prettier to look at to someone who understands it it becomes completely incomprehensible to somone who doesn't. Like Mark's examples there. Can't understand what the heck he's doing with it. What the heck is a low budget delegate and why would I want to make one? And I don't even want to try to figure out what the heck Object does. I think it lets you pass any sort of object but I really don't like the idea of coding like that.

I have this sinking feeling that Max3D is going to be as incomprehensible to me as Direct3D was when I finally decided to try learning it only to realise it was all in C++ which I never grasped well.

I like putting functions and variables inside my types to help avoid naming conflicts and keep stuff better organized. But that's where I draw the line!

lol. I partly agree about the reflection thing, it sounds exciting to be able to sort of `find` types or fields within types at runtime without knowing at the development stage, but we really need some better examples of how this is going to be useful and to do what. Hopefully it is fully documented in the new documentation.

Otherwise it sort of sounds promising, but as usual, I'm sure a lot of people will think that Mark is working on stuff that THEY are not interested in. Can't please em all.

Reflection doesn't do doodly for me. But it could be put to good use for certain situations.

I find the bit about the GxLib going 3D an interesting throw away line.

Well what everyone is interested in is the 3D engine. Nobody wanted all this OOP stuff. At least, that's not what most people wanted primarily. They just wanted Blitz 3D to be faster, have a better terrain engine, support proper mirrors, support shaders, support normal maps, and have a robust built in shadow system. That's all they really wanted. What Mark is doing seems like overengineering for his own amusement. He seems to love making compilers!

I just want 3D. And being able to compile to various consoles would be nice.

And I also want the stupid referencing issues to be fixed. We need weak references! Mark made this clever memory management system and then left off a major component that completely destroys the point of the whole thing, because if you keep anything in lists that keeps a link to itself, which you need to do, then you have to call functions to free the stuff anyway, thus defeating the purpouse of the elegant design in the first place.

All this other stuff he's adding I have no use for. Maybe I'll have some use for it in ten years when I've learned how to use it and then waste 90% of my time designing and redesigning my code instead of getting actual work done, but for now I don't even know what the stuff does, and I doubt even 5% of Mark's userbase does either.

I'm sure Dreamora will love this though. :-)

Speak for yourself. Some of us are much more interested in improving the language and completely uninterested in any 3d module.


Yes, well fair enough if that's what you want. but it's definitely not what everyone wants. A lot of people are happy with 2D and a lot of us already have 3d.


it's what he does best.

I think this runtime reflection stuff is pretty handy, myself :)

For example, it is great if you want a generic Save / Load system. Instead of going through piles of hard-coding, manually linking strings to variables and fussing through lines and lines of repetitive code, you can use runtime reflection with the "meta data" thingy, to automatically save variables marked as "savable". Linking the name in the file with the name of the variable happens automatically, and making something savable takes a single addition to the already existing object; not even another line of code.

What this is giving us is a power normally reserved for scripting languages like Python or PHP. Here we have variables that know what they are called, with a compiled program. Reflection solves a good half of the problems people have when it comes to objects that must be treated anonymously; whose actual contexts are not technically known, but which must be operated on in a uniform way.
Often, people solve that stuff with external scripts and masses of XML, but now we can get a lot more of that flexibility within BlitzMax.

Again, for game development (rather than tools), that is probably not as useful. The meta data sure is, though!

A good chunk of my code now uses reflection. It is invaluable.

local e:Enemy = Enemy( ReadObject( "myenemy.txt" ) )
Local obj:Object = Copy( e )

print e.x '200
MakeUndoStage( e )
e.x = 500
Undo( e )
print e.x '200

Could someone explain reflection? IS it some sort of "redefines" also found in archaic languages like Cobol, or rearranging of memeory areas? LIke taking a chunk of memory, but mapping it using some other type or something in the likes?

Cheers.

I missed the part about when he will add private/protected fields to types. This would be real useful...

Reflection: http://en.wikipedia.org/wiki/Reflection_%28computer_science%29

But it seems overly complex. A good and simple reflection example code in BlitzMax would be nice.

Now this is interesting:


Is that what we're talking about? That would probably call the end of needing some scripting languages.

I think reflection is great. I'll probably rewrite my unit testing module to use it.
The meta-data functionality appears to work a lot like Java's Annotations, which could mean you tag a method as one to be run during the test. very nice :-)

Of course, everyone unit tests their code anyway, don't they? :-)

You would still need to parse the statement, and some way to bind it to a context (eg as a 'method' in a type).

Gabriel:
"Speak for yourself. Some of us are much more interested in improving the language and completely uninterested in any 3d module."


If you're not most interested in BlitzMax's capability to be a cross platform 3D language, then why do you use it? Why not just use C++ or one of the many other object oriented languages out there which are much more mature, faster, have better support, better IDE's, and are bug free?

And I didn't say everyone, I said most people.


Michael:
"A good chunk of my code now uses reflection. It is invaluable."

I don't get what is supposed to be important there. The loading myenemy.txt, or the copying of one instance of the type to another?

I read that Wikipedia article. This is one of the better examples:




Note what it says about the downsides. Harder to read, no semantic checking.

What this seems to allow you to do is... Well I don't know what the hell it's supposed to allow you to do. It allows you to "vary the class name at runtime". So what? Why in the world would you want to do that? I don't want my "enemy" type to be called "ship" sometimes.


I see what it's doing there though. The code is a pain in the ass to read, but what it's doing is making an instance of a type, and then searching for a method called "hello" in it, and getting the pointer to that and saving the pointer in it's "method" method, so that when you go cls.method it calls the "hello" method.

See? I can't even explain it in a way that's easy to read. And that example just shows a class with one method. What if you've got 20? Do you have to instance each one with this horrible code?

I suppose if one wants to code their whole game using script files this might come in handy. But I'm making litle shareware games. That's overkill.


Oh and when I was in school, we were taught that self-modifying code was the devil, and would lead only to heartbreak. If this is what commercial game developers are using it's no wonder their games are so full of bugs and take three hours to compile. :-)

sswift, C++ is the worst attempt at an OO language that's ever been created. You should not use it as a reference. Java and SmallTalk are much better examples for OO languages. Also, C++ is losing more and more of its relevance. Soon, like COBOL, it will become a legacy language only used for maintaining old projects. Java and C# are eating its lunch, and that for many good reasons.

Using OO techniques can make your life significantly easier, in any language. You should take another look at it. And do yourself a favour: DON'T use C++ to learn OO concepts.

I also don't care much for a BlitzMax 3D engine. The language has a lot of potential, especially in other areas than gaming. Many people here have never even used it for writing games. The problem is that we cannot be sure that Mark fully realizes the potential he's created; people actually want to use BlitzMax to write APPLICATIONS, servers and middleware. It's great that you can easily create wonderful games with it, but I'm afraid that it is no longer the main/only focus of its users.

This reflection things looks interesting. I'm not sure I understand it though.
Can I, using reflection, check an object and see if it contains a function or field?
Instead of doing stuff like this:

local an_object:TEntity = get_current_entity()
local enemy:TEnemy = TEnemy( an_object )
if enemy then
  ' call a method only available in TEnemy
endif
local bullet:TBullet = TBullet( an_object )
  ' call a method that only exists in TBullet
endif

(In the example TEnemy and TBullet extends TEntity)
Probably a bad example and design but anyway.

If I could check if a method, function, global or field is present in an object that would probably save a lot of code and time. :)

EDIT: new posts created during the time I wrote this answers my question. Never mind me.

No its not? Have you ever programmed in C++ before? And if I read sswift's post above yours correctly... he is referencing a JAVA example!!! Oo



No, unmanaged code is losing it relevance... C++ will be needed for a few years yet and is not going away... This type of "C++ is dying" gossip has been going on for years and never seems to let up...

Its still here, I'm using it, Mark is probably using it, in fact, its still looks like an industry standard language as I've just googled "C++ jobs" and there hordes of vacancies!

Dabz

Sswift - it's not overkill because if you can think at a higher level then everything is faster to write. Read/Write object, copy object, unlimited undo/redo, generic composite editor, generic property editor are just some of the components I've made with reflection, and the point is that they same loaders/savers will work for not only this game's objects but the next and the one after that - there are a whole lot of routines that can be written generally so that they've only got to be written once.

And please, don't try to argue against a feature because a five line example doesn't make sense. It's telling you how to use it, not giving you a practical use for it.

I'm not arguing AGAINST a feature, I'm arguing FOR getting back to work on the 3D engine! :-)

I think it's good to expand the brain and have cool things possible in a programming language. But when it becomes overly complex to read the code, one might wonder at which point iot becomes unproductive, and what sort of coding are we going to do with this (OO, reflection, methods...). Plain Blitz3D is nice in the sense that you have simple code to read, that even the basic programmer can read and understand, from simplistic basic code. Of course we can overcomplicate anything in any language. But it could be that a language overcomplicates things for you also. I would think that using some specific OO ways of programming can only be good practice if it's not overdone. Properly used under absolute necessity, it becomes probably a joy to take in the code and work with it.

I'm sure sswift, overlooks the need of some of these recent additions to programming languages. If only we can properly understand their usefulness, only then we can stop arguing about this. As stated months ago by someone here, you are not forced to use the object oriented features. BlitzMax can be programmed pretty much in the same way that you program in Blitz3D. Only some minor differences in the way you declare Types, and put comments in code, and some other rather trivial things.

But of course, BlitzMax is not replacing Blitz3D right now, but hopefully it will, in my project.

Mark added the feature for himself to develop the 3D engine, so they are one and the same really.

_33: Well that's what programming boils down to, really - abstraction management. You've just got to figure out which abstractions are net positive and which are net negative, and this will vary person per person as well. If you understand reflection well, then there's nothing more natural than writing a generic CopyObject function and that is going to save a hell of a lot of time over the life of the project. Fire and forget, and it makes the main source more clear.

But if you don't understand reflection then you end up doing Method Copy:Object() in your types and that's probably better than having a black box in your code.

What i miss in the worklog is some insight on the big picture.

@Sswift-

I have learned C++, though not used it much. I program C every day at work. C++ is an industry standard for two main reasons:

1) You can do just about anything in it that you can can do in other languages
2) Historical/legagy

Give me Blitz over C++ any day. I can write programs that have some chance of compiling without a million errors that need fixing.

I think your worries that Max3D, when (if) it comes will be hard to understand for you are unfounded. Look at Blitz in general and the Max2D module - you never even have to touch methods as they all have function wrappers.

I think Mark has done a good job of providing some depth to the language without making the basics accessible to everyone. The only downside is that some of the new features, as you say, may not be of interest to many.

One question I have, based upon the worklogs, is does this work?

Local typeString:String = xmlNode.Name()
Local nType:Object = New typeString

Wherein a new type of whatever xmlNode's name is would be produced, or null/exception if it is of a type that has no implementation.

I completely agree with Sswift here.

I've not switched to MAX as it doesn't do what I want, and what it does do seems to be way too much like proper programming for my liking.

All I wanted from MAX was B3D with a few extra features... Pretty much what Sswift said, Updated 3D engine, updated sound engine, cross platform, etc etc. Oh and some kind of relational database plugged on the arse of it would be good too.

As it happens MAX has less features due to the lack of native 3D support (and isn't there something about needing to licence fmod for sound or something?!), therefore it utterly pointless for my cocking around style of game programming.

Nomen;


That's actually not true at all. Look no further than the feature set of lisp (and by extension the many languages that offer much of what lisp offers - like ruby) - macros, closures, runtime code compilation, code as data, keyword arguments, native garbage collection. You can define your own constructs like for, eachin, classes etc in lisp, in the same environment that you're writing your project in (of course, lisp ships with libraries that do all of this well already). The features that we're talking about on this thread - reflection, metadata etc - can be defined by the end user, like modules except for language constructs.

There's a reason for Greenspun's 10th law of programming:



Noel - close, you've got TTypeID.ForName( xmlNode.Name() ).NewObject() (or NewArray() etc). So yes, you can do that.

I agree with Sswift too.
Thought the Reflection thing looks usefull (Don't understand very well, but with "findMethod(string)" could open the door to something like own "Script" language), I think the main requested features is ... the 3D module.
The 2 years old sceenshots and testdemos of the early version of the fantomatic "3D module" was promosing : In 2 years nothing? What happened? no a new info, no a new screenshot, nothing of nothing.... But people still waiting :)

I'm with Sswift, I dont need more ways of doing the same things that I can already do with BlitzMax. What I need is BlitzMax to be able to do something new.

Like Sswift i'd have been happy with an evolution of Blitz3D, object instancing and shaders, some DX9 stuff. I love the engine, I dont want the earth, it just misses out a few modern features but other than that it's a great engine.

Instead we get treated to BlitzMax and promises of it's potential, which in all the years i've owned BMax have never been fulfilled.

So I agree with Sswift.

I'm sure reflection would be really useful if I could be bothered to learn it, but unless it will enable me to do anything that I cant already do I almost certainly wont bother - because I believe in simplicity.

BMax gets ever more complicated, but still cant handle UDP packets without learning C...

I feel like Mark wants Blitz to stand for something else that what I originally came here for, and that's why with every worklog I feel Blitz further distancing itself from what I want in a language.

Blitz3D with some DX9 features is all most of the forum goers here have wanted for the last few years.

Still, nice reflection system... Shame it isn't a 3D reflection shader though, now that I would be interested in.

Anything that makes Blitz more Lisp-like is a wonderful, beautiful addition in my eyes. Granted, it makes the self-reflection module I was working on more or less obsolete. I'm curious to see how the overhead of the native system compares to my hashtable based system.

Question: Is it possible to add new variables and methods to a class at runtime with this reflection? It doesn't seem so - so maybe my module isn't obsolete afterall.

How do I talk myself out of this one?? You're right of course... C has macros though, I guess they differ from ow they work in Ruby etc? I guess I would change my statement to 'you can do just about anything in C++, but a lot of it is a messy fudge'

The Reflection bit is definatly good news as far as I'm concerned. Very nice!

I have to agree with some of the earlier posts in this thread, Not everyone is all that intertested in the 3D stuff. There is a lot more to making games than having a 'decent' 3d Gfx library... specially considering there's allready a wadload of them out there, ready to use with Bmax.

Reflection opens up a whole range of cool things I can do with blitz. The saving/loading of anonymous persistent objects is only the tip of the iceberg. I'll have to go play with it to see just how far this can be taken, but I have some pretty nifty ideas that can make Blitz not only good for games themselves, but also give it a new leg up in the remote communication department.

Delegates are interesting to, allthough a light-weight eventhandling system can already be done very easily in the current Bmax implementation.

I'd say, a programming language can't be too big as long as the help is aimed at "BASIC level". It's just like BMax already is: superstrict strictness, classes, pointers, function pointers.. but no one MUST use them. They're there, and those who want to use it may use it. It *will* go wrong when the help -which isn't all galore anyway- offers the most simple examples of various commands using these high-end functionalities. One of the things that keep me from delving into other languages is that their help documents are extremely large, unfocused and usually aimed at people who're already code gods.

Dabz, yeah, C++ is somewhere on my CV, and sswift probably posted his message while I was typing mine.

To be superhonest: I only care about those useless programming language (or operating system) discussions when I'm in the mood for some death match entertainment. I was this morning while I was having breakfast, but I am not in the mood right now, because I'm in the office.

For me, C, C++ and even Objective-C are some of the ugliest languages ever invented. Unfortunately, they got a lot of acceptance. A beautifully designed language for me still is Pascal. It's clean and clearly strutctured - and does everything C can can do. But somehow people prefered the curly braces. Oh, my.

As for the job vancancies, Java outnumbers C++ by what factor? Four? Five? Java is the #1 programming language in this world, the others are just playing catch-up. And, no, I'm not a Java-Fanboy, this is just a plain fact (one that none of us has to like).

But sometimes, the really well-paid jobs are with niche languages that nobody is good at anymore. There are still good bucks to be made with COBOL, for example. Pascal-like languages are used in industry-robotics. The Military once had a faible for ADA and probably has millions of lines of code written in it that require maintenance. You get the idea.

But here's the general news flash: All these languages are just TOOLS. Some do certain jobs better than others, and NONE of them is the magical silver bullet. That's what they have in common with human languages. Italian is better for a fight with your girl friend, German is great when you want to command an army and Spanish is wonderful when you want to show off your "machismo" or go out and party. And ALL of them have a rightfully deserved place in this world.

Anyway. It's lunchtime, and I'll now go and do the Homer Simpson thing. ;-)

Lol! very nicely put ^^

Well I'm just hoping that mark actually releases a Blitz3D V2.0 which has got a new 3D engine and a database strapped on it's arse.

OK... I accept this is about as likely as Angelina Jolie walking up to me bare chested and saying "Hey Rob, fancy a juggle?"... But hey

lol, neither am I if I'm super honest too! :)

I was in a car crash on wedensday gone and the head is still a little sore! :) No need to make it worse ;)

I like C++, but like anything else... its horses for courses really! ;)

Dabz

This is becoming one of those 100+ post threads where everybody and his dog take his chance to spill his thoughts about the past,current and future situation of BlitzMax.

Now my 2c:
Reflection is (as far as i can see) a godsend since I'm busy with object serialization and trying some methods to implement component based programming
in BMax(eg. http://www.drizzle.com/~scottb/gdc/game-objects.htm IE-only)
So thumbs up on this one.

One of my pet peeves is the way we get informed on new developments. Occasionally filling worklogs with vague or half complete ramblings is not very informing.
I had the chance to read one of mark's posts on the beta forum forum and it was crystal clear....feels we, the 'hoi polloi' are treated a bit as second rated citizen's or spoiled kids.
But that's just my personal grudge.

About Max3d, afaik it ceased to exist somewhere this time last year. Even if mark's grand new project never gets published and just acts as source
for improvements and utilitarian mods for BMax it's very fine with me.

agree with sswift...

I like the simplicity of Blitz3D... with a small set of command you can do almost everything (game/multimedia related).. I switched from my own C++/DirectX engine to Blitz3D, because its fast, simple and do exactly what I want to do in a few lines of code.

You want to do some complex and serious application ?

-> Try Visual C#, it is just better for these kind of application (you have reflexion, OOP, nice GUI classes,...)

What we need on BlitzMAX is max3D. Everything else is nice to have but not essential.

Well, I feel for sswift and some of the others.

I like the OOP stuff, really. It has made me far more productive and has reduced my ability to introduce bugs or complicated structures... Cool. Then, some time ago Mark changed his mind about where blitzmax is going because 'he didn't want to do the same thing all over again'. I can symphesize with that thought. I like change as well. But a game-maker kind of program is something I am not interested in at all, so I will (very probably) not buy that new product. I have decided that what I have right now does suit my needs, and I count myself very lucky that I did buy Max for what it already offered when it was released (oop, nice 2d engine) and not for what was promised (or at least referenced at) but which will never be delivered. In a way, Mark has treated a lot of this customers who wanted to grow along with him and Max badly...

'twas a bad business decision, but we are used to that from BRL.

Hello.

I dunno. It seems to me that initially the OOP concept was one of simplicity but the development of the paradigm has led to it's becomming overly complex and distant, and not what was intended in the first place. I appreciate that people are saying that reflection et al are beneficial and will save time when learned, but...well, to me it looks like people are afraid of doing the work with what they've got.

For example, as mentioned above, saving and loading of types. Apparently, reflection means that you don't have to hard code every field. Wow! Yes, it's tedious, but I've got other things to worry about more than that.

Whatever language you use has got to be appropriate for what you're trying to acheive. The original 'mission statement' for Blitz 3d was that it was, essentially, an easy path into the world of 3d programming that, with just a little bit of work, people would be able to produce 3d games. In many respects, I think Max was meant to extend that. Sadly, perhaps, the comparison can be made to OOP in that the initial concept has become over complicated and has made it less and less accessible to the casual programmer. Perhaps there are fewer of those using Blitz now.

Anyway, I think the argument stands that if you don't want to use the new features you don't have to is reasonable, but equally I can understand the frustration of sswift because what he considers the core developments to the language do not appear to be, um, being developed. Instead, aids to the esoteric are taking priority, and when you're not going to use those features...and to be fair, it must be especially frustrating to someone like sswift who has provided so much to the community and obviously want to continue doing so.

Oh well.

Goodbye.

I welcome anything that improves the language as such but: there are a lot of things that BlitzMax lack. It has no multithreading support (this is the worst - languagewise - because the CPUs go clearly in the "more cores per processor" direction), it uses an ancient version of mingw (updating mingw alone would mean a decent push in performance), MaxGUI has a lot of bugs although it *can* be a real joy to use and there is still no official 3D module (which I consider less important since there are a lot of alternatives out but a decent multiplattform 3D solution would be nice nevertheles).
What's also missing is a 2D software module. You either need OpenGL or DirectX (on Windows) hardware.

reflection isnt for everything... probably one of the best examples to understand reflection is saving and loading. before reflection you have something like this (please note this is not syntactically correct or properly show the reflection interface of max. its just an example to show how procedures can change with reflection capabilities.):

Type Game
	
	Method Save()
		' loop all objects and save
		while (more objects to save)
			write to file (obj.save())
		wend
	EndMethod
	
	Method Load()
		' open up file and loop it
		While (more to load)
			' get the type
			type to init = from file
			Select
				case type = ship
					obj = new ship
				case type = rock
					obj = new rock
			EndSelect			
			obj.load(settings)
		Wend
	EndMethod
EndType

Type GameObj
	Field type
	
	' load and save methods need the child classes to do the work
	Method Load(settings)
	EndMethod
	
	Method Save()
		Return type
	EndMethod
EndType

Type Ship Extends GameObj
	Field x
	Field y

	Method New()
		type = "ship"
	EndMethod
	
	Method Load(settings)
		Super.Load(settings)
		x = x_setting
		y = y_setting
	EndMethod
	
	Method Save()
		Return Super.Save() + " | " + x + " | " + y
	EndMethod
EndType

Type Rock Extends GameObj
	Field size
	Field mass

	Method New()
		type = "rock"
	EndMethod
	
	Method Load(settings)
		Super.Load(settings)
		size = size_setting
		mass = mass_setting
	EndMethod	

	Method Save()
		Return Super.Save() + " | " + size + " | " + mass
	EndMethod
EndType

for this, each type has to implement its own save and load routines. the game load routine has to determine the type and have one big select statement to do its loading. with reflection, the above becomes something like:

Type Game
	
	Method Save()
		' loop all objects and save
		while (more objects to save)
			write to file (obj.save())
		wend
	EndMethod
	
	Method Load()
		' open up file and loop it
		While (more to load)
			' get the type
			type to init = from file
			' using reflection create an instance of the type.  
			' no more big select statement.
			obj = TTypeId.create(type to init)			
			obj.load(settings)
		Wend
	EndMethod
EndType

Type GameObj
	
	' load and save methods now handle all the work generically
	Method Load(settings)
		while (each field of this type)
			field value = setting
		wend
	EndMethod
	
	Method Save()
		settings = type (as given by reflection)
		' using reflection loop through all properties of the type
		while (more props to go)
			settings += property
		wend
		
		Return settings
	EndMethod
EndType

Type Ship Extends GameObj
	Field x
	Field y
EndType

Type Rock Extends GameObj
	Field size
	Field mass
EndType

loading and saving are now completely generic. doesnt matter how many objects extend from GameObj. i know this is a really simple example, but hopefully it shows a little better some of the capabilities with reflection.

I've changed my mind. Instead of a Max3D I wish Mark would give just a little attention to minib3d. People don't realise the good work Simon has done and minib3d is a very capable x-platform solution.

If you don't care about x-platform then go buy some of the currently, working, stable and ready for prime time 3D engines like 3impact, TV3D etc. You won't be dissapointed with either purchase.

I'm going to go with the folks that want the BlitzMax core language to improve. FOr me that means more OOP features and improvements to the language.

MaxGUI could do with some attention also.

That's a cool example. Mark should hire you. He problably won't.

Ok...but what does it all mean?!?!

A fair question. I much prefer Max's module approach to having a bunch of class libraries in .Net. I much prefer Blide to Visual Studio. I find it irritating to have to work in radians or rewrite math functions to avoid them. C++ is far too unwieldy, Java is not compatible with any of the libraries I'm using and although I came close to using C#, it still has that nasty Net 2.0 requirement which I wasn't prepared to put on my code. I can get better support quicker for BlitzMax on these forums than I can for any of the other languages on random, disparate fora. Hopefully that answers your question.


Actually you did say everyone. It's right here :


But I think this thread is roughly split down the middle between those who basically want what you want and those who don't, so most people was probably an overestimation too. Some do, some don't, and we both know Mark will work on what he wants to work on regardless of what most people want anyway. That's the joy of being an indie developer is that you get to work on the things you want and if people don't like it, they don't have to buy it.

gman:



Now wait a minute...

If you save the way you save in your first example, you can pick and choose which fields to save and restore.

But with the method you outline where saving and restoring has been made generic, you are forced to save the entire type, which could result in a ton of crap being saved that you don't want or need to be saved.

Plus you can already save an entire type in Max with a totally generic function by getting a pointer to the type and writing everything in it to a stream... though Max doesn't tell you the size of a type so you have to calculate it yourself, so I guess it couldn't be totally generic, but that is because Max fails to provide that function. Or so I hear.

@swift i think you can flag which fields/attributes can be saved/read in the save/load functions but i too am not much up on reflection.
You helper guys keep dishing the knowledge out :-)

I'm happy then. Cheers.

I didn't bother to read anything everything so I'm only reacting to the firs posts:
Guys, you DO want reflection, you just don't know it yet. Pretty much every serious game project you're going to write will need some dedicated editor to place entities and the like. The thing is, whith reflection you could have a somewhat generic editor, that will let you spwan and edit any entity in a generic way, without having to expand the editor every time you implement a new entity type. I suggest that people still sceptical about this to take a look at UnrealScript and the Unreal Editor. Inside UnrealEd, you can create objects of just any class (even the ones you just added throught scripts) and place them in the world editor. There is only one simple thing needed to allow that, and that's reflection.
Expect someone to write soon a world editor ala Droplet based on that concept.

> There is only one simple thing needed to allow that, and that's reflection.

Or have all your types as children of a base type.

Dynaman, even then, a great deal of hard-coding would have to be done. The workaround people tend to apply, to avoid stupid looking code, is using scripts for everything, which is often clunky, unnecessary and slow.

All types are children of a base type

I'm looking over this thread now, and I'm surprised at how few people realize that they will greatly benefit from the inclusion of reflection, even relatively basic support as it is, into BlitzMax. The best example so far is Koriolis's. If it's possible to iterate over the existing types (not those that have instances created, just those with implementations), with the inclusion of reflection and metadata, you could have anything from a property grid to a very powerful editor with not much code necessary to really make it function outside of implementing class features.

In short, this is an incredibly important development and has more or less renewed my interest in BlitzMax as a development tool, even if I won't use it solely.

I remember when BMax was released as a beta, a lot of people complained about it having some OO possibilities. I'm sure a lot of this people now use OO code and love it. Let's see what happens to refletion... Personally, I thing it is a vast improvement, not only for the reflection itself, but also by the improved faster compiler nobody is mentioning here. :D

I'm noting the quote:-



What does that actually mean?

People are getting hot and bothered by this reflection thing... but will it be what you are expecting?

Dabz

> All types are children of a base type

A particular base type then, one that supports the functionality of the editor.

Unless I'm working on incorporating other peoples classes I really don't see any scenario where reflection helps me. I don't begrudge it from those who do have a use for it though.

Only one note.
Please Mr Mark be sure to give a 'real' help-guide for the new commands for reflections...I'm getting lost with the syntax...

Type TMyType {kind="Value"}...
...Method SetMatrix:TMyType( mat:TMatrix ) {attribute="Matrix"}...

Print TTypeId.ForName( "TMyType" ).FindMethod( "SetMatrix" ).MetaData( "attribute" ) 'prints "Matrix"

Why .ForName("TMyType") and not ForName("Value")?
What is {kind="Value"} in this case?


Ok, I like the array's thing, but what about the others tweaks?

Think of it this way, the program knows about itself and is able to inspect its own structure at runtime and to interact with the structure, in a manner of speaking. True reflection, or complete support for it, would allow the program to modify itself and incorporate new components or remove existing components at runtime (e.g., like in .NET-based languages).

Nope.

Wow. Is my thumb not on the pulse of the Blitz Community.

That is not even remotely an elegant design.

That depends on the complexity of the game you're trying to write. For Match3 games, not so much. For any game that is intended to be say moded by a third party - it's absolutely invaluable.

No it isn't. That's an entirely pointless example. A better example would be persistence frameworks (like Hibernate/NHibernate) or Unit Test frameworks (like JUnit/NUnit).

Sure. But there are more jobs in Java and C#. Hell even VB.

And that's what you're getting, whether you realize it or not. Sure you can always (like sswift did) find some convoluted way of using reflection to achieve a simple task. On the other hand you can find simple examples that allow you to do tasks that are impossible without it.

What? Both of them?

Well that's fairly simple problem. Stop having crap data in your objects.

There are 2 flaws to that approach, the most obvious being a lack of interfaces/multiple inheritance. The less obvious of course is that no - you can't really do what Noel is suggesting without reflection.

The key words you're missing is "a very powerful editor with not much code necessary to really make it function". You could possibly do it with inheritance (or at least multiple inheritance) if you wanted to write thousands of lines of boilerplate code. Or you could use reflection.

That would also require dynamic class loading.

Which could be done in BlitzMax, provided the implementation is robust enough to work with. Compile new code, load it, allocate the structures, and add their information to the existing (reflection) information.

> For any game that is intended to be say moded by a third party

That's a good reason.

> There are 2 flaws to that approach, the most obvious being a lack of interfaces/multiple inheritance.

If you mean inheriting from two base types I've personally never used it. I don't see how it would be NEEDED for a powerful editor, although it can't hurt. Using it with third party mods, or a different team working on the items to be placed then yes I'd have to agree it's a good idea.

I'm starting a project next year, when I start the project I will use the best tool available to me at the time - I wont be waiting for a middleware developer and end up hanging on a promise that isnt fulfilled, I dont do that, I use what is available and I deliver. I dont like failing to deliver.

When I start this project I will be looking at all the 3D engine options available to me. The irony here is I came to Blitz after getting frustrated with the bugs in DarkBASIC. Now I look at how Blitz has not moved forwards and how DBP has most of it's issues resolved and i'm thinking "Smegg, I have to go back to that god aweful syntax again".

Syntax aside, it's now a better engine that what Blitz can offer me, with B3D stuck in last decade and the engine options for BlitzMax either being expensive, slow, or lacking key features.

Believe it or not I do care about Blitz. I have had my moneys worth out of the products I have bought. I speak critically of the current development drive because I like so many old timers know what *could* be great.

I know many people on this forum have joined Mark on his whirlwind adventure and love BlitzMax and all it delivers. There are also others that remember Blitz3D and just want to see it modernised, we dont care much for the 'power' of BlitzMax because the bottom line is, no matter how powerful it is, the damned thing is much slower to develop in than Blitz3D.

Dont get me wrong, I love having strict compilation, but as far as I am concerned and my own programming interests this and compatibility with OSX (choice of 3D engine depending) is the ONLY thing BlitzMax has going for it when I compare it to Blitz3D.

So yes, call me stuck in the times or say i'm a fool to want those fancy new features in a crude old basic, but you know what - I remember when I did have a great 3D engine in a crude old BASIC, it's just out of date, and there is no replacement.

So forgive me for arguing a case for a decent 3D engine for BlitzMax. Call be deluded if you will, but thats why I came to Blitz and thats why I fear I will have to leave Blitz.

"If you're not most interested in BlitzMax's capability to be a cross platform 3D language, then why do you use it? Why not just use C++ or one of the many other object oriented languages out there which are much more mature, faster, have better support, better IDE's, and are bug free?"

Common sense consideration

Hi,

What I'm finding with reflection is that it really just provides a way to 'automate' lots of stuff - especially loading/saving/copying/editing of objects.

This makes the 'real' code that actually does interesting stuff *MUCH* lighter than it would be if you had to manually write copiers/editers/loaders/savers for each type - not impossible, but very time consuming (esp in the case of editors), error prone and just plain BORING. In many cases you wouldn't normally bother, but reflection just makes it so easy...

For example, here's a bit of my current 'TEntity' type:

Type TEntity

	Method Name$()
		Return _name
	End Method
	
	Method SetName:TEntity( name$ )
		_name=name
		Return Self
	End Method
	
	Method Position:TVec3() {attribute}
		Return _trans
	End Method
	
	Method Rotation:TVec3() {attribute}
		Return _rot
	End Method
	
	Method Scale:TVec3() {attribute}
		Return _scale
	End Method

	Method Updaters:TList() {attribute}
		Return _updaters
	End Method
	
	Method ClearUpdaters:TEntity() {attribute}
		_updaters.Clear
		_updatersById=New TUpdater[4]
		Return Self
	End Method
	
	Method AddUpdater:TEntity( updater:TUpdater ) {attribute="Updaters"}
		Local id=updater.Id()
		If id<>-1
			If _updatersById[id] Throw "ERROR"
			_updatersById[id]=updater
		EndIf
		_updaters.AddLast updater
		_matrix=Null
		Return Self
	End Method
	
	Method Renderers:TList() {attribute}
		Return _renderers
	End Method
	
	Method ClearRenderers:TEntity() {attribute}
		_renderers.Clear
		Return Self
	End Method
	
	Method AddRenderer:TEntity( renderer:TRenderer ) {attribute="Renderers"}
		_renderers.AddLast renderer
		Return Self
	End Method
	
	Method Children:TList() {attribute}
		Return _children
	End Method
	
	Method ClearChildren:TEntity() {attribute}
		For Local entity:TEntity=EachIn _children
			entity._parent=Null
		Next
		_children.Clear
		Return Self
	End Method
	
	Method AddChild:TEntity( entity:TEntity ) {attribute="Children"}
		If entity._parent Throw "Entity is in use"
		entity._parent=Self
		entity._matrix=Null
		_children.AddLast entity
		Return Self
	End Method
	
	Method SetPosition:TEntity( pos:TVec3 ) {attribute}
		_trans=pos
		_matrix=Null
		Return Self
	End Method

	Method SetRotation:TEntity( rot:TVec3 ) {attribute}
		_rot=rot
		_matrix=Null
		Return Self
	End Method

	Method SetScale:TEntity( scale:TVec3 ) {attribute}
		_scale=scale
		_matrix=Null
		Return Self
	End Method
...

And the cool thing is: any method marked with {attribute} becomes instantly, magically serializable, copyable and editable. But this doesn't in any way affect how you write/develop your objects - they are still fully usable 'programmatically'.

There are about 20 types in my project that use this feature, and I expect there will be many more when I'm done. To have had to write the edit/copy/load/save code for all those types would have a huge impact on how much time I get to spend on the meaty, important stuff.

Also note that I'm not talking about serializing etc just fields - which is useful but very 'static', kind of like XML data or something - but am using methods to actually 'do work' when an attribute is modified. This means objects can do things like invalidate internal caches, load media etc when they are loaded/edited etc.

In fact, the whole thing becomes spookily similar to automating a program 'run'..all those TField.Sets, TField.Gets and TMethod.Invokes do in fact equate to very simple Max code...


This is the idea behind 'metadata'. For example...

Type TOptionsOrSomething
   Field FontName$  {serializable}
   Field FontHeight 'derived from font - not serialized
End Type

{serializable} is entirely arbitrary, but your LoadObject() code could use it to detect which fields need to be serialized.

Actually, one of the neat things is that objects don't have to 'use up' inheritance to implement save - a global SaveObject() can just walk the fields of *any* type of object. It could also potentially use FindMethod( "Save" ) to check if an object has a custom save method, although I'd argue that if you had to resort to that there's something wrong somewhere else...

The TTypeId.ForName() function takes a string type name. There is also a TTypeId.ForObject() function that takes a plain Object and returns it's type.

The {kind="Value"} bit is just an example of attaching meta data to a type, which may or may not be useful - remember, the meaning of meta data is completely up to you. Field/Method meta data - like the {attribute} and {serializable} examples above - are likely to be much more common.

Okay, here's a more concrete example...

Type TObjectStream

	Method ReadObject:Object()
		'read type name
		Local name$=_stream.ReadLine()
		
		'find type
		Local id:TTypeId=TTypeId.ForName( name )
		
		'create new object!
		Local obj:Object=id.NewObject()
		
		'restore it's fields...
		For Local fld:TField=EachIn id.EnumFields()

			'ignore non-serializable fields
			If Not fld.MetaData( "serializable" ) Continue
			
			'get type of field
			Local fldType:TTypeId=fld.TypeId()
			
			'is field an object or int/float etc?
			If fldType.ExtendsType( ObjectTypeId )
				'field is an object - recurse
				fld.Set obj,ReadObject()
			Else
				'field must be int/float etc...a 'leaf'
				fld.Set obj,_stream.ReadLine()
			EndIf
		Next

		Return obj
	End Method
	
	Method WriteObject( obj:Object )
		'what type of object is it?
		Local id:TTypeId=TTypeId.ForObject( obj )
		
		'write it's type name, eg: "TMyType"
		_stream.WriteLine id.Name()
		
		'scan it's fields...
		For Local fld:TField=EachIn id.EnumFields()

			'ignore non-serializable fields
			If Not fld.MetaData( "serializable" ) Continue
			
			'get type of field
			Local fldType:TTypeId=fld.TypeId()
			
			'is field an object or int/float etc?
			If fldType.ExtendsType( ObjectTypeId )
				'field is an object - recurse
				WriteObject fld.Get( obj )
			Else
				'field must be int/float etc...a 'leaf'
				_stream.WriteLine fld.Get( obj ).ToString()
			EndIf
		Next
	End Method
	
	Field _stream:TStream 'underlying stream
	
End Type

This is a simple 'object streamer' for loading/saving objects. Give it an object, and it'll read/write it and recurse through any fields marked {serializable}.

I haven't actually tested this, and it wont handle Null objects or multiple references to the same object (which can be fixed with a TMap), but it'll hopefully give you some idea of how it all works in practice. You can also hopefully see how this could be adapted for a CopyObject() style operation.

Is this 'too advanced' for BASIC users? Maybe for some, but I'm sure others will find it very useful. And of course, not every project has the need to stream/edit etc a large number of types like this anyway - it probably wont be much use in the context of a sprite lib!

But I do think it's the most exciting thing I've come across in terms of reducing code complexity since structs - and since I like it, you guys get lumped with it!

I know I'm going to regret asking (you) this, but which issues exactly? Seriously, we're about to start up a new project, and even 3D Game Studio came out ahead of DBPro.

Being a little over dramatic are we? Blitz3D was only released half a decade ago - and has seen many improvements since then.

Again, out of sheer morbid curiosity, what's wrong with either TV3D, Irrlicht or Leadwerks? Hell even MiniB3D isn't a terrible solution, for those of you who just want "Blitz3D+".

Well you're entitled to your opinion even if you're wrong. BlitzMAX is not only more powerful and generally faster, but it is also much, much faster to develop for than Blitz3D, partially because it gives you a reasonable chance of encapsulating source code, so as to make reusing source code practical rather than theoretical.

Therein ends all possibility of a reasoned discussion so i'm not going to try, except for one point, DX 7 released on 22nd September 1999, 8 years ago, best part of a decade. My points, whether you agree with them are not, have a basis that I believe in. As for debating the relative merits of our points of view, clearly no point.

It's only slower for you and anyone who is incapable of moving beyond your bizarre fetish for procedural languages. If you have trouble understanding how it is simpler to base a new entity type off an old entity type, instead of writing a whole new one, you need to {ends with "l"} yourself and spare everyone your misery.

Hey, settle down y'all.

Admittedly, DB Pro wouldn't be my first choice for a gamedev language, but it is based on more 'recent' tech than B3D, and if that's what's important to Banshee, then fine, go for it dude!

Heh, I know it's not intentional, but that is hilarious given certain bits of information.

I will trust Mark and will devote my entire life to Blitz. I have bought many many licenses, bought licenses for MaxGUI when Skidracer asked if we could buy more to support it. I bought 3. I bought the Blitz3D SDK. I have many MaxGUI and BlitzMax accounts.

I wouldn't know a damn thing about OOP had I not started messing about with it in BlitzMax. That's not the only thing though. When I read about c# constructors, recursion, overloading I quickly realised that BlitzMax and it's OOP was the only thing my neanderthal brain could cope with.


I would ask though that helpfull members not be excluded from the forum. I would like to say that GFK does not deserve to be banned. Especially considering that what he was banned for was letting people know of a memory he had about a certain person which was ammusing. There was no swearing, no personal attacks and every effort to have this resolved in an adult manner has failed.

I know I'm sticking my neck out here and risking being banned myself but I feel I need to take the risk simply because it is unfair for GFK to be treated this way by Skidracer. I have emailed you Mark and have emailed Skidracer. All my emails went unanswered. Please consider letting GFK return.

I love Blitz3D. It is cute. We love each other.

I'll say no more on the matter - I don't need to - I am the most dominant Blitzer in history.

Thats the bottom line, my project would be significantly enhanced by shaders. I dont want to leave Blitz behind because I love working with Blitz3D. So i'm just frustrated, I dont mean to be negative I really dont, i'm just frustrated.

EDIT: If the GFK thing is anything to do with me then i'm not bothered, i'm totally comfortable with who I am.

Becky

I'd love a language somewhere between Blitz3D and BlitzMax. Blitz3D with a little OO, some shadows, and other 3D improvements. Blitz3D 2 would still be my language of choice for games.

BlitzMax as much as I like it (with or without a 3D engine) will never replace Blitz3D. Its just so much more fiddly, less transparent. Blitz3D feels like an interpreted language in some ways, which is great for trying out ideas - quick and dirty.

Reflection is a useful and powerful feature, but I don't think it really matters that much to the majority of users. Maybe I'm wrong.

I'm sorry you feel you don't have any reasonable arguments with which to counter my masterfully formulated points. I would point out that DirectX 7 was not generally released (to people who don't subscribe to MSDN) until much later, and that by the time Blitz3D was released, DirectX8 was already out. Does that mean that by your reckoning, Blitz3D was obsolete before it was released?

Sure. When (or should that be if) it works. Not to mention the one thing Banshee and I agree on - the horrible syntax that makes you wish you were using Lisp and/or Haskell. But hey, my point was there are at least 3 engines that are "more recent tech" than Blitz3D. MiniB3D, TrueVision 3D and Irrlicht, the latter two of which are orders of magnitude more robust, better tested and more widely supported than DBPro.

TrueVision 3D, Irrlicht and even MiniB3D all support shaders, and in a much greater degree than, say DBPro.

My dream language would have the power of Python/Ruby, and the flexibility of Gamebryo.

@Flameduck - that's a better standpoint, see without the preconception of my reply it's possible to have reasoned debate :)

Why not MiniB3D? No offence as it's a great engine and a worthy effort and a fantastic achievement, but after I used it in a small project to try it out, I concluded that it is a bit slow. I'm also not sure now if it had the vertex manipulation and entityPick commands, not 100% though.

TrueVision - i've seen it in other games and never seen anything half as good as B3D games so I never really looked at it. Irrlicht has not really registered on my radar, neither of these engines are widely supported in BlitzMax though and it's hard enough getting support just with the core product let alone with 3rd party add ons.

Regarding development time, i'm an 'advanced basic' user, meaning i'm good with basic. I'm slower to develop with BMax than I am with B3D. As I said, it's a personal perspective.

Noel spoke down about me being stuck in procedural ways, sure ok, but I came here to buy a procedural language and i've adapted and evolved and do use BlitzMax, my X-System (http://www.raceauthority.com) is writen in BlitzMax, the software that runs my broadcasts (http://www.simtouringcarcup.com) is done in BlitzMax. Just because I dont like it doesnt meen I cant, so you can knock that argument on the head Mr Cower :)

B3D has many merits, and the best online help (the command reference section) of any IDE I have ever used. BMax would do well to learn some tricks from it's little brother.

Really? Huh. The reason I chose not to go with MiniB3D was that I felt the development lacked direction, coordination and a constructive way to collaborate. Slow was definitely not it. In fact my little test program was throwing around 1.6 million polys (Blitz3D unfortunately doesn't do surfaces with that many verts/polys, so I don't have a reference) at roughly 20 fps, on my sorry excuse for a PC.

Well fair enough. Consider that these games where written in older versions of TV3D tho' and quite possibly in either VB or C++, both of which aren't really all that hot for programming games with (IMHO). As far as support in BlitzMAX goes, it's my understanding that the BlitzMAX wrapper basically just exposes the TV3D engines interface to the language, so you'll be able to get all the support you need off the TV3D boards instead. There are a few BlitzMAX users hanging out there, and the more momentum TV3D gets from the Blitz community, the more likely it is that someone will be able to help you in BlitzMAX.

As for Irrlicht I've only really tried the Python version and it was rather good, for what it was, and performed surprisingly well. I'm sure the BlitzMAX version is absolutely awesome.

See, this is the part I don't get. I'm not trying to be clever, mean or rude here, but BASIC is just a language, and not a very standardized one at that (thanks Microsoft, you useless cretinous morons).

But here's the deal, you're a self-confessed procedural programmer (and maybe we interpret that term differently), but BASIC is traditionally a sequential programming language with no data structures (although over time it evolved into a functional, procedural and ultimately object oriented language). So you should be fairly at home in languages like C, Pascal and ALGOL as well, since they are also procedural languages, albeit with different syntax. So it seems obvious to me that you've moved somewhat upwards (in terms of abstraction) in your adoption of programming paradigms. Which is good, because it means that the Object Oriented Paradigm will eventually click.

For me the OOP didn't really click until I read Bruce Eckels's "Thinking in Java", which is available for free from his website and is pretty much a must-read for programmers who struggle with getting out of their procedural ways.

I just thought I'd point out that the more polygons you draw on the screen, the more meaningless the frame rates you get are if you're measuring an engine's performance.

Drawing half a million polygons in a single "surface", for example, proves nothing but the speed of your video card, unless:

1. The engine has some implementation of occlusion, in which case you could say it is fast

2. The engine optimizes the polygon structure for maximum cache performance on the video card and minimum overdraw

I may be wrong, but I don't think MiniB3D implements either of these, so the only real way to test the speed is to create a huge amount of small objects with varying materials.


Anyway, I agree with you about OOP. Many programmers who claim they only do "procedural" are actually use very OOP-like techniques, it's just that for some reason they're afraid to call it "OOP" or to take advantage of the benefits an OOP language offers (for what reason I don't know).


Regarding the original topic, I'm glad the BlitzMax language is improving. Unfortunately I'm not going to get to enjoy those features because BlitzMax is essentially useless to me without a 3D module that makes it worthwhile.

To the people who say the extra features are adding unnecessary complexity: New features like reflection are simply tools that you may or may not choose to use.

yah yah...why bother y'all when you cant change things anyway? It was too many yelling like this one around so far, to be easy to understand that it doesn't make any difference..I love Blitz3D, im using it, Im playing with it and its cooool...because I cant see point to yelling around, or arguing about something I cant change anyway, I land myself in to JME world and its cool, easy, modern features ,multiplatform and soon going to be JOGL appart from present LWGL whats great..for me, my wish is fullfilled and I can finally use straightforward 3DSMAX with something modern, multiplatform and developed on PC..so, until MAX3D raise up (if), I have pretty neat toy to play with..I wish you all same :) and yes..long life Blitz3D, I luv ya :)

P.S.
Full support for Swifty and Banshee here.. :)

Java Monkey Engine?

..yeahh..

Do you mind if I ask you what you're doing and how you're doing it? I've looked at Java a few times and never been able to fathom the point, mostly because it never seems quite able to do anything useful or impressive -- for example, I ran the z-pass shadows demo from the jmonkeyengine site, got a nice "Java Loading" box and then... nothing. Which is why I ask, because unless you can compile to a native exe whatever you produce is probably going to fall over on a ton of machines, just like it does on mine.

I'm really curious what your development environment is like because Java has always given me the impression of being a messy nightmare to actually make anything worthwhile and demonstrable with. I really don't get it, and I've never seen a straightforward document that explained how you're supposed to package and deliver bleeding edge Java apps.

environment development is beautiful Eclipse ide or if you like NetBeans..both rocks, extremely stable and very very clean...all demos and examples from JME(physics, cloth physics, particle, particle editor, shaders, water vfx/Red will like it if he see nice foam over waves/), working just fine...you have to properly assign specific libraries within Eclipse and after that its working just great..what you do for final product is to compile your game in to JAR and then simply within Command prompt (or you can create your own startup file and just click on it, do JAVA -JAR My_Jar_File.JAR , and things will work nicely...point is..your JAR game will work on ANY platform with installed Java Virtual Machine, what means you can write programs even for Pocket PC...

JME does not care a lot about fallbacks and tweaking for older hardware. When i was testing it out it looked okay on >=PS2 hardware but below there either showed up glitches or they turned stuff off. Things like their shaders for water for instance could be easily tweak to look much better also below. Physics came with the usual ODE problems, cloth is not supported by the physics engine directly, ... and so on. Everything comes around in a little bit low quality. Anyway i liked their shadows but don't expect an engine to spread in reasonable numbers with this huge size.

Mark thanks for explaining.
An example is better than a generic line of program!

BlitzMax is a fantastic language! And (now that I start understanding reflections...) it is even better :)
No one is obliged to use OOP or reflection with BlitzMax, you can (try to) ignore them - many of the standard commands are 'wrappers' to oop commands (see for example CreateList or ListContains...)

@Mark: nice example of the objectstreamer, very clear, very useful. Could you copy&paste it somewhere (eg. your worklog) so it doesn't get buried under this avalanche of other posts?

I totaly agree Swift and Banshee...

@Taumel
well..Im not sure whats low quality you mentioning about or 'simple tweaking' around, but far as i can see from Unity web site, their water demos is not even close to water example provided with JME..regarding separation between cloth physics and ODE physics..why that bothering you so much if things is possible to initialize and use within code in few lines anyway? Same goes with shaders and shadows..3-4 linec of code and everything working as expected, and keeping in mind multiplatform nature and upcoming JOGL support, I really cant se whats 'low quality' over there..

Unity water ( http://unity3d.com/webplayers/GrassDemo/index.html or http://spielwiese.marune.de/_uni/spielkisten/index.html ) works here on my machines, JME water does not always, that's the difference for me. If you're experiencing problems with the water in unity then watch out for v2 as DirectX should enhance the situation a lot.

Regarding the cloth physics this is simply a matter of quality and speed. You can do cloth in every rigidbody pyhsics enigne if you want to but the speed you get out of this it very different compared to native support.

Shaders and shadows working everywere...it would be nice if it would be like this but the reality is a very different experience. These are the sentences you often can read on this forum from certain people who seem to have no more experience with these kind of things beside of reading the features of an engine and maybe starting it up for once. Sadly the reality is a different place and once you really are working on a project which is shader related and which should support a wide range of cards, featuring meaningful fallbacks and taking interactions into account you'll understand why.

When looking through such eyes at JME then i think this is a nice project and it could be interesting in the future but at the moment it lacks quality. No question it's good enough for doing this and that but that's not what i would call a professional engine.

And once again, I totaly agree Swift and Banshee.

To quote a friend of mine 10 years ago when we were both learning C++: "Nah, I'm not bothered - I can program in Pascal in any language."

..I saw both demos you post before (I have Unity Pro) and I assure you that both of them can be done with B3D with similar if not better quality...so, as i said, I dont know whats wrong with JME water wich is absolutely better than samples I just saw, and for sure looking much much more real..but hey..its up to everyone..for me JME is a way to go, since I have no headache regarding fusion with 3DSMAX, and simplicity of use is incredible...well...low quality..ok..

It's your decision...

Why not get the GSDK ? Its fast and compatiable with most compilers.

From what I have seen both Dark and Blitz SDK's suffer from a lack of support when used with other plugins, and a generally low standard of support and are static in their development.

The factors above make it an unclear choice. It would not be long until I was stuck in my learning and the Blitz forum would say DBP is the issue and DB forum would say BlitzMax is the issue and i'd never get anywhere. I'd rather use a single, supported, product although I have not ruled it out.

Blitzmax sounds great, but i guess this thread shows that Mark has a large number of users that want more blitzmax and love where its going. but he also has alot of users that want another blitz3d because of its quick and easy to use nature. For the moment I would use an updated blitz3d alot more. Its not the shaders that I want its animated mesh performance and working filters.

I have myself loved Blitz3d and I am still fond of it but I quitted with Blitz some monthes ago because I could not really grasp Mark's strategy .
Even less after this thread
What's the point of developing a new OOP language while your 3D engine is as sort of dino ?
By the way , the most important features for me are stability and ease of use, I have never been a fanatic of advanced features but well, there is a limit....

I am astonished to see that some people find C++, or C# particulary hard
It is a prejudice, nothing more
At basic level, a Blitzer can take a couple of monthes to learn C++

BlitMax would make sense, in my opinion,just in case it provide some features dedicated to game programming, if any
but even in this case it is a detail
The real progress is in the 3d engine

For a small company to develop a generic OOP programming is a lost battle

>>For a small company to develop a generic OOP programming is a lost battle <<
Very good point, and very clearly supporting Swifty's and Banshee doubts..mine too by the way :)

For me the biggest obstacle of C++ (and C# too I guess, tho I've never really seen it) is its rather cryptic/decorated syntax. If you're coming from a real procedural language, then starting to learn C++ means learning a new syntax and new features (classes, pointers etc.). What if you make a bug? Is it a syntax error or a functionality error? BMax is a far more safe way to learn OOP. Once you get the impression you only need to learn the C++ syntax and you kinda already get the idea of the new functionality already then.

C++ is cryptic at times, but when you get used to it it's easy to understand, and I love the way you require very little code to accomplish something.

eg)

// uppercase each character in a string

while(*str) {
    *str = toupper(*str);
    str++;
}

I agree, some people seem to think it's great, but I've not seen anything to wow me, and the screenshots with FPS counters are running about only 40 FPS.

It is just a prejudice in my opinion

First of all C++ has not been designed for game programming, so you can skip a lot of C++ topics.
The syntax is not so different than Blitz sintax
About the bugs such as the dreadful pointers and memory leakage well, there is a trick...play it simple

I am an amateur , I stay away from the most sophisticated C++ features
Obviusly I can not exploit C++ full power but even so C++ is much more powerful and flexible tha Blitz script language

So why BlitMax ? switch to Blitz3d instead

Just some words more
I am reading in these days the excellent book " AI by Examples"
It is written in C++ same as 99 % of game programming books
Should I turn the code from C++ into BlitMax ?
Come on ,I prefer a simple copy and past
No Mark made a mistake
I do hope it realizeS it and it comes back to his natural mission
To design the best game engine on the market same as he did in the past with Blitz3d

Well, I can make good use of the new reflection features. Bring 'em on!

And I think Mark has a healthy philosophy:


So, either you're along for the ride or you're not...

@Naughty Alien and taumel: Thanks for the info & opinion. I must admit that I took a look at the setup docs for JME and thought 'What? It's 2007!' and the fact that Java Web Start is clearly supposed to cope with the demo files when it really just falls over keeps Java off my scope. I don't trust it to work, nice idea as it is.

Those Unity demos are great, though. I can see those.

@All:
Everyone seems to be repeating their position on Max so I'll add mine too: What would've been ideal for me would have been B3D with shadows and bump-mapping, implemented with the simplest technology (ie slower but widely compatible). I did buy Max eventually but it took me a while to find a decent excuse whereas with a few-bells-and-whistles-3D it would have been a no-brainer. I don't find that OOP really simplifies code -- a complex operation doesn't magically become simple because it is expressed in OOP -- but it is effective at brushing complexity under the carpet, transferring it away from the higher design that rests upon it (and yes, unravelling it later can be problematic so extend at your peril). I like Max's OOP a lot and it's been a fun way to learn -- well worth the entry fee.

Fingers crossed for ION3D eh? [Runs away]

Regarding TV3D. The people who've said that TV3D is not capable have probably never even used it.

Go to the showcase forum on the TV3D site and you'll find projects created with TV3D ranging from the god awfull to the visually superb.

I have also seen screenshots of the kind of GFX capability TV3D has when used with shaders. There's some really awesome stuff being done with TV3D.

Not only that but you can use it with BlitzMax thanks to Gabriel's wrapper.

I have a question. Will blitzMax ever go full OOP? As I understand it techniques such as overloading functions and methods are not supported in BlitzMax. I don't know how to use this stuff but if reflection (the way it's explained in this thread) can make coding easier then will adding more OOP features also help?

I'd like to see an updated Blitz3D SDK for C++ and other languages. Perhaps this can evolve into something more powerful - rather than waiting years for the written from scratch version.

Well, Mark in his worklog is speaking about 'his creature' gxLib

There wont be any 'gxLib' stuff released in the near future, as <b>it's gone pure 3d</b> and has become an important part of my current project.

So - remembering the alpha demo - a 3d engine (somewhere on the Mark's hard drive...) exists and it seems currently in working.
IF the new additions to BlitzMax are good for the 3d engine too, that's better for all of us: we have (quite now) a new compiler with new OOP elements and we will have a 3d engine...

PS: Reading the Mark's worklogs is like try to searching for Leonardo Da Vinci's secret messages...

With BlitzMax I can knock together a working app very quickly, with little effort since it's syntax is simple and quite flexible (where I don't need to worry about correct indents or having curly brackets everywhere).

Of course, I could as easily write the same app in Java, which I am equally at home with, but I choose the former, because to me, BlitzMax feels lighter and more efficient. (Obviously just an opinion, and may not relate to fact, but hey, that's why we have choice, folks).

Sure, BlitzMax could do with a tweak here or there (Please Mark, add Interfaces - it must only be a few extra lines to the parser/compiler ;-), but generally it has all I need to build the code I want to.

If I need, I can plug in directly, C, C++, asm, link to any old library, and generally make it appear as if BlitzMax is a "proper" programming language :-p

I guess I'll just potter on with BlitzMax regardless... even utilising such rarely used language features like "Extends"...

Because Irrlicht and TV3D are superior in every way?

A lot more than what? And what are you willing to pay for it? Studies have shown that the cost of changes to a software project increase exponentially the more changes it gets. Since its release Blitz3D has had well over 100 changes made to it, not counting bugfixes, it is therefore fair to assume that Blitz3D has in the last 6 years or so, grown to the point of being unmaintainable - the "werewolf" software Fred Brooks talks about in his "No Silver Bullet" essay. So let's say that Blitz3D needs at least 200 more changes to bring it "up to speed". So how much would Blitz3D 2 (for lack of a better name) cost? A conservative estimate would be only a single order of magnitude, or roughly $1000USD. Of course at this price there is going to be significantly fewer customers than at Blitz3D's price, so the actual cost to the customer is going to probably be at least twice that, and suddenly it doesn't seem like such a great deal, does it.

You're asking the wrong question. The right question is, what's the point of having a bleeding edge engine, if the language you need to use it is based on a 50 year old paradigm? So you have all the power of the Unreal 3 engine, but only have the woefully inadequate instruction set of Blitz3D to use it?

Sure. It's not so much learning it that's the problem. It's mastering it, and it being an anti-compact language, that are the problems. C# alleviates many of these issues to some extent, but still has a way to go.

Which is ironic since the only language you need MORE lines of code to accomplish the same task is assembly.

No it isn't. If you're not using any advanced features (operator overloading, multiple inheritance etc.) BlitzMAX is much, much more powerful, readable and adaptable than C++.

Well sure. I prefer writing the code myself. It helps me better understand what I'm doing.

How much are you willing to pay for it?

No you don't. While it is more meaningful to discuss reflection from an object oriented perspective, you could just as easily have a procedural language (like Pascal) with reflection.

FlameDuck, I was referring to the concise nature of C++ code, and I'm not talking about built-in engine commands that Blitz3d and the like have.

I would pay a reasonable amount for updates - depends on how much work was involved for each update (I'm talking about regular updates). It wouldn't be easy by any means, but if sensible goals were drawn-up, paving the way for the removal of weak areas it could be done. It's all about priorities, and getting a compromise between development time and improving an already good (and easy to use) engine.

Latter may be, the former isn't. And neither have the easy-of-use that the GSDK has.

It's interesting that Mark chose a bit of the 3D TEntity class to demonstrate his recent reflection work isn't it. Seems Max3D isn't as mothballed as may have been assumed.

Tentity, as in t'internet?

(in-joke for UKers only) :P

"So you have all the power of the Unreal 3 engine, but only have the woefully inadequate instruction set of Blitz3D to use it?"

You can have the power of the Unreal 3 engine and the power of C++
I dont think it is a big issue to expose a set of commands\ class to C++
Obviusly I would not stick to Blitz3d basic_like script


"If you're not using any advanced features (operator overloading, multiple inheritance etc.) BlitzMAX is much, much more powerful, readable and adaptable than C++."

I was talking of Blitz3d basic like ,programming language not of BlitzMax
Once again, rather than wasting plenty of time to develop a new OOP language it would have been better to update the 3d engine and expose the classes to C++
BlitzMax can come later
I dont mean it is bad, simply , I mean that it was not the top priority

The ironic thing about all of this is that 3D objects (note the key word OBJECT there) adhere very well to the principles of OO conceptually.

Since a lot of BMax's modules and libraries themselves are written in BMax, did it ever occur to anyone that the extension of the language into a fuller OO language is to allow a better toolset for Mark to acheive a greater momentum in developing his 3D module? A seasoned OO developer can develop and refactor existing OO code far faster than it's procedural counter-part.

The community just happens to benefit from the language extension.

What a lot of people do not understand is that OOP is more of a technique than anything else.

I've seen plenty of procedural code written in C++, Java, C# and even BlitzMax. Just because your code contains a "Class" keyword, it doesn't mean you've taken an object oriented approach.

So even if scary concepts like OO and reflection exist in a language, it doesn't stop you from continuing to write the code the way you want.

You and I must not be speaking of the same C++. One of the language design parameters was to not introduce any new symbols compared to C (which was done relatively successfully). Thus the nature of C++ is one of ambiguity. For any significantly large program, there is no way to absolutely know matter-of-factually, what a line of C++ code actually does.

Actually it's more an issue of managing complexity. Rather matter of factly there is no way to improve Blitz3D, to bring it on par with modern engines. Why? Because it's based on "oldschool" ideas about how to write 3D engines, and the paradigm has changed to using shaders and parallelism, as opposed to "brute force". Unfortunately it isn't as easy as writing a Goraud shader and recompiling for a later version of DirectX.

Ease-of-use is relative. Both have the degree of ease-of-use that I need.

And that's what they did. It's called the Blitz3D SDK in case you missed it. I think it's absurd that you're suggesting that people think Blitz3D was great for any other reason than the language.

Nice to know someone likes the fact that a pointer to the engine is needed before you can do anything. Unfortunately it doesn't pass the ease-of-use test for me.

"And that's what they did. It's called the Blitz3D SDK in case you missed it. I think it's absurd that you're suggesting that people think Blitz3D was great for any other reason than the language. "

Blitz3D SDK came some years later than BlitxMax and even later than DarkBasic SDK , for your information
Did I claim that Blitx3D is great for any other reason than the language ?
Really ? I missed it
Blitz3D is great for its game architecture the "entity" issue, which is basically an OOP, was definitly a smart idea
A game programming language makes sense if it supplies some features which are game programming oriented
Take for example the Torque programming language.
It comes with embedded classes but even in such a case we are talking about details
The added value of a game engine is the 3d module, not for sure the programming language
In any case If you just want a simple OOP than you can use LUA or Angel Script or Phyton
What's the reason for developping a brand new one OO language ?

BlitzMAX hasn't even been out for "some" years. Besides, I didn't think anyone was talking release dates.

Yes.

It is not an object oriented paradigm, but yes it is a degree of abstraction, which is always a good thing. Unfortunately since the language had no other aspect usually identified with the object oriented paradigm, using the entity abstraction meaningfully often required extensive housework.

I'll have you know that Pythons implementation of the object oriented paradigm, is several orders of magnitude more complete and powerful than in C++. And I am using Python BTW.

Because there wasn't really one that had all the features you could want? C++ is too horrible, Python is too slow, Java and C# have huge framework dependencies.

Like it or not, BlitzMAX fills a gap in the programming language landscape. It's unique in that it's garbage collected, it's cross platform, it outputs native code, it integrates with the GCC tool chain, it supports multiple paradigms, and ships with lots of convenient functionality for people who write media rich applications.

Amen brother!

if you refer to my

"So why BlitMax ? switch to Blitz3d instead "

I simply meant

"So why BlitMax ? switch to Blitz3d SDK instead "

"So even if scary concepts like OO and reflection exist in a language, it doesn't stop you from continuing to write the code the way you want."


That's not true. I wanted to learn DirectX and I couldn't because it was all C++ and object oriented, and there was no book which explained how to go about using it in any other manner. If BlitzMax is written in the same way requiring the use of OOP stuff to use the 3D interface then it might turn some folks off to the language.

Of course I like using stuff like ListName.Count(). I don't think that's too difficult for someone to grasp since it's not really different than just naming things a special way. But I think now they were doing something similar in C++ with DirectX with Name::Blah() and I didn't get that at the time, so I think you have to be careful with that stuff.

To those that would argue that you can use CountList() instead of List.Count() or whatever the command is, that's not entirely true, because there are a number of commands which are inacessable with functions. TMaps for example, last I checked weren't even documented, but I remember there being some other commands as well that were missing that were documented. I just can't recall which ones.

Anyway, it's entirely possible that people could be "forced" to use OOP if that's the way the interface is written. You could avoid it in your own part of the code, but the way you interact with the 3D stuff could well be OOP.

Alberto, dude, take a breath, you're all over the place. One minute C++ is a great language, anything less isn't worth it, then Blitz3D is a great language, nothing more is necessary, first it's the 3d engine that makes B3D good, then it's the language that makes it good.

Then you're advising LUA as an object oriented language? Lua has no support for object orientation at all. Nil. Zero. Zip. The nearest you can get is to hack it in with tables, and it's far more of a hack than anything you might have to do in BlitzMax.


You do not need a pointer to anything to use TV. In fact, if memory serves, there are no pointers whatsoever exposed by the wrapper.


Nothing to wow you in the whole three weeks since it was released to the public? Shame on them! Seriously, what would you want to see? If you saw a screenshot with awesome graphics you'd ( quite rightly ) say all it showed was good models, good textures, good animations. All DX9 3d engines are much of a muchness on what they visually look like, it's the under-the-hood flexibility and power which defines whether it's good for you or not.


That's the extent of your judgement? Bearing in mind that most video/screen capture utilites drop you to ~30FPS when they're going anyway, not to mention that it could have been running on a GF4MX. You've got to admit, it's hardly a thorough examination to look at a screenshot to judge performance, is it?

I mean, I'm getting 600-900 FPS on a moderate scene with animated characters, stencil shadows, full rigid body dynamics, a very complex HUD ( right down to tooltips for buttons! ) and multi-pass normal mapped environments which are also lightmapped ( custom shader XD )

I haven't done any real optimization yet, but then I haven't finished adding features, so it could go up or down before it's finished. I'm not too disappointed with 600 FPS though.


I very much hope so, but I fear not.


There are a number of language features which could make the language more powerful, and make a programmer's job more easy, yes.

For example, if you want to add two vectors now you're doing something like this :

Local V:cTV_3DVECTOR=Vector1.Add(Vector2)

With operator overloading, you could just have

Local V:cTV_3DVECTOR=Vector1+Vector2

The principle being that you can actually define what the + operator does with user defined types.

Interfaces and multiple inheritance would be very nice too. Multiple inheritance in particular can save a lot of work, but it can also get messy and bloaty if you don't use it sparingly and judiciously.

Properties would be very nice. They allow you to use methods as though they were fields. ( Well kind the opposite way around, but it's easier to explain this way. ) EG:

Type MyThing
   Field X:Int

   Method SetX(NewX:Int)
      If NewX<100
         If NewX>0
            X=New X
         End If
      End If
   End Method
End Type

Here you have a method called SetX in which you do some simply error checking to ensure that X is never >99 and never <1. However, if you just say Thing.x=101, you're jiggered, because there's no error checking on a field assignment. But there is with properties because when you type Thing.x=101 with a property, you actually call Thing.SetX(101) and your error checking is done. There's a matching Get with properties too. C# calls them "smart fields" which is a better description than I could have come up with.

Access modifiers would be handy too. In large programs, it can get messy very quickly and it gets very tempting to start calling methods all over the place. By adding access modifiers, you can make certain methods and fields private. That is, nothing outside the type can call them. This way you ensure that methods which you originally wrote for internal use by the type itself are not conveniently used when you're feeling a bit lazy. More often it would be used for libraries and modules, where you want to stop people fiddling with variables and methods they don't need and breaking stuff. Or even just to make usage more obvious by not letting them be confused by seeing methods they never need to use.

So yeah, there are quite a few language additions which could make life easier and more enjoyable.

Hell no... That's exactly why I was complaining in the first place here. I hate C. I hate C++. Too many symbols. Too hard to read the code, even if you have coded for a while in it. I don't want BlitzMax to become too much like C++. That's why I was rallying agaist the OOP stuff.

Java being so much like C++ is why I never learned that either. Well that and it being slow. And not capable of fast graphics. And not being used to make games in general.

Hell I even gave up on Visual Basic after coding one program in it because while the language was decent, it had poor grraphics and sound support, and even worse, the IDE they used was as complicated as the one they used for C++ and I couldn't figure the damn thing out.

Now I'm not an idiot, I could have learned it if I wanted to, but if I don't feel after an hour of toying with something that I'm making good progress at fully understanding it, I declare it to be crap and toss it out. That's why I use Vegas Video instead of Adobe Premiere or any other pro tools. And that's why I picked Blitz. Stuff that I don't make good progress with in an hour is stuff that I'm not gonne be an expert in even after a hundred hours of using it. (Like 3D studio Max) And I just don't have the desire to spend a thousand hours learning all the ins and outs of something. Cause by the time I figure it all out, they've come out with version 2 where they've changed the entire interface and I have to start relearning everyhting all over again. (Took months to go from Expert in Photoshop 5 to Semi-Expert in CS! Darn layer masks instead of groups, and new style groups which I still haven't figured out!)

Erm no offense Shawn, but using List.Count() as opposed to CountList(List) is pure syntax, and has nothing to do with whether you're using an OO language or not.

Like RocketGnome said, Blitz3D's entity system (which is generally heralded as the second coming, predominantly by ex-DB'ers I assume) is conceptually object oriented. So yes, I think it's fairly safe to say that since the way you interacted with "the 3D stuff" in Blitz3D was using object-level abstraction, the same is (at the very least) going to hold true for it's successor.

Because for me, the weakest link is the engine, not the language. The only item left on my absolutely-must-have-wishlist now that we have reflection, is being able to safely fork a thread on Linux. I stopped using C and C++ entirely (with the exception of one project at Uni) the day I got invited to the BlitzBasic for PC beta team. I don't even think I can locate my copy of CodeWarrior if I tried.

I wouldnt say no to overloading, nor Operater overloading.
Anyone know if this reflection thing is going to make these easier to add.

Also if BMax is an OOP language, and B3D isnt, the fact that you can just load a B3D program into Bmax, and find replace the ; for ' and : for . and . for \ and it will run (sometimes, Ok you need to add the Type List thing, and the B3DSDK or you wont have the commands, but the point stands).
Anyway doesnt this show that Bmax doesnt need to be programed in an OOP way?

Anyway point mute, we arent going to get Mark to change his mind. But anything that doesnt make the language slower is alright with me.

"Because for me, the weakest link is the engine, not the language"

Also for me
It is what I have been repeating and repeating
that's why I dont understand why ,Mark gave priority to the language rather than the engine

Heh. I had something similar trying out XNA having closed the solution explorer... 'Well it runs but where's the code?'

What the smeg is a 'solution' anyway?

Who says he did? Nobody knows what state "the engine" is in. In either case the world has plenty of perfectly fine 3D engines, but very few decent media oriented, readable and productive languages.

A collection of "projects".

Lord forgive me for asking but what is the point of that? I really quite like Visual Studio Express but the way it blathers on about solutions when I'm only really bothered about projects is very undermining.

So that you can use projects in more than one Solution.

Putting multiple projects in a single "solution" basically means you can work on more than one project at once in the same editor. No need to open two instances of Visual Studio, or to tediously close and open projects in order to switch between them.

For example, your "solution" might consist of a DLL engine and the actual game code. Putting both projects in the same solution makes it easy to work on both of these interrelated projects easily.

Say BlitzMax is your language of choice, which 3D engine would you then lean towards? Which physics engine would you use?

In Blitz3D it's quite simple, you already have a 3D engine, and you have add-ons such as post process effects, shadow engines, particle engines, sprite engines, GUI systems, PhysX ... Everything taylor made to work with Blitz3D and most possibly with each other.

If one has the skills and patience, he will make a remarkable game, such as many games already made and game that are currently in development.

I think that's where people are missing out generally speaking about BlitzMax, they don't see easy solutions, and things that have proof of concept.

That does make sense (John J.), but I'd still love to be able to turn it off and run two instances. Old skool :D

there's no reason you can't.

... You're all insane.

!In either case the world has plenty of perfectly fine 3D engines, but very few decent media oriented, readable and productive languages."

The direct opposite

lol, you know full well Truevision has been going for years (for people that are unfamiliar with it). :-)

I have seen some good stuff - which appeared to run very slowly based on the FPS shown.

Yep I know - bit of a snap judgement. But if I'm going to invest time in learning it then I want to know it'll be worth it in the end. Huge frame drop on exit? Didn't know that. I always press the print screen button (and paste into Photoshop) and have always got a true FPS figure.

Oh yes ofcourse I'll admit to that. Just don't want to invest time and be dissapointed.

I guess I'll have to take your word for it Gabe. Are you far off from releasing a demo of your work? Even if it's a little rough around the edges right now. I'm thinking the Blitz3d SDK might be easier to start with.

in bmax mod 3d cross platform is: gman mod for irrlicht
minib3d

dreamotion win dx
tv3d win dx

Who said anything about the wrapper ?

The engine is a DX10 Wrap (hahahah), but he probably means the TV3D wrapper for BMax, which as the only way to use it in BMax, the statement that it needed a pointer was directed at the wrapper and not TV3D itself.
Hence "In fact, if memory serves, there are no pointers whatsoever exposed by the wrapper", is totaly valid in the context of Tv3D use in BMax

Bought the Blitz3D SDK! For the games I intend to write Truevision3D seems like overkill. And I get to use C++ with it - cool!

Yes, but those of who've been using for that long aren't going to rush to release something just to impress you in the three weeks since it's been released. So that only leaves new users, who have only had three weeks with it.


That doesn't work in fullscreen on a lot of drivers. Most of the screenshots you see are taken with TV's internal screenshot function ( which writes directly to disk, fubar'ing the framerate ) or with a video/screenshot capture program with the same limitation. FWIW, I take screenshots the same way you do so mine have nice big juicy FPS figures on them, but I don't plan on showing any screenshots for a long time either ( see below. )


Yes, very far. I could scarcely hazard a guess, but probably 2 years plus.


It's been a huge investment of time and money already, and it's got a long way to go yet in terms of both, so a rough around the edges demo which would have even the slightest risk of affecting it's financial return is just not something I could do. I don't even plan to release screenshots until I'm absolutely ready. It's just as irritating for me as anyone else ( if not more so ) but I have to resist the temptation or I could end up spending three years working on a game which doesn't make back it's investment, let alone pay for three years of work.


As H&K said, you can't use it without the wrapper. But FWIW, the underlying library doesn't use pointers either. So either way, same answer. No pointers.

1. Java is much cleaner than C++, and unlike C++ it is a pure OO language. However, I can understand why you did not want to learn it. I am also not really a fan of curly braces, but I have to admit Java made giant leaps in the last couple of years, since the releases of Java 5 and 6. Oh, and you don't even have to program in Java to target the Java platform.

2. Just download the latest JRE and run some of the demos from the JMonkeyEngine website. After that, we discuss the "being slow" part again.

3. See point two. After that, we also discuss the fast graphics part again. However, I doubt that there will be anything left to discuss, because you will have to admit that Java --IS-- very well capable of doing fast graphics.

4. If anything else fails, download Tribal Trouble and have a look at lwjgl.

5. See 4. And also have a good look at the growing market for games for mobile devices. Handheld/mobile devices are the market where you want to be, and there Java is the #1 platform choice.

6. With Java, you can have sufficient performance, a mature and robust language AND all flavours of game, physics and graphics engines - and most of the time even for free. And it IS everywhere.

7. BlitzMax is a beautiful product and tool, and Blitz Research are doing the absolutely right thing by focusing on the language, because that makes the product more flexible and robust.

@Gab

Another two years!!!!!!
I knew you were doing a long haul project from you garentee that you were going to keep the TV3d wrapper up to date because it was essential for your project. But that was a year ago!

Well, good luck, from now on I going to pretend that Im in the middle of a long project, (Rather than not writing anything at all; which is closer to the truth)

Practice:
BlueFK: Well... what have you written... nothing... your opinion is rubbish...
H&K: Oh, just because I dont knock together little quiz games everyweek, or moan about how the engine doesnt do Sky properly, doesnt mean that Im not working on something Secret thats been a huge investment of time and money already, and it's got a long way to go yet in terms of both, so even a rough around the edges demo which would have even the slightest risk of affecting it's financial return is just not something I could do. I don't even plan to release screenshots until I'm absolutely ready. It's just as irritating for me as anyone else ( if not more so ) but I have to resist the temptation or I could end up spending three years working on a game which doesn't make back it's investment, let alone pay for three years of work ;)

Yep, and unfortunately, I was only able to work part time on the game during that time, because of commitments to GlimmerGames, ShadersForGames, the submission service and a couple of contract jobs. I hope to ramp that up to almost fulltime hours from now on, but there's still a huge amount of work to do.

Irrlicht doesn't use pointers ? So what do we have here then ?

IrrlichtDevice *device =
createDevice(EDT_SOFTWARE, dimension2d<s32>(512, 384), 16,
false, false, false, 0);

device->setWindowCaption(L"Hello World! - Irrlicht Engine Demo");

IVideoDriver* driver = device->getVideoDriver();
ISceneManager* smgr = device->getSceneManager();
IGUIEnvironment* guienv = device->getGUIEnvironment();

TV3D doesn't have pointers. Neither does GMan's wrapper, which is the only way to use it in BlitzMax.


I don't know. You pretending you thought we were talking about Irrlicht when TV3D has been mentioned ( at least ) three times by ( at least ) two different people?

And heres the TV3D C stuff :

pEngine = new CTVEngine(); 
 
  // Set the debug file/options. 
  // Do this before the 3D init so it can log any errors found during init. 
  pEngine->SetDebugMode( true, true ); 
  pEngine->SetDebugFile( "C:\\debugfile.txt" ); 
 
  // Set your beta-key/license: 
 
  pEngine->SetBetaKey( "UserName", "BETA-CODE-GOES-IN-HERE" ); 
 
  pEngine->Init3DWindowed( frmHWND, true ); 
 
  pEngine->GetViewport()->SetAutoResize( true ); 
 
  // Lets display the FPS: 
  pEngine->DisplayFPS( true ); 

  pEngine->SetAngleSystem( cTV_ANGLE_DEGREE ); 
 
  pScene = new CTVScene(); 
 
  pInput = new CTVInputEngine();  
  pInput->Initialize( true, true ); 
  

So TV3D doesn't use pointers either ?

All of which makes both Irrlicht and TV3D overly complex.

You know that's not BlitzMax, right?

EDIT: If what you're trying to say is that Irrlicht and TV3D are object oriented, then yes, they are. Otherwise, I'm not sure what you're trying to say.

As I said before, we're not talking about what its like in BlitzMax.

I could've sworn this was a thread about Mark's Worklog... weird...

Well, that is the topic. Should I apologize for being on topic or has Mark started writing worklogs about other languages now too?

Time to lock this thread and continue in a part II ..?

The last generation game engines use standard proramming language
The focus on the 3d module

C4 C++
Beyond Virtual Angel Script
LawMaker LUA
Unity JavaScript
DX Studio Java Script

Hmm, bmax seems to have caused a paradigm shift at BRL towers.

I'm struggling to see why minority and esoteric features like 'reflection' are taking priority over the majority who just want to be able to write games, as easily as possible, a la Blitz3D. I always thought most blitz users were hobby/amateur coders, not super experienced coders living on the cutting edge of OOP?!

Reflection certainly is NOT a "minority and esoteric" feature, it's a standard feature of modern programming languages, like serialization and support for multi-threading.

And if I remember the "Wishlist" thread right, Multi-threading support was the #1 wish among the BlitzMax users, not an "esoteric" 3D engine. Like it's been rightfully said before, there are already plenty of 3D engines available that run with BlitzMax.

The question rather is why those users who only want Blitz3D not just keep using it instead of bashing BlitzMax for not having a 3D engine built-in?

But you have mentioned one very important point, and that concerns the positioning of the BlitzMax language: Should it really be positioned as a game development language (only)? It is quite obvious that a lot of folks here are using it as a multi-purpose language for almost anything else, but -not- for game development. The more advanced language features are added to it, the more it will leave that "safe ground" of game development and people will ask for even more features that have not primarily something to do with writing games.

In my view, BlitzMax is not competing with or trying to succeed its older siblings Blitz3D and BlitzPlus. It is rather in the same arena with REALBasic and Visual Basic.NET. It does not have an IDE that gets anywhere near those tools, but it certainly has a language that is more than capable of competing with them.

If Blitz Research would re-position the product and invest in some marketing, the guys at REALBasic would be in some serious trouble.

I'm sorry, but it is. The fact that ~90% (at least) of people here don't even know what it is, should tell you that.

I could comment on some other things you said, but I can't be arsed, frankly. :P

At the end of the day, BRL (i.e. Mark) can do what the hell they like. I'll take my choice as to whether to continue using BRL products, or not.

Mainly because its Windows only. I would like an easy-to-use (hence my previous posts about TV3D & Irrlicht) 3D system that works with Mac, Linux and Windows (FX-200 would be even better), which, at the moment, there isn't anything that simple to use.

The more I read peoples points of view... The more I understand that no-one has a real clue where BlitzMax is going...

People are wetting their pants at the fact that it will have reflective programming capabilities. But have you ever paused to think that once you have all sussed it all you'll be crying out for more?

The keyword is 'simple'... Thats what your getting, once your passed using the 'simple' capabilities that BlitzMax will offer in regards to that style of programming, what will you do then?

I've already read tons of requests in the forums about BRL adding more OOP support, and this hasnt been addressed yet either.

I'm interested to know what people will do when they hit the limits? I really am.

Dabz

I always thought that was BRL's motto. Like I say, things seem to have changed.

Ahh, but your previous posts about TV3D & Irrlicht were nothing to do with how easy they were to use in Bmax, (apparantly), they were about how easy they were to use in C++
IrrB3D is easier to use that B3D

I think that's mainly you.

If BRL want their business to grow, they have to expand into wider markets.

Unfortunately ignorance isn't a very good metric for determining the usefulness of a feature. Most people here don't know what polymorphism means either (even people who use it). Just because you don't know what a buzzword means, doesn't make it less valuable.

No. Why? Because if you have to rely on other languages for writing your tools, you might as well reuse that code in your game. It makes sense to be able to write both the game, and the tools you need to create content for the game, in the same language.

One example would be H&K using Common Lisp for his server, but BlitzMAX for his client. Wouldn't it be cool if he felt BlitzMAX was powerful enough for both tasks?

Use LUA? Python? Common Lisp? C#? Even C++ has been suggested. That's why BlitzMAX needs to grow as a language - because you hit the limits of the language way, way before you hit the limits of the 3D engine.

Dont forget it also involves the discussion about GSDK

quote]Ahh, but your previous posts about TV3D & Irrlicht were nothing to do with how easy they were to use in Bmax[/quote]
Dont forget that TV3D is Windows only, which would limit its use in BlitzMax.
The pre-compiled Mac version of Irrlich is three versions behind the Windows version, which, unless you try and get it compiled for the Mac, could cause problems.

Hence the need for an official/semi-official fully working 3D system for BM. Mini3D is good, but isn't complete.

This isn't an expansion, it's a complete change of market.

How can people use a feature when they don't even know what it is/does, and why they should use it? That doesn't sound very valuable to me. As for ignorance, I always thought BRL laguages were open to people with limited/no previous coding experience, as a an easy gateway into game dev. Like I say: bmax = paradigm shift.

Sounds like a winner to me. Coming from a php background i can instantly see use for it. Being able to reference methods and fields without knowing they exist? How could that NOT be usefull.

the ability to "walk" the fields in an object 1 by 1 is also brilliant. Just define a "type" for your field, and you can do actions based on that.

I can think of a million uses where i have wanted to do this in blitzmax, and Im glad its getting in there.

Keep up the good work. No doubt once the nay sayers have a chance to play around with it they will find some use for it. Its the whole fear of the unkown thing. Not forgetting it is not a forced practice, it just opens up the language even more.

Good Lord!

What has happened to my thread?

Ah well, at least the more recent posts are on topic. My theory is proven right!
Whether a new post will be on topic can be calculated with a parabolic function based on thread length. Any new posts at this point are likely to be from people who have only skimmed the off-topic chunks of the thread, whereas mid-way, people will have read through everything.

Edit:
Well, speak of the devil!
Erm, keep at it, skn3!

Maybe Mark's secret plan is jumping directly on the raytracing bandwagon and so getting rid of all the ugly stuff regarding shaders... http://www.pcper.com/article.php?aid=455 ;O)

@taumel: then multithreading support must be in blitzmax. I guess not ^^

In what respect? You mean in the sense that reflection is "read only" for want of a better term? ( IE: You can use it to view data from an object at runtime, but not to create new data for an object at runtime. ) I think in this instance then, simple could also translate to "all 99% of people will ever want". Considering how many people are sure they'll never even want "simple" reflection, I really can't imagine many are going to want to "inject" new fields and methods into classes at runtime. That's really pretty advanced stuff. I mean it's very useful when you do need it, I'm sure, but I'm struggling to think of an occasion where I would. I've already "wasted" a number of weeks writing save, load and clone methods, not to mention the object properties section of my level editor all of which would have benefitted from the kind of simple reflection which is now coming ( albeit too late for me. )

I don't know, maybe I'm wrong and people will want full reflection, but I'm not sure what you're advocating as an alternative? Are you suggesting we don't have any language improvements because they'll only make us want more? I mean I see what you're saying - perhaps more in other areas than in reflection. I see how it can be frustrating to be given a taste for something and if you like the taste, they say "sorry, I don't have any more." I'm just not sure that leaving the language struggling down at the level of Blitz3D is the solution. I can't imagine I'm the only person who would genuinely feel nauseous at the thought of going back to Blitz3D having worked in Blitzmax for a couple of years now.

I guess you're saying that there are better languages, so it would be better for BRL to ditch the language part of their work and concentrate on a 3d engine, but I tend to agree with FlameDuck that the language was a good part of what made Blitz3D so good, and that it never was the most ass-kickingest of 3d engines. If you look over on DevMaster, there are literally dozens of very capable new 3d engines, all of which are a good margin better than Blitz3D, but there are barely a handful of languages which are ( even arguably ) more powerful than BlitzMax. Java, C++, Delphi, C#, possibly VB, Lua, Python, and then I'm struggling.

I know some people think that BRL would make a lot more money focussing on 3d engines than on languages, but I also think a lot of those self same people would change their tune if BRL ever actually went down that road. It's similar to how graphics sell games and then when they've been sold, they don't get played much because under all the graphics, they're a bit crap. People always want pretty graphics, but the language is like the gameplay that keeps you coming back for more. Without it, people who drift off in other directions pretty quickly, I think.

Thats exactly what I tried to point out Gabs.

Before BlitzMax arrived, I bet a fair few programmers on here never had a clue behind the concepts of OOP, or really, how handy it could be...

Now I find that BlitzMax has an implementation of OOP, but is missing certain aspects of it that, to me, make it a hell of a lot easier to program in an object orientated style e.g.

Nested classes
Constructors or destructors
Multiple inheritance
Polymorphism and templates

I probably will never use reflections (And I'm guessing quite a few people wouldnt too), but since porting my game over to C# (Which does have full reflective support BTW) these 'little' things surrounding OOP make life a LOT more easier to program in an object oriented fashion using a lower level language than BlitzMax.

Which to me, is ironic! :)



I'm not suggesting we go back to the level of Blitz3D, I'm suggesting BRL finishing implementing one programming idealogy before adding a new one.... That's all I'm getting at.

A mixed bag of programming concepts to me is worse than having non at all.

Dabz

Err, new() and Delete()
I can do without multiple inheritance, (Only because of the grief ppl say it creates), but Overloading esp OPerator Overloading would be good.

(Oh and c# doesnt have multiple inheritance. Does it?)

Sorry, I meant parameterized constructors.

xy = new XY(param1, param2);

Delete is not a true destuctor in a OOP way...

When a object goes out of scope in C# its destructor is automatically called, which in turn, means we can add extra code in the destuctor to handle anything that needs to be done before its gone altogether.



Technically no, but:-

1) As well as C#, I also program in C++, and it is handy
2) You can jiggle it though; http://www.c-sharpcorner.com/UploadFile/cbreakspear/MultipleInheritance11082005004843AM/MultipleInheritance.aspx

Dabz

Trashing Blitz3D isn't going to help BlitzMax.

Who's thrashed Blitz3D?

If your remarking on mine and Gabriels conversion, we are talking about Blitz3D's programming level... as in, BlitzMax's programming structure is at a lower level than Blitz3D's.

I think Blitz3D is a great product, possibly Marks finest hour...

Dabz

..hehehehe...you guys are funny..I luv ya all.. :)

I know what you mean, that's why I bought the Blitz3D SDK for C++. I aim to use this approach from now on (C++ and an engine). Just got my first C++/Blitz3D program up and running in Visual C++.

I liked BlitzMax, but personally I felt it fell between 2 stools - neither BASIC or full OOP/C++. I like C++ so it wasn't for me.

Exactly my point! ;)

Dabz

Just had to add Lisp to that list (heh, pun not intended.) Lisp gets no love.


edit: After scrolling up I noticed Flameduck actually mentioned Common Lisp. That really put a smile on my face. Thanks Flame :D.

Can anyone tell me what the overhead is in terms of speed and memory to include reflection? I've used it before in Lisp - but as they say, "A Lisp programmer knows the value of everything, but the cost of nothing."

And if anyone wants full reflection, I might be bothered to finish my Behavior Module that effectively features full reflection. New methods can be added to an object- you just need a pointer to the method, so I suppose it would be possible to actually compile a lua script or BVM script and dynamically add new methods (along with adding new variables, which is already supported).

There is some overhead though, since these dynamic reflective objects are built on top of a hashtable.

Aieee! Operator overloading is the devil!

Completely inconsistent madness. Syntax should not be doing multiple jobs based on context, just as it's stupid to have AND and OR acting differently whether they are in If statements or in math operations. (Either make them different operators, or unify the two uses).

If you want to overload something, use a method. They are more consistent, anyway, since one can determine at a glance what type goes where, and when. With operators, it could easily be any class divided by any class, and figuring this out requires another type of classification which has no viable reason to exist.

Okay, object methods do different things based on context, but knowing the context is much easier; it's just the one object. If it's operator overloading, the context relies on the type of two objects.

Sure, "you don't have to use it", but this is one case where it would be in use quite frequently in a way exposed to the user, so people would be required to at least put up with the concept. Furthermore, it would be a waste of time, since the power is already there with methods; operator overloading adds nothing new except for another way to execute a method.
It makes code hard to read since one symbol can then theoretically mean anything. That is not how punctuation should work.



Oh no, I'm sounding like one of the OOP naysayers. This is bound to backfire...

AType + AnOtherType
as apposed to
AType.Add(AnOtherType)
Is operator Overloading, seems quite usful and not at all Inconsistent madness. (OK it is Inconsistent if I make AType + AnOtherType mean Multiplyby or some such, but thats stupid programing, not a problem with Operator Overloading in general)

(PS Im willing to accept I might be using the wrong name)

Lisp is awesome. Too few people these days appreciate what it's done for programming language design.The reason it's considered inconsistent is that at times operator overloading is made to do some unusual things. For example, using the std::cout object, you use the bit-shift operators (<< and >>) to read and write to the stream. This is absurd because, well, bit-shifting is not for reading and writing data.

The problem lies with our understanding of what existing operators do, and by making their actual purpose ambiguous we create a great deal of confusion. Given the line "a = b << c;" we no longer know for sure just what is happening there. In C, and as FlameDuck pointed out this is not how it would be in C++, we would know that a is being set to b left-shifted by c. In C++, we have to first understand what a, b, and c are individually, then determine which is overloading which operators if any and find out what = and << are meant to do. In short, it's very confusing at times to find out just what the heck is going on.

Operator overloading has its place in programming, we just need to weed out the idiots who would use it in bizarre ways that don't make sense (as you said, using + for multiplication). Problem is that nobody wants to do this because then it somehow, in their minds, invalidates the usefulness of operator overloading. It's a bit like saying that because stupid people drink the stuff under the sink, that means we shouldn't use those chemicals at all.

I agree with Noel and H&K. Frankly, if you're stupid enough to overload the + operator to do subtraction, you're stupid enough to create a subtraction method called Add() which is no less nonsensical to me.

Operator overloading. I miss it whenever a language forces me to check for string equality with

mystring.equals(yourstring);

instead of mystring = yourstring

One of my pet peeves with java... (granted a minor thing, till I've spent a day looking at the darn code trying to figure out a bug)

The point is there's a difference between testing the absolute equality of objects (testing if they're the same object using the "=" operator) and testing the relative equality of objects (testing if they represent the same state using the equals method). Sometimes you need one, sometimes you need the other.

If you allow operator overloading you lose the ability to do the former.

@DynaMan
Errr
Mystring == yourstring
(hahahahahahahahah) (I suppose that disproves my stance that its obvious what Overloaded Operators do)

== An even greater sin of programming language design.

So says ME, and the heck with the rest of ya.

You would really hate PHP then. It has ===.

Operator overload is handy when you make member operator functions... Yet I highly doubt someone would make a - operator multiply.

Unless they have built up a decent amount of code at work and the company laid them off, and they are a little peeved! :)

Well, thats one of the things I would do! hehehe

Dabz

[/quote]Operator overload is handy when you make member operator functions... Yet I highly doubt someone would make a - operator multiply.

Unless they have built up a decent amount of code at work and the company laid them off, and they are a little peeved! :)

Well, thats one of the things I would do! hehehe[/quote]First thing I'd do in that case is write a lot of macros, then I'd use malloc and free and so on and so forth to allocate arrays, and only access them using pointer arithmetic. Finally, I'd write the operator overloading so it made zero sense whatsoever.

But then I'd be sued.

@f4ktor
Well, this was primary meant as a joke. I don't expect him coming up with a raytracer at all but what i would expect is proper threading support for BlitzMax in the near future.

I think I lean toward the sswift side of the argument. I've read the descriptions but I still don't understand what reflection is.

Similarly, I've never really 'got' this whole oop thing. I've written stuff with methods and all that whotnot but it didn't make anything magically easier or more readable. I don't object (ho,ho) to BMAX having all this advanced gubbins and I'm prepared to accept that far cleverer people than me think it's useful, important stuff so it must be offically good.

But I'd rather have a Max3d engine. I design (and reluctantly code) games for a living and the biggest thing preventing my switch to Max was the lack of a 3D module. Now I can use the old B3D engine I've made the switch but obviously I'd rather have a spiffy new engine that's cross platform and has these shader things people go on about (I don't actually know what a shader is exactly).

I know there are other engines out there but I don't want to invest time in learning one of those only to switch back when the offical one is released. I trust Marks stuff and I want to stick with it if possible.

As for the language side of things I would definitely make use of threading.

I also don't know what reflection is but hopefully the examples will be forthcoming with the update. I think if Mark's work log was more frequently updated then this post would have been a lot shorter. Even if it was thoughts, notes or how many doughnuts he was eating in a day(thats the important stuff). Just a thought, NOT IN THE FACE!

I have to side with Sswift, and John Pickford as well. Im confused however if the 3D module is being created/completed anymore. I havent stumbled onto any official direct comments on its development in some time.

Wikipedia on Reflection:

http://en.wikipedia.org/wiki/Reflection_%28computer_science%29#See_also


Wikipedia on Introspection:

http://en.wikipedia.org/wiki/Type_introspection

> You would really hate PHP then. It has ===.

Your right!

Well here's the problem. Some constructs will have more "operations" than C++ has reserved operators (which is the whole reason for having operator overloads in the first place). For instance if you have a Vector class what does "*" return? Dotproduct or crossproduct?

CrossProdut


But I take your point

For something as ambiguous as cross and dot products, I would use method names rather than overloading an operator that will cause confusion. Sure, you might have to type a few more characters, but at least you'll know what's happening on first glance.

Reflection excites me. Not entirely sure if this simple form is enough for my needs.

Of course, I say needs more in the sense of project ideas, rather than the likeliness of me actually ever coding anything ever.

I definately fit more into the BlitzMax is an awesome language category of people, rather than the Blitz3D was an awesome engine category. And for those confused, Mark stated in this very thread that these improvements are directly benefitting the 3D module anyway, so shush it. Really...

They should just make a Lisp.net. That would be the pinnacle of language design, IMO. All the benefits of Lisp + all the benefits of JIT. /drool

Anyways, does anyone know what the overhead in performance and memory might be like to incorporate reflection in Blitzmax? I know that's a vague and impossible to answer particularly accurately question, but perhaps some could give a ballpark figure?

I would be very happy beeing able to use a finished Ruby or BlitzMax-Basic via .NET.

I'd rather have it on the Java platform --> more supported architectures than .NET.

Uhm may i ask what kind of architectures? Mono is available not only for Windows and there are much more interesting tools built on .NET.

It's not exactly 100% Lisp, but you may like this: http://www.lsharp.org/
It's really insignificant, that's about all I can say. We're talking about fairly constant information here that doesn't have a whole lot of data to store. Depends entirely on the size of your application, of course.

taumel, Mono is quite nice, but it only supports a very basic feature set on most platforms, since it is far from being a complete port of .NET. Most GUI ("system.windows.forms") applications will only run on Windows and certain x86 GNU/Linux versions. On OS X, it is, hm, let's call it an "honourable effort", but one that requires X11, which nobody wants to use on OS X.

When we're talking about Multimedia support, .NET and Mono, when not running on Windows, are far behind Java.

J2ME is also more wide-spread than .NET, and I think there are also more robots out there that support Java than .NET.

As for the tools: Visual Studio only runs on Windows. When you move to other platforms, there is nothing available that compares to Eclipse and Netbeans. And most other .NET tools are basically Java ports.

Heck, I actually really like C# and .NET/Mono, but they are only a competetion for Java on the Windows platform -- and that one I do not use anymore for my own stuff.

Update: Except for that one SuSE Linux port of S/390, there is no .NET support on mainframes.

Reflection?
Does this mean the bugs of the maxgui module reported half a year ago will be finally fixed?

Unity uses Mono on OSX and Windows which works pretty well for me beside of that i'm not so fond of C#, Javascript and Boo, therefore it would be nice having Ruby or BlitzMax as a language.

Mono isn't as up to date as the original .NET but do you need every feature for beeing able to come up with a reasonabel game or application? I don't think so.

lol, that's a good one... :-P

Hahahahahahaha!! Boy I hope you're wrong.

C++ was designed by programmers, and COBOL, well...used it at college (shudders). Horrible and tedious language. Much preferred Pascal and C.

C++ is an industry standard for a reason:

1) It's fast and efficient!! John Carmack prefers Java - but it was too slow to adopt! Let's all program in languages that are even slower than COBOL and waste the Intel budget on ever faster chips.

2) It's popular, so there is lots of code available to use and learn from. After that it comes down to personal choice.

It's not for everyone and I can understand the critisism - too cryptic and so on. Fine, but don't knock it because you don't use it - use something else more user friendly like the excellent Blitz languages and Cobra.

Personally I'd like BRL to update the SDK and have the best of both worlds - a fast and efficient language I like, with an easy to use 3d Engine.

No it wasn't. C++ is the bastard child of C and SIMULA, that came about because Mr. Stroustrup (a mathematician) wanted to use SIMULA, but found it was not fast enough for what he wanted to use it for.

Yes. It was first.

Efficiency is doing things right. C++ does several things wrong. Therefore it is not exactly efficient.

Or alternatively we could just pretend that Intel aren't going to make faster chips anyway, and that 9 out of the top 10 (scientific) challenges facing video game developers today don't boil down to "computers are too slow".

Popularity isn't always a good thing, nor is the lack of a "Single Point Of Truth".

What's all this "let's discredit Cobol" theme all of a sudden? Have you ever programmed in Cobol on IBM 3090 system in a professionnal IT sector (not school)? It's an incredibly productive and predictable language. It's not made to do everything, but what's it's designed to do, it does very well, and very efficiently. I can account that from experience.

Cobol and the IBM mainframe are the 2 things that go together. The day the Mainframe systems sease to compute your insurance bills and your bank accounts, as well as your train schedules, and your federal income tax, then you can shout against it.

*sigh* How predictable FlameDuck. Unlike you I don't really want to bore people here with the evolution of C or pick over every line of every thread which might include general statements that get the point across.

Use what ever language that suits you, it's a personal choice. I understand that - do you? You seem to have a problem with letting people make up their own minds and tell them in tedious detail why you are (always) right in minute detail. I love C++, but I've mentioned others I like (Pascal, C, Blitz Languages, Cobra).

Stop being an arse man and go code something! ;-)

taumel, Unity uses Mono as a scripting system ONLY. It is not written in Mono itself. They could as well have integrated Python, Perl, Java or whatever else. You would not actually want to write desktop applications for the Mac with Mono, certainly not with System.Windows.Forms, and also not with Cocoa#. Servers are doable, though, and work just fine.

Steve, tons of C++ projects have actually failed because of the complexity of the language (or because of the hordes of programmers that could not handle it). There was a reason why most of the world jumped on Java instead, which has its own bag of fleas.

In 1998-2001, I was on a team with a codebase of 4.5 million lines mixed C++ and Xbase++ code, and the (gigantic) C++ part looked basically like that: C with some encapsulation. There was a common perception among the dev team that except for encapsulation a lot of the "higher" concepts of C++ either did not work, were too complex or simply counter-productive, so they did not use them. The project itself actually was the development platform Xbase++; I was not one of the core C++ coders, but among many other things I documented the C API of Xbase++ and wrote sample applications in Xbase++ and gave technical support to external Xbase++ developers. Great product and fun, unfortunately the company went through a very rocky ride in 2000/2001 and I decided to leave and get myself a new job. Anyway, that's where most of the C++ part of my CV comes from, but since then I became pretty good at avoiding that language as much as possible. ;-)

_33, yep, COBOL is nice. I always liked IDENTIFICATION-DIVISION. AUTHOR-IS me. PERFORM Typing UNTIL Programm-is-ready. ;-) But I'm afraid that the IBM folks are also using more Java than COBOL on their mainframes these days. They just went nuts with that language.

Uhm but aren't we talking mainly about games here and not system stuff? I also wouldn't take BlitzMax if i was after the second. Yep Mono is used for the scripting beside of other non Mono parts, so what? I don't think that in practice it's so relevant which parts are done with what as what counts in the end is what you can get out from a certain solution and i don't know a single Java based satisfying solution for games or simulations for instance. By the way Boo is kind of Phyton...

I've been taking a closer look at C# (.net/mono), and so far, it looks like a beautiful language.
Kind of like a nice cross between C++ and Basic.
And Mono is shaping up to become a complete conversion of .net.. Let's hope they get it right, and cross-platform development will become a breeze.. :)

Yes, Boo is compiled Python, targeted at the .NET platform.

Java: JMonkeyEngine, lwjgl, Jake2 and aren't there even Ogre wrappers for Java? Somebody was able to create a game like Tribal Trouble in Java, for me that is as much of a good credibility reference as I need.

Yes, C# is a beautiful language. It's only problem for me is that Apple is not supporting it and the Novell implementation is not good enough on OS X. That pretty much ends the discussion for me, even though I would LOVE to use it. But I doubt that Miguel de Icaza's group will ever get there, for those reasons:

1. They don't really care for OS X. (In fact, Miguel has posted quite a lot of Apple bashing on the web.) They also do not really care for any platform other than SuSE Linux. (Why should they? That's the one that pays their salaries.) Ultimately, only a fistful of Mono developers really work on OS X, and for such a huge project, that's simply not enough. Which leads here:

2. They do not have Microsoft's or Sun's or IBM's man power to really support so many different platforms, even if they wanted to.

3. They do not even have enough man power to implement and deliver a feature complete .NET platform. They are playing catch-up with Microsoft. Sure, it is officialy not their goal to deliver a full .NET implementation, but it actually hurts them on the long run not to have a full platform in the offer.

4. They actually do not have ANY support from other companies at all. In the industry, Java still is the #1 multi-platform solution, and nobody is really interested in changing that. All of the industry's efforts are put behind Java, not .NET, not Mono, not Python, not Perl, not PHP, not Ruby.

The really fascinating thing about C# and .NET is that all the people who really, really bash Java for some strange reason seem to like the Microsoft .NET platform instead, which ultimately is nothing else but a different flavour of the same technology and philosophy that are behind Java with a lot of the same problems and issues.

The only real difference between the two is that Java is already running full steam on all possible platforms.

--------------------------------

I am not sure, though, whether the entire discussion really is about games only. For me, it is not, and probably some others here also talk about it from a different perspective than from 'games-only'. I'm interested in games and their development, but that is just a part of the whole picture, and that is the reason why I'm interested in multi purpose languages, and not just domain specific solutions.

The folks here that advocate C++ are mainly after the system stuff, because in the end writing high performance engines -is- systems stuff. On the other hand, I know some very professional C++ developers who never were interested in going into the game industry because they found it boring "to just shovel around memory quick enough", to quote one of them.

Anyway, you are absolutely right that in the end only the result counts. Whatever makes you happy while getting there, use it.

Time for some coffee. :)

PS: I am NOT trying to convince anybody about anything here. I am especially NOT trying to tell people not to use BlitzMax. Whenever I have my own doubts about BlitzMax, I launch oddball's PhysLite samples and immediately experience that warm feeling for BlitzMax again. ;-)

I don't enjoy C# this much. I don't see were it's a beatiful language. Will be used a lot in the future and it's way better than C++ but simply no beauty. But there are other beauties around. Anyway the examples you brought up illustrate that there is no 3D Java Quality Product out there yet. Maybe in a few years but not now. Unity's Mono implementation works quite well, good enough to beat those Java Engines...

Yeah, but Unity's engine is also not written in Mono, so you cannot compare it to any engine written in Java. You can bet that Unity's engine is written in either C or C++.

However, the Unity folks could also have used Java and Jython as scripting languages instead of Mono's C# and Boo, because Java is as embeddable as Mono is, and it has already been used in a couple of commercial games for exactly that purpose already. They probably chose Mono because it already was Open Source at that time, and Java wasn't.

As for the 3D Java Quality: Yes, you're right, but Mono and .NET are in the very same boat. The only difference is that there actually -are- products shipped that use Java, but we have yet to see a shipped game using .NET or Mono.

By the way, what's wrong with engines like OGRE? What I see on their project page looks pretty much high quality to me. And that beast has language bindings for pretty much anything out there, including Python, Java and .NET. So if we want another useless language comparison, we can compare Java vs C# while both are using THE SAME game engine. :)

Anyway, I think C#'s a beautiful language because it is pure OO - everything is an object, even the 'primitive datatypes' (something that Java only implements since 1.5). I like that, it's consistent. C# also feels somehow rounder than Java; more like 'this is what Java should have been'. For me, it's the one thing Microsoft did right - regarding that this is a language aimed at big development teams and 'enterprise solutions'.

Anyway. Yes, there are other beauties out there. BlitzMax being one of them, because it gives me all the freedom that I like, while still being multi-platform, fast and the apps written in it don't have any deployment issues or require a VM installed. I do have a wishlist of features that I'd like to see in future versions, though. And none of them have anyhing to do with writing games. ;-)

I think I close this thread for me now.

This is incorrect. Boo is a language that has a syntax and idea based upon Python, but it is not Python specifically as there are still differences in syntax between the two languages.

Yes, you're right, and it is also not yet a 1.0 language version either.

Well, if you allow Unity games as examples for Mono based games then there are already games sold (portal and indie sites) and more in production to come.

I dislike these ; languages generally and object orientation can be found in a lot of other languages as well. I like Ruby.

all sounds handy to me. the downside of all this
negative feedback, will be less updates for bmax - im guessing the language is being extended to help with
the construction of the new 3D engine + these additions
are being made freely available...quit yer moaning ;)
- to be honest i havent written anything other than some quick snippets in b3d for quite some time - havent
used bmax forever :(
chances are that i will come back when the 3d engine is done...but til then, i will probably jst keep tinkering..

[actually, i dont care - ignore this post!] ;)

Actually, I find you should use whichever language allows you to solve a given problem quickest. In the last 5 or so years, that's just never been C++.

Not at all. I'm not saying I'm right. I'm saying you're wrong.

I code about 12 hours a day. If there's anything I need to do, it's code LESS.

Actually C# is more like C++--. Based on Object Pascal, it's a much more mature language, and features (amongst other things) generational garbage collection and a monitor for thread synchronization.

And Puzzle Pirates. The most successful independent MMORPG.

While it's true that .Net is Microsoft Java, the philosophy behind the two are radically different. Java is closer to the Unix philosophy (do one thing, and do one thing well), where as .Net is based on the Microsoft philosophy (do lots of different and unrelated things mediocrely).

FlameDuck, what I meant with 'philosophy' was that both use what Paul Graham would call a design-by-committee-language that is running on a VM. ;-)

.NET 1.0/1.1 were a nice start and I liked what they delivered at that time and surprisingly did not find it mediocre. I did not pay enough attention to .NET 2 and the additional class collection .NET to make a judgment, but it looks as if they are growing way too quickly and there is a chance that the result fits well into your description of their philosophy.

Java is mature and battle-tested. The problem that I have with .NET is that even Microsoft are not eating their own dog food and except for some ASP.NET-based products, they do not seem to be using their own technology. Or have I overseen all the big desktop applications written by Microsoft for and --IN-- their own .NET platform? The two nicest applications for .NET still seem to be Paint.NET and SharpDevelop.

Anyway, it doesn't matter (for me). I'm sure great things can be done with .NET as can be done on any platform. But since I am not aiming at Microsoft platforms, it is an academic discussion for me without personal importance or impact. MS is not where I am in my night time, and that's how I wanted it to be. :)

> Java is closer to the Unix philosophy (do one thing, and do one thing well), where as .Net is based on the Microsoft philosophy (do lots of different and unrelated things mediocrely).


I'd flip the words "mediocre" and "well", other then that I'd agree.

Bottom line:
In the grand scheme of things, compared to the ultimate, ethereal Jesus Language, they are both terrible.

Ahh, but does the Jesus Language work on the Java virtual machine or the .Net vertual machine?

Never heard of VisualAramaic.net ?

Any eta on the update?

I hope it will be released soon :)
At least the new modserver seams to be online :)

http://www.blitzbasic.com/modserver126/

No, he's right. Use whatever language suits you.

In you're case, whichever language allows you to solve a problem the quickest suits you the best. Just because you can't see other points of view doesn't mean they don't exist; many developers take performance into consideration, because that's what suits their needs the best.


Sorry, but if you're not saying you're right, the fact that you say he's wrong might not be true because what you're saying possibly isn't right. Therefore your statement is the logical equivalent of "Either I'm right and you're wrong, or you're right and I'm wrong." (useless)


Efficiency is doing things well and fast. Java does many things slowly. Therefore it is not exactly efficient.

It depends what you call efficient. Some languages are more efficient to the programmer, while others are more efficient to the user. I prefer to provide the efficiency to the user, personally. And no, it doesn't take me 2x longer to code a game in C++.

But I think we've discussed the C++ vs. Higher-level language debate more than enough by now understand each other's point of view.

I checked if the modserver was up a few days ago and it wasn't then... Glad to see it's up now! Comparing the modserver versions of the MaxGUI modules with those in BlitzMax 1.24, there doesn't appear to be any updates. :-(

Sure. In my experience, it's more a matter of some sort of pseudo-religious consideration. There's no problem too large, it's just the hammer that's too small. That kind of thing.

Well I was going by the ISO/IEEE definition. I don't know which definition you're using. Doing things fast is much, much less important than doing things right. Getting the wrong result faster, is not helpful.

In your world, who is the user of a programming language, if not the programmer?

I meant the user of the application. For example I can be much more efficient in a word processor if it can process the keys as fast as I type (extreme example, of course).


I'm using the English definition: "performing or functioning in the best possible manner with the least waste of time and effort"


True, but that is totally off topic. If you're saying that other languages help reduce bugs more than C++, you may be correct.

But my point still stands: Some programmers find C++ most efficient for their needs (speed), while others find higher level languages most efficient for their needs (productivity).

I don't know why people always think you should either focus on speed or correctness - why can't you simply have a highly optimized efficient fast correct algorith all at once?

You can (I do it all the time), it's just that FlameDuck doesn't know it, or he refuses to accept it.

Of course, he'll argue that C++ by it's nature causes bugs, etc., etc., etc., but it doesn't change the fact that you CAN have speed/efficiency/correctness/etc. all at once.

Now I do agree that there are some cases where you can't, for example if you use a language like Python which is interpreted/VM'ed and can't be fast, "by any definition of the word" (as FlameDuck likes to put it ;) )

Sure. But what has that got to do with the underlying programming language?

Yes. Well you should probably use a less ambiguous definition next time. For instance the "least waste of time and effort" would imply using off-the-shelf 3rd party libraries, however the chance of you finding an off-the-shelf library that does exactly what you need it to do (and nothing else), are probably fairly slim. So the English definition is as regards to software engineering is a contradiction in terms. Which is probably why the IEEE doesn't use it.

Yes I realize that's your point. It's just not (IMO) the correct focus. You should focus on customer needs first, programmer needs second (if at all).

Because developing an algorithm is always a trade-off between between different factors, speed, efficiency, readability and maintainability being some of them. Which is why you need to use a pragmatic and heuristic approach to algorithm design, depending on what your customers needs or wants.

Sure you can. I've recently written an indexing service using Lucene (Java) and Python that indexes about 20 GB of documents in 47 seconds, which is roughly 2 hours less than it takes the Microsoft Indexing Service (written in C++) to do the same thing.

Then you're using a much better algorithm than Microsoft.


Certain programming languages allow you to create faster executables than others. Fact.


Exactly! For applications / simple games, your customers don't need the speed of C++, but you customers do need the productivity (fast updates) of Java/C#/Python. But for advanced games, your customers most certianly do need the speed of C++. This is essentially all I've been trying to say in all the C++/high-level-language debates I've had with you. :)

Certain programming languages allow you to write more efficient algorithms, more efficiently, than others. Python may be an interpreted language, but its power stems from the fact that it accepts this and makes use of every ounce of power that can be gained from not being pre-compiled. (Something which Satan -- err, PHP, cannot seem to grasp, judging by its completely bloated muck of a core library).

Python is a great language for fast algorithms because of what it can do really easily, in a tidy way, without being a confused mess. For example, it does lists and maps (generally with hash tables), out of the box, as a part of syntax. Those are key elements in a lot of algorithms, so having them knit so tightly with the rest of the language is very powerful!

I disagree with the notion that any decent language can be rated on how fast its executables are. Python is definitely slower at figuring out to add 1+1, but that is, ultimately, insignificant. It isn't a scripting language just because Guido woke up one morning and thought "I am going to make a bloated waste of time!"; it is a scripting language because that is the best way for Python to fulfill its very unique objectives.
(PHP, on the other hand...)

So, where's the update? I want reflection, dang it.

Insignificant, for application programming. Most certainly not insignificant for game engine programming, where fast math and memory operations is critical for good performance.


What algorithms does Python allow you to implement faster than C++? I'm curious.

I'm talking about faster faster, actually. I find there is a greater tendency to be lazy with a language like C++. (Some people, on the other hand, are great with it).

To be honest I ignored all your discussion..

I just want to see the update :P

Or, if you're like me, you're absolutely obsessed with performance and couldn't care less about what the hell it looks like provided there's sufficient commentary to explain the process. I do it for fun, though, since I like to see how far I can push things.

Well, more than one week of discussion about 'C++' faster than '****'...
When the new update comes out, there will be 'at least' three weeks of discussion (again) about 'xxxx' is faster than 'yyyyy'....

1. make it run
2. make it bugfree
3. make it fast (optimise)

So I care less about speed if 1. + 2. are not in effect.

Has that new thread Noel Cower just started been deleted?

Seems so. The '124 Update' thread in BMax/Programming is also gone.

Maybe a 'good' sign ;)

I think new compiler stuff is really cool, I'd just like to say one thing:

I never thought I'd see the day where curly braces are part of Blitz. If I start seeing semicolons in the next update im going to ...

I'm waiting for the reflection stuff as well.
To get delegates up and running. (to those with 0 idea what this means: Method pointers, not only function pointers -> correct subscriber / observer pattern usage and the possibility to create clean multi class systems right now not possible without a serious amount of fake around)

To me OOP was the reason to get BM at all, otherwise I would have stayed with the old Blitz.

Performance is too me as important that it is not much worse than C# which it actually isn't.
What I miss on that end is the cyclic ref garbage collection. Would to me be more important than the gxLib and other stuff, but thats only my personal opinion. Just to mention: its important to me even thought I normally cleanly break up all references before null-ifying an object.

Technically they already are -- the ; is the command seperator to put multiple commands on the same line.

I really like other forums which mercilessly delete any offtopic posting other than the thread beginning.

Increases the knowledge and worth contained in posts.