Bizarre que ça marche pas, tu l'avais bien juste avant le surface_reset_target() et après tout le reste du draw dans la surface ? (je pense que oui, mais bon )

Oui, j'avais bien fait de la sorte.

Mais sans savoir pourquoi, ton post a attiré mon attention sur un autre problème qui était visiblement à l'origine de tout ça, et en modifiant le rendu de mes blend modes je viens de résoudre en quelques minutes ces bugs d'affichage qui me tenaillaient depuis de nombreux mois.

Merci nicoulas !

Lol ben de rien ^^

lol comme quoi le problème n'es jamis celui que l'on pense

Voili voilou Topazounet.

http://lecbna.org/bast/gamemaker/cbnabump2d/CBNA_Bump2Dlib_v110.rar

Le gain de FPS n'est pas énorme, mais cela te sera peut-être déjà utile. Il y a je pense encore des améliorations à faire.

Edit: et je viens de constater que des bugs apparaissent dès qu'il y a plusieurs lumières pré-rendues. Ce n'est pas encore ça.

J'ai également inclus la possibilité de choisir le mode de rendu (affichage ou non des parties ombrées), suite à la remarque de robotic.

Effectivement, robotnik avait raison, le rendu est meilleur sans les ombres avec des lumières multiples :oui:

Bast a écrit:

Edit: et je viens de constater que des bugs apparaissent dès qu'il y a plusieurs lumières pré-rendues. Ce n'est pas encore ça.

C'est corrigé. Dis-moi si ça te convient Topaze.

Rhoooooo, décidément, aujourd'hui, c'est définitivement noël pour moi ^^

Entre TheDarkTiger qui me corrige l'ultime bug pour notre moteur d'eau qui coule (et corrige un de ses codes pour une économie de vertexes) et toi qui me sort une version optimisée de ton système...

Si on rajoute que hier Playboy et moi avons corrigé le dernier soucis que j'avais dans son système de dialogue, et que Altanner me réclame un interview, je me sens vraiment comme une star holywoodienne aujourd'hui



Je teste ton système et les corrections de TheDarkTiger puis je vous tiens informé ici.


PS : ton prochain système de lumière sera accessible ou exclus à tes projets (ou bien tu ne sais pas encore) ?

Bast, normalement, si ton optimisation est comme je le souhaite, normalement, une room avec plein de lumière fixe et plein de blocs devrait couter autant de performance que si il n'y avait dans cette room que des sprites de bloc (j'espère que dans tes calcules, les lumières fixes ne font plus aucun calcules dans les blocs fixes).


Je vais tester

PS:Le moteur d'eau est opérationnel à 100%, il reste juste à le mettre en ordre et à l'inclure ^^


EDIT :





J'ai posé plusieurs lumière2 dans "Bump2Dlib V1.1 - Exemple plaques 2.GMK" et apparement, qu'une seule est prise en compte .

Deplus j'ai des "unknow action" dans tes objets donc si tu as changés de lib, il faudrait que tu l'inclus dans ton .zip ^^

Je suppose que les lumières 2 sont les lumières fixes optimisées et que les lumières 1 sont les lumières mobiles non optimisées ?

J'attends que tu m'éclaires ^^

génial !

la nouvel .lib est inclus, et c'est vrai que si on la met pas, ça plantouille XD

PS : Gosc, j'avais l'intention de faire une signature optimisé sous flash qui nous permettrait de prendre moi de place dans la signature tout en montrant plusieurs bannière... Il serait temps que quelqu'un fasse une bannière qui nous permettrait de faire alliance et de mettre plus de chose dans nos bannières.


PS : j'avais pas vu le .lib comme l'icone était toute blanche, je l'avais cherché mais pas vu XD

Je reteste.

Bon, j'ai les même soucis que précédement.
Qu'une seul lumières 2 est prise en compte et je ne constate pas du tout de différence de perf qui devrait être dû à l'optimisation de l'enregistrement dans un sprite.


