Now Mark, where are we exactly waiting for?
BlitzMax Forums/BlitzMax Programming/Now Mark, where are we exactly waiting for?
| ||
| Hi there! I am watching the progress of the Blitzmax 3D module with great anticipation (I saw the last worklog of Mark and it looks very nice), but where are we exactly waiting for? Is there some kind of specificationlist available, what are Mark's targets? If I am going to wait for a very simply engine, I might as well look for something else...I just want to know *where* I'm waiting for, and I can imagine a company like Blitz Research has some kind of roadmap available? thanks. |
| ||
| Mark and the communication about this 3d engine ... great story :) But, this engine must be nice ?? :) else ... If Bmax3DEngine = False then Filax_BuyCoderWorkshopsCobra=True Else Filax_ReadyToMadeNiceDemo=True Endif Lol :) |
| ||
| so if the BMax3DEngine = True, you'll cry? |
| ||
| Cry of happiness :) Thanks for bug report :) |
| ||
| np :) |
| ||
| Jeroen, You have to understand mark is up to his shoulder's with doing 4 things at a time including BlitzMax, 3D Module, Gui Module and Network module these things dont take one day its a very hard job to do, he has posted estimated date's on his worklog just check them out and wait patiently. |
| ||
| To be fair to skidracer, mark isn't doing all 4. Not that a 3d engine is easy or should be rushed. |
| ||
| Lets put it this way: BP is "dead", B3D is "dead", so there's mainly bmx he's coding for. But release dates are always pain. So "its done when its done" my guess. btw Drago is working on a bmx 3d engine for my Plushy Pusher project. :) |
| ||
| You have to understand mark is up to his shoulder's with doing 4 things at a time including BlitzMax, 3D Module, Gui Module and Network module these things dont take one day its a very hard job to do, he has posted estimated date's on his worklog just check them out and wait patiently. Thanks Sarge (and Grisu), for the only normal answer in this thread. I understand that Mark is busy, but that does not have anything to do with my original question: to get an idea of what is coming up. Planning is esstential and normal for each serious project, so I assume Mark has this information ready. All I ask is some kind of information on the project, it's not that this will affect Mark's busy schedule. |
| ||
| As you might read in his worklog, he plans to create a next gen engine above B3Ds with support of shaders |
| ||
| Planning is esstential and normal for each serious project There is no detailed information on the 3D engine at this point. Mark of course has a general plan of action (Dreamora's post probably just about sums it up), but experimentation while trying to put theory into practise tends to change a lot of things. Changes of this nature have caused a lot of upset in the past, so don't expect specifics at this point. |
| ||
| Planning is esstential and normal for each serious project, so I assume Mark has this information ready. I guess you're not familiar with The Agile Manifesto? Large scale planning is no longer an integral part of developing software.The reasons are many, but the most important one is that unlike traditional manufactured goods or building, constructing software is not something you can plan ahead, because you're trying to hit a moving target. When you're building a house, you can be pretty sure that in the middle of production, you won't have to suddenly start adding a basement, or having to build it twice as wide, and half as tall. When building a car, you can be pretty sure it's not supposed to be able to fly aswell. When building software however, these certainties cannot be taken for granted. Hardware changes, software changes, changes in what the user/customer needs/wants, competeing products etc. all combine to make software infinitly more complex than all other traditional forms of production. Thus traditional engineering methods, such as those deployed in the past, are not effective at controling and managing quality software (as the huge ammount of absolutely terrible software available substantiates). |
| ||
| We're waiting for stuff. 'Nuff said. |
| ||
| I think the original post would be well answered, by Mark, with some cool sounding technical phrases relating to the 3D engine, "it has this, and that, and maybe that too!" I don't expect to know when, precisely, Mark will decide it is finished, or what, precisely, it will contain / support. But it would be entertaining, and reassuring, to have maybe weekly worklog updates so we can keep up our excitement and anticipation till it is, eventually, released. |
| ||
| Well said Flameduck? I will use that next time at work. |
| ||
| The reasons are many, but the most important one is that unlike traditional manufactured goods or building, constructing software is not something you can plan ahead, because you're trying to hit a moving target. Flameduck, thanks for the link. I disagree though. What you are presenting is a philosophy. While Mark may not choose to put every detail in his planning, large scale planning IS important (question is, what IS "large" scale planning ofcourse). If you have a company, primary target is to make money. Period. And for that you need a business plan and a project plan, which contains all the financial details. And, you can't give financial details with a proper idea of what your product is going to be, and write this down as such. And, I never said planning is something static, something that you keep and hold for the whole project. It's dynamic and flexible. I am a project coordinator by "nature". For a large game project I am working on (commercial game, not Blitz) planning is very, very important The whole game is broke down into clusters and seperate tasks for teams. I also wrote a special collaborate CMS (online) for game planning. Not that this all justifies my opinion, but I'm just saying that I know where I'm talking about. The least a project needs (if there's no project plan), is a roadmap with some details. And yes, those details can change! |
| ||
| > question is, what IS "large" scale planning ofcourse In the case of BMax it pretty much is "Make the most kick butt 3D engine I am capable of" Anything else is simply execution. |
| ||
| <nag> First of all, stop saying 'where' instead of 'what'! =] </nag> there is no place like 127.0.0.1. That's like saying, there is no place like localhost. It doesn't -actually- make sense. But it's cute ;] |
| ||
| First of all, stop saying 'where' instead of 'what'! =] ??? Explain. That's like saying, there is no place like localhost. It doesn't -actually- make sense. But it's cute ;] The meaning of localhost, is "home", "your place". When I see 127.0.0.1 I don't translate it litteraly, I see the meaning of it. |
| ||
| Hi, At the moment, everything is still really at the experimentation stage. I have tried not to 'nail down' any details just yet as I wanted to work out some of the mundane tech/math stuff before proceeding with a broader architecture. This is mainly because, although I know *what* I want the architecture to be capable of, I'm not totally sure about *how* to achieve it! The biggest architectural improvement I want to make is the addition of a decent culling/occlusion system. While many of hobbiest 3D engines/languages can do things like display quake levels, oct-trees, terrains etc, they all tend to work in isolation - ie: very few can cull entities within a quake level using the quake level's vis. So, the thing I'd like to achieve here is to be able to do things like 'insert this quake level into this quad-tree node of this terrain' etc. And then, be able to 'insert this statically bounded animation into this sector of the quake level' and so on. But to keep it generalized - eg: so the architecture doesn't need to know about quake levels, oct-trees etc - is a challenge! Note: by quake level I really just mean 'some kind of culling/occlusion system'. I spent many hours with a pen and paper trying to suss this out - but hadn't really achieved anything. However, out of the blue the other day, I had the germ of an idea of how such an architecture might look and will be following that up very soon. I pretty much agree with Flameduck's 'manifesto' - I think most programmers would - but my favourite article on software design would have to be: http://www.developerdotstar.com/mag/articles/reeves_design_main.html ...the main point being that the only true software design is a piece of code that actually does what it's supposed to do. Which does not negate the value of high level planning or abstract design, but more just recognizes that the process of creating a 'good design' carries on right through until the last line of code is written. |
   |