CBNA SmartLight - Moteur de lumière

Lol non c'est pas la GME, GMF p-e ? (GameMaker en France, un truc comme ça)
Bah après le probleme c'est que la communauté est dispersée partout en france et au québec :p

...Et ailleurs...

Ce n'est pas vraiment le bon topic pour discuter de ça. :)

Ouais, désolé ^^"

Bref, ce moteur ne me servira pas pour mon projet en cours, mais qui sait ? Je l'utiliserai peut-être un jour :p

C'est génial Merci

"La couleur de la lumière étant déterminée lors du rendu par la variable sl_light_color."

Faut le mettre où cette variable ?

Edit: En fait non, oubliez la question, je suis en 5 FPS avec ce système trop lourd.

nha mais de base calcul poussé sous gm = epic fail, normal que ca rame

moi chez moi ca rame pas, ca reagis 30 seconde après mais ca rame pas

J'adore regarder et écouter ta vidéo HD !
J'espère qu'il va y avoir au moins 1 jeu de qualité qui va exploiter, et faire honneur à ton système.
Est-ce que certains ont déjà commencé à l'utiliser ?

Perso, je m'attelle pour l'instant à faire honneur à ton précédent système ^^

Perso ce système est trop lourd pour mon pc avec GM (bien que magnifique faut le reconnaitre).

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).