• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

yschmitzz

Progrmação de jogos com C++

27 mensagens neste tópico

bom, to aprendendo a programar em win32

mas to com uma duvida

pra mim, nao é necesario saber a parte do windows form pra programar jogos?

estou certo?

caso sim

eu devo me expecializar nessa area da ficar fazendo console?

mas espero tambem programar windows form em C++ xD

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Deves ficar com a consola até aprenderes a linguagem. Depois muitas destas questões irão desaparecer por si próprias porque tu próprio perceberás as respostas.

Mas para deixar isto bem claro de uma vez por todas:

- Windows Forms não é C++. Ponto. Tu não programas Windows Forms com C++. C++ e Windows Forms não têm nada a ver um com o outro. Windows Forms não é igual a C++... et cetera. Windows Forms é usado com C#. Não estou zangado contigo. Estou zangado com a Microsoft e pela forma como esta criou o Visual Studio Express que tem criado uma confusão tremenda na cabeça de iniciantes à linguagem como eu nunca antes vi. O Visual Studio C++ Express Edition é o grande responsável por esta confusão.

- Windows Forms inclusivamente poderá vir a ser descontinuado em próximas edições da .Net Framework (o que já começa a ser um costume com a Microsoft que leva a uma total descrença nas tecnologias propostas por esta empresa se continuam a avançar com plataforma tecnológicas, anunciá-las como a melhor coisa do mundo e depois abandoná-las porque afinal não eram tão boas assim). A Microsoft desenvolveu A Windows Presentation Foundation (WPF) para eventualmente substituir Windows Forms. Esquece Windows Forms, se queres programar em C++ e mesmo se queres programar em C#.

Entretanto não aprendas a programar Win32 ainda. É programação avançada. O C++ exige estudo, e muita dedicação. Obriga a paciência também. E obriga a uma disciplina de estudo que deverá ser seguida com algum rigor. Já te disse antes e volto a dizer; o teu objectivo agora não deve ser aprenderes a fazer jogos, ou aprenderes a programar para Windows, ou outra coisa qualquer. O teu objectivo agora é aprenderes a programar em C++. Isto implica conheceres a linguagem de programação, o que ela te oferece e quais as ferramentas ao teu dispor.

Se achares que não estás disposto a oferecer pelo menos 1 ano da tua vida a aprenderes estas coisas antes de te num projecto, então sem dúvida aconselho-te a esqueceres o C++. C# será uma melhor alternativa para ti. Poderás começar logo a programar para Windows. Tenho quase 15 anos de experiência com o C++ (com alguns intervalos pelo meio). Só ao fim de 2 anos de aprendizagem desenvolvi o meu primeiro projecto sério e com 15 anos ainda hoje estou a aprender coisas novas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Entretanto não aprendas a programar Win32 ainda. É programação avançada. O C++ exige estudo, e muita dedicação.

mas aquele seu tutorial nao é de win32??

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

mas aquele seu tutorial nao é de win32??

Oh, não, não.

Ui! A confusão que vai para aí yschmitzz :)

Aquele tutorial é sobre C++. Para programares em Win32 terás que incluir a <windows.h>. Vamos lá a ver se explico isto um pouco melhor...

Quando se diz programar para Win32, significar programar para a Windows API que é um conjunto de classes, funções, objectos e constantes pertencentes a uma biblioteca que te irão permitir programar para o ambiente Windows. "Ambiente" aqui quer dizer fazer janelas, butões, etc...

Ora esta biblioteca é comummente conhecida como Win32 API e tem como ficheiro header principal <windows.h>. Existem outras formas de programar botões e janelas em C++. Com o Visual Studio Professional Edition é possível usar MFC (Microsoft Foundation Classes). Isto é uma outra biblioteca que pega na biblioteca Win32 API, "mete-a numa caixa", e organiza as coisas de forma a tentar tornar o desenvolvimento para Windows um pouco mais fácil (uma vez que programar directamente com a Win32 API é realmente complicado e obriga a escrever muito código). Isto de meter a Win32 API "numa caixa", é conhecido como library wrapping. Ou seja o MFC é um wrapper à volta da Win32 API. Também poderás ouvir, o MFC é uma framework ou ainda o MFC encapsula o Win32API.

