Pen^2 :
je pense que c possible avec grahx.
http://alineasofts.free.fr/graphx/documentation.htm
sinon, utilise Genlig, Xlib, ou Extgraph
pas XLib
Pen^2 :
je pense que c possible avec grahx.
http://alineasofts.free.fr/graphx/documentation.htm
sinon, utilise Genlig, Xlib, ou Extgraph
Sasume
: Tu ne peux pas, la fonction que tu utilises copie par octets.
orage
:Sasume :
Oui, c'est possible avec graphx. Utilise les fonctions de sprites clippées. Si possible, découpe ta map de 320x200 en carrés de 16x16 (ou 32x32), et n'affiche que ceux qui ont une partie visible.
Si je remplie le buffer d'affichage "map" entierement,
n'aurais-je plus a y toucher dans la boucle princlipale ? Si oui, pour copier le buffer "map" au buffer principal, j'utilise la fonction "GX_Copy(map)", avant d'utiliser "GX_DisplayWorkBuffer()". Mais comment faire pour décaller l'image de "map" (x--||x++||...) ?
orage :
ok merci...
En fait, c'est moi ou la fonction GX_PutSprite08_..() marche mal avec graphX ? : On ne voit qu'une partie du sprite 8 bits...
Thibaut B
Tu peux poster le *.89z et la partie du code où tu utilises GX_PutSprite08 ? Merci
// C Source File
// Created 31/08/2003; 15:25:08
#define USE_TI89
#define OPTIMIZE_ROM_CALLS
#include "graphx.h"
// Main Function
void _main(void)
{
short trois_8bits_data[] = {0x00,0x00,0x18,0x18,0x24,0x24,0x04,0x04,0x08,0x08,0x04,0x04,0x24,0x24,0x18,0x18};
GX_sprite_08_nomask *trois_8bits = (GX_sprite_08_nomask *)trois_8bits_data;
GX_HANDLE ecran;
if(!GX_PowerOn(TRUE))
return;
ecran = GX_CreateBuffer();
if(ecran == H_NULL)
{
GX_PowerOff(TRUE);
return;
}
GX_SetWorkBuffer(ecran);
GX_PutSprite08_ER(trois_8bits, (LCD_WIDTH-8)/2, (LCD_HEIGHT-8)/2);//(Sprite = '3')
GX_DisplayWorkBuffer();
while(!GX_SHIFTpressed());
GX_PowerOff(TRUE);
return;
}
Thibaut B
Je te conseille d'abandonner l'idée du buffer géant [...] leurs coordonnées.
Je m'ennuie, donc voici ton sprite : ##
# #
#
Il est correctement convertiorage
: si je tente d'afficher un sprite qui fait une autre dimention, ça marche parfaitement.
Brunni> La technique que tu utilises n'est pas si mauvaise. Avec des ScrollRight (plutôt ScrollLeft), ça peut marcher aussi, mais ce n'est pas pratique si ton arrière-plan est animé ou si tu as plusieurs niveaux de scrolling.Peut-être mais ça dépasse forcément à droite. N'y a-t-il vraiment pas plus propre que de passer un gros rectangle blanc sur la partie visible que sur 92+ (ou ne pas copier cette zone vers la mémoire vidéo)? Sans compter que sans clipping, ça risque bien de planter (scrolling à gauche). Tout le monde utilise des tampons de deux motifs de plus que l'écran horizontalement et verticalement?
Sinon, la technique utilisée par genlib (cf doc de genlib) est assez puissante.Connais pas. Vais voir...
BrunniJe ne comprends rien de ce que tu mets
:Brunni> La technique que tu utilises n'est pas si mauvaise. Avec des ScrollRight (plutôt ScrollLeft), ça peut marcher aussi, mais ce n'est pas pratique si ton arrière-plan est animé ou si tu as plusieurs niveaux de scrolling.Peut-être mais ça dépasse forcément à droite. N'y a-t-il vraiment pas plus propre que de passer un gros rectangle blanc sur la partie visible que sur 92+ (ou ne pas copier cette zone vers la mémoire vidéo)? Sans compter que sans clipping, ça risque bien de planter (scrolling à gauche). Tout le monde utilise des tampons de deux motifs de plus que l'écran horizontalement et verticalement?
Je ne comprends rien de ce que tu metsTu dessine ta map (de 0 à 160/TAILLE_MOTIF inclus à droite) avec un décalage (entre 0 et TAILLE_MOTIF non-inclus) sur la gauche. Mais forcément la colonne qui sera dessinée tout à droite finira entre 160 et 160+TAILLE_MOTIF non-inclus, donc forcément ça dépasse à droite. Et ça ce n'est pas gênant sur une 89 puisqu'on ne le voit pas, mais sur 92+/V200, je n'ose pas imaginer...
mais pourquoi ne pas faire un buffer dans lequel on affiche 1 sprite de plus dans chaqye direction. Comme ca, ca permettrait de faire un scroll au pixel pret non ?Effectivement, mais ça ne fonctionne pas pour les décors animés c'est tout.