SebRmv
-
Posts
1,553 -
Joined
-
Last visited
-
Days Won
1
Posts posted by SebRmv
-
-
I don't have linux nor any idea of how to port the zerosquare's routines on linux ^^
it seems that it doesn't work on win98, does any one can test it and tell me if it's working for him ? (on xp or 98 ?)
because if the pack only work on my computer, that's a bit useless :/
Maybe I can try to hack it myself.
I guess an ATARI version would be cool also.
-
Hello there !
I just got a JagCD from someone and the first think I tried to do was trying to encrypt a CD using the BJL version of Matthias Domin Encryption program.
But this need a serial cable that you plug in the dsp port and this need a jaglink, and I don't have this hardware.
So I tried to save some money and soldering pain, and used the "mini debugger" source of Zerosquare that allowed me to dump the Jaguar memory to a file on my PC. I then patched the program of matthias to disable uart and xmodem transfer, as well as joypad reading that was disturbing BJL transfer, and added the BJL transfer routines from Zerosquare instead of the uart/xmodem routines.
and here is the result, a really easy to use "one-double-click-encryption" pack
which allow you to encrypt a cd using your jagcd and the BJL only just by double clicking on a batch file that does the job for you.
I would like to thanks Zerosquare and Matthias Domin for their great job that allowed me to do this pack.
Enjoy !
ps: This works only with a parallel port at $378, on XP or 98
Great job!
And what about a linux version ?
-
eh oui, bon anniversaire M Boss
-
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?
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))
-
[edit : "The data registers may only be
written to while the Blitter is idle." page 70/141 of the Jag_v8 documentation]
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?
-
I was playing a bit with the blitter today and I tried to do a line routine using the blitter (in 68k, but just for blitter-understanding purpose)
and I came up with this nice little screen that can be used as a screensaver
200 lines, redrawn each time (the VBL is almost full but the code is over-VBL-jump proof so it will only be slower in 60Hz I suppose)
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?
-
Bon Anniversaire Seb !
Vive Jagopedia !
ps : même ton équipé préférée a tout fait pour que tu sois heureux aujourd'hui !
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 )
-
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
-
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?
-
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
-
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
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
-
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)
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 !!!
-
I think a lot of commercial Jag games were done in C -- Doom had a lot of C (custom GPU compiler notwithstanding). C code on the 68k purely is never going to be anywhere near the Jag's top performance, but that doesn't mean it can't do a game. Seb's library is a good step in that direction since it accelerates low level details for you, reducing the impact.
I'm curious about your plans for the lib, Seb?
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
-
Yes, that's a very good idea. I think the better the dev environment, the more people might want to use it.
And it's especially important to get rid of the "C is too slow" rumor. Afterall there are plenty of game ideas where C is probably fast enough.
I'll try it out as soon as I can.
Regards, Lars.
Exactly. I also think that C is sufficient for many games.
The trick is that the goary stuff is made in assembler (GPU/DSP/68k) and is part of the lib.
Thus this is still sufficiently efficient.
Note also that assembler's addicts may also use my lib. It is not a "C only" thing.
Cheers & Merry Christmas
-
Better late than never !!
Happy birthday Ovalbugman !!
GT
Same thing here
Happy birthday man
-
Hi Lars!
That's very cool news if you consider using my own library
Concerning your questions about Visual Studio, I cannot really answer to these since I develop mainly with my linux distro.
With linux, you can simply download my shell script that builds a gcc cross compiler to generate 68k code.
ie download and run:
http://removers.free.fr/softs/archives/mk_xgcc.sh
then you can get a source distrib of my libs, ie download
http://removers.free.fr/softs/archives/jlibc-0.5.1.tar.gz
http://removers.free.fr/softs/archives/rmvlib-1.1.2.tar.gz
and build them (in this order)
I assume the path you will use are the same as mine
(I know there is an issue in the Doxyfiles that states explicitly an absolut path on my system )
To build, simply run ./build.sh (that are in the archives)
Then, you can start using my library.
I have already coded some small examples to illustrate how to use it.
The sources are downloadable at my website:
http://removers.free.fr/softs/download.php
About a documentation of the library, I have started to document the code
and use doxygen to generate an HTML doc. This is browsable at the following
urls:
http://removers.atari.org/doc/jlibc/
http://removers.atari.org/doc/rmvlib/
I know this documentation is not perfect (far from that), but I hope it can already
help programmers to become familiar with the library.
I am currently writing a more technical document to explain the internals
of the library (and in particular the sprite manager that is going to evolve
quite a bit soon [i hope Christmas vacation will be sufficient to implement all my ideas])
Anyway, I would be pleased to answer all your questions and hear your suggestions.
Maybe it is a good idea to open a new part in this forum (or elsewhere) so that users
can discuss about the library.
Cheers
Seb
Gt Is The Man Of The Day
in Random chatter
Posted
Bon anniversaire GT!
Vivement que tu mettes le turbo