forum.system-cfg.com

Donc il faut commencer par les bases.

initiation à l'assembleur sur Exelvision déplacé dans un nouveau post


Concernant ton interprétation des lignes de codes que je t'avais donné en exemple ce n'est pas exactement ça :

LDA #$05 copie la valeur de l'adresse $05 dans le registre A

mais plutôt on met la valeur $05 dans l'accumulateur A,
parce que # précise qu'il s'agit d'une valeur et non pas d'une adresse

Merci pour ce petit cour,
Je commence a mieux comprendre la chose, mais il y a encore beaucoup de chemin avant que la ce soit clair dans ma tête

Ne t’inquiète pas pour les fautes, j'ai tout compris et c'est le principal.

Une petit question, qu'elle compilateur utiliser pour faire mes tests futurs ??

Justement j'allais en venir ultérieurement quel assembleur utiliser pour les sources TMS7020, personnellement j'utilise TASM qui fonctionne encore très bien sous Win10 à condition de prendre al bonne version

Je pense que ca serait bien d'ouvrir un nouveau post pour cette initaition à l'assembleur pour TMS7020 ...

Oui, ce serait mieux car ce n'est pas le sujet d'origine

Pour la routine assembleur de gestion de sprite, j'avais récupéré et testé une API Exlevision (surement celle d'exelement votre). Elle était bien codé, très pro, mais ce n'était pas très flexible, et pas très rapide à cause du basic, même si on gagnait un peu en vitesse, rien était fluide à cause du Basic.

Il vaut mieux faire des sprites en mode texte de toute façon: c'est déjà plus simple aussi. (et du 100% code machine)

Ton soucis sera de comprendre le VDP et la comm avec le VDP, pas l'assembleur. Le bouquin que tu as imprimé est bien mais pas pour le débutant, ce n'est pas une initiation mais un livre de référence technique. Il n'existe pas d'autres sources correctes pour débutant à part la formation de 6502man.

Il faut commencer petit comme on a fait: on teste des affichages texte, ensuite graphique (sideshow)... ensuite on pige vite le truc et c'est parti mon kiki. Mais ne réinvente pas la roue non plus: mes APIs permettent une tonne de truc (pas que de l'affichage) ont été étudiées pour s'occuper de son code métier, sans se prendre la tête avec le reste (comme une base d'affichage texte multi-fenêtrée avec scrolling... et hyper rapide => pratique au début quand on teste des trucs mais qu'on maitrise pas le VDP).

J'utilisais TASM aussi, rien d'autre ne fonctionnait... et TASM était excellent et très paramétrable/customisable pour l'archi Exelvision. Son macro langage me permettait de l'utiliser comme un pseudo lilnker: le code assemblé ne contenait que les routines utiles au programme (avec dépendance) mais les APIs entières.

Tu devrais t’entraîner en développant ta routine de remplissage de box pour ton jeu en fait: je pourrai te filer des ébauches de routines graphiques (qui donnent toutes les astuces pour afficher un simple point), et les pistes pour tracer des lignes (horizontales ça devrait suffire et c'est déjà assez technique) en s'inspirant de l'affichage d'un point.

tout à, fait d'accord avec toi jester

Ton soucis sera de comprendre le VDP et la comm avec le VDP,...

Il faut commencer petit comme on a fait: on teste des affichages texte, ensuite graphique...

Je vais suivre avec assiduité les cours de 6502man.

Je vais bien sûr aller progressivement dans mes petits programmes test, déjà afficher un texte ensuite redéfinir des caractères et ainsi de suite.

Et j'utiliserai enfin des API pour m'aider et gagner du temps.

Bien sûr j’essaierai de faire mes propres routines pour mes jeux et peut être un jeux totalement en assembleur mais là c'est vraiment pas pour tout de suite

Où en est ton projet kikich ?
Le mien est en stand by par manque de temps.

Il n'a pas beaucoup bougé pour le moment, car moins motivé car déçu un peu du résultat. Depuis je suis sur un autre jeux qui lui approche de la fin.

Cool , quel type de jeu ?

Un petit puzzle game inspiré de boulder dash.
Je ferais je pense dans la semaine un post

Malheureusement un jeu à la boulder dash demande beaucoup de réactivité pour obtenir un gameplay agréable, ou même simplement utilisable. Pour avoir développer à l'apoque de nombreux Gros jeux en Basic, je peux t'affirmer que c'est impossible... le résultat sera injouable car entre le moment où le joueur pressera une touche et celui où le résultat sera pris en compte et affiché, il aura déjà pressé une autre touche ou deux... depuis déjà longtemps !

Ton premier jeu était réalisable sur Exl. Simplement il ne faut pas décrire directement en Basic chaque scène, mais lire sous forme de Data la description de chaque scène, et avoir une sorte de petit interpréteur de scène. Ainsi tu peux lire les datas sur K7 par partie (partie 1 du jeu, partie 2 du jeu, etc.)

Pour les jeux réclamant une interaction forte, l'exelbasic n'est pas utilisable en pratique. Même en injectant de l’assembleur ça reste poussif car la boucle de jeu en Basic est extrêmement lente. De plus en exelbasic la scrutation d'une touche se fait par polling, ce qui est gourmand et catastrophique... alors que l'architecture matérielle de l'exl100 traite le clavier sous interruption. A cela il faut ajouter la latence de l'infra-rouge qui est insupportable même en assembleur !!!
Bref, c'est le bordel !

Tout dépend donc si ton puzzle game est très passif ou réclame une bonne réactivité temps réel ?
Il vaut mieux faire des démos sur matos exelvision, comme ça pas de soucis de gameplay, et comme personne ne jouera jamais aux jeux... on a plus de chance d'être vu avec une démo
Franchement si tu veux t'amuser, fonce sur le coté démo... la tu peux sortir de chouette truc et/ou rigolo même en Basic avec qqs routines assembleurs pour aider un peu.
Qui a joué un transylvania version Exl ici... c'est à dire qui a vu autre chose que l'intro ?

Moi Contraint et forcé, pour réaliser les copies d'écrans : http://dcexel.free.fr/programmes/transy ... index.html

Je me demande si une vidéo youtube walktrough/speedrun/longrun n'atttirerait pas quelques nouveaux amateurs pour ce jeu. . .