Jump to content
Jagware

Orion_

Level1
  • Content count

    1,073
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Orion_


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


  2. just a little question, since the GPU has the double speed of the 68k, can we say that 2 GPU cycle = 1 68k cycle ? so for example: the GPU can do 2 instruction of 4cycle in the same time the 68k do one instruction taking 4 cycles ? I think it would be quite useful to take advantage of this timing, so the 68k don't have to waste time waiting for the GPU to finish and can do other useful stuff.


  3. I have no idea how it actually works, but I can't imagine it is what I assume "raytracing" to be (ie allot of vector algebra, crossproducts,dotproducts, n stuff) ...since i assume that code to be bigger than 836 bytes ;)

    there must be some simplification involved... or?

    it is real raytracing, only one light, and 3 shaded sphere, no rotation, but it use a lots of dotproducts, 2 squareroot, some div, and that for each pixel, the GPU is quite fast I was impressed, but the fixed point make this fast too.

    I can release the source code If you want :) but it's not really a clean source code, and it have some dirty last minute hack because I had problem with some distance comparison.

     

    Is that 3 shaded spheres ? ...or just one? (the green one?) ..i mean regarding fixpoint, why does the red&blue look smoother shaded than the greenone?... wouldnt the math be the same?...

    are there some Z values involved?..and how do you calculate the shadevalues?

    The green one is closer to the camera than the 2 others, and I think because of the fixed point and lost of precision, the shaded colors are ugly :/

    the shadevalue is calculated doing crossproduct between the light vector (from the light to the intersected point on the sphere) and the normal at the intersected point of the sphere surface.

     

    is it .8 or .16 fixpoint? ... (or signed 7.8 or something)....

    signed .8 (else I think it will overflow)

     

    -Could the DSP do half of the screen? ... (ie ~2 faster... not counting the 16bit bus to dsp, hence the "~")

     

    -Do you storew pixels to screen space with external stores?

    A good idea would be to let the gpu build, say 1 scanline of the screen in GPU memory, and then Phraseblitt a hole scanline to screenspace... killing all external stores!

    Combine this with the 1st point.. letting the dsp do same thing but other half of screen...

    (I use external storew)

    actually I was thinking of doing that before starting the raytracer, that's why I tried a simple test with the GPU to predict how fast It will be using those optimisation, even by reducing the screen to 160x120 I think I will not do better than 2fps, I don't know if that be worth it.


  4. This is a little bad attempt to Fixed Point Raytracing on Jaguar.

    The Raytracer is 100% GPU Code. (836bytes)

     

    I know this is not really looking like a raytracer, but actually it is :)

    the bad colors and precision is due to the fixed point :/

    it's not optimised, it was only a little technical test to see how fast this would be on GPU ^^

    This was coded on emulator Project Tempest, but it also work on a real jaguar except that it seems there is some glitchs with the jagware logo :/

     

    anyway, enjoy :)

     

    (promise, I will try to start making some more useful stuff from now ^^)

     

    Jag Raytracer

     

    raytracer.png


  5. and with Project Tempest 0.95, it works well but only if your object list begins with the **two** branch objects :blink:

    I added the 2 branch object (thank GT Turbo for the advices), but it still don't work in PT :/

    I have 2 branch object, that point to the STOP object at the end of my list, the first branch is a_vde<VC and the second, a_vdb>VC.

    and it seems to work at least with normal sprite in RGB16 since I use it in my little intro and GT Turbo tried it on the jaguar.

     

    Perhaps use Removers one : http://removers.free.fr/softs/download.php

    I don't have ocaml compiler sorry :D

    if you have the tga2cry.exe and can send it to me (at my usual email address) that would be nice, thanks :)


  6. bon je fait come back avec cette toute petite intro, pour tester mon gestionnaire de sprite, tout en 68000 pas du tout optimisé et sans restauration de liste etc... donc y'a largement de quoi faire mieux, mais c'etait un premier test ;)

    un écran "leonard like" avec 100 sprites + le background et un petit mod oldschool (estraik) :)

     

    pour ceux qui ne peuvent pas tester sur jaguar, ça fonctionne sur l'emulateur Project Tempest :)

     

    english

     

    I'm coming back with this very little intro to test my first sprite manager, 100% 68000 code absolutly not optimised, without OP list restoration, etc... so I can do a lot better, but that was just my first little test ;)

    a "leonard like" screen with 100 sprites + the background picture, and a little oldschool mod (estraik) :)

     

    Enjoy !

     

    thanks to GT Turbo for the picture ! because I don't have a jaguar anymore, so that was coded on the Project Tempest emulator !

    post-1-1146887794_thumb.jpg

     

    (The red thing is not present on the intro inside the zip file, this is how much time my routine actually take in VBL)


  7. nice effect SebRmv ;)

    I'm a bit angry since I tried to achieve that effect a month ago per pixel using GPU and it was damn slow, I should have read more the atari doc to find out this feature ^^

    anyway I will try to get it working on PT !

    does anyone can send me or link me to where I can download the tga2cry.exe tool ?

    thanks !


  8. GT Turbo m'en avait parlé et j'ai fini par trouver ou etait ce fameux bit de RMW, par contre quand je l'active ça me fait rien sur l'emulateur (ecran noir), et d'apres la description de la doc et les sources de l'emulateur virtual jaguar, ça ne fonctionne quand mode CRY16.

    quelqu'un a t'il déja essayer d'activer ce fameux bit pour voir ce que ça fait ?

    visiblement ça additionne les couleurs du sprite sur le line buffer, et ça fait une saturation ! ce qui est très interessant pour faire certain effet, quand on vois comment ça ram en essayant de faire ça même au GPU pixel par pixel :D

     

     

    english

     

    GT Turbo told me about it a few days ago, and I finally found were this bit should be activated (in the first phrase of the sprite object). I tried that on the emulator (PT) and all I got was a black screen. reading the doc and the source code of the Virtual Jaguar emulator, it seems that it only work in CRY16 mode, I tried both CRY16 and RGB16 but it doesn't work on PT, so, does anyone had already tried this blending mode ?

    it seems to add the sprite pixel to the line buffer and saturate the color, so we have blending feature for free, and it can be great for some effect (and a lot faster than doing that per pixel even using the GPU, (yes, I tried .. ^^))


  9. en parlant de branch object, ça serais possible d'avoir un peu plus d'explication sur les fameux 2 branch object qu'il faut avoir en debut de liste d'apres toi ?

    ça donne quoi probleme visuellement si on a pas ces 2 branch object ?


  10. A few precisions :
    • The JagWire has two modes : the classic BJL one, to replace a parallel port connection, which is compatible with the BJL ROM, the Protector:SE cartridge, and the BJL CD (therefore, also useful to those who do not own the JagCF) ; and a fast communication mode for the JagCF (up to 3 megabits per second).

    so, the jagwire has 2 plug, one for the jagpad and another one for the JagCF ?

    is the JagWire more stable on WinXP than the Dos BJL software under portalk or whatever parallel port winxp driver ? (I hope so ^^)

    since it is compatible without using a JagCF, will the JagWire be available before the JagCF release ?

    if yes, when do you plan to release it ?

    thanks :)


  11. hello !

    voila je suis en train de coder l'invitro pour l'AC2006

    et il ce trouve que j'ai un probleme avec la routine de replay de MusicMon2.5 visiblement

    mon musicien utilise les SID, donc 200Hz et obligation de mettre la routine de replay dans le TimerC

    jusque la aucun probleme, par contre j'ai besoin du TimerB pour switcher de palette au milieu de l'écran

    or la ce pose un probleme...

    a un moment de la musique, ça sacade et on entend plus certaine note, autre probleme que j'ai remarqué

    mon timer B qui est censer s'executer a un endroit bien precis (un numero de ligne a l'écran quoi ...)

    a tendance a "bouger" parfois, c a dire que il s'enclenche pas tout le temps a la bonne ligne :blink:

    je soupçone la routine de replay, vu qu'elle est en 200Hz :/

    quelqu'un a déja eu ce probleme ?


  12. un petit truc que j'avais converti en 68000 d'une routine en C trouvé je sais plus ou :D

    ça marchais asser bien ^^

    resultat dans d0, par contre ça donne un resultat 8bits :D

    ; Un VRAI random :) (pas comme celui du XBios ...)
    myrand:
        move.w    seed8_1(pc),d1
        move.b    0(a0,d1.w),d0
        move.w    seed8_2(pc),d2
        add.b    0(a0,d2.w),d0
        move.b    d0,0(a0,d2.w)
        addq.b    #1,d1
        addq.b    #1,d2
        andi.b    #63,d1
        andi.b    #63,d2
        move.w    d1,seed8_1
        move.w    d2,seed8_2
        rts
    
    seed8_1: dc.w 29
    seed8_2: dc.w 63
    
    random8:
    dc.b 215,25,169,8,231,201,91,15,156,5,152,30,159,50,22,49
    dc.b 28,148,157,123,58,3,156,236,46,78,50,157,186,170,233,138
    dc.b 49,98,215,231,0,249,233,254,194,12,110,115,122,166,15,2,163
    dc.b 237,143,30,54,5,45,199,201,106,184,136,44,175,197,11

×