How about this then: Have a SWI interface for language independence (e.g. for use in BASIC, and for testing purposes).

Yep

Application BLs to correct place in exported jump table -> Jump table B(ranch)s to OpenGL routine in module.

This still involves breaking the processor pipeline a few times... would it be significantly quicker?

I imagine so otherwise they wouldn't have bothered for the sharedClib. Also could you then execute the module code without changing the processor mode? Side-stepping the context switch would be significant surely?

Mind you you forgot that you have to re-instate the modules address space, so branch table will point to veneers to do this which call the actual code.

I've been doing a little bit of testing with my Warp code and I'm finding that the SWI overhead is fairly significant. Then again I have only got an A4000.

I think we need to talk to someone who knows about the Shared C Library, like the guy who maintains the SharedCLib stubs for GNU C. And Microdigital, of course...

If they'll talk to anyone.

Anyway....

There are a few reasons I've been avoiding OpenGL:

1. Big download to try and ship over to my Acorn
2. All the fiddling round with filenames we would have to make, and the image filing system needed for the files to be set up properly (I'm on ROS 3.7)
3. All the FP-reliant stuff
4. All the little calls and things that would eat up tons of processor time if done as a module
5. Any other PC designed bits that would muck up Acorns
6. The fact I know virtually nothing about OpenGL
7. Trying to get the thing to compile, even before the major Acorn-optimization occurs
8. The single-tasking basis
9. The lack of an API to follow (Making one implementation incompatable with another)
10. That if I were to make my own API, it would either be ignored/rubbish/never finished
11. It's a lot for one person to do in their free time while going to College (Remember that the exam system has changed now, meaning I've got mocks in Feb and real exams in the summer, followed by the same thing next year!)

Get the idea?

If you lot are set on getting OpenGL, and can come to some firm descision on how to get the thing to work (Module/AOF, multitasking, etc), then I could at least start it, and if I give up at some point I'll shove it on the Web somewhere.

The only real question I can leave you with is whether this thing should be OpenGL, or a new/other engine. Vote now or die!

I'd urge anyone to do anything like this in ARM assembler so that it's comprehensible by more RISC OS users and perhaps more optimised for the hardware we use.
Of course this way might not be the most feasible...

I'd urge anyone to do anything like this in ARM assembler so that it's comprehensible by more RISC OS users

Generally things start off being written in a high level language (particularly if you want to port them!), and optimised later on for a specific architecture (eg StrongARM, ARM+FPU)

11. It's a lot for one person to do in their free time while going to College (Remember that the exam system has changed now, meaning I've got mocks in Feb and real exams in the summer, followed by the same thing next year!)

Get the idea?

If you lot are set on getting OpenGL, and can come to some firm descision on how to get the thing to work (Module/AOF, multitasking, etc), then I could at least start it, and if I give up at some point I'll shove it on the Web somewhere.

The only real question I can leave you with is whether this thing should be OpenGL, or a new/other engine. Vote now or die!

But don't worry, there is a lot more to a game engine than the rendering routines... How about you write your game engine, refering to the proposed OpenGL specification.

When the rest of the engine is finished, if nothing comes of efforts to get OpenGL/MiniGL on RISC OS, then you'll be no worse off than if you'd just sat down and written the renderer yourself in the first place.

It would be totally unreasonable to expect any one person do do such a project on their own. The essence of such a system would be cooperation between programmers for the common good.

I'm up for being a team-hub on such a project and I'll make some sort of web site somewhere but I need interested programmers.

We need to get some kind of agree API/organisation going if this project is going to get off the ground. I think RISC OS Ltd and Microdigital need to be included, for starters.

[chuckles]I'm quite sure that you would get nothing back from ROL or MD regarding this especially ROL. They won't be interested.

I understand where Jeff is coming from concerning OpenGL. Despite being an advocate I'll admit I've shyed away from Mesa simply because of the ridiculous system requirements for it (8MB RAM, 6MB HD). This isn't a dig at David Boddie mind - he has done a fantastic job, as have the rest of the Mesa team under Brian Paul but in it's current state it isn't suitable for our needs.