Existem também bibliotecas que não tem nada a ver com a Microsoft mas que fazem essencialmente o mesmo que o MFC. o WxWidgets e o Qt são exemplos de duas outras bibliotecas que te permitem programar janelas, botões e outros controlos para Windows.

Ora existe depois a noção de "programação para windows" que precisas de ler com cuidado nesta fase até teres mais conhecimentos para saberes perfeitamente o que o autor daquela expressão poderá estar a dizer. Programação para Windows poderá querer dizer duas coisas; programar janelas e essas coisas, ou fazer programas que sejam compatíveis com o sistema operativo Windows. E isso inclui programas para a consola.

O tutorial de que falas é um tutorial de C++. Na realidade aquele código poderá ser usado sem qualquer alteração em qualquer sistema operativo que ofereça um compilador C++. É um tutorial de C++ que procura explicar algumas coisas do C++ utilizando o Visual Studio. Estarás a programar para a consola naquele tutorial. Um dia quem saiba talvez faça um para o WxWidgets que é a biblioteca que uso para programação de janelas e afins para o Windows, linux e Macintosh.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

- Windows Forms não é C++. Ponto. Tu não programas Windows Forms com C++. C++ e Windows Forms não têm nada a ver um com o outro. Windows Forms não é igual a C++... et cetera. Windows Forms é usado com C#. Não estou zangado contigo. Estou zangado com a Microsoft e pela forma como esta criou o Visual Studio Express que tem criado uma confusão tremenda na cabeça de iniciantes à linguagem como eu nunca antes vi. O Visual Studio C++ Express Edition é o grande responsável por esta confusão.

C++/CLI ainda é C++, como VB.NET ainda é VB, e Delphi ainda é Pascal. Programar Forms em C++ é possível na variante C++/CLI. Concordo é que win32 e Windows Forms não têm nada a ver uma coisa com a outra (ainda que os Forms sejam o encapsulamento retorcido do win32 :) ).

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

C++/CLI ainda é C++, como VB.NET ainda é VB, e Delphi ainda é Pascal.

Uí! Terás à perna uma data de gente :)

C++/CLI não é C++. Isso te garanto. Basta tentares compilar o código com o gcc. O C++/CLI poderia ser entendido como uma extensão ao C++... introduzia novos conceitos como a tal história das versões safe de algumas funções, por exemplo. Mas mesmo assim isso imediatamente colocaria o C++/CLI como uma linguagem não-C++ porque eliminaria a componente General-Purpose do C++.

Mas o C++/CLI faz mais do que isso. Mudou também a sintaxe da linguagem em algumas áreas, por exemplo:

//c++
int foo = 23;
int* ptr = &foo;

//C++/CLI
int foo = 23;
int^ ptr = &foo;

O C++/CLI inclui também sintaxe própria para lidar com o seu garbage collector:

class foo {
    public:
        !foo(); // destructor (não-deterministico)
    /* ... */
}

... e muitas, muitas, outras alterações à sintaxe e modelos de desenvolvimento. Na realidade, o C++/CLI tem o seu próprio standard independente do C++ em ECMA-372. Agora o Managed C++ que foi deprecado pelo C++/CLI é que poderia ser eventualmente entendido como um superset do C++, mas o conceito ainda assim está errado. O que o MC++ era essencialmente era um conjunto de extensões que lhe permitiam ligar-se directamente com código C++ nativo e C#. Era essencialmente uma ponte entre os dois e nunca chegou a tonar-se uma linguagem de programação completa.

...