Bast : as tu vérifié que après que la lumière fixe appliquée dans une instance fixe soit enregistrée dans le sprite même de l'objet fixe, que la lumière fixe cesse de prendre en compte l'obj fixe ?

Il a forcément un soucis quelque part, à mon très humble avis

Topaze22 a écrit:

PS : ton prochain système de lumière sera accessible ou exclus à tes projets (ou bien tu ne sais pas encore) ?

Ce sera complètement open source, et les utilitaires et démos techniques qui iront avec le seront aussi.

Topaze22 a écrit:

J'ai posé plusieurs lumière2 dans "Bump2Dlib V1.1 - Exemple plaques 2.GMK" et apparement, qu'une seule est prise en compte.

Topaze22 a écrit:

Bon, j'ai les même soucis que précédement.
Qu'une seul lumières 2 est prise en compte

Normal, la lib a toujours agit comme ça. Pour créer plusieurs lumières, il faut créer plusieurs objets.. Oui l'ergonomie est un peu foireuse, mais comme dit cette lib est vieille de plus de trois ans, et il y a trois ans je ne me débrouillais pas aussi bien qu'aujourd'hui. C'est un vieux code, il faut faire avec.

Topaze22 a écrit:

Je suppose que les lumières 2 sont les lumières fixes optimisées et que les lumières 1 sont les lumières mobiles non optimisées ?

Ce ne sont pas les lumières en elles-mêmes qui déterminent le mode de rendu, ce sont les actions situées dans obj_draw. Mais oui, dans ce cas précis la N°1 est en temps réel et la N°2 pré-rendue.

Topaze22 a écrit:

je ne constate pas du tout de différence de perf qui devrait être dû à l'optimisation de l'enregistrement dans un sprite.

La différence de perf n'est pas très flagrante et dépend des situations. Elle est de l'ordre de 2~3%.

Topaze22 a écrit:

as tu vérifié que après que la lumière fixe appliquée dans une instance fixe soit enregistrée dans le sprite même de l'objet fixe, que la lumière fixe cesse de prendre en compte l'obj fixe ?

C'est bien comme ça que ça marche. Au lieu que chaque objet calcule et affiche les quatre sprites de lumière différentes, une seule sprite pré-calculée est affichée. C'est moins lent, mais pas forcément probant.



Je n'ai plus touché au code de cette lib depuis plusieurs années et je me suis remis dedans pour te faire plaisir, mais il faut bien avoir conscience qu'elle se fait vieille et qu'il n'est pas forcément évident d'y ajouter de nouvelles modifications.

Ok, ça ne me pose pas de problème d'utiliser un objet pour chaque light, pas du tout du tout ^^, juste que je pensais que tu n'avais pas calculé ainsi ^^


Concernant la faible différence de perf de l'optimisation, cela vient du faite qu'en faite tu n'optimises pas comme il aurait fallut, mais je comprends parfaitement que le code soit vieux et que tu planches sur d'autres choses.

Mais en toute logique, mettre 200 light fixe sur 200 objets fixe devrait couté très peu de perf, et mon PC devrait faire tourner une telle room à plus de 800fps et non moins de 70. Je ferais avec, j'ai déjà inclus une autre optimisation qui soulage grandement les perfs, en toute logique, je devrais être capable de rajouter moi même un système capable en un step de regarder toutes les lumières fixes et tout les objets fixes, de faire les calcules pour changer les sprites des objets fixes et supprimer leur présence de ton engine tout en laissant leur sprites affichés.


T'inquiète, je devrais me le faire d'ici fin août. Le truc c'est que le fonctionnement sera intrasec à mon Projet Mario donc je ne pourrais pas vous en faire bénéficier.


PS:est t'il possible d'utiliser les surfaces même si mon niveau est en 3D ? genre : j'éteins la 3D, je me sers des surfaces pour modifier les sprites puis je rallume la 3D 3 steps plus tard... ? Ca devrait marché en théorie non ? Si oui, mon idée devrait marché et les lumières fixes sur objets fixes ne couteront absolument rien à l'image d'une lightmap.

