pour les effets de lumière je fais comme suit:
j'applique un calque noir opaque à 80% pour donner l'effet nuit, et je creuse des "trous" en forme de sprite que j'ai défini par ailleurs dans ce calque pour créer la lumière.

Oh bah non malheureux, fais SURTOUT PAS comme ça !

Je ne sais pas comment fonctionne Game Maker, mais à mon sens il faut que tu arrives à un système où le moteur, pour chaque "pixel" affiché, identifie s'il est éclairé ou non (correspondant à un masque également, de même "forme" que celui actuel), et en fonction affiche une couleur "éclairée" ou non. L'idéal est ensuite de définir explicitement, pour chaque élément graphique, sa couleur quand il est dans l'ombre et sa couleur quand il est éclairé. C'est (théoriquement, tout dépend de comment fera Game Maker après...) bien plus performant, car à chaque fois le moteur a juste à décider si il inscrit le pixel selon telle ou telle couleur, sans à avoir à faire le moindre calcul, alors que dans ton cas il faut qu'il opère une opération "x0,2" pour chaque pixel dans l'ombre* ! Tu peux aussi complexifier en utilisant un masque en "niveau de gris" et donc une pondération de l'éclairage, ce qui pour le coup reviendra effectivement à une multiplication (double en fait), mais tu arrives à un système beaucoup plus évolué aussi.

Le méga avantage d'une telle technique c'est qu'en plus, tu peux décider que l'éclairage n'aura pas un effet uniforme (et plat) comme c'est actuellement le cas (voir ce que je disais ici), mais tu pourras décider spécifiquement comment chaque élément de décor réagira au fait d'être dans le faisceau de lumière. Pour le décor lointain (qui dans l'absolu ne devrait subir AUCUNE répercussion de l'éclairage du premier plan) il suffit p.ex. que la version à l'ombre et la version éclairée soient les mêmes, et le tour est joué. Tu pourra aussi intégrer des élément d'avant-plan qui ne soient pas éclairées non plus (ou alors juste leurs bordures) car se retrouve en situation de "contre-jour" par rapport à tes spots. Tout ça permettant de donner beaucoup de consistance et de relief à tes visuels.

Après c'est une proposition (qui plus est théorique) pondue comme ça, il y a forcément d'autres façons de faire** ;).
D'autant que, je le répète, je ne sais pas après comment intégrer spécifiquement cela à Game Maker.

_______________

(EDIT)

* En fait c'est même bien pire que ça dans ton cas, parce que tu n'appliques PAS une opération d'atténuation par une "simple" multiplication, mais (si j'ai bien compris) tu fusionnes deux "calques" : un avec le niveau en pleine lumière et l'autre représentant la découpe des ombres, uniformément noir et pondéré par une opacité de 0,8. Donc pour chaque pixel Game Maker ne va pas "simplement" multiplier la couleur du bitmap par un coefficient, mais MOYENNER deux valeurs (celle des deux calques) selon un calcul bien plus complexe = image x 0,2 + masque x 0,8. Alors que dans ton cas particulier où ton calque d'ombre est uniformément noir (valeur pour chaque pixel de ton masque = 0) cela revient à simplement réaliser une seule multiplication (image x 0,2) ; mais ça Game Maker ne peut pas le deviner, donc il fera le calcul complet à chaque fois.

