Ok, you want to start some sort of coding project. The OpenSim organisation, in my view, should fully support this, by offering start-up advice, clarification and cross-project communication/cooperation.

In your case you clearly want to start a development project. What are your mission statement? What kind of framework? Graphics? Simulation? Full simulation application framework?

Is it part of the eBattlefield project? Then you should go over and join their structures if you haven't done so already. Or maybe you want to start some individual technology development effort?

What is the main purpose? Create a technology? A end-product? Recreational, experimental coding/research?

The idea behind this "Framework" would be that no matter which platform, graphics API (openGL, DirectX) the application and engine ontop of this framework would not have to change. The "Framework" would be interface between the real applications and computer API's... This has to be done in order to make platform independant software.

I just want to help and get this moving so we can have the programmers start "working" on something, even if it has nothing to do with the simulation/ebattlefield project.

They can use our framework, or their own... I'm getting ants in my pants. I wanna start coding, and this is a nice generic thing to do that would help everybody...

For example, Falcon4 has a framework that goes on top of Glide and DirectX... On top of their framework is Falcon4 graphics engine... If you pick Glide or DirectX, Falcon4 looks the same and the actual Falcon4 code does not change... They use this framework as the interface between the graphics API and Falcon4... With ERazor, he removed this framework and had the Falcon4 code use DirectX directly...

>Is anybody working on a platform
>independant framework right now?
>If not, do a few of you C++ developers
>want to start defining one?

Just start coding. There needs to be a volume of work to get things going. Once there is code and libraries of sounds grpahcis etc it can be refactored so that it is compatible into a higher level design.

So if you want to do something just start, when you get it so that it is useable, useful and works, publish it to the Opensim/eBattlefield site and it can grow from there. Later on it will become apparent how it all fits in, but for now we need "stuff". Otherwise we will be pontificating over the design forever.

cam is right, if you're keen to start coding, you should start working.

But you're sounding very ambitious here, talking about a complete framework. It might be a good idea to narrow it down to some smaller area within, if you want to start C++ coding asap. Otherwise you should really be discussing overall design concepts long before starting coding. That said, other than what you've stated in the "Who's in" thread, I don't know your background or skill level, of course.

Also, if you're primarily concerned with doing useful stuff for eBattlefield, you should research what's freely available on the Internet. For example, basic stuff like geometry and math classes, as well OpenGL/DirectX 3D code, terrain code and algorithms etc. are all available in many variants.

On the other hand, maybe you are looking for recreational work, a learning process and want to do this stuff for fun?

Have you had a look at the open source simulators (e.g. Sabre, FlightGear)? Although using code from these is bound by their licences you can still learn from the code. Maybe even contribute to those projects in the process!

Regading abstraction layers, it seems that the concensus over at eBattlefield already is to use OpenGL as a platform independent graphics API. OpenGL exists on all the interesting platforms as far as I know (Win, Linux, Mac). Why introduce another layer?

That said, your idea for abstracted, platform independent simulator framework sounds very similar to AURON Jet. This is a freely available framework (only in beta so far), with a non-commercial free licence model, I think. Check it out. Even if you're out to reinvent, it should give you ideas.

Whatever you choose to do, come back and talk about it! :-)

BTW, are you registered in an eBattlefield team? If not, why not?

Because,
1. it's an OPEN SOURCE project. Why oh why do I have to sign up for anything?

2. it is part of the old/existing eBattlefield structure which needs to be revised for the new merger. Discussion for structure are still valid, as the announcement states that this will be a community effort, ie opening the project to the community.

3. Because the implication (regardless of whether it is meant or not) is that somehow, eBattlefield are in a position to veto someone based on the merits of the application. I abhor this method.

That is "why not"! ;)

Cheers
Teapot

quote:

---

Originally posted by Teapot:
Quote Attila : [b]BTW, are you registered in an eBattlefield team? If not, why not?

Because,
1. it's an OPEN SOURCE project. Why oh why do I have to sign up for anything?

2. it is part of the old/existing eBattlefield structure which needs to be revised for the new merger. Discussion for structure are still valid, as the announcement states that this will be a community effort, ie opening the project to the community.

3. Because the implication (regardless of whether it is meant or not) is that somehow, eBattlefield are in a position to veto someone based on the merits of the application. I abhor this method.

That is "why not"!

Cheers
Teapot

[/B]

---

Organizational changes are taking place Teapot. And for the signing up part there a few good valid reasons. We are putting members into a database that keeps track of your skills, as well as what teams you are a part of. When we begin creating a new and improved website we can use that database to give every member a customized web page that shows important information for the teams you are a part of. In this way members don't have to sort through tons of unrelated stuff to find what they need for the particular project they are working on. There is nobody being turned away that I know of. Anybody can help in someway or another and are welcome at eBattlefield.

Boddman

Come on over and pay no attention to the silly people picketing the parking lot.

If there is OpenGL written into the source application, thats alot of work to be re-written if the API changes. It should be modular, there should be another abstraction layer. Even if OpenGL stays with us for another 5 years, thats great, but there is always a potential to have something change. With sound, since there isn't a standard, we will have to make that abstraction layer anyways...

You should never code for the now when dealing with something that won't be complete for another 2 years. and something that will be used for 5... Look 5 years back, we didn't have 3d cards at all...

Where I work, we call this "coding yourselves into a corner." Where you code so specific, it takes more work to fix the problem than it is to re-write the whole thing from scratch. If you start with it "right", it will be alot easier down the road. My company where I work stuggles with this alot. They always "gotta get something done, quick!" and they start coding by the seat of their pants, then realize they did it wrong. By taking an extra day to figure it out in the beginning would have saved them a weeks worth of work down the road.

I have a strong opinion to add the abstraction layer and allow all kinds of API's. Making this "OpenGL" only could lead to headaches down the road.

I will check out those projects, Attila, I'm kinda out to reinvent the wheel though. I'm not trying to be cocky. I just have the opinion that when you use someone's designs, you inherit their design flaws as well. I'd rather have a nice clean slate, and start from the ground up, coding for this OpenSim/EBattlefield in particular.

Right now, any potential framework I help design wouild be to support multiple platforms, multi-user (maybe even hundreds, or thousands of online people), multiple apis, multiple types of play (plane, heli, ship, awacs, control tower, sam operator, infantry) etc etc etc. Of course this sim specific stuff would not be in the framework, but with that in mind, we can make sure the framework supports it... For example, the framework would handle the networking. If the framework is coded to only support 16 players, then of course, this isn't gonna work for 1000 players. It has to be coded for unlimited amount of people. Then you get into "servers" (with a S) to handle the load, and load balancing, and all this has to be coded into the framework because the server IP's could change on you while playing for load balancing, and that could be independant to the application. The application won't even need to know.

P.S. I've signed up at EBattlefield awhile back. I don't go over there because I don't like the message board... Its too hard to navigate and see whats going on. Here is just a list of topics and replies.

P.P.S. I will start on this myself. I will try to get something going. I just came here looking for help because I'm a DirectX man. I don't want to make this abstraction layer more DirectX specific. I would, of course, try to make it generic, but since I have absolutely no idea how OpenGL works, I could write it in the wrong way unknowingly... I also don't know how Linux works, so it could be more Microsoft Visual C++ specific and it might not even compile on Linux.

I will try and attempt it, since it will be open source, anybody who is familar could grab it and modify and make it work...

If you got any ideas, write them down and create a proposal to submit to eB. Once we get our final organization set up, then we can start working as teams going through submited proposals to create the standards in which to base our project off of. That is how I'm contributing right now.