Got some knowledge of ARM code/C/C++/3D graphics?

Then head on down to www.coderscauldron.com and join the revolution!

This is the MESA website:
http://www-solar.mcs.st-and.ac.uk/%7Edavidb/Mesa/

And... IT WORKS VERY GOOD! We only need for much more performance a FPU because OpenGL an other 3D Libs (Direct3D) works with floiting points. A port of Unreal Tournament and Quake3Arena to RISC OS is with MESA not a problem.

MESA is using the drivers concept, so if a company would release in the near future a 3D graphics card, the support of this card should be possible and very easy.

Think about it...

Best regards,
Artchi
http://www.t-c-r.org/

[Edited by Artchi at 17:55, 20/4/2001]

/me ducks any flames in reference to this post

According to the web site it needs 8+ megs of RAM, and long filenames/77+ directory entries, which may put off some people (*cough* me *cough*) Plus MesaLib is in tar format, and I found it a pain tracking down a tar extractor.

Not only will RGL (Our API) be lower spec, but should also come in one source archive, useable via a SWI interface, jump table, or AOF, making it very accessable.

Plus "Mesa on RISC OS needs optimisation. In particular, the driver rendering functions need rewriting in assembler. This is where you come in. Your improvements will be appreciated." The lack of Mesa news/demos/games on any Acorn sites I've seen does suggest that it needs these optimisations before being useable with games, and not being able to modify the MESA source itself could be a problem when optimising, or shows that you haven't been advertising MESA enough

RGL will already be optimised when released. In terms of hardware support, that could probably be done in RGL by swapping a few source files round, using a few #defines, or even splitting it into seperate AOF's and run-time linking, which is essentially a changeable driver system.

And I can't exactly join the MESA team if I've already started on RGL

I'm not trying to say that MESA's bad or anything, but...

According to the web site it needs 8+ megs of RAM, and long filenames/77+ directory entries, which may put off some people (*cough* me *cough*) Plus MesaLib is in tar format, and I found it a pain tracking down a tar extractor.

You probably need this much memory to build the libraries, although I wrote that a long time ago. I've never built it with Acorn's C compiler (since I don't have it) so the requirements for anything other than gcc are unknown to me. The 77 file limit wasn't initially an issue and it may not be a problem if you selectively extract the files. I appreciate that this may be tricky if you don't already know which files you need!

It's also available in .zip and .tar.bz2 formats. See http://download.sourceforge.net/mesa3d/

Not only will RGL (Our API) be lower spec, but should also come in one source archive, useable via a SWI interface, jump table, or AOF, making it very accessable.

I'm encouraging the development of this, although I haven't really contributed anything concrete, since I suspect people want a fairly short-term solution and I can't see Mesa getting friendlier to low-spec. systems in the near future.

Plus "Mesa on RISC OS needs optimisation. In particular, the driver rendering functions need rewriting in assembler. This is where you come in. Your improvements will be appreciated."

The comment still stands. There has been interest in utilising fixed point arithmetic routines in order to boost the speed on StrongARM machines, but I haven't heard anything about this plan for a long while.

The lack of Mesa news/demos/games on any Acorn sites I've seen does suggest that it needs these optimisations before being useable with games, and not being able to modify the MESA source itself could be a problem when optimising, or shows that you haven't been advertising MESA enough

It can do some fairly simple screensavers on the ARM7500FE machines and possibly on StrongARMs, depending on the complexity of the scene.

I announced the initial availability of the RISC OS driver on comp.sys.acorn.announce back in 1998, and have occasionally posted information to various comp.sys.acorn groups, but I haven't posted updates to .announce mainly because I haven't substantially improved its performance.

RGL will already be optimised when released. In terms of hardware support, that could probably be done in RGL by swapping a few source files round, using a few #defines, or even splitting it into seperate AOF's and run-time linking, which is essentially a changeable driver system.

And I can't exactly join the MESA team if I've already started on RGL

Well, I have devious plans to work some of your efforts back into the RISC OS driver for Mesa, if I ever get enough time to do so.