Taquin - Page 1

Grace à cooper qui a eu la gentillesse de me faire profiter de son code pour réaliser des jeux de taquins j'ai commencé la production de masse.

En cadeau voici le premier que j'ai réalisé

http://pageperso.aol.fr/firenzemouss/Taquin.o


Mon but serai de faire une rom "compilation" de 256 voir 512ko ou à chaque fois que l'on réussi un tableau on accède au suivant.

Problème: étant donné que la taille des programmes exécutable ne peut excéder 40ko je ne peux pas écrire les tableaux les uns à la suite des autres.
D’ou ma question: comment faire.


Ma première idée consistait à crée une sorte de menu (genre les menus de sélections de niveau dans les jeux) ou à chaque foi que l'on termine un tableau cela entrainera le retour au menu de sélection et autorise le passage au niveau suivant...

Problème: comme tout le monde le sais je ne suis pas très doué en prog. Donc si quelqu'un pouvais m'aider...



Et puis au risque de me répéter, encore un énorme merci a cooper pour son programme vraiment excellent.

Tu peux éventuellement envisager de charger les niveaux depuis la rom à chaque fois...

RYGAR (./1) :
étant donné que la taille des programmes exécutable ne peut excéder 40ko

Et pourquoi donc?

Parce que c'est la taille de la Ram

Si je parts sur l'idée de chargé les tableaux depuis la rom à chaque fois, faut t'il que j'écrive les codes source d'une maniere spécifique ou bien puis-je réaliser en amont mes tableaux en .0 (comme celui en démo poste 1) et les compiler ensuite a l'aide d'un autre programme?

Il y a un truc que je ne dois pas comprendre alors.
Les jeux de plus de 40K se chargent au fur et à mesure dans la RAM?
En gros, ca fonctionne comment? Parce que je ne sais même pas qu'elles sont les bonnes questions à poser pour comprendre le mécanisme!

La ROM (cartouche) d'un jeu lynx doit être vue comme une "cassette".

La console lit des blocs de manière successives. Elle commence bien évidament par aller lire le prmier pour charger le programme. Ensuite, on peut aller lire un bloc de données supplémentaires sur la cartouche. Dans cette optique, on va avoir une zone en RAM pour le programme lui même et une autre zone dans laquelle on stockera ce qu'on aura chargé depuis la ROM. Au niveau suivant, cette seconde zone en ram sera écrasée par les données chargées dans le bloc suivant en ROM. Et ainsi de suite...

Pour la création, il faut externaliser ses données et le préciser dans un "makefile".

Et si on suit la méthode de Fadest sans utiliser de makefile, on fait comment?
T'aurais pas un petit exemple pour voir comment on fait. Ces données sont juste dans le makefile ou dans la source aussi?

je n'ai pas d'exemple parce que je n'utilise pas les makefiles comme il faut... :/ désolé

Sois pas triste
Visiblement toi non plus tu n'es pas passé au megapak de Karri! Il devrait faire un manuel ca arrangerait surement beaucoup de monde. Ca a l'air du bon boulot en plus, mais si quelqu'un pouvait expliquer comment l'utiliser ca serait encore mieux
Hormis son MegaPakTemplate où il y a tous les Makefiles qui'il faut, il n'y a pas de description des fonctions que l'on peut utiliser.
Je trouve le manque d'informations assez décourageant surtout lorsque l'on débute, et c'est bien dommage.
Surtout quand je vois les tutos pour programmer sur Atari 2600 j'hallucine!

Dis moi comment tu fais, ca sera plus simple. J'utiliserais ta méthode

En fait, le problème du nouveau compilo, c'est qu'il n'est pas compatible avec le kit BLL (noms de fonctions différentes), car il utilise des noms de fonctions communes pour pouvoir recompiler plus facilement sur toutes les plates-formes 6502 (en gros, c'est une adaptation à la Lynx d'un compilo pour plates-formes 6502). Personnellement, je n'ai pas envie de tout jeter, ni d'investir du temps pour repartir de 0. Par contre, il permet effectivement de charger/décharger des bouts de code dynamiquement, donc d'avoir un programme plus gros en réalité.
Pour ma part, lorsque mes jeux deviennent trop gros, j'externalise les fonds (il faut dire que plus c'est coloré, détaillé et tout et tout, plus ça prend de place, jusqu'à 9ko par écran une fois compressé) et je n'en charge qu'un à la fois. Il m'est arrivé également de splitter mes programmes (à la base, Shoot, domino, dance, ...) étaient des niveaux bonus d eSpace Lock, devenus indépendant. Bref, c'est pas l'idéal, mais je fais avec ces restrictions, même s'il est surement possible de faire mieux (mais peut-être pas avec le kit BLL en C qui n'est pas terminé au niveau gestion de fichiers).

