MiniB3d Monkeys-At-A-Typewriter Edition

I have created (or, rather, set up) a set of resources for a version of MiniB3d known currently as minib3d-unstable.

At our disposal is:
-A Google Code Page, which hosts source code and includes an issue tracker.
-A Google Group (Sorry, we must trust Google to not change that beta too much; I have become addicted to the its nice new features!).

The source code (the library, in this case) is available via SVN at Google Code.
To use SVN, I recommend either the command line (actually 100% easier than those overdone/buggy GUI tools this time!) or SmartSVN.
It is a bit fiddly to get going, so I'll write a quick how-to on it as soon as I figure it all out myself.

Stable releases and additional snapshots of the "unstable" stuff in SVN are to be posted on the discussion group.

Feel free to help by joining the project and making changes to it as you see fit. (Adjustments proposed, but will eventually get in there).
If you want, you can aid in creating examples or tutorials; both of which can be uploaded to the discussion group thanks to the very cool Google Groups Beta.
Just so you know, this project is open for (in fact, Asking For) name suggestions.

Edit:
I realize that I have already posted on this recently, but that last thread was more a pondering how to do it thing, while at this point it's all sort of sorted except for the moral dilemma of "oh no, I did this while Simon didn't have a chance to respond!". (So a more... er... obvious thread title is necessary).

Nice work. I'll be sure to join and contribute where I can.

Oh, and just to satisfy the pedant in me it's MiniB3D, not MiniB3d :)

Dont shoot me for this, (please), but I dont like the way klepto2 has done his md2 code at all.

Also by breaking the code up, the functions should have been kept with the type that are accessing, just to name one thing.

Dont get me wrong, its good work Klepto, but it simply doesnt match the rest of the code.
The Conts, (which I cannot see the point off, but assume Im wrong), should be within a type, as should that really long global array. And TMD2Loader? thats the name of a subprogram, not a type. All the fields except Mesh stop existing after creation. Either extend Mesh or just put the whole thing into tmesh.LoadMD2 and make the fields local variables instead.

So anyway, I've exagerated my dislike of Kleptos code, so I can make a point, which is, what happens If for example I make the changes I want to Kleptos code, (which Im going to do). Will two versions now exist? Will you host them both? If simon doesnt say which one he likes best do you just pick one?

Edit: Ive reread my post now its posted (if you know what I mean), and I would like to say kleptos work is realy well done, and the point I am making doesnt distract from that. ok.

Just submit your changes and I'll dump them on SVN, or sign up for the power to do SVN Commit :)

It sounds like you want to do some biggish changes, but essentially just to sorting everything, so it shouldn't hurt the final use of the library much or at all, right?
Therefore, no problem.

Snapshots from SVN will be kept around for a while, so anyone wanting Klepto's original arrangement can still use it. (Either from Klepto himself or from the snapshot).

I agree with the giant Functions file being a bit troublesome because it is still rather bulky.
However, it seems logical with the files for each type declaration being specifically for the Type declaration (and only the Type declaration).
Thus, if you want to change that (and go ahead!) I suggest putting functions into files like FBrush.bmx, FMesh.bmx, etc.

Conts... I'm assuming you mean constants defined somewhere?
Ah, in the MD2 loader?
May as well change as long as it doesn't hurt anything...


Of course, for changes like this in the glorious future, discussions should be created in the discussion group. At this time, there is probably little point.