Quanto a Delphi - Pascal e VB - VB.Net... entendo o argumento. Mas não só não concordo com ele, como não consigo relacionar com o C++ - C++/CLI

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu não disse que eram compatíveis, tenho bem presentes as diferenças entre as duas. Apenas disse que C++/CLI é uma variante (ou, como disseste, uma extensão. Ou ainda, uma degeneração :) ) de C++. Tem C++ no nome, é C++, e é por aí que se pode programar Forms com C++.

A sintaxe e as características não são iguais nem compatíveis, mas o nome está lá.

Ia dizer que chega de offtopic, mas afinal não é offtopic :D

E acrescento ainda que acho que foi uma manobra de marketing horrorosa da parte da Microsoft chamar C++ a esta linguagem. Horrorosa e que provavelmente falhou, porque os programadores de C++ que pegaram na linguagem para experimentar devem ter-se sentido frustrados. Eu pelo menos senti...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

E acrescento ainda que acho que foi uma manobra de marketing horrorosa da parte da Microsoft chamar C++ a esta linguagem. Horrorosa e que provavelmente falhou, porque os programadores de C++ que pegaram na linguagem para experimentar devem ter-se sentido frustrados. Eu pelo menos senti...

Desculpem lá a ignorância mas estão a falar de Visual C++ (a linguagem propriamente dita), não é? É que com tanto vocabulário novo (pelo menos para mim) torna-se um pouco difícil acompanhar o desenrolar do tópico...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Nope.

O Visual C++ não é uma linguagem de programação. É o nome do compilador C++ da Microsoft (VC++). Estamos a falar do C++/CLI e do MC++ incluídos no Visual Studio 2005 e 2008.

Desde que o Visual Studio C++ 2005 Express Edition saiu que notei de imediato nos forums em que participo e na USENET um novo problema. Os iniciantes à programação em C++ que naturalmente adoptaram este IDE ficavam muito confusos com a forma como criavam projectos C++. Coisas como Managed C++ (que não é C++)  não estar bem definido na criação de um projecto; Um projecto puro C++ é definido como sendo Win32... o que não poderia estar mais longe da verdade; A inclusão de projectos CLR (que também não são C++) que têm consola e o tal Windows Forms... E tudo isto dentro de um mesmo cabeçalho -- Visual C++.

Para um utilizador conhecedor, nada isto é um problema. Mas para um iniciante à linguagem de programação C++ isto é uma fonte impressionate de confusão e natural irritação. A razão porque o fizeram fica por discutir. Tenho aqui a mesma opinião que o TheDark -- uma manobra de marketing, quiçá para levar mais pessoas a adoptarem a plataforma .Net que eles querem impingir a toda a força.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Nope.

O Visual C++ não é uma linguagem de programação. É o nome do compilador C++ da Microsoft (VC++). Estamos a falar do C++/CLI e do MC++ incluídos no Visual Studio 2005 e 2008.

Desde que o Visual Studio C++ 2005 Express Edition saiu que notei de imediato nos forums em que participo e na USENET um novo problema. Os iniciantes à programação em C++ que naturalmente adoptaram este IDE ficavam muito confusos com a forma como criavam projectos C++. Coisas como Managed C++ (que não é C++)  não estar bem definido na criação de um projecto; Um projecto puro C++ é definido como sendo Win32... o que não poderia estar mais longe da verdade; A inclusão de projectos CLR (que também não são C++) que têm consola e o tal Windows Forms... E tudo isto dentro de um mesmo cabeçalho -- Visual C++.

Para um utilizador conhecedor, nada isto é um problema. Mas para um iniciante à linguagem de programação C++ isto é uma fonte impressionate de confusão e natural irritação. A razão porque o fizeram fica por discutir. Tenho aqui a mesma opinião que o TheDark -- uma manobra de marketing, quiçá para levar mais pessoas a adoptarem a plataforma .Net que eles querem impingir a toda a força.

Tinha a ideia de que, tal como existe visual basic, também havia visual c++...

