Bonjour à tous

Dans mon projet de jeu RUGEN, j'aimerai avoir un personnage dans un SPRITE pour que cela n'efface pas le fond de l'écran.

J'ai lu beaucoup d'articles sur les SPRITEs, j'ai chargé le logiciel SPRITE-ALIVE ... très difficile tout cela pour un novice

Je ne ferai pas de SPRITE, sauf si je trouve une piste pour démarrer, donc je ferai un personnage sur 3 cases de haut et 2 de large avec des caractères redéfinis par la commande "SYMBOL", comme dans le jeu SABOTEUR (personnage noir sur fond coloré).

Si quelqu'un aurait un lien vers une page simple qui expliquerait à un novice comment faire un SPRITE en BASIC , merci par avance

Mon personnage de 48 pixels de haut (3 cases en mode 1) serait en gros comme cela :

Impossible de faire ca en basic, un faut une routine en assembleur

Glup's

Je ne connais rien du tout en assembleur, alors me lancer à mon âge ... (45)

J'ai trouvé ce code pour faire de "faux sprites" en Basic :



La première ligne active le mode transparent pour afficher des caractères en ayant le tour du caractère qui est transparent et qui donc n'efface pas les motifs du fond de l'écran.

La 2e ligne remet les caractères en mode normal (non transparent).

Avec la commande SYMBOL je pense redéfinir quelques caractères (18 pour 3 sprites de 6 caractères) un peu comme dans le jeu Saboteur, car il semble qu'il soit fait ainsi lorsqu'on voit le déplacement du personnage.

Après le passage de mon personnage, le fond devra être reconstruit mais se sera du case par case (caractères CHR$).

Je ne vois que cette méthode à mon niveau

