KSP 0.25

[x335]

Quelqu'un m'explique en quoi c'est dégueulasse ? Il avait un problème il l'a résolu qu'est ce qu'il y a de mal à ça ? (je connais pas unity pas tapez s'il vous plait =p )

[DrDam]

Quelqu'un m'explique en quoi c'est dégueulasse ? Il avait un problème il l'a résolu qu'est ce qu'il y a de mal à ça ? (je connais pas unity pas tapez s'il vous plait =p )

pour donner un exemple ( je sais pas s'il est génial) .... imagine que la fenêtre de ta ne se s'ouvre pas à moins de forcer sur un truc dans ta porte. Tu te dis, " bah c'est pas grave, je vais mettre une plaque de Plexiglas, que je descend comme je veux, et quand elle est en bas, elle appui sur le truc qui fait descendre ma fenêtre" ...

J'ai beau pas être expert en mécanique, j'imagine qu'il doit y avoir plus simple ( et j'en connais pas plus que toi sur Unity)

[x335]

Ton exemple est un peu bizarre mais je pense avoir compris merci

[Nemecle]

Si tu veux il voulait faire un curseur qui a des 'crans' : genre il glisse pas en douceur mais 'accroche' de manière régulière : or Unity ou plutôt la bibliothèque dont ils se servent pour l'interface ne permet pas de faire ça directement : donc il a mis deux curseurs l'un sur l'autre, l'un entrainant l'autre seulement de temps en temps et devenant 'invisible' par moment. Un sacré bordel

[Jebediah Kerman]

Donc au final ça semble plus être une pirouette de dev pour palier à une lacune de Unity qu'à du codage bourrin. Après je m'y connais pas en dev, mais c'est pas un petit slider incrémenté qui va donner un framerate dégueu, si ?

[DrDam]

Donc au final ça semble plus être une pirouette de dev pour palier à une lacune de Unity qu'à du codage bourrin. Après je m'y connais pas en dev, mais c'est pas un petit slider incrémenté qui va donner un framerate dégueu, si ?

Non, on a pas dis ça ... biensurs que non que cette "pirouette" ( et c'est le bon terme) ne va pas dégommer le framerate. On dit juste que c'est pas le genre de pirouette avec laquelle tu fanfaronne

Après pour parler de celui là, il restera dans les choux tant que le module physic sera traité par 1 seul processus par le CPU, mais ça viendra avec les montés de version de Unity ( au passage, une monté de version de Unity dans KSP pourrai prendre 1 ou 2 mois, et faire une release rien que pour ça ... autant dire que c'est pas un petit boulot)

[Nemecle]

Non ça va pas tuer les performances du jeu, surtout que ça concerne le menu : mais bon si c'est le fameux truc à 3000 lignes de code ça fait un peu lourd le slider incrémental à la con...

[DrDam]

Non ça va pas tuer les performances du jeu, surtout que ça concerne le menu : mais bon si c'est le fameux truc à 3000 lignes de code ça fait un peu lourd le slider incrémental à la con...

Ou encore pire : ça s'ajoute au truc à 3000 lignes ...

[Eptios]

Et si tout est codé comme ça, on est pas au bout du développement...

[Dragoon1010]

1: Pas forcément vrai. Il existe bon nombre de libraries très complètes et faciles à prendre en main (Boost, etc...).

2: Franchement, entre coder mon moteur de jeu homemade (ce qui veut dire se casser les **** sur le multiplatforme (user des différentes API systèmes, tout en encapsulant ça) taper de l'openGL, gérer le son (tout ça aussi dans le multiplatforme), le networking, le windowing (X11, WinAPI...), franchement pas à la portée de tout le monde, et prendre un moteur de jeu certes complexe, mais complet, maintenu depuis une dizaine d'années, avec une communauté active, OS-wide, quasi bug-free..., j'ai fait mon choix. Et rien ne t'empêche de faire un fork du moteur pour l'adapter à tes besoins.

C'est donc bien ce que je dit, certe créer son moteur de A à Z c'est chiant, mais si tu veux tout gérer, c'est ce qu'il y a de mieux. Attention, je ne dit pas que les nombreux moteurs de jeu dispo sont à chier, juste qu'ils ne sont pas forcément adapté à tout les projets, et même si il existe de nombreux addons/librairies, il arrive parfois qu'on ne trouve pas ce dont on à besoin.