Já agora, se não for esticar-me muito nas perguntas, o que é isso da plataforma .NET (além de uma coisa que a M$ criou para lixar quem estava a aprender VB6 na altura como eu)?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Já agora, se não for esticar-me muito nas perguntas, o que é isso da plataforma .NET (além de uma coisa que a M$ criou para lixar quem estava a aprender VB6 na altura como eu)?

Hehe, tem piada que o digas dessa forma. :)

Também achei terrível a perca do VB. Durante muitos anos foi uma linguagem de desenvolvimento indispensável na criação de aplicações de apoio à empresa e na criação de aplicações de pequenas e médias dimensões. O VB teve o dom de popularizar o conceito de Programação talvez mais que que qualquer outra linguagem nos últimos 30 anos. Acabar com uma linguagem de programação é realmente algo que só poderia passar pela cabeça de uma empresa privada e detentora dos direitos. Tivera o VB sido aberto ao público e hoje tenho a certeza que uma comunidade vasta estaria a suportar o VB e a continuar o desenvolvimento do Core. Poder-se-á argumentar que o VB sobreviveu através do VB.Net. Mas a única coisa realmente que sobrou foi a sintaxe... e ainda assim existem muitas diferenças. O VB.Net não tem hoje nada a ver com o VB. E já se percebia que não ia quando à cerca de 8 anos foi lançado o primeiro beta da .Net framework. (Ainda tenhos os 2 CDs por aí algures, quando era subscritor do MSDN).

Bom, em relação ao .Net Framework....

Não te vou explicar ao detalhe do que se trata. Para isso poderás começar por aqui: http://en.wikipedia.org/wiki/Microsoft_.NET#Microsoft_.NET

Mas compreendo que muitas vezes as explicações formais de tecnologias emergentes sejam demasiado complexas para um leigo. Eu próprio não percebo por vezes metade do jargon utilizado por muitos destes websites e pior pelos documentos emitidos pela própria Microsoft (e suspeito que ninguém percebe). Portanto vou-te explicar o que é a .Net Framework em termos simplistas e com essas noções poderás pelo menos melhor compreender o que leres por aí.

A .Net Framework (daqui em diante .Net) é uma ideia excelente e foi muito bem concebida. Disso não tenho dúvidas. Tenho uma só critica a fazer-lhe e é uma crítica importante. Mas fica para o fim. A .net é essencialmente um wrapper à volta do Kernel do Windows. Isola o coração do Windows e os programadores comunicam com ela. É ela que depois diz ao Kernel o que fazer. Assim um programador está completamente liberto de todas as considerações em relação ao hardware, e tem à sua disposição uma biblioteca única para programar em qualquer linguagem de programação que a suporte. Claro está que é muito mais do que isso. É também um conjunto vasto de soluções únicas para problemas de programação, desde protecção de memória a desenvolvimento em multithreads.

Porque a .net mete um saco de plástico à volta do Kernel do Windows, pode fazer coisas muito importantes em termos de segurança do sistema operativo. Este é um dos aspectos mais importantes da .net. Com alguma dose de bom-senso poder-se-á afirmar que programas desenvolvidos para a .net são extraordinariamente seguros em termos do que podem e não podem fazer ao Sistema Operativo. É muito difícil, se não praticamente impossível, um programa destes criar instabilidade ao sistema operativo.

Finalmente, a .net define uma série de standards comuns a praticamente todos os sistemas operativos. É concebível portanto olhar para a .net como portável para vários sistemas operativos. Significa que o meu código C# poderá correr em Linux, Macintosh, Solaris, et cetera, se estes sistemas implementarem .net. É o que acontece hoje com o projecto Mono no Linux que permite correr código .net para windows no linux, e para linux no windows. Portabilidade é no entanto uma área complexa e existem muitas partes do .net que ainda não são suportadas pelo Mono, pelo que a compatibilidade do código é ainda limitada.

