Voila, c'est pas vraiment un tuto mais je savais pas ou mettre (il y a pas de 'Autre' pour Game Maker)

Comme promie je dévoile une astuce simple.

N'importe quelle room dans game maker, peut être infiniment grande.
Enfaite La taille de la pièce (room_widthet room_height) ne limite pas la taille de la pièce réelement.

Tous d'abord il suffit de débloquer la view, pour se fair il ne faut pas lui attribuer d'objet a suivre depuis l'editeur de room mais fair un code en GML simple suivant un objet, taper manuelement dans un step event comme :
view_xview=OBJET.x-view_wview/2
view_yview=OBJET.y-view_hview/2

et surtout ne pas empècher la view d'aller en dessous de valeur 0 ou que la limite de la room comme if view_xview<0 {view_xview=0;}
(adresser aux utiliser confirmer en gml qui on l'habitude)

1)

Effectivement, si vous déplacer la view plus loin que la dimention de la room (en bas a droite) le background continue si il a était cocher Tile Vert et Tile Hort dans catégorie Background de l'editeur de room, et des objet peuvent être visible et intéragir comme ceux se trouvent dans les limites. Donc la taille d'une room est inifniment grande dans cette direction (voir photo)

2)

Quand en haut a gauche, il a aussi possibilité d'étendre la room a l'infinie : le backgrounds peuvent commencer avec décalement : on peut mettre un chiffre négatif aussi grand que l'on souhaite, et les objet peuvent aussi exister.

3)
Il y a en contre partie un inconvénient, il est impossible de placer des objets a coordoné négatif ou plus grande que la taille de la room depuis l'editeur de room de game maker, fait si vôtre projet est munie d'un editeur de carte par exemple, on d"un placement d'objet par code en debut de room, c'est possible de placer les objet n'importe ou.

Ptit exemple : une room qui fait par exemple 800x600,


On peut placer des objets A,B,C de coordonée : 2500,500 ou 500,2500 ou -1000,-1000 (reconnaissable par des point rouge sur le schéma si dessus).
La view centrer sur l'objet A (2500,500)


Un porblème ? une question ? n'hesitez pas

Ca ressemble plus à un bug, qu'à une fonctionnalité voulue par les créateurs de GM. L'informaticien que je suis se dit qu'à un moment donné le programme plantera car il essaiera d'écrire dans une zone non-allouée (dépassement de capacité d'un tableau par exemple).

Tant que ça fonctionne, autant en profiter mais cela ne veut pas dire que cette particularité ne sera pas corrigée dans une version ultérieure.


edit: A y réfléchir, c'est surement voulu à cause du support de la 3D. Puisque la vue 3D, elle, est infinie !

Reste que ce n'est pas très "beau" d'un point de vue informatique et qu'en interne cela doit poser des problèmes de taille de coordonnées.

Bien vu quand même

Merci

Je me pose qaussi la question si cela est un bug ou une ouverture voulu par le concepteur.

Figure toi que j'utilise plutot cette "faille" pour mes editeur de carte, car tous le monde c'est qu'il est impossible de changer instantanément la taille d'une room dans la quelle on se trouve, alors je change des variable qui bloque la view a la place, mais je n'ai jamais vraiment créer de jeux dont les carte soit inifinie car comme tu la dit, il y a risque de plantage.

Une question que je me suis toujour poser, le jeux vidéo DeltaForce, est un jeux 3D qui est réputer pour être un jeux assez stable et adaptable pour l'époque, était capable de généré des carte 3D (avec des élévation différente selon les coordoné) infinie, je n'ai jamais compris comment ...

Beaucoup plus simple :
Le room width et le room height ne servent à rien en réalité enfin, quasiment rien.

Juste pour
- avoir les ascenseurs horizontaux et verticaux sous l'éditeur de GM, - avoir l'event "hors de room" dont on peut très facilement se passer.
- la caméra dans le mode 3D se sert de cette valeur pour définir un truc genre ses "ports", il me semble, mais on s'en moque, une foi le jeu lancé, on peut modifier ces valeurs donc bon.


Et perso, mes rooms dans mon jeu n'auront pas seulement une taille illimité, mais un nombre d'objet et de tuile illimité aussi, il suffit juste de réfléchir un minimum et de programmer en conséquence. La seul vrai limite, c'est les calcules (d'affichage et codes à éxécuter) consernant la masse chargée et activé.

Deplus, grâce à GM8 et son import/export de room, on pourra même m'en faire.

Je suis occupé en ce moment, m'enfin, arrangez vous pour faire des desactive all/activeregion une foi par second (activé une région plus large que l'écran), arrangez vous pour pouvoir charger/décharger les tuiles et les objets hors de GM dans un fichier texte et de recharger ce qu'il faut quand on s'approche de la fin de la zone dont on a chargé les obj et les tuiles et le tour est joué


Real Infinite room powaaaaaaaaaa (pour chargement déchargement des obj et tuiles, on peut se facilité la vie avec l'un des systèmes dispo je ne sais plus où [car je ne l'ai pas encore intégré mais je n'ai aucun doute du résultat.])

Il reste le problème de dépassement de valeur. Si les coordonnées sont codées sur des entiers (32bits), la limite pourra être atteinte. Il faudra quand même aller jusqu'à la -4294967295 ou +4294967296, mais dans un jeu de vitesse par exemple, ca pourra arriver.

Bon, il reste quand même de la marge.

Par contre, concernant la charge/décharge dans des fichiers textes, je ne pense pas que ce soit une bonne idée quand on connait le coût de lecture/écriture sous Windows. Par contre, créer une DLL pour enregistrer/charger des données sérialisées peut se révéler intéressant (reste à écrire cette DLL).

j'utilise Other intersect boundary en event et en actions j'utilise javascript:emoticonp('')
Il faut bien créer plusieurs Rooms.


Cordialement

On veut une room avec une taille infinie, pas plusieurs rooms mises bout à bout!