O que há de Novo?
Fórum Outer Space - O maior fórum de games do Brasil

Registre uma conta gratuita hoje para se tornar um membro! Uma vez conectado, você poderá participar neste site adicionando seus próprios tópicos e postagens, além de se conectar com outros membros por meio de sua própria caixa de entrada privada!

  • Anunciando os planos GOLD no Fórum Outer Space
    Visitante, agora você pode ajudar o Fórum Outer Space e receber alguns recursos exclusivos, incluindo navegação sem anúncios e dois temas exclusivos. Veja os detalhes aqui.


GameDev e por que eu não uso Game Engines.

E você? O que usa?


  • Total voters
    28

kaseiicy

Larva
Mensagens
7
Reações
9
Pontos
3
É, eu já sei o que você tá pensando: "hurr durr como vc faz um jogo sem engine? para de falar m**** gordao". Maaaaas, deixe eu terminar de falar primeiro.
Eu não uso Game Engines prontas, eu crio as minhas próprias, agora algum de vocês devem estar pensando: "Ih alá o retardado fica reinventando a roda" maaaaaas calma lá meu "pasero".

O problema que eu sempre tive com Game Engines em geral (Unity, Cocos, Godot, Unreal, etc) é que elas todas usam tecnologias que não acho interessante, por exemplo, Godot usa uma especie de Python e C# para programar. Unreal você só consegue produzir games para jogadores com PCs fod**. Unity tem historico de alto consumo computacional para pouco resultado. Sem contar que todas essas engines usam linguagens que sinceramente eu considero o "côco do cavalo do bandido", C++, Python e C#.

Então como um bom dev Java por mais de 8 anos, eu pensei assim: Hmm, eu tenho a capacidade de criar a minha própria solução! E né que eu tenho mesmo? O meu primeiro projeto eu fiz, pasmem, com JWT puro hahahaha. Então eu comecei a estudar computação gráfica e tive meu primeiro contato com OpenGL e DirectX, cara eu me apaixonei a primeira vista com OpenGL.

OpenGL provê uma solução aberta, grátis e multiplataforma. E adaptando uma coisa e outra você pode criar para Mobile com o mesmo codigo. Maravilhoso né? Bom, no inicio não. A documentação da API não é muito amigavel para iniciantes, materiais são caros ou dificeis de achar de graça, eu TIVE que COMPRAR o livro do OpenGL 4.2, foi 130 reais na epoca, mas valeu a pena.

Outra coisa, recursos relacionados a essas APIs você só acha majoritariamente em C++. Faz sentido, C++ é o padrão da industria. Então pra estudar OpenGL/DX/VK vc precisa manjar pelo menos um pouco de c++ só para entender os exemplos.

Algumas semanas de estudo depois, eu descobri a biblioteca java que ia mudar o modo como eu crio jogos até hoje! Ela se chama LWJGL (LightWeight Java Game Library), e advinhem um jogo EM JAVA que é 3D? Minecraft. É, minecraft foi criado usando LWJGL 2!

Hoje em dia a Biblioteca evolui bastante, antigamente ela provia uma solução propria para o OpenGL, hoje ( versao 3 ) ela provê um sistema de C++ bindings ou seja não é só codigo emulado ou adaptação (Wrapper) o codigo do LWJGL usa CODIGO NATIVO C++ para prover bibliotecas C++ comuns como GLM, GLFW, OpenAL, OpenAL, Opus, Assimp e etc tudo pela JNI! então você tem um desempenho do k7!

Bom, porém, usar APIs de baixo nível certamente é mais dificil doq usar uma abstração (Unity por exemplo), mas a experiencia de criar algo com as suas proprias maos é deliciosa.

Ah para interessados nisso, não eu não comecei meu gamedev "from scratch" já criando uma engine. Criar uma engine é um subproduto de você criar jogos do zero. Você vai percebendo e entendendo partes do codigo que podem ser genericalizados e transformando isso em libs e dps com o tempo quando vc ganha dominio suficiente vc começa a construir sua game engine como uma especie de "super library", dps disso vc começa a desenvolver pequenas GUI para utilitarios dessa lib e mais futuramente vc faz uma solução All-In-One com editor e tudo mais que tem direito.

No momento eu estou no maximo que dá pra se estar do segundo passo, porque? Simples! Uma solução All-In-One é INFINITAMENTE mais dificil que tudo, sozinho é impossivel! E como eu não sou muito do tipo colaborador esse é o maximo que eu consigo chegar, porém eu estou satisfeito com as minhas proprias ferramentas.

Eu deixaria alguns links de referencia mas vai que os moderadores me banem! kkkkkkkk

TL;DR

Java junto com LWJGL3 tão suavera como usar C++ usando bibliotecas nativas! Obviamente, usar APIs de baixo nivel significa que você PRECISA FAZER TUDO DO ZERO! E eu não to zuando quando eu digo DO ZERO. Mas, a experiencia que você ganha é invaluavel e é super divertido!
 

Madarame

Mil pontos, LOL!
Mensagens
14.057
Reações
34.959
Pontos
1.054
ih alá o gordão querendo pagar de intelectual :coolface


Tua engine é boa? Mostra umas fotos ae de algo rodando nela pra rapaziada aqui. Tem um kra no youtube que faz as próprias engines, inclusive uma roda até raytracing no DOS em 16 cores, na vdd todas as engines dele são feitas no DOS.
 

kaseiicy

Larva
Mensagens
7
Reações
9
Pontos
3
ih alá o gordão querendo pagar de intelectual :coolface


Tua engine é boa? Mostra umas fotos ae de algo rodando nela pra rapaziada aqui. Tem um kra no youtube que faz as próprias engines, inclusive uma roda até raytracing no DOS em 16 cores, na vdd todas as engines dele são feitas no DOS.

USHDIAUSHDAIUDHSAIUDH, eu perto desses caras ai não passo de um noob kkkkkkk os cara que faz raytracing no DOS não é nem gente é a encarnação de DEUS kkkkkkkkkkkk

Mano sinceramente eu não vou postar foto muito menos video :p por dois motivos:
  1. eu tenho vergonha, pq não tá completo
  2. pq os grafico sao feios (ainda) kkkkk

tipo feio, tipo feio msm mas isso é pq eu sou pessimo com dev de shader ;-;
 

kaseiicy

Larva
Mensagens
7
Reações
9
Pontos
3
Mas em breve assim que eu ter algo mais apresentavel eu vou começar a upar no YT, tho eu n posso passar link do canal, pq vai que os mod acha que eu to promovendo canal :V mas se tu quiser o link chama no pv
 

kaseiicy

Larva
Mensagens
7
Reações
9
Pontos
3
Apesar dos resultados eu ter vergonha de mostrar, o source é outra coisa.
Aliais, eu to reescrevendo ela pra tentar encaixar tecnicas novas como shader pre-compilados (SPIR-V) e funções mais modernas OpenGL 4.3+ :D
 

Anexos

  • Screenshot_2.png
    Screenshot_2.png
    167,1 KB · Visualizações: 65

DocVooDoo

Lenda da internet
Mensagens
31.936
Reações
41.551
Pontos
1.689
Não existe bala de prata nisso.
Você resolve fazer sua própria engine e terá o custo de fazer muita coisa sozinho e algumas vezes "redesenhar a roda" fazendo coisas que já existem em outras engines.
Você resolve adotar uma engine de terceiros e terá também limitações, as vezes problemas de suporte.

O mais importante é ter opções.

Quem dera se 10/20 anos atrás tivéssemos todas essas opções que temos hoje em dia.
 


wildanimal86

