OpenGL: Основы. (комментарии) (2 стр)

MAMONT-92 [REBORN]
> А вот под паскаль, где можно нормальный глат раздобыть и нормальный огл-юнит?
Под паскаль ты врятли что-то найдёшь...

Pixar
> cNoNim
> Спасибо за совет. Я в общем-то мог бы писать всё функционально, но, во-первых,
> мне надо будет рисовать диаграмму UML,
это зачем?
> а во-вторых, после C# я мыслю почти на
> 100% объектно-ориентированно, то есть, если, допустим, передо мной встаёт
> задача написать загрузчик файла, я представляю его (загрузчик) в качестве
> объекта, у которого есть какие-то свойства, которые позволяют его настраивать,
> и методы, с помощью которых можно выполнять специфичные для данного объекта
> действия. Таким образом, рассматривая какую-либо задачу, я несознательно
> разбиваю её на модули, но тут у меня такая фишка не получается.
ну и плохо что не получается
> Я не могу
> разбить методы по кучкам, разве что отобрать методы взаимодействующие с OpenGL
> и не взаимодействующие с ней, но даже в этом случае не могу представить, чем
> должен быть объект (class COpenGL???).
у тебя вся проблема в том что ты мало работал с OpenGL, когда поднаберешся опыта,
сразу будешь видеть как группируются его функции и даже поймешь почему OpenGL
в принципе довольно таки сильно объектно ориентирован,
на вскидку я тебе могу следующие объектны назвать
Shader, Program, Uniform, Attribute, Buffer, Texture и тд над всем этим стоит Context который все собирает в кучу.
> Подобная же проблема с окошком. В C# есть класс Form, управляя свойствами
> которого можно спокойно создать окно. Тут я не понимаю, каким образом выделить
> информацию, относящуюся к окну, от всего остального.
это тоже от недостатка опыта,
я бы начал с вот примерно вот с такого класса

struct window
{
int width, height;
std::string title;
};

ну а дальше бы плясал от потребностей, еще удобно попробовать написать обертку над какойнить сишной либой,
погляди GLT, объектно ориентированная обертка над GLUT...
> Ещё меня поразил вопрос, который у меня появился насчёт параметров функций:
> зачем они нужны, если существуют глобальные переменные? Также мне не понятно,
> что представляют собой глобальные методы в рамках ООП. То есть, это же не
> свойства объектов? Выходит, что это свойства всего приложения?
> Блин, у меня месиво в голове. Мне надо подумать :)
у тебя ООП головного мозга, попробуй поизучать ченить функциональное, будешь в каждой мелочи видеть функцию

cNoNim
> это зачем?
UML + документация + прога  = курсовая

cNoNim
> Shader, Program, Uniform, Attribute, Buffer, Texture и тд над всем этим стоит
> Context который все собирает в кучу.
cNoNim
> это тоже от недостатка опыта,
> я бы начал с вот примерно вот с такого класса
cNoNim
> у тебя ООП головного мозга, попробуй поизучать ченить функциональное, будешь в
> каждой мелочи видеть функцию
Всё принял во внимание. Учту.

MAMONT-92 [REBORN]
> А вот под паскаль, где можно нормальный глат раздобыть и нормальный огл-юнит?
У FreePascal нормальный, есть и SDL заголовки(jedi проект), насчет opengl.pas просто погугли их валом и самых разных
cNoNim
> cNoNim
Они в своем VS уже держат С99 ? Или как всегда...., я конечно могу ошибаться, но там всегда была ориентация на only С++

RigoN
> Они в своем VS уже держат С99?
нет
а как связано C99 и WinApi?
> я конечно могу ошибаться, но там всегда была ориентация на only С++
где там?
ты не поверишь VS и WinAPI могут разные люди разрабатывать

cNoNim
> cNoNim
Опять немного офтопим...:)
тобой написано; "WinApi - С..."
Вот я и спросил: чем все это собирается?. Ответ -VS

Тогда следующий вопрос, как можно ориентироваться на язык у которого нет нормальной поддержки в компиляторе?
Так что думаю, там С++ ориентация:)

RigoN
в VS есть нормальная ориентация на C89...
в чем проблема то я не пойму?
ты хочешь сказать что WinAPI на C++?
ой не смеши, а...

Мне кажется, что у NeHe написано подробнее.

cNoNim
> ты хочешь сказать что WinAPI на C++?
(не полностью, безусловно там и asm и C и C++) Исходников я не видел, так что это предположение...
если у тебя есть аргументы, поделись...

А каким образом можно обеспечить независимость от графической библиотеки? Нужен класс manager, который будет работать с отдельной библиотекой? Или как это делается?

RigoN
ты чувак меня немного не правильно понял...
с наружи WinAPi - чистый C... что там внутри до одного места,
но и потом. я очень сильно сомневаюсь, что там есть что то на С++
Pixar
от какой графической библиотеки?
ты хочешь совместить DX и GL? так делать в общемто не нужно

cNoNim
> от какой графической библиотеки?
> ты хочешь совместить DX и GL? так делать в общем-то не нужно
Я имею в виду, как, в принципе, обеспечить независимость движка от графической библиотеки?
У меня недавно развилась такая идея. Создаётся класс, в котором оборачиваются функции opengl, DirectX и ещё чего-нибудь (я не буду ничего оборачивать, мне просто важна сама концепция). Этот же класс создаёт форму и производит дополнительную инициализацию, которая только может понадобиться. Дальше класс (вернее объект класса) запускает работу самого приложения (мне пока трудно представить, как...), а само приложение использует внешние (публичные) методы класса, то есть интерфейс, который не изменяется при смене используемой графической библиотеки.
Теперь вопрос. Так ли реализуется всё это на самом деле? Мне просто интересно, чем обеспечивается гибкость (переносимость) реальных систем.
Ещё мне интересно, функция WinMain() заворачивается в класс или она всегда снаружи?

ты не тем занялся, сделай сначала ченить по проще

Pixar
> Ещё мне интересно, функция WinMain() заворачивается в класс или она всегда
> снаружи?
Конечно снаружи...
Этж входная точка приложения...

ezhickovich, Pixar
можно извернуться, но я опять же повторюсь
Pixar
ты не тем занят