Et je ne sais pas combien de mémoire prend des sprites et la programmation qui va autour (et à quelle adresse mémoire tout cela se met.

J'aurai une image de 16 ko (CARTE.SCR) qui sera déjà dans un coin, puis des tonnes de variables pour les dialogues déclenchés ou non avec les 18 personnages déjà rencontrés ou non, les quêtes validées ou non, les villes visitables ... Bref, je ne sais pas si tout va rentrer dans la Ram

Quelle est la taille maxi d'un programme en Basic déjà ?

Ram du CPC 6128 : 128 ko dont seulement 64 ko accessibles, et en plus ces 64 ko ne sont apparemment pas uniquement pour le programme que je tape.

Quelqu'un saurait combien de Ram est accessible pour les besoins d'un jeu ?
- Ram image pour ma carte mise de côté = 16 ko.
- Ram pour les sprites ? 16 ko aussi ??
- Ram pour le programme Basic qui tourne ? pas que 16 ko tout de même ? on peut bien aller aux 32 ko pour le Basic ?

Merci

Salut

Place dispo pour ton prog basic pour le moment tu as de &170 a &4000 =&3e90 (16k)
après tu as ton image, de &4000 a &8000 elle pourrait etre placee en &6000
comme ça tu gagnerais encore &2000 pour ton fichier basic. S'il te faut encore
plus de place tu peux placer ton image dans une ram comme ça tu gagnes
encore &4000, mais ton jeu ne tourneras plus sur un 464 non muni d'extention memoire.

Ok, merci !

16 ko ... trop léger, je vais les atteindre à coup sûr.

Pour placer l'image de 16ko en &6000, le code est beaucoup à modifier ?

Et oui je préfère que ça tourne aussi sur CPC 464 pour qu'un maximum de monde puisse y jouer

Sinon, en ce moment, je stagne complet, le Gotek en lecteur B ça ne marche que 1 fois sur 10, et même les SAVE enregistrent des fichiers modifiés aléatoirement (avec symbols bizarres). J'ai commandé un adaptateur pour mettre le Gotek en lecteur A interne, on verra si c'est mieux. Je suis bien déçu, je rame depuis 5 semaines avec ce Gotek.

Bonsoir à tous,

Je reviens sur mes "sprites" pour mon jeu Rugen.

Grâce à Velus j'ai déjà 24 Ko de place mémoire (au lieu de 16) en ayant mis l'image de ma carte en &6000.

Je suis en train de redéfinir des caractères pour construire mon personnage en 6 cases en mode 1 (3 de haut x 2 de large) :


(sur cette image c'est marqué 48 pixels de haut, mais en mode 1 = 3x8 = 24 pix).

J'ai créé toutes les images de mon personnage qui se déplace et tire vers la droite.

Mais, dois-je redéfinir d'autres caractères pour créer mon personnage qui va à gauche ?

Peut-on dire au CPC : "Fais-moi les mes mêmes caractères mais inversés !" ??

Si cela existe, quelle est la commande en basic qui inverse un caractère ? (horizontalement)

Merci par avance

Ca n'existe pas, faut dessiner toutes les positions
Il faut que tu inverses les bits de ton chr. En binaire c'est pas compliqué mais en basic
je sais pas s'il y a moyen de trouver une astuce, ca me parait fort compliqué !

Zut

Bon, eh bien c'est parti.

Pas trop dur car en général j'utilise :
SYMBOL 255,&c00000000,&x11111111, ...

chaque ligne de 8 pixels n'est que des 0 et des 1

Mais cela fait 2 fois plus de lignes, cela prend de la place dans mon programme, donc je vais faire cette redéfinition des caractères dans le programme qui est chargé au départ (l'accueil) puis lorsque le jeu se chargera ces caractères resteront modifié mais les lignes de SYMBOL 255,&x.... n'y seront plus (Premier fichier ne contient que la page d'accueil, puis le 2e fichier c'est le jeu en lui-même).

il suffit de sauver tes symbols en un fichier binaire. Si tu as fait symbol after 32 tes chrs
doivent se trouver vers &a000 jusque &a700 quelque chose comme ça. Tu lances ton basic
et tu sauves. Save"chr",b,&a000,&700

10 symbol after 32
20 load"chr"

youpie c'est bon tes chr sont devenus un fichier binaire

Ok, mais comme les lignes qui redéfinissent mes caractères CHR$ seront dans le premier programme (l'intro), lorsque le 2e programme sera lancé (RUN"RUGEN2") le premier programme ne sera plus dans la RAM donc mes lignes qui redéfinissent mes caractères ne l'encombreront plus

Et ce n'est pas rien car il faut dans les 4 à 5 ko pour redéfinir les 48 caractères qui représentent mon personnage dans 8 situations (personnage de 6 cases = 3x2).

J'aurai aussi au moins un "méchant" de la même taille que mon personnage, donc potentiellement au moins 36 caractères encore.

Donc je vais avoir à taper : SYMBOL [numéro du CHR$],...,...,...,...,...,...,...,... 84 fois

Le mieux tu utilise un petite routine assembleur XOR du genre

org &a000
ld hl,(&9ffc) ; charge l'adresse saisie en basic
ld de,(&9FFE) ; charge l'adresse ecran chosie pour l'affichage
ld b,7 ;
CONT
ld a,(de) ; l'accumulateur A contient le contenu de l'adresse pointée par DE voir prog Basic
xor (hl) ; on xor avec le contenu de l'adresse pointée par HL (ici la valeur &FF voir prog Basic)
ld (hl),a ; on charge l'adresse pointée par HL avec le contenu de l'accumulateur A
inc de ; increment DE
inc hl ;increment HL
djnz cont ; DJNZ decremente B et continue tant que B n'est à 0. donc ici on remonte àCONT tant que B est différent de 0.
ret; et on se casse de la routine




associé au prog Basic:

10 mode 2
20 j=1
30 for i=0 to 7
40 poke &a050+i,&ff -met &FF dans &a050+I 8 fois adresse &a050 choisie au pif
50 next i
60 poke &9ffe,&50 - l'assembleur va récupérer ces adresses &a050 et &c000
70 poke &9fff,&a0
80 poke &9ffc,&0
90 poke &9ffd,&c0
100 call &a000 - appel de la routine
110 call &bb06 - on attend une touche
120 j=j-1
130 if j=0 goto 60


j'ai essayé de faire simple...
tu mets tout ça dans winape et tu essayes.

Si tu comprends tout tu peux agrementer la routine assembleur pour qu'en un seul appel de &a000 tu affiche un sprite complet.
Pour ça je verrais bien la routine de Richard Fairhurst (sur le site) qui retourne le ligne de l'écran qui se trouve sous la ligne actuelle le tout dans HL

.nline ld a,8
add h
ld h,a
and 64
ret nz
ld bc,16304
sbc hl,bc
ret

autrement dit si HL contient &c000 (première ligne écran) après la routine HL contiendra &c800 (seconde ligne écran) quelque soit le position sur l'écran.

bon c'est sur ça se complique un peu mais je pense que c'est une bonne solution pour avoir un affichage rapide tout en gardant un programme Basic.

Merci SPeCTRo

Si j'ai bien compris, c'est une image .SCR de 17 ko qui contiendrait tous mes sprites et les commandes en langage machine iraient chercher chaque bout de cette image qui correspondraient chacun à un de mes sprites ?

Trop compliqué pour moi je pense

Oui tu peux définir une image qui contient tout tes sprites, par exemple sotckée en &4000, et aller les coller dans la mémoire écran en &c000. Tu peux même en stocker une ne bank mémoire et en fonction des ambiances tu switchs entre les deux bank en &4000 (exemple un jeu en été/hiver et tu change tes sprites ou fond d'écran etc...)
Cherche de la doc pour essayer de mieux comprendre comment cela fonctionne.
Il y en a plein sur ce site mais également ailleurs...

un livre à posséder absolument
http://amstrad.eu/uploads/fichiers/ftp_ ... d_vol1.pdf

et sa suite plus spécialement dédié au système disque des cpc6128 et 664.
http://amstrad.eu/uploads/fichiers/ftp_ ... d_vol2.pdf


Et surtout le site quasar avec pleins d'informations sur les CPC et leurs petits secrets....
http://quasar.cpcscene.net/doku.php?id=sommaire

Merci , je vais lire tout cela.

normalement ton sprite du personnage, ne devrait pas prendre au temps de place en memoire une fois redefini

si comme tu dit ton personnage fait 3X2 donc 6 cases, donc 6 caracteres pour une position

et 6X8 = 48 caracteres pour 8 positions

pour une position, ca prend reellement en memoire que 3X8X2 soit 48 Octects

donc pour 8 Positions ca te fait que 48X8 = 384 Octects

on est loin de tres 3-4 Ko necessaire pour ton personnage

ce qui te prend de la place justement ces toutes ces lignes de SYMBOL, que le BASIC doit interprété

cependant tu sera quand meme obliger de taper au moins une fois, toutes tes lignes de SYMBOL pour redefinir tes caracteres

et apres comme dit VELUS, de regarder ou se trouve reellement en memoire tes caractere redefinis, et de sauvegarder cette zone en binaire

tu gagnera un max de place, et de temps, et pour l'affichage tu pourra toujours utilisé la commande PRINT chr$

le caractere 33 commence en memoire en #a004