> If you can do this, please already take into account what's announced for
> Qt5: Drop of support for OpenGL1.
I wasn't aware of this. I too think there should still be support for
older hardware.
I wouldn't worry about (new) netbooks (or other cheap hardware) not
supporting GL2, though.
The main reason to support GL1 I can see at the moment are some open source
Linux drivers (especially older Radeons not supported by AMD anymore),
and some older Intel GPUs. On Windows Nvidia/AMD front, GL2 support
goes way back.
The open source drivers are improving very fast lately, though.
I'm planning to reimplement existing functionality, and that includes GL1.
My idea is to have the main code in separate classes for each GL version
("Renderer" - or whatever you name it - implementations: GL1Renderer,
GL2Renderer, etc.), while the code that can be shared would
be in classes commonly used by the implementations.
The QGL setup code could be separated into another class
("GLProvider" - implemented by - Qt4GLProvider, Qt5GLProvider?),
which would be used by GL implementations of "Renderer".
The result should be easy to adapt for Qt4/Qt5 builds with
a little conditional compilation (right now, #ifdefs are all over the place).
(I don't know much about where does Qt 5 bring breaking changes -
all I know it's not supposed to be very drastic)
As for maintainability - I think I can write better documented code than
what I see in some places in Stellarium at the moment :) .
(There is a _lot_ of undocumented classes/methods all over the place).
As for developer guidelines - what exactly do you mean?
API docs with examples for users?
(which I plan to do - you can look at my previous projects - linked to before)
Or guidelines for future developers?
I can document the ideas behind the implementation, if that's what you mean.
On 3/28/12, No Idea <[email protected]> wrote:
> As discussed on IRC yesterday, I propose a major OpenGL refactor
> as a project instead.
>
> The goal of this project would be to separate all OpenGL code
> into a separate subsystem consisting of multiple classes.
> Maybe even a separate namespace? (Stellarium doesn't seem
> to use namespaces - should I just put the code into
> a separate directory? - I'd like all "video" code to be in one place)
>
> This would have an implementation-independent API,
> as is common in various game engines,
> so that there could be separate implementations for
> e.g. GL1, GL2, but, in future, it'd be also easy to add
> GL3/4 or GLES. (even a SW renderer or D3D I guess).
>
> Note that I don't propose any new functionality, just a rewrite
> of what's already there. However, it should be easier to
> build on the refactored code, add support for e.g VBOs,
> and also to look for bugs and optimization opportunities.
>
> This weekend, I'll branch the Stellarium repo and experiment
> a little, and send a GSoC application.
>
> (Don't have time right now due to the university.)
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Stellarium-pubdevel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