J'ai finalement retravaillé une bonne partie de la structure de la librairie, ce qui m'a permit de créer un système de pré-rendu bien plus performant que le précédent. Maintenant, le gain de performances est clairement visible.

=> CBNA Bump2D v1.2

Vue la forte modification de la lib, les gm6/gmk créés avec les versions précédentes seront incompatibles avec cette nouvelle mouture.

Changements significatifs apportés depuis la v1.1:
- Suppression des actions permettant le rendu pour surfaces isométriques et convexes, que de toute façon personne n'utilisait.
- Suppression également de l'action servant à créer un alpha graduel.
- Modification des actions permettant le rendu de relief. Le calcul et l'affichage se font maintenant à partir des objets lumières eux-mêmes.
- Il est maintenant possible d'utiliser plusieurs instances du même objet lumière.
- La conception des sprites de relief a été revue: au lieu d'avoir quatre sprite différentes, il suffit maintenant d'une seule sprite composée de quatre sous-images.
- Amélioration globale de l'ergonomie.
- Nette amélioration du système de pré-rendu des lumières.
- Ajout d'une version anglaise de la librairie.

Voilà pour toi Topaze. Maintenant je retourne bosser sur CBNA SmartLight. :)

génial

Je crois avoir remarqué que les ombres ne fonctionnent plus, même en mettant le mode de rendu en ombres+lumière ou en ombres seulement.

nicoulas a écrit:

Je crois avoir remarqué que les ombres ne fonctionnent plus, même en mettant le mode de rendu en ombres+lumière ou en ombres seulement.

Car cette option n'est pas valable dans le cas des lumières non dynamiques: il faut s'assurer que la lumière est définie comme étant dynamique pour que les ombres soient affichées.

Ah ok, et forcément fallait que j'essaye sur le 3ème .gmk, celui avec les lumières statiques

Bast a écrit:

J'ai finalement retravaillé une bonne partie de la structure de la librairie, ce qui m'a permit de créer un système de pré-rendu bien plus performant que le précédent. Maintenant, le gain de performances est clairement visible.

=> CBNA Bump2D v1.2

Vue la forte modification de la lib, les gm6/gmk créés avec les versions précédentes seront incompatibles avec cette nouvelle mouture.

Changements significatifs apportés depuis la v1.1:
- Suppression des actions permettant le rendu pour surfaces isométriques et convexes, que de toute façon personne n'utilisait.
- Suppression également de l'action servant à créer un alpha graduel.
- Modification des actions permettant le rendu de relief. Le calcul et l'affichage se font maintenant à partir des objets lumières eux-mêmes.
- Il est maintenant possible d'utiliser plusieurs instances du même objet lumière.
- La conception des sprites de relief a été revue: au lieu d'avoir quatre sprite différentes, il suffit maintenant d'une seule sprite composée de quatre sous-images.
- Amélioration globale de l'ergonomie.
- Nette amélioration du système de pré-rendu des lumières.
- Ajout d'une version anglaise de la librairie.

Voilà pour toi Topaze. Maintenant je retourne bosser sur CBNA SmartLight. :)

A mince, je venais pour regarder comme ça, au cas ou il y avait une info interessante sur le topique qui m'a vu naitre au sein de la communauté du CBNA [et oui, mes tout premiers postes sont ici XD].

Et je ne m'attendais pas à voir cela, je teste, et je commente d'ici peu.

:snif2: vous vous doutez de ce que je vais pouvoir faire avec maintenant que le statique ne pompe plus que très peu :snif2:

Bon, je retire l'ancien système, j'inclus le nouveau, et ça me fera une meilleur room pour la démo 4.

Une question pour Bast : quelque soit la méthode que tu utilises, ça me conviens parfaitement, juste, si tu enregistres tes lumières fixes dans une surface, j'ai besoins de le savoir. Sinon, c'est vraiment impécable pour moi, merci encore Bast, ça me permettra de faire tourner tes niveaux sur les vieux PC sans problème.


Toujours là pour moi, ça fait plaisir ^^

