Jump to content
Jagware

SebRmv

Level1
 View Profile  See their activity

  • Content count

    1,553

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by SebRmv

  4. Posted · Report reply

    Ok, as I can't sleep, I have written the solution (I mean the code of the solution).

     

    You can look the result with http://removers.atari.org/blit2d.bin

     

    The transformation matrix is written on screen.

    The blue values are "a" and "b"

    The red values are "c" and "d"

    The white values are "e" and "f"

     

    You can of course edit the values with the program.

     

    To select the value you want, press 1 to 6 on the joypad.

    Then you can increment or decrement the value by 1<<SCALE with up and down on the joypad.

    The default SCALE is 0 (so the default increment is 1) but you can change the scale with 7, 8, 9 and 0. The corresponding scales are 0, 4, 8 and 12.

     

    Enjoy

     

    Seb

     

    PS: the exercise is still up!

  8. Posted · Report reply

    no, sorry, there won't be a gui version. I think it is easier to use as a command line tool, particularly if you mechanize the calls in a Makefile.

     

    By the way, the image formats usable are (should be)

    PNG, JPEG, TIFF, BMP, PPM and maybe GIF

    (not that TGA format is not supported in particular)

     

    Seb

  10. Posted · Report reply

    En gros voilà une petite question.

    Supposons que l'on soit en train de bosser sur un remake d'un jeu qui n'a pas été porté sur jaguar, ou du moins ça ne reste qu'une rumeur, et que l'on travaille à partir rien d'origine mais où tout est refait (images, codes, zik ...) est-ce qu'il peut y avoir des problèmes de droits malgré tout ?

     

    En gros pour résumer tout simplement, est-ce qu'un concept de jeu peut etre protégé ?

     

    c'est vrai, c'est une bonne question

    et je n'en ai aucune idée

    pour les jeux auxquels je pense :rolleyes:, il y a des clones libres qui existent

    mais ça ne répond pas à la question "a-t-on éventuellement le droit de commercialiser?"...

     

    Seb

  11. Posted · Report reply

    That will be very useful ! Thanks !

     

    (I won't say anything about the binary being more than 1 Mb in size... :lol: I know it's not your fault :) )

     

    Yes, that's the price to pay when statically linking all the libraries you need...

     

    Seb

     

    PS: by the way, what about the documentation of the video registers :P ?

    • Like 1

  12. Posted · Report reply

    Hello,

     

    I am proud to announce that I have finally managed to compile a version of my Jaguar Image Converter for Windows XP and Linux which does not require additionnal packages or softwares to be installed :yes:

     

    You can find the binaries there:

     

    http://removers.atari.org/softs/download.php

     

     

    Enjoy !

     

    Seb

     

    PS: for other binary release, please contact me...

    PPS: under windows, you do not need to install cygwin, you just need to have the file cygwin1.dll which is included in the package I have made :D

    • Like 1

  14. Posted · Report reply

    Hello,

     

    I'll try to translate my post of yesterday in the french speaking zone. (see http://www.jagware.org/index.php?showtopic=255)

     

    So, as I said, I played a little with the blitter and discovered how to make rotations with it :yes:

     

    Actually, the method is (vaguely) described in the Atari documentation but I understood it once I reinvented the method :D

    And by the way, the authors of the Jaguar Underground Documentation hadn't understood how to do... because it is not possible to have holes as they say.

     

    The idea is to use A2 as the destination register. We will simply scan the zone where we want to write the rotated data and we will fetch the corresponding graphics data with A1 which will scan the source sprite.

     

    I define W as being the width of the sprite and H its height.

     

    So, imagine we want to rotate a sprite of an angle alpha. If we define X',Y' as being the new coordinates and X,Y being the old ones (where the coordinates are expressed from the centre of the rotation at CX,CY and with axis parallel to the screen)

    you probably remember from your maths course that

     

    X = X' cos(alpha) - Y' sin(alpha)

    Y = X' sin(alpha) + Y' cos(alpha)

     

    now, what happens if X' change by one (ie becomes X'+1)

    then X becomes X+cos(alpha)

    and Y becomes Y+sin(alpha)

    so here we get the increment to use in the inner loop!

     

    Thus, we have

    INC,FINC_X = cos(alpha)

    INC,FINC_Y = sin(alpha)

     

    well, good point!

     

    Now, what happens if Y' becomes Y'+1 and X' changes by -W

    In this case, we have X' becomes X' -W * cos(alpha) - sin(alpha)

    and Y' becomes Y - W*sin(alpha) + cos(alpha)

     

    This gives us the value to put in step values for the outer loop!

     

    STEP,FSTEP_X = -W*cos(alpha) - sin(alpha)

    STEP,FSTEP_Y = -W*sin(alpha) + cos(alpha)

     

    Now, we do not want to write garbage data when the A1 pointer leaves out the original sprite, so we use clipping

    We set:

     

    CLIP_X = W

    CLIP_Y = H

     

    and the last thing to compute is the coordinate where to start for A1

     

    after computation, we get

     

    PIXEL,FPIXEL_X = CY*sin(alpha) - CX*cos(alpha) + CX

    PIXEL,FPIXEL_Y = CY - (CX*sin(alpha) + CY*cos(alpha))

     

    In case, I have not been clear enough, see the source code I have posted in the french speaking zone ;)

     

    the function get_cos_and_sin takes in d1 the angle and returns the value 16.16 of the cosinus (d1) and the sinus (d2) for that angle.

     

    FInally, feel free to ask any questions if this remains obfuscated for you

     

    Seb

  15. Posted · Report reply

    Salut,

     

    voilà, j'ai un peu joué avec le blitter hier et aujourd'hui

    et bonne nouvelle: j'ai réussi à faire des rotations au blitter!!

     

    en fait, la doc Atari donne les infos pour le faire et j'ai compris après avoir redécouvert moi-même la méthode leurs explications :D

    par contre, les auteurs de la Jaguar Underground Documentation n'avaient pas compris comment faire les rotations au blitter !

     

    alors, voilà

    on va faire le cas d'une rotation toute simple (sans mise à l'échelle, après, c'est pareil si vous avez compris)

     

    on veut tourner une image de taille W*H d'un angle alpha avec un centre de coordonnées CX,CY

    on veut mettre le résultat dans une image de taille W*H aussi avec le centre au même endroit

    (on tourne juste le sprite par rapport au centre donc)

     

    plaçons nous dans le repère avec comme origine CX,CY et les axes comme il faut (parallèles au bord de l'écran)

    je note X,Y les coordonnées d'un point dans l'ancien repère (sprite non tourné)

    et X',Y' les coordonnées de ce même point dans le nouveau repère (sprite tourné)

     

    maintenant, un peu de maths

     

    vous savez sans doute que l'on a

     

    X = X' cos(alpha) - Y' sin(alpha)

    Y = X' sin(alpha) + Y' cos(alpha)

     

    (comme disait mon prof de maths sup, toujours les anciennes coordonnées en fonction des nouvelles)

     

    si on dérive par rapport à X' tous ça

    on obtient

     

    dX = cos(alpha) dX'

    dY = sin(alpha) dX' (physician's style :D)

     

    ce qui veut dire que si X' devient X'+1

    alors X devient X + cos(alpha) et Y devient Y+sin(alpha)

     

    (pareil, on dérive par rapport à Y'

    dX = -sin(alpha) dY'

    dY = cos(alpha) dY')

     

     

    donc, si vous connaissez le blitter un petit peu

    on voit tout de suite que A2 scannera la destination (et donc dessinera le sprite tourné)

    et A1 scannera la source

    et on utilisera le mode PIXEL bien sur avec comme incrément cos(alpha) et sin(alpha) !!

     

    INC,FINC_X = cos(alpha)

    INC,FINC_Y = sin(alpha)

     

    pour revenir à la ligne, on utilisera A1_STEP et A1_FSTEP

    on revient de dX' = -W

    donc -W * cos(alpha) pour X et -W*sin(alpha) pour Y

    mais il ne faut pas oublier non plus de descendre d'une ligne (donc dY' = 1)

    d'où

     

    STEP,FSTEP_X = -W*cos(alpha) -sin(alpha)

    STEP,FSTEP_Y = -W*sin(alpha) + cos(alpha)

     

    on va aussi utiliser le clipping du blitter pour ne pas écrire n'importe quoi si l'on sort du dessin du sprite original

     

    CLIP_X = W

    CLIP_Y = H

     

    et maintenant, il ne reste plus qu'à trouver d'où l'on commence dans A1

    (c'est à dire quelles sont les coordonnées du point 0,0 dans l'image originale (là je ne suis plus dans le repère centré))

     

    eh bien, on ressort encore nos formules de maths

     

    on obtient

     

    PIXEL,FPIXEL_X = CY*sin(alpha) - CX*cos(alpha) + CX

    PIXEL,FPIXEL_Y = CY - (CX*sin(alpha) + CY*cos(alpha))

     

    et voilà!!

     

    un peu de code, au cas où je n'aurais pas été clair :whistling:

     

    ça tourne l'image base_gfx dans l'image base_buffer

    notez que j'efface d'abord la zone (en mode phrase)

    puis ensuite je fais effectivement la rotation

     

    l'image a une largeur de 56 qui est aussi la largeur des données (WID56)

     

    l'angle est dans d1

    j'ai utilisé une routine get_cos_and_sin qui lit

    simplement en data les valeurs pour le cosinus et le sinus

    (d1 vaut le cosinus et d2 le sinus)

     

    j'ai aussi bricolé vite fait une multiplication d'une valeur 16.16 (utilisée par le blitter) par un entier positif < 32768

     

     

    n'hésitez pas à poser vos questions si je n'ai pas été clair

     

    Seb

     

    .macro    wait_blitter
