Pages: [1] 2   Bas de page
Imprimer
Auteur Fil de discussion: [Demo] Palette et HBL  (Lu 5339 fois)
0 Membres et 1 Invité sur ce fil de discussion.
Cotsz Hors ligne
Jr. Member
**
Messages: 65


Voir le profil WWW
« 28 Juin 2008, 20:16:17 »

Comme nous avons déjà parlé de HBL et de palettes,
j'ai trouvé judicieux de faire une petite "Demo du samedi" sur le principe des rasters.

Les rasters sont apparus rapidement sur les premiers ordinateurs personnels 8bits (par ex: Décruncher des Atari Xl/XE).
Le fait de modifier la palette en HBL permettant de dépasser le nombre maximum de couleurs affichables à l'écran.
Au millieux des années 80 on vit donc apparaître de plus en plus de jeux découpés horizontalement, avec par exemple un tableau de bord dans une palette pour 1/3 vertical de l'écran et un playfield dans une autre palette pour les 2/3 tiers restant. (éventuellement scrollant)
Ces proportions pouvant même être inversées (The last V8, Red Max ou les 1ers jeux de type flight simulator de l'époque).

Mais le mouvement raster prit toute son ampleur sur la fin des années 80, la puissance des processeurs 16/32bits, permettant le calcul précis de la position du balayage écran (raster), on vit apparaître les premiers plasmas.

Il est à noter que l'interruption HBL permit aussi l'Overscan :
    En modifiant la valeur de base de la mémoire vidéo pendant la HBL il devint possible de dépasser la limite de la résolution prévue à la base pour le hardware.

Au début des années 90, les rasters, plasmas et autres overscans devinrent le passage obligé de toute démo underground respectable.
Ce qui fût sévèrement décrié par la très moyenne, mais notable : "Démo des fêlés" (Amiga).
(Je ne me suis toujours pas remis de la pub pour la souris à ventouses Atari)

Ma petite démo est assez simple et elle se base sur les précédentes démos.
Elle se contente de faire rouler un raster barre, de haut en bas de l'écran.
Elle fonctionne légèrement mieux sous émulateur que sur DS.

http://sentinel.minastirith.free.fr/download/RasterDS.rar

Tout l'art du code en HBL étant normalement de compter le nombre de cycles CPU exact afin d'obtenir le temps réel que votre code prend pour être exécuté par le processeur. Afin de savoir où en est le balayage (début, fin, milieu de la ligne...).
Pour faire simple : lors de votre interruption, le "PA_GetVcount()" vous permet d'obtenir le "Y", mais seule la durée de votre code vous donne le "X".

Il faut bien comprendre que la seule vraie limite de l'interruption HBL est le temps.
En effet, à chaque HBL votre code doit avoir fait son job avant la ligne suivante.
Et à 60 Hz et 192 lignes, vous avez 1/192ème de 1/60ème de seconde... c'est peu.

Bien sûr, il faudrait coder directement en assembleur pour pouvoir obtenir le temps réel de notre code.
Mais le principe du raster, ou la simple possibilité de modifié la HBL, nous ouvre de vastes horizons sur DS.

Bon, sinon le code parle de lui-même... Il vous suffit normalement de remplacer le main.c de la précédente démo sur les palettes, par le mien.
Code
(c):
 
// Includes
#include <PA9.h> // Include for PA_Lib
 
// Converted using PAGfx
#include "gfx/all_gfx.c"
#include "gfx/all_gfx.h"
 
#define RED 31
#define GREEN (31<<5)
#define BLUE (31<<10)
 
u16 vblpal[256]; // Palette VBL
u16 hblpal[256]; // Palette HBL
s16 start=0; // 1re ligne d'affichage du raster
bool down=true; // Flag pour savoir si le raster monte ou descend.
 
// Couleurs du raster
u16 Rcol[6]={26,31,24,20,18,0};
 
void CopyPal(u16 *SrcPal, u16 *DstPal){
  u16 i; for(i=0; i<256; i++){ DstPal[i] = SrcPal[i];}  
}
 
void HBL_function(void){
  s16 vcount = PA_GetVcount();
 
  // On commence par copier la palette préparée lors de la HBL précédente.
  // pour être sûr d'avoir fini avant le départ du balayage.
  PA_LoadBgPal(1, 3, (void*)hblpal);
 
  if(vcount > 192) vcount = 0; // Loop
 
  // Affichage du raster, par modification de la palette.
  switch(vcount-start)
  {
case 1: { hblpal[1]=Rcol[0]; break;}
case 2: { hblpal[1]=Rcol[1]; break;}
case 3: { hblpal[1]=Rcol[2]; break;}
case 4: { hblpal[1]=Rcol[3]; break;}
case 5: { hblpal[1]=Rcol[4]; break;}
case 6: { hblpal[1]=vblpal[1]; break;}        
  }
}  
 
// Function: main()
int main(int argc, char ** argv)
{
 
PA_Init();    // Initialisation de PA_Lib
PA_InitVBL(); // Initialisation de la VBL standard
 
// Load Backgrounds with their palettes !
PA_EasyBgLoad(1, 3, test); // Background name, used by PAGfx...
 
PA_InitText(1, 0);  // Initialisation du système de texte
PA_OutputText(1, 5, 19, "A la mode des 90's...");
 
// Duplication de la palette du gif dans nos palettes de travail
CopyPal((u16*)test_Pal, (void*)hblpal);
CopyPal((u16*)test_Pal, (void*)vblpal);
 
// Init palette
PA_LoadBgPal(1, 3, (void*)vblpal);
 
// Init HBL
irqSet(IRQ_HBLANK, HBL_function);  
irqEnable(IRQ_HBLANK);
 
 
// Infinite loop to keep the program running
 
u16 loop=0;
while (1)
{
 
  // Le pad change la couleur du fond
  if(Pad.Newpress.Up){
  vblpal[1]=RED;
  }  
  if(Pad.Newpress.Left){
     vblpal[1]=BLUE;
  }  
  if(Pad.Newpress.Right){
     vblpal[1]=GREEN;
  }  
  if(Pad.Newpress.Down){
     vblpal[1]=0;
  }  
 
  // mouvement du raster
  // avec rebond de haut en bas
  // 191-6 => hauteur de l'ecrant moin celle du raster
  if(down) {
     start++;
     if(start>(191-6)) down=false;
  } else {
     start--;
     if(start<1) down=true;
  }
 
  // Rotation du raster
  // avec une petite temporisation
  // pour qu'il ne tourne pas trop vite
  if(++loop>4)
  {
     loop=0;
     if(down) {
Rcol[5]=Rcol[4];
Rcol[4]=Rcol[3];  
Rcol[3]=Rcol[2];
Rcol[2]=Rcol[1];
Rcol[1]=Rcol[0];
Rcol[0]=Rcol[5];
     } else {
Rcol[5]=Rcol[0];
Rcol[0]=Rcol[1];
Rcol[1]=Rcol[2];
Rcol[2]=Rcol[3];
Rcol[3]=Rcol[4];
Rcol[4]=Rcol[5];
     }
  }
 
  PA_WaitForVBL();
  PA_LoadBgPal(1, 3, (void*)vblpal);
}
 
return 0;
 
} // End of main()
 
« Dernière édition: 23 Mars 2009, 16:47:35 par Cotsz » Journalisée

" La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi ! "
Albert Einstein (mon comique préféré)
Doud Hors ligne
Global Moderator
*****
Messages: 246


Voir le profil
Chasseur de bug

« Réponse #1 : 28 Juin 2008, 20:18:21 »

Euh ?  Huh?

Ok pas de soucis, mais ça m'a étonné le lien sans explication  Tongue

Bonne rédaction Wink
« Dernière édition: 28 Juin 2008, 20:37:19 par Doud » Journalisée

Minishlink Hors ligne
Mega Member
***
Messages: 1359


Voir le profil WWW
Quand on veut, on peut !

« Réponse #2 : 28 Juin 2008, 21:00:53 »

Manière un peu exotique de répondre à un sujet, mais bon. whistle Langue
Journalisée

Arialia Hors ligne
Elite Member
**
Messages: 831


Voir le profil
« Réponse #3 : 28 Juin 2008, 21:14:56 »

c'est donc cela les raster? Merci pour l'explication et le code  Azn
Journalisée

Mon blog de dev   - -  Mon tutoriel sur la libfat -- DSPhoto
Un bon programmeur est fainéant : il déteste refaire la même chose, il fait donc des fonctions Wink

Mais qui m'a mis des nounours roses ? Le rose c'est pour les homo et les gamines , beurk, mais ça va bien aux fleurs Smiley
Et aux jeux de Genevois Wink
Copper Hors ligne
Mega Member
***
Messages: 1232


Voir le profil
« Réponse #4 : 28 Juin 2008, 21:49:38 »

Oui c'est pas mal Smiley

Sur DS on peut aussi le faire avec le DMA qui peut copier à chaque HBL... (vu dans la démo DScaler postée par Alekmaul)

J'ai également fait un essai pour pouvoir changer la couleur en milieu de ligne (ce qui m'arrangerait bien pour mon space invader monochrome) ... Apparement c'est possible avec un TIMER bien paramètré, lancé à chaque HBL et qui déclenche une interruption...

