Salut At0 !
Tu pourrais regarder ce qu'on font certains jeux comme Enter the Gungeon ou bien encore FTL.
Pour Enter the Gungeon, ils ont:
- un mode pixel perfect (la vision exacte des créateurs du jeu), c'est en gros la résolution native de ton écran, avec des bandes noires si besoin et si ton écran supporte au moins la résolution du jeu de base (ce qui est normalement le cas des jeux en pixel art).
- un mode streched, qui va étirer sur toute la résolution de ton écran les pixels. Tu perds le pixel perfect mais tu joues en fullscreen.
- un mode où l'écran va changer de résolution pour s'adapter au jeu, cela revient pratiquement au même que l'upscale.

FTL fait plus ou moins pareil, avec des modes fenêtrés pixel perfect, natif avec blackbars et enfin streched fullscreen.

Enfin, dans binding of isaac (le 1er), ils avaient des multiplicateurs (comme les émulateurs), natif, natif x2, natif x4. C'est peut être un bon compromis pour garder les pixels "entier" (1 pixel ingame = 2 pixels écran), car ce sont surtout les demis pixels qui cassent tout selon moi.

Je suis un peu dans le même cas en ce moment je débute avec un petit jeu en pixel art histoire d'apprendre.

Pour la réso je pense que ca dépend des logiciel, y'a plusieurs options disponible en général et tout dépend du support final, mais sur pc je pense que la plupart des gens joue en hd 1080p donc mieux vaut visé assez haut niveau réso.

Dans Construct 2 par exemple j'ai fait un Set layout Scale to 2.0, pour avoir un zoom x2 propre, mes assets en pixel sont assez grand sinon j'aurai fait x4.
Pour les autres logiciel je pense que y'a moyen d'avoir des pixel propres aussi.

Mais bon j'suis un peu noob encore donc je me pose autant de questions que toi.

En ce qui me concerne j'ai pas encore eu la foi de créer un jeu mais tous mes prototypes étaient en résolution unique, pour éviter de tout flinguer xd.
Je pense que le meilleur moyen pour gérer la physique, c'est de la gérer indépendamment du graphisme, par exemple 32 pixels affichés peuvent correspondre en interne (=calculs physiques) à 16 pixels, voire 8 ... Ainsi, c'est uniquement lors de l'affichage que ce genre de choses (passer du repère "interne" au repère "externe" en gros) se fera. D'un point de vue calcul il s'agit d'un pur produit en croix : si par exemple tu veux afficher quelque chose à la position X;Y de l'écran du joueur, tu fais X(repère écran) = X(repère interne) / (largeur du repère interne) * (largeur de l'écran) ... (et de même pour Y).
En ce qui concerne la mise en pratique dans Game Maker, absolument aucune idée de comment fonctionne le bousin :/ Mais j'imagine que tu n'es pas le premier à te poser la question, donc je te conseille de d'abord chercher des extensions Game Maker, voir si y en a pas une qui est déjà codée, et que tu peux recycler direct ^^.
Pour finir, je suis pas sûr qu'un simple "taille des pixels * 4" soit suffisant pour décréter un jeu en HD ... si tu veux absolument du HD, il faudra alors reprendre chaque sprite à la main je le crains :/ Le plus simple reste comme dans Binding of Isaac (et comme le disait cAyou) du natif, natif*2, natif*3, natif*4, etc ... en gros un pixel prend 4, 9, 16 pixels dans la nouvelle résolution, quoi ...

Je pense pas qu'il y es besoin de reprendre chaque sprite à la main pour agrandir, y'a moyen de faire un zoom propre.

Par contre je sais pas si Game maker est vraiment si bien maintenant par rapport à Unity par exemple qui à un moteur 2d bien mieux foutu il me semble.

Cela dépend si tu fais des rotations ou non et si tu veux qu'elles soient "propres".

Personnellement, je n'aime pas trop "tricher" avec le pixel art donc j'évite ce genre d'effets, j'évite les lumières tamisées et les mélanges d'échelle, tous mes pixels ont la même taille, pixel perfect. Si on veut des rotations propres, mieux vaux taper au moins 4x au dessus (pour éviter l'aliasing) et coller un image_xscale=4; image_yscale=4; sur tous les objets (on peut aussi directement le faire via l'éditeur de room).

Moi sur GM, je joue avec les vues et je laisse le soft faire en mode keep aspect ratio. Quitte à ce que certain aient des bandes noires sur les côtés ou sur le dessus/dessous. Après il me semble que la plupart des gens ont un écran 16/9ème donc je vise juste ce format. Et je laisse la possibilité aux gens de jouer on fullscreen ou non et de "resize game window". On peu changer tout ça à la volée via les variables, je vois pas pourquoi ça casserait les déplacements ou les animations...

Jusqu'à il n'y a pas si longtemps, le rendu était bizarre, avec des pixels "arrondis", comme si on avec mis un shader qui simule un écran arrondi, mais depuis les dernières mise à jour le rendu est parfait ! C'est carré carré.

[PS]
Dans mon dernier projet, je simule une console portable et le jeu se fait dans son écran. La résolution du jeu (160x144 si vous voyez ce que je veux dire...) est donc bien différente du rendu de la console. C'est un peu compliqué mais en gros, je triche pas du tout, je maintiens le pixel perfect. J'ai une vue1 en 160x144 et une vue2 en fullHD et j'utilise les surfaces pour redessiner le rendu 160x144 aux dimensions qui me plaisent dans la vue fullHD et ça se fait proprement tant qu'on garde le bon ratio. Je suppose que c'est un peu la même technique pour Hyper Light Drifter.

Salut At0, salut tout le monde (1er message sur ce forum o/)

Pour la question que tu poses, j'ai justement trouvé un lien intéressant hier.
Ce sont des explications pour le logiciel Construct 2 (sur lequel je travaille (ou m'amuse, comme vous voulez ^^)) en ce moment.

Mais les explications peuvent s'adapter à Game Maker, je pense. Le nom des réglages et modes de mise à l'échelle seront juste différents.
https://www.scirra.com/tutorials/73/supporting-multiple-screen-sizes/fr

En gros, c'est possible de faire du pixe-art qui s'adapte à l'écran, mais pour garder le pixel perfect et ne pas avoir des pixels qui bavent, il va falloir que le rapport d'agrandissement ou de diminution de l'image soit un nombre entier. 2, 3, 4... mais pas 1,5 par exemple.

Sinon, théorie personnelle non vérifiée, il faut peut-être augmenter la résolution de tes assets (background, persos, objets), de sorte qu'au lieu de faire 16x16, ton perso en fasse par exemple 160x160. Comme si tu codais directement pour la résolution max et non pour la réso native d'un jeu retro en pixel qu'on upscale ensuite. (t'as suivi...X) ? ^^)

J'espère t'avoir aidé.
Je retourne sur mon jeu. Je t'ai dit sur Tweeter que je le montrais aujourd'hui, faut pas que je traîne
a+

Salut At0,

Cette question est très intéressante, et j'en profite pour y glisser mon point de vu :

A mon sens, le plus simple (et "le mieux" ?) est que tout le jeu soit rendu dans la résolution native du pixel art, et pas dans celle de l'écran ; et qu'uniquement le résultat final de chaque frame soit upscalé, dans une résolution qui reste effectivement un multiple de la résolution native de ton pixel art pour un rendu "moderne" (fait de pixels bien carrés et uniformes), ou bien en utilisant un traitement de l'image plus évolué mimant (plus ou moins) le rendu des tubes cathodiques de la grande époque (la première solution restant de loin la plus simple ; et la seconde pouvant être rajoutée secondairement sans soucis, à ta place je ne m'en préoccuperait pas de prime abord ).

Pourquoi cela ?

- pour un soucis d'homogénéité et de cohérence : en effet, dans le cas contraire tu risque de te retrouver avec des pixels se chevauchant pour des rendus (à mon sens) plutôt disgracieux (et pas vraiment en accord avec le concept de pixel art) ; si tu utilises des rotations ou des redimensionnement de sprites tu peux te retrouver avec des pixels qui ne sont plus tous de la même taille ou tous orientés de la même façon ; si tu utilises des "effets spéciaux" notamment à base de particules ou des filtres de post-processing (halos de lumière, flous cinétique, effet de profondeur de champ, ...) tu risque là encore de perdre le rendu pixelisé à certains endroits.

Spoiler :

À NOTER QUE certains jeux s'accommodent trés trés bien de ce genre de "libertés", d'un Rogue Legacy et ses redimensionnements de sprites "what the fuck" qui participent au caractère délirant de la DA, à Void and Meddler et son intégration de personnage en pixel art au sein de décors HD, en passant par Mother Russia Bleeds ... pour lequel certains rendus jurent un peu quand même je trouve (les armes aux pixels "penchés", les ombres "pas à l'échelle", les effets de flou de mouvement dans le référentiel haute résolution qui dénote avec le rendu pixel art, les sprites décalés de 1 ou 2 pixels réels avec donc des gros pixels mal alignés, les lasers des sniper en HD,...) ; j'ai beaucoup aimé Mother Russia Bleeds, mais pour le coup je pense que ce jeu aurait beaucoup gagné à être plus carré sur son rendu du pixel art, ce qu'assure un rendu natif en "basse résolution" (enfin, Mother Russia Bleeds aurait gagné à être plus carré sur beaucoup d'autres choses que simplement son rendu graphique ...mais c'est un autre sujet ).

Des jeux comme Hyper Light Drifter ou encore Not a Hero bénéficient eux d'un pixel art strict, ne lésinent pas sur les effets pour autant, et leurs rendus sont vraiment cool!

- pour assurer une bonne précision des contrôles : l'un des avantages du pixel art (ou du moins d'une basse résolution) est d'autoriser des déplacements, des collisions, des sauts, etc. "au pixel près" ; en effet placer son personnage au pixel près est bien plus aisé si la largeur de l'écran est subdivisé en "seulement" 320 positions possibles (dont chacune est bien discriminable) qu'en 1920 (dans le cas d'un moteur de jeu qui "travaillerait" en full HD). Si on place des sprites "en pixel art" dans un référentiel en haute résolution, on va par défaut se retrouver dans une situation ou un déplacement de 1 pixel pourra être "trop précis" pour être facilement appréhender par le joueur (après on peut bien sûr programmer des incrémentations ne se faisant que 4 pixels par 4 pixels p.ex., mais ça demande de bien intégrer cette règle partout et peut alourdir la mise en œuvre ; voire être source de bugs sournois :P).

- pour assurer des performances au top, et du coup avoir plus de possibilités pour "se lâcher" (sur le nombre d'ennemis, sur la taille et complexité des niveaux, sur la richesse des rendus, sur les interactions physiques,...) ; en effet faire tourner un jeu en 320x240 et tout gérer (affichage des sprites, calculs des collisions, éclairages dynamiques, filtres de "post processing", etc.) dans cette résolution sera incommensurablement plus léger que réaliser ces opérations sur une image en 1920x1080 d'emblée, quand bien même les sprites correspondront à de la basse résolution upsaclée.

A noter qu'à un moment va se poser nécessairement le choix de la résolution "native" du pixel art.
A ce titre il me parait intéressant de constater que :

• 1280 x 720 ("HD ready") = 640 x 360 x2
• 1920 x 1080 ("full HD") = 640 x 360 x3
• 2560 x 1440 ("Quad HD") = 640 x 360 x4
• 3840 x 2160 ("4K" ou "UHD") = 640 x 360 x6

et que donc cette résolution de 640x360 est un multiple de la grande majorité des standards de résolution actuels (et à venir : 4K, 8K...). Ça me parait de fait un première choix pas idiot à considérer . Après on peut affiner selon des besoins spécifiques bien sûr.

Autre point auquel il faut penser, c'est le rapport largeur/hauteur (16:9, 4:3, ...) et notamment si on le veut fixe (avec donc "bandes noires" si l'écran du joueur n'est pas au même format) ou s'adaptant à l'écran pour être toujours en plein écran. Le "toujours plein écran" peut paraitre séduisant, mais souvent problématique à mettre en oeuvre pour un jeu en 2D, car va interférer dans le positionnement des sprites et décors, dans le contrôle de la mise en scène, ou encore (plus fondamentalement) dans l'équilibrage du jeu (p.ex. un jeu est pensé avec une certaine distance en avant du personnage permettant de voir arriver les ennemis, si le jeu pensé pour du 16:9 est étiré sur un 21:9 le joueur sera avantagé car verra arriver les ennemis plus tôt ; ou bien les verras "popper" d'un coup devant lui ; ou bien ils tireront sur lui plus tôt que si le jeu était joué sur un écran 16:9 ce qui peut déséquilibrer le level-design ; et si le joueur joue sur un écran 16:10 il pourra voir un passage secret qui normalement devait être caché sous le bas de l'écran en 16:9 ; etc.). A mon sens le rapport fixe est largement à privilégier.

______

PS : bon, tout ça c'est une base théorique, mais dans la pratique tu vas te retrouver tributaire de ce que t'autorise le moteur de jeu "tout fait" que tu utilises, ces préceptes ne seront pas forcément applicables tel quel ...