Header de Genlib - Page 1

1

Le 09/11/2009 à 11:37

Les versions des headers de genlib dans PreOS et dans genlib ne sont pas les mêmes. Etonnamment, PreOS semblerait avoir un header plus récent ? oO
"1.1." pour PreOS
"1.0.1" pour Genlib

Que prendre ?

ps : c'est ton mail en caramail dans la doc, c'est normal ?

2

Le 09/11/2009 à 13:55

Bon, pendant que j'y suis (parce que je me suis pas penché sur les headers pour rien

) j'ai un problème ici, avec ce test-case qui me semble minimaliste :

test

_main:
	jsr	genlib::init
	genlib::PUSH_DSCREEN	d0
	jsr	genlib::set_dscreen_int
	jsr	genlib::set_dscreen_function


	lea.l	Map(pc),a3
	lea.l	Tiles(pc),a4
	suba.l	a5,a5
	moveq.l	#16,d3
	jsr	genlib::init_plane
	move.l	a0,PlanePtr


	jsr	genlib::put_plane
	jsr	genlib::wait_a_key


	movea.l	PlanePtr(pc),a0
	jsr	genlib::free_plane
	genlib::POP_DSCREEN
	jsr	genlib::quit
	rts


PlanePtr:	dc.l	0

Map:	dc.b	1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
	dc.b	1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,1
	dc.b	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,1
	dc.b	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,1
	dc.b	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

Tiles:	dc.w	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0		; spr1
	dc.w	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

	dc.w	1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1		; spr2
	dc.w	1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

- J'initialise genlib
- un dscreen
- un plane
- je veux l'afficher... non, rien :/

Vu la map binaire et les sprites (carrés blanc ou noir), je m'attendais à voir une sorte de damier ou assimilé, mais non, je vois un bout de RAM. Où me plante-je ?[nosmile]

3

Le 09/11/2009 à 19:19

Folco (./1) :
Que prendre ?

Preos. Moi j'ai 1.1 dans mon git de genlib

Folco (./1) :
ps : c'est ton mail en caramail dans la doc, c'est normal ?

Outdated.

Sinon il manque genlib::update_vscreen dans ton exemple.

4

Le 09/11/2009 à 19:39

PpHd (./3) :
Preos. Moi j'ai 1.1 dans mon git de genlib

Ya une release au chaud alors ? J'ai ça dans la dernière archive :
__GENLIB__INCLUDE__FILE__ EQU '1.01'
(ya même un genlib.h~ qui traine, celui de la 1.0)

PpHd (./3) :
Sinon il manque genlib::update_vscreen dans ton exemple.

Merci. J'y reviendrai, je ne comprends pas bien la marche à suivre pour rafraichir au mieux l'écran et le vscreen, quand c'est nécessaire ou non. Disons que le sens de certaines fonctions m'échappe.

PpHd (./3) :
Outdated.

J'espère alors que c'est au moins à jour dans ton git.

edit

Ok, j'ai un résultat, mais avec ça :

Données

Map:	dc.b	1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
	dc.b	1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,1
	dc.b	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,1
	dc.b	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,0,0,0,0,0,0,0,1,0,0,0,0,1,0,1
	dc.b	1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,0,0,0,0,1,0,0,0,0,1,0,0,0,0,1
	dc.b	1,0,0,0,0,1,0,1,0,0,1,1,1,0,0,1
	dc.b	1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1

Tiles:	dc.w	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0		; spr1
	dc.w	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

	dc.w	$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF		; spr2
	dc.w	$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF,$FFFF

Je voudrais avoir mon damier, mais j'ai un écran noir. Un sprite 16*16 fait pourtant 64 octets, je déconne encore ?

5

Le 09/11/2009 à 20:45

moveq.l #4,d3

6

Le 09/11/2009 à 20:50

Ah, merci, oublié de réessayer.

7

Le 10/11/2009 à 13:15

Doc :
d3.w = sizeX = The number of columns (real or its log2).

Pourquoi "real" alors ? Dans quel cas ? Après un change update ?

Edit -> Réponse : Oui

bon, une question plus sensée :
Quel est l'intérêt de key_matrix ? Son pointeur est renvoyé par read_joypad, quel intérêt ? On a tout ce qu'il faut dans d0.l, non ? (a0) == d0 ?

8

Le 10/11/2009 à 17:49

Autre chose, à propos du Virtual Screen, là j'ai un peu plus de mal.

Si j'ai bien compris, un VScreen fait 2 octets de plus de chaque côté de l'écran que le LCD.
Donc tant que je scrolle pas plus de +-16 pixels dans chaque direction, je ne suis pas obligé de le rafraichir, c'est ça ?
Et si je dépasse cet offset en scrollant, il faut que je rafraichisse le VScreen, c'est toujours ça ?

