SebRmv

bon anniv' pmdata

It does not seem to work.

Is this resolved?

Bon anniversaire GT! Vivement que tu mettes le turbo

Maybe I can try to hack it myself. I guess an ATARI version would be cool also.

Great job! And what about a linux version ?

eh oui, bon anniversaire M Boss

I know I can hack myself the code Anyway, it seems that you can emulate the division unit of the GPU/DSP by doing q = a/b REMAIN = a%b if (q & 1) == 0 then REMAIN-=b; For the 16.16 division, it is simply the result of dividing (a << 16) by b (48 bits integer for (a << 16))

Yes, I have seen that also in the doc. So this could mean that some of the registers are double buffered (in particular, almost all of the address registers) Does anybody have tested this?

cool

Ok, not really related but I have a question about the blitter: do the registers are double buffered? (this would mean that we can prepare the next blit while the current one is being completed) if yes, which ones exactly?

bien vu

Merci les amis Zero: sacrés perroquets

Thanks for this! Does this work also on 60 Hz Jag? (this may explain why I was unable to test it on my Alpine )

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

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

Thanks for this. Do you emulate the GPU pipeline also? About division, how do you emulate 16.16 division? What is a 16.16 division? Do you also emulate that the G_REMAIN does not necessary contain the remainder but a value that permits to compute the remainder?

Yes, there are some examples (with videos) on the page. Since the API has not changed, I have not updated the examples though. Cheers

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

Hello, finally, I finished the work I wanted to do on the sprite manager. I have just released the source code (v 1.1.4). The changes are transparent for users but internally the display manager has been entirely rewritten. Now, the OP list is divided in 8 lists and branch objects are used to optimise bus access. I have made some quick tests and managed to reach about 480 sprites at 60 Hz and 570 sprites at 50 Hz. In practice, I think that 350-400 sprites is more reasonable.

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?

Happy new year !!!

Well, I have to find some time to spend on this (I am playing a bit too much during these holydays...) but I hope the new sprite manager will be ready for january 2008 I'll give more details when it will be about to be released. (but I really hope this will work as I expect)

un peu en retard mais un très bon anniversaire MK

Merry Xmas ! If only Santa Claus could bring me a JagCF