Pour les sprites zoomes on a des params en plus qui sont HSCAlE, VSCALE, REMAINDER
HSCALE et sont copain ont des parties entieres et fractionelles, c'est les 3 premiers bits qui sont la part entiere je supposes ? Cela autoriserait des valeurs de 0 a 7 et si on considere la partie fractionel on aurait droit maxi a des zooms de 7.99999999 c'est cela ?
Et le REMAINDER sert a quoi ?
[english]
For zoomed sprite, we've got three additionall paramters who are HSCALE, VSCALE and REMAINDER
HSCALE and VSCALE got integer part and floating part, that's the 3 first bits who are the integer part ? Thats allows size from 0 to 7 and if we take the floating part we can zoom up until 7.99999999 that's it ?
and the REMAINDER, what's it ?
GT Turbo ;)
Full Version: A propos des sprites zoomes
Je penses que c'est sa.
Pour le remainder je ne suis pas sur mais je pense qu'il permet de faire des Zooms plus grand en faisant peut-être remainder*HSCALE et remainder*VSCALE. (remainder ayant aussi une partie entiere et fractionnere)
Mais je ne suis pas sur.
Il faut tester.
Je n'ai pas encore trop regardé les zooms.
Pour le remainder je ne suis pas sur mais je pense qu'il permet de faire des Zooms plus grand en faisant peut-être remainder*HSCALE et remainder*VSCALE. (remainder ayant aussi une partie entiere et fractionnere)
Mais je ne suis pas sur.
Il faut tester.
Je n'ai pas encore trop regardé les zooms.
<div class="quotetop">SCPCD :</div><div class="quotemain">
Il faut tester.
Je n'ai pas encore trop regardé les zooms.
</div>
C'est bon pour moi, je commence a écrire l'intro et le main menu de Poong, vu qu'Azrael a réussi a débuggué le source C et peut enfin travailler convenablement.
Ca va zoomer sec a l'intro !!
[english]
That's good for me, i begin to write intro and main menu of Poong, because Azrael has debugged C source and can work nicely !!
That will zoom hard at intro !!
GT En train de zoomer !! ;)
Il faut tester.
Je n'ai pas encore trop regardé les zooms.
</div>
C'est bon pour moi, je commence a écrire l'intro et le main menu de Poong, vu qu'Azrael a réussi a débuggué le source C et peut enfin travailler convenablement.
Ca va zoomer sec a l'intro !!
[english]
That's good for me, i begin to write intro and main menu of Poong, because Azrael has debugged C source and can work nicely !!
That will zoom hard at intro !!
GT En train de zoomer !! ;)
Ca y est j'ai fait quelques essais et vous allez pouvoir en faire aussi !!
Apparement Remainder a des effets bizzares mais n'est pas un rapport de sur-zoom.
Recuperez l'exemple ici :
Exemple
Il y a un prog pour le Bjl (ZOOM_SPR.TOS), les sources au cas ou et l'image converties joyeusement avec Ellipse, image provenant du jeu Blood Money.
Si vous lancez le code, vous avez 6 compteurs, ceux a gauche partie fractionel et ceux de droite partie entiere. La premiere ligne c'est le Remainder, les deux autres Hscale et Vscale.
Touche 1 et 4 pour modifier le Remainder
Touche 2 et 5 pour modifier le Hscale
Touche 3 et 6 pour modifier le Vscale
On dirait que cela fonctionne a l'envers, la partie fractionnel est divisé par l'entiere pour avoir un rapport de zoom !! Faites votes essais par vous meme on attend vos remarques avec plaisir !!
Avec une image zoomé, si on modifie le Remainder cela fait des 'cochonneries' sur l'image !!!
Les compteurs sont en decimal (Je trouvais plus ma fonte hexa codé a la main !), les parties fractionnels sont décalés (de 3) avant affichage, cela pour avoir un chiffre compréhensible pour en tirer des conclusions.
Et tout a zero on a plus rien !!
[english]
I have done some trys and now you can do it too !!
At first sight REMAINDER do some strange effects
Pick up the example here !
Example
There is a prog for Bjl, source and the picture (converted by Ellipse) coming from the game Blood Money.
If you run it, you've got 6 counters, the left one are fractional part and right one integer part.
First line : REMAINDER, the two others HSCALE and VSCALE
Key 1 and 4 to modify Remainder
Key 2 and 5 to modify Hscale
Key 3 and to modify Vscale
I'am thinking that will run in bad direction !! Fractionnal part is divied by the integer part for getting a zoom ratio. Try by ourself !!
With a scaled picture, if we modify the Remainder, that give some dirty things on it.
Counter are in decimal (I have lost my hexa font, coded with my little hand !), the fractionnal part are shifted of 3 before displaying, in way to got understanding number.
And everything at zero, nothing on screen !!
GT Turbo :yes:
Apparement Remainder a des effets bizzares mais n'est pas un rapport de sur-zoom.
Recuperez l'exemple ici :
Exemple
Il y a un prog pour le Bjl (ZOOM_SPR.TOS), les sources au cas ou et l'image converties joyeusement avec Ellipse, image provenant du jeu Blood Money.
Si vous lancez le code, vous avez 6 compteurs, ceux a gauche partie fractionel et ceux de droite partie entiere. La premiere ligne c'est le Remainder, les deux autres Hscale et Vscale.
Touche 1 et 4 pour modifier le Remainder
Touche 2 et 5 pour modifier le Hscale
Touche 3 et 6 pour modifier le Vscale
On dirait que cela fonctionne a l'envers, la partie fractionnel est divisé par l'entiere pour avoir un rapport de zoom !! Faites votes essais par vous meme on attend vos remarques avec plaisir !!
Avec une image zoomé, si on modifie le Remainder cela fait des 'cochonneries' sur l'image !!!
Les compteurs sont en decimal (Je trouvais plus ma fonte hexa codé a la main !), les parties fractionnels sont décalés (de 3) avant affichage, cela pour avoir un chiffre compréhensible pour en tirer des conclusions.
Et tout a zero on a plus rien !!
[english]
I have done some trys and now you can do it too !!
At first sight REMAINDER do some strange effects
Pick up the example here !
Example
There is a prog for Bjl, source and the picture (converted by Ellipse) coming from the game Blood Money.
If you run it, you've got 6 counters, the left one are fractional part and right one integer part.
First line : REMAINDER, the two others HSCALE and VSCALE
Key 1 and 4 to modify Remainder
Key 2 and 5 to modify Hscale
Key 3 and to modify Vscale
I'am thinking that will run in bad direction !! Fractionnal part is divied by the integer part for getting a zoom ratio. Try by ourself !!
With a scaled picture, if we modify the Remainder, that give some dirty things on it.
Counter are in decimal (I have lost my hexa font, coded with my little hand !), the fractionnal part are shifted of 3 before displaying, in way to got understanding number.
And everything at zero, nothing on screen !!
GT Turbo :yes:
je viens de charger l'exemple ... je fais des tests...
ya 2 fois "3" ?
commentaires :
bah je vais simplifier le truc :
- quand on appuie sur la touche 1 : on a l'impression que pas grand chose se passe mais l'image semble se modifiée de façon étrange comme si des bandes de pixels se décalaient vers le bas mais pas tous !
- quand on appuie sur 2 : l'image s'agrandit sensiblement verticalement
- quand on appuie sur 3 : l'image s'agrandit sensiblement horizontalement
- quand on appuie sur 4 : l'image semble descendre de quelques pixels
- quand on appuie sur 5 : l'image s'agrandit verticalement
- quand on appuie sur 6 : l'image s'agrandit horizontalement
euh que dire de plus ... bah le remainder ça sert à quoi ?
Citation
Touche 1 et 3 pour modifier le Remainder
Touche 2 et 4 pour modifier le Hscale
Touche 3 et 6 pour modifier le Vscale
Touche 2 et 4 pour modifier le Hscale
Touche 3 et 6 pour modifier le Vscale
ya 2 fois "3" ?
commentaires :
bah je vais simplifier le truc :
- quand on appuie sur la touche 1 : on a l'impression que pas grand chose se passe mais l'image semble se modifiée de façon étrange comme si des bandes de pixels se décalaient vers le bas mais pas tous !
- quand on appuie sur 2 : l'image s'agrandit sensiblement verticalement
- quand on appuie sur 3 : l'image s'agrandit sensiblement horizontalement
- quand on appuie sur 4 : l'image semble descendre de quelques pixels
- quand on appuie sur 5 : l'image s'agrandit verticalement
- quand on appuie sur 6 : l'image s'agrandit horizontalement
euh que dire de plus ... bah le remainder ça sert à quoi ?
Merci Fredifredo pour l'info, j'ai remplacer ma touche, UP.
Le probleme c'est que par exemple 3 et 6 agrandissent l'image horizontalement toutes les deux, mais le truc, c'est qu'il y a un registre avec deux valeurs a mettre dedans donc pourquoi ? Et d'après la doc officiel, les 3 premiers bits (Les registres de droite 0 a 7) sont la partie entiere, donc si on registre de droite affiche 2 cela signifierait un zoom de 2 fois, et les parties de gauche, des parties pas entiere donc par exemple si je mets 2 a droite, et 4 a gauche, on devrait avoir une zoom de 2.4 fois, et quand tu fais cela y a rien qui colle. Le registre de gauche augmente plus vite le facteur de zoom que la partie entiere !!
GT Turbo :wacko:
Le probleme c'est que par exemple 3 et 6 agrandissent l'image horizontalement toutes les deux, mais le truc, c'est qu'il y a un registre avec deux valeurs a mettre dedans donc pourquoi ? Et d'après la doc officiel, les 3 premiers bits (Les registres de droite 0 a 7) sont la partie entiere, donc si on registre de droite affiche 2 cela signifierait un zoom de 2 fois, et les parties de gauche, des parties pas entiere donc par exemple si je mets 2 a droite, et 4 a gauche, on devrait avoir une zoom de 2.4 fois, et quand tu fais cela y a rien qui colle. Le registre de gauche augmente plus vite le facteur de zoom que la partie entiere !!
GT Turbo :wacko:
Dans le code source que je t'ai passé, cts avait mis des commentaires dans la table des objets dans le fichier principal testrgb.s je crois. peut-être y a-t-il un début de réponse ?
Je regardes tout a l'heure c'est pas clair tout cela, et je vais essayer de relire l'explication du Remainder, cela pourrait peut etre servir une fois.
GT Turbo ;)
GT Turbo ;)
J'ai rien trouvé dans le fichier sus-cité Fredifredo, par contre je penses avoir trouver, certains ont le Da Vinci d'autres ont la doc officielle d'Atari faut faire de sacrés recherches et parfois pas la ou ont pense !), si ont regarde dans le 'gros chapitre' bugs, il y a un petit paragraphe comme quoi Vscale a du mal a faire un zoom de 7.0 et après regardez bien la parenthèse (%111.00000) ce qui fait que le nombre enfin de compte ne fonctionne pas comme on pense
On a dans les 3 derniers bits la partie entiere et les 5 premiers la partie décimale, voila pourquoi dans les sources qu'on peut trouver, la valeur est initialisé a $20(%0010 0000) car si on décompose en binaire :
000 / 00000 (H ou V Scale)
001 / 00000 ($20) ce qui fait un rapport de zoom de 1 !!! Donc laisse l'image inchangé !!
Et voili voila !!
GT Turbo :yes:
On a dans les 3 derniers bits la partie entiere et les 5 premiers la partie décimale, voila pourquoi dans les sources qu'on peut trouver, la valeur est initialisé a $20(%0010 0000) car si on décompose en binaire :
000 / 00000 (H ou V Scale)
001 / 00000 ($20) ce qui fait un rapport de zoom de 1 !!! Donc laisse l'image inchangé !!
Et voili voila !!
GT Turbo :yes:
Confirmation par l'exemple, recliquez sur le fichier au dessus, maintenant vous avez les entiers a gauche, les fracs. a droite et vous jouez avec les touches cela marche 'beaucoup plus meilleur !'
GT Zoom !! ;)
GT Zoom !! ;)
Nouvelle pour le remainder, si vous laissez fixe ce truc de rigolo, la premiere ligne d'un sprite zoomé n'est pas zoomé !! Cela ne se voyais pas trop sur l'exemple que j'avais posté car image trop grande, j'ai essayé sur du plus petit, si on zoome sans toucher le Remainder, la premiere ligne ne bouge pas elle fera toujours un pixel, si on augmente le Remainder en meme temps que les autres cela fonctionne a merveille, c'est bete j'ai pas mon code ici, je le posterais surement plus tard.
GT Turbo ;)
GT Turbo ;)
Et voila l'exemple avec une petite boule :
http://Cerebral-Vortex.net/files/ZOOM_16.ZIP
Et que la boule soit avec toi !! Oui je sais c'est petit mais on fait avec ce qu'on a !!
GT Nul avec mes jeux de mots !! ;)
http://Cerebral-Vortex.net/files/ZOOM_16.ZIP
Et que la boule soit avec toi !! Oui je sais c'est petit mais on fait avec ce qu'on a !!
GT Nul avec mes jeux de mots !! ;)
QUOTE (GT Turbo @ 10 Jul 2005, 11:07) 
For zoomed sprite, we've got three additionall paramters who are HSCALE, VSCALE and REMAINDER
HSCALE and VSCALE got integer part and floating part, that's the 3 first bits who are the integer part ? Thats allows size from 0 to 7 and if we take the floating part we can zoom up until 7.99999999 that's it ?
and the REMAINDER, what's it ?
GT Turbo
HSCALE and VSCALE got integer part and floating part, that's the 3 first bits who are the integer part ? Thats allows size from 0 to 7 and if we take the floating part we can zoom up until 7.99999999 that's it ?
and the REMAINDER, what's it ?
GT Turbo
This is used by the OP to render scaled sprites (the Atari documentation is your friend)
After each line is processed, the corresponding 68k program (to what the OP do) is
CODE
;; d0.b = REMAINDER
;; d1.b = VSCALE
;; d2.w = HEIGHT
;; d3.w = DWIDTH
;; a0 = DATA
sub.b #1<<5,d0; subtract 1 to REMAINDER
bcc.s .done ; if positive then that's all
.adjust:
add.w d3,a0; next line in DATA
subq.w #1,d2; decrement height by one
beq.s .done; if height becomes 0 then stop
add.b d1,d0 ; add VSCALE to REMAINDER
bcc.s .adjust; until it becomes positive
.done:
;; update values (REMAINDER, HEIGHT, DATA)
;; d1.b = VSCALE
;; d2.w = HEIGHT
;; d3.w = DWIDTH
;; a0 = DATA
sub.b #1<<5,d0; subtract 1 to REMAINDER
bcc.s .done ; if positive then that's all
.adjust:
add.w d3,a0; next line in DATA
subq.w #1,d2; decrement height by one
beq.s .done; if height becomes 0 then stop
add.b d1,d0 ; add VSCALE to REMAINDER
bcc.s .adjust; until it becomes positive
.done:
;; update values (REMAINDER, HEIGHT, DATA)
Pour compléter mon message précédent,
avec Stabylo, on a un peu bossé sur le sujet, et après réflexion,
il s'avère qu'un bon choix de valeur initiale pour le REMAINDER est VSCALE - 1
(c'est à dire la plus grande valeur strictement inférieure à VSCALE,
le 1 étant compris comme 2^(-5))
L'idée en effet est que la valeur initiale du REMAINDER détermine combien de fois
la première ligne va être copiée
(c'est la partie entière du REMAINDER précisément)
Si on prend plus grand que VSCALE, la première ligne sera affiché trop de fois,
si on prend trop inférieur à VSCALE, idem, la première ligne ne sera pas affichée assez de fois.
avec Stabylo, on a un peu bossé sur le sujet, et après réflexion,
il s'avère qu'un bon choix de valeur initiale pour le REMAINDER est VSCALE - 1
(c'est à dire la plus grande valeur strictement inférieure à VSCALE,
le 1 étant compris comme 2^(-5))
L'idée en effet est que la valeur initiale du REMAINDER détermine combien de fois
la première ligne va être copiée
(c'est la partie entière du REMAINDER précisément)
Si on prend plus grand que VSCALE, la première ligne sera affiché trop de fois,
si on prend trop inférieur à VSCALE, idem, la première ligne ne sera pas affichée assez de fois.
Question:
Pourquoi ai-je dans la tête l'idée que la hauteur des sprites zoomés doit être décrémentée de 1?
Je crois me rappeler l'avoir lu quelque part mais je ne me rappelle plus où... quelqu'un saurait-il
m'en dire plus?
Pourquoi ai-je dans la tête l'idée que la hauteur des sprites zoomés doit être décrémentée de 1?
Je crois me rappeler l'avoir lu quelque part mais je ne me rappelle plus où... quelqu'un saurait-il
m'en dire plus?
QUOTE (SebRmv @ 8 Jan 2008, 03:28)
Pourquoi ai-je dans la tête l'idée que la hauteur des sprites zoomés doit être décrémentée de 1?
Je crois me rappeler l'avoir lu quelque part mais je ne me rappelle plus où... quelqu'un saurait-il
m'en dire plus?
Je crois me rappeler l'avoir lu quelque part mais je ne me rappelle plus où... quelqu'un saurait-il
m'en dire plus?
I'm not sure I fully understand the question, but remember how the sprite scaling works - it's just a simple counter per scanline.
IIRC, decrementing by 1 at the beginning makes the first scanline appear on a sprite that is scaled down -- otherwise it usually skips the first scanline. Typically it looks better to have the first scanline present and let it skip the next one.
Does that help?
QUOTE (Tursi @ 9 Jan 2008, 23:51)
I'm not sure I fully understand the question, but remember how the sprite scaling works - it's just a simple counter per scanline.
IIRC, decrementing by 1 at the beginning makes the first scanline appear on a sprite that is scaled down -- otherwise it usually skips the first scanline. Typically it looks better to have the first scanline present and let it skip the next one.
Does that help?
IIRC, decrementing by 1 at the beginning makes the first scanline appear on a sprite that is scaled down -- otherwise it usually skips the first scanline. Typically it looks better to have the first scanline present and let it skip the next one.
Does that help?
Sorry Tursi for the french
My question was about the "height" field of scaled sprites.
I believe I read somewhere that height of scaled sprites has to be decremented by one.
But I can't remember where I have seen that and just asked if anyone also read that.
From my experiment, if height is not decremented, then the last line seems to be corrupted.
I even believe that the fix proposed was to add an empty (black) line at the end of each
scaled sprites.
Anyway, thanks for your help.
Have you seen the new release of my library?
I am pretty proud of the way the OP list is built now
Don't be sorry for using your own language! -- I need the practice to retain my Canadianism. If you could say more phrases like "no sugar added!" and "free toy inside!", it would help me remember my childhood reading the French side of cereal boxes.
I believe I worked it out on paper once myself - if you do the math about when the scanlines draw I think it works out. I can't give an example right now because I'm at work, but draw it out on paper and I think it makes sense.
I haven't had a look at the library yet, but the specs sounded nice. Do you have some videos on the page? (I will go look now.)
I believe I worked it out on paper once myself - if you do the math about when the scanlines draw I think it works out. I can't give an example right now because I'm at work, but draw it out on paper and I think it makes sense.
I haven't had a look at the library yet, but the specs sounded nice. Do you have some videos on the page? (I will go look now.)
QUOTE (Tursi @ 10 Jan 2008, 23:50)
Don't be sorry for using your own language! -- I need the practice to retain my Canadianism. If you could say more phrases like "no sugar added!" and "free toy inside!", it would help me remember my childhood reading the French side of cereal boxes.
I believe I worked it out on paper once myself - if you do the math about when the scanlines draw I think it works out. I can't give an example right now because I'm at work, but draw it out on paper and I think it makes sense.
I haven't had a look at the library yet, but the specs sounded nice. Do you have some videos on the page? (I will go look now.)
I believe I worked it out on paper once myself - if you do the math about when the scanlines draw I think it works out. I can't give an example right now because I'm at work, but draw it out on paper and I think it makes sense.
I haven't had a look at the library yet, but the specs sounded nice. Do you have some videos on the page? (I will go look now.)
Yes, there are some examples (with videos) on the page.
Since the API has not changed, I have not updated the examples though.
Cheers
QUOTE (SebRmv @ 10 Jan 2008, 15:39)
Yes, there are some examples (with videos) on the page.
Since the API has not changed, I have not updated the examples though.
Since the API has not changed, I have not updated the examples though.
Yeah, I've seen the old videos. I wanted to see your sprite test!
A sprite test with a lot of "free toys inside" 
Looking at the NET files (thanks SCPCD )
we learn that SCALED sprites are displayed as long as
VC >= YPOS & (HEIGHT >0 || ((HEIGHT == 0) && (integer part of REMAINDER > 0))
hence the fix
)we learn that SCALED sprites are displayed as long as
VC >= YPOS & (HEIGHT >0 || ((HEIGHT == 0) && (integer part of REMAINDER > 0))
hence the fix
QUOTE (SebRmv @ 28 Jul 2006, 14:28)
This is used by the OP to render scaled sprites (the Atari documentation is your friend)
After each line is processed, the corresponding 68k program (to what the OP do) is
After each line is processed, the corresponding 68k program (to what the OP do) is
CODE
;; d0.b = REMAINDER
;; d1.b = VSCALE
;; d2.w = HEIGHT
;; d3.w = DWIDTH
;; a0 = DATA
sub.b #1<<5,d0; subtract 1 to REMAINDER
bcc.s .done; if positive then that's all
.adjust:
add.w d3,a0; next line in DATA
subq.w #1,d2; decrement height by one
beq.s .done; if height becomes 0 then stop
add.b d1,d0; add VSCALE to REMAINDER
bcc.s .adjust; until it becomes positive
.done:
;; update values (REMAINDER, HEIGHT, DATA)
;; d1.b = VSCALE
;; d2.w = HEIGHT
;; d3.w = DWIDTH
;; a0 = DATA
sub.b #1<<5,d0; subtract 1 to REMAINDER
bcc.s .done; if positive then that's all
.adjust:
add.w d3,a0; next line in DATA
subq.w #1,d2; decrement height by one
beq.s .done; if height becomes 0 then stop
add.b d1,d0; add VSCALE to REMAINDER
bcc.s .adjust; until it becomes positive
.done:
;; update values (REMAINDER, HEIGHT, DATA)
so, after examination of the NET files, it is not exactly what is implemented.
The correct program is rather:
CODE
;; d0.b = REMAINDER
;; d1.b = VSCALE
;; d2.w = HEIGHT
;; d3.w = DWIDTH
;; a0 = DATA
sub.b #1<<5,d0; subtract 1 to REMAINDER
.adjust:
cmp.b #1<<5,d0; compare to 1 (instead of 0)!!
bpl.s .done
add.w d3,a0; next line
add.b d1,d0; REMAINDER += VSCALE
subq.w #1,d2; height--
bpl.s .adjust
.done:
;; update values (REMAINDER, HEIGHT, DATA)
;; d1.b = VSCALE
;; d2.w = HEIGHT
;; d3.w = DWIDTH
;; a0 = DATA
sub.b #1<<5,d0; subtract 1 to REMAINDER
.adjust:
cmp.b #1<<5,d0; compare to 1 (instead of 0)!!
bpl.s .done
add.w d3,a0; next line
add.b d1,d0; REMAINDER += VSCALE
subq.w #1,d2; height--
bpl.s .adjust
.done:
;; update values (REMAINDER, HEIGHT, DATA)
This explains why it does not work correctly when VSCALE >= (7<<5).
(since in this case, overflow can occur)
Also, I believe the ideal initial value for the REMAINDER is
1<<5 + VSCALE - 1
Nice infodump, Seb!
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.