Discussion :

[Cirrus Minor]

Ca me plait bien, comme ça, il faut voir ce que ça donne en jouant, mais, en effet, on a souvent tendance à avoir les scores en haut et les éléments de gameplay en bas.

De plus, je songe adapter un système de calque

Rhooo ! J'avais lu un "système de claques" !
Ca consiste en quoi ? Dessiner une grosse partie du décors d'un coup pour éviter de dessiner les sprites un à un ?

[Vetea]

Oui voilà tu as tout compris !
Ça serait une image de fond, un background qui m'eviterait de gérer l'affichage de centaine d'objet et ainsi, d'alléger grandement la conso CPU.
Pour le système de claques, ça peu s'arranger ...

[Ynothan]

Salut Vetea,

De mon côté aussi je m'améliore même si je reste particulièrement mauvais

Je suis néanmoins beaucoup plus efficace depuis que j'utilise la touche "Z" pour tirer effectivement...

Le tank donne envie, je pense qu'on se fera un grand plaisir d'utiliser cette engin

Sinon bonne idée que d'optimiser le rendu graphique, j'imagine que c'est toujours relativement le même constat sur toutes les technologies : l'affichage est très gourmand !

Sur ce, je vais tenter d'accéder à la mission 4

[Vetea]

Merci Ynothan et bon courage !!
Le tank va être un sacre challenge au niveau game design, gameplay car le joueur devra jongler avec les touches fléchées pour deplacer le tank, Q et D pour faire tourner la tourelle et Z pour tirer.
La tourelle et le châssis étant gérer de manière différente.
L'IA des tanks ennemis sera aussi différent du reste de même que les cartes.
J'espère arriver a inclure la destruction des objets et obstacles en jeu. Je ne garantis rien mais je ferai des essais.
Un petit goût de Battlefield Rétro a la sauce Papi !
Cette technique de calque fut très utilisée a l'époque, et l'on gagnait beaucoup avec. J'espère trouver une solution et y arriver car cela réglera la stabilité de vitesse sur des machines plus lentes selon la richesse des cartes.

Bon jeu !

[Ynothan]

Merci ! Je progresse je viens d'échouer à la mission 4 avec 31850 points (je tue pas mal de soldats au couteau )

Effectivement cette technique de calque est assez intéressante lorsque l'on a beaucoup de petits objets !
Bon courage pour cette optimisation ainsi que pour les tanks

Au passage c'est cool que les tourelles soient indépendantes !

[Dabou Master]

Petit passage express d'encouragement !
Inutile mais c'est l'intention qui compte non ?

[Vetea]

Petit passage express d'encouragement !
Inutile mais c'est l'intention qui compte non ?

Yesssss ! The trailer's man is back !!!
Merci et bon courage a toi, on sait que ce projet nous donne du fil a retordre ...
Amicalement.

[Vetea]

Youpi !!

J'ai trouvé la solution de mes calques !! Enfin !

Voici une capture d'écran du calque principal du Background du 1er stage ( Il s'agit d'une partie de la carte ... )



Après le chargement des données ( Coordonnées, type de tuile, etc ... ), je traite dans une image tampon, tous les objets en arrière plan.
Ensuite cette image tampon sera affichée en premier lieu, suivi des ombres et ensuite de tous les objets mobiles ( unités, projectile, eau, etc ... )
Mais, je peux aussi procéder avec la même méthode tout ce qui est ombrage voire élément en hauteur ( affiché en dernier donc hors HUD ), donc créer autant d'image tampon qui seront des couches d'images brutes à afficher.
Du coup, l'économie en ressource CPU va être énorme pour un cout mémoire réduit.

Pour rappel, cette technique était très utilisé à l'époque des consoles 8 & 16 bits et aussi les vieux micros ... Gérer une simple image en plan était bien plus pratique qu'afficher tous les objets de la même scène !

Il y aura un peu de chamboulement dans le code puisque le nombre d'élément à traiter par le moteur en temps réel va être significativement réduit. Mais avec cette technique, les petites configuration seront un peu plus épargnées et la vitesse en jeu stabilisé pour ces dernières.

Je vous en dirai plus dans les jours qui viennent bien sûr !

EDIT :

Re youpi !!!
J'ai appliqué la même technique à toutes les ombres fixes du décor !!
C'est génial car après l'ajustement du nombre d'objet lié aux ombres à afficher, je gagne facile 25% de ressources CPU !
Sur une carte "chargée", avant je tournais à 25% en charge ( soit 25 * 4 équivaut à une charge maxi pour un 4 coeurs ), et avec ma méthode, je tombe à 16 17% ce qui est vraiment énorme ..
Et encore, je n'ai pas ajusté le nombre d'objet du background dans la routine d'affichage des mes éléments ... Donc encore de l'optimisation en prévision.
Le cout en mémoire est de 10 mo ce qui équivaut à l'image tampon qui est utilisé.
J'effectuerai d'autres tests sur le T100 de ma chérie.
Je ne garantis toujours pas une jouabilité sur un Netbook, mais en tout cas, je fais au mieux pour les petites configurations.

Sur ce dodo ...

[Vetea]

Salut,

Je viens de compiler mon nouveau code et voulu tester le jeu avec cette gestion de calque sur le NetBook de ma femme ( un Asustek T100 ).
Je passe de 10, 11 FPS à 20 FPS !
Ce qui est non négligeable !!

J'ai même réussi à jouer sans trop de problème même si la vitesse du jeu reste plus lente bien sûr, mais il y a vraiment du mieux !



Vous devriez avoir de meilleurs sensations de jeu avec vos PC de bureau normalement.
Enfin, sur un I3 +, cela n'aura aucun impact vu la puissance brute de ces CPU, mais sur un vieux Double Coeur à 2Ghz cela devrait beaucoup mieux tourner !

Je réalise d'autres tests et modification et je vous diffuserai une Mise à jour Express du client en 4.4B !

A bientôt !

[Cirrus Minor]

Performances doublées, en effet, c'est pas mal du tout !
Je n'avais pas de problème de lenteur, sur ma machine, mais il est évident qu'il y en qui seront ravis !

[Vetea]

Performances doublées, en effet, c'est pas mal du tout !
Je n'avais pas de problème de lenteur, sur ma machine, mais il est évident qu'il y en qui seront ravis !

Merci Cirrus,
Mais ce qui m'importait, c'est le problème qu'avait noté LittleWhite concernant la différence de vitesse qu'il y avait selon le type de carte. Cela dépendait du nombre d'élément surtout concernant tout ce qui est objet de sol et de décor.
J'espère en tout cas que cela restera un mauvais souvenir !
A propos, quel est le type de ton CPU Cirrus ?
Merci !

EDIT :
J'en ai profité pour donner un petit coup de pouce à tous les réfractaires des terrains minés !
En effet, les zones minées seront plus "visibles" qu'avant ... De plus, il se peut qu'une ou plusieurs mines soient visibles.
Voilà !

[jean_kevin_musclor]

Salut Veta et bravo pour l'avancement de ton boulot !!

Je viens ramener ma science 5 minutes en tant que nostalgique des vieux trucs:

Pour rappel, cette technique était très utilisé à l'époque des consoles 8 & 16 bits et aussi les vieux micros ... Gérer une simple image en plan était bien plus pratique qu'afficher tous les objets de la même scène !

C'est faux pour les consoles, y'avait pas assez de ram pour stocker une image aussi grande. C'était du rendu hardware, la puce graphique était capable de tracer des milliers de tuiles de façon bien séparée (on pouvait d'ailleurs les animer individuellement ou par sous-blocks selon les machines) et sans solliciter la moindre ressource au processeur de calcul qui était beaucoup trop lent pour tripoter plus de trois pixels de l'ecran (en témoigne le portage foireux d'another world sur console qui ramait comme pas permis)

