Bon a part les image qui ne s'affiche pas bein lit ( sa a été traduit par un traducteur google)!!! :
La fabrication d'un config.bmp de base qui fonctionne est vraiment simple, et probablement pas même digne d'un article dans l'omnibus. En fait il est plus facile que je rends lui le bruit juste ci-dessous, mais j'ai voulu être complet pour les types de technologie qui veulent comprendre chaque détail. Mais je figure que c'est un bon endroit à commencer avant que j'obtienne à plus de pièce d'amusement de l'article.
D'abord, il y a vraiment seulement une règle concernant la façon dont une région est divisée en villes : que chaque ville est à angle droit de 1km, de 2km, ou de 4km sur un côté (alignant sur une grille de 1km) et les villes ne peut pas recouvrir. Pour la simplicité, la plupart des personnes font leurs régions de sorte que les villes remplissent rectangle (souvent 16km x 16km) mais ce n'est pas complètement nécessaire, car nous verrons plus tard.
Quoi qu'il en soit, le dossier de config.bmp est un dossier à mémoire d'image standard de Windows (ou OS/2). L'intensité de la couleur devrait toujours être 24 bits (couleur vraie) et la largeur et la taille en Pixel devraient égaler l'ampleur est-ouest et l'ampleur au nord-sud de la région en kilomètres, respectivement.
Chaque Pixel représente un kilomètre carré dans la région, et la couleur du Pixel est déterminée par la taille de la bâche de ville qui ajustent. Le rouge (RGB=255,0,0) est pour de petites villes (de 1km), vert (RGB=0,255,0) pour le milieu (2km), et bleu (RGB=0,0,255) pour de grandes villes (de 4km). Par exemple, une région de 9x7km pourrait être divisée comme ceci :
Et le config.bmp (4x agrandi ici pour la clarté) ressemblerait à ceci :
Tandis que je suis à lui, je noterai que les dimensions de l'image à fond gris de heightmap peuvent être obtenues en multipliant les dimensions de config.bmp par 64 et en additionnant 1. Ainsi des 9 par région de 7 kilomètres auraient besoin d'une image à fond gris de heightmap de la taille 577 par 449 Pixel.
Toute la ceci est jusqu'ici juste au sujet de la connaissance commune. Jusqu'ici.
Le premier « secret » que je vais dire est comment SimCity interprète les couleurs dans config.bmp. Chaque Pixel ne doit pas être un rouge, vert purs, ou du bleu. En fait, la couleur de *any* peut théoriquement être employée dans un dossier de config.bmp.
Quand SimCity regarde un Pixel dans config.bmp, tout qu'il s'inquiète vraiment est environ si chaque canal de la couleur est 255. N'importe quelle autre valeur de 0 à 254 pourrait aussi bien être zéro. Maintenant n'importe quel Pixel où la valeur rouge est 255 et les deux autres valeurs ne sont pas 255, le Pixel est considéré comme rouge. De même, n'importe quelle couleur où les valeurs rouges et bleues sont 254 ou moins et la valeur verte est 255 est considérés verts, et n'importe quel Pixel avec une valeur bleue de 255 tandis que les valeurs rouges et vertes sont les deux non 255, est considérée bleu. Sur le ce, n'importe quel Pixel où le canal de *no* a une valeur de 255, ou si plus d'un canal a une valeur de 255, le Pixel est consdered « autre. »
Que SimCity fait-il avec de « autres » Pixel ? Il laisse cette partie de la région vide. De cette façon, on peut créer une région avec une forme irrégulière, même des trous ou des « îles » qui ne sont pas reliés (même par l'océan) à d'autres parties de la région.
Ceci peut réellement être utile en réduisant des temps d'importation pour des régions faites sur commande, car SimCity ne prendra pas le temps de traiter les parties de la région qui ne sont pas couvertes par des villes. Si une section de larege d'une région est océan, ces parties de la région peuvent être laissées non couvertes par des villes, et seulement les villes jouables ont besoin d'heure d'importer.
Un dernier secret. Si possible, SimCity ramènera config.bmp au plus petit possible rectangle contenant ses Pixel rouges, verts, et bleus, éliminant de « autres » Pixel sur le fond (sud) et bons bords (est).
La note, SimCity ne cultivera pas dehors les Pixel qui représentent réellement des villes, seulement secteurs vides. Elle recherchera alors un heightmap à fond gris dans les dimensions de *new* calculées basées sur le config.bmp cultivé.
Ceci signifie qui théoriquement, un peut prendre une photographie 640x480 (ou plus grand) numérique, s'assurent qu'aucun des Pixel n'est plus léger que (254.254.254) et puis place un config.bmp approprié dedans ou s'approchent du coin upper-left. Je ne suggérerais pas faire ceci sur l'échange de la carte de Simtropolis, cependant, parce qu'un dossier de .bmp à cette taille serait rediculously grand pour télécharger, et votre carte sera probablement supprimée du STEX.
Ce peut être amusement, bien que, pour mettre une armature gentille autour de votre config.bmp (laissant l'espace supplémentaire dans votre image à fond gris des côtés supérieurs et gauches de l'armature, puisque SimCity ne cultivera pas de ces côtés) ou le jeu autour avec les couleurs à l'intérieur de la carte elle-même tant que le soin est pris pour s'assurer vous ne changent pas comment un Pixel sera interprété par SimCity. Voici un exemple.
Une application simple de ceci est côte fertile dans le STEX là, les couleurs entre les villes sont changées un peu ainsi différentes villes peuvent être distinguées par une visionneuse humaine. Le pays et le Columbus* de Phil montrent encore plus de techniques avançées. Il y a des manières sans fin dont les gens peuvent personnaliser leurs dossiers de config.bmp. Veuillez employer le bon goût.
* Columbus n'a pas été encore téléchargé à l'heure de cette écriture, mais un agrandissement de son config.bmp peut être trouvé dans le forum de journaux de ville.
Si vous avez n'importe quelles questions au sujet de cet article, svp P.M. STomnibus
- When life gives you lemons ask for tequila and salt
- Endless traveller