.\~:
    move.l    B_CMD,\1
    ror.w    #1,\1
    bcc.s    .\~
.endm
.macro    imul16_16
;; \1 = registre contenant la valeur 16.16
;; \2 = registre contenant un entier POSITIF sur 16 bits (15 bits donc)
;; \3 = registre temporaire pour calcul intermediaire
;; \1 est intacte apres l'operation
;; le resultat est stocke dans \2
    move.w    \2,\3
    mulu.w    \1,\3    ; partie fractionnaire
    swap    \1
    muls.w    \1,\2    ; partie entiere
    swap    \1
    swap    \2    ; decale de 16
    clr.w    \2
    add.l    \3,\2    ; ajoute la partie fractionnaire
.endm


rotate_base:
W    equ    56
H    equ    50
CX    equ    56/2
CY    equ    32
;; efface le buffer
    wait_blitter    d0
    move.l    #base_buffer,A1_BASE
    move.l    #PIXEL16|XADDPHR|PITCH1|WID56,A1_FLAGS
    move.l    #0,A1_PIXEL
    move.w    #1,d0
    swap    d0
    move.w    #-W,d0
    move.l    d0,A1_STEP
    
    move.w    #H,d0
    swap    d0
    move.w    #W,d0
    move.l    d0,B_COUNT

