Programmation Master System en Assembleur + variante en C

Alex Kidd (Alex Kidd) Score : 7195 Date d'inscription : 26/08/2009

Content, j'ai "presque" fini ma détection de collision ^^
pas simple entre un perso de 24x24 (pas centré, ca serait trop facile) et une grille de blocs 16x16...

PS.
Pour Vingazole, si on veut faire un truc à 4 joueurs, faudra avoir des sprites de 2x2 tiles (16x16px) pour ne pas dépasser la limite des 8 par lignes.
Pour les reste, tout est géré en tiles de background, donc la pas de souci.
Quand j'y repense, c'est bizarre que ca n'ait pas été porté à l'époque sur SMS (alors que sur nes oui...).
Graphiquement je ne suis pas fait chié, j'ai recup les tiles de la version original et adapté la palette pour SMS (et c'est plutot pas mal du tout ^^)

Pour la taille des sprites, il y aura sûrement moyen de gérer un flickering pas trop dégueu, je pense...

Tu ferais comment, changer/incrementer l'ordre de la SAT à chaque frame genre un "espèce" de LIFO) ?
1-2-3-4-5 puis 5-1-2-3-4-5, 4-5-1-2-3....
je suppose que comme ca c'est pas le meme tiles qui clignote, non ? (ou du moins à l'oeil c'est "soft")

Je pensais plutôt: afficher une frame sur deux d'abord les deux colonnes de droite de chaque perso, puis la colonne de gauche; puis faire le contraire à la frame suivante: afficher les deux colonnes de gauche, puis la colonne de droite. Comme ça, la colonne centrale de chaque perso serait toujours affichée et on aurait un clignotement rapide (25 fps en PAL) des colonnes droite et gauche (dans le pire des cas où les 4 persos seraient alignés horizontalement).

Par contre, gestion du flickering ou pas, il faudrait afficher les persos (càd envoyer leur tiles dans la SAT) dans l'ordre décroissant de leur coordonnée Y pour donner une impression de profondeur (les persos de coordonnée Y les plus grandes passeraient devant les autres à l'affichage).

ok, compris pour le flick (c'est pas con !)

Pour la SAT :
si j'ai un perso en 200 et un autre en 170 puis un dernier en 50 (par exemple)
le 200 doit etre en 1er (SAT de 0 à X)
puis celui de 170 (SAT de X à Y)
puis celui de 50 (SAT Y à Z)

j'ai bon ? (la flemme de regarder sur smspower...^^)

sinon Maxim a mis bmp2tile à jour avec la compression aplib + support bibliotheque externe.
la aplib est prise en charge par z88dk, j'ai juste testé la compression de bmp2tiles, je passe de 8ko à 1ko pour un fichier de tiles.

ichigobankai a écrit:: Pour la SAT :
si j'ai un perso en 200 et un autre en 170 puis un dernier en 50 (par exemple)
le 200 doit etre en 1er (SAT de 0 à X)
puis celui de 170 (SAT de X à Y)
puis celui de 50 (SAT Y à Z)

j'ai bon ? (la flemme de regarder sur smspower...^^)

Oui, c'est bien ça, le sprite n°0 est affiché devant le sprite n°1 qui est affiché devant le sprite n°2 etc...
Je viens d'ailleurs de vérifier que c'est le contraire qui est écrit dans la doc officielle SEGA (et donc dans ma trad en français)

ichigobankai a écrit:: sinon Maxim a mis bmp2tile à jour avec la compression aplib + support bibliotheque externe.
la aplib est prise en charge par z88dk, j'ai juste testé la compression de bmp2tiles, je passe de 8ko à 1ko pour un fichier de tiles.

J'ai vu ça, impressionnant le taux de compression !

je t'envoie un mail, avec une comparaison de perso 24x24 et 16x24, tu me diras ce que t'en penses.
le 16x24 serait plus simple à la fois pour le calcul de collision/placement et pour le flick (plus de souci) et surtout moins de tiles à charger (90 au lieu de 126), d'ailleurs questions :
est ce que ca ne serait pas mieux de charger/remplacer les tiles des sprites au fur et à mesure ?

genre je charge "juste" une position à l'initialisation (donc 3x3 ou 2x2 tiles), et je change ses tiles en fonction du temps (pour l'anim) et de la direction ?

