ASMTI83Probleme de double direct input - Page 1

Bonjour,

Je n'arrive pas à scanner 2 groupes de touches différents avec direct input...

Dans un premier fichier je scanne les flèches :
[code]
ld a,$FF ; Before any action, reset the keyport
out (1),a ; ...by sending to the port 1 the value 255 (FF
ld a,$FE ; select the keyboard group to scan (here the arrow keys)
out (1),a ; ...by sending to the keyboard port (1) the value FE.
in a,(1) ; Get the port value, which says wich keys was pressed
cp 254 ;\
jp z,bot ;|
cp 253 ;| Look for the key which was pressed and jump to the correct label.
jp z,left ;|
cp 251 ;|
jp z,right ;|
cp 247 ;|
jp z,top ;/
[/code]

Jusque là tout marche bien ...

Et dans ma seconde macro, lorsque je fais :
ld a,$FF
out (1),a
ld a,$FD ; ici je n'arrive pas a scanner un autre keyport
out (1),a
in a,(1)
bit 0,a
;cp 254
jp z, drop_bomb
[/code]

Ca ne scanne pas le bouton enter...

Par contre si je mets le meme groupe $FE au lieu de $FD, bah ça marche...
Je ne comprends vraiment pas ce qui empêche de faire marcher ce direct input sachant que a est mis à FF avant et le port est bien reset également... ?!

Quelqu'un a une idée?

Merci d'avance.

Thibault

Hum, en fait c'était un problème de placement de mes appels ...
Aucun rapport avec direct input...

Le deuxième direct input n'était appelé que lorsque le premier avait donné un résultat ... donc il aurait fallu cliquer très vite sur une flèche puis "enter" pour que ça marche...
(Et avec l'émulateur c'est impossible xD).

Bon bah résolu

Désolé pour le dérangement.

Au contraire ça fait un peu vivre le forum

Juste une chose, je serais toi je ferais un "push af" avant le saut et un "pop af" après (si tu veux pouvoir justement appuyer sur plusieurs touches en même temps, pour les directions du moins).

Sinon tu as un projet en asm ?

deeph (./3) :
Juste une chose, je serais toi je ferais un "push af" avant le saut et un "pop af" après (si tu veux pouvoir justement appuyer sur plusieurs touches en même temps, pour les directions du moins).

Tiens je ne savais pas qu'on pouvais faire push af... (ça m'aurait évité de copier a dans hl à chaque fois).

Sinon tu as un projet en asm ?

ouaip
Bah un petit truc, mon premier projet asm
Un petit bomberman pour me faire la main...

Fichier joint : (demo2.gif)

(Ca va moins vite en vrai...)

Mais j'en suis qu'à 50 % pas plus (les bombes n'explosent pas, y a pas d'IA) mais bon vu que j'ai commencé y a quelques jours c'est déjà pas mal je crois


J'ai regardé un peu tes projets, ils sont super jolis, tu as des choses à m'apprendre

Ça a l'air sympa Tu bosses avec les routines d'un shell en particulier ? Ion ?

Sinon la plupart de mes projets sont très peu développés (flemme), et les codes sources sont moches et loin d'être optimisés (mais ça marche ). Mais bon même si je suis pas un expert en asm n'hésite pas à poser des questions

En passant si t'as besoin d'info sur la pile : http://tift.tuxfamily.org/asmpourlesnuls.html et http://tift.tuxfamily.org/wp-content/tuto_v01.pdf

Merci

Je bosse sans shell mais j'utilise quand même des routines d'affichage (qui ne sont liées à rien donc).
J''utilise les routines de "movax" pour le sprite 8x8 mais pour le fond d'écran c'est ma routine perso

Les routines de movax s'appellent DRWSPR et CLRSPR mais je crois qu'elles sont un peu retouchées chez moi.