Et j'ai hate de voir le "CBNA SmartLight", je me souviens que tu l'avais évoqué dans ton topique de MetalGun.

Vivement ta démo 4 dans ce cas. ;)

Topaze22 a écrit:

Une question pour Bast : quelque soit la méthode que tu utilises, ça me conviens parfaitement, juste, si tu enregistres tes lumières fixes dans une surface, j'ai besoins de le savoir.

Les lumières sont enregistrées dans des sprites. Les surfaces n'interviennent que très brièvement lors de la conception de ces dites sprites.

Bien que ton système semble extrêmement facile à installer, tes shapes ne s'allument pas dans mon projet Mario

Donc je suis obliger de te poser quelques questions qui vont peut être te sembler bizar, mais les réponses pourraient m'éclairer (si j'ose dire).


-Les quatres faces éclairées, sont t'elles dessinées avec un vertex ou par un draw_sprite ?


-A quel moment se fait le dessinement des éclairages ? [Dans l'objet light ou dans l'objet shape ?]

-Quel est la profondeur (depth) de tes lumières ? (c'est le même depth que ton obj_shape ? Ou la même profondeur+1, ou -1 ?)


Edit : si tes sprites non dynamiques sont crées alors que le mode 3D est encore activé, les surfaces ne sont pas utilisables donc le sprite crée ne contient rien ?




Edit : J'ai remplacé le sprite du bloc par un sprite minuscule de façon à affichée tes lumières (au cas ou l'éclairage était derrière le sprite du bloc) et en effet, l'éclairage est simplement derrière le sprite du bloc, donc je vais essayer de ruser

Edit : pour l'instant, seul l'éclairage dynamique s'allume (et derrière le bloc qu'ils doivent éclairer)

Je continue de chercher

Edit : Ok, en faite, il faut que ton obj_shape est une profondeur moins faible que les obj_light. Donc l'affichage du shape se fait dans l'obj_shape dans sa depth, alors que l'affichage de l'éclairage se fait dans les obj_light dans la depth de l'obj_light.

Donc l'affiche des éclairages dynamiques marchent comme il faut au dessus des sprites des blocs.

Par contre les lights non dynamique n'éclairent toujours rien, donc je continue à chercher.

Edit : Question : lors de la création du sprite pour les lumières non dynamiques : le code qui te permet d'ouvrir une nouvelle surface puis de créer ton sprite, ça se fait dans l'obj_shape ? Et si oui, à quel moment, lorsque l'obj_shape se crée, il regarde si il y a des lumières dynamiques et crée alors le sprite ?

Si je crée une lumière non dynamique "in game", disons une minute après avoir crée la room contenant des obj_shape, le sprite des objets shape se met à jour ?

Si je pose ces questions, ce n'est pas pour que tu rajoutes quelque chose, c'est pour que je trouve où il y a le pépin pour pouvoir contourner le pépin.




Edit : j'arrive à afficher les lights non dynamiques dans ma room2D, mais pas dans ma room3D. Pour y arriver, il a fallut que je comprenne que tes obj_shape devaient être présent dès le début non ? Si je crée un obj_shape 10s après le début, ça ne marche plus ?

Edit : comme on pouvait s'en douter, d3d_end() et 3d_start() conservent les sprites des shapes dynamiques crée (à condition je suppose que la d3d était "end" lorsque ton système avaient besoin des surfaces pour créer les sprites).


Je continu de chercher

Topaze22 a écrit:

-Les quatres faces éclairées, sont t'elles dessinées avec un vertex ou par un draw_sprite ?

Draw de sprite.

Topaze22 a écrit:

Edit : si tes sprites non dynamiques sont crées alors que le mode 3D est encore activé, les surfaces ne sont pas utilisables donc le sprite crée ne contient rien ?

Oui, je suppose.

Topaze22 a écrit:

Edit : Ok, en faite, il faut que ton obj_shape est une profondeur moins faible que les obj_light. Donc l'affichage du shape se fait dans l'obj_shape dans sa depth, alors que l'affichage de l'éclairage se fait dans les obj_light dans la depth de l'obj_light.

