Pour rappel à la base le projet n'est qu'un jeu, il n'est pas question de démo, le truc sorti à l'Alchimie y'a 2 ans est un bonus.

Pour ce qui est de m'entourer de personnes, c'est très compliqué.

Niveau code, les codeurs non OpenGL n'existent pratiquement plus, ils ont la 40e voir 50e passée et la plupart ont pris leur retraite du code. De toute façon, ces compétences déjà rares ne sont plus sur Amiga depuis 1993.

Niveau graphisme: Aujourd'hui, quand on parle de "low poly" en 3D, on parle d'une quantité de polygones qui pour un seul objet dépasse le cumul de tous les polygones existant dans la totalités des jeux Os4. Clairement, à l'heure où un mesh "low poly" fait 10.000 triangles, aucun mec ne se fera chier à bosser sur des mesh qui vont de 2 à 500 triangles. J'aborde même pas le problème des maps et des shaders avec lesquels les graphistes bossent.

Niveau musique: J'ai repéré un gars que j'aime beaucoup, mais son prix pour simplement pondre un theme est plus élevé que ce qu'un jeu shareware sur Amiga peut rapporter. Sachant que c'est pratiquement le poste le moins cher...

Et de toute façon, va trouver des gens motivés à bosser sur un projet qui (pour le moment) ne tourne pas sur leur PC.



Très honnêtement, à ce jour j'avance bien plus vite que je ne l'espérais. Oui y'a rien de bien neuf sur les screenshots, mais passé un certain seuil maintenant proche, le jeu apparaitra tout seul.

 >modifié pour être "quasi OpenGL" dans son fonctionnement, et en fait, OpenGL c'est super bien foutu

C'est à dire ???!!!?

Qu'as tu donc découvert dans OpenGL qui t'emballe tant désormais ??!? car on t'as connu bien critique sur MiniGL

 (MiniGL qui n'est pas exactement la même chose qu'OpenGL j'en conviens..)

Juste curieux...

Alain

y parle peu être de warp3d nova?

@crisot:
Message édité par : artblink / 26-04-2016 18:34

Alors justement ça tombe particulièrement bien que vous parliez de .OBJ, c'est justement un très bon exercice et quelque chose qui montre "facilement" la différence entre mon moteur "custom" pré-modification, et un moteur OpenGL (pour Artblink).

Prenons un cube. Il est constitué de 8 points, chaque point étant utilisé par 3 faces. Le truc, c'est que si chacune des faces est texturées/colorées différemment, OBJ stockera uniquement 8 points, et plusieurs "pointeurs" avec des couleurs/textures différentes pour chaque utilisation de ce point unique.

Mon moteur fonctionnait pour ingurgiter directement du OBJ, j'avais donc une liste de pointeurs de points, une liste de pointeurs de textures, une liste de pointeurs de couleurs, etc, et au moment de traçage, je faisais un petit medley avec tout ça pour le faire ingurgiter à Warp3D.

OpenGL marche totalement autrement. Pour OpenGL, chaque point est STRICTEMENT unique. Il n'y a qu'une seule et unique liste de pointeurs qui comprend tous les paramètres. Donc si le coin d'un cube est rouge, il est rouge pour TOUTES les faces. Si on souhaite qu'un point soit utilisé avec des couleurs/textures différentes, il faut alors dupliquer l'intégralité du point. Comprendre: Si le cube à 6 faces de couleurs différentes, alors il faudra dupliquer chaque point 3 fois: Total, notre cube fait maintenant 24 points, et non 8.

Ca marche exactement pareil pour l'éclairage. Par défaut l'éclairage est forcément "smooth", doux entre chaque arrête. Si on souhaite avoir un éclairage "dur" avec des arrêtes franches, il faudra dupliquer les points de chaque arrête.

Vu ainsi, on ne voit que des inconveniants : Car notre cube avec ses points dupliqués, au moment du fameux "transform and lightning" que l'on a pas en hardware sur Amiga, il faudra l'appliquer à 24 points et non 8, et il faudra faire dans le vide 3 fois la même chose: Inutile...

Et pourtant... En pratique, ça présente tellement d'avantages. Le fait de supprimer pleins de buffers de pointeurs, ça simplifie tellement de choses, ça optimise tellement l'utilisation mémoire... Chaque point étant unique, il suffit de tout traiter à la chaine avec une bonne moulinette, plus besoin de reconstituer ses points au moment de l'éclairage, du clipping... En fait, tout va plus vite.

Bref, c'est sans doute obscure pour plein de gens d'ici, mais clairement, j'ai carrément divisé la quantité de lecture/écriture mémoire. Les boucles de transform & ligthning, bien qu'ayant plus de points à traiter, sont plus courtes et plus rapide pour chaque point. Du bonheur.

Bref, là je parle de techno de 1995, rien ne neuf. Je me suis juste penché sur le fonctionnement du "pipeline" interne à OpenGL, et j'ai juste eu le déclic du "putain c'est trop bien pensé" avec 20 ans de retard. 

MINIGL:

Si j'en veux à ce truc, c'est parce qu'il est affreusement lent. Hans me disait il y a quelques années que si mon moteur allait vite c'était justement parce qu'il était "custom", et que MiniGL devait ses lenteurs à son obligation de respecter des standards. Avec mon immense respect que j'ai pour ce grand monsieur: Bullshits. Mon moteur n'a jamais été aussi rapide que depuis qu'il mimique OpenGL. C'est si simple et bien pensé que je ne comprend même pas qu'on puisse en louper une implémentation à ce point...

(ce fut long...)
Message édité par : Crisot / 26-04-2016 21:50

Donc en gros, plus t'as de point avec un minimum d'arguments et plus ça va vite
@Crisot: T'aurai pas des exemple de code d'IA sympa pour des concurents de jeux de voiture en vue de dessu? j'avais trouver un site, il y a longtemp, mais je ne me rappel plus du nom :-(
Message édité par : artblink / 26-04-2016 22:10