This is where the concept of MiniGL comes in. OpenGL has somewhere around 150 functions, most of which are irrelevant for games, a MiniGL driver contains just the required functions.

However, even assuming this route was taken, there are still other issues to be considered. As I've already said OpenGL offers a large API, partially because a lot of the functions are duplicated depending on whether they take shorts, ints or floating point values. Which set do you concentrate on? Bear in mind that any application that uses the integer interface loses a lot of accuracy (it's NOT a fixed point interface) and also if you want to port applications then the floating point interface is most useful.

With this in mind perhaps someone with more experience in BASIC and ARM than I have could explain how floating point numbers would be transferred across SWIs via registers (ie do you load a register with a pointer to the floating point number?). I don't have these problems with libraries in C as I just use floats. Obviously the underlying API doesn't have to store and manipulate data as floats.

Finally one thing to be aware of. With almost any 3D API you'll soon realise that you could write more efficient code if you wrote it specifically for your engine - using an API has other advantages though. As an example with both OpenGL and Direct3D you'll soon realise that it's impossible to transform objects without transforming certain vertices two or more times due to the way they work. Without explaining a lot of OpenGL and giving example code it's difficult to explain why but it's due to the fact that both APIs have to work at the primitive level (points, lines, polygons etc) rather than object level to maintain flexibility.

Are people still interested?

We need to get some kind of agree API/organisation going if this project is going to get off the ground. I think RISC OS Ltd and Microdigital need to be included, for starters.

[chuckles]I'm quite sure that you would get nothing back from ROL or MD regarding this especially ROL. They won't be interested.

They should be. OpenGL on set-top boxes?Netstations?

[chuckles]I'm quite sure that you would get nothing back from ROL or MD regarding this especially ROL. They won't be interested.

They should be. OpenGL on set-top boxes?Netstations?

Netstations is Pace's domain and I don't think they are too bothered with games at the moment.

Andrew Weston - OpenGL, optimised assembler
Chris Bazley - OpenGL/MiniGL, group effort, company backing
Nathan Walker - Group effort for anything 3D
Lee Johnston - Attempted MiniGL, almost died but still interested in Open/Mini

How about you write your game engine, refering to the proposed OpenGL specification.

Hmm...
I suppose this is one way round it. Right the physics/game engine, then if OpenGL vanishes I could rip apart my code, work out all the OpenGL bits, and make a version of OpenGL which only does the things I need it to, kind of like a MiniGL implementation. It would probably be part of the engine itself, so hardware rendering and future upgrades would only be possible by re-compiling the physics/engine code. It is a pretty good idea to work from the game side down to the rendering, since then you know what you need.

[chuckles]I'm quite sure that you would get nothing back from ROL or MD regarding this especially ROL. They won't be interested.

We can always start without them, and if they decide to do their own version the we can just completely ignore it or something. Alternatively, if they come crying to us then we can tell them to fuff off.

With this in mind perhaps someone with more experience in BASIC and ARM than I have could explain how floating point numbers would be transferred across SWIs via registers (ie do you load a register with a pointer to the floating point number?).

The basic format of an FP number (in case you don't know) is the fraction (I think that's the right name) and the mantissa. To get a 'real' number from that, you would use:

MOV OUT,FRACTION,LSL #MANTISSA

which is basically how an FP would be converted to an integer. The maths are basically the same as working with numbers in scientific format, e.g. (5*10^5)*(7*10^3) would come to 35*10^8, timesing the fractions together and adding the mantissas. I think I've got some more info in an old BBC assembler book, very good for optimised code ideas

Either use that system, or if it's an FP register you can just use one of the FP commands to transfer it, and let the hardware/software do the rest.

At the moment I think I/we've got two paths - the OpenGL one, or the optimised engine one.
The optimised engine would be a complete system (Physics, renderer and game links), probably unexpandable to keep code simple, and likely to be written as a module for easy upgrades/multitasking. Hardware support could be added at a later stage by producing a hardware-only version of the module (Which could even interface into OpenGL).