A ideia por detrás da .net é esta: Se todos os programadores para windows desenvolverem em linguagens de programação .net, o sistema operativo está protegido, a sua segurança está garantida e consequentemente a sua estabilidade aumenta. Daí esta tecnologia ser tão importante para sistemas em plataforma Windows onde a integridade dos dados e dos sistemas seja um factor crucial. Entretanto se todos os programadores Windows desenvolverem para a .net, a Microsoft terá mais facilidade em efectuar todo o tipo de alterações ao Core do Windows sem que isso tenha impacto no código existente. Presentemente este é o grande problema do Microsoft Windows. O seu Kernel e a API são antigos, velhos, cansados e precisariam de uma grande remodelação. Mas isto é muito difícil de fazer porque muito código existente deixaria de funcionar. Mas se a única coisa que os programadores tinham acesso era à .net, então a Microsoft estaria livre para mexer no Core sempre que quisesse e bem lhe apetece-se.

E prontos. Qual é a minha critica?

A .net é completamente fechada sobre si mesma. Impõe ao programador um conjunto de linguagens e não permite o desenvolvimento de hooks para outras linguagens de programação. Apesar do CLI estar especificado e ter o seu próprio standard -- o que torna concebível o desenvolvimento de movas linguagens que suportem a .net -- não suporta, e provavelmente nunca suportará linguagens existentes ou outras que venham a ser desenvolvidas. Outros sistemas operativos preferem implementar os seus sandboxes (áreas protegidas) a nível do core. A .net decidiu-se por fazê-lo a nível da linguagem de programação. Isto na minha opinião é errado. A esperança da .net resolver os problemas de segurança e estabilidade do Windows é fortemente reduzida porque linguagens que o possam afectar não têm como tirar partido da sandbox da .net. Ou seja, em termos práticos a .net não resolveu nada.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Grande explicação! Só acrescentaria que se assemelha muito em função à plataforma Java, embora com um nível superior de flexibilidade, pelo menos no que toca a linguagens de programação, uma vez que Java apenas permite programar numa linguagem (obviamente, Java), e .NET permite (até ao momento) várias linguagens, entre as quais (que me lembre):

- C# : a principal e mais importante das linguagens da plataforma, porque é a que tem implementada a maior fatia do standard .NET;

- VB.NET;

- C++/CLI;

- Python;

- possivelmente outras...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Muito obrigado pela explicação. Oxalá um dia te possa agradecer da mesma forma (sonhando...). Força, continua com o bom trabalho.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

A .net é completamente fechada sobre si mesma. Impõe ao programador um conjunto de linguagens e não permite o desenvolvimento de hooks para outras linguagens de programação. Apesar do CLI estar especificado e ter o seu próprio standard -- o que torna concebível o desenvolvimento de movas linguagens que suportem a .net -- não suporta, e provavelmente nunca suportará linguagens existentes ou outras que venham a ser desenvolvidas.

Existem vários linguagens desenvolvidas para a plataforma .NET. Estou-me a lembrar de Boo, IronPython e IronRuby. No caso do IronPython mais tarde a Microsoft até contratou quem estava por trás do projecto para dar continuidade ao seu desenvolvimento. A Microsoft também está a desenvolver um port de Ruby para .NET, chamado IronRuby. Por isso não é verdade que a Microsoft não suporte outras linguagens.

Por fim também gostava de referir que a Microsoft abriu o código fonte da plataforma .NET, embora nuna licença restrictiva. Mas penso que isto mostra alguma boa fé por parte da empresa em mudar algumas das suas práticas. Aliás, todas as outras linguagens que referi anteriormente desenvolvidas pela Microsoft utilizam uma licença BSD, salvo erro.

Grande explicação! Só acrescentaria que se assemelha muito em função à plataforma Java, embora com um nível superior de flexibilidade, pelo menos no que toca a linguagens de programação, uma vez que Java apenas permite programar numa linguagem (obviamente, Java)...