Ser evoluído
Mensagens
113
Reações
44
Pontos
38
com uma engine vc se torna mais produtivo isso pelo menos na minha visão , a pessoa desenvolve mais em menos tempo...
 

CidoLoco

Bam-bam-bam
VIP
Mensagens
3.138
Reações
2.083
Pontos
354
Eu tenho mais de 120 kg, então me qualifico a não usar engines prontas. Não apenas isso, mas pelos 3kg além dos 120 eu estou reescrevendo o jogo em lisp.

No meu caso, corri de usar engines prontas principalmente devido a questão de licença, e pelo fato de que a unity é ruim para algumas coisas que eu preciso.
 

kaseiicy

Larva
Mensagens
7
Reações
9
Pontos
3
Não existe bala de prata nisso.
Você resolve fazer sua própria engine e terá o custo de fazer muita coisa sozinho e algumas vezes "redesenhar a roda" fazendo coisas que já existem em outras engines.
Você resolve adotar uma engine de terceiros e terá também limitações, as vezes problemas de suporte.

O mais importante é ter opções.

Quem dera se 10/20 anos atrás tivéssemos todas essas opções que temos hoje em dia.
ai no caso vai mais da preferencia entre: bater cabeça com teorias ou bater cabeça com suporte kkk
 

Raptor87

Bam-bam-bam
Mensagens
1.167
Reações
3.750
Pontos
303
Java é uma linguagem terrível para programar uma engine. Primeiro que você não consegue gerar código nativo como em C ou C++ e a runtime (JVM) da linguagem é pesadíssima, com alto consumo de memória e processamento. Segundo, garbage collector é obrigatório, você não tem qualquer controle sobre a memória que a sua engine usa e o mesmo garbage collector consome muitos ciclos da CPU e pausa a thread principal da aplicação para limpar os recursos alocados, causando stuttering e quedas na taxa de quadros.

Outro detalhe é que com Java não é possível programar em baixo nível, você depende de hacks feitos em C para acessar a API do OpenGL e no Windows, não é possível acessar a API do Direct3D. Sem falar em outros detalhes, como a falta de sobrecarga de operadores, o que torna cálculos em classes de vetores e matrizes mais verboso e confuso, etc.

Não é atoa que é raro ver jogos comerciais feitos em Java. Minecraft é uma exceção.
Se alguém quer entrar no mercado de jogos, o óbvio é estudar C++ e C# (que também não é uma linguagem apropriado para se desenvolver uma Engine, mas ela é usada como linguagem de scripts em muitas engines como por exemplo a Unity 3D ).
 

CidoLoco

Bam-bam-bam
VIP
Mensagens
3.138
Reações
2.083
Pontos
354
runtime (JVM) da linguagem é pesadíssima
Não é mais tão ruim quanto antigamente. Como tu disse, maior parte do esforço em um jogo nessas linguagens é delegado a bibliotecas nativas escritas em c/c++ e a performance é suficiente pra maior parte dos casos. Atualmente é bem comum ver jogos em Java e C#, principalmente em Mobile. E hoje em dia a gente tem hardware sobrando (tanto memória quanto cpu) na maior parte das plataformas, o que nos dá o privilégio de priorizar velocidade de desenvolvimento ao invés de otimização.

Java e C# hoje em dia são bons meio-termo entre performance e facilidade de desenvolvimento. C++ tem performance melhor mas exige um dominio muito bom de programação e tem curva de aprendizado alta. O Garbage Collector é realmente um saco, mas saber trabalhar com ele é mais fácil do que dominar alocação/desalocação de memória manual em C++. Em C uma desalocação errada de memória é segfault em runtime, o tradedoff disso em Java/C# são possíveis travadinhas no loop do jogo de vez em quando. :P (e tem como ser evitado em maior parte)

Para quem precisa extrair 100% do hardware realmente C++ é o caminho (por isso que é usado pra jogos comerciais grandes), mas para desenvolvimento casual (principalmente pra gente menos experiente) Java e C# entregam uma performance decente a troco de uma maior facilidade.

E ainda tem Rust aí que ta chegando como uma alternativa moderna ao C.
 

bquarkz

Ei mãe, 500 pontos!
Mensagens
1.137
Reações
795
Pontos
574
Cara eu fiz minha própria engine 2D usando Java e LWJGL a alguns anos atrás, dá muito trabalho. Na verdade eu comecei brincando com uma engine de física e precisava de um render porco para mostrar minhas peripécias. Resultado, foi muito divertido com certeza e o aprendizado foi colossal, mas eu não usaria isso para fazer um jogo e vender. Nem f**end0. Ainda mais com Unity e Unreal de "graça". No entando, volta e meia volto a brincar lá naquela porcaria. Hoje em dia uso o spritebatch do libgdx que é uma coisa linda de Deus, e a fisica box2d tb integrado no libgdx.

Segue ai a versão estável da bagaceira lá para meados de 2015 (renderer feito por eu mesmo):


E na versão atual estou brincando, quando tenho tempo em criar uma espécie de sistema de janelas (usando o libgdx como renderer):



Fiz o vídeo acima para discutir as ideias de um jogo com alguns amigos. O código está no github se alguém quiser se aventurar: Beyond-Time-Game


Agora, falando sobre Garbage Collectors, acredito que o GC padrão do Java é uma das sétimas maravilhas do mundo. Quando desenvolvia em C++ fiz meu próprio GC que apesar de horrível ainda assim era muito melhor que ficar gerenciando memória manualmente e conviver com leaks constantes. Para projetos grandes, que rodam em servidores, não tem jeito, não adianta, mesmo que vc seja MUITO disciplinado ainda assim dá m****. Até jogos AAA feitos em C++ usam GC de alguma maneira.

E se vc não gosta da maneira que o GC padrão do Java roda, troque, crie o seu próprio, ou pague por um que mais se aplica a sua necessidade. A JVM aceita GC customizados. Aliás na própria runtime oficial do Java temos alguns GCs disponíveis, é só escolher. E outra coisa, se vc quer performar em Java ou C++ (sendo jogo ou não - acredite existem aplicações que requerem mais processamento que um jogo) e vc acha que a solução "build-in" de gerenciamento de memória não está entregando, então parta para um "object pool", ou técnica semelhante.
 

Cristiano Sword

Bam-bam-bam
Mensagens
2.296
Reações
10.701
Pontos
453
É, eu já sei o que você tá pensando: "hurr durr como vc faz um jogo sem engine? para de falar m**** gordao". Maaaaas, deixe eu terminar de falar primeiro.
Eu não uso Game Engines prontas, eu crio as minhas próprias, agora algum de vocês devem estar pensando: "Ih alá o retardado fica reinventando a roda" maaaaaas calma lá meu "pasero".

O problema que eu sempre tive com Game Engines em geral (Unity, Cocos, Godot, Unreal, etc) é que elas todas usam tecnologias que não acho interessante, por exemplo, Godot usa uma especie de Python e C# para programar. Unreal você só consegue produzir games para jogadores com PCs fod**. Unity tem historico de alto consumo computacional para pouco resultado. Sem contar que todas essas engines usam linguagens que sinceramente eu considero o "côco do cavalo do bandido", C++, Python e C#.

Então como um bom dev Java por mais de 8 anos, eu pensei assim: Hmm, eu tenho a capacidade de criar a minha própria solução! E né que eu tenho mesmo? O meu primeiro projeto eu fiz, pasmem, com JWT puro hahahaha. Então eu comecei a estudar computação gráfica e tive meu primeiro contato com OpenGL e DirectX, cara eu me apaixonei a primeira vista com OpenGL.

