Allegro x SDL x SFML
435 views
Skip to first unread message
Marcelo Mauro de Oliveira
Apr 30, 2016, 6:22:52 PM4/30/16
to ccppb...@googlegroups.com
Olá pessoal,
Estive lendo estes dias sobre C++ (pois até então só havia usado o C para procedural e Java para POO) e por fim me deparei com as bibliotecas gráficas citadas no cabeçalho deste tópico.
Gostaria da opinião de vocês: a escolha entre elas é mera questão de gosto ou há realmente vantagens no aprendizado de uma delas especificamente?
Todas elas falam da OpenGL como base. (Farei disciplinas sobre esse assunto no futuro) Estariam então OpenGL, DirectX, etc... no mesmo patamar, mas diferente das anteriores?
Obrigado pela atenção!
Marcos Roberto
Apr 30, 2016, 7:29:59 PM4/30/16
to ccppb...@googlegroups.com
Já utilizei as 3. E o que posso lhe dizer é o seguinte:
SFML, é de longe a mais fácil de instalar e sair programando, é muito simples mesmo! Possui funcionalidades como carregar fontes TTF sem maiores problemas. E a única que tem uma API C++ mesmo, orientada a objetos.SDL, é a que irá rodar em qualquer plataforma, no entanto entenda ela como uma camada de abstração dos sistemas de video, audio e entrada. É simples também, no entanto não tem tantas funcionalidades disponíveis no biblioteca padrão, precisando dos auxiliares com SDL_mix, SDL_ttf, etc. Em geral, é uma biblioteca mais baixo nível e é em C.
Allegro5 é o mais completo na minha opinião, só que tem uma forma diferente de trabalhar pois ele utiliza alguns conceitos como streams para eventos, tem uma boa API em C, em geral é um meio termo entre a abstração alta do SFML e a baixa do SDL. Eu recomendo ela, pois possui bastante coisas como funções para filesystem até controles hapticos, entre outras.
--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~------------------------------
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~------------
Fernando Ginez da Silva
Apr 30, 2016, 7:41:31 PM4/30/16
to ccppb...@googlegroups.com
Marcos,
Muito bom o teu resumo de cada biblioteca. Fiquei com uma dúvida quanto ao aspecto multi-plataforma. Na tua experiência, neste quesito de portabilidade, a SFML não é equivalente à SDL?
Um abraço,
_____________________________________________
Fernando Ginez da Silva
Fernando Ginez da Silva
Lucas Nunes
Apr 30, 2016, 9:09:03 PM4/30/16
to ccppbrasil
Apesar de não ser uma biblioteca gráfica no mesmo estilo das citadas, se o objetivo for estudar OpenGL, acho que
vale a pena dar uma olhada na GLFW. É bem simples e fácil de usar e abstrai bastante coisa.
Felipe Magno de Almeida
May 1, 2016, 12:05:37 AM5/1/16
to CcppBrasil
On Apr 30, 2016 7:22 PM, "Marcelo Mauro de Oliveira" <marma...@gmail.com> wrote:
>
> Olá pessoal,
>
> Estive lendo estes dias sobre C++ (pois até então só havia usado o C para procedural e Java para POO) e por fim me deparei com as bibliotecas gráficas citadas no cabeçalho deste tópico.
Allegro me dá saudades de programar em C com DJGPP em 32 bits no DOS pra fazer jogo.
> Gostaria da opinião de vocês: a escolha entre elas é mera questão de gosto ou há realmente vantagens no aprendizado de uma delas especificamente?
>
> Todas elas falam da OpenGL como base. (Farei disciplinas sobre esse assunto no futuro) Estariam então OpenGL, DirectX, etc... no mesmo patamar, mas diferente das anteriores?
>
> Obrigado pela atenção!
>
> --
--
Felipe Magno de Almeida
Wanderley Caloni
May 1, 2016, 1:25:45 AM5/1/16
to ccppbrasil
Quem nunca ficou depurando de madrugada um problema de memória ao carregar o jogo recém-compilado no DOS 32 bits, com o DJGPP se recusando em abrir?
Allegro me faz lembrar de um projeto que participei em equipe de uma versão do Mario. Se chamava Mario Mate o Presidente. Eu até fiz um editor de fases no VB3.
Se você está nessa lista e se lembra disso, dá um ping ae :)
[]s
Allegro me faz lembrar de um projeto que participei em equipe de uma versão do Mario. Se chamava Mario Mate o Presidente. Eu até fiz um editor de fases no VB3.
Se você está nessa lista e se lembra disso, dá um ping ae :)
[]s
angelo
May 1, 2016, 11:22:06 AM5/1/16
to ccppb...@googlegroups.com
VB 3 ? dos 6.0, dos4gw, djgpp... turbo c++, masm etc etc
Pô, das antigas hein ? Só falta ter começado sua vida de programador em um MSX, hehehe
Essa época era boa, modo texto.. ou o cara sabia ou não sabia.. não havia google e nem mimimi.
[]s
-----Mensagem original-----
De: ccppb...@googlegroups.com [mailto:ccppb...@googlegroups.com] Em nome de Wanderley Caloni
Enviada em: domingo, 1 de maio de 2016 02:26
Para: ccppbrasil <ccppb...@googlegroups.com>
Assunto: Re: [ccppbrasil] Allegro x SDL x SFML
Pô, das antigas hein ? Só falta ter começado sua vida de programador em um MSX, hehehe
Essa época era boa, modo texto.. ou o cara sabia ou não sabia.. não havia google e nem mimimi.
[]s
-----Mensagem original-----
De: ccppb...@googlegroups.com [mailto:ccppb...@googlegroups.com] Em nome de Wanderley Caloni
Enviada em: domingo, 1 de maio de 2016 02:26
Para: ccppbrasil <ccppb...@googlegroups.com>
Assunto: Re: [ccppbrasil] Allegro x SDL x SFML
Felipe Magno de Almeida
May 1, 2016, 11:32:31 AM5/1/16
to CcppBrasil
On May 1, 2016 12:22 PM, "angelo" <angelo...@gmail.com> wrote:
>
> VB 3 ? dos 6.0, dos4gw, djgpp... turbo c++, masm etc etc
>
> Pô, das antigas hein ? Só falta ter começado sua vida de programador em um MSX, hehehe
>
> Essa época era boa, modo texto.. ou o cara sabia ou não sabia.. não havia google e nem mimimi.
Foi como eu comecei. Com msx. Mas só basic. Comecei com 7 anos e um livro do meu pai que programava por hobby.
Marcelo Mauro de Oliveira
May 1, 2016, 11:44:57 AM5/1/16
to ccppb...@googlegroups.com
Legal isso, eu comecei a programar tarde... só tive acesso ao meu primeiro computador aos 20 anos... era um Pentium mmx 233Mhz, rodando windows 5 num hd monstro de 8Gb... Programar mesmo tempos depois.
Felippi Crominski
May 1, 2016, 12:51:39 PM5/1/16
to ccppbrasil
Já ouvi falar bem de Alegro, um bixa cura de aprendizado. Até cheguei a brincar com ela vários anos atrás.
Quanto a SDL e SFML, não conheço.
Se não tem problema em ficar restrito ao Windows, e queira algo totalmente orientado a objetos, fazer as coisas "no braço", recomendo DirectX, para um bom aproveitamento, é bom conhecer a OO do C++, como você já conhece OO em java, então você já conhece uma pequena parte do OO em C++, mas ainda tem bastante coisa que o java não tem. Dê uma olhada na STD (standard), e nas funcionalidades adicionadas no C++11 e C++14, de uma olhada também na BOOST que é uma espécie de biblioteca de novas funcionalidades sugeridas para serem adicionadas na STD.
Se você deseja portabilidade, a e complicou, esquece OpenGL, porque como Biblioteca Gráfica, ela fracassou miseravelmente, atualmente nem existe uma biblioteca oficial de OpenGL. Se você deseja programar DIRETAMENTE com a OpenGL, terá que programar até os Shaders. e ainda por cima, orientado a C (procedural).
OpenGL é atualmente um padrão de comunicação entre o hardware e o software. Então se deseja utilizar algo próximo da OpenGL, terá que utilizar uma outra biblioteca por cima da OpenGL.
Na UFMS, a parte prática de CG é utilizando a glut, que oferece várias abstrações para utilizar a OpenGL. No entanto, a mesma teve sua ultima mudança significativa em 1998, além dela ser orientada a C (procedural), não recomendo ela e nem nenhuma outra que venha nesse sentido, pois se refere a uma versão obsoleta da OpenGL. Vale lembrar que a glut só teve uso educacional.
Já trabalhei com o framework QT, que é bem portável, tem uma documentação boa. Ele possui muitas funcionalidades e classes. Mas sempre que um recurso exista na STD, utilize preferencialmente a STD. Com o G++ 6.1, parece que todas funcionalidades de C++11 e C++14 estão finalmente consolidadas no G++( por exemplo, no ubuntu 12 LTS, std::thread não funcionava). Por mais que não seja o mais comum, é possível se aproximar um pouco da OpenGL utilizando QT.
Enfim, cuidado com livros e artigos obsoletos, muitos conceitos mudaram na OpenGL e DirectX, em especial no que cada uma se propõe a fazer.
Quanto a SDL e SFML, não conheço.
Se não tem problema em ficar restrito ao Windows, e queira algo totalmente orientado a objetos, fazer as coisas "no braço", recomendo DirectX, para um bom aproveitamento, é bom conhecer a OO do C++, como você já conhece OO em java, então você já conhece uma pequena parte do OO em C++, mas ainda tem bastante coisa que o java não tem. Dê uma olhada na STD (standard), e nas funcionalidades adicionadas no C++11 e C++14, de uma olhada também na BOOST que é uma espécie de biblioteca de novas funcionalidades sugeridas para serem adicionadas na STD.
Se você deseja portabilidade, a e complicou, esquece OpenGL, porque como Biblioteca Gráfica, ela fracassou miseravelmente, atualmente nem existe uma biblioteca oficial de OpenGL. Se você deseja programar DIRETAMENTE com a OpenGL, terá que programar até os Shaders. e ainda por cima, orientado a C (procedural).
OpenGL é atualmente um padrão de comunicação entre o hardware e o software. Então se deseja utilizar algo próximo da OpenGL, terá que utilizar uma outra biblioteca por cima da OpenGL.
Na UFMS, a parte prática de CG é utilizando a glut, que oferece várias abstrações para utilizar a OpenGL. No entanto, a mesma teve sua ultima mudança significativa em 1998, além dela ser orientada a C (procedural), não recomendo ela e nem nenhuma outra que venha nesse sentido, pois se refere a uma versão obsoleta da OpenGL. Vale lembrar que a glut só teve uso educacional.
Já trabalhei com o framework QT, que é bem portável, tem uma documentação boa. Ele possui muitas funcionalidades e classes. Mas sempre que um recurso exista na STD, utilize preferencialmente a STD. Com o G++ 6.1, parece que todas funcionalidades de C++11 e C++14 estão finalmente consolidadas no G++( por exemplo, no ubuntu 12 LTS, std::thread não funcionava). Por mais que não seja o mais comum, é possível se aproximar um pouco da OpenGL utilizando QT.
Enfim, cuidado com livros e artigos obsoletos, muitos conceitos mudaram na OpenGL e DirectX, em especial no que cada uma se propõe a fazer.
Wanderley Caloni
May 1, 2016, 12:51:39 PM5/1/16
to ccppbrasil
Também comecei tarde. Só consegui por as mãos em um computador pessoal com 17 anos, embora já tivesse feito um curso ou outro aos 14, 15... foi com os livros de computação que comecei meu romance na área. Antes de me aventurar no BASIC (Quick BASIC, aliás [1]) já havia entendido a lógica booleana, binário e a arquitetura Von Neumann bem antes. Mas foi com a noção de que C era a linguagem dos manos que aí me aprofundei mesmo, em flip flops, leiaute de memória, assembly, etc.
A vida era divertida quando os problemas tinham que ser resolvidos na unha. Gastava-se um tempo do cão, mas era divertido. Hoje o tempo economizado no Stack Overflow também é útil, já que sobra mais tempo para resolver problemas mais difíceis.
Thiago Adams
May 1, 2016, 1:42:07 PM5/1/16
to ccppb...@googlegroups.com
Eu também comecei no MSX. Era da gradiente, comprado de segunda mão sem driver por 100 dolares.
Escrevia o programa em basic conforme os comandos descritos no livro que acompanhava o MSX. Achava que basic e assembly era a mesma coisa, já que vinha dentro do computador.
No início fazia os programas e depois copiava tudo para o papel, pois nunca consegui gravar o programa na fita cassete.
Devido a esta dificuldade arranjei com meus pais mais 100 dolares para comprar um driver de disquete 5 1/4 também de segunda mão.
Então podia fazer um programa de computador e gravar em um disquete. Que coisa legal? Já pensou? Ter uma máquina (computador) que se pode programar e isso fica dentro de um disquinho magnético? Era só ligar na tv da sala, e arranjar um modo de ficar confortável. Depois ganhei um TV 14 polegadas falsificada que havido sido comprada em um consorcio pelo minha mãe e esta TV ficou de monitor. Que maravilha! Era uma máquina toda pronta em uma mesa só para isso! Eu devia ter uns 15 anos.
Mas tinha algo errado. Por que os jogos em MSX eram rápidos e meus programas eram lentos? Quem será que poderia me dar esta explicação? Fui no pirata de jogos local e expliquei a situação. Ele me disse que então eu teria que programar em assembly. Mas tinha também o turbo pascal. Sai de lá com o disquete do turbo pascal 3. Agora faltava a documentação. Depois de um dias busquei nas livrarias da cidade e tinha um livro que dizia exatamente o que eu precisava. "turbo pascal 3" IBM pc. Era para PC, mas mesmo assim eu comprei e deu certo.
Aprendi que para sair do editor daquela "coisa"era só apertar control k d. O livro já tinha se pago por me dar esta combinação mágica.
Assim entendi a procudure o if while etc.
O capítulo MSX passou quando comprei um Amiga.
A moral da história sabe qual é, pegando a frase do caloni?
>A vida era divertida quando os problemas tinham que ser resolvidos na >unha. Gastava-se um tempo do cão, mas era divertido.
A vida era muito divertida mesmo! Eu me divertiria se só tivesse um MSX mesmo nos dias atuais.
Ano passado me diverti com arduino. Não importa a máquina.
Rafael Silva
May 1, 2016, 11:10:52 PM5/1/16
to ccppb...@googlegroups.com
Estou achando estranho não terem pipocado nomes como Vulkan e Openframeworks.
Acho que o Vulkan vai substituir do OpenGL. O DirectX ainda é o rei na área de jogos e a Apple resolveu criar a API dela (Metal).
Boa sorte, espero que você manje muito de álgebra, se quiser posso indicar um livro bom de math, mas em inglês.
Eu sou jr comparado a vocês, comecei num 486, larguei e voltei.
Obs: DOS FDP NUNCA TINHA MEMÓRIA BÁSICA PRA JOGAR!!!!!!!! E a memória high não servia pra rodar nada...
Att.
Felippi Crominski
May 1, 2016, 11:26:17 PM5/1/16
to ccppb...@googlegroups.com
Ao que me parece, Vulkan é só um novo nome para uma nova versão da OpenGL, me parece puramente marketing. Infelizmente a Khronos fez muita escolha errada, e ferrou de vez a OpenGL com biblioteca gráfica.
Thiago Sonego Goulart
May 2, 2016, 3:17:34 AM5/2/16
to ccppb...@googlegroups.com
Felippi, eu recomendo que tu tome mais cuidado antes de compartilhar informações incorretas. Nada pessoal, mas me permita corrigir os pontos incorretos que são relevantes ao tópico original:
- DirectX, assim como todas as outras bibliotecas gráficas de baixo nível, não tem absolutamente nenhuma relação com OO ou C++.
- Se portabilidade é importante, OpenGL é disparada a biblioteca com maior suporte em diferentes sistemas. Porém, no mundo real, quem desenvolve um produto deve decidir em quais plataformas ele vai rodar e isso afeta quais bibliotecas gráficas precisam ser suportadas (muitas vezes mais de uma!).
- OpenGL não é "um padrão de comunicação", é simplesmente uma biblioteca gráfica escrita em C. Se tu quer utilizar OpenGL, tudo que tu precisa fazer é incluir os headers e linkar corretamente. Existem outros problemas de runtime que eu vou mencionar mais abaixo.
- Vulkan não é uma nova versão da OpenGL, é uma biblioteca completamente nova, criada em conjunto por várias empresas, cujo objetivo é expor as capacidades da GPU de forma mais explícita. Vocês podem considerar OpenGL "baixo nível", mas ela abstrai bastante o modo como uma GPU funciona, e isso é um problema pra aplicações que utilizam a GPU ao extremo[1].
Além disso, percebi uma certa confusão entre os conceitos de biblioteca e abstração, então vou vou tentar esclarecer um pouco.
Existem algumas bibliotecas gráficas de baixo nível que dão acesso ao hardware: OpenGL, OpenGL ES, DirectX, Metal, Vulkan e Mantle, entre outras. No início dos tempos, OpenGL e DirectX ambas eram "fixed-function"[2], onde a API expõe conceitos como câmeras, luzes, matrizes, transformações lineares, etc. Devido à pouca flexibilidade, ambas eventualmente se tornaram "programmable", onde agora também precisamos escrever shaders (programas que rodam dentro da GPU), e com isso a biblioteca não precisa mais saber da existência de câmeras e outros conceitos que só existem no nível da aplicação. Metal, Vulkan e similares são novas bibliotecas que continuam a expandir a ideia de programabilidade, mas que buscam diminuir a complexidade dos drivers que as implementam; é simplesmente um trade-off entre performance e simplicidade de código (ao nível de aplicação).
Escrever um "Hello World" em OpenGL pra um sistema operacional específico sem nenhuma dependência envolve, entre outros detalhes, definir o "contexto", criar uma janela, tratar eventos de teclado e/ou mouse, criar uma cena (modelos 3D, texturas, iluminação, ...) e gerenciar frames. Se não está óbvio, são centenas de linhas de código nada triviais, e que são específicas pra uma única plataforma! Pra simplificar o desenvolvimento de aplicações gráficas, existem bibliotecas por aí que buscam abstrair essas tarefas, e finalmente chegamos ao tópico dessa thread. Não vou falar sobre elas especificamente pois as únicas que já mexi foram SDL e GLFW, mas a ideia é que todas elas resolvem um subconjunto (potencialmente diferente) desses problemas que listei. Qual utilizar vai depender do nível de abstração que tu quer trabalhar (mais abstração => menos flexibilidade e performance).
Agora que estamos todos mais alinhados, estou à disposição pra responder perguntas mais específicas. E por favor, já existe muita informação ruim sobre bibliotecas gráficas (especialmente OpenGL) na internet, vamos tentar não agravar esse problema.
--
Thiago Sonego Goulart
Adriano dos Santos Fernandes
May 2, 2016, 7:40:12 AM5/2/16
to ccppb...@googlegroups.com
On 01/05/2016 02:25, Wanderley Caloni wrote:
> Quem nunca ficou depurando de madrugada um problema de memória ao carregar o jogo recém-compilado no DOS 32 bits, com o DJGPP se recusando em abrir?
Depurando com printf's...
> Quem nunca ficou depurando de madrugada um problema de memória ao carregar o jogo recém-compilado no DOS 32 bits, com o DJGPP se recusando em abrir?
> Allegro me faz lembrar de um projeto que participei em equipe de uma versão do Mario. Se chamava Mario Mate o Presidente. Eu até fiz um editor de fases no VB3.
> Se você está nessa lista e se lembra disso, dá um ping ae :)
Antes era com o Borland C/C++ 16 bits.
Nessa época a Allegro era apenas pra DOS. Depois deixaram
multiplataforma com suporte a OpenGL no Linux e DirectX no Windows, se
não me engano.
Adriano
PS: Eu costumava abrir os arquivos .exe dos jogos em editor de texto pra
ver que compilador eles usavam e nessa época só dava Watcom C++.
Felippi Crominski
May 2, 2016, 9:21:34 AM5/2/16
to ccppb...@googlegroups.com
Thiago, quando me refiro a parte OO, estou me referindo a forma como se manipula a maioria das funcionalidades da "biblioteca" diretamente. Você mesmo disse, "a OpenGL foi escrita em C"...
De fato, se tem objetivos de se utilizar Linux e plataformas embarcadas, terá que utilizar alguma biblioteca que se comunique com o hardware utilizando o padrão definido pelo consórcio Khronos (Utilizar o padrão OpenGL). Nesse cenário, não há nenhum concorrente a altura.
Você conhece algum link com uma implementação oficial da "biblioteca" OpenGL pura(não fazendo parte de um conjunto de outras ferramentas com o QT), atualizada( versão 4.*), e que seja "homologada" pela Khronos?
"(...)é uma biblioteca completamente nova, criada em conjunto por várias empresas, cujo objetivo é expor as capacidades da GPU de forma mais explícita", essa é a descrição exata do que é a atual OpenGL. O conjunto de empresas que você citou, é o consórcio Khronos. Expor a GPU de forma mais explicita, é justamente oque a OpenGL 4.* tem feito.
De fato, ainda sou muito ignorante em relação a Vulkan, mas ME PARECE(volto a frisar esse termo) que conceitualmente, é uma nova versão da OpenGL, em que se deseja abandonar de vez o suporte a diversas funcionalidades que a tempos são deprecated na OpenGL. Mas não me parece algo totalmente novo. Gostaria de estar enganado...
Há vários anos atrás, era possível criar uma janela e desenhar algo simples (uma reta por exemplo), utilizando apenas a OpenGL "oficial" e "atualizada", e isso era possível com menos de 200 linhas de código. Além disso, funcionaria no Linux e no Windows.
Leia um pouco da história da OpenGL, dos rumos tomados depois que a mesma passou a ser controlada pela Khronos, é muito interessante.
De fato, se tem objetivos de se utilizar Linux e plataformas embarcadas, terá que utilizar alguma biblioteca que se comunique com o hardware utilizando o padrão definido pelo consórcio Khronos (Utilizar o padrão OpenGL). Nesse cenário, não há nenhum concorrente a altura.
Você conhece algum link com uma implementação oficial da "biblioteca" OpenGL pura(não fazendo parte de um conjunto de outras ferramentas com o QT), atualizada( versão 4.*), e que seja "homologada" pela Khronos?
"(...)é uma biblioteca completamente nova, criada em conjunto por várias empresas, cujo objetivo é expor as capacidades da GPU de forma mais explícita", essa é a descrição exata do que é a atual OpenGL. O conjunto de empresas que você citou, é o consórcio Khronos. Expor a GPU de forma mais explicita, é justamente oque a OpenGL 4.* tem feito.
De fato, ainda sou muito ignorante em relação a Vulkan, mas ME PARECE(volto a frisar esse termo) que conceitualmente, é uma nova versão da OpenGL, em que se deseja abandonar de vez o suporte a diversas funcionalidades que a tempos são deprecated na OpenGL. Mas não me parece algo totalmente novo. Gostaria de estar enganado...
Há vários anos atrás, era possível criar uma janela e desenhar algo simples (uma reta por exemplo), utilizando apenas a OpenGL "oficial" e "atualizada", e isso era possível com menos de 200 linhas de código. Além disso, funcionaria no Linux e no Windows.
Leia um pouco da história da OpenGL, dos rumos tomados depois que a mesma passou a ser controlada pela Khronos, é muito interessante.
Por fim, uma grande quantidade de jogos de alto desempenho(um exemplo são os jogos da Valve), quando querem portabilidade em Linux e Windows, costumam fazer trabalho dobrado, fazem tanto em DirectX quanto em OpenGL. Porque será que essas empresas não fazem apenas em OpenGL?
Vinícius dos Santos Oliveira
May 2, 2016, 9:28:05 AM5/2/16
to ccppbrasil
Em 2 de maio de 2016 10:21, Felippi Crominski <feli...@gmail.com> escreveu:
Você conhece algum link com uma implementação oficial da "biblioteca" OpenGL pura(não fazendo parte de um conjunto de outras ferramentas com o QT), atualizada( versão 4.*), e que seja "homologada" pela Khronos?
Essa frase soa tão estranha para mim.
Você conhece algum link com uma implementação oficial da "linguagem" C++, pura (não fazendo parte de um sistema operacional e outras ferramentas), atualizada (versão C++14), e que seja "homologada" pela ISO?
Felippi Crominski
May 2, 2016, 10:37:46 AM5/2/16
to ccppb...@googlegroups.com
Vinicius, sim, minha pergunta não foi muito bem formulada. Já que vc perguntou sobre C++14 http://en.cppreference.com/w/cpp/compiler_support, além disso, segue o site oficial da linguagem C++ isocpp.org, C++ não é uma implementação, é uma definição de linguagem. De forma análoga me refiro a OpenGL como uma definição de comunicação de hardware e software, e não uma biblioteca gráfica propriamente dita. Mas na verdade isso são apenas conceitos.
MEU conceito de biblioteca(obs: a frase não é minha): "Coleção ordenada de código de programas e rotinas, a que um programador pode recorrer para desenvolver outros programas."
Agora de você assetar que a definição de comunicação (usualmente, definição de funções), e não a implementação em si seja uma biblioteca, então OpenGL é uma biblioteca gráfica.
MEU conceito de biblioteca(obs: a frase não é minha): "Coleção ordenada de código de programas e rotinas, a que um programador pode recorrer para desenvolver outros programas."
Agora de você assetar que a definição de comunicação (usualmente, definição de funções), e não a implementação em si seja uma biblioteca, então OpenGL é uma biblioteca gráfica.
--
Thiago Sonego Goulart
May 2, 2016, 3:41:56 PM5/2/16
to ccppb...@googlegroups.com
Felippi, volto a insistir que tu tome mais cuidado antes de responder. Ao compartilhar opiniões fantasiadas de informação, tu está prejudicando o aprendizado de pessoas que tem menos conhecimento que tu.
OpenGL é uma biblioteca, independente de como tu prefira chamar. Khronos é responsável por definir a API, e implementações são distribuídas de diferentes formas. A Mesa[1] é uma implementação em software da biblioteca. Implementações em hardware são disponibilizadas na forma de drivers, ou como parte do sistema operacional (iOS e OS X, por exemplo).
Quanto a Vulkan, pode ficar feliz pois tu está completamente enganado. É bastante claro pra mim que tu não acompanha de perto a evolução das bibliotecas, mas mesmo assim insiste em fazer afirmações baseadas em opiniões. Uma simples busca no google pode te ajudar a entender melhor as mudanças[2], assumindo que tu consiga compreender o impacto de cada uma delas. Spoiler alert: o impacto é gigantesco pra quem tem aplicações gráficas onde o gargalo é CPU devido ao overhead do driver que implementa a biblioteca.
Eu conheço relativamente bem a evolução da biblioteca, mas a explicação desse cara aqui [3] é uma ótima referência. Utilizar ambos Direct3D e OpenGL vem do tempo em que os drivers/versões de OpenGL disponíveis eram ridiculamente inferiores, mas ainda assim era desejável ter um produto que rodasse em múltiplas plataformas. E também existe um componente de marketing em tudo isso: eu trabalho em uma empresa que faz jogos pra iOS e Android, e nosso backend é OpenGL. Quando chegou a hora de lançar nosso último jogo, nosso time de marketing entrou em contato com a Apple pra que o jogo aparecesse na página inicial da AppStore e assim conseguir mais instalações. Um dos pedidos da Apple foi que usássemos Metal ao invés de OpenGL. A Microsoft faz acordos similares com desenvolvedores mundo afora.
--
Thiago Sonego Goulart
Felippi Crominski
May 2, 2016, 6:46:53 PM5/2/16
to ccppb...@googlegroups.com
Thiago, trecho inicial de um link seu:
"Vulkan is a new API for hardware-accelerated graphics (and general computation) via traditional GPUs. OpenGL will continue to be developed, as it is a higher-level API than Vulkan is intended to be. Originally referred to "glNext," one can infer that Vulkan was likely going to end up being "OpenGL 5," but that the standards body eventually decided that a new name would better coincide with the relatively clean break the API purports to make from existing OpenGL paradigms."
A priori(hoje, isso não é mais verdade), a adoção de um novo nome foi principalmente para eliminar muita coisa obsoleta, e poder remodelar muitas funcionalidades, mais algo ainda como um OpenGL 5.
Hoje pesquisei mais e realmente muita coisa mudou desde o inicio conceitual da Vulkan, eu estava bem desatualizado em relação a mesma. O Lunar Xchange, reflete uma mudança significativa de paradigma, muito positiva por sinal. Pena que Vulkan's continua bastante C-like. Mas entendo que no que se propõe, utilizar OO nesse nível, seria um gargalo desnecessário. Bastante coisa será reaproveitada da OpenGL 4.5, e pelo visto, muita coisa do Mantle também. E com o conceito de diferentes níveis de proximidade com o hardware, pode ajudar na curva de aprendizado.
"Vulkan is a new API for hardware-accelerated graphics (and general computation) via traditional GPUs. OpenGL will continue to be developed, as it is a higher-level API than Vulkan is intended to be. Originally referred to "glNext," one can infer that Vulkan was likely going to end up being "OpenGL 5," but that the standards body eventually decided that a new name would better coincide with the relatively clean break the API purports to make from existing OpenGL paradigms."
A priori(hoje, isso não é mais verdade), a adoção de um novo nome foi principalmente para eliminar muita coisa obsoleta, e poder remodelar muitas funcionalidades, mais algo ainda como um OpenGL 5.
Hoje pesquisei mais e realmente muita coisa mudou desde o inicio conceitual da Vulkan, eu estava bem desatualizado em relação a mesma. O Lunar Xchange, reflete uma mudança significativa de paradigma, muito positiva por sinal. Pena que Vulkan's continua bastante C-like. Mas entendo que no que se propõe, utilizar OO nesse nível, seria um gargalo desnecessário. Bastante coisa será reaproveitada da OpenGL 4.5, e pelo visto, muita coisa do Mantle também. E com o conceito de diferentes níveis de proximidade com o hardware, pode ajudar na curva de aprendizado.
Reply all
Reply to author
Forward
0 new messages