Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Betas et WIPs » Hawk (107 réponse(s))

./REPRISE DU POST PRECEDENT (post n°57) Marquer comme non lu.

geogeo

Ecrit le: Mardi 16 août 2005 à 12:56

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Niveau compression, compressez un fichier MIDI de PolySnd de 5 Ko environ voir plus il passera facile dans les 200 octets voir moins.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°58 Marquer comme non lu.

Nul

Ecrit le: Mardi 16 août 2005 à 14:36

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Oui, encore faut-il trouver le fichier midi !

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°59 Marquer comme non lu.

Onur

Ecrit le: Mardi 16 août 2005 à 21:06

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

tu vires les infos que ne peut gerer la caltoche? (genre les variations de pitct, balance gauche/droite, etc..)

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°60 Marquer comme non lu.

Kevin Kofler

Ecrit le: Mardi 16 août 2005 à 22:33

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Si vous voulez une compression meilleure, vous avez toujours LZMA...

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°61 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mercredi 17 août 2005 à 09:48

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

... dont la routine de décompression fait une taille triple de celle de la version rapide de la routine de décompression PPG (au passage, lanceurs spécifiques suck à cause du gaspillage dès qu'il y en a plus d'un), mais est plus de 10 fois plus lente... Tant que cela n'aura pas été résolu, presque personne ne va l'utiliser.

Lionel Debroux - membre de TICT.

./Post n°62 Marquer comme non lu.

Dari

Ecrit le: Mercredi 17 août 2005 à 11:14

Membre privilégié

Messages: 968

Membre n°203

Inscrit le 18 avril 2004

TTStart powaaa !

"iPod, therefore, I am."

http://media.laquadrature.net/Quadrature_black-out_HADOPI_468x60px.gif

./Post n°63 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mercredi 17 août 2005 à 18:11

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Ou SuperStart, que Greg finira bien par updater. Pour le moment, SuperStart a toujours la routine "SuperStart" (384 words). La nouvelle (rapide) fait ~100 words de moins, tout en étant au moins deux fois plus rapide.

Lionel Debroux - membre de TICT.

./Post n°64 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 18 août 2005 à 21:58

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
... dont la routine de décompression fait une taille triple de celle de la version rapide de la routine de décompression PPG (au passage, lanceurs spécifiques suck à cause du gaspillage dès qu'il y en a plus d'un), mais est plus de 10 fois plus lente... Tant que cela n'aura pas été résolu, presque personne ne va l'utiliser.

Mais elle fait son boulot (compresser) nettement mieux que ttpack (jusqu'à une trentaine de % sur certains testcases).

./Post n°65 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 19 août 2005 à 09:11

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Je sais, j'utilise la compression LZMA pour mes propres fichiers PC, des PC qui sont beaucoup plus puissants que nos TI-68k.

Lionel Debroux - membre de TICT.

./Post n°66 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 19 août 2005 à 21:32

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Mais les TIs avec leur mémoire limitée ont vraiment besoin d'une bonne compression!

./Post n°67 Marquer comme non lu.

Lionel Debroux

Ecrit le: Samedi 20 août 2005 à 10:37

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Mais peu de gens sont disposés à attendre 10 ou 20 secondes pour qu'un programme qui se décompresse en moins d'une seconde avec une autre compression, fût-elle moins puissante.
N'avais tu pas vu la levée de boucliers que tu avais déclenchée sur le forum de TIGCC/TICT quand tu avais dit que pour toi, c'était bien bon, car la seule chose qui comptait pour toi, c'était le taux de compression, avant de reconnaître que 20 secondes pour Ice Hockey 68k, c'était quand même trop lent ?

Je mentionne systématiquement ce "petit" défaut de la compression LZMA quand tu ne le fais pas. Je n'ai même pas besoin de dire qu'elle était plus puissante que les autres, car tu l'as dit, et c'est son seul avantage (puisque même s'il faut finaliser la discussion avec Pasi Ojala, la licence n'en est plus un).

Au passage: il est un fait que la mémoire des TIs serait moins limitée si plus de gens faisaient des programmes incompatibles on-calc...

Lionel Debroux - membre de TICT.

./Post n°68 Marquer comme non lu.

geogeo

Ecrit le: Samedi 20 août 2005 à 13:32

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Au passage: il est un fait que la mémoire des TIs serait moins limitée si plus de gens faisaient des programmes incompatibles on-calc...

Relance de débat, dis-moi combien d'octets tu gagnes en virant la compatibilité on-calc dans GFA-Basic par exemple?
Même chose pour Nebulus?

Réponse des miettes genre 3 Ko voir 5 Ko ce qui n'est rien!

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°69 Marquer comme non lu.

Lionel Debroux

Ecrit le: Samedi 20 août 2005 à 15:52

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Pour GFA-Basic: je ne connais pas le code de la partie GFA-BASIC. En revanche, GFA-TEM contient énormément de code de test de touches au clavier, sous forme de dizaines de macros
.macro KEY_READ row_ti89, row_ti92, col_ti89, col_ti92
move.w #1<<\row_ti89,%d1 | 4
move.w #1<<\row_ti92,%d2 | 4
move.b #\col_ti89,%d3 | 4
move.b #\col_ti92,%d4 | 4
jbra TokenConstant_KeyRead
.endm

TokenConstant_KeyRead:
clr.b %d0
tst.w CALCULATOR
jbeq _TokenConstant_KeyRead_TI89
_TokenConstant_KeyRead_TI92:
move.w %d2,%d1
jbsr _rowread2
btst.b %d4,%d1
sne %d0
jbra TokensExec_AddResult_NoDel_Bool

_TokenConstant_KeyRead_TI89:
jbsr _rowread2
btst.b %d3,%d1
sne %d0
jbra TokensExec_AddResult_NoDel_Bool

ce qui fait plusieurs centaines d'octets (8 * nombre de constantes de touches - et les constantes calculatrice s'optimisent de la même façon).

