Discussão |
| |
|
| Abdalla |
Novo Video demonstrativo da Engine:
|
| Abdalla |
Video demonstrativo da Engine rodando em um Pentium 4 (placa de video onboard).
Testado propositalmente sob estas condições porque o objetivo da Engine é rodar tanto em ambientes limitados como sistemas mais sofisticados.
|
| Abdalla |
Olha, eu acho importante uma Engine dispor de uma simples linguagem de script.
Mas, francamente, quem programa SÓ java, muito provavelmente nem está na area de prog. jogos. tá bem mais pra TI
Se fosse programar um jogo, crieo que deve pensar em linguagens como C++, C#, Lua...
Linguagens como Java, .NET são voltadas para TI...
A nossa Engine tem sim um diferencial, ainda não revelei, por questão de "marketing", mas o diferencial não está na linguagem, que realmente será lua pela simplicidade e extrema eficiencia comparada com outras linguagens de script.
Ah, não sei se ficou claro mais, temos 2 publicos alvos: Amadores e Empresas
Amadores = Jovens que querem criar jogos 3D de qualidade com o minimo de esforço possivel e com rapído aprendizado.
Empresas = Com uma equipe que exige recursos mais avançados via programação de script.
Um programador de jogos que trabalha numa empresa e não sabe C++, pelo amor de deus como alguem o contratou ??
O pré-re... |
| Bitetti |
Kra, eu migrei tudo pro Gamekit ele já vem até c um editor.
Tudo é em Lua e já vem com uma boa estrutura de programação.
|
| mcunha98 |
Justamente a falta delas !
Tua engine se assemelha muito com o Ogre, estude-o e você verá que houveram versões/ports para outras linguagens pois são poucos que trabalham com C/C++ e se trabalhar provavelmente esteja em um nível tão jedi que não precise de uma engine.
Fazer sua engine trabalhar com outras linguagens é um excelente ganho pois garante a vida útil dela. Limitar a Lua com C++, bom...existem vários sistemas que já fazem essa dupla, visite este link:
|
| Abdalla |
Sobre o SQLite, entendo, interessante podemos usar então o SQLite ao invés do MySQL, vamos dar uma pesquisada sobre isso.
Sobre os Datafiles, como eu disse antes, nosso objetivo é não obrigar, mas possibilitar que o usuário da engine consiga manipular tantos formatos abertos e difundidos quanto ao nosso proprio formato criptografado e compactado.
Sobre a escolha da linguagem é o seguinte: A Engine está sendo feita toda em C++, OpenGL e GLSL...
A Engine possui um Level Editor junto a um script editor, para a logica do jogo (esse será provavelmente em LUA).
O objetivo é tornar a programação o mais proximo do visual possivel, claro que possibilitamos a programação direta em código (pois o level editor gera um script automático), mas ele em si já contém muitas ações que antes, eram exclusivas ao script.
Agora eu não entendi muito bem isso:
Como assim colocar Java numa Engine 3D para PCs e consoles ?
Desculpe minha ignorancia, mas qual sera o ganho com... |
| ferat |
Mano, quanto a criptografia, eu utilizo uma técnica própria. Eu chamo de "desvio". Tipo, se tenho um objeto .md2, eu abro ele no TSP Desv, e salvo como .tmda. Praticamente é o mesmo arquivo, com algumas trocas de ordem binária. Eu acho que, como no seu caso, talvez um hacker chinês consiga quebrar o sigilo. Mas, é um q a mais de segurança, né?
Já para arquivos .tga, não consegui fazer o mesmo! Ficam tudo a mostra na pasta de texturas.
T+ |
| mcunha98 |
O MySQL requer um "server" rodando em localhost, ouvindo em portas e tendo algo mais parrudo do que você necessita (como guardar configs locais), por isso compensa (e muito) usar SQLite, ele é embarcado em vários softwares de peso (como o Firefox) e vale muito a pena ser usado por ser rápido e simples (mais que o mySQL).
Sem dúvida a palavra aqui no caso de relevância é a leveza e velocidade do SQLite, existem comparativos que demonstram claramente quando optar por um ou por outro.
Seu comentário sobre usar datafiles me lembrou muito o Blitz Basic (de novo), eles também cometeram esse "deslize", claro, talvez pecando pelo excesso do que por outra coisa. Uma coisa que é legal sim de se pensar, é como era nos velhos e bons tempos do Quake, e vocês poderiam sim é trabalhar com a leitura de um arquivo "datafile" como por exemplo os famosos pk3 (padrão quake) que tinham pastas específicas lá dentro com vários arquivos de textura (jpg, png, etc...) e também de modelos (... |
| Abdalla |
a animação que no caso é esqueletal não foi afetada pela escolha do formato, que ainda continua válido.
Quando disse que tinhamos muito trabalho para incluir isso no deadline, me referia aos diversos tipos de formatos, por isso pretendemos selecionar nichos menores.
Mas como eu disse antes, gostei da sugestão do FBX, apesar de não conhecer bastante sobre esse formato (e olha que conheço muitos formatos usados pela maioria das engines).
Obrigado pela força, postaremos futuros avanços |
| mcunha98 |
Talvez se tivesse priorizado entender os formatos mais aceitos e padronizados no mercado teria economizado um baaaita tempo inventando a roda de keyframes, vertex morph, etc...
Teu trabalho é extremamente admirável, como qualquer projeto, decisões importantes podem ter sido feitas de maneira equivocada, torço pelo seu sucesso e principalmente que esta ferramenta se torne acessível para competir de frente com gente grande (veja um pouco sobre o Sculptris, sua iniciativa me lembra a do Dr. Pepper, que sozinho se deu bem fazendo algo que foi "moldado" junto com os usuários).
Sucesso para teu projeto ! |
| Abdalla |
puts, obrigado mesmo pelas sugestões.
Vamos as respostas:
- Bump Mapping Já foi implementado (1º Screenshot)
- SOM, claro, não foi dito, mas é obvio que iremos implementar (por ultimo) som 2D e 3D. O planejado é carregamento de: WAV, MIDI e OGG (mas eles serão criptografados e compactados dentro de um Datafile).
- Bom, realmente o FBX é um formato de intercambio. Mas de todos os formatos que conheço, o mais simples de editar materiais é o OBJ, tanto que ele é em arquivo texto mesmo, e qualquer modelador decente tem um exportador pra OBJ.
O Objetivo é usar um conversor proprio da engine para criptografar os modelos e impedir o acesso (é obvio que um chines maluco por engenharia reversa vai conseguir quebrar) mas o objetivo é tentar colocar algo o mais proximo do seguro.
Realmente como vc disse, Não temos o objetivo de importar 3DS, MD2, MD3, LWO, PLY, RAW e variações... pois como eu disse o objetivo é usar o proprio tipo de modelo, alem do mais temos mui... |
| Bitetti |
sugestão:
.MySQL é banco pesado, exige instalação separada. Troque por um SQLite ou Firebird.
.Cal3D
Qual linguagem pretendem usar como script? |
| mcunha98 |
Duvidas/Sugestoes:
Som (2d/3d)
Normal/Bump maps
Importar fbx (ainda que seu formato próprio seja uma boa idéia, vai ter muita ferramenta 3D para você escrever plugins, reinventar a roda nessa questão vai ser um trabalho pesado). |
| Abdalla |
Ah claro, não foi mencionado mas sim, estamos implementando o seguinte:
Há uma Classe Scenario que carrega um cenário para o jogo de 3 formas diferentes:
Nos 2 ultimos casos os testes de colisão são via heightmap (obviamente).
No primeiro estamos usando uma modificação de voxels. |
| ferat |
Uma sugestão: Carga de Heightmaps!
T+ |
| Abdalla |
obrigado pela força, alguma sugestão de implementação ou melhora,
por favor não deixem de me falar. |
| ferat |
Cara, parabéns pelo projeto! Está ficando muito bom!!! |
| Abdalla |
Já estava querendo divulgar essa Engine a um bom tempo, mas só agora entramos na fase Alpha do projeto:
Engine 3D para desenvolvimento de futuros jogos.
O objetivo, alem de ser eficiente e possuir uma alta qualidade gráfica, é se manter estável até nos computadores menos potentes e trabalhar com escassez de recursos gráficos mantendo a qualidade.
Ficha Técnica (Versão 0.1):
- Carregamento de modelos 3D (obj e sk3, modelo criptografado proprio)
- Geração de primitivas Tridimensionais via parametrização
- Física 3D para corpos rígidos e dinâmica rotacional.
- Geração de partículas, podendo gerar próprias imagens.
- Iluminação: Gourand, Phong (pixel a pixel), podendo ser SpotLight
- Carregamento de imagens: bmp, png, jpg, pcx e tga
- Mapeamento de Normais, via CPU e GPU
- Multi-Texturização Reflexiva
- Saída de Textos
- Multi-threading, processamento concorrente para a física
- Fog (Efeito de Neblinas)
- Cell... |
|
