Jump to content
Jagware
Sign in to follow this  
Tursi

Jagcode 2 Entries

Recommended Posts

Tursi    0

I'm a little surprised that nobody here has even mentioned their JagCode work! Since it's a different environment than JS2 I was expecting a different, maybe more technical, conversation. :)

 

Anything to be said guys? :) SPCPD, want to talk about your OP processor? (I'm curious about how much work it was to get that many moving objects on the spiral screen). Orion, any thoughts on building your poly engine? Anyone know who did The MAXX?

 

Share this post


Link to post
Share on other sites
Zerosquare    10
I'm a little surprised that nobody here has even mentioned their JagCode work!
We did discuss quite a bit, but that was on IRC. And as Pocket said, we did reply to a few questions on yAronet. Feel free to ask about anything specific you want to know. :)

 

Anyone know who did The MAXX?
I know who he is (I offered to make a video capture of his game and have it posted on Youtube), but since he replied privately, I assume he wants to remain anonymous until the voting is over. I'll just say that he's a newcomer to the Jag scene, AFAIK.

Share this post


Link to post
Share on other sites
SCPCD    0
I'm a little surprised that nobody here has even mentioned their JagCode work! Since it's a different environment than JS2 I was expecting a different, maybe more technical, conversation. :)

 

Anything to be said guys? :) SPCPD, want to talk about your OP processor? (I'm curious about how much work it was to get that many moving objects on the spiral screen). Orion, any thoughts on building your poly engine? Anyone know who did The MAXX?

:)

 

The difficulty when we have so many sprites, is that the OP takes many bandwidth to the DRAM so we have not so many time to create the Object List.

For exemple, in NTSC, there is 25 blanking line and 244 visible line.

so if we push the OP to it's limit you can not access to the DRAM during 244 line and we have only 25 line to create the next list and all other things.

The next limitation is to do a OP list that don't take more than 63.55µs to reach the STOP object else there will be glitch on screen.

 

About technical choice on FACTS :

 

With a logic analyzer we can see that the object processor have a quicker data access for the 2 first phrase of bmp data (due to pipeline effect).

So I have the choice between 4x4 sprites and 8x8 sprites.

 

With 4 width sprites, the OP read the BMP header and the first line of the sprite in 14 cycles (@26.59MHz) so in 63.55µs we could have 63.55µs*26.59MHz/14 = 120 sprites per line. (and the RMW mode doesn't take more cycle with this sprite size \o/)

but create a list of 244 line of 120 sprites is impossible :D and 1 line by sprite is to difficult to manage.

It's more interesting to have square sprite :)

That's why I have cut the sprite list in 60 band of 4 lines (=244 visible line) :)

But like I said before, we can have 120 sprites per line so about 120 sprites into the band. (because the OP should have finished the band in 63.55µs ;))

 

The next thing to think about is the case of sprite that is between 2 band, and for that there is 2 solution :

- cut the sprite and add it to both band

or

- the OP read 2 band by line so it can finish to draw previous sprite.

 

I have chosen the 2nd one, because it's the one that take less CPU time.

 

Then to have the maximum bandwidth for the GPU and the OP we should limit the use of the DRAM by the DSP and the 68k, for that in the demo the 68k are stopped and the DSP don't use the DRAM to generate the sound (thanks to zerosquare ! \o/)

 

With so many sprite, we have no choice than to create 2 sprites list ;)

And we need also many memory space :D

 

For the demo, the sprite list takes about 256kbytes of memory. :whistling:

 

 

 

In the spirale part, the GPU compute about 2688 sprites coordinate but all these sprites are not visible (about 1900 are always visible and up to 2090 visible) :)

There is about 135 GPU cycle to add a sprite to the list. It's a very optimised code : {read sin/cos value, compute coordinate x/y, clipping x/y, compute bmp header, append the sprite to the list} for each sprites :)

 

To draw spirale and move it with this precision, there is a very accurate cos/sin table :)

 

All GPU code takes about 2kbytes and there is about 2kbytes of table for the glass effect and there is only 4 free bytes into the GPU memory ! :D

I used also some tricks for the GPU code like automodifying code to reduce the size of the GPU code :)

 

 

 

----------

I think that my post is not easy to read, It is late and I'm not good in english, so if you have any question, I will answer ;)

Share this post


Link to post
Share on other sites
Tursi    0

Your post is great, SCPCD, thanks for going into such detail for me. I was definately curious and you answered my question very well. :)

 

After watching your spirals again and again, I found myself wondering whether you could get anything more out of the memory bandwidth by inlining your Bitmap objects with the OPL itself... potentially to reduce page hits - each object header would lead right into the bitmap graphics for that object and in most cases at least the first bit would be on the same page of DRAM. Since Bitmap objects have a link address anyway, you easily skip the data for the next object. (This approach does not lend itself to a dynamic list, though).

 

Based on what you say about the author of The MAXX, Zero, I think I offended him (assuming 'he') and he's the one who mailed me at JSII, cause I sure didn't recognize his name. :) To be honest when I saw it under Virtual Jaguar I was a lot more impressed than under Project Tempest - it's nicely polished for what it does. If he could snag a license he could make a killer game there.

 

 

Share this post


Link to post
Share on other sites
SebRmv    2
The next thing to think about is the case of sprite that is between 2 band, and for that there is 2 solution :

- cut the sprite and add it to both band

or

- the OP read 2 band by line so it can finish to draw previous sprite.

 

I have chosen the 2nd one, because it's the one that take less CPU time.

 

Interesting. But this works just because you know that any sprite is at most on two strips, doesn't it?

 

Share this post


Link to post
Share on other sites
SCPCD    0

I have dimensioned the band to have the same height than a sprite, consequently each sprite is in one or 2 band :)

 

Share this post


Link to post
Share on other sites
SebRmv    2
I have dimensioned the band to have the same height than a sprite, consequently each sprite is in one or 2 band :)

 

Yes. Ok. Thank you for the details :)

 

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  

×