CBNA SmartLight - Moteur de lumière

Idem,juste la vidéo en HD ramme

> Mise à jour: 1.2

- Optimisation du nombre de surfaces nécessaires au rendu des lumières (réduction du volume de VRAM requis).
- Optimisation du rendu des lumières (réduction de la charge processeur).
- Optimisation de la gestion de la mémoire vidéo (VRAM): à présent, seules les lumières directement visibles à l'écran sont stockées en mémoire.
- Suppression de la variable sl_light_forcerender (sa fonction étant maintenant assurée automatiquement).
- Variable sl_light_shadowscale remplacée par sl_light_shadowlength.
- Variables xx, yy, w, h renommées avec le préfixe sl_ afin d'éviter d'éventuels conflits de noms.

Certains se plaignaient que le rendu rame: vous voilà servis. J'ai revu certaines logiques et appliqué de nouvelles méthodes qui me trottaient dans la tête depuis un moment, ce qui m'a permis de réduire considérablement le volume de VRAM occupé ainsi que le nombre d'itérations/samples à calculer lors du rendu des ombres.

Voici un benchmark réalisé à l'aide de la version d'évaluation de EVEREST v5.5, et se basant sur un walkthrough pré-enregistré de la démo technique avec d'abord la v1.1 du moteur, puis la v1.2. On y observe le pourcentage d'utilisation processeur, et l'usage de la VRAM (sachant que j'avais d'autres applis en arrière plan au moment du test).



En voici un autre, réalisé cette fois-ci à l'aide de FRAPS, présentant le framerate de la démo technique avec la v1.2 du moteur, d'abord sous GameMaker 7 puis sous GM8.



Les précédentes performances du moteur étaient satisfaisantes, celles de cette nouvelle version le sont encore plus. Donc à moins de jouer sur un laptop vieux de 4 ans avec un chipset graphique minuscule, tout le monde devrait être en mesure de profiter de ces effets graphiques avec un framerate décent. Je rappelle au passage que la démo présente un rendu simultané de l'ensemble des systèmes offerts par le moteur (ombres solaires, cycle jour/nuit, ombres ambiantes, nombreuses lumières dynamiques, etc), mais ne vous y fiez pas trop: il ne vous est pas obligatoire de tous les afficher en même temps, et pris à part, chacun de ces modules sont très rapides même sur une petite configuration.

À votre bon cœur m'sieurs dames.

C'est vraiment super ça. Dès que je rentre chez moi je teste sur mon vieux pc
En tout cas les progrès sont assez remarquables, bien joué !

wouhouuu une maj \o/

Promis, si jamais je finis un jeu(je dis ça depuis 8 ans lol), j'intègre ton moteur!

De toute façon, il est toujours intégré au début du développement de mes jeux :p

C'est maitre topaze qui va être ravis
Sinon beau boulot pour l'optimisation

Magnifique !

Le moteur était déjà génial, et maintenant, tu l'améliore encore.
Il va finir par devenir parfait XD

En tout cas, encore bravo !
Et surtout, surtout, merci de le laisser en libre usage !

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?

Super Bast ! On en est pas rendu là, mais je pense bien qu'on va tenter d'utiliser ton système pour notre jeu.

lol, tres bonne mise a jour !

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.

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