1

Yop tlm! Bon promis, apres ce post je me calme smile gol

En fait voilà, J'ai compris récemment comment marchait l'instruction RC_COPY.
Cependant, j'ai compris comment elle marchait lorsqu'elle va chercher un bloc d'image sur l'écran logique pour le passer sur l'écran physique.

Mais admettons que je veuille construire un semblant de Sprite (vraiment primitif smile ) avec [pbox x1,y1,x2,y2] (Pour.... une raquette dans un Pong par exemple grin ).

Comment puis-je faire pour dessiner pbox sur l'écran logique et pas sur le physique (afin de l'envoyer sur le physique à coups de RC_COPY) ??

Pourquoi cette question?
Parce que mon début de Pong me semble en fait à refaire :
Pour faire mouvoir la raquette, j'utilise :

choix&=inp(2)
select choix
case gauche..
x1 et x2 vers la gauche
case droite..
x1 et x2 vers la droite
endselect
CLS
Pbox x1,y1,x2,y2

Et tout ca tourne dans une boucle REPEAT UNTIL jusqu'à ce que F10 soit pressé.
(Je ne sais plus si le code est exactement comme ca, je vous l'écris de mémoire)

En fait, cette technique est fort genante pour les yeux (Clignotement du au CLS). J'ai essayé VSYNC mais ne connaissant pas vraiment, j'ai oublie cette insctruction en voyant que ca ne marche pas.

En résumé, La question importante est :

Comment puis-je utiliser RC_COPY avec l'instrution PBOX? Comment "dessiner" ou même écrire directement sur l'écran logique afin de transferer plus tard sur ecran physique??

Voilaaaaaa
Le supplice est terminé smile
J'espere que tout ce texte ne sera pas trop rébarbatif...
Merci d'avance à ceux qui auront le courage de lire jusque là smile

2

Les sorties graphiques telle que box, pbox, circle etc... ne se font que sur l'écran physique si je ne me trompes pas, c'est pour cela que dvp des jeux d'action sous Gem c'est un peu casse gueule.

Dessine plutot sous un prog de dessin et recopie plutot de ton image en mémoire sur l'écran logique avec Rc_copy et voila un probleme de règlé.

Ou tu dessine ta boite sur l'écran physique tu la recopie quelque part en mémoire et après tu recopie de ce bout de ram sur l'écran logique.

Cooper tu dois te souvenir, je suis pas sur j'ai je crois que l'inp(2) attend physiquement une touche, cela veut dire que tant qu'on a pas pressé une touche, le reste du prog est bloqué, ce qui veut dire que pour les méchants ou autres objets il ne bougeront pas tant qu'une touche est pressé, je suis pas sur d'ou mon appel a l'aide a Cooper ou toute personne utilisant le Gfa plus souvent que moi.

Utilises plutot inkey$

a$=inkey$

par exemple après dans a$ tu la touche pressé, exemple :

if a$="4"
goto gauche
endif

ou cela marche aussi avec le select

select a$
case "A"
endselect

Théoriquement en cas d'utilisation de deux écrans tu devrais avoir un semblant de code ressemblant a cela :

do
swap physic%,logic%
void xbios (5,ltonguehysic%,l:logic%,w:-1)
vsync
cls

; ici tu affiches tes sprites
; et tu fais ce que tu veux

loop

Voili, voila j'espère que cela t'aidera.

a +

GT Turbo (octopus)
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

3

Voici un bout de code qui ne scintille pas l'ecran...

~XBIOS(5,L:-1,L:-1,0)
e2$=SPACE$(32000)
e3$=SPACE$(32000)
e2%=V:e2$
e3%=V:e3$
CLS
BMOVE XBIOS(3),e2%,32000
BMOVE XBIOS(3),e3%,32000
~XBIOS(5,L:e3%,L:e2%,W:-1)
DO
  CLS
  !...
  ! RC_COPY sur l'ecran e3%
  ! ...
  ~XBIOS(5,L:e3%,L:e2%,W:-1)
  VSYNC
  SWAP e2%,e3%
LOOP UNTIL PEEK(&HFFFFFC02)=57
~XBIOS(5,L:e2%,L:e2%,W:0)
EDIT

4

bien vu GT, INP(2) attend qu'une touche soit pressée pour continuer. Comme tu l'as dis, on peut utiliser INKEY$. Il y a une autre solution, un peu plus rock'n'roll (mais normalement un peu plus rapide), c'est d'utiliser un PEEK des familles.

key&=PEEK(&HFFFC02)

Par contre il retourne un SCANCODE (a=10, z=11, e=12) au lieu d'un code ASCII (a=65, b=66, c=67)

Donc il vaut peut être mieux tester auparavant le resultat de la pression de telle ou telle touche avec une boucle :

DO
key&=peek(&hfffc02)
exit if key&=1 ! si c'est ESC on fait cassos
print key&
LOOP

Bon courage, en esperant que ça t'aide aussi smile

5

'INP(2) ! Renvoie le code ASCII de la touche pressée (bloque le programme)
'INP(-2) ! Renvoie si une touche est pressée (ne bloque pas le programme)
'
REPEAT
UNTIL INP(-2)=TRUE
'
KEY|=INP(2)
PRINT KEY|



EN termes de performances, je ne sait pas si c'est le meilleur choix, mais ça fonctionne wink

6

je connaissais pas le coup du -2 ! Merci pour l'info Coldfire smile

7

C'est valable pour toutes les sorties en INP :

Valeur positive : lire la sortie
Valeur négative : savoir si un octet est présent sur la sortie




Coldfire wink

Edit : Je dit sortie, mais c'est plutôt entrée grin

8

Glop glop merci! Je vais pouvoir tester toutes ces idées!
'
Ayant encore un peu de mal avec le chargement d'image ds le prog (C'est con mais j'ai pas envie d'utiliser une procédure déjà faite, j'aimerais vraiment bien comprendre le fond du truc donc pour l'instant, je trifouille, farfouille et refouille les différentes instructions smile ).
'
Je vous donne des nouvelles des ke ca avance smile

