Minecraft!
-
Je n’y ai jamais joué mais uniquement vu en vidéo. Si j’ai bien compris, c’est un immense bac à sable jouable en réseau. Le but est de survivre comme dans Sapiens. Le graphisme est 3D mais avec un look très old-shool avec ses blocs très pixélisé.
Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !
thellier a écrit :
Hello
Et au final on peut voir les sources de MineCraft ? ou alors on parle dans le vide…..
Alain
Les sources de Minecraft non mais les sources de Minetest, oui :
Ma config : Amiga CD32 nue, c'est un super joujou pour rester dans le monde de l'Amiga 🙂
je ne connaissais pas, c’est sympa ce minetest
effectivement un petit équavalent sur amiga, même sans casser 3 pattes à un canard, ça me botterais aussi.
Ce qui est énorme avec Minetest :
– C’est gratuit
– C’est opensource
– C’est plus rapide
– Le binaire fait à la fois client et serveur
– Le LAN fonctionne entre machines dont l’OS est différent (Testé entre Windows 7 et PinguyOS 11.04)
Ce pour quoi il faut être patient encore avec Minetest :
– Tous les éléments craftables de Minecraft ne sont pas encore implémentés. Mais le coeur logiciel permet de gérer la majorité des cas. Affaire à suivre …
Ma config : Amiga CD32 nue, c'est un super joujou pour rester dans le monde de l'Amiga 🙂
Minecraft étant écrit en Java, les sources sont naturellement accessibles via une décompilation. Il existe de nombreux mods à Minecraft qui réécrivent une partie des classes du jeu, qui en rajoutent d’autres et qui recompilent le tout. Le code est ainsi tout à fait “accessible” et la pratique n’a pas l’air de gêner le développeur du jeu. Au contraire, il faut dire qu’il en profite également puisqu’il intègre souvent aux mises à jour des éléments de jeu initialement contenus dans un mod.
pascmart84 a écrit :
Minecraft étant écrit en Java, les sources sont naturellement accessibles via une décompilation. Il existe de nombreux mods à Minecraft qui réécrivent une partie des classes du jeu, qui en rajoutent d’autres et qui recompilent le tout. Le code est ainsi tout à fait “accessible” et la pratique n’a pas l’air de gêner le développeur du jeu. Au contraire, il faut dire qu’il en profite également puisqu’il intègre souvent aux mises à jour des éléments de jeu initialement contenus dans un mod.
Ce n’est pas ce qu’on appelle opensource …
Ma config : Amiga CD32 nue, c'est un super joujou pour rester dans le monde de l'Amiga 🙂
Ce n’est pas ce qu’on appelle opensource …
Ce n’était pas la question posée me semble-t-il.
oui leo moi non plus j’avais pas envie d’y toucher je trouvais ca moche .
j’ai quand meme essayé et ce jeux est addictif !!ca plaira pas a tout le monde c’est sur mais moi je suis rester bloqué dessus un bon moment a c’est tres rare quand j’accroche a un jeux .
éssais tu me diras
Je vais paraître à la traine mais… c’est quoi Minecraft ? Biensûr, j’en a entendu parlé, mais les écrans que j’ai vu ne m’ont franchement pas donné envie d’y toucher… Et quand j’entends “Java”, ça me donne encore moins envie
Ceux qui était à l’Alchimie 111111 auront pu voir un bout en temps réel:
J’avais pas percuté, alors c’était ça la sphere verte sur fond noir en 3D fil de fer que je voyais sur ton écran !??
Don't lose it... and don't lose your head
Yomgui qui nous prépare un clone de Minecraft ?
Heureusement qu’on a ce gas là tout de même ! On a des programmeurs de génie dans notre univers
Et j’ai même pas vu à l’Alchimie… Yomgui, tu as une petite vidéo pour voir comment ça tourne ?
Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !
@highlander: non ca c’était ma tête… 8-/
Yomgui: T’es bien courageux, et tu me coupes même l’herbe sous le pied Le boulot que tu es en train de faire je rêve de le faire aussi. (j’y pense presque tous les jours en fait, sauf que toi tu concrétises ^^)
Faut être honnête, au dela de ses apparences simplistes, en raison de sa profondeur de champ, de la quantitée de cube, un Minecraft n’est pas simple à réaliser sur nos “petites” machines (mais pas impossible non plus).
Au niveau optimisation du bousin, je pense que le premier gain de vitesse s’obtiendra surtout en réunissant tous les polygons partageants le même plan et la même textures en un minimum de polygons.
L’avantage c’est qu’un tel algo est très simple d’écriture, et n’a besoin d’être réexecuté que partiellement à chaque modification de terrain. Ca réduit également drastiquement la quantité de vertex à T&L. Le désavantage c’est que ça réduit lourdement les possibilités d’occlusion culling. De toute façon je doute qu’un occlusion culling à l’échelle d’objet aussi petits et nombreux que des cubes de terrain soit réaliste (Mais j’admet être une bille à ce jeu là )
Au niveau des performances, tu dis que tu es à 29.000 faces (quad ou tri?) par seconde. C’est quand même un peu léger à ce niveau de texturage et de filtrage, maintenant je sais pas ou passe le temps machine. J’veux pas dire de connerie mais la scene que j’ai modélisé à l’alchimie me donne dans les 400.000 tri/sec (CPU limited sur Aone [email protected], mais énorme marge d’optimisation), et je trouve que c’est encore loin d’être suffisant pour afficher un Minecraft digne de ce nom. Enfin bon t’as déjà fait des prouesses en opti
Keep on! J’applaudi
@Crisot: merci de ton soutiens!
Je sais pas trop ce que cela va donner ni où je m’embarque en faite.
Sinon pour le moteur de rendu, j’utilise des quads que je rend en remplissant un tableaux de vertex/tex/color que je donne ensuite à manger à TGL par glDrawArrays(). donc difficile de faire mieux mise-à-part en mettre le plus possible.
Donc là plusieurs choix pour répondre à la question: comment remplir un max de vertex dans un minimum de temps?
Pour l’instant j’ai construit la carte en interne de façon très simple mais très versatile: 1 appel à glDrawArray c’est 24 vertex max (6 quads).
Alors l’idée de grouper les cubes entre-eux pour former des surfaces oui, je vais le faire.
Mon idée pour la suite c’est de faire un gros tableau pour glDrawArrays() avec tous les cubes “statiques”, tableau créé pendant la lecture de la carte. Avec une gestion de l’occlusion (j’ai déjà, marche à merveille!) on entre que les faces visibles, cela limite en taille.
Evidement tu vas me demander comment cela ce passe quand on retire ou ajoute un cube: en faite plutôt qu’un gros tableau pour toute la carte, qui pourrait évidement être trop gros pour la mémoire (et puis carte infinie on oublie) je découpe la carte en “clusters”, chaqu’un de taille fixe (genre 25x25x25 cubes). La boucle principale de rendu cherche premièrement dans les clusters en mémoire ceux qui sont visibles dans le champ de la caméra.
Pour chaque cluster je rend avec 1 seul appel à glDrawArrays() tout son contenus. Si rajout d’un cube j’ajoute dans mon tableau une entrée à la fin. Si on retire un cube, je vire l’entrée pour ce dernier et si ce n’est pas le dernier de la liste je le remplace par le dernier, pour pas avoir de “trous” dans le tableau.
Les clusters seront eux mêmes gérés dynamiquement pendant le rendu: si le joureur comment à aller dans un secteur où il est proche d’un cluster de bordure, des nouveaux sont générés qui remplaceront les plus lointains de la camera… histoire de garder de la mêmoire.
Avec tout cela je pense que je devrais avoir de bonne perfs.
De plus les textures pour les cubes “monde” sont tous dans la même texture OpenGL, donc 1 seul appel à glBindTexture avant le rendu de toute la carte, avec de passer au “sprites”. Mais là c’est une autre histoire
Note:
Après réflexions (et calculs…) je vais pas faire 1 tableau fixe par cluster, car 1 face c’est 32 octets (12 pour les vertexes, 12 pour les couleurs, 8 pour les textures), donc 1 cluster de 11 cubes de côté donne 255552 octets, avec une distance raisonnable de 10 clusters de côté stockable en mêmoire on obtient 243.7 Mo! :'(
Cela serait dommage de prendre autant si en plus un cluster n’est pas remplis à fond (avec que des blocks transarents en plus pour être sûr de devoir tout afficher).
Je vais voir pour un truc plus dynamique.
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Minecraft!