I shall instead base my next project around the Omega API, and release it with a substitute OpenGL module that fills in the gaps for people without 3D hardware.

Hmm, luckily most of it's about Mark's post

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.

That's the problem. It's 'soon' and not 'now'. We don't even know if Microdigital will even implement a software API. If they do, then bob's your aunt. If not, then we're still at square one.

Without details on the API, us writing a software version would be impossible, and nobody wants to wait for a 3D engine.

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.

I think the main problem here is the API. Number 4 solves that problem by doing away with it completely, so may be a temporary solution. Alternatively, once the Omega API is complete our engine could be modified to link up with the Omega API, solving everyones problems. I vote No. 4

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.

That's the problem. It's 'soon' and not 'now'. We don't even know if Microdigital will even implement a software API. If they do, then bob's your aunt. If not, then we're still at square one.

Without details on the API, us writing a software version would be impossible, and nobody wants to wait for a 3D engine.

I'll keep this one short this time...

As I've said, feel free to do this. (Ignoring the potential benefits of hardware graphics acceleration with Omega, presumably)

Solved in the post above this (Presuming no-one else has got in the way)

I shall instead base my next project around the Omega API, and release it with a substitute OpenGL module that fills in the gaps for people without 3D hardware.

Good luck!

Arg! Anothet post! (Goes to check email...)

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

As to TF2's release, it should hopefully be sometime this year.

More than a little bit off-topic for these forums, but this seems like a good opportunity for me to pimp UKFortress, a rather good UK-orientated Team Fortress 1.5/2 website that I also happen to run .

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!

It certainly seems that way. If we go along with the plan of, "Do it yourself", we will be back to square one because that's been the consensus for the past 10 years and look where it's got us.

We need to work together but we need an agreement (i can't vote as my simple mind doesn't have a clue) and also a decent list of people and what they are going to do. The worst scenario that can often happen is everyone starts working together and eventually one person finds themselves doing everything. I don't want this to happen.

I will take Rich's suggestion of hosting the web-site with him but I am NOT going to setup a web-site if nothing is going further than disagreement.

Teamwork guys, teamwork.

It certainly seems that way. If we go along with the plan of, "Do it yourself", we will be back to square one because that's been the consensus for the past 10 years and look where it's got us.

It got us surprisingly far (Star Fighter 3000, Drifter, Brutal Horse Power), but I agree that it is time to stop writing individual graphics renderers and start cooperating.

Teamwork guys, teamwork.

The Ambitious 3D Engine project requires *explicit* dedication and teamwork. The software graphics renderer project would *implicitly* generate teamwork, if organised well.

I would also like to throw in one final point which seems to have escaped my notice. How often is it that people have to ditch their old games because they don't work on a new OS/CPU? For this reason, the more code that is shared between many programs (ie in modules), the easier it is for a dwindling number of programmers to maintain old applications.

Consider all the old programs which were fixed for StrongARM by the judicious replacement of the music player module used.

Since it is likely that a software renderer module would need to be in ARM code to be fast enough, and it is likely that the code calling it would be in C (already 32-bit safe), programs could be made 32-bit safe just by updating the renderer.

In other words, the amount of hand-coded ARM code inside games would be reduced.

[Edited by chrisbazley at 21:36, 11/1/2001]

It got us surprisingly far (Star Fighter 3000, Drifter, Brutal Horse Power), but I agree that it is time to stop writing individual graphics renderers and start cooperating.

Teamwork guys, teamwork.

StarFighter and SR and Chocks Away were done by the same crew who left. Drifter, I was told, isn't proper 3D and BHP was using that god awful TAG engine.

Fednet and Andrew Docking never released their 3D code so noone could do anything with it, anyway it's protected by legalities. TAG was to a few but it's naff.

In 10 years, there's hardly a lot to show for it.

This post is probably going to sound somewhat harsh but I don't mean to offend anyone on here.

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.

