CPC Rulez
https://cpcrulez.fr/forum/

questions en vrac
https://cpcrulez.fr/forum/viewtopic.php?f=4&t=3450
Page 1 sur 2

Auteur :  fano [ 11 Fév 2009, 20:09 ]
Sujet du message :  Re: questions en vrac

Bon ben ça avance tout doucement mais je bloque sur un truc : le cyclage des adresses avec le scroll hard.
Avec certaines lignes, quand l'offset passe une certaine limite, mes points sont décalés, ça surement à voir le fait que ma configuration CRTC ne prend pas entièrement les 16K (48*21 donc 256 octets en rab) mais je ne trouve pas de solution à ce problème.
Ca fait trois jours que je me creuse la tête et que je frotte les cheveux qu'il me reste mais je trouve pas, à l'aide !

Auteur :  Megachur [ 12 Fév 2009, 07:30 ]
Sujet du message :  Re: questions en vrac

si je comprends bien ta question :

exemple avec un écran en mém &c000

tu codes le CRTC avec reg 12 et 13 -> &3000

et quand tu reviens (suite au scroll hard) à &3xxx après un certains temps tes sprites en mémoire (&cxxx) sont décalés ?!

montre nous ton code qui calcule l'adresse en mémoire du sprite, on t'aidera à identifier où tu dois placer des contrôles pour voir si tu es bon !

Auteur :  fano [ 12 Fév 2009, 20:00 ]
Sujet du message :  Re: questions en vrac

Oui, c'est grooso modo ça, j'utilise des objets de 1*2 pixels pour représenter les projectiles mais au bout d'un moment (offset>#300) mes points ne sont plus correctement placés.

