Jump to content
Jagware
Sign in to follow this  
GT Turbo

A propos des sprites zoomes

Recommended Posts

GT Turbo    3

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 ;)

Share this post


Link to post
Share on other sites
SCPCD    0

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.

Share this post


Link to post
Share on other sites
GT Turbo    3

<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 !! ;)

Share this post


Link to post
Share on other sites
GT Turbo    3

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:

Share this post


Link to post
Share on other sites
Fredifredo    0

je viens de charger l'exemple ... je fais des tests...

 

 

 

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

 

 

 

 

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 ?

Share this post


Link to post
Share on other sites
GT Turbo    3

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:

Share this post


Link to post
Share on other sites
Fredifredo    0

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 ?

Share this post


Link to post
Share on other sites
GT Turbo    3

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 ;)

Share this post


Link to post
Share on other sites
GT Turbo    3

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:

Share this post


Link to post
Share on other sites
GT Turbo    3

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 !! ;)

Share this post


Link to post
Share on other sites
GT Turbo    3

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 ;)

Share this post


Link to post
Share on other sites
SebRmv    2
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 ;)

 

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

 

;; 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)

Share this post


Link to post
Share on other sites
SebRmv    2

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.

Share this post


Link to post
Share on other sites
SebRmv    2

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?

Share this post


Link to post
Share on other sites
Tursi    0
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?

 

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? :)

Share this post


Link to post
Share on other sites
SebRmv    2
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? :)

 

Sorry Tursi for the french :P

 

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 ;)

Share this post


Link to post
Share on other sites
Tursi    0

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.)

Share this post


Link to post
Share on other sites
SebRmv    2
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.)

 

Yes, there are some examples (with videos) on the page.

Since the API has not changed, I have not updated the examples though.

 

Cheers

Share this post


Link to post
Share on other sites
Tursi    0
Yes, there are some examples (with videos) on the page.

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! :)

Share this post


Link to post
Share on other sites
SebRmv    2

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

Share this post


Link to post
Share on other sites
SebRmv    2
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

 

;; 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)

 

so, after examination of the NET files, it is not exactly what is implemented.

The correct program is rather:

 

;; 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)

 

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

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×