Donc à chaque tour de ma boucle infinie, je fais un put_plane, et s'il je l'ai fait trop bouger, je dois auparavant faire un genlib::update_vscreen_x ?
Donc put_plane utilise le VScreen uniquement, jamais les données réelles de la map ? (tableau d'index + table de tiles)

9

Le 10/11/2009 à 19:25

Folco (./7) :
Quel est l'intérêt de key_matrix ? Son pointeur est renvoyé par read_joypad, quel intérêt ? On a tout ce qu'il faut dans d0.l, non ? (a0) == d0 ?

Ca coute pas cher de le retourner. Et (a0) != d0

Folco (./8) :
Donc tant que je scrolle pas plus de +-16 pixels dans chaque direction, je ne suis pas obligé de le rafraichir, c'est ça ? Et si je dépasse cet offset en scrollant, il faut que je rafraichisse le VScreen, c'est toujours ça ?

Oui, mais ce n'est mis à jour que si c'est nécessaire. C'est géré tout seul.

Folco (./8) :
Donc à chaque tour de ma boucle infinie, je fais un put_plane, et s'il je l'ai fait trop bouger, je dois auparavant faire un genlib::update_vscreen_x ? Donc put_plane utilise le VScreen uniquement, jamais les données réelles de la map ? (tableau d'index + table de tiles)

Appelle tout le temps VScreen. Il ne fera la mise à jour que si nécessaire.
Oui

10

Le 10/11/2009 à 19:44

PpHd (./9) :
Oui, mais ce n'est mis à jour que si c'est nécessaire. C'est géré tout seul.

Yay ! \o/ Ca me faisait chier de le faire !
Ca doit être à ça que servent :

unsigned short xs_old; // Internally used
unsigned short ys_old; // Internally used

Donc moi je modifie juste xs et ys, puis s'il faut mettre à jour le vscreen, il fait tout tout seul ? Cay la fête ça.

PpHd (./9) :
Appelle tout le temps VScreen. Il ne fera la mise à jour que si nécessaire.

Super, donc en effet, pas la peine de s'embêter à faire des calculs pour savoir si on doit demander un rafraichissement.

Très bien pensé tout ça, c'est chouette ! Feel the power !!!

PS
1. C'est vrai que si j'avais dû gérer le rafraichissement, la taille et la disposition d'un vscreen aurait été documentée quelque part.
2. Ca fait bizare d'écrire directement dans une Plane pour modifier sa position, sans aucune fonction d'accès. Mais c'est optimal.

11

Le 11/11/2009 à 02:25

Quelle utilité ont les variables genlib::sprite_scr_x/y, étant donné qu'on file les coordonnées dans d0/d1 ? Ca permet de définir des offsets constants ?

Sinon ça poutre tout le reste

12

Le 11/11/2009 à 11:10

Si tu utilises copy_xyplane_xysprite, ca ne sert à rien.
(Ca sert à définir la base relative des sprites).

13

Le 11/11/2009 à 12:02

Ah. Merci.

Mais si j'utilise des coordonnées relatives pour mon perso, ça ne sert à rien alors ?
Je soustrait à ces coordonnées les offsets x et y de la map, et j'affiche le sprite. Peut pas faire mieux ?

14

Le 11/11/2009 à 12:34

C'est déjà intégré à genib. Pas besoin de le faire. Ca bouffera des cycles pour rien.

15

Le 11/11/2009 à 13:18

Ok, alors je suppose que ça vaut le coup quand on a plus d'un sprite à afficher.

Sinon, je m'étonnais que tu postes à cette heure-ci, j'avais pas capté qu'on était le 11/11

16

Le 23/11/2009 à 17:46

La doc dit ça :
void gl_put_masked_big_sprite (short x, short y, const MBGS *mbgs)
Ca, c'est dans le header de genlib :
void gl_put_masked_big_sprite ( short x D0, short y D1, MBGS *bgs A0 );
Manque pas un const ?

17

Le 23/11/2009 à 18:53

Si, si.

18

Le 20/11/2010 à 12:37

Euh, pour ne pas recréer un topic pour une simple question je poste ici.

le romcall idle() est utilisable avec genlib ? La doc de tigcc dit que c'est pas possible d'utiliser idle avec les grays, mais c'est utilisé dans gl_main par exemple (fonction ready()). C'est bien prévu pour ?

19

Le 20/11/2010 à 13:14

Ce n'est pas utilisable avec toutes les routines de gray, sauf celle de genlib qui sont compatible.

20

Le 20/11/2010 à 13:47

Bien ouej et merci