Ensuite, tout dépend ce que tu veux faire comme jeu.

Je ne veux pas faire specialement un jeu mais juste pouvoir faire tenir 256ko de jeu de taquin sur une seule ROM et pouvoir ainsi me graver une EPROM pleinement occupée.

L'ideal serai de faire un menu (genre ceux que tu as sur les yastuna) qui permet de charger tel ou tel tableau puis une fois le tableau resolu on revient au menu et ainsi de suite.

J'arrive pas à lancer la ROM chez moi. Il me dit que l'image n'est pas reconnu

surement un pb avec ton émulateur... ça marche bien chez moi et au boulo.

marche très bien ici aussi...


ton image de boot est correcte ?

Je lance n'importe quel jeu et routine, etc. D'ailleurs ton programme AQUA passe bien.

Je viens de penser de re-télécharger la ROM... et ça marche
Toutes mes excuses pour ces inquiétudes et mes étourderies. Je te voyais déjà entrain de chercher le pourquoi du comment dans tes codes

Sympa l'image ! C'est qui sur la photo ?
Sinon pas évident comme c'est une photo, mais sympa

Il m'a fallu presque 10 minutes pour y arriver
Quand j'avais 6-7 ans j'étais balaise à ce jeux (mais les images n'étaient pas du même genre ), j'ai perdu ma super technique.

J'aime bien le maniement avec les flèches (du coup, avec la Lynx et sa crois directionnel ça doit être nickel !)

Pour le maniement bravo à cooper, c'est vrai que c'est vraiment super agréable à jouer et je confirme que c'est beaucoup plus sympa et rapide à jouer sur console.

PowerMarcel (./19) :
mais les images n'étaient pas du même genre

Justement j'en avait marre des taquins publicitaires des années 80... Elle est quand même plus sympa cette demoiselle...
Et je parle pas de ses 20 copines que j'ai deja "taquinisé" aussi!

Rien de bien spectaculaire au niveau du code

Et la différence se fait sentir au niveau rapidité sur vraie console car l'emulation de la gestion des sprites n'est pas terrible avec handy

vince (./7) :
La ROM (cartouche) d'un jeu lynx doit être vue comme une "cassette".

La console lit des blocs de manière successives. Elle commence bien évidament par aller lire le prmier pour charger le programme. Ensuite, on peut aller lire un bloc de données supplémentaires sur la cartouche. Dans cette optique, on va avoir une zone en RAM pour le programme lui même et une autre zone dans laquelle on stockera ce qu'on aura chargé depuis la ROM. Au niveau suivant, cette seconde zone en ram sera écrasée par les données chargées dans le bloc suivant en ROM. Et ainsi de suite...

Pour la création, il faut externaliser ses données et le préciser dans un "makefile".

La rom n'est pas mappé en mémoire ? (quitte a avoir une pagination)

non

il faut voir la rom comme une bande magnétique

Erf ok c'est con ça :/ (donc accessible a partir d'un port IO je présume...)

Hum ça doit etre un défi interessant ça

(hummm et en plus c'est du 6502... )

non, lecture // mais séquentielle et pas assez de mémoire interne pour ghoster une cartouche complète

complete c'est sur, mais sur NES (par exemple, vu que c'est le meme CPU) la ROM est mappé sur les 32 derniers Ko avec pagination possible et ça n'a pas empeché d'avoir des jeux de plusieurs centaines de K (voir meme presque 1Mo)) (oui 1Mo ça parais ridicule maintenant )

Bon j'arrete de polluer ce sujet ^^

cooper (./22) :
Et la différence se fait sentir au niveau rapidité sur vraie console car l'emulation de la gestion des sprites n'est pas terrible avec handy

Ca c'est clair le jeu de 60 cases que j'ai fait est d'une lenteur halucinante sous handy alors qu'il tourne trés bien sur console.

cooper (./22) :
Rien de bien spectaculaire au niveau du code

Et la différence se fait sentir au niveau rapidité sur vraie console car l'emulation de la gestion des sprites n'est pas terrible avec handy

Pour info, tes sprites sont chainés ou pas ?

Nope pas là