http://en.wikipedia.org/wiki/List_of_JVM_languages

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Existem vários linguagens desenvolvidas para a plataforma .NET. Estou-me a lembrar de Boo, IronPython e IronRuby. No caso do IronPython mais tarde a Microsoft até contratou quem estava por trás do projecto para dar continuidade ao seu desenvolvimento. A Microsoft também está a desenvolver um port de Ruby para .NET, chamado IronRuby. Por isso não é verdade que a Microsoft não suporte outras linguagens.

A questão é que as linguagens têm de ser desenvolvidas para suportar .net. A .net não expõe hooks para linguagens existentes desenvolverem bibliotecas de acesso.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

A questão é que as linguagens têm de ser desenvolvidas para suportar .net. A .net não expõe hooks para linguagens existentes desenvolverem bibliotecas de acesso.

Isso não será por questões de segurança? Admito que não percebo muito das entranhas da plataforma .NET para discutir isto com alguma segurança do que estou a dizer...

Mas a linguagem não tem de fazer output de código CLI para poder correr na .NET VM? Logo qual é o sentido de expor hooks? Ou queres dizer hooks para usar as bibliotecas de .NET utilizando linguagens non-managed? :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Precisamente. Derrotaria a segurança imposta pela .Net. Não será possível desenvolver esses hooks porque o programa resultante teria mesmo assim de correr no .Net sandbox, o que nunca poderia acontecer numa linguagem unmanaged ou numa linguagem com a sua própria VM. Daí afirmar que não existem nem provavelmente alguma vez existirão.

Portanto a .net oferece um esquema de desenvolvimento para Windows paralelo a muitos outros. O Core do Windows está apenas protegido por quem utilize ferramentas de desenvolvimento .net. Porque o sandbox existe num layer acima do Sistema Operativo e porque é disponibilizado através de uma VM, a possibilidade de a Microsoft proceder a alterações de fundo ao seu Kernel ainda se encontra limitada. O ideal seria que o maior número possível de programadores usassem .Net  e que pouco a pouco a redução de código unmanaged justificasse finalmente uma versão do Windows totalmente remodelada.

Mas isso dificilmente acontecerá. A adopção do .Net tem sido relativamente lenta. Percebe-se facilmente. Basta entrar numa loja de software. Depois existe pelo menos  uma área importante de desenvolvimento para a qual o .net ainda não está a conseguir responder: O desenvolvimento 3D.

A minha critica centra-se portanto no facto de que o .net, não resolveu ainda nem resolverá o problema de se criar um Sistema Operativo altamente maleável. É uma vasta plataforma com imensas vantagens em muitas áreas de desenvolvimento. Não me passaria pela cabeça hoje por exemplo desenvolver uma aplicação (que corresse apenas em Windows) em C++. Não faz sentido excepto se a aplicação for 3D (e vamos lá ver como o XNA evolui. Presentemente ainda não serve). Tenho todo o interesse portanto em aprender o mais rapidamente possível C# e C++/CI. Principalmente a última porque acredito que será por aqui que muita coisa acontecerá.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Já percebi o que queres dizer.

Também tenho andado atento ao XNA, e parece-me uma plataforma bastante atraente. Não sei se já programaste em C#, mas é uma linguagem muito mais fácil de usar do que C++, e sendo garbage collected não tens que te preocupar com memory leaks.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Interessante. Não fazia ideia. Isso é suportado pela Sun?

Sim.  Esta diversidade de linguagens melhora todo o eco-sistema à volta da plataforma Java. Basta compilares uma linguagem para Java bytecode, e automaticamente todas as outras linguagens podem aceder a APIs criadas nessa linguagem. Na plataforma .NET funciona de forma semelhante. Basta navegares pela documentação do Java que encontras vários livros sobre o funcionamento da plataforma, especificações de bytecode, etc.

E mesmo que não seja suportado, a plataforma Java é free software, não sendo necessário o suporte da Sun.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

E mesmo que não seja suportado, a plataforma Java é free software, não sendo necessário o suporte da Sun.

Pois claro. Mas dá sempre jeito :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Também tenho andado atento ao XNA, e parece-me uma plataforma bastante atraente.