Hmm, perhaps we need another vote...

1. Full OpenGL, company support for standard implementation
2. Full OpenGL, ignore any standards
3. Cut-down OpenGL (Unlikely to be any standards)
4. Own complete engine, again no standards

Once we have a firm descision on what this is, we can go into detail on what it will be coded in and stuff.

Also Nathan, I've got a good idea for a website that I've been thinking of for a month or two - www.coderscauldron.com (Or co.uk). Place for Acorn coders, with forum, file space, web space, etc. If I/we had the time it could be nice to set it up

What do you think Nathan? This would detract a bit from speicifc VOTI work although I suppose it would eventually become beneficial.

Also Nathan, I've got a good idea for a website that I've been thinking of for a month or two - www.coderscauldron.com (Or co.uk). Place for Acorn coders, with forum, file space, web space, etc. If I/we had the time it could be nice to set it up

What would be different with the site compared to other acorn sites? Also, I like to spend minimum possible on web-sites (as you may have noticed), what's the cheapest ISP to offer domain name and server space? I know about freenetname but they stipulate they can use adverts at any time and I already have an account with them and you are only allowed one.

What do you think Nathan? This would detract a bit from speicifc VOTI work although I suppose it would eventually become beneficial.

As regards the VOTI group of people and associates, all are busy with projects. If this 3D code is serious and everyone is serious about doing stuff then time can be withdrawn from specific VOTI projects for work on this 3D code. However, anyone working with us on EMD will have to put EMD as priority should we need anything due to it being largely complete.

As regards Overcast, time can be detracted from this because the project is in early stages and this project may bring new ideas how to do things.

I ccould also, hopefully, get advice from good RISC OS coders past and present but they probably won't be able to participate in the actual coding, merely give advice.

Cya peeps

Because I seem to remember the Ant suite had some sort of plugin files that it could load in and use when it needed them.

On to CC:

What would be different with the site compared to other acorn sites?

OK then, name me the current Acorn websites that are programming orientated, offer web space for member's projects, and have forums with file enclosure support, with a forum structure that is easily changed (e.g. one directory per project).

As far as I know, there aren't any.

Also, I like to spend minimum possible on web-sites (as you may have noticed), what's the cheapest ISP to offer domain name and server space?

I've found one free offer - www.0costhost.com. Might not be enough web space though, although we can easily expand that by signing up with someone else and linking the new files to there

In terms of adverts, I'm really not that bothered about banner ads. I've never clicked on one in my life.

As regards Overcast, time can be detracted from this because the project is in early stages and this project may bring new ideas how to do things.

I'm sure Andrew will be pleased about that

