Linked by Thom Holwerda on Thu 7th Jul 2005 13:21 UTC
RISC OS Hardware accelerated 3D graphics on RISC OS took a step closer to reality, thanks to Simon Wilson. He claims to have ported Mesa 3.2, a 3D graphics library that sports an OpenGL software interface. More importantly, he says he has also ported an Nvidia graphics accelerator from BeOS to harness the GeForce2 video card in the Iyonix to plot graphics fast in hardware.
Thread beginning with comment 1011
To read all comments associated with this story, please click here.
Is it just OpenBeOS(Haiku)
by Earl Colby pottinger on Thu 7th Jul 2005 20:19 UTC
Earl Colby pottinger
Member since:
2005-07-06

I noticed lately that it seem a number of alt.OSs seem to depend of on Hakui's opensource to get things started.

Not that Haiku is doing it all, but the only open-source Hardware accelerated 3D graphics code I have heard about has been Haiku's. Everyone else seems to depend on wrappers around Windows drivers or used closed sourced drivers for the card.

Same with file systems. While there are some interesting open source journaled filesystems out there the only ones that offer both journaling, advance file attributes and live queries at the same time seem to be based on OpenBFS.

I am always surprised no-one ported OpenTracker to another OS.

And I just full of it? If not what else do you think people will port from Haiku in the future?

Reply Score: 1

RE: Is it just OpenBeOS(Haiku)
by on Thu 7th Jul 2005 21:03 in reply to "Is it just OpenBeOS(Haiku)"
Member since:

Porting OpenTracker is far more complicated, actually, than porting a display driver. Why is that?
There are a few reasons, actually. For one thing, BeOS has a threading/application design/implementation model that, AFAIK, has only Syllable and its parent with a matching or almost identical model. If you take out the B out of the names of the classes OpenTracker uses from the Interface Kit and other things, it would likely largely compile.

However, above and beyond that, is that (though this isn't as big of an item as it could be) it uses some undocumented BeOS API's that are not officially supported, and may change. At this point, it's likely that perhaps only yellowTab would change them, if you consider Zeta the heir apparent to BeOS 5.03. Then again, Zeta is likely in the future to replace more portions of its codebase and libraries with those developed for Haiku.

And the last meaningful thing: OpenTracker is a snarled piece of code for anything that was part of OpenTracker when it was released. Anything that started out in OpenTracker itself (that is, the vector icons did NOT start out in OpenTracker, and use a pre-existing library) is cyclically dependent on itself, to where less than 1% of the original OpenTracker code can be reused without a lot of hacking at the source. Supposedly, Tracker was published as OSS under the thoughts and hopes the code would be reused in other BeOS software. The reality, because of the structure, is that the only reuse of the code has been in branches of a full OpenTracker itself, because almost all of the code is completely spaghettified, and it isn't worth the bother to try to reuse it.

OpenTracker should be completely replaced with something that does at least as much as OpenTracker currently does, but written with a fresh design with no code from the old Tracker, with using notes about the file handling in terms of copying files with all the attributes, etc. that make OpenTracker distinct from most other file managers. This will, of course, likely cause some breakage of applications that use BFilePanel, the file selection dialog that's used as part of the standard BeOS API: this is exported from the OpenTracker executable, such that an application that uses a it effectively brings in almost all of the code of OpenTracker into its address space, just to allow a common file dialog for opening and saving files. Perhaps this is something that will happen with Haiku R2, which may very likely have major API changes anyway, besides likely using a more recent version of gcc where the C++ ABI is different from that of gcc 2.9x.

Reply Parent Score: 1

Earl Colby pottinger Member since:
2005-07-06

>Porting OpenTracker is far more complicated, actually, than porting a display driver.

Thanks for the informative reply. I guess I have been fooled by the number of diffirent OpenTrackers into thinking it's code must be easy to understand/change. I have only looked at the code once, and then I was over looking for the find function to see if I could add features to the queries. I guess that is your point, even with a maze of code it is possible to add functions, but that does not mean understand the total code and porting it is easy.

And yes, I too am looking forward to the day that Haiku is compiled with a more up-to-date compiler, BeOS is pretty fast for the things I do now, an update compiler should make it sing.

Reply Parent Score: 1

RE: Is it just OpenBeOS(Haiku)
by adamk on Fri 8th Jul 2005 18:27 in reply to "Is it just OpenBeOS(Haiku)"
adamk Member since:
2005-07-08

Not that Haiku is doing it all, but the only open-source Hardware accelerated 3D graphics code I have heard about has been Haiku's.

You've never heard about the Direct Rendering Infrastructure? http://dri.freedesktop.org/wiki/

Adam

Reply Parent Score: 1

Earl Colby pottinger Member since:
2005-07-06

Nope, until this thread earlier pointed it out to me I had not. I am just now trying to plow my way thru it right.

PS. Thank you everyone for the non-flaming replies - I learnt something new, which is always good ;)

Reply Parent Score: 1