I also see what you mean about the MD2 loader...
I was about to start a discussion (for what it's worth at this point in time :b) about Extensions, and how it will become tempting to add features that sometimes don't quite fit in smoothly to the design.
I've noticed with Irrlicht, for example, that things look horribly messy when there are strange debug tools lying around in the source code, such as automatic FPS cameras which nobody in their right mind would use in an end product (and which are not hard to create!).
If somebody wanted to add a debug tools thing to MiniB3d, it could be added as an optional Include following some kind of convention.
The same sort of convention could be done with the MD2 loader; a particular extension could add itself (via function pointers, perhaps?) to a list of Loaders and called cleanly/automatically, but only if the extension has been enabled.
Adding to that (I am obsessed with soft-coding), some Extensions could be included by default for simplicity and symmetry. (All file loaders as Extensions).

This probably has a speed hit, but also a big boost to the "Ooh, neat code!" thing and it improves the scalability or whatever.

Edit:
Okay, Simon, I've changed all my "3d"s to "3D"s :b

Edit:
Here is that discussion...
The idea actually is a lot like my own recent fiddlings in stuff, so I will try my hand at it; I'm already sort of in the mode for Extension System building. (Although the most recent thing has been converting my beautiful PHP 5 to PHP 4 with Magic Quotes on, so my morale is a bit low and my code may look awful now that I've become resigned to the disgusting PHP 4 glurk).

Hi guys, I accept that my MD2 implementation doesn't completely fit with SimonHs implemention (eg: his b3d loader).
But to explain why I have done it this way is the following. At the beginnig I was thinking of a generic ModelLoader which could be extend to all kinds of loaders. In fact I have choosed a different way. But I mainly use Types to integrate things like complex functions as one type (for me it raises the readability) but feel free to change it to your prefers.

The rest of the MD2Loader is mainly integrated as the rest of miniB3D. Also the really long array wasn't in the type just because it was added later (these values represent precalculated Normals). And the main problem for me was to get midpoint of reintegration if a new update of SimonH is available and the complete confomation with SimonHs code.

Also the filesplitting was just a beginning, maybe you have noticed, that it just uses include, what is in my point of view the false way (because of the long compilation times). With time my goal in this case is to change the whole code to have an import structure so that really only the files are recompiled when needed.

BTW: I think there is no need of two different Versions (mine and H&K). We could add the best of all this Versions (maybe my Version as a prototype) and then make up one new one.

And at least, maybe you should know that all my additions were made with no idea when SimonH will publish a new Version. So all of this is just a 'hack' into MiniB3D and should show what all is possible with this Engine.

Cheers klepto2

Okay, understood :)

I'm working on that Extensions system right now for Loaders and only loaders at the moment, to see if this can all be made tidy -- EEK! BLIde froze :( -- sooner rather than later.

One question so far:
You've added a new field to TMesh called md2_surfaces and a new function to retrieve them. The function to get them looks identical to the old one, though, except that surf_list is changed to md2_surfaces.
So, I wonder... what is the difference between the regular surf_list and md2_surfaces?
Do you think it is possible to get an md2 surface working like a regular surface early on? (I am hoping to keep the Extensions as simple as possible; just a single function needing to be customized aside from those called directly by the user).



On the topic of changing stuff, does anyone know a free SVN client that doesn't stink of bugs?
I've tried a few, but they all have failed in some way. One of them, in fact, did that odd disappearing into thin air act when I tried simply to connect to an SVN server (and I tried it on two SVN servers on two different operating systems / computers!).
SmartSVN is good and has a free version, but it requires me to pay if I want a full feature set.

Tortoise SVN is probably decent (I liked Tortois CVS, so their SVN software probably won't disappoint), but I've never been fond of adding extensions to Explorer so it's not my preferred solution unless they have built an alternate version that works entirely on its own.

yeah, the md2_surface list should normally replaced by a normal anim_surf, I will do it later at home, also I have fixed some compatibility issues in the shader system. Also I will add an option to disable VBO Support in some way to prevent problems with eg: sprites etc. because for smaller vertex groups there is no performance win.

[jedi mind trick]You will write a AlignToVector port for minib3d[/jedi mind trick]

Ant, if you toss out a MiniB3D with DX8.1 driver available support, I'll buy it (Hint! Hint!)

AlignToVector, eh?
This is just a bit of rotation stuff, right?
I'll look at it; It's about time I committed something that actually does something.

Edit:
Ah, I see. More scary than I thought!
Does anyone use the Rate thing? (My ignorance says that would be the a bothersome chunk of doing, so I'd rather avoid it).

The rate thing is the w component on your rotation quaternion. How would not having it possibly change the amount of work needed?