CBNA SmartLight - Moteur de lumière

Bast a écrit:

Je vais encore essayer de gratter un peu de performances, mais après ça je pense pas qu'il sera possible de pousser le rapport ressources/qualité graphique plus loin.

daminetreg a écrit:

Merci Bast, c'est du beau boulot ces optimisations. Cela mériterait un annoncement sur le site non ? (Copier/coller de ton post)

EDIT: Cela fonctionne très bien avec Wine sous Linux (avec dx9.0 d'installé). J'ai du 6 fps sur 60 sur mon laptop dans la Tech Demo mais c'est très jouable, je me demande d'ailleurs si ce n'est juste pas l'affichage des fps qui buggent sur linux. Et la démo avec les lumière que l'on drag/drop fonctionne très bien aussi.

Tu savais qu'une boîte de jeu m'avais déjà fait entendre que la porte serait ouverte pour toi quand je leur avait montré ce que tu faisais?

Je suis flatté de lire ça, mais je ne connais pas beaucoup de boîtes qui développent sous GameMaker. Enfin bon je suis toujours content de savoir que ce que je fais est apprécié.

Quand tu parles de l'affichage des FPS, tu veux parler de l'affichage in-game ou bien d'un programme à part (Fraps..) ? Et sinon je veux bien d'une news sur le site (ça lui donnera un peu de vie), je le ferais bien moi-même si mon compte était toujours fonctionnel.

Généralement les boîtes n'embauchent pas que des compétences mais aussi des attitudes et de plus toi tes compétences tu ne les place pas nécessairement dans la technologie que tu utilises, mais dans la qualité de tes algorithmes, après peu importe le système sous jacent, tu parviens au même résultat, le temps d'adaptation serait très certainement mineur si tu devais passer à un autre langage.

Aussi les boîtes ont des projets tampons plus petits sur lesquels il arrive qu'il n'y ait qu'un seul programmeur, cela permet de gagner de l'argent avant le démarrage d'un second contrat, pendant que les autres développeurs préparent une maquette pour obtenir un contrat. Et de toutes façons dans une ambiance de ce genre, les différents développeurs partagent l'information et quand quelqu'un a des qualités de réflexion importante comme toi c'est peu coûteux de demander à un des développeurs d'expliquer et de montrer d'autres langages et technologies à ce dernier.

De toutes façons une fois que tu connais un langage, les autres ne sont plus qu'une phase d'adaptation plus ou moins longue, mais le plus dur est déjà fait: tu sais programmer.

Oui c'est l'affichage in game qui ne bougeait pas. Je devrais tenter avec un programme du style de fraps, mais sous Linux avec Wine cela peut être compliqué

Pour la news sur le site, je t'envoi de nouveaux identifiants après le repas.

> Mise à jour: 1.2.5
- Ajout de la variable sl_tod_active, permettant de configurer les variables de lumière globale sans avoir à passer par un tableau 'ToD'.
- Création d'un nouvel utilitaire d'édition, permettant de conçevoir des ToDs et lumières puis de les importer dans GameMaker.

N'étant pas satisfait du précédent éditeur de ToD, j'en ai conçu un nouveau qui englobe maintenant également l'édition des lumières. Il est donc possible de créer, d'éditer et prévisualiser le cycle jour/nuit et les lumières en temps réel, puis d'enregistrer leurs variables afin d'en faire directement usage dans GameMaker; ce qui rend le moteur encore plus facile et rapide à utiliser qu'il ne l'était déjà.

oh mon dieu Bast, je vais te demander en mariage....

je sais pas comment t'as fait, mais cet éditeur est carément orgasmique....
Je viens de jouer avec en comprenant tout, tout est intuitif, facile à utiliser, et j'en passe....

C'est vraiment d'une réalisation professionnelle, tant dans l'ergonomie que dans l'interface en elle même!

Franchement, chapeau.
Je crois que je vais me mettre à faire un jeu juste pour l'utiliser :p
Quitte à faire un pong.

pfffffffffffffffffff ! je pensais que ce qu'il faisait était le top du top mais il continue encore de l'améliorer... Quand s’arrêtera t'il ?
Le cycle jour nuit m'interresse beaucoup. Je n'ai pas trop eu le temps de regarder les codes, mais vous pensez qu'il y aurait moyen d'isoler juste cette fonction facilement ?

Il est possible de n'activer que les éléments voulus, donc oui, mais juste le séparer dans un script à part, non. Le moteur a été conçu comme un tout et n'est pas juste un amas de différents systèmes, chaque élément est directement imbriqué dans l'autre afin d'offrir un rendu unifié et crédible.

M@d_Doc a écrit:

oh mon dieu Bast, je vais te demander en mariage....

Je pensais bien que ça te plairait. :)

