I'd probably put it in comp.sys.acorn.misc or something like that myself, only diehard Acorn fanatics read csaa *puts on flameproof gear*

So yes, now we need the specs. from Jeffrey and / or Lee.

I'm working on the document I mentioned as I speak. It's pretty basic so far - I've briefly covered what has been said on here, I've cleared up the API vs Engine issue and I'm about to talk RISC OS issues. Then comes the heavy bit as I suspect I'll have to introduce a few things like transformation pipelines to get my points across

I'm not intending this to be "the spec". I'm trying to focus discussion onto some of the technical issues and ways we could go about things. I'm also intending to do an evaluation of OpenGL so we can decide once and for all if that is the route we're going to take. Note I am concentrating more on low-level API issues than than things like should we use portals, BSP trees etc as these firmly belong at the engine level.

Hopefully the final document will be in HTML by exporting from Easiwriter. I can also cope with Draw, Word, RTF and Postscript. Speak up if you have a major preference but I suspect HTML should be ok (afterall, we're all reading this right?)

Any higher level concepts or standards wouldbe more useful later I'm thinking, at least for the core areas.
For planning though, yes I'd think some of the concpets you mention would be worth including.
Can you include some explanation o the terminology though?

Regards,

Andrew

I'm trying to explain some of the terminology, although I haven't got that far yet. I've just finished the overview of RISC OS issues that are immediately apparent to me. I don't know how the rest is going to pan out yet because I've only a vague idea in my head of what I have to say.

BTW if it sounds like this is progressing quickly it's because I've only done the easy part so far. ;-)

would be supplying a basic 3D API for RiscOS,

BTW we gotta call the API RiscGL

I very much doubt that this would be legal. The Mesa project got their wrists slapped because people started calling it "MesaGL".

4) List of people working on project and what they are willing to do.

As for the game engine itself, I don't really have time to be involved in a core role.

on the OpenGL issue then, it looks like we should take OpenGL, adapt it to how we need it (leaving us to move onto the engine), and so we would be supplying a basic 3D API for RiscOS, which could be released along with the Engine.