OpenGL provê uma solução aberta, grátis e multiplataforma. E adaptando uma coisa e outra você pode criar para Mobile com o mesmo codigo. Maravilhoso né? Bom, no inicio não. A documentação da API não é muito amigavel para iniciantes, materiais são caros ou dificeis de achar de graça, eu TIVE que COMPRAR o livro do OpenGL 4.2, foi 130 reais na epoca, mas valeu a pena.

Outra coisa, recursos relacionados a essas APIs você só acha majoritariamente em C++. Faz sentido, C++ é o padrão da industria. Então pra estudar OpenGL/DX/VK vc precisa manjar pelo menos um pouco de c++ só para entender os exemplos.

Algumas semanas de estudo depois, eu descobri a biblioteca java que ia mudar o modo como eu crio jogos até hoje! Ela se chama LWJGL (LightWeight Java Game Library), e advinhem um jogo EM JAVA que é 3D? Minecraft. É, minecraft foi criado usando LWJGL 2!

Hoje em dia a Biblioteca evolui bastante, antigamente ela provia uma solução propria para o OpenGL, hoje ( versao 3 ) ela provê um sistema de C++ bindings ou seja não é só codigo emulado ou adaptação (Wrapper) o codigo do LWJGL usa CODIGO NATIVO C++ para prover bibliotecas C++ comuns como GLM, GLFW, OpenAL, OpenAL, Opus, Assimp e etc tudo pela JNI! então você tem um desempenho do k7!

Bom, porém, usar APIs de baixo nível certamente é mais dificil doq usar uma abstração (Unity por exemplo), mas a experiencia de criar algo com as suas proprias maos é deliciosa.

Ah para interessados nisso, não eu não comecei meu gamedev "from scratch" já criando uma engine. Criar uma engine é um subproduto de você criar jogos do zero. Você vai percebendo e entendendo partes do codigo que podem ser genericalizados e transformando isso em libs e dps com o tempo quando vc ganha dominio suficiente vc começa a construir sua game engine como uma especie de "super library", dps disso vc começa a desenvolver pequenas GUI para utilitarios dessa lib e mais futuramente vc faz uma solução All-In-One com editor e tudo mais que tem direito.

No momento eu estou no maximo que dá pra se estar do segundo passo, porque? Simples! Uma solução All-In-One é INFINITAMENTE mais dificil que tudo, sozinho é impossivel! E como eu não sou muito do tipo colaborador esse é o maximo que eu consigo chegar, porém eu estou satisfeito com as minhas proprias ferramentas.

Eu deixaria alguns links de referencia mas vai que os moderadores me banem! kkkkkkkk

TL;DR

Java junto com LWJGL3 tão suavera como usar C++ usando bibliotecas nativas! Obviamente, usar APIs de baixo nivel significa que você PRECISA FAZER TUDO DO ZERO! E eu não to zuando quando eu digo DO ZERO. Mas, a experiencia que você ganha é invaluavel e é super divertido!

aiai.... vamos por partes...

JAVA NÃO é uma linguagem boa pra games, muito menos pra engines, sobre as engines q vc citou, vc tem varias engines nao graficas (box2d, sfml, allegro etc) ou algumas graficas q tem bom desempenho como a Construct e gamemaker, que rodam no meu celeronD e petium4 encostado aqui em cima dos armario.

Fazer sua própria engine eh bom pra evoluir seu nivel de programador, foi isso que eu fiz em 2016, quando eu tava muito travado em fazer um rpg a la valkyrie profile no unity, desci o nivel e fui programar sistemas antigos em C, Basic e asm. Mas sejamos sinceros, estamos no Brasil, onde jogos não costumam dar futuro nem pra pagar o aluguel barato de um cortiço, vc com certeza trabalha com outra coisa. Pelo q te deu pra entender no seu texto vc eh dev JAVA. Se vc quiser ter mais controle da maquina use uma engine não gráfica como a alllegro. E outras as vezes oq vc quer fazer nem come tanto processamento, umamigo meu queria faze só um jogo de navinha e tava codando em sdl puro! Eu mostrei a ele q podia er rendimento e uma ferramenta free com o C1, ele tá mó feliz e logo lança o jogo.
Gente... fazer jogo não é só programar, eu faço minha propria engine em baixíssimo nivel no mega drive/dreamcast e pc, e tô comendo o pao q o kapeta pisou.
Como acredito q o projeto tem futuro, e eu SEMPRE termino oq começo vou até o fim. E tbm pq to perto de terminar essa porra de engine. Alias eu quero termianr o quanto antes, não aguento mais ver um hexadecimal na minha cara, já cheguei na depressão de fazer piadas com multiplicadores de registradores de endereço.
Mas lembre, um jogo tem gráficos pra fazer, roteiro (nem todos eu sei..), musica, testers, level design e TODO o game design AINDA, q eh como essa porra vai ser divertida e não um monte de audio visual com input na cara do jogador.

Sobre os links, eu nãoa cho q nenhum ADM aq vai apagar links de openGL, mesmo se for de livros, ate pq a maioria eh velho e os mais novos ninguem nem liga se compartilha, quem gosta dessas porra igual eu gosta de comprar o fisico pra cheirar. mesmo q tenha digital.

Compartilha ai, fiquei curioso ;)
 

bquarkz

Ei mãe, 500 pontos!
Mensagens
1.137
Reações
795
Pontos
574
aiai.... vamos por partes...

JAVA NÃO é uma linguagem boa pra games, muito menos pra engines, sobre as engines q vc citou, vc tem varias engines nao graficas (box2d, sfml, allegro etc) ou algumas graficas q tem bom desempenho como a Construct e gamemaker, que rodam no meu celeronD e petium4 encostado aqui em cima dos armario.

Fazer sua própria engine eh bom pra evoluir seu nivel de programador, foi isso que eu fiz em 2016, quando eu tava muito travado em fazer um rpg a la valkyrie profile no unity, desci o nivel e fui programar sistemas antigos em C, Basic e asm. Mas sejamos sinceros, estamos no Brasil, onde jogos não costumam dar futuro nem pra pagar o aluguel barato de um cortiço, vc com certeza trabalha com outra coisa. Pelo q te deu pra entender no seu texto vc eh dev JAVA. Se vc quiser ter mais controle da maquina use uma engine não gráfica como a alllegro. E outras as vezes oq vc quer fazer nem come tanto processamento, umamigo meu queria faze só um jogo de navinha e tava codando em sdl puro! Eu mostrei a ele q podia er rendimento e uma ferramenta free com o C1, ele tá mó feliz e logo lança o jogo.
Gente... fazer jogo não é só programar, eu faço minha propria engine em baixíssimo nivel no mega drive/dreamcast e pc, e tô comendo o pao q o kapeta pisou.
Como acredito q o projeto tem futuro, e eu SEMPRE termino oq começo vou até o fim. E tbm pq to perto de terminar essa porra de engine. Alias eu quero termianr o quanto antes, não aguento mais ver um hexadecimal na minha cara, já cheguei na depressão de fazer piadas com multiplicadores de registradores de endereço.
Mas lembre, um jogo tem gráficos pra fazer, roteiro (nem todos eu sei..), musica, testers, level design e TODO o game design AINDA, q eh como essa porra vai ser divertida e não um monte de audio visual com input na cara do jogador.

Sobre os links, eu nãoa cho q nenhum ADM aq vai apagar links de openGL, mesmo se for de livros, ate pq a maioria eh velho e os mais novos ninguem nem liga se compartilha, quem gosta dessas porra igual eu gosta de comprar o fisico pra cheirar. mesmo q tenha digital.

Compartilha ai, fiquei curioso ;)


Discordo e concordo.

Java como linguagem já soa meio ultrapassada, mas ainda assim se prova útil em vários momentos. Principalmente por ser uma linguagem compilada para uma excelente maquina virtual (JVM) e madura, rodando a pelo menos 20 anos no mercado. Acredito que esse seja o grande trunfo do Java, no entanto atualmente outras linguagens se apresentam debaixo do mesmo guarda chuvas do JVM, tais como: Kotlin, Goovy e Scala...

No tocante a usar Java para scriptar jogos: acredito que o maior problema seja a falta de um "operator overloading" o que auxiliaria e muito com jogos. Mas, se o desenvolvedor for mais versado em Java e convive bem com isso, com certeza, isso não seria um problema. Então, discordo quando vc diz que JAVA NÃO é boa para jogos, pelo menos para scripts. Isso depende de quem escreve. No entanto, eu preferiria usar Kotlin que aceita operator overloading e algumas outras funcionalidades bem legais. E levando em conta o fato de que estão portando muita coisa da libGDX para Koltin aqui: https://libktx.github.io/ torna isso mais atraente ainda.

Agora, dizer que está criando uma engine do zero usando Java é meio esquisofrenico, jah que Java em sua totalidade roda em uma JVM, e usar JNI para acessar diretivas do sistema operacional DIRETAMENTE só mostra que você está codando em C++ e não em Java. Então sim, não faz sentido algum usar Java para uma engine e concordo plenamente contigo. Apesar de que eu não duvido que haja perdido pela internerds algum transpilador de byte-code para codigo nativo e que faça o link diretamente com bibliotecas do sistema.

Porém, sempre tem um porém né :), vc pode usar Java como uma linguagem de mais alto nível para elaborar sua engine e manter o acesso a diretivas do sistema usando OpenGL no caso de implementar isso para um PC, ou SDK Android no caso de implementar para um Android, desde que as implementações obedeçam um CONTRATO bem definido. E é exatamente isso o que a libGDX faz, para mim soa fantástico. Vc pode construir tudo no PC e depois fazer deploy direto para um Android da vida sem maiores custos (em tese). Ou seja, você coda em Java e linka com a implementação alvo. E acredito que seja mais ou menos isso que o OP tenha em mente, o que ao meu ver é muito louvável!
 

Kazin

Mil pontos, LOL!
GOLD
Mensagens
1.879
Reações
4.129
Pontos
1.054
Desmerecer a performance de engines como a Unreal e Unity, falar mal de C++ e depois mandar que fez uma engine em Java não dá né fera. :klol

Uso Unreal e Unity nos meus projetos e entregam ótimos resultados com ótima performance. Não sinto nenhuma necessidade de uma engine personalizada.
 

Landstalker

Lenda da internet
Mensagens
19.355
Reações
39.658
Pontos
1.584
Na verdade, amiguinho, OpenGL é feito em C e se utiliza também em C, o que, claramente, também não lhe impede de usá-la em C++, mas foi feita em C e não no C++ já que o seu objetivo é rodar como uma State Machine.

A Unity melhorou absurdamente de performance nos últimos 5 anos, agora há os recursos de DOTs e de ECS com uso muito melhor de multithreading. Essa historia da Unity ser uma engine fraca e que só serve pra construir joguinho já caiu por terra há tempos.

Unreal é bem interessante, mas concordo contigo que é estranha e pesado para projetos bem menores. O Paper2D que foi uma iniciativa para bater de frente com a parte 2D da Unity colocada a partir de 2014 acabou que não deu muito certo e até hoje a UE é quase que exclusiva para grandes projetos ou de indies 3D.

Java é uma linguagem do seu tempo, mesmo sendo uma linguagem que trabalhei por 8 anos e até tirei certificação nela, acho-a problemática para focar numa programação de jogos, não que isso seja um empecilho ao seu uso, a depender do que for fazer, é completamente viável sim, mas com outras tecnologias e linguagens em foco, acho preterido utilizar-se desses outros recursos. A Kotlin parece algo muito promissor e interessante, infelizmente não peguei para estudar essa nova "Java" da tcheca.

Eu só vejo a vantagem de você criar uma engine para aprimorar o conhecimento de programação de jogos a um nível de baixo, entendendo realmente como tudo funciona atrás das cortinas ou então para também criar uma engine com o seu próprio workflow, dessa forma você pode se tornar mais produtivo em não ter que se adaptar à forma como as outras engines funcionam, mas criar a sua própria para seguir a maneira como você realmente gostaria de trabalhar numa engine.
 

bquarkz

Ei mãe, 500 pontos!
Mensagens
1.137
Reações
795
Pontos
574
Na verdade, amiguinho, OpenGL é feito em C e se utiliza também em C, o que, claramente, também não lhe impede de usá-la em C++, mas foi feita em C e não no C++ já que o seu objetivo é rodar como uma State Machine.

A Unity melhorou absurdamente de performance nos últimos 5 anos, agora há os recursos de DOTs e de ECS com uso muito melhor de multithreading. Essa historia da Unity ser uma engine fraca e que só serve pra construir joguinho já caiu por terra há tempos.

Unreal é bem interessante, mas concordo contigo que é estranha e pesado para projetos bem menores. O Paper2D que foi uma iniciativa para bater de frente com a parte 2D da Unity colocada a partir de 2014 acabou que não deu muito certo e até hoje a UE é quase que exclusiva para grandes projetos ou de indies 3D.

Java é uma linguagem do seu tempo, mesmo sendo uma linguagem que trabalhei por 8 anos e até tirei certificação nela, acho-a problemática para focar numa programação de jogos, não que isso seja um empecilho ao seu uso, a depender do que for fazer, é completamente viável sim, mas com outras tecnologias e linguagens em foco, acho preterido utilizar-se desses outros recursos. A Kotlin parece algo muito promissor e interessante, infelizmente não peguei para estudar essa nova "Java" da tcheca.

Eu só vejo a vantagem de você criar uma engine para aprimorar o conhecimento de programação de jogos a um nível de baixo, entendendo realmente como tudo funciona atrás das cortinas ou então para também criar uma engine com o seu próprio workflow, dessa forma você pode se tornar mais produtivo em não ter que se adaptar à forma como as outras engines funcionam, mas criar a sua própria para seguir a maneira como você realmente gostaria de trabalhar numa engine.

Nope, OpenGL não é um programa, ela é uma API, ou seja, uma documentação, um contrato que lhe diz como usar aquele sistema. E também não é feita em C, ela pode ser sim implementada todinha em software porém a implementação completa da API do OpenGL é feita em hardware, ou pelo menos deveria - ou não faria sentido. A implementação fica a cargo do desenvolvedor do hardware e chamamos isso de driver. Temos um binding do OpenGL em C, em Java (que roda o binding de C por baixo dos panos), em Javascript e assim vai. Quanto a uma implementação por software, eu vi um maluco fazendo do zero uns anos atrás e naquela época ficava lento que dava vontade de chorar :). Nunca me arrisquei a tanto, tem que ter pelo menos uns dez quilos de teta para isso, eu to no seis e meio ainda. E ele estava fazendo em C++ não em C. No passado algumas funcionlidades eram implementadas em software e aos poucos portadas ao hardware. Atualmente, não sei em que pé anda, faz muito tempo que não brinco com isso.

Para se ter uma engine vc precisa ter muito mais que só acesso a hardware grafico, aliás algumas nem disso precisam. Vc precisa de controle de IO, pool de objetos, GC, temporizadores e etc. Isso normalmente são desenvolvidos em qq liguagem que vc queira, e acredito que seja justamente o que o colega OP esteja fazendo em JAVA. Um exemplo pratico e explicado muito por cima seria dizer que o OpenGL precisa de texturas, mas uma textura para o OpenGL é um array de bytes, porém o OpenGL não prove acesso a IO ou nada parecido, é uma API para acesso a hardware gráfico. Então deve-se fazer uso de sua linguagem "pridileta" e contruir as rotinas para acesso a IO e conversão de dados. Ou seja, pegam aquele PNG maroto de algum lugar do disco, da memória, de um web service e converte em um array de bytes para passar pro hardware. E obviamente, o game loop, o momento de escrita e atualização do OpenGL isso tudo é controlado pela engine. E é isso parsa.

Para mais informações:
https://www.khronos.org/opengl/wiki/FAQ#What_is_OpenGL.3F
https://www.khronos.org/opengl/wiki/Language_bindings
 
Ultima Edição:

Cristiano Sword

Bam-bam-bam
Mensagens
2.296
Reações
10.701
Pontos
453
Primeiramente, eu não tenho nada contra JAVA, trabalhei com ela, tirei até certificação em 2015, tava numa modinha retada de tirar certificação e tinha um monte de gente(ou ainda tem) vendendo curso pra isso. Eu sou a favor de usar as ferramentas mais adequadas para resolver o problema.
Linguagem de programação não é religião. Você usa uma escova de dentes pra esfregar o chão do banheiro ou da sala? ou você usa um esfregão pra escovar os dentes? Então pronto.

Desmerecer a performance de engines como a Unreal e Unity, falar mal de C++ e depois mandar que fez uma engine em Java não dá né fera. :klol
Uso Unreal e Unity nos meus projetos e entregam ótimos resultados com ótima performance. Não sinto nenhuma necessidade de uma engine personalizada.
Excelente, unity é ótima. E compila em um monte de coisa. Se compilasse pra Mega Drive fazia meu jogo nela xD
Agora se eu fosse fazer um jogo de plataforma com sprites simples, eu usaria o c2 ou game maker.
Cada problema uma ferramenta mais adequada. Por isso não indico JAVA pra jogos, pra q? pra esquentar sua cabeça? Vai usar um rodo pra varrer?
Se for pra estudo ai em frente.



Ai cristiano... mas tem minecraft...tem o jogo fodao xyz.... q fizeram lá na casa do caraio....
vai na fé.
Depois não reclama. Programador resolve problema, com ferramentas adequadas que torne seu trampo mais facil.
Quer fazer um fps pra nintendo switch com com java ou asm arm? vai em frente.

Nope, OpenGL não é um programa, ela é uma API, ou seja, uma documentação, um contrato que lhe diz como usar aquele sistema. E também não é feita em C, ela pode ser sim implementada todinha em software porém a implementação completa da API do OpenGL é feita em hardware, ou pelo menos deveria - ou não faria sentido. A implementação fica a cargo do desenvolvedor do hardware e chamamos isso de driver. Temos um binding do OpenGL em C, em Java (que roda o binding de C por baixo dos panos), em Javascript e assim vai. Quanto a uma implementação por software, eu vi um maluco fazendo do zero uns anos atrás e naquela época ficava lento que dava vontade de chorar :). Nunca me arrisquei a tanto, tem que ter pelo menos uns dez quilos de teta para isso, eu to no seis e meio ainda. E ele estava fazendo em C++ não em C. No passado algumas funcionlidades eram implementadas em software e aos poucos portadas ao hardware. Atualmente, não sei em que pé anda, faz muito tempo que não brinco com isso.

Para se ter uma engine vc precisa ter muito mais que só acesso a hardware grafico, aliás algumas nem disso precisam. Vc precisa de controle de IO, pool de objetos, GC, temporizadores e etc. Isso normalmente são desenvolvidos em qq liguagem que vc queira, e acredito que seja justamente o que o colega OP esteja fazendo em JAVA. Um exemplo pratico e explicado muito por cima seria dizer que o OpenGL precisa de texturas, mas uma textura para o OpenGL é um array de bytes, porém o OpenGL não prove acesso a IO ou nada parecido, é uma API para acesso a hardware gráfico. Então deve-se fazer uso de sua linguagem "pridileta" e contruir as rotinas para acesso a IO e conversão de dados. Ou seja, pegam aquele PNG maroto de algum lugar do disco, da memória, de um web service e converte em um array de bytes para passar pro hardware. E obviamente, o game loop, o momento de escrita e atualização do OpenGL isso tudo é controlado pela engine. E é isso parsa.

Para mais informações:
https://www.khronos.org/opengl/wiki/FAQ#What_is_OpenGL.3F
https://www.khronos.org/opengl/wiki/Language_bindings

Acho que OpenGL é em asm e opcode se nao me engano. Pelo menos a 1.2 q to estudando eh assim. Não sei as atuais
 

Landstalker

Lenda da internet
Mensagens
19.355
Reações
39.658
Pontos
1.584
Nope, OpenGL não é um programa, ela é uma API, ou seja, uma documentação, um contrato que lhe diz como usar aquele sistema. E também não é feita em C, ela pode ser sim implementada todinha em software porém a implementação completa da API do OpenGL é feita em hardware, ou pelo menos deveria - ou não faria sentido. A implementação fica a cargo do desenvolvedor do hardware e chamamos isso de driver. Temos um binding do OpenGL em C, em Java (que roda o binding de C por baixo dos panos), em Javascript e assim vai. Quanto a uma implementação por software, eu vi um maluco fazendo do zero uns anos atrás e naquela época ficava lento que dava vontade de chorar :). Nunca me arrisquei a tanto, tem que ter pelo menos uns dez quilos de teta para isso, eu to no seis e meio ainda. E ele estava fazendo em C++ não em C. No passado algumas funcionlidades eram implementadas em software e aos poucos portadas ao hardware. Atualmente, não sei em que pé anda, faz muito tempo que não brinco com isso.

Para se ter uma engine vc precisa ter muito mais que só acesso a hardware grafico, aliás algumas nem disso precisam. Vc precisa de controle de IO, pool de objetos, GC, temporizadores e etc. Isso normalmente são desenvolvidos em qq liguagem que vc queira, e acredito que seja justamente o que o colega OP esteja fazendo em JAVA. Um exemplo pratico e explicado muito por cima seria dizer que o OpenGL precisa de texturas, mas uma textura para o OpenGL é um array de bytes, porém o OpenGL não prove acesso a IO ou nada parecido, é uma API para acesso a hardware gráfico. Então deve-se fazer uso de sua linguagem "pridileta" e contruir as rotinas para acesso a IO e conversão de dados. Ou seja, pegam aquele PNG maroto de algum lugar do disco, da memória, de um web service e converte em um array de bytes para passar pro hardware. E obviamente, o game loop, o momento de escrita e atualização do OpenGL isso tudo é controlado pela engine. E é isso parsa.

Para mais informações:
https://www.khronos.org/opengl/wiki/FAQ#What_is_OpenGL.3F
https://www.khronos.org/opengl/wiki/Language_bindings

Onde foi que eu falei que era um programa?

Ela é especificação que dá liberdade às empresas a implementar a sua própria API OpenGL, não é à toa que APENAS a Apple implementava a sua especificação, enquanto em sistemas como Windows e Linux os vendors de placa de vídeo implementavam a sua.

E sim, ela é criada inteiramente em C e (o seu acesso direto), como eu disse, nada impede de você usar C++ com ela (até é recomendável), e há os bindings dela para diversas outras linguagens e que, claro, pode-se perder um pouco de performance no meio do caminho já que são bindings de uma implementação feita em C e não uma chamada direta aos recursos OpenGL.

Eu tenho vários projetos implementados em OpenGL puro, talvez eu dia eu os coloque num GitHub da vida.
 

bquarkz

Ei mãe, 500 pontos!
Mensagens
1.137
Reações
795
Pontos
574
Onde foi que eu falei que era um programa?

Ela é especificação que dá liberdade às empresas a implementar a sua própria API OpenGL, não é à toa que APENAS a Apple implementava a sua especificação, enquanto em sistemas como Windows e Linux os vendors de placa de vídeo implementavam a sua.

E sim, ela é criada inteiramente em C e (o seu acesso direto), como eu disse, nada impede de você usar C++ com ela (até é recomendável), e há os bindings dela para diversas outras linguagens e que, claro, pode-se perder um pouco de performance no meio do caminho já que são bindings de uma implementação feita em C e não uma chamada direta aos recursos OpenGL.

Eu tenho vários projetos implementados em OpenGL puro, talvez eu dia eu os coloque num GitHub da vida.

Bom, quando vc falou que OpenGL é feita em C eu entendi que vc queria dizer que ela era um software, ou programa, ou biblioteca, sendo que na verdade OpenGL é só um requerimento, uma documentação. A API não dá liberdade nenhuma e é justamente o contrário. Apple, NVIDIA, AMD, ou qq outro fabricante de hardware gráfico podem e devem implementar essa API para que seus hardwares sejam compatíveis com OpenGL. De novo, OpenGL não é um recurso, não é um software, não é uma biblioteca, não é uma SDK, não é uma engine, não é magia negra que roda dentro do seu computador. OpenGL é uma extensa documentação que "fixa" a maneira de acessar o hardware gráfico e torna isso único, ou seja, não importa a loucura que os fabricantes façam dentro do hardware deles se implementarem a documentação do OpenGL qualquer um poderá acessar.

Apenas a Apple implementava a API pq o computador da Apple é um sistema fechado. É a própria Apple que produz sua própria "GPU", então cabe a eles mesmo o dever de implementar a API. O PC no entando é mais modular e vc consegue ter diferentes hardwares e sistemas operacionais. Nesse caso, como vc disse cada vendor deve ter seu próprio driver, e a implementação se dá no hardware e não no sofftware. Não há perda de performance nos bindings, eles são simplemente uma tradução para linguagens de alto nível (alguams nem tão alto nível assim) para tornar possível chamadas aos métodos, ou diretivas da API. Perda de performance pode ocorrer quando vc tem que lidar com o HAL do S.O., mesmo que minima. Atualmente nenhum SO permite acesso a hardware direto. Já foi o tempo em que vc disparava uma interrupção para acessar o modo gráfico (leia isso, pf). E é daí que vem os drivers opengl32.dll no windows e Mesa no linux - porra já nem sei se é isso mesmo faz tanto tempo, mas enfim. Esses drivers implementam também a API, mas funcionam como proxies, vc pensa que está acessando o hardware diretamente, mas vc está acessando o SO, e o SO conversa com o driver da place de video (aquele que vc instala para jogar o joguinho) que tb pode e deve implementar a API, mas é outro proxy e esse sim faz as chamdas no hardware diretamente. E é no nível do hardware que a porra toda acontece. Pq, pensa só, não faz sentido nenhum vc gastar os olhos da cara em uma GPU (um hardware) se todo o "recurso" é implementado em um software (feito em C/C++/Lisp ou qq outra linguagem milagrosa) que roda na sua CPU, como qualquer outro programa. Ou vc pensa que seu código em C/C++/Lisp/Fortram/Java/ASP.Net/C#/Lua/Javascript/... é compilado diretamente para código de máquina da GPU?

Cara, sério, não faz sentido nenhum dizer que a OpenGL foi criada em C.
 

Landstalker

Lenda da internet
Mensagens
19.355
Reações
39.658
Pontos
1.584
Rapaz, é até "errado" falar que OpenGL é uma API porque na verdade ela é uma especificação onde as empresas podem implementar a suas APIs em cima desse conjunto de regras. Eu não sei por que diabos você entende que algo feito em C é necessariamente um programa já que você pode usar essa linguagem até para escrever código de máquina fazendo calls em ASM. Sem contar as bibliotecas que podem ser escritas nelas e que são utilizadas por outros programas, mas enfim.

Quando falei de Apple é apenas para dar um exemplo de como ela trata - ou melhor, tratava - o OpenGL em seus sistemas MacOS. Inclusive, sou usuário de Mac há quase 10 anos, infelizmente ela dropou o recurso.

"C/C++/Lisp/Fortram/Java/ASP.Net/C#/Lua/Javascript/... é compilado diretamente para código de máquina da GPU? "

Nada é implementado direto pra GPU, até mesmo os shaders que são compilados e executados em GPU antes eles precisam ser lidos por uma CPU e passados para o processamento da GPU. Uma vez em memória e compilados - já você armazena em buffers - aí sim eles podem ser chamados à vontade por vários outros processos do código fonte.
 

Omega Frost

Mil pontos, LOL!
Mensagens
21.398
Reações
32.917
Pontos
1.459
Acho que o OP e muitos outros já disseram o essencial, que é ter algo que você se sinta confortável usando e seja produtivo. Muitas vezes ter menos recursos ajuda a manter focado nos pontos centrais do projeto.