Mais il y a 2 problèmes :
1) ca ne marche pas sur emulateur (du moins pas avec no$gba pas essayé les autres) un peu chiant pour la mise au point donc
2) Il semble que le DMA (utilisé pour autre chose dans mon cas) perturbe les interruptions et donc le TIMER qui ne se déclenche pas au bon endroit tout le temps (c'est peut-être aussi quand le processeur est trop occupé)
« Dernière édition: 29 Juin 2008, 13:50:27 par Copper » Journalisée
Cotsz Hors ligne
Jr. Member
**
Messages: 65


Voir le profil WWW
« Réponse #5 : 28 Juin 2008, 22:29:14 »

Le DMA prend le bus mémoire pour lui tout seul et blok les cpu. D'après ce que j'ai lu.
Il doit donc avoir fini de copier avant la fin de la ligne (dans mon cas) ce qui est jouable.
Et pour toi avant la position "X" de la ligne suivant la découpe horizontale que tu veux appliquer.
Faudrait arriver à savoir combien de temps prend exactement le dma pour copier 256 words.
Ou 128 long... après tous on est sur DS.

Moi je voudrai juste modifier un seul registre de la palette, et donc plutôt que de perdre du temps avec la PALib
et le DMA (PA_LoadBgPal utilise le DMA) je préférais juste modifier le bon word de la palette placer en mémoire vidéo (euh la V_RAM... sur DS)
Mais même pour 256 words vaut sûrement mieux éviter le DMA pour plus de stabilité...

enfin faut voir, je connais que très peu la DS...

Je l'ai acheté la semaine dernière, faut être indulgents aussi un peu Wink

Mais en déplacent le PA_LoadBgPal(1, 3, (void*)hblpal); à la fin de la HBL,
Par exemple, sur DS (ça ne se voit pas sous no$gba) tu perds facilement 8pixels sur la première ligne.
Dans ma demo, l'idée est de faire tout les calculs pour la HBL suivant.

copper => copper_list ?
« Dernière édition: 29 Juin 2008, 17:04:39 par Cotsz » Journalisée

" La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi ! "
Albert Einstein (mon comique préféré)
Cotsz Hors ligne
Jr. Member
**
Messages: 65


Voir le profil WWW
« Réponse #6 : 28 Juin 2008, 22:42:38 »

Manière un peu exotique de répondre à un sujet, mais bon. whistle Langue

La 2D, la 3D et le code, sont tous 3 des arts.
je mani un peu les 3.
Et les artistes sont exotiques  whistle

(tout comme mon orthographe aussi d'ailleur, oui, merci... d'ou ma maniére de faire mes post...)
« Dernière édition: 28 Juin 2008, 22:47:28 par Cotsz » Journalisée

" La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi ! "
Albert Einstein (mon comique préféré)
birslip Hors ligne
Administrateur
*****
Messages: 513


Voir le profil WWW
« Réponse #7 : 29 Juin 2008, 02:17:04 »

Ca s'appelle comme ça! En fait, c'est exactement ce que je fais pour le menu de MagicTouch. Ca permet d'économiser de la mémoire, tout en laissant la place à des effets sympas, le HBL nous sauve la vie!  Azn
Journalisée

tylerD Hors ligne
Newbie
*
Messages: 3


Voir le profil
« Réponse #8 : 29 Juin 2008, 10:27:51 »

Bonjour !
Pour mon premier message sur le forum je voulais te remercier de cette super démo  Cheesy
J'espere que tu en feras d'autres!
Journalisée
Mony Hors ligne
Hero Member
*****
Messages: 548


Voir le profil WWW
zOMG !!!1

« Réponse #9 : 29 Juin 2008, 10:36:39 »

Sympa cette démo ! Même si ça fait mal aux yeux Langue

Journalisée

Membre du club des joyeux guitaristes pas aidés et codeurs avec les pieds de Dev-Fr et pas du club des pieds pas guitaristes aidés de joyeux codeurs Dev-fr...

Michoko Hors ligne
Full Member
***
Messages: 224


Voir le profil
« Réponse #10 : 29 Juin 2008, 13:45:45 »

Merci beaucoup pour ce tuto Cotsz, ça rappelle le bon vieux temps ! Smiley
Journalisée
Cotsz Hors ligne
Jr. Member
**
Messages: 65


Voir le profil WWW
« Réponse #11 : 29 Juin 2008, 16:20:29 »

Ca s'appelle comme ça! En fait, c'est exactement ce que je fais pour le menu de MagicTouch. Ca permet d'économiser de la mémoire, tout en laissant la place à des effets sympas, le HBL nous sauve la vie!  Azn

C'est bien fait parce que je n'ai pas vu ou !
Sympa comme tout ton petit jeu et très bonne idée, dommage que le mago ait un balai dans le c... Wink
Mais j'aime bien les méchants qui tombe accrochés à leurs ballons. laugh
« Dernière édition: 05 Juillet 2008, 01:14:44 par Cotsz » Journalisée

" La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi ! "
Albert Einstein (mon comique préféré)
Cotsz Hors ligne
Jr. Member
**
Messages: 65


Voir le profil WWW
« Réponse #12 : 29 Juin 2008, 16:22:15 »

Sympa cette démo ! Même si ça fait mal aux yeux Langue

Bonjour !
Pour mon premier message sur le forum je voulais te remercier de cette super démo  Cheesy
J'espere que tu en feras d'autres!

Merci beaucoup pour ce tuto Cotsz, ça rappelle le bon vieux temps ! Smiley

Merci  Cool
 
C'est fort possible que je fournisse d'autre petite chose à l'occasion, mais je promet rien.
Mais il est vrai aussi que niveau code je suis tombé ammoureux de la DS, y'à pas photo...
Donc oui, normalement...

En tout cas je bosses actuellement sur un petit jeu (action/réflection) que j'avais commencer il y a longtemps (1992 sur Amiga)
Le playfield maximal fait 64x64 dales/tiles/modules de 32x32pixels, soit 2048x2048 pixels, soit en gros 4Mo de memoire en mode 8bits.
On conçois aisément qu'il faille savoir utilisé quelque techniques de programations pour pouvoir afficher et scroller sur un terrain de jeu qui
ne peut pas être placer entierrement en mémoire. A l'occasion je ferrais peu etre quelque chose la dessus.
(mais je sais aussi que ça ce trouve dejas sur le net)

Avec 3 ça fait encore plus mal aux yeux Wink
(Mise à jours du 20/07/08) http://sentinel.minastirith.free.fr/download/Rasters2DS.nds
« Dernière édition: 20 Juillet 2008, 07:20:12 par Cotsz » Journalisée

" La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi ! "
Albert Einstein (mon comique préféré)
morukutsu Hors ligne
Sr. Member
****
Messages: 437


Voir le profil
Noctambule

« Réponse #13 : 29 Juin 2008, 20:04:11 »

Dans le cas ou tu as 64 tiles différentes de 32x32, quelque soit la taille de la map ça ne prendra que la place pour les 64 tiles. Je ne vois pas pourquoi ça irait jusqu'à 4mo de mémoire ?
Journalisée
Cotsz Hors ligne
Jr. Member
**
Messages: 65


Voir le profil WWW
« Réponse #14 : 30 Juin 2008, 12:24:49 »

Parce que la map doit être construite quelque part en memoire pour être affichée.
Et il y a bien plus de 64 tiles differentes le problème n'est pas là.
Mais si tu vois pas le probleme c surement que tu sais faire sur DS.
Mais il n'y avait pas de mod tile sur l'amiga comme sur la DS.
Fallait donc le faire soit même.

En fait cette adaptation que je fait est juste tres sentimentale. C'est juste pour le plaisir de réutilisé des graphs qui ont demandés
des heures de boulot et qui non jamais réelement servi a quelque chose.
Je ne m'occupe donc pas de savoir si j'utilise bien la bonne methode de programmation sur DS.
De toute maniere pour ma part je n'ai que survolé rapidement le mode tile de la DS, donc pour l'instant je fait comme sur amiga.
en mode 8bits boudle buffers. (y avait pas non plus de mode double buffer, fallait aussi le faire, grace à l'IRQ VBL...)
Le reste c'est mes routines et le DMA.

De toute maniere il me semble que PAGfx bosse a partir de tiles 8x8 et non 32x32...
Et gérer des assemblages de 4x4 tiles me parais bien lourd.
« Dernière édition: 30 Juin 2008, 13:06:27 par Cotsz » Journalisée

" La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi ! "
Albert Einstein (mon comique préféré)
Pages: [1] 2   Haut de page
Imprimer

Aller à: