Bad Dudes Vs Dragon Ninja sur Mega Drive en Basic

OK, par contre je suis pas familier du fonctionnement du scrolling sur MD, est-ce que des lignes d'une même map 

Tu n'aurais pas les images brutes et non découpées en tiles ??

touko : comment ca marche pour la zik en cours de jeu sur la MD, c'est copié dans la ram (et ca prend de la place donc il faut pas trop abuser sur la taille)  ou c'est "streamé" depuis la rom (et la,  le poids de la musique, ca ne compte plus vraiment)?

kaot a écrit:touko : comment ca marche pour la zik en cours de jeu sur la MD, c'est copié dans la ram (et ca prend de la place donc il faut pas trop abuser sur la taille)  ou c'est "streamé" depuis la rom (et la,  le poids de la musique, ca ne compte plus vraiment)?

Tout dépend de la taille, mais en général elle reste sur la ROM et est lue directement de là soit par le 68k soit le z80, tout dépend du driver audio .
Une musique doit faire entre 20 et 50 ko je pense (sans sample bien sur), et vu la taille des cartouches que tu peux avoir pas de soucis pour la taille, vetea à mis que des musiques au format .wav pour son papie MD .

La tiennes fait combien ??

entre 20 et 60 k chaque, à la louche (samples compris), peut etre moins en le "réduisant" (j'ai vu un trimmer de .vgm sur le net, ca permet de gagner un peu de place en compressant les data des patterns, encore faut-il que ca soit lu correctement en bout de chaine...)

en fait jte demandais ca parce que je vois sur le wiki de le MD :
The system contains 72kB of RAM, as well as 64 kB of video RAM.

jme dis que meme si la musique ne fait que 5k, vu le peu de ram dispo, c'est déja énorme si c'est copié en ram. du coup ca m'arrange que ce soit lu direct depuis la rom.
bon, j'y retourne...

Oui la mettre en ram est toujours une possibilité, mais l'utilité n'est pas très grande .
Mais faut pas te formaliser sur la taille, les tiennes sont bonnes et vu que les roms aujourd'hui peuvent faire 32 MB sans soucis, t'as de la marge 

TOUKO a écrit:Oui la mettre en ram est toujours une possibilité, mais l'utilité n'est pas très grande .
Mais faut pas te formaliser sur la taille, les tiennes sont bonnes et vu que les roms aujourd'hui peuvent faire 32 MB sans soucis, t'as de la marge 

attention à la taille des rom quand meme. des qu'on depasse 4096 octets, on ne peux plus la tester sur une everdrive.
sur emulateur, au dela de cette limite, kega fusion deconne aussi.

Oui, 4096 ko, ça te fait une cartouche de 32 MB 
Je pense que ça devrait suffire pour dragon ninja, quand je vois vetea qui à mis tout les sons et les musiques en samples dans ces 32MB .

Aaaah des megabits, pas des megabytes ! C'est trompeur quand on parle de Ko pour les zikes. Pas l'habitude de compter en bits moi (et je ne suis pas le seul visiblement !)

C'est vrai, j'aime pas non plus, mais bon c'est plus simple quand tu parles de tailles sur MD/SNES/PCE, ça permet de situer une taille par rapport aux jeux de l'époque, qui ne juraient que par les tailles en Mbits ..

D'accord, mais dans ce cas écrit 32 Mb (mégabits), pas 32MB (mégabytes = mégaoctets)

vingazole a écrit:D'accord, mais dans ce cas écrit 32 Mb (mégabits), pas 32MB (mégabytes = mégaoctets)

Pas faux ça !!!
J'ai plutôt tendance à écrire MB pour MegaBits, et directement MO pour MegaOctets, et pas bytes .
Ca permet d'éviter les confusions .

Notes que depuis 1998 le kilo octet est passé de 1024 à 1000 octets
Il a fallut intégrer les codeurs java qui ne savent pas ce que c'est que le binaire et l'algèbre de bool 
C'est un demi troll... mais juste un demi 
http://fr.wikipedia.org/wiki/Octet

Oui, la belle aberration des Kio et Mio...
Mais c'est plutôt les commerciaux qui ont inventé ça : si si, votre clé fait bien 16 giga, il y a 16.000 octets

Edit : le "gibi", ça va plaire aux alcolos

Eh les gars vous êtes venus nous pourrir le topic ou quoi ??, on code du sérieux ici 
On parle d'arcade perfect là, pas de savoir combien de traits de couleurs différentes on va pouvoir afficher, non mais 

Je commence un nouveau boulot, donc j'ai pas eut le temps de passer sur le forum. Le temps que je retrouve mes marques.

J'en profite pr refaire de 0 mon moteur quand j'ai le temps le soir. J'ai bcp appris sur la megadrive depuis alors autant repartir sur de bonnes bases.

quand on bosse, dév' un jeu devient quasi impossible.

je confirme doc   .
C'est pour ça qu'il faut que le dev retro reste un loisir, et ne devienne pas une contrainte, sinon on lâche l'affaire .

J'en profite pr refaire de 0 mon moteur quand j'ai le temps le soir. J'ai bcp appris sur la megadrive depuis alors autant repartir sur de bonnes bases.

C'est normal, mais fais attention de ne pas tout refaire à chaque foi, car sinon t'en fini jamais,et je sais de quoi je parle, je suis comme ça 
C'est aussi pour ça qu'il faut éviter de se disperser sur plusieurs machines .

oh yeaa les gars sont de retour

TOUKO a écrit:je confirme doc   .
C'est pour ça qu'il faut que le dev retro reste un loisir, et ne devienne pas une contrainte, sinon on lâche l'affaire .

C'est normal, mais fais attention de ne pas tout refaire à chaque foi, car sinon t'en fini jamais,et je sais de quoi je parle, je suis comme ça 
C'est aussi pour ça qu'il faut éviter de se disperser sur plusieurs machines .

Je suis d'accord avec toi, c'est pourquoi, je programme 1 heure, je joue 1 heure. Ca libère l'esprit.
Pour le code, faut se rendre à l'évidence, ça me prendrait autant de temps à modifier qu'à réécrire proprement, j'en suis qu'au début heureusement.

Urbinou a écrit:Oui, la belle aberration des Kio et Mio...
Mais c'est plutôt les commerciaux qui ont inventé ça : si si, votre clé fait bien 16 giga, il y a 16.000 octets

Edit : le "gibi", ça va plaire aux alcolos

Moi c'est le contraire. J'ai jamais aimé l'usage qu'on faisait en informatique des préfixes Kilo, Mega, Giga qui ont un sens bien précis dans le système international (mille, un million, un milliard) et qui sont galvaudé en info. Et c'est justement a l'epoque ou les commerciaux ont commencé a reprendre le sens premier de ces suffixes pour les CD ou les HDD et donc créer de la confusion qu'il a fallut enfin faire ce qui aurait du etre fait dès le debut, crée des préfixes adaptés au monde binaire plutot que d'utiliser ceux existant de la mauvaise facon (un meme préfixe ne peut pas représenter des valeurs différentes).
Malheureusement personne ne les utilisent, meme dans un systeme d'exploitation comme Windows du coup la confusion reste tout le temps et partout (combien de fois on s'est retrouvé a tâtonner avant de graver un CD ou DVD pour savoir si ca va rentrer parce que chacun utilise les meme préfixes pour des valeurs differentes).

