1C Home   |   Register   |   Today Posts   |   Members   |   UserCP   |   Calendar   |   Search   |   FAQ

Go Back   Official 1C Company forum > 1C Publishing > IL-2 Sturmovik

IL-2 Sturmovik The famous combat flight simulator.

Reply
 
Thread Tools Display Modes
  #1  
Old 10-21-2008, 09:39 PM
K_Freddie K_Freddie is offline
Approved Member
 
Join Date: Feb 2008
Posts: 561
Default BoB in OpenGL or DirectX ??

Maybe some one might know whether the graphics interface for BoB is either one of these (or both), or some new interface.

Thanks
KF
Reply With Quote
  #2  
Old 10-21-2008, 10:58 PM
IceFire IceFire is offline
Approved Member
 
Join Date: Apr 2008
Posts: 1,879
Default

Oleg said OpenGL would be the API of choice. I figure that makes sense anyways. I wonder if they will be going for OpenGL 2.0 or 3.0. Probably 2. Everyone seems to hate 3.0.
__________________
Find my missions and much more at Mission4Today.com
Reply With Quote
  #3  
Old 10-22-2008, 02:11 AM
MaXMhZ MaXMhZ is offline
Member
 
Join Date: Oct 2007
Posts: 46
Default

OpenGL development has been a mess now for several years. It's not that people hate 3.0, 3.0 will most likely be a failure on many fronts. read this article on Tom's hardware.

If it is to be OpenGL, it will probably be 2.0
Reply With Quote
  #4  
Old 10-23-2008, 02:19 PM
KG26_Alpha's Avatar
KG26_Alpha KG26_Alpha is offline
Super Moderator
 
Join Date: Jan 2008
Location: London
Posts: 2,796
Default

BoB SoW

OGL 3.xxx or some variant

At present its >>

2.1

Vid manufacturers are using 2.1

http://www.opengl.org/documentation/current_version/

Also some more info here if you want to explore a bit

http://www.realtech-vr.com/glview/do...on.html#OPENGL
__________________



Last edited by KG26_Alpha; 10-23-2008 at 03:07 PM.
Reply With Quote
  #5  
Old 10-25-2008, 07:33 PM
K_Freddie K_Freddie is offline
Approved Member
 
Join Date: Feb 2008
Posts: 561
Default

Thanks, I'll have a look at this.
Reply With Quote
  #6  
Old 10-25-2008, 07:55 PM
KG26_Alpha's Avatar
KG26_Alpha KG26_Alpha is offline
Super Moderator
 
Join Date: Jan 2008
Location: London
Posts: 2,796
Default

Quote:
Originally Posted by MaXMhZ View Post
OpenGL development has been a mess now for several years. It's not that people hate 3.0, 3.0 will most likely be a failure on many fronts. read this article on Tom's hardware.

If it is to be OpenGL, it will probably be 2.0
Quite the opposite if you read the article fully......From Barthold Lichtenbelt at Nvidia

What happened to Longs Peak?

In January 2008 the ARB decided to change directions. At that point it had become clear that doing Longs Peak, although a great effort, wasn't going to happen. We ran into details that we couldn't resolve cleanly in a timely manner. For example, state objects. The idea there is that of all state is immutable. But when we were deciding where to put some of the sample ops state, we ran into issues. If the alpha test is immutable, is the alpha ref value also? If we do so, what does this mean to a developer? How many (100s?) of objects does a developer need to manage? Should we split sample ops state into more than one object? Those kind of issues were taking a lot of time to decide.

Furthermore, the "opt in" method in Longs Peak to move an existing application forward has its pros and cons. The model of creating another context to write Longs Peak code in is very clean. It'll work great for anyone who doesn't have a large code base that they want to move forward incrementally. I suspect that that is most of the developers that are active in this forum. However, there are a class of developers for which this would have been a, potentially very large, burden. This clearly is a controversial topic, and has its share of proponents and opponents.

While we were discussing this, the clock didn't stop ticking. The OpenGL API *has to* provide access to the latest graphics hardware features. OpenGL wasn't doing that anymore in a timely manner. OpenGL was behind in features. All graphics hardware vendors have been shipping hardware with many more features available than OpenGL was exposing. Yes, vendor specific extensions were and are available to fill the gap, but that is not the same as having a core API including those new features. An API that does not expose hardware capabilities is a dead API.

Thus, prioritization was needed, and we made several decisons.

1) We set a goal of exposing hardware functionality of the latest generations of hardware by this Siggraph. Hence, the OpenGL 3.0 and GLSL 1.30 API you guys all seem to love ;\)