Game/Application (Mark's area of interest)
/\ ||
|| \/
3D game engine (Jeffrey's area of interest)
/\ ||
|| \/
OpenGL API (By agreement with MicroDigital)
| |
|----| |------|
| |
Open-source MicroDigital
Software Hardware
Implementation Driver

(My area of (Not our
interest) concern)

I have tried editing it, but it ignores my changes. >

The formatting is screwed up, but you should be able to make out what that is supposed to look like. All spaces have been removed.

I have tried editing it, but it ignores my changes. >

The project seems to be going along quite well now, and it sounds like Lee's spec thing should cover all the things we need to take into account.

There is a feature of OpenGL which I think is really handy (Supposing I've read the docs right), and that's the vertex arrays. Having lists of vertices makes sense, but having a 'stride' value so you can cut out non-graphics relevant data is a very good idea. If we are making an API then this is a very important feature IMHO.

In terms of all the 'fancy' features, I agree that dotted lines are unlikely to be needed, and coding should be much easier without them. Features like curve approximation/polygon division would be nice, especially if we had curve objects built into the renderer/API. That way the graphics would be scalable depending on what system you're running it on. On the other hand, scalable graphics might be a bit too complex for us to delve into (For the first version at least). I suppose this will be in your docs somewhere, Lee?

Since I'm here, I might as well mention an alternative to floating point that I've just thought of - fractions. It would be handy if we had some kind of competition to produce the fastest math routines for integers, fixed point, floating point and fractions. This would really help us to decide what system to use, perhaps I'll write a few progs to do that some time (Although other people trying their own versions would be nice). Stick your code up on the 3D engine bits thread.

[Edited by Phlamethrower at 11:04, 15/1/2001]

The project seems to be going along quite well now, and it sounds like Lee's spec thing should cover all the things we need to take into account.

I doubt it will to start with, but the point of the document is to find the gaps

There is a feature of OpenGL which I think is really handy (Supposing I've read the docs right), and that's the vertex arrays. Having lists of vertices makes sense, but having a 'stride' value so you can cut out non-graphics relevant data is a very good idea. If we are making an API then this is a very important feature IMHO.

I just knew the boy Jeff was going to say that the minute he read up on them. Vertex arrays are incredibly powerful. There are downers to the OpenGL implementation but I'll be covering that in the document. Bear in mind that while they're downers to a software rasteriser, hardware accelerators are often designed to implement the D3D and OpenGL specs.

In terms of all the 'fancy' features, I agree that dotted lines are unlikely to be needed, and coding should be much easier without them. Features like curve approximation/polygon division would be nice, especially if we had curve objects built into the renderer/API. That way the graphics would be scalable depending on what system you're running it on. On the other hand, scalable graphics might be a bit too complex for us to delve into (For the first version at least). I suppose this will be in your docs somewhere, Lee?

So we also want something on scalable engine techniques and higher order surfaces? I'll admit I don't know much about these. However higher order surfaces are usually built on top of the more primitive OpenGL commands so are a possibility once something is up and running.

It would be handy if we had some kind of competition to produce the fastest math routines for integers, fixed point, floating point and fractions. This would really help us to decide what system to use, perhaps I'll write a few progs to do that some time (Although other people trying their own versions would be nice). Stick your code up on the 3D engine bits thread.

Good idea, although I'll have to leave it to the ARM guys. However I believe the routines should be seen as a resource rather than a definite statement of how a driver works. If there's no FPA fixed point would be nice. Otherwise why not take advantage of the FPA? Bear in mind that these would be two distinct drivers for the same API. Before people groan, that doesn't actually represent a huge amount of work over getting an API in the first place.

Otherwise why not take advantage of the FPA? Bear in mind that these would be two distinct drivers for the same API. Before people groan, that doesn't actually represent a huge amount of work over getting an API in the first place.

*Smacks head on table*

Of course! Why should we care about what number types we're using? If it's written in C then changing to a different type is relatively easy, and in assembler it would all be done by macros/routines, which are easy to change anyway!

I don't know that much about scalable engines myself, so it would be best to leave that out for the first version (As in forget about it completely, then spend the next couple of months re-writing the code to support it )

I thought that fractions were taken account of for the graphics plotting by performing the calculations precisely before entering the low-level code and then shifting the values back down for screen coordinate plotting.
I assume yu're talking about other sections of the whole system??

On a non FPA enabled ARM processor using floating point all the way through may prove too costly. The trick then is to change the parameters passed into each call to fixed point and optimise the transformation code for that. However the application is none the wiser for it. Note you are correct about "shifting down". With fixed or floating point math you have to "clamp" the values back to screen coordinates eventually but this happens after the transformations have taken place.

As Jeff says, if we redefine all the types and math operations using macros we can simply recompile / re-assemble to change between the numeric types used.

There's some slightly bad news - the document I was working on is going to be delayed, probably until next week due to my PhD supervisor wanting to see some writeup.

I didn't even know CC was getting things put on it yet.... must be some mail problem at my end or something. I'll take a look.

You can stick my email address up on the site Nathan, just use the hotmail one (the one i'm using here).

Since Lee's holding us up on his docs, I'm getting some time to do work on XSpr, so there may be a new version out sometime soon for those who use it (Just me and Andrew at the moment I think )

Looks fine so far, although analysing the sites features isn't exactly possible yet since they aren't there
You can stick my email address up on the site Nathan, just use the hotmail one (the one i'm using here).
Since Lee's holding us up on his docs, I'm getting some time to do work on XSpr, so there may be a new version out sometime soon for those who use it (Just me and Andrew at the moment I think )

So is the plan to see what Lee says the project will entail, Jeffrey?
Then will you ascribe roles or should we hold another discussion at this point?
The project looks set to go ahead at some point, hopefully. It should be a learning experience and certainly will be for me!!

Since Lee's holding us up on his docs,

and your homework for tonight is to read and understand the full OpenGL spec

I know you're kidding.

So is the plan to see what Lee says the project will entail, Jeffrey?

The project will entail

lots of reading
lots of smashing head against the wall
lots of coding (we hope)
followed by some sort of release.

I'm getting a little bit confused though now. When I started the doc it was intended to look at our options, pros and cons of each. Since then it seems that we've pretty much come to the conclusion that following the OpenGL API is the way to go so I'm wondering now what people want to see in it. I've introduced this whole thing, I've looked at some RISC OS issues but I can't exactly explain OpenGL - that'd take a whole book.

I figure that I should introduce some terminology (such as coordinate systems and the like), transformation pipelines and then look at the parts of OpenGL that are of most relevance to us - ie the general philosophy, the Begin / End API, vertex arrays and maybe display lists (although I'm not that familiar with them).

Blimey, that's quite a lot actually.

I need some correctly worded information about this project for the about page.

BTW, I've pretitles it RISC OS G'e'L. Cool huh

Andrew

As for writing the document in stupid speak I'll do my best - remember though you can always go "oi Johnston I don't understand this bit, write it better".

Finally what I meant by release was something that is usable as Andrew points out, I didn't mean some huge product.

http://www.parsec.org/download.html

BUT it's a 2MB download.

This is the kind of engine that sits on top of an API like OpenGL and maybe worth a read.