** La vision la plus classique je pense restant d'utiliser les bitmaps comme des "diffuse map" (représentant donc les valeurs de chaque pixel s'ils sont "éclairés à 100%"), qui seront pondérées lors de l'affichage par une map d'éclairage, qui va donc moduler l'intensité avec laquelle chaque pixel va apparaitre à l'écran ; ce qui peut aussi moduler sa couleur car la map d'éclairage peut être en couleur (pas forcément en niveau de gris), et puis aussi facilement être dynamique. A mon avis ça reste moins "performant" que ce que je propose plus haut car limite l'effet de l'éclairage à un effet uniforme, qui ne tiendra donc pas compte p.ex. de la distance des plans éclairés. On peut en revanche très naturellement étoffer cette méthode en rajoutant des couches de données aux bitmaps, comme une notion de profondeur justement (façon "axe Z" des rendus 3D), une couche d'auto-illumination (les pixels de cette couche seront affichés tels quels, en addition du reste, sans prendre en compte le fait d'être éclairé ou non) qui peut tout particulièrement résoudre ton problème de l'arrière plan (qui correspondrait alors 100% à de l'auto-illumination, avec une diffuse map elle uniformément noire, et donc aurait son affichage complètement dissocié des effets d'éclairages), une normal map, et tout ce qu'on veut au final ; pour des rendus qui peuvent devenir super sophistiqués, mais aussi vachement plus complexes à mettre en place ! (et à calculer)
A mon avis ce que je propose est bien plus optimisé par rapport à tes visuels (où les éléments sont ou bien éclairés, ou bien à l'ombre), permettant une grande liberté (chaque élément peut réagir absolument comme tu le veux à l'éclairage), une grande facilité de mise en œuvre, des calculs très simples pour le moteur, et un travail de production des assets très réduit (dans la grande majorité des cas, la couche "dans l'ombre" sera juste la couche "éclairée" pondérée par un facteur d'atténuation, ce qui se crée en 2 secondes).

Franchement cool ton ptit jeu Et fait en grande partie dans les chiottes XD tu m'as tué! Chapeau!

Si je puis t'aider à améliorer ton fond avec mon humble avis, essai de garder les bâtiments sombre et éclairer la plupart des fenêtres d'une lumière jaune? Peut être pas toute car comme tu as beaucoup de fenêtres ça risque de nuire encore à la lisibilité. Et pourquoi pas ajouter par la même occasion quelques étoiles dans le ciel?

Bon courage dans l'avancement

Ah si c'est grave si c'est moche! XD Le fond c'est 50% de l'ambiance!
Fais nous rêver comme les arrières plans des zones de Casino dans les Sonic 2D
Bon courage!

ça ressemble fortement à une usine à gaz

Techniquement parlant, c'est moins une usine à gaz que ta technique actuelle (qui effectue beaucoup plus de calcul pour un contrôle plus limité ; et s'avère même handicapant, comme pour l'arrière plan).
Après il faut voir comment implémenter ça "élégamment" dans Game Maker, mais si creuser la chose peut te prendre un peu de temps, c'est comme ça que tu apprendras à utiliser le moteur (pas en passant par des voies détournées qui ne prennent pas en compte la façon dont le moteur travaille).

Ce qui est curieux avec les moteurs de jeu "tous faits" c'est que beaucoup en vienne à trouver normal d'utiliser des méthodes complètement bizarres (et anti-optimales) pour arriver à un résultat, et que les méthodes simples et logiques semblent inaccessibles sans sérieusement se retrousser les manches.

Je me rappelle d'un type avec qui j’avais échangé un temps (je sais plus quel moteur s'était?) qui me montrait que pour gérer les déplacements dans un jeu type dungeon crawler il utilisait une représentation graphique de son labyrinthe affiché hors-champ, avec un code couleur correspondant à différents éléments de jeu, et sur lequel il exécutait des tests graphiques afin d'identifier si une case correspondait à un mur, un ennemi, etc. ... au lieu d'utiliser un bête tableau de valeurs. Et quand je lui ai évoqué cette solution autrement plus simple et puissante (et simplement autrement plus logique), il ne semblait avoir aucune idée de comment faire !

Des fois j'en viens à me demander si débuter sur de tels moteurs (du moins sans se montrer rigoureux sur la façon de les employer) n'est pas une source de sérieux mésapprentissage du développement de jeu (sur l'aspect technique je veux dire).

(oui, bon, ok, "mésapprentissage" ça existe pas, mais j'ai pas trouvé le bon mot pour dire ça ... )