Coming soon... - Page 2

je dit ca je sais po mais le pixeltest c un peu bourrin nan ??

une matrice

, ça serait trop dur je pense. Plxtest à la limite, en testant aux extremité des hélices (car si y'a collision, ça touchera forcement un des 2 bouts).

Pour le scroll c'est hyper facile (surtout si les niveaux sont ds une matrice toute prête).
un peu de clipping et hop.

pour CF, merci RAGE2000

mouais , j'ai mandié assez longtemps une beta pour comprendre qu'il la file à personne !!!! je pense que c'est un autre prog que celui de PpHd.

ah nan avec une matrice bien gérée (g une idée sous la tete) on peut tres bien s'en sortir

ben vu que son hélice est en scroll progressif (pas du case par case), c'est pas hyper facile, mais fesable. moi aussi j'ai une idée, mais qui serait assez grosse (cad 2 Ko au moins rien que pour ces collisions grace à une matrice).

Les Pxltest devraient être + rapide et moins chiant à programmer : if(Pxltest(48,65) == 1) ect ....

non, pas comme ça pim, plutot comme le fait le jeu donné en exemple dans TIGCC (caveblaster)

pour les collisions c simple, jpensais effectivement à caveblaster (le baton se déplace toujours sur une partie "blanche" du niveau). sinon pour chrono, laissez tomber, c pas chrono
et pour réduire la taille du baton, ça me semble presque impossible, vu que la rotation du baton est en fait une succession de sprites, fodrait que je refasse plein de sprites de tailles différentes, c chiant...
sinon pour le scrolling c vrmt fait a l'arrache

C ou asm ?

C

bah le scroll y'a pas 36 moyen ...

t'affiches avec une marge de 1 sprite de + à droite en clippant (car c'est là que le décor apparait) , et tu décalle de x pixel (x++ à chaque fois en redessinant tout, puis quand x=16 (donc tu a affiché 1 sprite de 16*16 en plus à droite quoi), ben tu te décalle ds la position de la matrice de 1 "cran", et ainsi de suite.

ds Cave Blaster, comment est géré le pxlTest() ????

-

pk vous faites pas de map de collision???
C plus rapide, plus simple, et ça permet de multiples possibilitées :
-gérer des obstacles
-gérer les portes
-gérer tous les autres trucs commes les objets à prendre

une routine de rotation de sprite serait tro lente jpense

vive la map de collision !!!!!!!!!

oui mais pas si facile à replacer l'hélice ds cette map en étant précis.

c clair ça se joue au pixel pres et les "virages" ne se font pas de façon réguliere donc ça me semble impossible d'utiliser une matrice pour les coliisions

oué, si t'as pas des sprites tout carré, c'est mort !

-

contrairement_a_ce_que_certains_pourraient_penser,_le_projet_n'est_pas_abandonné,_loin_de_là.
mais_j'ai_choisi_de_recommencer_le_codage_du_jeu,_en_utilisant_genlib._le_prog_sera_compatible_ti92+_des_la_premiere_beta,_ce_qui_n'était_pas_prévu_initialement.
je_gere_les_collisions,_j'ajoute_des_niveaux,_et_puis_c_bon!!!
allez_un_pitit_screen_pour_la_route.

euh.. ton screen marche pô, là.
ainsi dc, tu continues ton jeu? c cool, ça!

un truc ke je me demande: comment tu codes sans la barre d'espace? c pa possible...

copier_coller_qd_j'en_ai_vrmt_besoin
mais_la_plupart_d_temps_je_me_sert_de_latouche_TAB

g rien dit, y marche ton screen. , tu gères le déplacement vertical maintenant. et les collisions? le shot en di pa long...

juste une ques Nerick > ton scrolling, il est de combien de pxl/affichage ?

2

bah ca va encore
c maintenant
moi ca oscille pour le scrolling entre 1 et 8

gugusg>dans_driver,_tu_utilises_des_rotations_pour_les_virages_de_la_caisse,_ou_alors_tu_définis_plusieurs_sprites?

ben pour gugusg, je pense qu'il utilise divers sprites car il perdrait du tps a le faire en rotation vu que le deplacement doit etre rapide

mais pour toi, vu que tu as besoin de bcp de sprites, faut mieux que tu fasses une rotation

pour l'instant rotations
on verra plus tard

tu vois?
tu devrais les précalculer...