[...]

Edit : Question : lors de la création du sprite pour les lumières non dynamiques : le code qui te permet d'ouvrir une nouvelle surface puis de créer ton sprite, ça se fait dans l'obj_shape ? Et si oui, à quel moment, lorsque l'obj_shape se crée, il regarde si il y a des lumières dynamiques et crée alors le sprite ?

Non non, rien ne se passe dans les objets éclairés. Tout se passe dans les objets lumière. Il suffit d'ouvrir la lib avec libbuilder et de regarder les scripts pour s'en rendre compte.

Dans le cas des lumières pré-rendues, il y a une sprite par objet lumière. La dite sprite étant affichée par l'objet lumière lui même, et donc avec le depth de ce dernier.

Pour les lumières dynamiques, les sprites de relief sont affichées sur les objets éclairés depuis l'objet lumière avec une instruction with.

Topaze22 a écrit:

Si je crée une lumière non dynamique "in game", disons une minute après avoir crée la room contenant des obj_shape, le sprite des objets shape se met à jour ?

Comme dit précédemment, les sprites pré-rendues sont générées par les objets lumière eux-mêmes lors de leur création: donc si tu ajoutes un objet (ou une instance) lumière pendant le déroulement du jeu, la sprite pré-rendue sera générée sans aucun souci.


Edit: euh, pendant que j'écrivais, ton post a eu le temps de changer 36 fois de forme, il faudrait peut-être un peu clarifier.

Topaze22 a écrit:

Si je crée un obj_shape 10s après le début, ça ne marche plus ?

Si, ça marche. Sauf bien entendu pour les lumières pré-rendues, qui sont calculées une bonne fois pour toutes au moment de leur création.

Ok, merci pour les infos, je continue de chercher ^^

Supposons que la 3D est bien activée lorsque en mode non dynamique, il y a tentative d'utilisation de surface pour générer le sprite : le nouveau sprite doit contenir le spr_shape + le spr_deséclairages ? Parceque pour l'instant, en mode3D, le spr_shape s'affiche bien, alors que la surface devrait retourner zéro en toute logique, et ne devrait même pas retourner le sprite shape non ?

Edit : j'ai tout barré puisque lorsque l'on remplace le spr_shape par autre chose, on comprend qu'il n'y a pas fusion, tu l'avais dis en plus il me semble ^^

PS : Je viens de me réveiller...
PS n2 : Bast, je te demanderais peut être d'avoir un scrip en plus du drag and drop, parce que avec le drag and drop, on peut pas le mettre partout pour coder comme on veut ^^

Topaze22 a écrit:

PS n2 : Bast, je te demanderais peut être d'avoir un scrip en plus du drag and drop, parce que avec le drag and drop, on peut pas le mettre partout pour coder comme on veut ^^

Hop:

http://lecbna.org/bast/gamemaker/cbnabump2d/CBNA_Bump2D_scripts_v120.rar

*réception*
Hop laaaa !

Heu Bast, je me suis mal exprimé, ce n'était pas le script que je voulais avoir car c'est ton moteur que tu chéris et qu'avec le script, on voit tout tes codes.

Je voulais juste avoir la possibilité de mettre une fonction à la place du drag and drop. Si tu souhaites planquer tes codes, tu devrais éditer ton dernier post et m'envoyer juste le nom de la fonction (sans script, je ne sais pas si c'est faisable, ou bien tu le planques dans une DLL et tu me donnes juste la fonction qui fait un apel externe !?)



Edit : Bon, je continue de galérer, j'épluche tes codes en cherchant mon pépin avec mon mode3D. (marche nikel en 2D, mais en mode3D, les éclairages non dynamiques ne s'affichent pas encore ^^)

Lol Topaze, le code d'une librairie est visualisable de toute façon, puis il me semble que Bast ne cherche pas à protéger le code de ce moteur (par rapport à ce qu'il m'avait dit quand j'avais tenté de le porter en 3D).