Vamos ver se passa a ser um pouco mais do que isso :)

Presentemente é ainda um thin layer do ActiveX o que realmente não ajuda muito para programação 3D mais avançada como a exigida pelos jogos dos dias de hoje devido à quebra de performance (aqui sim a performance é um factor) a que o .net obriga.

Não sei se já programaste em C#, mas é uma linguagem muito mais fácil de usar do que C++, e sendo garbage collected não tens que te preocupar com memory leaks.

Já brinquei um pouco com C# sim. Mas nada de especial :( Terei que estudar a linguagem a fundo ainda. No entanto estou um pouco dividido entre C# e C++/CLI. Não sei... penso que C++/CLI ainda vai dar muito que falar e é por aí que muitos programadores C++ vão querer entrar e fixar-se. Se não repara:

  • Total suporte CLI. O MC++ não tinha nem de longe.
  • Semantica C++ suportada. Templates e destructors deterministicos continuam a funcionar. Ainda mais fantástico porque os posso misturar com Generics e non-deterministic destructors. Eu até posso declarar um type .Net no stack! Isto ainda é melhor que C#! hehe
  • Por causa disto tenho um maior controle sobre como quero atacar a minha aprendizagem .Net utilizando ao máximo os meus conhecimentos C++
  • E porque C++/CLI é agora totalmente suportada, não terei necessidade depois partir para outros soluções como C#. E se tiver que o fizer por necessidade, já o farei com muito mais à vontade, resolvo o problema em mãos, e depois vlto para o C++/CLI.

O C# é ideal para quem se inicia no .Net sem um background C++. Mas para tipos como eu para quem o C++ tem sido a sua principal companhia nos últimos 15 anos, C++/CLI é muito mais sexy. Se bem que, em abono da verdade, o meu interesse resume-se a questões curriculares. O meu desenvolvimento tradicional manter-se-á C++ porque não concebo a ideia de desenvolver software exclusivo para o Windows excepto quando tal me for exigido.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Vamos ver se passa a ser um pouco mais do que isso :)

Presentemente é ainda um thin layer do ActiveX o que realmente não ajuda muito para programação 3D mais avançada como a exigida pelos jogos dos dias de hoje devido à quebra de performance (aqui sim a performance é um factor) a que o .net obriga.

A grande vantagem do XNA, a meu ver, é poderes correr aplicações desenvolvidas no Zune, Xbox 360, e no PC. Tudo com o mesmo código. E ainda podes distribuir as tuas aplicações no XNA Creators Club. Sem aprovação da Microsoft. A comunidade é que decide quais aplicações estão aptas para distribuir.

XNA e C# tem performance mais que suficiente para os jogos desenvolvidos hoje em dia. Repara nas dezenas de jogos que são feitos em Flash, Java, Python, etc... O que tu deves queres dizer é que não tem performance para jogos AAA, mas mesmo que tivesse nunca vai ser usada nesses casos, pois esses jogos são quase sempre desenvolvidos para consolas, onde o C++ é rei.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Hmm... não somente Triple A. Aplicações como o Celestia são também afectadas. No fundo todo o tipo de aplicações, jogos ou não, com uma altas exigências 3D sofrem um impacto na performance apreciável e notório em C#. Claro está que outras aplicações com menos exigências, mas mesmo assim 3D podem ser desenvolvidas. Mas não pssa pela cabeça de ninguém desenvolver o Celestia, Stellarium, o Sins of Solar Empire, ou o Galactic Civilizations II em Java, Flash, Python ou C#. E estas não são aplicações Triple-A.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Marfig, já fizeste testes para dizer isso?

Nem vejo porque não haveria de ser capaz de fazer aplicações exigentes em 3D. Pelo que tenho visto, C# é 10-15% mais lento que C++. E depois de enviares os dados para a API gráfica, o resto da magia acontece na placa gráfica. Claro que existe algum processamento que tem de ser feito, mas não vejo porque C# não consiga dar conta do recado.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora