PS: Não é também só pela existência dos ponteiros. Até porque, hoje em dia se programa com smart pointers em C++, que também faz uma espécie de garbage collection.
No C# é mais fácil acessar código nativo. A sintaxe dos métodos unsafe é limpa e segura. Bem diferente do inferno chamado JNI. Sem falar, claro, nas integrações com DirectX e com o XNA.
No C++, você tem controle total. Pode acessar instruções de hardware, sabe exatamente o que vai ser compilado e como.
[quote]Não é também só pela existência dos ponteiros. Até porque, hoje em dia se programa com smart pointers em C++, que também faz uma espécie de garbage collection.
No C# é mais fácil acessar código nativo. A sintaxe dos métodos unsafe é limpa e segura. Bem diferente do inferno chamado JNI. Sem falar, claro, nas integrações com DirectX e com o XNA.
No C++, você tem controle total. Pode acessar instruções de hardware, sabe exatamente o que vai ser compilado e como. [/quote]
Humm, legal, eu achava que o maior empecilho eram os ponteiros, apesar do C# acessar código nativo ele também é multiplataforma pelo que eu entendi.E o Java acessa a JVM ou acessa nativamente pelo JNI.
A Microsoft nunca vai querer o Java integrando XNA com o Java também.Será preciso investimento da Oracle nisso, ou desenvolvimento de alguma ferramenta da comunidade Java.
Com Java vc consegue acessar memória nativa e trabalhar com ponteiros. Só não sei se isso tem qualquer praticidade para jogos.
http://mentablog.soliveirajr.com/2012/11/which-one-is-faster-java-heap-or-native-memory/
[quote]Com Java vc consegue acessar memória nativa e trabalhar com ponteiros. Só não sei se isso tem qualquer praticidade para jogos.
http://mentablog.soliveirajr.com/2012/11/which-one...er-java-heap-or-native-memory/[/quote]
Legal!Dessa eu não sabia!
Bem, isso é usando uma classe do pacote “sun.misc”. Portanto, não é do Java padrão.
Essa classe pode (e provavelmente não vai) existir em outras implementações da VM - mesmo entre implementações da próprio Oracle.
Fora isso, você não só usou uma classe de um pacote não padrão, como teve que acessar um método inacessível dessa classe.
Um verdadeiro hack, mas que atende mais a uma curiosidade do que a um código de produção.
[quote=ViniGodoy]Bem, isso é usando uma classe do pacote “sun.misc”. Portanto, não é do Java padrão.
Essa classe pode (e provavelmente não vai) existir em outras implementações da VM - mesmo entre implementações da próprio Oracle.
Fora isso, você não só usou uma classe de um pacote não padrão, como teve que acessar um método inacessível dessa classe.
Um verdadeiro hack, mas que atende mais a uma curiosidade do que a um código de produção.[/quote]
Vai na fé que vai estar lá sim !!! hehehe
É assim que eles devem fazer MemoryMappedFiles e DirectBuffers.
Backdoors estão aí para serem explorados. 
Como diz a música:
“They love to tell you to stay inside the lines, but something is better on the other side…”
[quote=saoj]Vai na fé que vai estar lá sim !!! hehehe
É assim que eles devem fazer MemoryMappedFiles e DirectBuffers.
Backdoors estão aí para serem explorados. :)[/quote]
Não entendo como um cara que diz isso pode não gostar de C++… você se tornaria um monstro.
[quote=ViniGodoy][quote=saoj]Vai na fé que vai estar lá sim !!! hehehe
É assim que eles devem fazer MemoryMappedFiles e DirectBuffers.
Backdoors estão aí para serem explorados. :)[/quote]
Não entendo como um cara que diz isso pode não gostar de C++… você se tornaria um monstro. :)[/quote]
Gosto de coisas com um nível de abstração alta pois não me considero possuidor de um cérebro com over-clocking.
Nessa linha te pensamento é melhor trabalhar com assembly para dominar o CPU e todo o resto.
Java está para C++ assim como C++ está para assembly.
É mais confortável e menos doloroso de programar em Java na minha opinião.
Acho que do C++ para o assembly o passo é bem maior.
Você sai de objetos e templates, direto para um código que nem sequer estruturado é.
Achei estranho pq geralmente o pessoal que gosta de hacks e exploits adora usar C++.
Afinal, você pode achar os hacks do sistema operacional, pode usar drivers nativos e tem bem mais poder de fogo para fazer coisas “não recomendadas pelo fabricante”.
Você chegou a ter alguma experiência posterior com C++, ou o seu é trauma da época da faculdade (da época que não se usava STL, boost e se manipulava ponteiros selvagemente no braço)?
[quote=ViniGodoy]Acho que do C++ para o assembly o passo é bem maior.
Você sai de objetos e templates, direto para um código que nem sequer estruturado é.
Achei estranho pq geralmente o pessoal que gosta de hacks e exploits adora usar C++.
Afinal, você pode achar os hacks do sistema operacional, pode usar drivers nativos e tem bem mais poder de fogo para fazer coisas “não recomendadas pelo fabricante”.
Você chegou a ter alguma experiência posterior com C++, ou o seu é trauma da época da faculdade (da época que não se usava STL, boost e se manipulava ponteiros selvagemente no braço)?[/quote]
Tem razão, Vini. Meu trauma é antigo. Faz muito tempo que não brinco.
Qual o livro vc recomendaria para uma cabeça-dura como eu, para aprender C++ the modern way?
[quote=saoj]Tem razão, Vini. Meu trauma é antigo. Faz muito tempo que não brinco.
Qual o livro vc recomendaria para uma cabeça-dura como eu, para aprender C++ the modern way?
[/quote]
Se quiser revisar o básico da linguagem, o principles and practices do Stroustrup:
(não confundir com o outro livro dele, que é arido de ler e fica só nos detalhes sintáticos da linguagem).
Outra opção, já que você já programa, é o Accelerated C++.
Caso você esteja sabendo a linguagem é só seguir a área “para quem sabe C++” desse roadmap:
http://www.pontov.com.br/site/cpp/46-conceitos-basicos/88-roadmap-c
Agora, se você só quer brincar um pouco de fazer aplicações, ao invés de pegar um livro de C++ puro, pegue um de QT, como esse aqui:
[quote=ViniGodoy][quote=saoj]Tem razão, Vini. Meu trauma é antigo. Faz muito tempo que não brinco.
Qual o livro vc recomendaria para uma cabeça-dura como eu, para aprender C++ the modern way?
[/quote]
Se quiser revisar o básico da linguagem, o principles and practices do Stroustrup:
(não confundir com o outro livro dele, que é arido de ler e fica só nos detalhes sintáticos da linguagem).
Outra opção, já que você já programa, é o Accelerated C++.
Caso você esteja sabendo a linguagem é só seguir a área “para quem sabe C++” desse roadmap:
http://www.pontov.com.br/site/cpp/46-conceitos-basicos/88-roadmap-c
Agora, se você só quer brincar um pouco de fazer aplicações, ao invés de pegar um livro de C++ puro, pegue um de QT, como esse aqui:
[/quote]
Valeu mestre. Eu teria muito interesse em trabalhar com non-blocking I/O, selectors, EPoll, UDP, byte buffers e networking, que é a área que eu trabalho.
Vc já viu algum livro que fala sobre isso? Vc já trabalhou com isso em C++?
[quote=saoj]Valeu mestre. Eu teria muito interesse em trabalhar com non-blocking I/O, selectors, EPoll, UDP, byte buffers e networking, que é a área que eu trabalho.
Vc já viu algum livro que fala sobre isso? Vc já trabalhou com isso em C++?[/quote]
Já sim. Uma das principais bibliotecas para isso é a boost, em especial, a boost asio:
http://www.boost.org/doc/libs/1_52_0/doc/html/boost_asio.html
Para aplicações internet based, dê uma olhada na POCO:
[quote=ViniGodoy][quote=saoj]Valeu mestre. Eu teria muito interesse em trabalhar com non-blocking I/O, selectors, EPoll, UDP, byte buffers e networking, que é a área que eu trabalho.
Vc já viu algum livro que fala sobre isso? Vc já trabalhou com isso em C++?[/quote]
Já sim. Uma das principais bibliotecas para isso é a boost, em especial, a boost asio:
http://www.boost.org/doc/libs/1_52_0/doc/html/boost_asio.html
Para aplicações internet based, dê uma olhada na POCO:
http://pocoproject.org/[/quote]
Imagino que um servidor MMOG deve usar isso tb…
Algum livro que fala sobre isso?
Provavelmente sim. Infelizmente, há pouquíssima literatura sobre o assunto. Um dos livros, um tanto superficial é:
Ele fala mais dos truques de design e da importância de um protocolo otimizado, mas não entra a fundo sobre questões de I/O não bloqueante.
Aliás, talvez um server de MMO é um local onde não vejo problemas do Java entrar. Afinal, o Java é feito com muitas preocupações de rede em mente e os problemas de latência são muito piores do que os possíveis atrasos do garbage collector.
Até agora tem sido ótima. Desenvolvi jogos educacionais pela Positivo, usei tecnologias de jogos numa pesquisa para dar acesso a surdos mudos. Organizei eventos como a Global Game Jam (que seria bom você participar na sua região) e também adoro dar aula para a moçada da área.
Sim, mas não tantas. O mercado tem crescido nas empresas de treinamento, simulação e games educacionais. Melhorou muito nos últimos anos, após o governo finalmente entender que games não são necessariamente jogos de azar, o que permite-nos agora conseguir investidores e financiamentos com mais facilidade.
Também melhorou bastante com a distribuição da apple store, steam e Play market. Mas a parte de entretenimento ainda engatinha no Brasil.
O que não ajudou muito foi o projeto Jogo Justo, que é um projeto exclusivamente para lojistas. Eles queriam até impor impostos sobre a distribuição eletrônica, para evitar “competição desleal”.
É importante mostrar um bom portifólio. O mercado internacional está bem aberto para contratação de programadores pelo mundo. Talvez o SaoJ possa falar sobre aceitação bem melhor do que eu.
Sim, especialmente se você almeja ir para o exterior.
Ajudaria você pegar uma pós, como a que oferecemos na PUC, para conhecer melhor as várias tecnologias da área e se focar em uma delas.
Um dos nossos professores foi ex-funcionário da EA, e todo inicio de curso dá uma palestra sobre o que é trabalhar no exterior. Também não é o mar de rosas que todo mundo acha.
Sim. Entretanto, você deve ter plena consciência de que fazer jogo é uma profissão. Trabalha com tecnologias interessantes, mas ainda é um trabalho.
Você quase nunca fará os jogos que irá jogar. Você terá objetivos, prazos, metas. Você terá bugs para corrigir, logs para analisar. E pode ser que faça um ponto do jogo pouco interessante, como o módulo que controla os scripts do jogo.
A menos que esteja num estúdio pequeno, você também não será o criador da história, pois os papéis são divididos. A parte de produção fica com o game designer, roteiristas e com artistas.
Não pense na área com glamour, pois é um passo certo para você quebrar a cara.
Por outro lado, é certamente um dos ramos mais interessantes (e difíceis) tecnicamente. Quantas aplicações você conhece que misturam ao mesmo gráficos, rede, som, inteligência artificial, tempo real, multi-processamento e ainda trabalham com tecnologia de ponta?
PS: Vi no seu histórico que há um mês atrás você pensou em se matricular na especialização em POA. Não conheço muito o curso de lá, mas é um bom passo fazer um curso como esse. Ainda que você não trabalhe com jogos, vai conhecer várias tecnologias e formas diferentes de encarar problemas. Muitos alunos, pelo menos da PUC, elogiam o curso porque os tornaram programadores melhores, mesmo fora dos games.
[quote=ViniGodoy]
Uma alternativa similar que vem se destacando é o C#. Seja no XNA ou na API do Windows 8[/quote]
Uma duvida ViniGodoy,
A própria Microsoft vem desencorajando o uso de qualquer linguagem que não seja o C++ para a criação de jogos para Win 8 e posterior venda na Windows Store.
Quem usa C# tem que apelar para soluções como o Monogame ou SharpDX.
Tá certo que o Monogame parece ser a indicação da Microsoft para substituir o XNA, mas msm assim é uma situação parecida que acontece com o Java hoje para jogos.
E o XNA é limitado no Win 8.
Qual é essa solução da API do Win 8 ou WinRT usando o C#?
Confesso que não pesquisei o assunto com mais profundidade, por isso a duvida, já que não é primeira vez que o vejo citando algo do tipo.
Olha, desculpa pelo off-topic…
De onde você tirou que ela está desencorajando? No site da MS, há diversos e diversos artigos sobre games em C# e JavaScript:
http://msdn.microsoft.com/en-us/library/windows/apps/hh452780.aspx
A recomendação é para o “hardcore”. Que aliás, nunca foi diferente. Mesmo com o XNA, o hardcore sempre se manteve com C++ e DX.
E, sim, no caso para Windows 8 eu estava falando que se pode usar C# com WinRT.
Agora, é difícil falar em Windows 8, pois esse foi um passo bastante significativo da Microsoft. E acho que ainda não está completo. Muita coisa mudou para a introdução da interface Metro.
Mas a situação não tem nada de parecida do Java. Primeiro de tudo, a Microsoft apoia ativamente a indústria, e promove o C# para jogos.
Ela descontinuou uma de suas soluções, o XNA, mas não o C#, nem o DirectX. O C# continua sendo a linguagem principal do Windows Phone 8, continua sendo usado no Playstation Suite, continua valendo para o X-Box e continua como linguagem principal da Unity. Isso o torna uma linguagem muito mais interessante que o Java, que luta bravamente no Android.
Quanto à “morte” do XNA… vale lembrar que boa parte do XNA era, na verdade, implementação do DirectX, como a biblioteca XNAMath, ou mesmo as bibliotecas de Audio.
Ele é feito originalmente para C++, mas como roda sobre RT, pode ser acessado via C# ou JavaScript.
A Microsoft estimulou a criação do DirectX Toolkit, que é uma implementação de parte das classes do XNA em C++:
Como eu falei um pouco antes, o C++ é, e continua sendo, a linguagem mainstream para games. Mesmo no auge do XNA, a Microsoft nunca deixou de suportá-lo. E não creio que vá deixar tão cedo.
Particularmente, eu até preferiria que a MS focasse seus esforços em tornar o DirectX um pouco mais amigável (por exemplo, abandonando aquela convenção de nomes detestável e usando recursos mais novos do C++).
PS: Quase me esqueço. Uma coisa que não suporto da MS, e no caso do WinRT eles tem feito com muita freqüência, é chamar aquela bizarrice de “managed C++” de C++. Não é do “managed C++” que estava falando no post anterior quando disse em recursos mais modernos da linguagem, e sim, das evoluções do C++11 oficial (lambda, smart pointers, etc).