Djes a écrit :Tu parles de celui-là ? Je me suis amusé pour vous taquiner un peu
Tu vois mon bon DJES...ça confirme ce que je disais
Gad elmaleh dans son sketch ''les emissions de télé la nuit'' a écrit :Ils font des blagues d'intello que seuls eux comprennent.... Le mec fait des vannes à lui.
- "C'est un peu comme en 1505, le médaillon d'lsis Novnak..." arf arf arf !!!
Va rire à cette blague, toi qui as lu que un "Oui-Oui" ! En plus, c'était "Oui-Oui veut pas aller à l'école" !...
Et ben le seul bug que j'ai trouvé dans ton code...c'est que la fenetre ne se ferme pas quand on clic sur la "p'tite croix"
J'ai un code d'affichage d'une carte en isométrique bloqué à cause de ça et je me vois mal appliquer ce genre d'astuce qu'aux tiles en bordure.
Raz le bol des astuces qui sont des verrues avec des poils capillotractés, pour palier aux bugs.
En tant que programmeur on a un minimum de sens de l’esthétique, c'est tellement abusé que ça m’empêcherait de dormir.
Il y a deux méthodes pour écrire des programmes sans erreurs. Mais il n’y a que la troisième qui marche. Version de PB : 6.00LTS - 64 bits
Fig a écrit :J'ai un code d'affichage d'une carte en isométrique bloqué à cause de ça et je me vois mal appliquer ce genre d'astuce qu'aux tiles en bordure.
Pourquoi se limiter aux tiles en bordure, puisqu'on peut mettre les coordonnées qu'on veut ?
Je te remercie pour ta contribution, Djes, mais vraiment je suis particulièrement en colère vis à vis de ce bug. (qui date de Mathusalem et dont presque tout le monde semble se foutre) Ce qui explique je suis un peu de mauvaise foi.
Afficher une tile à une coordonnée fixe en modifiant ses coordonnées de transformation est... très malin... mais c'est une aberration totale qui me contrarie rien que d'y penser.
Je propose que la documentation PB supprime les coordonnées de displaysprite() et oblige l'utilisateur à les spécifier dans transformsprite() tant qu'on y est...
Parce qu'actuellement on a ce laconique:
Purebasic HelpFile a écrit :Il est parfaitement autorisé d'afficher le sprite partiellement ou complètement hors de l'écran.
Bein voyons... Grrrr
Il y a deux méthodes pour écrire des programmes sans erreurs. Mais il n’y a que la troisième qui marche. Version de PB : 6.00LTS - 64 bits
Fig> Je comprends que ça puisse t'énerver. Ca m'est arrivé aussi, même si j'ai eu quelques cadeaux, comme le support des couches alpha et le png... Les plus grosses difficultés sont arrivées avec les nouvelles versions de directx, et la fin de la 2D telle qu'on la connaissait. Ici comme tu le sais, les sprites n'en sont pas vraiment, ce sont des triangles gérés par la carte 3D, et le transformsprite() ne doit pas être si simple à adapter en opengl, sur linux et sur mac, surtout qu'il y a pas mal d'incompatibilités "constructeurs" à gérer de façon invisible. J'avais demandé des fonctions pour mieux connaître les capacités graphiques de l'utilisateur, mais en fait, on touche là à des demandes qui sortent du cadre d'un BASIC. Normalement, il faut commencer à mettre soi-même les mains dans le cambouis de l'OS, et windows, ben c'est vraiment sale, et en plus ça pue.
Aussi, la lib sprite devrait être repensée, avec le support du hotspot et des shaders, plus comme de la vraie 3D, mais facilement manipulable. Seulement, il faut vraiment bien penser à tout en amont, parce que, mine de rien, avec Ogre, le support des différents formats d'images, la boucle d'événements, ça fait un sacré jonglage ! Et puis, il faut soit masquer, soit implémenter tout le côté matrices et transformations, et ça, ça implique (peut-être) d'intégrer un nouveau type natif "matriciel" à PB...
Enfin, je sais que Fred travaille par "secteurs". La lib 3D a été mise à jour il y a quelques temps déjà, il s'est beaucoup occupé de spiderbasic, peut-être que maintenant, ce sera la lib sprite, qui sait...
Blendman> Est-ce que tu ajoutes bien la position absolue (x, y) seulement tout à la fin, après les transformations ?