Et _kb_getkey.asm:
|masques précalculés
.data
.even
_kb_key_masks:
.word 0xFDFF,0xFEFF,0xFF7F,0xFFBF,0xFFDF,0xFFEF,0xFFF7,0xFFFB,0xFFFD

|codes de touches
_kb_key_data_92P_V200_normal:
.word 45,13,97,113,271,48,46,173
.word 257,136,108,111,43,266,264,0
.word 61,109,107,105,272,263,265,42
.word 94,110,106,117,268,262,13,112
.word 47,98,104,121,273,259,260,261
.word 32,118,103,116,269,40,41,44
.word 258,99,102,114,274,55,56,57
.word 0,120,100,101,270,52,53,54
.word 0,122,115,119,275,49,50,51
.word 344,340,338,337

_kb_key_data_92P_V200_shift:
.word 45,13,65,81,271,48,46,173
.word 257,136,76,79,43,266,264,0
.word 61,77,75,73,272,263,265,42
.word 94,78,74,85,268,262,13,80
.word 47,66,72,89,273,259,260,261
.word 32,86,71,84,269,40,41,44
.word 258,67,70,82,274,55,56,57
.word 0,88,68,69,270,52,53,54
.word 0,90,83,87,275,49,50,51
.word 33112,33108,33106,33105

_kb_key_data_92P_V200_2nd:
.word 4141,4109,0,63,271,60,62,4372
.word 4353,58,34,0,4139,266,4360,0
.word 92,59,124,151,272,263,4361,4138
.word 140,0,190,0,268,4358,4109,95
.word 93,39,38,18,273,4355,4356,4357
.word 32,157,0,35,269,123,125,91
.word 4354,0,159,64,274,4151,4152,4153
.word 0,169,176,0,270,4148,4149,4150
.word 0,0,223,33,275,149,4146,4147
.word 4440,4436,4434,4433

_kb_key_data_92P_V200_diamond:
.word 0,8205,8257,8273,8463,8240,8238,8365
.word 8449,8328,8268,8271,0,8458,8456,0
.word 8253,8269,8267,8265,8464,8455,8457,8234
.word 8286,8270,8266,8277,8460,8454,8205,8272
.word 8239,8258,8264,8281,8465,8451,8452,8453
.word 8224,8278,8263,8276,8461,8232,8233,8236
.word 8450,8259,8262,8274,8466,8247,8248,8249
.word 0,8280,8260,8261,8462,8244,8245,8246
.word 0,8282,8275,8279,8467,8241,8242,8243
.word 8536,8532,8530,8529

_kb_key_data_92P_V200_lock:
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 0,0,0,0,0,0,0,0
.word 33112,33108,33106,33105

_kb_key_data_89_normal:
.word 264,0,0,0,0,0,0,0
.word 265,258,149,124,61,120,277,268
.word 48,49,52,55,40,121,266,269
.word 46,50,53,56,41,122,278,270
.word 173,51,54,57,44,116,257,271
.word 13,43,45,42,47,94,263,272
.word 338,337,344,340

_kb_key_data_89_shift:
.word 264,0,0,0,0,0,0,0
.word 265,80,75,70,65,88,277,268
.word 86,81,76,71,66,89,266,269
.word 87,82,77,72,67,90,278,270
.word 32,83,78,73,68,84,257,271
.word 13,85,79,74,69,94,263,272
.word 16722,16721,16728,16724

_kb_key_data_89_alpha:
.word 264,0,0,0,0,0,0,0
.word 265,112,107,102,97,120,277,268
.word 118,113,108,103,98,121,266,269
.word 119,114,109,104,99,122,278,270
.word 32,115,110,105,100,116,257,271
.word 13,117,111,106,101,94,263,272
.word 33106,33105,33112,33108

_kb_key_data_89_2nd:
.word 4360,0,0,0,0,0,0,0
.word 4361,4354,159,176,39,4184,4373,273
.word 60,34,58,4151,123,4185,18,274
.word 62,92,4149,4152,125,4186,151,275
.word 4372,4147,4150,59,91,4180,4353,271
.word 4109,4139,4141,4138,93,140,263,272
.word 4434,4433,4440,4436

_kb_key_data_89_diamond:
.word 8456,0,0,0,0,0,0,0
.word 8457,64,8341,8316,157,8280,277,8460
.word 156,8241,8244,8247,0,8281,95,8461
.word 158,8242,8245,8248,169,8282,190,8462
.word 8365,8243,8246,8249,8236,8276,8449,8463
.word 8205,0,0,38,33,136,8455,8464
.word 8530,8529,8536,8532
.even

qui fait là aussi plusieurs centaines d'octets.
1 KB supplémentaire est donc envisageable.

Je ne connais pas le code de Nebulus non plus, donc je ne peux pas répondre comme ça.

En revanche, ce que je sais, c'est que ça sauve ~2 KB dans Ice Hockey 68k (dont le code n'est pas fait pour, il reste des , ~6 KB dans une version précédente de Hawk (et vu ce qu'il a modifié, ça n'a pas dû bien changer), ~10 KB estimés dans TI-Chess (coût des tests de touches + coût des graphismes).

> Réponse des miettes genre 3 Ko voir 5 Ko ce qui n'est rien!
"rien", faudrait pas exagérer... Surtout que ça se cumule, comme entre autres la perte de place due aux lanceurs spécifiques dès qu'il y en a plus d'un.
Et puis tu sais bien que chaque octet compte pour Kevin (voir entre autres les démonstrations de joie à chaque fois que Samuel gagnait deux octets sur la routine de décompression PPG), voyons...

Lionel Debroux - membre de TICT.

./Post n°70 Marquer comme non lu.

Sasume

Ecrit le: Mercredi 31 août 2005 à 22:19

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Nul :
Non, je n'utilise pas le Tilemap Engine, je trouve que ce n'est pas pratique ici et en plus:
"Et voici ceux où la librairie ne devrait pas être utilisée :

* Les jeux de plateau où le décor est constitué de sprites affichés à des coordonnées multiples de leur largeur (ex : SimCity) - voir les fonctions Tile... d'ExtGraph pour faire cela
* Les shoot'em up"
(cf doc de Tilemap)

En fait, je me suis mal exprimé : je voulais parler des shoot'em up avec scrolling vertical.
Pour ton jeu ça me semble parfaitement adapté.
Par contre, j'ai jeté un coup d'oeil à tes sources, et il est vrai que dans son état actuel, ton moteur n'est pas vraiment adapté pour ça. Mais ça permettrait d'alléger nettement le processeur.

./Post n°71 Marquer comme non lu.

Nul