Eu sigo o canal do TheCherno no YouTube onde ele faz um devlog da engine que ele está criando (https://www.youtube.com/channel/UCQ-W1KE9EYfdxhL6S4twUNw) e eu concordo com a motivação dele que é aprender como faz, quais são as dificuldades e os problemas ao se desenvolver em Engine do zero.

E eu acho que quem quer aprender, que faça na linguagem que está mais confortável, já vai ter bastante coisa pra aprender e os problemas vão aparecer não importa a linguagem. Eu já tentei mexer com OpenGL em Delphi :klol mas foi um aprendizado de qualquer forma, um dos exemplos era uma cópia de Quake, então dá pra tirar algo. Cada linguagem tem uma forma diferente de tratar certos paradigmas, como a linguagem se constrói em cima de certos pilares e como isso facilita ou dificulta resolver alguns problemas.

Engines hoje em dia tentam resolver o maior número de problemas possíveis pra ter pessoas usando, então se a gente filosofar um pouco sobre isso, é quase como aprender uma linguagem de programação e uma nova API gráfica. Elas também tem que focar em todos os aspectos da produção de games, generalizar várias plataformas e pensar que uma empresa não faz apenas um jogo, faz vários, então garantir reusabilidade de partes dos jogos que funcione a longo prazo.

Como disseram também sobre o OpenGL, ele é puramente uma especificação, assim como Vulkan, OpenCL e afins. Ele foi concebido como um meio para que fabricantes de dispositivos (GPUs no caso) tornem o hardware compatível com uma grande variedade de programas gráficos e isso é o mais próximo que você consegue chegar de falar diretamente com o driver, tanto que, no diagrama do OpenGL, o driver vem logo abaixo.

Isso é diferente com conversar com o DirectX, que é são várias bibliotecas da Microsoft, que fica no meio do caminho entre o driver e o programa. É por isso que o DirectX expõe muito mais funcionalidade do que o OpenGL, porque ele está intrinsecamente ligado ao subsistema gráfico do Windows.

Então não existe uma biblioteca "OpenGL" da mesma forma que tem o d3dx.dll, o que existe é uma biblioteca de cada fabricante de hardware, Intel, Nvidia, AMD, e você precisa se conectar em alguma delas para conversar com aquele dispositivo. Isso é feito usando uma framework ou o GLEW, que vai carregar a DLL do fabricante no seu programa e carregar os endereços das funções do OpenGL pro programa usar.

Pode-se dizer que existe algo parecido com o OpenGL acontecendo entre o DirectX e os fabricantes de hardware porque, obviamente, vai ter que existir uma especificação. Mas esse é o lado do DirectX que os programadores não vêem.

Cada uma das abordagens tem vantagens e desvantagens. Às vezes deixar o Windows+DirectX lidar com alguns detalhes é vantajoso, porque em teoria ele tem uma visão do sistema que o driver não tem, sem falar que evita que cada empresa tenha que reescrever código comum, por outro lado pode existir uma maneira melhor de fazer algo em um determinado hardware, como aconteceu nesse último update do Windows em que lançaram o GPU Scheduling.

Mas é interessante notar que toda a implementação do software de OpenGL vem embutida nos dr


Ele especifica como vão ser os protótipos das funções, argumentos, tipos de dados, valores de constantes ... que vão parar no opengl.h que um programador C/C++ inclui na hora de programar. Eles também especificam como essas funções interagem e devem se comportar quando o programador usa elas.

Mas o ponto fundamental que o @Landstalker disse é que não existe um "hub central", uma DLL (ou .so no caso de Unix) que você se conecte pra

Mas como o @Landstalker disso, não existe um "programa", não é que nem DirectX que você linka a d3dx.lib para ter acesso a essas funções do d3dx.dll. Essas funções vem com DLLs (ou .so's no caso de Unix) distribuídos
 

bquarkz

Ei mãe, 500 pontos!
Mensagens
1.137
Reações
795
Pontos
574
Acho que o OP e muitos outros já disseram o essencial, que é ter algo que você se sinta confortável usando e seja produtivo. Muitas vezes ter menos recursos ajuda a manter focado nos pontos centrais do projeto.

Eu sigo o canal do TheCherno no YouTube onde ele faz um devlog da engine que ele está criando (https://www.youtube.com/channel/UCQ-W1KE9EYfdxhL6S4twUNw) e eu concordo com a motivação dele que é aprender como faz, quais são as dificuldades e os problemas ao se desenvolver em Engine do zero.

E eu acho que quem quer aprender, que faça na linguagem que está mais confortável, já vai ter bastante coisa pra aprender e os problemas vão aparecer não importa a linguagem. Eu já tentei mexer com OpenGL em Delphi :klol mas foi um aprendizado de qualquer forma, um dos exemplos era uma cópia de Quake, então dá pra tirar algo. Cada linguagem tem uma forma diferente de tratar certos paradigmas, como a linguagem se constrói em cima de certos pilares e como isso facilita ou dificulta resolver alguns problemas.

Engines hoje em dia tentam resolver o maior número de problemas possíveis pra ter pessoas usando, então se a gente filosofar um pouco sobre isso, é quase como aprender uma linguagem de programação e uma nova API gráfica. Elas também tem que focar em todos os aspectos da produção de games, generalizar várias plataformas e pensar que uma empresa não faz apenas um jogo, faz vários, então garantir reusabilidade de partes dos jogos que funcione a longo prazo.

Como disseram também sobre o OpenGL, ele é puramente uma especificação, assim como Vulkan, OpenCL e afins. Ele foi concebido como um meio para que fabricantes de dispositivos (GPUs no caso) tornem o hardware compatível com uma grande variedade de programas gráficos e isso é o mais próximo que você consegue chegar de falar diretamente com o driver, tanto que, no diagrama do OpenGL, o driver vem logo abaixo.

Isso é diferente com conversar com o DirectX, que é são várias bibliotecas da Microsoft, que fica no meio do caminho entre o driver e o programa. É por isso que o DirectX expõe muito mais funcionalidade do que o OpenGL, porque ele está intrinsecamente ligado ao subsistema gráfico do Windows.

Então não existe uma biblioteca "OpenGL" da mesma forma que tem o d3dx.dll, o que existe é uma biblioteca de cada fabricante de hardware, Intel, Nvidia, AMD, e você precisa se conectar em alguma delas para conversar com aquele dispositivo. Isso é feito usando uma framework ou o GLEW, que vai carregar a DLL do fabricante no seu programa e carregar os endereços das funções do OpenGL pro programa usar.

Pode-se dizer que existe algo parecido com o OpenGL acontecendo entre o DirectX e os fabricantes de hardware porque, obviamente, vai ter que existir uma especificação. Mas esse é o lado do DirectX que os programadores não vêem.

Cada uma das abordagens tem vantagens e desvantagens. Às vezes deixar o Windows+DirectX lidar com alguns detalhes é vantajoso, porque em teoria ele tem uma visão do sistema que o driver não tem, sem falar que evita que cada empresa tenha que reescrever código comum, por outro lado pode existir uma maneira melhor de fazer algo em um determinado hardware, como aconteceu nesse último update do Windows em que lançaram o GPU Scheduling.

Mas é interessante notar que toda a implementação do software de OpenGL vem embutida nos dr


Ele especifica como vão ser os protótipos das funções, argumentos, tipos de dados, valores de constantes ... que vão parar no opengl.h que um programador C/C++ inclui na hora de programar. Eles também especificam como essas funções interagem e devem se comportar quando o programador usa elas.

Mas o ponto fundamental que o @Landstalker disse é que não existe um "hub central", uma DLL (ou .so no caso de Unix) que você se conecte pra

Mas como o @Landstalker disso, não existe um "programa", não é que nem DirectX que você linka a d3dx.lib para ter acesso a essas funções do d3dx.dll. Essas funções vem com DLLs (ou .so's no caso de Unix) distribuídos

Eu não conhecia o canal, vlw pela dica, e sim acho extremamente válido botar as mãos em algo assim simplesmente pelo aprendizado e diversão. E concordo again, não importa a linguagem, use aquilo que mais lhe é familiar, hoje em dia é possível, e o grande ponto positivo disso é ter algo a menos dentro da curva de aprendizagem.

Não sei mais como anda isso atualmente, mas opengl32.dll servia justamente para expor até a OpenGL1.1 e se vc precisa de algo mais, ai sim, vc partia para um GLEW por exemplo, para carregar as "extençõoes". A DLL simplesmente buscava o driver correto no registro do windows e fazia chamadas a partir dele, ou seja, a DLL era um proxy. Quanto ao DirectX não faço a minima idéia de como funcione, então nem posso contribuir muito.

Rapaz, é até "errado" falar que OpenGL é uma API porque na verdade ela é uma especificação onde as empresas podem implementar a suas APIs em cima desse conjunto de regras. Eu não sei por que diabos você entende que algo feito em C é necessariamente um programa já que você pode usar essa linguagem até para escrever código de máquina fazendo calls em ASM. Sem contar as bibliotecas que podem ser escritas nelas e que são utilizadas por outros programas, mas enfim.

Quando falei de Apple é apenas para dar um exemplo de como ela trata - ou melhor, tratava - o OpenGL em seus sistemas MacOS. Inclusive, sou usuário de Mac há quase 10 anos, infelizmente ela dropou o recurso.

"C/C++/Lisp/Fortram/Java/ASP.Net/C#/Lua/Javascript/... é compilado diretamente para código de máquina da GPU? "

Nada é implementado direto pra GPU, até mesmo os shaders que são compilados e executados em GPU antes eles precisam ser lidos por uma CPU e passados para o processamento da GPU. Uma vez em memória e compilados - já você armazena em buffers - aí sim eles podem ser chamados à vontade por vários outros processos do código fonte.

kkkkk, talvez pq eu seja uma mula. A definição de programa ou softweare é muito geral, é tudo aquilo que roda no computador. Mas, deixa pra lá, acabei entendendo o que vc disse. E me desculpe se fui meio babaca.

E sim OpenGL é uma especificação, e uma especificação por sua vez gera uma API - em geral uma API é um contrato de trabalho, uma interface. Aliás, o próprio nome diz isso, Application Programming Interface. Então, OpenGL é uma especificação e tem uma API. Se bem que intercambiar as coisas não é lá de todo errado, pois para fins práticos de programação uma API é a especificação transliterada. A própria documentação oficial trata a OpenGL como uma API. Acho que isso resolve esse empasse.

Mas, meu real ponto contigo era o seguinte: A implementação da API se dá no hardware da GPU e os desenvolvedores de jogos, ou ao menos da engine, consomem essa API para manipular gráficos. Não há código relacionado a OpenGL, não é um software, mas sim uma idéia, um comportamento, uma interface. Nem os drivers implementam essas APIs, eles transliteram ao todo as chamadas para a GPU . Mesmo APIs específicas da NVIDIA e AMD fazem o mesmo, bom não sei se 100%, mas a idéia é que sim. Ou seja, há código envolvido no driver, há código envolvido nos bindings, mas nenhum deles "implementa" de fato a OpenGL, eles são apenas proxies/bridges para a real implementação que se dá no hardware da GPU. E quando vc disse: "OpenGL é feito em C e se utiliza também em C", eu só achei que poderia contribuir com alguma coisa, pois essa afirmação não fez sentido para mim.
 

Cristiano Sword

Bam-bam-bam
Mensagens
2.296
Reações
10.701
Pontos
453
Acho que o OP e muitos outros já disseram o essencial, que é ter algo que você se sinta confortável usando e seja produtivo. Muitas vezes ter menos recursos ajuda a manter focado nos pontos centrais do projeto.

Eu sigo o canal do TheCherno no YouTube onde ele faz um devlog da engine que ele está criando (https://www.youtube.com/channel/UCQ-W1KE9EYfdxhL6S4twUNw) e eu concordo com a motivação dele que é aprender como faz, quais são as dificuldades e os problemas ao se desenvolver em Engine do zero.

E eu acho que quem quer aprender, que faça na linguagem que está mais confortável, já vai ter bastante coisa pra aprender e os problemas vão aparecer não importa a linguagem. Eu já tentei mexer com OpenGL em Delphi :klol mas foi um aprendizado de qualquer forma, um dos exemplos era uma cópia de Quake, então dá pra tirar algo. Cada linguagem tem uma forma diferente de tratar certos paradigmas, como a linguagem se constrói em cima de certos pilares e como isso facilita ou dificulta resolver alguns problemas.

Engines hoje em dia tentam resolver o maior número de problemas possíveis pra ter pessoas usando, então se a gente filosofar um pouco sobre isso, é quase como aprender uma linguagem de programação e uma nova API gráfica. Elas também tem que focar em todos os aspectos da produção de games, generalizar várias plataformas e pensar que uma empresa não faz apenas um jogo, faz vários, então garantir reusabilidade de partes dos jogos que funcione a longo prazo.

Como disseram também sobre o OpenGL, ele é puramente uma especificação, assim como Vulkan, OpenCL e afins. Ele foi concebido como um meio para que fabricantes de dispositivos (GPUs no caso) tornem o hardware compatível com uma grande variedade de programas gráficos e isso é o mais próximo que você consegue chegar de falar diretamente com o driver, tanto que, no diagrama do OpenGL, o driver vem logo abaixo.

Isso é diferente com conversar com o DirectX, que é são várias bibliotecas da Microsoft, que fica no meio do caminho entre o driver e o programa. É por isso que o DirectX expõe muito mais funcionalidade do que o OpenGL, porque ele está intrinsecamente ligado ao subsistema gráfico do Windows.

Então não existe uma biblioteca "OpenGL" da mesma forma que tem o d3dx.dll, o que existe é uma biblioteca de cada fabricante de hardware, Intel, Nvidia, AMD, e você precisa se conectar em alguma delas para conversar com aquele dispositivo. Isso é feito usando uma framework ou o GLEW, que vai carregar a DLL do fabricante no seu programa e carregar os endereços das funções do OpenGL pro programa usar.

Pode-se dizer que existe algo parecido com o OpenGL acontecendo entre o DirectX e os fabricantes de hardware porque, obviamente, vai ter que existir uma especificação. Mas esse é o lado do DirectX que os programadores não vêem.

Cada uma das abordagens tem vantagens e desvantagens. Às vezes deixar o Windows+DirectX lidar com alguns detalhes é vantajoso, porque em teoria ele tem uma visão do sistema que o driver não tem, sem falar que evita que cada empresa tenha que reescrever código comum, por outro lado pode existir uma maneira melhor de fazer algo em um determinado hardware, como aconteceu nesse último update do Windows em que lançaram o GPU Scheduling.

Mas é interessante notar que toda a implementação do software de OpenGL vem embutida nos dr


Ele especifica como vão ser os protótipos das funções, argumentos, tipos de dados, valores de constantes ... que vão parar no opengl.h que um programador C/C++ inclui na hora de programar. Eles também especificam como essas funções interagem e devem se comportar quando o programador usa elas.

Mas o ponto fundamental que o @Landstalker disse é que não existe um "hub central", uma DLL (ou .so no caso de Unix) que você se conecte pra

Mas como o @Landstalker disso, não existe um "programa", não é que nem DirectX que você linka a d3dx.lib para ter acesso a essas funções do d3dx.dll. Essas funções vem com DLLs (ou .so's no caso de Unix) distribuídos
Não conhecia o canal, já me inscrevi e marquei as notificações. Quero futuramente fazer uma engine apenas por aprendizado para o Dc com OpenGL 1.2. VOu começar quando tiver mais tempo.
 

Aleatório

Bam-bam-bam
Mensagens
1.251
Reações
1.481
Pontos
224
Minha diversão era fazer os jogos e não as desenvolver as ferramentas. Por isso eu sempre usei engines já existentes no mercado. Grande maioria das vezes usei a Unity mesmo, por ser a que mais tem material na internet, mas usava o Corona também.
 

Forbidden Memories

Mil pontos, LOL!
VIP
GOLD
Mensagens
2.746
Reações
7.112
Pontos
1.004
Se você gosta de computação gráfica tudo bem, legal, mas até uma engine 2D (engine mesmo) já demanda muito tempo de desenvolvimento, quanto mais uma engine 3D que é extremamente complicado de se fazer corretamente algo funcional. Tempo perdido que você poderia estar usando pra fazer JOGO ao invés de ENGINE.

Imagina se o pessoal de gamejam fosse desses de "CRIAR JOGO NA RAÇA".

E não vou nem comentar a briguinha de linguagens, dificilmente alguem aqui vai atingir o limite de uma delas. Time to market é muito, mas MUITO melhor que um ganhozinho de benchmark de uma linguagem vs. a outra que pode ir por agua abaixo se o programador for medíocre.
 

Ponfick

All Hail
Mensagens
10.010
Reações
2.931
Pontos
1.204
A postagem perdeu totalmente a credibilidade, quando tentou falar que Java é uma boa linguagem :khuebr.

Criar a própria engine para quem vai fazer um jogo pequeno não faz sentido, o tempo que tu vai gastar criando e tunando ela, tu termina o jogo.

Para conhecimento técnico ate vai, mas mesmo assim acho um gasto desnecessário de tempo é energia.
 

Jogadô

Lenda da internet
Mensagens
29.322
Reações
21.616
Pontos
1.699
Estou afastado do mundo da programação há uns 5 anos, eu era desenvolvedor web, até que dominava bem essa área, mas nunca peguei pra tentar fazer um game, tava querendo reaquecer meu cérebro, será que eu iria me bater muito?
 
Topo Fundo