9

Glop glop!!

Du nouveau! Le jeu à bien avancé! La raquette du joueur se déplace maintenant grâce à la souris. La balle bouge toute seule et rebondit sur les raquette et sur les bords (J'ai pas encore programmé le fait de perdre) et l'adversaire, contrôlé par le prog se déplace en fonction de la balle (ok ok, l'adversaire ne peut po perdre lol).

En gros la grosse partie du prog' est finie. Cependant, j'ai fait des tests avec void xbios (5, ......) mais les différents tests que j'ai effectué ont fait planter le prog'.

(Ah oui! Et comme la touche Alternate de mon clavier marche pas, je suis obligé de redémarrer à chak fois k'un prog' plantouille ou entre dans une boucle infinie).

Donc pour l'instant, le clignotement est... insupportable! Surtout que la raquette du joueur et celle de l'adversaire ne clignotent pas en même temps alors c'est encore pire!

A remarquer, l'instruction VSYNC permet à la balle de ne pas scintiller mais le reste clignote encore plus alors pour l'instant je l'ai enlevé.

Voila ou j'en suis.
Je vous enverrais bien le fichier GFA mais là j'ai pas le temps. Des que je peux, je vous l'envoie!

10

Balance le fichier on va te règlé ton probleme de scintillement sans soucis.

Je sais pas si tu connais, mais en cas d'erreur tu peux faire appellé une routine perso, cela permet de reprendre la main en cas de plantage, faut faire comme cela :

on error gosub quand_ca_plante ! a mettre au tout début du code



*tu mets ce que tu veux ici*


procedure quand_ca_plante
edit ! permet de revenir au gfa
return



GT Turbo octopus
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

11

AAAAAAH!!!

Alors "EDIT" Sert à ça!!
*l'illumination*
Ok!

Bon, voici le fichier GFA :http://membres.lycos.fr/narky76/instpong.gfa

J'espere que le lien marche chez vous (Oui, c'est le bon lien, c'est juste que l'ordi avec lequel je vais sur le net est incapable de lire correctement un lien... mad mur

12

Apparement marche pas ton lien, si tu peux envoie le direct ici :

gt-turbo -at- cerebral-vortex.net



GT Turbo octopus
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

13

Glop glop, je te l'ai envoyé. Mais là franchement, je vois pas pourquoi le lien marche pas...
'
Zarb'...

14

J'ai le fichier, je regardes cela le plus tot possible et te le renvois direct dans la foulée !!

GT octopus
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

15

Glop glop merci
'
De mon côté, je vais essayer de comprendre ce $ù^5-^$ù de lien qui marche pas.

16

Narky :
En résumé, La question importante est :

Comment puis-je utiliser RC_COPY avec l'instrution PBOX? Comment "dessiner" ou même écrire directement sur l'écran logique afin de transferer plus tard sur ecran physique??


Pourquoi n'utilises-tu pas les instructions BMOVE, PUT et GET ?
A moins que ton jeu ne tourne que sous GEM ?
avatarSite perso : http://strider.untergrund.net/
Atari STF / STe / Mega STE / Falcon030 / Falcon CT60

17

StriderPourquoi n'utilises-tu pas les instructions BMOVE, PUT et GET ?
A moins que ton jeu ne tourne que sous GEM ?

censure !!!! même un RC_COPY is forbidden pour du GEM, ça ne passe plus dans autre chose qu'une résolution TT.
RC_COPY est plus rapide qu'un PUT/GET, mais plus lent qu'un BMOVE.

18

Le probleme avec le bmove, c'est vrai qu'il est très rapide, mais faut commencé a sortir la calculatrice pour calculé les valeurs, et pour un sprite de taille normale, cela va se finir par un massacre car il faudrait faire un bmove par ligne et pour recopié des sprites genre 16*16, j'ose pas y pensé !!

Le bmove est plutot a utilisé pour copié de gros bloc d'un coup ou des lignes completes


GT Pour le RC_copy !! oui
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

19

GT pour le vro_cpyfm (couleur) et pour vrt_cpyfm (duochrome et masques) grin
Avec NVDI, c'est rapide et ça passe partout wink

20

Strider > Parce que j'ai testé RC_copy et get/put et entre les deux, je préfere utiliser rc_copy..
Pourquoi, je sais pas, y'a des fois comme ça grin

21

Rajah Lone :
censure !!!! même un RC_COPY is forbidden pour du GEM, ça ne passe plus dans autre chose qu'une résolution TT.
RC_COPY est plus rapide qu'un PUT/GET, mais plus lent qu'un BMOVE.


Ah bon, j'avais fait des tests sur de petits sprites sur Falcon, il me semblait que PUT/GET était plus rapide que RC_COPY wink
avatarSite perso : http://strider.untergrund.net/
Atari STF / STe / Mega STE / Falcon030 / Falcon CT60

22

Strider
:
Rajah Lone :
censure !!!! même un RC_COPY is forbidden pour du GEM, ça ne passe plus dans autre chose qu'une résolution TT.
RC_COPY est plus rapide qu'un PUT/GET, mais plus lent qu'un BMOVE.


Ah bon, j'avais fait des tests sur de petits sprites sur Falcon, il me semblait que PUT/GET était plus rapide que RC_COPY wink


La question est a tu fait les essais sur la meme machine ? Car sinon a cause du blitter !!

GT En train d'affiché des sprites !! oui
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

23

J'ai fait mes tests sur Falcon 16 MHz, j'aurais du tester sur ST/STE... smile
avatarSite perso : http://strider.untergrund.net/
Atari STF / STe / Mega STE / Falcon030 / Falcon CT60

24

Tiens d'ailleurs! (En esperant ne pas trop m'écarter du sujet mais apparement non grin)

C'est quoi exactement ce "blitter" dont tout le monde parle?
Dans le menu options du bureau, je l'ai "activé" mais je sais pas trop ce que c'est en fait...
Si quelqu'un pouvait éclairer ma lanterne smile

25

Le blitter est une puce bien sympa qui est la pour facilité / accéléré certains traitements de copie de bloc, si il est activé rc_copy en tire profit car il utilise cette puce au lieu de copié de façon soft.


GT Pour le blitter !!
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

26

Ok!!

Je me doutais ke le blitter avait un rapport avec l'affichage mais je croyais ke c'était un processus software..
Bon beh je m'endormirais moins con ce soir smile

*Narky compte les puces*

27

Et il est désactivable car certains jeux conçus pour le STF refusent de fonctionner si le bliter est activé.

28

ColdFire :
Et il est désactivable car certains jeux conçus pour le STF refusent de fonctionner si le bliter est activé.


Lequels ? Je suis curieux, car en général les jeux utilisent des routines perso pour l'affichage donc le blitter ne change rien du tout, a moins que ces jeux utilisent le gem pour les copies de bloc, d'ou leur vitesse !!!!! eek


GT Curieux oui
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !

29

Bon, autant pour moi, j'ai dit jeux, j'aurait du dire programmes grin




ColdFire, l'Atariste non spécialiste triso

30

smile