Ecrit le: Mercredi 31 août 2005 à 22:28

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Juste pour les animations alors, pas pour les bords (ça ferait une matrice énorme). Mais je ne suis pas sûr que ce soit plus rapide avec Tilemap.

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°72 Marquer comme non lu.

Sasume

Ecrit le: Mercredi 31 août 2005 à 23:12

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Je ne comprends pas trop ce que tu veux dire par "animation" et "bord" #confus#

J'ai la flemme d'étudier ton code, mais il me semble que tu utilises SpriteX8 pour afficher une bonne partie de tes décors, or cette fonction est très lente

Quel est ton format de stockage des maps si tu n'utilises pas une matrice ?

./Post n°73 Marquer comme non lu.

Nul

Ecrit le: Jeudi 1er septembre 2005 à 00:21

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Les animations sont en fait les ennemis qu'il faut tuer.
Les bords haut et bas sont les images fixes qui défilent sur le fond (avec une espèce de treillis).
Je n'utilise SpriteX8 que pour rafraîchir les bords donc tous les 9 pixels. Sinon j'utilise Sprite32 pour les animations.
Il y a seulement deux motis élémentaires qui constituent les bords: un motif pour le haut et un autre pour le bas. La "map" est une liste indiquant l'ordonnée à laquelle il faut afficher d'abord le bord haut puis le bord bas (dans le code, c'est situé dans le dossier 'gfx', fichier 'hawk_gfx', 'bord_ord'). Ca peut paraître un peu crade comme façon de faire mais ça gagne énormément de place. Au lieu d'afficher 3 sprites avec Sprite32, j'affiche une seule sprite avec SpriteX8.

Voilà, j'espère que j'ai été plus clair cette fois

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°74 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 1er septembre 2005 à 08:55

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Hmm, peut-être un client pour les *SpriteX16... Quels modes de dessin des SpriteX8 utilises-tu ? Est-ce qu'elles sont gray (probable), clippées ?

Au passage, est-ce que tu as fait des versions compatibles on-calc ET incompatibles on-calc ? Je n'ai pas téléchargé le ZIP de ticalc car il est énorme à cause des animations.
-Edité le Jeudi 1er septembre 2005 à 09:00 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°75 Marquer comme non lu.

Nul

Ecrit le: Jeudi 1er septembre 2005 à 10:04

Membre: Maître

Messages: 141

Membre n°196

Inscrit le 16 avril 2004

Oui, Sasume m'a donné une bonne idée: il y a moyen de gagner de la vitesse dans l'affichage des bords. Le mode de dessin est en gray, non clippée et l'image a 16 pixels de largeur.
Non, je n'ai pas encore fait la version incompatible (après la rentrée je pense). Le zip de ticalc est beaucoup moins gros (870 ko contre 2.8 Mo avant), j'avais en effet laissé les screenshots animées dedans ...

"De tous les animaux, l'homme a le plus de pente,
A se porter dedans l'excès."

Jean de la Fontaine

./Post n°76 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 1er septembre 2005 à 13:12

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Nul :
Les animations sont en fait les ennemis qu'il faut tuer.

OK, donc le tilemap engine ne te srvira à rien pour ça.

Les bords haut et bas sont les images fixes qui défilent sur le fond (avec une espèce de treillis).
Je n'utilise SpriteX8 que pour rafraîchir les bords donc tous les 9 pixels. Sinon j'utilise Sprite32 pour les animations.
Il y a seulement deux motis élémentaires qui constituent les bords: un motif pour le haut et un autre pour le bas. La "map" est une liste indiquant l'ordonnée à laquelle il faut afficher d'abord le bord haut puis le bord bas (dans le code, c'est situé dans le dossier 'gfx', fichier 'hawk_gfx', 'bord_ord'). Ca peut paraître un peu crade comme façon de faire mais ça gagne énormément de place. Au lieu d'afficher 3 sprites avec Sprite32, j'affiche une seule sprite avec SpriteX8.

Pourquoi 3 sprites avec Sprite32 si tes bords font 9 pixels de largeur ?
En fait, je n'avais pas vu que tes niveaux ressemblaient à un "tunnel", c'est vrai que dans ce cas, ta solution est plus économique en mémoire. Et puis niveau rapidité je pense que tu t'en sors bien parce que tu n'as pas besoin de tout réafficher (l'arrière plan) à chaque fois...