pour gérer une ville avec une voiture qui se promène ( la mienne)? Plus précisément, ce que je voudrais faire, c´est un peu comme des " tiles" mais en 3D.

Prenons comme exemple que ceci est ma ville vue de dessu. http://img64.imageshack.us/img64/9986/ville4qs.jpg

La ville fait 100*100 pixels, divisé en case de 10*10 pixels.

Je voudrais remplir chaque case par une petite partie de ville, exemple, une rue, un virage, un batîment, etc. Bien sur le tout sera beaucoup plus grand que 100*100 pixels, je crois essayer de commencer par au moins 20*20 cases, et peut-être grandir de plus en plus.

Bon, ma question est : est-ce que ceci prendra un ultra-méga-super gros PC viril? Ou bien si c´est possible d´être joué sur un PC de 500 MHz par exemple?

Pour info, le tout est fait sous BlitzBasic.

Merci d´avance.

Presque tous les jeux sont faits comme ca, c´est possible

C´est pas le concept mais la mise en application qui détermine la puissance nécessaire...

Si tu fais des High Poly, avec un code mal optimisé ça passera pas...

Si tes Polys sont raisonnables, que le code est bien optimisé...ya pas trop de problème

Bah, pour les polygones, seul ma voiture aura beaucoup de polygone, car c´est quand même le plus important, et les batîments, ca risque d´être simplement un primse à base rectangulaire, avec les 4 textures de chaque côté.

Les routes, ce sera la même chose, les coins de trottoir seront assez rond, ( environ 10 côtés max).

Y´aurais aussi un problème de code, je l´expliquerais après dîner.

c´est surtout au niveau optimisation d´affichage et stockage des données, qu´il va falloir bosser, Arbre BSP, quadtree, octree etc...

si t´as l´intention d´afficher toute ta ville a chaque fois, oui il va te falloir une GROSSE config.

Pas d´accord avec TomtomClancy, dans le acs du tiling, tu n´as pas besoin de quadtrees.
Un petit calcul pourrait permettre de te prouver que ton PC est assez puissant :

tu ramenes ta ville a un tableau à dimensions dans lequel tu stockes le " type" de tile

Imaginons que pour chaque tile, tu gardes 4 octets ( ce qui pourrait te permettre d´énumérer + de 4 milliards de tiles différents) ( on tape super large)
Si ta carte fait 20*20 comme tu dis, on calcule l´espace de mémoire nécessaire :
20*20*4 = 1600 octets = 1,6 Ko.
( Est ce que ton PC a 1.6 Ko de RAM disponible ? Largement tu le sais surement, mais les PC actuels ont bien 512 Mo de RAM. Meme les vieux PC maintenant ont encore 128 Mo de RAM,
ce qui pourrait permmettre de stocker + de 100 000 fois un terrain 20*20

Si tu fais une carte de 1000*1000 tiles, ça fait 4 Mo d´alloués, ce qui se gere encore tres bien !
Et oui, c´est a ça que ça sert, la RAM dans les PC ! apres la puissance du processeur ne sert pas pour le stockage du monde sous cette forme.

Apres, j´explique pourquoi le quadtree n´est pas nécessaire ici : comme la structure est tres réguliere, calculer les tiles mis en jeu pour un x/y donné revient a faire
divisions uniquement : c´est la méthdoe la plus rapide qui soit

ah ben j´avais pas bien compris le probleme alors, je pensais qu´il voulais afficher en 3D.

bon ben j´aurais raison une autre fois

Si si c´est en 3D sont truc.

Mais bon peu importe, la discussion porte sur la facon de stocker des données et non la nature de ces données.

Donc diviser le monde en grille, c´est la methode la plus bourrine et la plus simple.

Dans TombRider, on a un merveilleux exemple de grille 3D ( voxel)
--> tout n´est que cubes de la meme taille
Cependant, vu la taille des stages ( et sachant qu´en dimenesion 3, ça monte bien + vite, a mon avis, il devait y avoir une compression quelquonque ( surtout pour les zones sans briques... RLE ?

JeanYvesYves
Posté le 25 juillet 2005 à 09:39:53
Pas d´accord avec TomtomClancy, dans le acs du tiling, tu n´as pas besoin de quadtrees.
Un petit calcul pourrait permettre de te prouver que ton PC est assez puissant :

tu ramenes ta ville a un tableau à dimensions dans lequel tu stockes le " type" de tile

Imaginons que pour chaque tile, tu gardes 4 octets ( ce qui pourrait te permettre d´énumérer + de 4 milliards de tiles différents) ( on tape super large)
Si ta carte fait 20*20 comme tu dis, on calcule l´espace de mémoire nécessaire :
20*20*4 = 1600 octets = 1,6 Ko.
( Est ce que ton PC a 1.6 Ko de RAM disponible ? Largement tu le sais surement, mais les PC actuels ont bien 512 Mo de RAM. Meme les vieux PC maintenant ont encore 128 Mo de RAM,
ce qui pourrait permmettre de stocker + de 100 000 fois un terrain 20*20

Si tu fais une carte de 1000*1000 tiles, ça fait 4 Mo d´alloués, ce qui se gere encore tres bien !
Et oui, c´est a ça que ça sert, la RAM dans les PC ! apres la puissance du processeur ne sert pas pour le stockage du monde sous cette forme.

Apres, j´explique pourquoi le quadtree n´est pas nécessaire ici : comme la structure est tres réguliere, calculer les tiles mis en jeu pour un x/y donné revient a faire
divisions uniquement : c´est la méthdoe la plus rapide qui soit
Excellent, mais comment je fais pour savoir combien d´octect prendra chaque morceau? Est-ce la taille des fichiers? Par exemple, " maison.x" ?

ta maison.x ne va etre chargée qu´une seule fois... puis affichée a chaque fois que tu l´appelles ( c´est a ca que servent les listes d´affichage en opengl par exemple)

en fait pour résumer, chaque case de ton monde ne contiendra que des pointeurs vers des listes d´affichage

combien d´octect prendra chaque morceau >

Alors. Au niveau de ta map, on a dit, maximum 4 octets par tile : tu stocke juste le type de tile a mettre

Bon maintenant, apres, il faut aussi stocker, pour chaque type, le tile lui meme !
C´est a dire l´image, le bitmap.
En non-compressé, c´est simple, en haute résolution tu comptes 4 octets par pixels. Pour chaque tile, tu multiplie donc X*Y*4 pour avoir la taille en otcte d´un tile.

L´avantage, c´est que tu ne stockes un tile qu´une fois en mémoire : c´est a dire que si dans ton monde, tu as une grande foret, tu as donc un grand bloc de tiles qui sont de type 12 par exemple ( tu dis que 12, c´est un tile d´arbre)
mais le tile darbre, lui, tu ne l´as qu´une fois en mémoire, tu vois?

tout a fait

mais il faut quand même définir les positions des tiles, et ça peut prendre pas mal de place en mémoire, non? ou y´a une façon d´optimiser le positionnement?

Ben la position des tiles, c´est les 2 ou 4 octets qui définissent, pour chaque case, le type

la position est implicite, puisque tu definis une grille et chaque élément de cette grille est le type du tile qui se trouve a cette position ! donc CQFD

Apres, si tu veux gagner en mémoire, tu peux compresser , mais bon, apres tu perds en puissance...

oki