Pour les vieux micros c'était possible, mais pas forcément utilisé des masses, y'avait pas non plus forcément assez de ram pour pré-dessiner la totalité de la map, et à mon souvenir dans les vieux jeux dos les tuiles étaient animées comme sur les consoles. Pour accélérer le tracé la technique employée consistait surtout à porter toutes les routines de tracé en assembleur. (et ça n'a pas beaucoup changé depuis, ensuite les machines sont passées à l'assembleur hardware, et aujourd'hui au glsl/hlsl)

La technique que tu utilises en revanche est très connue des utilisateurs de langages lents (basic, c#, javascript, etc) je m'en suis servi d'ailleurs quand je travaillais avec les langages lents... et c'est pour ça que les langages lents m'ont gonflé parce qu'au final ça finit par te compliquer la vie à chercher des t'as d'optimisations tordues pour compenser la lenteur du langage.

Ca peut étonner mais le tilemapping c'est le genre d'algo où plus le langage est bas-niveau et plus c'est facile à programmer. En c++ l'algo m'a pris environ trente lignes, et en glsl... seulement 5 lignes (bon dans le glsl j'ai pas fait l'animation de palette donc ça prendrait ptêt 7 lignes en allant jusqu'au bout du rendu retro)

Et je le prouve:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
		// REFRESH THE LOCAL CELL ROW IF NEEDED ----------------------------
 
		bool refreshCell = y == yStart ||(  ( ( ( y+sY ) >> 3 ) & 63 ) != currentRow  )||( ( ( sX >> 3 ) & 63 ) != currentColon );
		if (  refreshCell  ) {
 
			currentRow = ( ( y+sY ) >> 3 ) & 63 ;
			currentColon = ( sX >> 3 ) & 63 ;
 
			unsigned const char * tileIndexMap = s_tileIndexMap , * tilePaletteOffsetMap = s_tilePaletteOffsetMap;
			unsigned char * localRowPalOffset = s_localRowPalOffset;
			unsigned char ** localRowTileAdress = s_localRowTileAdress , ** pVram = s_pVram;
			unsigned char indexCell = 0, indexTile = 0, palOffset = 0 ;
			long mapCell=0, row=currentRow, col=currentColon;
 
			// RESOLVE ADRESSES AND PALETTE OFFSETS FOR ALL TILES OF THE ROW
 
			for ( indexCell = 0; indexCell < S_SCRW / 8 + 2; indexCell ++ ) {
				mapCell = ( ( indexCell + col ) & 63 ) + ( row << 6 ) ;
				indexTile = tileIndexMap[ ( indexCell+(sX>>3) & 63 ) + ( row << 6 ) ];
				localRowTileAdress[ indexCell ] = pVram[ indexTile >> 6 ] + ( ( indexTile & 63 ) << 3 ) ;
				localRowPalOffset[ indexCell ] = tilePaletteOffsetMap[ mapCell ] ;
			}
 
		}
 
		// copy backgrounds tiles
 
		if ( true ) {
 
			long step = 0 , numSteps = S_SCRW / 8 + 1 , localY = ( y+sY ) & 7 ; // steps of copy
			unsigned char pixRow = 0, palOff = 0; // the compressed data on one row
			unsigned char * writeHere = s_scanline - 1 + 8 - ( sX & 7 ) , * writeStop = writeHere, * localRowPal = s_localRowPalOffset;
			unsigned char ** localRow = s_localRowTileAdress;
 
			// uncompress each tile row - OPTIMIZE MAXIMUM HERE -----------------------
 
			for ( step = 0; step < numSteps; step++ ) {				
 
				pixRow = localRow[ step ][ localY ] ; // read pix row in vram
				palOff = localRowPal[ step ]; // read palette ofsset
 
				// uncompress 1 bit pixels to 8 bit pixels
 
				for ( writeStop=writeHere+8; writeHere<writeStop; pixRow >>= 1 ) {
					*(++writeHere) = ( 1 & pixRow ) + palOff;
				}
 
			}
 
		}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
        vec2 offset = floor(vec2( texture2D( tilemap, vUV ) )*256.0)*0.0625;       
        float activeSheet = floor( offset.y / 0.25 );
        float subSheet = mod ( floor( subSheetsOffsets / pow(8.0,floor(offset.y/0.25)) ) , 8.0 );
        offset.y = mod(offset.y,0.25) + subSheet * 0.25;              
        gl_FragColor = texture2D( sampler, mod(vUV*4.0,0.0625) + offset );

[illight]

Tu commences à penser à ton portage sur Mégadrive c'est ça ?

[Vetea]

Oui y a un peu de ça Illight !!
Merci Jean pour ces précisions.
Quant a ton code, j'y capte rien en passant ...
Mais si tu le dis, je te crois volontiers.

[jean_kevin_musclor]

Vetea >

Si ça peut te rassurer moi non plus je ne comprends rien à mon code je ne me souviens plus du tout de comment j'ai fait les calculs... ça fait un moment que j'y ai pas touché, (à vrai dire ces temps-ci je ne fous plus rien du tout parce que coder des jeux amateur ça remplit pas le frigo)

Sinon, j'ai testé ton jeu, j'aime bien les voitures les bateaux il commence à y'avoir de l'action

Je repère toujours plein de bugs de z-ordering on dirait bien que tu ne t'es pas basé sur le "pied" des objets comme j'avais expliqué... tant pis.

De toutes façons pour le portage megadrive tu vas devoir te passer de cet algorithme... d'une part car la megadrive ne pourra pas afficher assez de sprites donc tu vas devoir stocker tous les objets statiques dans les tilemaps, et d'autre part car le processeur de calcul de ce genre de consoles est beaucoup trop lent pour supporter ce type d'algorithme... le process calcul de ces consoles servait uniquement au game-design (faire bouger les objets en gros) tous les algo d'affichage étaient gérés automatiquement par le process graphique.

Je vois éventuellement une piste, peut-être complètement foireuse mais bon je sais pas je réfléchis... d'abord stocker toutes les images des objets statiques sur le calque de tuiles de premier-plan. Ensuite il faut un algo inteligent qui permet de savoir si un sprite est tracé devant ou derrière ce calque. Par exemple, faire une grille qui stocke toutes les valeurs "z", z qui dépend à la fois de la position y et de la hauteur de l'objet avec la formule iso2d de type z+y, ensuite même calcul pour les sprites, et si le z est supérieur ou inférieur à celui des cases qui se trouvent derrière, on sait si le sprite doit être tracé devant ou derrière... pas d'autre idée pour l'instant.

[Vetea]

Merci Jean d'avoir testé cette dernière mouture riche en action et qui je l'espère, te rappelle ces bon vieux jeux rétros.

La version MD, j'y pense pas encore ... Elle murit dans ma tête, mais je n'aime pas m'eparpiller et je préfère me centraliser a la version du moment, cela me permet de fournir un travail sérieux et surtout pas bâclé.
Il faut aussi que je me degotte une MD ! Ma femme compte lnen offrir une pour mes 43 ans ... Bientôt quoi ...
J'avais zieuté quelques OPcodes du 68000 et des tutos AsM très bien foutus sur la MD.
Va falloir gérer des blocs en pagaille mais l'idée de dev. sur ce genre de machine m'excite beaucoup et un projet de ce type sera une première sur les fabuleux forum de DVP !!

Amusés toi bien et annonces tes records.
Ce matin j'ai dépassé les 200 000 points et arrivé au stage 16 !!
Va falloir que je créer des map pour bientôt !!

[bombseb]

C'est du 68000 sur la Megadrive ?
En ce moment je bidouille un peu sur Amiga (68000)... c'est vraiment sympas le 68000

[Cirrus Minor]

A propos, quel est le type de ton CPU Cirrus ?
Merci !

J'ai un Core i3 3220 2 coeurs, 3,30 GHz.

[Vetea]

Merci Cirrus !
Avec un tel CPU, tu auras aucun soucis de vitesse c'est clair !!
Le seul piège quand on développe avec un CPU rapide, c'est celui de l'optimisation pour les joueurs qui ont des CPU faiblard ...

@Bombseb : Le CPU de la MD est bien un 68000 a 7.67 MHz épaules par une puce graphique spécialisée ainsi qu'un Z80 8 bits qui lui gère les sons.
Soit 2 types d'assembleur sur une même console .. Ahahah !

Pour ce qui est de la version 4.4B, je termine le debuggage, rajoute quelques stages en plus, et vous l'aurez en ligne très bientôt !

J'ai aussi commencé a dessiner mes Boss sur papier .. Et oui, y aura en plus des tanks, des Boss bien balourd, des mini Boss, des objets spéciaux droppés par ces unités, et encore plus de stages !!
Un feu d'artifice pour conclure cette aventure !

A bientôt.

[Vetea]

Bonjour à tous,

Je continue à peaufiner la version 4.4B !
La gestion des calques est pleinement fonctionnelle !! Cela apporte un plus au niveau de l'optimisation et de la stabilité de la vitesse pour les CPU lents.

Je viens aussi de mettre un terme à une nouveauté que vous découvrirez dans les cartes : l'ajout de mobiliers pour les zones "Indoor" !

Voici une petite capture :


Il s'agit d'une capture d'une nouvelle carte en passant ...

Sur ce point, j'ai ajouté 2 cartes exclusives ce qui porte le nombre total de stage à 22 !
De plus, j'ai résolu un petit bug sur le Bazooka qu'avait révélé LittleWhite, j'avais un "double tir" au tout premier tir de ce dernier.
Sans oublier la nouvelle visibilité des mines ... Mais ça, je vous laisserai le découvrir !

A bientôt !