un clone de txtrider - Page 3

ben tu fais un long temps d'init au debut et apres c bon ... (precalul les positions en fin, si c possible, je c pas trop comment tu le fais marcher KII)

mais ça serait tro cool!!! c ça le plu marran ds un shoot_them_up, jouer en coop, j trouve!! sachant ke darkangel a fait un rts en link, tu bien faire un shoot_hem_up en link! y'a à priori moins d'infos à véhiculer. faudrait se mettre à genlib, il mme semble qu'elle gère le link(total est fait avec genlib....)

quasiment tout est précalculé...
oué, c vrai que ça fait pas tant que ça, en fait...

il faut :
position dans les 2 matrices qui constituent le niveau.

A chaque fois qu'on touche un ennemi ou mur avec un missile, transmettre l'ordre de fmort du missile, et celui de baisser le niveau du mur ou ennemi...
mais galére qd même...

justement : c un super défi que d'y ariver !!

moi je tenterais

et bien, qd j'aurai fini en mode 1P, peut-être verrai-je pr le mode 2P...
vu que je connais pas du tout les manips du link, faudra le temps
mais j'essayerai..

ce sera pour KIII

je n'ai pas l'intention de sortir de KIII...

je sens bien un petit tunnel en link à 2P, pr commencer...
ensuite, suffira de généraliser le principe
(je rappele que K n'est rien de plus qu'un Tunnel amélioré)

comme tous les shoot-them-up a avancement .. (RType ...)

oué, en gros
sauf que moi, pour K, ct au sens propre : j'ai copdé un tunnel, puis j'ai rajoté des ennemis, puis des mssiles...
le projet TIGCC est resté le même...

j t souhaite du courage pr le link, ça va être

je hn'ai pas dit que je le coderai, mais que je le coderai PEUT-ÊTRE !

sisi, tu l'as dit!
nan sérieu, c à faire,j crois..

je crois aussi
mais voila quoi... je sais pas utiliser le link, d'une (mais ça, je peux apprendre)

et de deux, ça va me demander de réfléchir

Quelqu'un possède des sources de txtrider ?

ca tombe bien tu doit te changer les idees

je dois bosoer ce WE...
et je serai pas chez moi le WE prochain
peu pas vraiment coder avant le 23 au soir

mais tu peut y penser nan ??
moi je pense beaucoup plus que je code sur mes futurs algorithmes, ce qui me permet de garder un code et une structure d'ensemble comprehensible

pareil

je peux pas trop y penser à cause de... arf


et je peux pas coder pr oublier ...

squale92 a écrit :
Thibaut> je suis d'accord...
(remarque, je ne sais pas si c toujours le cas, mais ça l'a été à un moment, il me semble)
Mais je penses que la TIGCC-team a fait ça pr éviter l'abus de Dll...

En effet. Les DLLs ne sont faites que pour casser la limite des 64 KO! Pour tout le reste, il y a les librairies statiques!

squale92
a écrit : AU moins, le Kernel se débrouille avec les libs (pas besoin de mettre en statique le code d'appel des Dll dans chaque prog !)

Au lieu de mettre le code d'appel en statique, mieux vaut mettre le vrai code en statique!

Et je ne pense pas qu'il sera probable que quelqu'un ait effectivement sur sa calculatrice 6 programmes _nostub (les 5 que tu as comptés plus 1 pour la taille de la librairie dynamique elle-même) à utiliser une éventuelle ziplib.a. En général, j'estime qu'il en aura au maximum 3 (je dirais même plutôt 1 ou 2 - pourquoi y aurait-il une masse de programmes à utiliser un algorithme qui compresse très mal quand ttpack compresse très bien? La compression on-calc n'est nécessaire que très rarement!), et donc les librairies statiques conviennent déjà.

Squale92 #59> gaffe qd même à la taille de l'éxécutable, c déjà assez gourmand sur K 0.5 beta...

squale92 a écrit :
je crois aussi
mais voila quoi... je sais pas utiliser le link, d'une (mais ça, je peux apprendre)

et de deux, ça va me demander de réfléchir

merde! jy pensais pa; laisse tomber alors, c pa pr toi.

Kevin> moué.... mais bof...

ftp83> KII a pr le moment besoin de 57640 octets de RAM qd l'exe est en RAM.
et 102732 qd il est en archive (vu qu'il est temporairement recopié en RAM)

ouaaaaa !!!!!!!!
mais c un jeu monstrueux !!!!!!

K nécessitait toue la RAM de la TI

KII demande le moins de RAM possible (enfin, je peux peut-être gagner 1 ou 2ko, mais pas plus) à mes yeux...
Vu tous les graphismes, et autres, ça demande bcp de RAM...

rien que 3ko pr mettre la matrice des murs, plus 1ko pr celle des ennemis (pour chaque niveau, en sachant que un seul niveau est présent simultanément en RAM)
plus tous les sprites...
par exemple, 12 ennemis par niveau, en sachant que chaque ennemi est constitué de 4 sprites en niveau de gris non masqués...
plus le boss de fin de niveau...
plus les sprites des murs...

comment tu fais squale pour connaitre la RAM exacte demandée ?

technique de barbare :
je regarde avant de lancer le prog combien il y a de RAM libre.
et en plein milieu du jeu, je regarde combien il en reste...
=> et je soustrait les deux valeurs

bin comment tu fais pr savoir en pl1 jeu combien y t'en reste? tu as ajouté à ton code une touche pr savoir?

j'ai fait encore plus bidon :
àa chaque cycle, un petit HeapAvial, puis sprif, puis drawStrXY...

ça fait ramer à mort... mais pas grave.

squale92 a écrit :
j'ai fait encore plus bidon :
àa chaque cycle, un petit HeapAvial, puis sprif, puis drawStrXY...
ça fait ramer à mort... mais pas grave.

je ne connais pa ces 2 fct°....(newb..), ms jimagine.

oué, en plus que je me suis planté en les écravant
HeapAvail => renvoie la taille de RAM libre (en gros)
sprintf => fait comme printfd, mais met le résulat dans un buffer (donc, transforme la valeur retournée par HeapAvail en une chaine de chars)
DrawStrXY => affiche le buffer