Given that you'd hope Omega would appear in the time it would take to write a decent engine I don't see the problem with changing SWI numbers. If you write to an API spec then parameters CAN'T change. That's the point of a spec.

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.

The reasons I'm asking these questions is because I'm not convinced that there's anyone here who could achieve what has been proposed.

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

So far I've provided

discussion
full source code to a basic event driven 3D engine
full source code to a rasterisation API
full source code to a simple dynamic linker
source code to a scanline polygon plotter
a multitude of references to useful information sources

I can't help it if people ignore these. I wouldn't say any of the above are great but they may provide a starting point / useful code.

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

Then you're not creating OpenGL. OpenGL isn't an API to convert, it's a specification to implement. The fact that there are open source versions available means you have reference points. OpenGL isn't tied to a system. It doesn't specified how you implement it just what it must do.

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

Why would FP go? In fact even if I were to write a MiniGL driver I'd implement the FP interface and convert to fixed point underneath if necessary. I can't see how you can state that PC games wouldn't work with it. Do people have any idea of just how few of OpenGLs features something like Quake 3 actually uses?

There is no OpenGL "source", just different implementations of the API.

There is the open source Silicon Graphics reference code. There is Mesa, there is the Palm Pilot MiniGL driver.

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.

You also benefit from the multitude of documentation and experience that's readily available. For example the two OpenGL bibles, programmers and reference guide are both available on the web for free.

Again OpenGL ISN'T an engine. The engine will be unique in the way that Unreal isn't Quake isn't Totality.....

They key thing IMO is to start simple, otherwise it would be too much work.

The point about a state driven API (such as OpenGL, Direct3D, anything we come up with) is that you can distribute a version of the API that only does, say, flat polygons and implement the other states transparently. Features will then just "work" in client code.

Right ok having got that off my chest I'll repeat one thing and then make a proposal...

Any 3D engine is, at some point, going to have to sit on facilities like those provided by OpenGL. OpenGL is not the engine, it's low level 3D utility functions. The more the API does the less work it is to create an engine but there are limits to API complexity and decreasing performance.

There is resistance to the idea of OpenGL because people don't know it. Well people won't know anything else we come up with so that argument is invalid. OpenGL has the advantage that it is fully documented already and that reference source code exists.

Alternatively we spec our own API. I have ideas for this, how it would work, how an application would interface to it etc etc. I would be willing to put together a document outlining the proposal and explaining some of the technical details over the next week (bear in mind that this in itself is a large task) to provide a reference for future discussion.

However if I am to do this may I please ask that people go and look at some OpenGL resources to get a feel for it (because what I would propose isn't all that far removed). I suggest starting at

http://heron.cc.ukans.edu/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_PG/%40Generic__BookTocView/7109;cd=7;td=6

and looking at

chapter 1 Introduction to OpenGL up to OpenGL as a State Machine

chapter 2 the section OpenGL Geometric Drawing Primitive and also Vertex Arrays Steps 1 and 2

unfortunately the PDF version seems to have disappeared. I have copy but it's a 6MB zip file.

BTW of all these the section on vertex arrays is the most important for what I have in mind.

.... except that this forum doesn't support file enclosures. Also you lot got in contact with me about XSpr, I responded, and what happened? Nowt.

Drifter, I was told, isn't proper 3D

Responding to Lee's last post:
Is the scan-line polygon plotter code the assembler code from the warp/OS/G 3d engine you sent me a few months back?

No, it's different. It uses an active edge table to ensure there is no overdraw. I never got round to writing an assembler version because it's very complicated. The OS/G code I sent you is probably newer because I started it sometime after Acorn Computing closed down.

Drifter, I was told, isn't proper 3D

You want to be careful with these 'proper 3D' types, next they'll have you convinced that the polygons in Half-life actually *are* sticking out of the screen at you... ;-)

hehe, just no Head-Crabs jumping out from the screen please

Getting back to the topic ... what Lee was saying about OpenGL reasons it a bit more, If we used OpenGL within the 3D engine to speed up development then this is probably the way to go, and use OpenGL, but what we dont want to do, and which I think might have been misintepreted (which could explain the negativilty to OpenGL) by some people is that you would either create an engine, or port an API.
With the development of this project, i think its now going to be most important if everyone who is wanting/are involved with this to have a meeting on IRC (or some other chat application) so that we can discuss how this engine is going to be implemented, and what are the plans for it.
Someone decide when is convienent, and what app to use for this please
Last Point: 3D sound - how the hell does this work??? - is it just a matter of a few algorythms which stick the "sound" in a 360 degree enviroment, and then converted to stereo channels & pumped out of the soundcard (m000 why couldnt the RPC have Four speaker support ), or is it more complicated than this??
I can imagine that this would be one thing that many people would automatically expect in a game, so perhaps in the later stages of this API and Engine some kind of sound support should be included, along with a similar technology to Creatives EAX, which is relatively simple in that it just adds predefined sound effects to the sound in relation to the environment, but can give some fantastic effects.
Right, ill be back in a few hours - im just gonna play around with the destiny demo & see what went wrong

Drifter, I was told, isn't proper 3D

You want to be careful with these 'proper 3D' types, next they'll have you convinced that the polygons in Half-life actually *are* sticking out of the screen at you... ;-)

hehe, just no Head-Crabs jumping out from the screen please

Getting back to the topic ... what Lee was saying about OpenGL reasons it a bit more, If we used OpenGL within the 3D engine to speed up development then this is probably the way to go, and use OpenGL, but what we dont want to do, and which I think might have been misintepreted (which could explain the negativilty to OpenGL) by some people is that you would either create an engine, or port an API.
With the development of this project, i think its now going to be most important if everyone who is wanting/are involved with this to have a meeting on IRC (or some other chat application) so that we can discuss how this engine is going to be implemented, and what are the plans for it.
Someone decide when is convienent, and what app to use for this please
Last Point: 3D sound - how the hell does this work??? - is it just a matter of a few algorythms which stick the "sound" in a 360 degree enviroment, and then converted to stereo channels & pumped out of the soundcard (m000 why couldnt the RPC have Four speaker support ), or is it more complicated than this??
I can imagine that this would be one thing that many people would automatically expect in a game, so perhaps in the later stages of this API and Engine some kind of sound support should be included, along with a similar technology to Creatives EAX, which is relatively simple in that it just adds predefined sound effects to the sound in relation to the environment, but can give some fantastic effects.
Right, ill be back in a few hours - im just gonna play around with the destiny demo & see what went wrong

Seriously I know you're interested in that side of things. What I would say is that any sound module / API is separate to a rendering engine. I would expect it to be implemented as a separate module. This is not to say it shouldn't be done if possible.

However this is an area that is still developing in the Windows and Linux worlds and I personally don't have much experience of it. The thing to keep an eye on is OpenAL - not necessarily to port but to get a feel for what it can do as it (along with OpenGL and some other stuff) are the basis of the Indrema SDK (Software Development Kit) and will probably be quite influential.

Finally I'll ask again, do people want me to write the document I suggested in a previous post. If so let me know. If no one says anything I won't bother.

I'll look at that OpenGL manual thingy.

Other things related to the 3D effort are happening away from the forum, such as setting up the website.

Perhaps if we had a much simpler vote:

1. I tell you lot what we are going to do
2. You try and have a nice democratic discussion on what would be best

Try and make your descisions clear, and leave all other discussions until I've counted the votes. I would advise reading that OpenGL thing before making a descision though.

The people I'm looking for in the vote (Although there may be a few I've forgot) are me, Nathan, Andrew, Chris, Mark, and Lee. We need to wait until this main core have replied otherwise someone is bound to be unhappy.

This doesn't seem to be working, and I'm not sure what I can do about it.

What do you want to do about it?

2. You try and have a nice democratic discussion on what would be best

This gets my vote for several reasons, not least that I've been burnt before in projects where the organiser "told" us what to do and then I watched as the project died (after considerable effort was put in) as problems cropped up for the organiser.

Hope this helps,

Andrew

I've already said a couple of times what I would and could do i.e. assembler parts that I'd be learning as I was doing it.
Nathan and myself would require this to be a VOTI project (for reasons also stated).

Well, it doesn't have to be a VOTI project as such but credit should be given.

Mainly it's because you're not likely to easily find a better coordinator that Nathan.

Thanks. Although I don't often make my head swell, what I would say in my favour is that I have had a long few years in the RISC OS behind-the-scenes activities. I have seen what can happen, the signals when something turns sour and people to avoid. I also have a list of useful contacts.

Mark has offerred to test software and develop graphics when necessary.
Chris, I believe is working on anothe project.
Lee is very busy and all his computer time I undestand is taken up mainly with VOTI-associated work.

I don't know if I can vote as I can't program so I wouldn't know the route to go for, I am a mere simpleton

I will go with whatever the majority.

This doesn't seem to be working, and I'm not sure what I can do about it.

What do you want to do about it?

I want us to come to a descision as to what we're actually doing. Once that's been done we can get down to doing it.

Do I take it then that the votes have been given (Since Andrew has accounted for everyone), or do you think they'll disagree with a democratic discussion?

Also I've gotten through the 1st chapter of that OpenGL thing, and my view is that OpenGL is fine, especially if we were to start with some of readily available code, then optimise it bit by bit.

This would also work with teamwork, since we could give each person a handful of files to optimise as they see fit.

In case I have begun to mislead anybody I don't think I'd be prepared to learn OpenGl either, simply to work and learn to do relevant assembler routines given a plan of action and coordination towards a goal.

I don't think you'd have to learn it. Don't take this the wrong way but I don't think you're the best person to implement an OpenGL framework because your skills lie elsewhere.

It seems to be that we're starting to figure out what people really want to do now. It seems to me that Jeff wants to design / build an engine, Andrew will help with ARM optimisation and I'm the one really advocating the OpenGL route. With this mind does it seem sensible that Jeff fleshes out his engine ideas with the assumption that an OpenGL module is available and I look at getting a MiniGL driver up and running? Andrew waits in the wings for someone to go "optimise this"

If so then I'd also say the following. Jeff should assume the presence of the Begin / End paradigm and vertex arrays but not display lists for the time being. Also assume that anything that isn't immediately useful to a game (all those variations on drawing lines for example) aren't available.

Before we make a final decision I want to throw one more spanner in the works. Although I advocate OpenGL from a standards point of view there are a few issues that other people here might not want to live with. Do people want me to discuss these before we all start hacking code or do people want to remain blissfully ignorant? If people are happy to live with it whatever it entails then that's that. Otherwise I'll describe the issues and propose some "extensions" to address them.
I really would have to write a document for that though as it'll be too big to go on here.

Democratic discussion is all very well and good, but it can sometimes mean that nothing gets done. I personally prefer 1 person who knows what they are talking about dictating (Jeffrey, Chris ?) but taking into account the views of other people (hey, that's what management is all about :-), but as Nathan said, this does lead to people falling out quite often...

First thing to do I would imagine is agree on a spec before we even think about starting to code. I got a bit lost here, have we finally decided to implement OpenGL ? Or go another route ?

2) The web-site domain has been bought. It will use the code used in AA and Iconbar but not sure who will manage the initial site as I don't have a clue about CGI and web-based programs such as discussion boards.
I also don't believe this site should be designed to look nice. This wastes time, I believe it should be easy to use and functional. Graphics can be done by Ramuh and Mark.
I am unclear whether Tim/Richard have the time to do the site, I am happy to do it all provided I have the assistance with respect to the forum code etc.

3) Next plan is to get the specs up there and a discussion about it. Then finalise it.

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

5) I'll then ask my contacts who is available for advice and they can check the boards for this.

6) Coding begins.

Any problems?