C'est bizarre dans tes projets tu n'as que très peu de fichiers sources (souvent qu'un seul fichier .z80 je crois), perso j'aime bien séparer les routines pour que ça soit bien clair et plus facile à programmer.
Mais l'esthétique de tes projets est géniale, c'est une merveille (jeu d'avion, la balle qui descend etc...)

En passant si t'as besoin d'info sur la pile : http://tift.tuxfamily.org/asmpourlesnuls.html et http://tift.tuxfamily.org/wp-content/tuto_v01.pdf

Je connais déjà bien ces tutos... (Le second est celui qui va être repris et amélioré )

Merci pour l'info en tout cas.

Tes projets sont quasi releasable pour certains, non?
Enfin ça donne l'impression.

[Défenseur de l'open source que je suis,] voici un lien pour le projet :
[url]https://patch-tag.com/r/contra-sh/z80/snapshot/current/content/pretty [/url]

Thibault

En général je n'ai qu'un seul fichier .z80 (le programme en lui même) et plusieurs .inc (les routines/sprites...).

Quant à mes projets, en général le moteur est pas mal avancé mais plein de bugs. Par exemple dernièrement je me prenais la tête avec la routine pour afficher les bots dans "Street Hero"...

Je me verrais bien continuer le projet de la balle en verre ou le RPG pour zContest (le beat'em all aussi mais ça prendrais plus de temps...).

Un autre petit screenshot avec les bombes qui disparaissent (timer) :

Fichier joint : (bombtimer.gif)



Puis tant qu'à faire en voici un tout neuf :
Fichier joint : (sprite_explose.gif)

Ca se voit pas bien mais y a l'explosion (ça sort mal au screenshot) !!!

Cool

Mais c'est normal que le personnage clignote ?

C'est l'enregistrement des screenshot qui fait ça...
Mais en vrai il clignote pas du tout

Un autre screenshot avec une meilleur gestion de l'explosion (dure plus longtemps) :
Fichier joint : (explose.gif)



edit : je vais peut-être créer un topic pour ce jeu non?

Comme tu veux c'est ton topic

C'est sympa le repository, j'irais jeter un coup d'œil aux sources dès que j'ai le temps

edit : je viens de regarder rapidement, tu utilises des listes pour les coordonnées des bombes ? J'aurai plutôt fait une matrice pour la map (déjà pour la dessiner c'est plus simple je pense), à laquelle j'aurais ajouter directement les bombes et explosions. Ensuite suffit de gérer le déplacement des personnages toujours sur la matrice pour savoir s'ils sont touchés ou pas, etc...

deeph (./12) :
C'est sympa le repository, [...]

Le repo c'est bien pour rendre public et voir les changements d'une version à l'autre mais c'est surtout une garantie de ne pas avoir à faire plein de sauvegardes dans son coin.
Et le plus important à mon avis c'est que je ne code pas en ayant peur de planter ce qu'il y avait avant, puisque je peux revenir à une version antérieure facilement.

edit : je viens de regarder rapidement, tu utilises des listes pour les coordonnées des bombes ? J'aurai plutôt fait une matrice pour la map (déjà pour la dessiner c'est plus simple je pense), à laquelle j'aurais ajouter directement les bombes et explosions. Ensuite suffit de gérer le déplacement des personnages toujours sur la matrice pour savoir s'ils sont touchés ou pas, etc...

Je n'y avais pas pensé, gh m'a parlé de double buffering mais je ne l'ai pas utilisé (dans un projet futur je pense).

A propos du source :
Je ne blit pas tout l'ecran à chaque fois (c'est un choix en partie justifié par le fait que le joueur ne peux pas chevaucher les rocher).
J'efface sous le joueur quand il se déplace puis je l'affiche (d'ou le clignotement sur le screenshot).
J'affiche les bombe à chaque déplacement (je crois).
Une liste pour les x, une liste pour les y, et une liste pour le timer, lorsque x ou y ou timer sont à 0 ça signifie qu'il ne faut pas afficher.
Le timer est décrémenté à chaque tour, si on est à 10, on affiche l'explosion, si on est à 1 la bombe disparait.
La encore si le joueur est sur la bombe il meurt donc pas de probleme de superposition.
J'ai imaginé me servir du graphbuffer pas simplement comme buffer d'affichage mais aussi pour tester des pixels éteints ou pas, mais finalement je ne l'ai pas fait.
J'utilise une grosse matrice de la taille de l'écran pour le fond (pas de tilemap). Je sais c'est mal


Comment fais-tu pour utiliser une matrice.
2 hypothèses me viennent à l'idée :
- Une case de la matrice correspond à un emplacement 8x8 donc on a du mal à gérer le déplacement s'il ne sont pas alignés sur une case non?
- Ou alors tu utilises 1 octet par pixel (ce qui permet d'attribuer une valeur différente si c'est le coin haut-gauche d'un sprite bombe, sprite bonhomme, sprite rocher etc...) mais la ça fait gros en mémoire

Tu parcours toute la matrice à chaque fois pour savoir ou il y a une bombe?
Bref c'est pas bien clair si tu as 2 min pour m'expliquer ton idée...

Autre chose ; concernant le double buffering, y a t il un emplacement pour ces buffers (je suis quasi sur que non).
Et comment gérer ça (j'imagine avec un pointeur sur l'élément courant et un decalage avec le registre ix par exemple) ?
Ca ferait donc 3 buffers avec le graphe buffer (un pour le premier plan, un pour le fond et enfin le graph buffer) ?

Je vais créer un autre topic dès que j'ai 5 min


Thibault

En gros à la base tu as une matrice qui représente ta carte (donc 10*7 ici), tu mets par exemple 1 pour un truc non franchissable puis ce que tu veux pour une bombe/explosion.

Le joueur à une position x et y relative à l'écran j'imagine (donc entre 0 et 96 pour x et 0 et 64 pour y si je me souviens bien), donc t'as juste à la diviser par 8 (cf http://progg.free.fr/z80/ par exemple) puis à arrondir pour avoir une coordonnée comparable avec la matrice. En fonction de ça tu vois bien si là ou il veut aller c'est traversable ou non, si ça a pété etc... De même quand une bombe pète tu vérifies sur la matrice si un joueur est dans la zone d'impact.

Enfin ceci dit je pense que ce serait plus simple que tu gères les déplacements "par tiles" au lieu de pixel par pixel, quitte à rajouter une animation de transition entre chaque tiles pour que ce soit moins moche.

Quant aux buffers, c'est à toi de décider de leur adresse, ça ça dépend que de ta routine d'affichage... D'ailleurs c'est souvent plus pratique de travailler avec un buffer plus grand que l'écran (pour le scrolling par exemple).

Enfin ceci dit je pense que ce serait plus simple que tu gères les déplacements "par tiles

??
La j'efface un sprite entier puis je l'affiche à coté... C'est quoi tiles ?

donc t'as juste à la diviser par 8 (cf http://progg.free.fr/z80/ par exemple) puis à arrondir pour avoir une coordonnée comparable avec la matrice

Par contre avec cette methode tu es bloqué si tu veux gérer des morceaux plus petits que des bloc de 8*8?
Parce que avec l'arrondi tout ce qui va de x modulo 8 = 0 à x modulo 8 = 7 subit le même traitement...

avec un buffer plus grand que l'écran (pour le scrolling par exemple).

Oui le scrolling il faudra que je m'y mette (prochain projet?!). ^^

Un tiles c'est une "brique" qu'on utilise pour le mapping : http://en.wikipedia.org/wiki/Tile-based_video_game#Tile_set

En gros ça signifie que les mouvements de ton sprites se font d'un tile à un autre (donc par 8 pixels).

'fin après c'est sûr que si tu veux faire des objets plus petits que 8 et avoir obligatoirement un déplacement fluide c'est inutile d'utiliser cette méthode.

En fait j'aurais très bien pu utiliser une matrice comme tu l'as expliqué dans ce mon projet.
Car en fait il n'y a pas besoin de gérer plus petit que des cases 8x8.
Ca aurait bien simplifié les choses d'ailleurs.

Si j'ai bien compris une tile consiste à mettre plusieurs sprites à la suite et naviguer de la premiere jusqu'à la dernière (en decalant de la taille d'un tile) pour faire animer un personnage.

Je vais essayer d'améliorer les mouvement du bomberman dès que j'ai fait l'IA.

Merci pour ton aide en tout cas.

Oui voilà c'est le principe en gros

Sinon pour l'IA y'a un article qui explique rapidement les algorithmes (ça vient d'un projet 68k) : http://www.tigen.org/jyaif/Article/Bomberdude_ai.htm , par contre sans matrice ça doit être beaucoup plus dur à gérer.

Merci pour le lien c'est vraiment génial.

En C ça a l'air plus facile ^^

Je ne pourrai pas implémenter un bot aussi malin sans une grosse refonte du coeur du programme.
Je vais utiliser ta méthode des matrices et automatiser le déplacement d'un emplacement d'une case 8x8 à une autre case 8x8 avec tiles.
Exactement comme tu me l'as expliqué...

Comme le fait julien Solignac dans bomberkid (sauf qu'il s'agit de bloc 4x4 je crois).

Ne pas passer dans une boucle pour chaque deplacement d'un pixel va me faire gagner du temps.
Ca sera aussi plus joli/fluide et finalement il n'y a pas de raison qu'on puisse stagner sur des cases non alignées (inutile).
Du coup, plus besoin de calculer l'emplacement aligné pour poser une bombe comme je fais actuellement (puisqu'on sera forcement bien positionné).

Et gérer sous forme de matrice va m'optimiser à fond le truc (surtout pour l'IA) car là avec seulement un fantome qui ne pose pas de bombe ça comment à ralentir (il faudrait déjà optimiser) .

Sur vrai calc ça marche pas trop mal
héhé

J'ai hâte de voir le résultat

Merci "yapluka"... ^^