Getting ready to return from my sabbatical...

[crysstaafur]

what happened to any recent/new builds of dabooda turbo? I'll explain..

Initially the p2p project kinda took over my coding time for several months.
Not just the lib, but it's fb counterpart lib as well. in addition to example code, testing/debugging example code (again for both vb and fb), as well as
documentation (however slim it was..)..

The good news is it's done. I just need to get on the ball, finish the last example program and finish the documentation.

Life is crazy when you least expect it. I've been working for myself for nearly
4 months solid at this point, at first it was quiet, so it gave me time to code, but as of now, I am doing good just to read the forums (other than this one) and keep up with things.

I will be starting college here in less than a month. I am at least gonna try
my damnest to get the p2p stuff done and out of the way before I start school.

I haven't given up on DBT. I won't. Even picking through it at least half an hour a week or two I've been able to squash a bug here and there. It still isn't full proof enough to perfectly run lolo just yet. If I can't get it fixed before school starts I am seriously thinking about just dropping the current development branch go back to 1.5.3 and starting over again on
1.5.4

I've at least narrowed down the problem to rect & strip handling when using longs in place of ints.. I think there was a single being treated like an int, when it should have been long in the beginning.. Additionally I am
not really sure if the lolo code takes this into account when loading and rendering textures, but I am actively looking into this.

On the plus side, it was really neat to be able to summon the dev console
and place with some internals inside lolo while lolo was running (in spite of some strip issues... Once I've got all the system math unified to long
and narrowed all doubles to single, I think it will be truly ready for it's last
touches. Mainly more console fun. 8P I am still wondering about the feasablity of live loading a texture using the console.. that will be sooooo
awesome to get working! Imagine when ever you are trying to see if some image looks right in your game, but you don't want to test it using
code.. what if you could set a console variable to a path, then use the console to 'add' the texture' then ask it to display temporarliy while running your game.. could be useful I think. The inline math system is done. The batch system is 50% done. Once the batch system is in place, you will be able to script some pre-defined values/functions/methods
to load automatically.. for instance imagine beign able to see the fps
of your game when using the debug console, but never having to implement fps into your game..

Another thing I am trying for is to be able to trace variable values in
real time. I may have to create a function that would be inserted into
your debug game code and 'log' it's values into a hidden array. this
hidden array would then feed into the console so you can either
view values or (hopefully) change them on the fly to see what something
would do, without having to change a line of code..

I am still willing to take the last leap of evolution after a 1.5.4 build, and
finally make a 'native dx8/fb' dbt.. I've got most of the porting tools done.
Just need two more tools made and it's a reality. One tool that would read
through the original source and sort out non-dx8 content from stuff that
is still dx8 relient. The other would be an inserter that would take a copy
of the fb wrapper and auto fire into it, the non-dx8 code inplace of it's
vtable call. From there I would only have to worry about converting by hand the raw dx8 calls from vb format into something fb can use natively.

I want to do it this way as it will allow me to sort things out to where I would have which methods/funcitons would need special attention when
it comes time to create the optional OpenGL mode..

The vertex class I suspect will need to be converted by hand with no shortcuts..

Additionally the p2p class will likely not be ported, which is why I finally
decided to make it a separate lib altogether. Once I've done a native fb
port of dbt that works, I should then have an intuitive grasp on the C version of dx8 to where the p2p could then be ported..

The main problem is handling network events/triggers. That is the biggest thing preventing a native fb build atm.. so the p2p lib may have to stay as a vtable wrapper.. Even in spite of me still trying to convince myself that there has to be a way around the implements/events issue..

Lastly, once the native port of dbt is done, and the basic structure (and some functionaliy) of the opengl engine is done, dabooda and I are strongly considering a dx11 wrapper for fb. This could also mean a third
mode in dbt. 8P

We've figured out the basic science of what needs to be done to get a .net library written for c++ to work in fb, but translating it into a working piece of engineering is still going to be a hellva challenge.. unless microsoft
magically makes a gcc 3.x compatible dx11 module.. (not real likely..)
It would seem likely that ati/nvidia would more likely in such an endevor..
I know they have in the past..

Long story short, we are not dead, just busy in the background.. working for a better future.. peace...
_________________
There are 10 kinds of people, those who can read binary and those who can't.. ^_^

[Loe]

Hi Crys how are you?
I just want to point out about event trigger.
Actually axsuite2 can generate event trigger programming out of COM/activex.
MS Calendar sample simply show how to invoke Calendar Button click event.
So if dbt can trigger event in VB so does in FB ^_^
currently im still in developing axsuite3.
Major improvement in axsuite3 it'll have COM template generator, and produce vtable FB Class wrapper.
So the FB user can make their own COM dll and use 'dot' syntax as in VB