If you license out the API or Engine (possibly ask for x% from the takings of a game produced using the engine then that time spent by everyone will also have been paid back a little, whilst giving us all a 3D API with which we can then make some dead cool 3D games, which in turn will draw more users to RiscOS

Hmmm... I don't think that asking for money for this engine would be such a good idea. No-one would use it, since there isn't really a RISC OS games market to pay the money out. And if it's a VOTI project, then VOTI themselves would be using it for games (Along with everyone else), so I'm sure VOTI will pass x% onto whoever helped make it

I vote No. 4 - create the new 3D engine.

Finally! A vote! Give the man a wooden donkey!

As regards XSpr, I've worked out the format of the 24bit compressed sprites but haven't got round to coding them or the rotated/scaled sprites either

Alex, I've got no idea what .o files are on Unix, so I can't help you. You can do things like AOF files for linking with C (At compile time though ). There may be some general run time plugin system somewhere, but I've never seen one

Come on you lot! Vote!

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

Also, I like to spend minimum possible on web-sites (as you may have noticed), what's the cheapest ISP to offer domain name and server space?

I've found one free offer - www.0costhost.com. Might not be enough web space though, although we can easily expand that by signing up with someone else and linking the new files to there

In terms of adverts, I'm really not that bothered about banner ads. I've never clicked on one in my life.

I'm surprised at you guys! If you want to spend no money at all, and don't like ads, why didn't you ask us?

The server TIB/AA is on is here to serve the RISC OS community. No costs, no banner ads, account at joker.com (domain registry), full CGI/PHP access and a friendly Webbie that'll give you free forum code (not me obviously, the "friendly" bit should tip you off that I'm talking about Tim

Ask and ye shall receive...

[Edited by rich at 16:43, 11/1/2001]

As far as dynamic linkers go then I am aware of two further options. Firstly there is rink but I don't know the status of this. I'm pretty sure Ben Summers isn't maintaining it anymore. I did hear that someone else was but I don't know who. I made some progress with decoding the file formats but couldn't figure out a few bits. Again it'll probably break when we go 32bit.

The other option is my own linker, wlink. It's written in C but I never came up with a quick and easy way to export symbols from the application to the library (actually read I know the theory but have neither the time nor inclination to do it) and as such it relied on the app writer creating a symbol file from link at link time. It doesn't have a particularly nice API either. Finally I it won't cope with .o files compile for modules so is a non-starter there. If anyone wants to look it's at

http://www.comp.lancs.ac.uk/computing/users/johnstlr/riscos/wlink/wlink.zip

Another option for plug-ins that may be workable is to have an event driven engine. The core of the engine provides the minimal framework for registering event handlers and firing events. Additional modules could register for events by passing a SWI number and a block to be called with. You wouldn't need many events and most would be coarse grained to the extent that handlers would do a lot of work so the SWI overhead would be fairly, negligable. Of course this does depend on the ability to construct SWI calls on the fly but then isn't this what the CallASWI module is for?

Although non-module based this is the approach taken by both TAG and my own OS/G engine. Before I forget the 3D resources I mentioned are TEMPORARILY available at

http://www.comp.lancs.ac.uk/computing/users/johnstlr/riscos/threed.html

however I'm currently discussing with Nathan about cleaning up the distributions and putting them on the coding vault. When this happens I'll let the AA / TIB people know so they can post news story if they want.

As far a hosting server goes, while I appreciate Rich's offer it would appear that people have never heard of http://sourceforge.net which was setup with precisely this in mind. I suggest people take a look but to get the best out of it we all need to understand CVS and such like.

Finally as far as the vote goes I don't understand the distinction being made on options 1-3. OpenGL is OpenGL is OpenGL. If you create an implementation that adheres to the freely available spec then it will be standard. If a company produces an OpenGL module then all you have to do is alter your module to respond to the same SWI numbers. MiniGL is not non-standard. It is a subset of OpenGL. Such a subset hasn't been standardised but if you go and read source code which uses it it's not hard to figure out what is useful or not. Most MiniGLs probably implement the same subset.

As for building a RISC OS only engine I wonder if people understand fully what this entails and that any engine is independent of OpenGL anyway. In fact most PC engines are independent of the underlying API so they can swap between OpenGL / D3D / whatever. So assuming this is the choice of people perhaps we could hear your thoughts on

what the API will look like
...what level does the API work at
...how will an app interact with the engine
...how will an app customise the engines output?

what the architecture will be
...what does the transformation pipeline look like
...what kind of state does the engine need to store?

etc

Oh yeah what's XSpr?

If a company produces an OpenGL module then all you have to do is alter your module to respond to the same SWI numbers[/quoute]

The idea is that we wouldn't have to change the SWI numbers! Imagine what would happen - we would have to change the SWI numbers (And perhaps some of the parameters they pass), re-compile all our own code, re-distribute the module and code, and then wait while everyone else re-compiles their code. Getting in touch with companies in the first place would let us decide on a standard OpenGL SWI base/system vars/plug in system/etc.

As for building a RISC OS only engine I wonder if people understand fully what this entails and that any engine is independent of OpenGL anyway

I understand what it entails, and yes it would be completely OpenGL independent because it wouldn't need it at all, or even be likely to support it (since no current RISC OS OpenGL initiative exists)

what the API will look like
...what level does the API work at
...how will an app interact with the engine
...how will an app customise the engines output?

what the architecture will be
...what does the transformation pipeline look like
...what kind of state does the engine need to store?

We will be either converting something OpenGL-like, or doing a completely new engine that will be a renderer, physics engine, game links, etc without any API for anyone to make (for example) new object types. Let us decide before bombarding us with questions that would have different answers depending on what we're doing.

And XSpr is a sprite plotter I've been working on, about 20k of code and comes in module/AOF format

Also if I appear a bit argumentative then it's because I'm arguing on another forum

Finally as far as the vote goes I don't understand the distinction being made on options 1-3. OpenGL is OpenGL is OpenGL. If you create an implementation that adheres to the freely available spec then it will be standard. If a company produces an OpenGL module then all you have to do is alter your module to respond to the same SWI numbers. MiniGL is not non-standard. It is a subset of OpenGL. Such a subset hasn't been standardised but if you go and read source code which uses it it's not hard to figure out what is useful or not. Most MiniGLs probably implement the same subset.

As for building a RISC OS only engine I wonder if people understand fully what this entails and that any engine is independent of OpenGL anyway. In fact most PC engines are independent of the underlying API so they can swap between OpenGL / D3D / whatever. So assuming this is the choice of people perhaps we could hear your thoughts on

Having a decent graphics API as a facility available for all programmers is a project which can usefully and practically be done cooperatively.

Writing a game engine on the other hand, and the way in which this is done, is a very personal project. Since 3D game engines vary so much with personal preference, it essentially comes down to a number of clever people who may write 3D engine(s). The idea that all games should be based on the same engine isn't even particularly desirable, in my opinion.

I think that Jeffrey should write his 3D engine in whatever way he likes, and if he is generous then he can release it as well-documented open-source. The point about a decent graphics API was that this (the bit that is generally common to all engines) is there to make everyone's life easier.

Other than that, people can write what they like. Good luck to them!

Just to clarify the different options...

1. We would be converting OpenGL to RISC OS, with a standard SWI set, upgrade paths to future OpenGL versions, etc.
2. We would be converting OpenGL, but without any real standards. This would allow us to heavily modify the OpenGL source, making it more RISC OS compatable but removing the upgrade path
3. We would convert some of OpenGL, e.g. the bits that are game related, in a similar fashion to no. 2 (Since it won't really be to any standards). Don't expect any PC games to work with this version, since FP is likely to go or something else major like that
4. Completely new complete engine system, ready for a game. Would be a renderer, object definitions, physics engine, and the game engine links (e.g. run this code when this object hits something). Unlikely to be plug-in expandable, but hopefully enough rendering options for any game type (space, RTS, indoors/outdoors, etc).

Get the idea? The only one I'd ever try to do myself would be no. 4, because that could all be based around my own ideas which everyone else would then follow. Group work on it would help though.

Also the forum I was arguing on (The TF2 one) has just crashed (Again )

I seem to be noticing that this group effort thing has suddenly died out, and that people expect me to be doing all the work again (Doh!), as well as leaving the desicions to me (Bad if this engine is to be released, which is what the whole idea was), and that there are still no votes!

I'm behind you all the way (as is anyone else who likes the prospect of 3D games). The essential (and good) spirit of this thread is intact (e.g. sharing of code/ideas/documenting your 3D engine)

It is just that Lee and I were pushing for /automated/ cooperation where the renderer is concerned (through a free, open-source module).

Just to clarify the different options...

1. We would be converting OpenGL to RISC OS, with a standard SWI set, upgrade paths to future OpenGL versions, etc.

2. We would be converting OpenGL, but without any real standards. This would allow us to heavily modify the OpenGL source, making it more RISC OS compatable but removing the upgrade path

3. We would convert some of OpenGL, e.g. the bits that are game related, in a similar fashion to no. 2 (Since it won't really be to any standards). Don't expect any PC games to work with this version, since FP is likely to go or something else major like that

4. Completely new complete engine system, ready for a game. Would be a renderer, object definitions, physics engine, and the game engine links (e.g. run this code when this object hits something). Unlikely to be plug-in expandable, but hopefully enough rendering options for any game type (space, RTS, indoors/outdoors, etc).

People may help your with your (ambitious ;-)) game engine. This would be great. But myself, I'm busy on another project at the moment. The area of overlap is the renderer...

Get the idea? The only one I'd ever try to do myself would be no. 4, because that could all be based around my own ideas which everyone else would then follow. Group work on it would help though.

In my view, we wouldnt really be benefitting from options 1 to 3, - they may make it easier to convert a PC Game, but as we have discussed before Licensing fees are way out of the Risc League.
No. 4, whilst being a lot of work, will by far produce from that kind of project, where the "API" would be somewhere under the engine, meaning that anyone can pick it up and actually spend their time in writing a GOOD, and high quality game, rather then spending much more time on writing an engine that uses OpenGL (although OpenGL would make this a little easier).
VOTE No. 4! VOTE No. 4! VOTE No. 4! VOTE No. 4!
(god bless copy & pasting )

& WHEN IS TF2 EVER GOING TO BE RELEASED!!!!!????

Would you change your mind if Microdigital were persuaded to release the proposed renderer API for their Omega card?

Maybe. The main problem I would have then is my distinct lack of knowledge about OpenGL. You clarifying that there is no 'source' is a help, which means that (As you said) we can seriously mangle it up internally so that it's easier to work with on Acorns (Instead of sticking with all the PC file names, an image filing system for long file names, etc.).

Just plain converting something is quite easy, because you don't have to make any critical descisions yourself

If a company produces an OpenGL module then all you have to do is alter your module to respond to the same SWI numbers

The idea is that we wouldn't have to change the SWI numbers! Imagine what would happen - we would have to change the SWI numbers (And perhaps some of the parameters they pass), re-compile all our own code, re-distribute the module and code, and then wait while everyone else re-compiles their code. Getting in touch with companies in the first place would let us decide on a standard OpenGL SWI base/system vars/plug in system/etc.

This has been thought of... ;->

In my view, we wouldnt really be benefitting from options 1 to 3, - they may make it easier to convert a PC Game, but as we have discussed before Licensing fees are way out of the Risc League.

Licensing fees come down with time. And I think that anyone who has given up on keeping up with industry-standard features has given up on RISC OS, essentially.

To put it bluntly, you'll be getting a new graphics API soon (with Omega), and so a software implementation will benefit all the programmers who intend on using it. Not to mention all the people who don't buy Omegas.

No. 4, whilst being a lot of work, will by far produce from that kind of project, where the "API" would be somewhere under the engine,

Presumably you mean on top of. Under was what I was advocating.

meaning that anyone can pick it up and actually
spend their time in writing a GOOD, and high quality game, rather then spending much more time on writing an engine that uses OpenGL (although OpenGL would make this a little easier).
VOTE No. 4! VOTE No. 4! VOTE No. 4! VOTE No. 4!
(god bless copy & pasting )

Nobody is AGAINST number four, everyone likes it.

It is just that I was hoping that we could potentially get more people (INCLUDING those in favour of number four, AND those with other projects) behind a more widely usuable (and used) API.

[Edited by chrisbazley at 19:42, 11/1/2001]

I agree with your (Mark's) view on no.s 1-3.

It looks like we'll be doing No. 4 then... (Unless the other lot magically appear and cast their votes).

I've already got a plan for a complete 3D engine, but is probably not quite as well thought out as something I could do now. They key thing IMO is to start simple, otherwise it would be too much work. Once the 'simple' bit is done, it might be easier for us to work on the complex bits seperately, e.g. each person writing a different VIS/rendering technique.

As to TF2's release, it should hopefully be sometime this year. Stop by at the TF2 website/forums if you get bored, guaranteed to be off topic/newbie infested all year round

http://www.sierrastudios.com/games/teamfortress

Regards,

Andrew