Topaze22 a écrit:

Le cycle jour nuit m'interresse beaucoup. Je n'ai pas trop eu le temps de regarder les codes, mais vous pensez qu'il y aurait moyen d'isoler juste cette fonction facilement ?

Normalement faire un cycle jour nuit c'est pas sorcier, tout dépend de ce que tu veux en fait.

Sinon ben que dire Bast, c'est encore plus parfait qu'avant :p

Et bien bast, tu as beaucoup de talent (j'espère programmer aussi bien que toi maintenant), j'ai testé avec un système de changement de résolution automatique et que dire c'est magnifique.
Un grand bravo, j'ai envie de faire un jeu juste pour utiliser ton système.


edit : je veux dire que je voudrais avoir le niveau que bast à maintenant plus tard.

Enorme Bast. C'est génial. C'est cool de l'avoir rajouté sur le site, mais pitié une news sur le site ce serait merveilleux. Avec la screenshot de ton éditeur ce serait parfait.

Je sais pas si je l'ai déjà dit, mais ce système est awesomesque ! J'ai juste une question, on peut utiliser des backgrounds (tiles) au lieu d'utiliser des sprites et objects ? Ce serait plus léger pour ce que je désire faire. Ce serait génial !

Ce n'est pas impossible, mais je doute que ce soit la méthode la plus optimale qui soit. Avoir des tiles qui réagissent à la lumière serait effectivement moins lourd que d'avoir le même nombre d'instances vu qu'il n'y a pas de gestions de variables ou de collisions, mais contrairement aux instances qui peuvent être appelées facilement à partir de l'index des objets, il n'existe pas de fonction semblable pour les tiles; il faut donc aller chercher leurs IDs manuellement avant de pouvoir les inclure dans le rendu des lumières. Reste à savoir si ce processus est plus lent que la gestion d'instances ou l'appel de fonctions draw (SL_cast_sprite).

J'ai rapidement testé cette petite chose qui parcourt l'index à la recherche de tiles, mais c'est bien trop rudimentaire et très peu fiable.

Code:

i = 10000000;

while tile_exists(i)
{
  draw_background_part(tile_get_background(i),tile_get_left(i),tile_get_top(i),tile_get_width(i),tile_get_height(i),tile_get_x(i),tile_get_y(i));
  i += 1;
}

La seule solution viable serait de parcourir la surface de l'écran avec une double boucle, en récupérant l'id des tiles avec la fonction tile_layer_find(depth,x,y), puis de les afficher avec un blend noir dans le buffer des lumières comme les autres textures (ligne 210 du script SL_engine_render).

Si tu en as réellement besoin j'essaierai d'expérimenter ça dans une version future, mais pour le moment je vais déjà m'assurer de terminer la mise à jour que je compte sortir dans les jours qui viennent (je publierai peut-être une news sur le site, pour le coup).

Bast a écrit:

Puis de les afficher avec un blend noir dans le buffer des lumières comme les autres textures (ligne 210 du script SL_engine_render).

Oula, trop compliqué, j'crois que je vais continuer la méthode simple.

Au fait, pour reprendre ce sujet, j'ai bien tenté de modifier la valeur de ces 3 fonctions mais ce n'est pas celles-ci que je dois utiliser (ou du moins, ça en a pas l'air). Moi ce que je veux, c'est éclaircir la zone noire pour que la map soit moins sombre. Si je mets un petit scale, le rendu est celui de gauche. Un grand scale est le rendu de droite.



Voici le rendu sans lumières:



On voit bien que la map est beaucoup plus sombre avec les lumières. Où se trouve la fonction qui gère ça ?

Dans l'objet qui gère le rendu (obj_engine dans les exemples), écris ceci dans un événement quelconque:

Code:

sl_tod_active = 0;
global.sl_ambient_light = 0.5;

La première variable désactive le cycle jour/nuit automatique, la seconde modifie la puissance de l'éclairage ambiant (qui est donc la valeur que tu veux modifier).

Merci, c'est nickel !

Ton jeu a un joli style pixel art. Je trouve que ton jeu est très beau, et le moteur de bast très beau, mais qu'il ne vont pas ensemble. C'est comme ajouter un moteur lumière à metal slug, ça ruinerait tout.

Après, ce n'est que mon avis :3

Ah bon, merci. Je préfère quand même avec ce système de lumières, ça rend la map plus vivante (même si c'est sombre). Mais je prends ton commentaire en compte si j'hésite encore après finition de la map.

> Mise à jour: 1.3
- Optimisation du rendu des ombres solaires (réduction de la charge processeur).
- Amélioration de la résolution des sprites affichées dans le buffer d'ombre.
- Le système de sauvegardes de GameMaker est maintenant correctement supporté.
- Révision et optimisation de la mise en page des scripts.
- Correction de la gestion des arguments de SL_cast_sprite.
- Correction de la gestion des marges du rendu des ombres solaires.

J'ai tenté d'éclaircir un peu la syntaxe des codes, à la fois dans les scripts et les exemples; j'écris d'habitude de gros pâtés peu aérés, et je conviens que ça ne facilite pas la compréhension pour un lecteur tiers. J'ai également revu certains codes dans le .gmk de la démo, qui dataient d'il y a plusieurs années et que j'ai donc réécrits un peu plus intelligemment. Ceci devrait être la dernière mise à jour avant un bon moment, à moins que des utilisateurs trouvent des bugs.

je comprends pas trop le truc avec les sauvegardes gm...
C'était quoi le soucis et c'est quoi qui marche maintenant?

Vu que les surfaces ne sont pas sauvegardées et que leurs ids peuvent changer entre deux parties, il est nécessaire de supprimer puis re-créer l'ensemble des surfaces pendant le jeu lorsqu'une sauvegarde est écrite ou chargée. En bref, le code suivant aurait auparavant provoqué une erreur, ce qui n'est plus le cas:

Code:

SL_engine_free();
game_load("save.sav");
SL_engine_ini();

Bien sûr, en pratique tout ce qui se situe après une fonction game_load dans un même événement n'est pas exécuté, donc ce code tel quel ne fonctionnerait pas. Mais l'idée est là.

Salut, je regardais un peu les scripts, ainsi que les précédents posts du forum et je me demandais comment y inclure la détection du personnage dans l'ombre ou du moins vers quel script ou quelle ligne se retourner. Tu parlais du collision_line mais comment savoir avec cette fonction que l'on se trouve dans une ombre. J'aimerais un petit éclaircissement si possible M. Bast. Merci d'avance ! Et encore bravo pour ce moteur c'est facile à intégrer et fantastique en visuel.

La fonction collision_line permet de tester la présence d'un objet entre le personnage et une lumière, et donc de savoir si le personnage se trouve dans l'ombre de cet objet ou non. Voici une méthode possible, qui prend également en compte la distance par rapport à la lumière:

Code:

Visible = 0;
with obj_light if point_distance(x,y,obj_char.x,obj_char.y)<320 && !collision_line(x,y,obj_char.x,obj_char.y,obj_occluder,0,1) other.Visible = 1;

Je t'en ai fait un petit exemple.
http://www.lecbna.org/bast/gamemaker/cbna_smartlight/sl_exemple_visible_GM8.gmk

Merci pour tout Bast (y compris l'exemple ), j'ai choppé l'idée, je suis bête de pas y avoir penser avant ! Je mets tout ca en place et je te tiens au courant ! Sinon autre question, peut-on enlever facilement l'effet volumétrique du rendu car dans du 2D vu de côté ca crée parfois quelques effets à moins que ce ne soit pas ca ! MErci encore

Si tu parles de l'effet suivant:

Spoiler:

Tu peux régler la diffusion des ombres en ajustant la variable sl_light_shadowsharpness d'une lumière.

encore merci pour l'astuce ! Sinon, je suis arrivé à glisser une bonne détection aux niveaux des ombres, ca fonctionne nickel ! Une dernière question (enfin j'espère ! ^^). J'ai des ombres bien crénelées à certains moments et je me demandais comment tu faisais pour toujours avoir de l'ombre super lisse, j'ai essayé de corriger en jouant avec pas mal de variables mais sans résultats concrets ! Que faire docteur ?
Encore merci d'avance pour ton aide !

Les ombres sont rendues en superposant des samples, et si ces samples sont trop éloignés l'un de l'autre cela peut causer un effet de crénelage. La variable permettant de régler ça est sl_light_shadowfactor (je te renvoie à la doc pour une explication plus en détails).

Il est également possible de se retrouver avec du crénelage si les dimensions des textures sont trop petites (ou si le scale des lumières est trop important), mais à moins d'avoir des textures de lumière en 50x50 ça ne posera pas de problèmes.

Re merci !!! Et m'en excusant d'avance, j'ai failli, j'ai encore une question. Est-ce qu'il est possible d'appliquer smartlight à plusieurs vues en simultanée ? Et si oui, comment ? J'ai vu dans la fonction ini que ca s'appliquait à la current view et ca me parait compliqué (en tout cas à vue d'oeil), d'étendre le système à de multiples views. donc si une voie plus facile existe, je suis preneur ! Merci encore pour tous tes conseils !

Le système a été conçu pour fonctionner avec une zone d'écran unique. Il n'est pas impossible de générer un affichage pour plusieurs views, mais cela implique de multiplier le nombre de rendus des buffers d'écrans, des masks, et même des lumières et ombres, par autant de views qu'il y a à l'écran. Ce n'est pas performant, et je le déconseille fortement.

Si toutefois tu désires tout de même le faire, il suffirait de retirer le "global." de global.sl_viewid en utilisant une fonction de remplacement automatique dans le fichier .gml, puis de créer autant d'objets engine que de views, en assignant à chacun une view différente. Je n'ai pas testé, mais ça devrait fonctionner.

..Mais je le dis encore, c'est une très mauvaise chose à faire, et il vaudrait mieux éviter.

Ba une view fait que couper l'écran, les performances devrais pas tant changer que ca non?

ben disons que les calculs exécutés dans la fonction render doivent être eux multiplier ce qui peux rendre l'effet un peu gourmand ! Je m'en doutais un peu ! Je vais tenter l'expérience quand même pour voir. Ça tombe ca peut fonctionner pour ce que j'ai envie de faire. Je vous tiendrais au courant ! Merci encore Bast ! Ah aussi petite précision le système fonctionne très bien avec game maker 8.1 standard !

Ce ne sont pas juste les calculs de rendu qui doivent être dupliqués, mais également toutes les surfaces, et donc l'espace VRAM occupé. Ça va lourdement ralentir ton jeu pour pas grand chose.

Wargamer a écrit:

Ba une view fait que couper l'écran, les performances devrais pas tant changer que ca non?

Deux views, c'est deux affichages différents et indépendants l'un de l'autre, et qui nécessitent donc chacun des buffers et calculs uniques.

traduction : Dans un jeu de plateforme en 2D sous GM, à chaque image à afficher, gameMaker regarde toutes les tuiles pour afficher les bonnes. Si tu as des instances d'objets avec un view activate instance, meme chose, GameMaker va regarder tout les xy de toutes les instances pour activer celles qui sont dans l'écrans. Si tu as deux views, tu ballais toutes les tuiles et toutes les instances deux fois...

Ici, avec Bast, c'est pareil, deux views, ça veut purement dire deux fois plus de calcules. Certes, tu auras pas deux fois plus de pixels à afficher, et la surface afficher reste la même. Au vu de combien une belle vue de Bast pompe, deux vues, ce n'est pas trop pensable, sauf si tu prévois que sur le long terme, tout le monde changera bien de PC un jour. Ou que le mode deux views n'est pas inévitable dans ton jeu.

En fin de compte, je n'ai peu être pas été plus simple que tsaB



PS : à chaque foi que je regarde la vidéo HD, je n'en reviens pas. (je suis un amateur de Benchmark 3D, tesselation, unreal Engine, Crysis Engine ect...)