*     move.l    #(BLUE<<16)|WHITE,B_PATD
*     move.l    #(RED<<16)|CYAN,B_PATD+4
    move.l    #0,B_PATD
    move.l    #0,B_PATD+4
    
    move.l    #UPDA1|PATDSEL,B_CMD
;; rotation
    wait_blitter    d0
    move.l    #base_buffer,A2_BASE
    move.l    #PIXEL16|XADDPIX|PITCH1|WID56,A2_FLAGS
    move.l    #0,A2_PIXEL

    move.w    #1,d0
    swap    d0
    move.w    #-W,d0
    move.l    d0,A2_STEP

    move.l    #base_gfx,A1_BASE
    move.l    #PIXEL16|XADDINC|PITCH1|WID56,A1_FLAGS

    move.w    #H,d0
    swap    d0
    move.w    #W,d0
    move.l    d0,A1_CLIP

    move.w    angle,d1
    bsr    get_cos_and_sin

    move.w    d2,d0
    swap    d2
    swap    d0
    move.w    d1,d0
    swap    d1
    move.l    d0,A1_FINC

    move.w    d2,d0
    swap    d2
    swap    d0
    move.w    d1,d0
    swap    d1
    move.l    d0,A1_INC
    
    move.w    #W,d3
    imul16_16    d1,d3,d7; W*cos(alpha)
    move.w    #W,d4
    imul16_16    d2,d4,d7; W*sin(alpha)
    move.l    d2,d5
    neg.l    d5    ; -sin(alpha)
    sub.l    d3,d5    ; -sin(alpha)-W*cos(alpha)
    move.l    d1,d6    ; cos(alpha)
    sub.l    d4,d6    ; cos(alpha)-W*sin(alpha)

    move.w    d6,d0
    swap    d6
    swap    d0
    move.w    d5,d0
    swap    d5
    move.l    d0,A1_FSTEP
    
    move.w    d6,d0
    swap    d0
    move.w    d5,d0
    move.l    d0,A1_STEP
    
    move.w    #CX,d3
    imul16_16    d1,d3,d7; CX*cos(alpha)
    move.w    #CY,d4
    imul16_16    d2,d4,d7; CY*sin(alpha)
    sub.l    d3,d4
    add.l    #CX<<16,d4
    move.w    #CX,d3
    imul16_16    d2,d3,d7; CX*sin(alpha)
    move.w    #CY,d5
    imul16_16    d1,d5,d7; CY*cos(alpha)
    add.l    d5,d3
    neg.l    d3
    add.l    #CY<<16,d3
    exg.l    d3,d4

    move.w    d4,d0
    swap    d4
    swap    d0
    move.w    d3,d0
    swap    d3
    move.l    d0,A1_FPIXEL

    move.w    d4,d0
    swap    d0
    move.w    d3,d0
    move.l    d0,A1_PIXEL
                    
    move.w    #H,d0
    swap    d0
    move.w    #W,d0
    move.l    d0,B_COUNT

    move.l    #CLIP_A1|UPDA1|UPDA1F|UPDA2|LFU_REPLACE|SRCEN|DSTA2,B_CMD
    rts

  20. Posted · Report reply

    what... do you mean that you could not use a "jr" instruction in an IRQ or what?

     

    It should work....

     

    hmm.. please elaborate on this....

    Are the code to big or to secret to post here or could you post, working relative code (outside irq), nonworking code(inside irq), and working absolute code?

     

    Would just be interesting to se...

     

    regards

    /Sym

     

    I have to do some tests again because it is quite strange.

    The code in question is part of my sprite manager which will be soon

    be released (open source , BSD license) :D

     

    When I say PC relative code, I am thinking of code like the following one:

     

    start:

    move PC,r0

    ...

    movei #label-start,r1

    ...

    add r0,r1 // label relocated

    ...

    jump t,(r1)

    nop

    ...

    label:

    nop

     

     

     

    another solution I found, instead of ->

    while whatever

    -starting the GPU

    -waiting for the GPU to stop

    -doing other stuff with the 68k

    wend

     

    I will do:

    while whatever

    -waiting for the GPU to stop

    -starting the GPU

    -doing other stuff with the 68k during the GPU is computing stuff

    wend

     

    then it avoid to restart the GPU if it have not finish, and we can do other usefull stuff while the GPU is working. taking advantage of parallel processing ^^

    we can do better than intel dual core, we have triple core ! ;)

    that is exactly what I do in my tunnel and fire screen :P

    (if I have understood what you are saying, of course :D)

  22. Posted · Report reply

    :huh:

    Je vois pas trop pourquoi ca ne fonctionnerais pas :huh:

    Si tu as respecté les regles sur les interruptions, je ne vois pas ce qui pourrait ne pas fonctionner :unsure:

    a moins que tu fais des trucs louches dans ton code :D

     

    [english]

    If you respecte all laws for the GPU interrupts, I don't understand why this don't work :unsure:

    unless you made strange things in your code :D

     

     

    oui, moi non plus, je ne comprends pas vraiment

    j'ai switché pour du code absolu et ça a marché...

    (mon code PC relatif marchait avant que je le mette en interruption)

     

    [english]

     

    yes, me neither

    I changed for absolute code and it worked so I concluded that something was wrong with PC relative code and interrupts

    (my PC relative code worked before I put it in interrupt)

  23. Posted · Report reply

    ce week-end, j'ai un peu joué au GPU (les interruptions en particulier), et j'ai eu l'impression que le code PC relatif en interruption, ça lui plaisait pas trop... est-ce que vous avez déjà fait cette expérience?

     

    [english]

     

    this week-end, I played a bit with the GPU (and interrupts) and I had the impression that it did not like PC relative code in interrupt... does someone else has also made this experiment?

     

    Seb

  24. Posted · Report reply

    Nice Blobs demo SebRmv !!! =)

     

    are that scaled bitmaps? ..

     

    ..and a Brownian motion simulation or what? ;)

    Well for the blitter i understood it, yes intensity is a signed 7bit value... and as i understood it so are the cry colours.. ie 1 cry value are composed of two 3bit signed colour components and one signed 7bit intensity component.. (ie s3s3s7 (s=signed, #of bits)).

    With the blitter properly set up additions will saturate to produce a binary value of %0111011101111111 for positive values.

     

    I hope to god the OP does the same!... and SebRmv, if that is OP bitmap objects with just the rmw bit set (and the data all opsitive values) then it would apear so... (i must have made some mistake in the test code i made back when i experimented with it... Im pritty sure i know what... since the BG also needs to be signed... which it wasnt... and perhapps i cant use the bitmaps i choose for the blobs...)

     

    ..This is done with the "-glass" parameter in the tga2cry program atari created.. ( i know that... now)...

    Will have to reopen my old x-files and finish that code ;P

     

    regards

    /Sym of TNG

     

    no these are not scaled bitmaps

    it is simple (not scaled) sprites simply with the RMW flag set :D and only positive values for Y

     

    oh, now I see why you asked about scaled bitmaps

    no, it is just different images

    this little demo is the example program I will give with my sprite manager when it will be ready (I have just one little technical thing to complete at least)

     

    Actually, I coded my own image converter (see the link few posts above) but I guess this is what the -glass flag of tga2cry gives (not sure however)

     

    For the moves, it uses the pseudo random number generator I have posted in an other thread...

     

    Seb

  25. Posted · Report reply

    Nice demo man! =)

     

    And NO the scroll is not to BIG =) ...but it lacks something... (besides a greet ;) ..it should have had a sinus shaped Y-scale zoom on it :) and the nostalgia would have been complete..

     

    No sincerely.. a nice demo!... Im glad and inspiered by the fact that some small demos are beeing published for the jag!...

     

    nice, cool work!

     

    cheers!

    /Symmetry of TNG

     

    Oh sorry for the greetings

    actually, it was a difficult part for me because it was some time I was not aware of the Atari scene

    when I wrote the text

    but, yes, I will definitely add you in next greetings :D

     

    Seb

     

    PS: actually, I might release an updated version because there is a tricky bug included in the current version.

×