2) We decided on a formal mechanism to remove functionality from the API. We fully realize that the existing API has been around for a long time, has cruft and is inconsistent with its treatment of objects (how many object models are in the OpenGL 3.0 spec? You count). In its shortest form, removing functionality is a two-step process. First, functionality will be marked "deprecated" in the specification. A long list of functionality is already marked deprecated in the OpenGL 3.0 spec. Second, a future revision of the core spec will actually remove the deprecated functionality. After that, the ARB has options. It can decide to do a third step, and fold some of the removed functionality into a profile. Profiles are optional to implement (more below) and its functionality might still be very important to a sub-set of the OpenGL market. Note that we also decided that new functionality does not have to, and will likely not work with, deprecated functionality. That will make the spec easier to write, read and understand, and drivers easier to implement.

3) We decided to provide a way to create a forward-compatible context. That is an OpenGL 3.0 context with all deprecated features removed. Giving you, as a developer, a preview of what a next version of OpenGL might look like. Drivers can take advantage of this, and might be able to optimize certain code paths in the forward-compatible context only. This is described in the WGL_ARB_create_context extension spec.

4) We decided to have a formal way of defining profiles. During the Longs Peak design phase, we ran into disagreement over what features to remove from the API. Longs Peak removed quite a lot of features as you might remember. Not coincidentally, most of those features are marked deprecated in OpenGL 3.0. The disagreements happened because of different market needs. For some markets a feature is essential, and removing it will cause issues, whereas for another market it is not. We discovered we couldn't do one API to serve all. A profile encapsulates functionality needed to meet the needs of a particular market. Conformant OpenGL products may implement one or more profiles. A profile is by definition a subset of the whole core specification. The core OpenGL specification will contain all functionality, including what is in a profile, in a coherently designed whole. Profiles simply enable products for certain markets to not ship functionality that is not relevant to those markets in a well defined way. Only the ARB may define profiles, individual vendors may not (this in contrast to extensions).

5) We will keep working on object model issues. Yes, this work has been put on the back burner to get OpenGL 3.0 done, but we have picked that work up again. One of the early results of this is that we will work on folding object model improvements into the core in a more incremental manner.

6) We decided to provide functionality, where possible, as extensions to OpenGL 2.1. Any OpenGL 3.0 feature that does not require OpenGL 3.0 hardware is also available in extension form to OpenGL 2.1. The idea here is that new functionality on older hardware enables software vendors to provide upgrades to their existing users.

7) We decided that OpenGL is not going to evolve into a general GPU compute API. In the last two years or so compute using a GPU and a CPU has taken off, in fact is exploding. Khronos has recognized this and is on a fast track to define and release OpenCL, the open standard for compute programming. OpenGL and OpenCL will be able to share data, like buffer objects, in an efficient manner.

There are many good ideas in Longs Peak. They are not lost. We would be stupid to ignore it. We spent almost two years on it, and a lot of good stuff was designed. There is a desire to work on object model issues in the ARB, and we recently started doing that again. Did you know that you have no guarantee that if you change properties of a texture or render buffer attached to a framebuffer object that the framebuffer object will actually notice? It has to notice it, otherwise your next rendering command will not work. Each vendor's implementation deals with this case a bit differently. If you throw in multiple contexts in the mix, this becomes an even more interesting issue. The ARB wants to do object model improvements right the first time. We can't afford to do it wrong. At the same time, the ARB will work on exposing new hardware functionality in a timely manner.

I want to ask you to take a deep breath, let this all sink in a bit, and then open up the OpenGL 3.0 and GLSL 1.30 specifications we just posted that have all new stuff clearly marked. Hopefully you'll agree with me that there's quite a lot of new stuff to be excited about.

http://www.opengl.org/registry/doc/g...ithchanges.pdf
http://www.opengl.org/registry/doc/G...ithchanges.pdf

This is certainly not the end of the OpenGL API. OpenGL will evolve and will become better with every new revision. I welcome constructive feedback.

Regards,
Barthold Lichtenbelt
OpenGL ARB Working Group chair
__________________



Last edited by KG26_Alpha; 10-25-2008 at 07:58 PM.
Reply With Quote
  #7  
Old 10-28-2008, 06:46 AM
tritosine tritosine is offline
Junior Member
 
Join Date: Oct 2008
Posts: 6
Default

i heard theres clear path for some "monster expansions" to come for the new GL. Also, AMD Fusion will be in the OpenCL deal, with a Radeon R800 inside the CPU. OpenCL audio is definately nice perspective for games, and personally I poo on DX
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 10:53 AM.

Based on a design by: Miner Skinz.com

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright © 2007 1C Company. All rights reserved.