car sinon entre les tiles de background + les persos ca passe pas (enfin si y'a 4 persos à charger)

et oui pour la compression, c'est assez impressionnant !
il m'affiche 84,38%...^^

Les persos 16x24 feront l'affaire (les originaux utilisant seulement 17/18 pixels sur les 24), en plus ça simplifie/allège tout !

Du coup, ça passerait pour les tiles de background+persos ?

Si oui : il vaut mieux que tu charges toutes tes frames d'animations une fois pour toutes et que tu affiches les tiles correspondant aux frames d'animations que tu veux montrer,

sinon : tu es obligé de faire comme tu as dit (mettre à jour les patterns de tiles au fur et à mesure) et ça risque d'être tendu à cause de la quantité de données à mettre à jour en VRAM (32 octets/tile * 6 tiles/perso * 4 persos), tu seras peut-être obligé de répartir le chargement des frames d'animation sur plusieurs frames d'affichage - risque de glitches graphiques si tu "mords" sur l'affichage actif (hors VBLANK).

PS: n'oublie pas que les sprites doivent impérativement utiliser les tiles n°0 à 255.

ok, je ne savais pas pour les sprites/tiles en 0/255.

je vais passer les tiles de background dans la bank 2 (en nombre pas de souci), je testerai tout à l'heure (faut que je regarde dans les fichiers include), pour les persos je vais devoir "sabrer" car on depasse les 256... sinon faut limiter a 3 players et c'est con.

Si ça ne passe pas 256 tiles pour toutes tes frames d'animation de sprites, tu peux peut-être faire un truc mixte: 6 tiles fixes pour le joueur 1 que tu modifies au fur et à mesure, et les 3 autres avec toutes les frames chargées une fois pour toutes.

Ca te fait combien de tiles d'animation par perso/au total, en fait ?

alors, par perso :
4 directions, avec chacune 3 anims + mort (3 anims aussi, normalement c'est bcp plus entre 5 et 10 selon les versions...doit pouvoir se mettre juste en 1 image, avec pkoi pas un truc à la alex kidd ; un ange qui disparait vers le haut de l'écran)

donc en tiles ca ferait
si on prend la mort en 3 anims (5 * 3) * 6 tiles, soit 90 tiles au total / perso.

si on prend la mort en 1 anim ((4*3)*6)+6, soit 78 tiles au total / perso.

dans le dernier cas, ca passerait avec ta méthode, 3 persos chargés + 1 avec 6 tiles qui se chargent au fur et à mesure. (240 tiles - 234 fixes + 6 dynamiques);

NB. la mort peut etre identique à tous les persos, du coup on pourrait gagner un peu !
72 tiles / perso + 6 tiles de mort

Ok, dans ce cas le meilleur compromis ça me semble être de faire 2 persos sur 6 tiles à mettre à jour au fur et à mesure et 2 persos avec les frames déjà chargées : 12 tiles à charger par frame je suis sûr que ça passe et ça te permet de ne pas "sacrifier" tes animations Wink

J'ai eu une réponse de Furrtek pour le multitap, je t'ai fait un mail.
J'ai refait les sprites en 2x3 tiles et remis la planche de tiles de background au "propre".

Cool

et j'ai dormis 5h...^^,
pas simple avec les 2 gosses à gérer depuis 10 jours....heureusement que maman arrive tout à l'heure (et repart lundi ><)

je ferais un mail à haroldook pour la lib en C, savoir pour le system de bank, vgm player....enfin les trucs qui risques de me "coincer".

J'ai bien envie aussi d'envoyer un mail au gars de "Gekioko PunPun Maru" (qui a été fait quasi intégralement en C), mais j'ai l'impression que c'est japan only.
http://68000.web.fc2.com/oko/

Bon ca y est la partie multiplayers (4 joueurs) est fonctionnelle !
Me reste plus qu'a coder....plein de "petits trucs" avant de faire un teaser
(au moins le system de collision)

Hayato (Kenseiden) Score : 357 Date d'inscription : 18/03/2013

Apparemment on est limité à 48ko pour le développement en c , si mes souvenirs sont bons je crois que le gars qui avait développé bread and butter avec le z88dk avait sortis plusieurs versions de son jeu avec des niveaux differents à cause de cette limite. En tous cas ichigo bon courage pour ton projet multitap, ca l'air d'etre de la bombe.

j'ai trouvé des exemples dépassant les 48ko avec un système de banks comme les jeux fait en ASM (chaque bank faisant 16ko) Wink

Pour le moment je ne m'occupe pas de la "taille", et je peux tjs compresser tout ce qui est graphisme pour gagner en place.

J'ai corrigé des problèmes liés au multitap, maintenant toute cette partie est fonctionnelle, me reste surtout la partie "collision" à refaire.

Allez ~60% de la partie collision faite, et c'est bien prise de tête ^^
Je pense qu'un petit teaser devrait pouvoir ce faire ce weekend.

Hayato (Kenseiden) Score : 357 Date d'inscription : 18/03/2013

T'as raison Ichigo pour les attributs H/V ça marche directement , je me suis compliqué la vie , alors que j'aurai du directement tester.

attention tout de même, les attributs de flip h/v ne marchent pas sur les sprites, uniquement sur les tiles de background Wink

Hayato (Kenseiden) Score : 357 Date d'inscription : 18/03/2013

Petit avancement de mon projet homebrew qui se nomme désormais christmas tale , petite musique pour l'ecran titre aevc un appuyez sur start qui clignote, la musique est jouée en boucle jusqu'a ce que l'on appuie sur le bouton 1.

Sympa, ça donne envie Smile

Alex Kidd (Alex Kidd) Score : 2741 Date d'inscription : 15/11/2010 Age : 31

Pareil, j'aime bien le design du perso, j'attends de voir l'avancement ^^

_________________
Have fun Playing

Alex Kidd (Alex Kidd) Score : 6459 Date d'inscription : 16/03/2010 Age : 35

Jolie.

Sur smspower bientot les presentations des jeux pour le concours.

Il y a deux 2048 en competition, j'adore ce jeu alors forcement c'est la joie.

» Programmation Master-System en assembleur
» Programmation Master-System en basic
» [VDS] Master system 2 pack sonic en boite, jeux, master system 1
» ColeCoco Master - Adaptateur Colecovision pour Master System
» Samsung GamBoy System (la master system coréenne)