What 3d solutions are there?

BlitzMax Forums/BlitzMax Beginners Area/What 3d solutions are there?

AaronK(Posted 2006) [#1]
Hi guys. Been away a long while. I'm looking to do some BlitzMax development but need a 3d solution. It seems that every programmer and their dog has done some sort of 3d implementation, so I was wondering which ones are recommended by you guys?

I need something robust that could be used for a final release if there are any. Wrappers for other engines (Torque etc) I will look at also if you know of any.


BTW: I'm on a Mac, so needs to be compatibile (No DX only etc)

Cheers
Aaron


marksibly(Posted 2006) [#2]
MiniB3D Rulez!

It's a free, open source implementation of Blitz3D in OpenGL. Although it's a little incomplete, it's still quite usable.

Do a search in the programming forum for more info.


Dreamora(Posted 2006) [#3]
GMans Irrlicht wrapper is as well highly recommendable

Other options: no most likely not, as most devs here are windows users.


ImaginaryHuman(Posted 2006) [#4]
And there's always the `wait for max3d` option ;-D


Dreamora(Posted 2006) [#5]
I think after 2 years, at least this option isn't that much of an option anymore :-) With all the problems that recently popped up within the compiler and language itself I'm a little unsure if I'm willing to risk similar problems to Max2D with Max3D if they are combined with compiler problems. (as well, there are still things missing needed within BM itself for the 3D module like multithreading or at least mt safeness for using mt libs and callbacks. Simple reason: Networking without MT isn't going to work usefully and a game language which actively prevents usefull networking is just not acceptable anymore in 06)

But lets hope everything changes and we will soon be able to do real stuff with BM :)


ImaginaryHuman(Posted 2006) [#6]
I guess it depends what your needs are as to whether you think something is a missing feature or not. If something affects your project then presumable it's a problem, but otherwise not. If BlitzMax falls in a forest and there's no-one around to hear it, does it make a sound? ;-0


marksibly(Posted 2006) [#7]

Networking without MT isn't going to work usefully


Erm, why?

I've seen the source code to various networked games and read plenty of articles about the architecture of others and none of them used multithreading.

I could perhaps understand a MMO game requiring multithreading, but it's overkill for a vast number of game styles.

Networking *is* hard, but there are tools to help - from low level sockets to mid level enet to high level gnet. All of these are quite usable within - and have even been designed for - single threaded environments.

So please, if you're thinking about doing a networked game, don't be put off by this!


RepeatUntil(Posted 2006) [#8]
Then question for you Mark about networking, Enet and Gnet: BlitzMax is using Enet, which allows reliable UDP. Is it possible to use this feature in BlitzMax/Gnet ?? Is there an option to turn it on?? (if yes, then it's not documented)


DStastny(Posted 2006) [#9]
If you look at the source for GNET you will see this
		Local packet:Byte Ptr=enet_packet_create( buf,sz+2,ENET_PACKET_FLAG_RELIABLE )


So in answer to your question it already is.

Doug Stastny


RepeatUntil(Posted 2006) [#10]
But what if we don't want to send all the information as RELIABLE?? (position for example)


Dreamora(Posted 2006) [#11]
Mark: Sure, a network library does not need multithreading for itself. But a network library as part within a game framework nearly needs one or at least would heavily benefit if it could run on an own thread.
Especially in 07, where multi cores are the common CPU type that is sold and thus true parallel running programs are no problem at all. (even apples little cheapy systems come dual core).

Just to clarify: I don't say it is not possible without MT.
But BM does not seem to be targeted at casual game programmers market only (where MT is not needed most likely), so it should at least allow the link to external mt based libraries without breaking as BM currently does ...
This is not targeted at network only. The main usage and potential to me: AI - there is nothing more annoying than the need to make the enemy dumb just because it is not possible to calculate the path further or not analyzing the environment further because it would block the rendering or network or input as all this stuff runs in a single thread.


LarsG(Posted 2006) [#12]
if you have to "make the enemy dumb", because you're running out of cpu time, then I'm pretty sure you're either attacking the problem from the wrong angle, or you haven't optimized more time consuming parts of your code..

my 2 cents though.


Dreamora(Posted 2006) [#13]
Not really.
But an animate based AI (ie intelligent that reacts to its environment instead of using an automate or scripts) needs a large amount of data analysis and decision making.
In my case: RTS which is squad based. The squad leader (a higher rank unit) does decisions on his own if there is no input from the player. But to do so, he / she analyzes the informations you have as player as well, which affect his surrounding.
In the same time, all the squad members are animate units as well which analyze their environment. but to a far lower degree than the squad leader, as they are led by player / squad leader.

It is sadly not possible to do this analyze approach usefull as the user input sadly suffers heavily.
You are right, so far it is not fully optimized yet. But even with optimation, it won't make a difference that is high enough to make the whole thing even nearly playable in realtime on a non-monster system.
So far, it has only been possible to come around that doing virtual multithreading. But running 2 apps using UDP for "communication" isn't something I plan to use as "final idea".
Surely, a different way would be virtual multithreading.
But I'm sorry. Its 2006, even Windows is multithreading capable since Windows 98 and today, all new CPU are multi core. So why would I want fake something that is much more efficiently implemented into the system and hardware today, especially as the workload for me to fake it is far higher. (the other 2 supported OS know of multithreading for many more years you know. Can't remember right now, when Unix got it exactly, but long before MS implemented it in Windows)

And create it in another language with threading and statically import it sadly not possible as many tests done by others earliers showed (RakNet Wrapper as the "most current" one).

But ok, why discuss over it if even a very experience programmer does not see the reason for multithreading although the terrains in Blitz3D already showed WHY it would be usefull and the language would heavily benefit of it.

If this is the last word on threading, thats a sad thing, as it is the feature that will be most needed in future.

PS: I'm not looking for a high featured super end thing as in java or C#, as even tests in PureBasic with its mutex showed that that is already more than enough to get around the problems.


SculptureOfSoul(Posted 2006) [#14]
I have to agree with Dreamora here. BMax seems to be a true multi-purpose language (at least, I know I'm treating it as such) and there's just no reason that multi-threading shouldn't be incorporated. I'm not saying that Mark needs to drop everything he's doing to implement it. I know that won't happen, and I understand and respect that. Introducing MT probably won't earn him any extra money...well, yet that is.

After Max3D is out though, I think it'll become even more of a necessity. Max3D should draw some new customers to Blitz, and after it's completion Mark will hopefully continue to make BMax the great language it's on it's way to becoming. I mean, you toss MT into the mix, along with perhaps a more full-featured audio module, a bit more OO robustness, and there's little reason for any programmer working on a non-AAA title to choose C/C++ over BMax.


Gabriel(Posted 2006) [#15]
there's just no reason that multi-threading shouldn't be incorporated.

Mark has already given good reasons why it shouldn't. Whether you or I think those reasons are sufficiently important is neither here nor there, there are good reasons.


Dreamora(Posted 2006) [#16]
I have not seen any reasons so far beside "GC is not mt safe", sorry.
If so, I would be happy if you point me to reasons, why BM should be non-MT on its 3 OS that all support it system wise already.

With reasons I don't mean reasons why a single part should not be MT, but why the language itself should actively DISALLOW MT / Callbacks (as it is not just not supporting it), which is what it currently does and thus makes its C++ connection a little pointless as you won't find that many C++ sources that do not use either.