Bah, en fait j'utilise une table avec les offsets pour y puis j'y additionne x et enfin je finis par cycler avec un simple OR (screen_adr=#C0) sachant que (SCROLL_scrOffset) est le double de l'offset CRTC :

Code :
ld DE,(SCROLL_scrOffset)
add HL,DE   
ld A,H      
or  screen_adr   
ld H,A


Pour l'alimentation du scroll c'est la même chose mais sans table sachant que j'utilise des blocs de la taille d'un caractère CRTC donc l'adresse de base est rapide a calculer.
Je me doutais bien quelque par que mon approche devait être trop simpliste.Sinon, voilà le code complet du calcul d'adresse :

Code :
;skip status
inc L  ;+1
;get xpos in (PROJ_xPos) and convert in byte/pixel offset
ld A,(SCROLL_pixOffset)
neg         
add A,(HL)      ;sub pix offset to x
or A          ;clean carry
rra           ;divide per 2, parity bit in carry
ld E,A        ;store in E
ld A,%01010101
jr c,not_pair_pixel   
rla         ;shift on left (carry is supposed to be NULL)
.not_pair_pixel
ex AF,AF'      ;keep pixel in AF'

xor A
ld D,A

push DE         ;save DE

;get ypos in (PROJ_yPos) and convert to line address

inc L       ;decimal of PROJ_xPos   +2
inc L       ;PROJ_yPos      +3
ld L,(HL)   
ld H,A      ;00ypos in HL
ld E,A      
ld D,scr_table_high  ;scr_table in DE

add HL,HL   ;multiply ypos by 2
add HL,DE   ;HL points to line offset

ld E,(HL)
inc HL
ld D,(HL)   ;get offset
;ex DE,HL   ;put in HL

pop HL
add HL,DE   ;add to x offset

ld DE,(SCROLL_scrOffset)
add HL,DE   ;so we get offset from real screen

ld A,H      ;MOD it !
;and #3F   ;add if screen_adr is not #C0
or  screen_adr   ;start of the screen high
ld H,A


PS : excellent le tableau des timings de chez grim au fait :D , me suis fait un petit prog raster pour completer ceux qui manquent.
PS2: la rupture sur +, c trop top , un jeu d'enfant, pour peu on en mettrait partout :mdr:

Auteur :  Megachur [ 12 Fév 2009, 21:33 ]
Sujet du message :  Re: questions en vrac

je n'ai pas trop le temps d'analyse ce code en détail ce soir,
mais quelques remarques rapides :

si on prend un screen de &50 de large

&c000 -> &c050
...
&f800 -> &f850
...
&c0f0-> &c1e0
...
&f8f0 -> &f8e0

si tu fais des "inc l" pour positionner ton sprite au bon x, tu vas faire &c0f0 + 1 +1 +1 +1 -> et tu vas obtenir &c0ff -> &c000 !!!

autre remarque généralement quand on fait un scroll horizontal, on fait

admettons qu'on envoi &3000 au départ (screen en &c000) au crtc (reg 12 et 13)

on fait

screen_address
ld hl,&3000
inc hl ; scroll deux octets
ld a,h
and &33
ld h,a

et pas un "or &33" ! le and &33 fait en sorte que dès que HL est supérieur à &33 (110011 en binaire), ex h = &34 (110100 en binaire)
110100 and 110011 ça fait 110000 (=&30)
si tu fais un or
110100 or 110011 ça fait 110111 (=&37 !!!)

j'espère que cela pourra t'aider !

Auteur :  fano [ 13 Fév 2009, 07:38 ]
Sujet du message :  Re: questions en vrac

Je commence tout juste à entrevoir le problème mais y'a t'il une règle particulière ou est ce juste une série d'exceptions ?
Sachant que l'offset est de 2K, le problème est susceptible de se produire sur la dernière ligne de chaque caractère CRTC ou mon raisonnement n'est pas bon ?

En fait le inc L, c'est simplement parce que la structure utilisée pour le projectile est de 16octets et que l'adresse de départ de la table est alignée sur 256octets, c'était juste pour économiser 1NOP à chaque inc.

Pour le OR, pas de problème.Le OR #C0 sert simplement à mettre les bits 7 et 6 de H à 1, du coup ça fait cycler sur #4000 à l'adresse #C000.C'était la solution qui me semblait la plus simple (et économe lol).
Mon code pour l'offset CRTC est celui-ci en fait :
Code :
ld HL,(SCROLL_crtcOffset)
inc HL
ld A,H
and 3
ld H,A

ld (SCROLL_crtcOffset),HL
add HL,HL
ld (SCROLL_scrOffset),HL

Auteur :  Longshot [ 13 Fév 2009, 14:30 ]
Sujet du message :  Re: questions en vrac

Ce qu'explique Megachur, c'est qu'il faut que tu gères le cyclage de ram.
Le calcul que tu as fait correspond à ça :
TabOffsetY[Sprite.Y] + Sprite.X/2 + OffsetVideo (si j'ai suivi :sweatingbullets: )

Je ne comprends pas ce que vient foutre ce truc dans le calcul...
ld A,(SCROLL_pixOffset)
neg
add A,(HL) ;sub pix offset to x


On considère que l'offset évolue de 000 à 7FF inlassablement
Normalement, on devrait calculer la position x et y relative à cet offset en considérant qu'il est le point zéro (donc en ajoutant x/2 et en ajoutant (y/8 x sizx) + (y mod 8) x 2048))

Tu as "réglé" le prob du calcul de y en créant une table
Mais le fait d'intégrer le bloc (y mod 8) dans ce calcul est pervers car cela ne permet plus de gérer le cyclage simplement car les débordements provoquent des changements de bloc.

En effet, imaginons que nous ayons des lignes de #50 octets et que soyons à la ligne 193...
Ta table d'offset va nous donner #CF80 (24 x 80 + 2048) (donc adresse entre #C800 et #CFFF)
Admettons que notre offset soit arrivé à #7FE (offset crtc #3FF). Soit 2 octets avant 0000.
(on doit donc obtenir une position 2 octets avant #CF80, en #CF7E)
#7FE + #CF80 nous donne #D77E alors que nous devrions encore être entre #C800 et #CFFF

Il faut isoler la partie numérique "bloc" de la partie numérique "offset cyclage".
On ne cycle pas sur les blocs.
En gros c'est comme si tu faisais un calcul "modulo" sur 11 bits sans devoir toucher aux 5 autres bits qui déterminent le bloc et la page.
Or ton calcul provoque allègrement des débordements sur les 5 bits. On change ainsi de bloc, voire de page.

Bref, tu dois isoler les 5 bits de l'offset que tu sors de ta table Y et les garder sous le coude en virant les 3 bits faibles
Avec les 11 bits restants, tu les additionnes à ton offset écran, puis x / 2
Tu ramènes ensuite ton offset sur 11 bits (AND %00000111)
Et tu recolles ensuite tes 5 bits non modifiés

Dans notre exemple #CF80 ramené à 11 bits donne #780. On garde #C8 sous la main (11001000) avec un AND %11111000
#7FE+#780=#F7E. ramené à #77E en 11 bits avec un petit RES 3,H, puisque seul le bit 3 peut subir un débordement
Et on y recolle notre page+bloc avec un OR #C8. Ce qui donne #CF7E

Je crois que ça devrait mieux fonctionner ainsi.

Et puis pourquoi tu mets des commentaires en anglais d'abord, hein ?

Auteur :  fano [ 14 Fév 2009, 10:23 ]
Sujet du message :  Re: questions en vrac

Super ! merci pour cette explication détaillée, faut encore que je comprenne dans le détail mais si j'ai bien compris le principe général, il faut séparer le calcul de l'adresse du caractère et celle de la ligne du caractère.

Citer :
Je ne comprends pas ce que vient foutre ce truc dans le calcul...

Un petit bout de code valant mieux qu'une longue explication, voilà le bout qui va avec :
Code :
;update scroll
ld A,(SCROLL_pixOffset)   
add A,A ;*2
add A,A ;*4
or 128
ld (ASIC_Sscr),A


Sinon pour les commentaires en (mauvais) anglais, c'est une (bonne) habitude.

[ce qui suit ne sert en rien le déroulement de l'intrigue et vous pouvez le zapper sans conséquence pour la compréhension de la suite de l'histoire]
En fait, le language que j'utilise pour le PC n'a pas de communauté française (xblite) donc je commente systématiquement en anglais.Et puis, je suis parfois tombé sur du source avec des commentaires inutiles (pour moi) car en allemand ou en espagnol, langues auxquelles je ne comprends strictement rien, donc de là je pense au non francophones qui pourraient être amenés à lire mon code.

Auteur :  Longshot [ 16 Fév 2009, 11:15 ]
Sujet du message :  Re: questions en vrac

Citer :
si j'ai bien compris le principe général, il faut séparer le calcul de l'adresse du caractère et celle de la ligne du caractère.

Exact.

Citer :
ld (ASIC_Sscr),A

Ben vi. Difficile de voir que tu faisais du retard vidéo sur plus.

Citer :
donc de là je pense au non francophones qui pourraient être amenés à lire mon code.

Certes, mais sur cpc, je doute que bcp prennent aujourd'hui le temps de lire un source...(à part bien sûr quant il est posté dans un thread sur cpcrulez)

Tiens nous au courant...

Auteur :  fano [ 17 Fév 2009, 13:21 ]
Sujet du message :  Re: questions en vrac

J'ai bien relu ton post et ça m'a éclairé :idea: .Au final, si j'ai bien compris, on peut diviser l'adresse écran pour le CRTC en groupes de bits :
page(2bits),bloc(3bits) et adresse(les 11 restants).
Et ça change toute ma façon de comprendre l'affichage sur CPC !

En tous cas, merci à tous pour vos conseils, je vous tiens au courant quand ça commencera à donner quelque chose de montrable :D

Auteur :  fano [ 21 Mars 2009, 16:00 ]
Sujet du message :  Re: questions en vrac

Ca avance un peu, le scroll fonctionne parfaitement et je me suis même fendu des quelques GFX.J'ai pas pu résister au plaisir de poster un petit wip :

Image

J'ai écrit aussi une petite boite à outils (PC) pour les tiles et les sprites, si quelqu'un est interessé, je peux filer le source (il vaut ce qu'il vaut mais fonctionne bien)

Page 1 sur 2 Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/