Pour le code, faut se rendre à l'évidence, ça me prendrait autant de temps à modifier qu'à réécrire proprement, j'en suis qu'au début heureusement.

Et surtout ne code pas un truc vite fait pour tester sur le niveau 1 par exemple, penses directement pour tout les niveaux, ça te permettra d'avoir un moteur plus ou moins adapté à tout tes niveaux .
Sinon tu vas commencer par mettre plein de truc avec le niveau 1 et tu vas te retrouver avec un programme mal adapté pour des niveau difficiles comme la forêt, et là tu vas commencer par faire un code crade et tordu pour pas tout recommencer .

Je viens de me rendre compte que le jeu arcade utilise une palette principale de 15 bits, donc convertir les GFX comme ça vers une palette 9 bits va y avoir pas mal de perte niveau couleurs, et donc détails.

TOUKO a écrit:Je viens de me rendre compte que le jeu arcade utilise une palette principale de 15 bits, donc convertir les GFX comme ça vers une palette 9 bits va y avoir pas mal de perte niveau couleurs, et donc détails.

15 bits comme la neogeo , car le 16eme bit sert pour la transparence.

Pas le choix pour la megadrive à moins de faire un jeu en 32x.

Le choix serrait de recoloriser les GFX en prenant en compte une palette 9 bits, donc bcp de boulot .

On a des GFX arcade en 32 couleurs, qui tombent souvent à 16 ou 13 couleurs quand tu les passes en 9 bits de façon automatique, la perte est assez énorme visuellement selon les niveaux .

Oui, il faut définir les palettes en manuel, donc, c'est pourquoi une recherche artistique est absolument nécessaire. Mais le sacrifice était plus grand sur la version famicom du jeu.

philip a écrit:Oui, il faut définir les palettes en manuel, donc, c'est pourquoi une recherche artistique est absolument nécessaire. Mais le sacrifice était plus grand sur la version famicom du jeu.

On est d'accord, mais bon c'est rageant de savoir que tu peux garder une grosse partie de la qualité des décors d'origine, et perdre 50% des couleurs à cause d'une conversion automatique en 9 bits .

TOUKO a écrit:Je viens de me rendre compte que le jeu arcade utilise une palette principale de 15 bits, donc convertir les GFX comme ça vers une palette 9 bits va y avoir pas mal de perte niveau couleurs, et donc détails.

C'est marrant car j'avais bien cité ce problème là quelques pages avant (surtout que ça me paraissait logique étant donné le problème plus qu'évident des couleurs limités de la megadrive :) ).

Pour la version Md tu as raison, ça change rien, mais pas pour une éventuelle version  SGX ou on a 32 palettes .

TOUKO a écrit:Pour la version Md tu as raison, ça change rien, mais pas pour une éventuelle version  SGX ou on a 32 palettes .

Oui certes ça pourrait être une version arcade perfect, hormis pour les teintes qu'il faudra adapter (étant donné que la Supergrafx a la même palette que la PC Engine, c'est à dire du 9 bit). Ceci dit, c'est la version Megadrive qui nous intéresse ici.

De la news les cocos ?

En attendant voici un soft qui va vous permettre de dump les sons du jeu.

http://rbelmont.mameworld.info/?page_id=223

A+