Jump to content
Cyprian_K

Graphics Processor Object

Recommended Posts

Does YPOS matter in case of GPU Object?

I'd like to invoke an GPU Object interrupt in exact line.

I tried value 0, 100, and $7FF and for all of them interrupt is generated every line.

888367571_Jag_GPUOBJ.thumb.png.33b35d4c18f8850ae18090f15da83e69.png

 

Should I use branch then?

 

 

Share this post


Link to post
Share on other sites
12 minutes ago, Cyprian_K said:

Does YPOS matter in case of GPU Object?

I'd like to invoke an GPU Object interrupt in exact line.

I tried value 0, 100, and $7FF and for all of them interrupt is generated every line.

888367571_Jag_GPUOBJ.thumb.png.33b35d4c18f8850ae18090f15da83e69.png

 

Should I use branch then?

 

 

Hardware bug, GPU Objects fire on every line.

Workaround: Use two BRAnch OBJects before it (Less than/Greater than)

  • Like 4

Share this post


Link to post
Share on other sites

In the most up to date JTRM, the YPOS for GPU Object was removed.

In the netlist, there is no use of YPOS for Gpu object (the state machine always execute gpuint).

 

I think I have read somewhere that this feature was removed from the specification and replaced by the use of branch object.

 

 

Edited by SCPCD

Share this post


Link to post
Share on other sites
On 9/29/2020 at 8:15 PM, SCPCD said:

In the most up to date JTRM, the YPOS for GPU Object was removed.

In the netlist, there is no use of YPOS for Gpu object (the state machine always execute gpuint).

 

I think I have read somewhere that this feature was removed from the specification and replaced by the use of branch object.

 

 

Big mistake, it's easier to write a GPU object with YPOS and even HEIGHT than adding more objects to the list.

 

I think that they never asked to some game developers (where's the vertical mirror in bitmapped objects?...)

Share this post


Link to post
Share on other sites
1 hour ago, swapd0 said:

Big mistake, it's easier to write a GPU object with YPOS and even HEIGHT than adding more objects to the list.

 

I think that they never asked to some game developers (where's the vertical mirror in bitmapped objects?...)

Got to argue this.

Branch objects allow splitting the screen into horizontal segments, reducing the length of the list, allowing far more complex games to be written.

The bullets in P1 (Yeah, not a great use of the harware, LOL) and the TileMaps in the RAPTOR API use branch objects to vastly reduce the OP load and execution time per line.

Share this post


Link to post
Share on other sites

I wonder why BITMAP has LINK address. It's obvious in case of BRANCH because of flow control.

Is it any useful case for adding it to BITMAP?

Share this post


Link to post
Share on other sites
On 10/14/2020 at 10:10 PM, Cyprian_K said:

I wonder why BITMAP has LINK address. It's obvious in case of BRANCH because of flow control.

Is it any useful case for adding it to BITMAP?

Well, you always need to indicate the OLP where the next object is.

And the next object could be anywhere (PHRASE aligned) in memory.

 

 

  • Like 2

Share this post


Link to post
Share on other sites
On 10/15/2020 at 6:40 AM, Cyprian_K said:

I wonder why BITMAP has LINK address. It's obvious in case of BRANCH because of flow control.

Is it any useful case for adding it to BITMAP?

Height sorting objects into horizontal bands to reduce Object Processor load.

Share this post


Link to post
Share on other sites
9 hours ago, CyranoJ said:

Height sorting objects into horizontal bands to reduce Object Processor load.

But to do that, you create a tree with branch objects at the start, then each node points to an array of objects, you should never use the link address of an object to point to an object of a different band.

 

Or maybe there are a different approach? 

 

This is in my TODO list, because many times I have no free cycles for the 68000.

 

Share this post


Link to post
Share on other sites
25 minutes ago, swapd0 said:

But to do that, you create a tree with branch objects at the start, then each node points to an array of objects, you should never use the link address of an object to point to an object of a different band.

In that case the latest object in that band is linked to a stop object. 

Share this post


Link to post
Share on other sites
13 hours ago, swapd0 said:

But to do that, you create a tree with branch objects at the start, then each node points to an array of objects, you should never use the link address of an object to point to an object of a different band.

You would only do that if you plan on building an entirely new list every frame, which raptor does not do.  It is perfectly fine to "cross-stitch" objects for the most efficient display order, or skip over unused objects in a pre-built list.

See: Dynamic Culling in the RAPTOR manual.

Share this post


Link to post
Share on other sites
On 10/14/2020 at 9:10 PM, Cyprian_K said:

I wonder why BITMAP has LINK address. It's obvious in case of BRANCH because of flow control.

Is it any useful case for adding it to BITMAP?

Most objects can follow one another eg BITMAP Object then another BITMAP Object as they can be aligned to 16 bytes but you can get a BITMAP Object followed by a Scaled Bitmap Object - which needs to be aligned to 32 bytes. So you can get a gap between them.

0 ->15 Bitmap Object

15->31 Empty Space

32->47 Scaled Bitmap Object

48->63 Empty Space
64->79 Scaled Bitmap Object
 

 

  • Like 1

Share this post


Link to post
Share on other sites

Yes, but if you remove the LINK field you could fit the scaled bitmap object into 16 bytes, and you won't need to align them to 32 bytes.

Share this post


Link to post
Share on other sites
1 hour ago, swapd0 said:

Yes, but if you remove the LINK field you could fit the scaled bitmap object into 16 bytes, and you won't need to align them to 32 bytes.

And then if you want to change, say object 6, how do you calculate the offset to it if they're all different sizes....

Share this post


Link to post
Share on other sites

All objects have different sizes (STOP, BRANCH & GPU 8 bytes, BITMAP 16 bytes, SCALEDBITMAP 32bytes), with my scheme (STOP, BRANCH & GPU 8 bytes, BITMAP & SCALEDBITMAP 16 bytes).

 

If you are following the list to calculate the offset, you'll do the same but if you find a BITMAP or SCALEDBITMAP object you know that the next one is 16 bytes behind.

 

 

Share this post


Link to post
Share on other sites
11 hours ago, swapd0 said:

All objects have different sizes (STOP, BRANCH & GPU 8 bytes, BITMAP 16 bytes, SCALEDBITMAP 32bytes), with my scheme (STOP, BRANCH & GPU 8 bytes, BITMAP & SCALEDBITMAP 16 bytes).

 

If you are following the list to calculate the offset, you'll do the same but if you find a BITMAP or SCALEDBITMAP object you know that the next one is 16 bytes behind.

 

Kind of missing the point, if you are 'following the list' you are wasting cycles encoding/decoding a chain that doesn't even need to be calculated, as you can bit shift to the correct object with fixed sizes.

Share this post


Link to post
Share on other sites
14 hours ago, swapd0 said:

Yes, but if you remove the LINK field you could fit the scaled bitmap object into 16 bytes, and you won't need to align them to 32 bytes.

Which then complicates the silicon as it now needs to handle phrase and qphrase alignments, means an extra address line too, just so you can save a few bytes of RAM? doesn't seem like a worthwhile trade of.  I'm no silicon engineer, but I am pretty sure that things that seem trivial or simple in code are not going to be as simple or trivial to implement in silicon, added complexity I would imagine leads to greater chance of bugs in the hardware, more transistors needed etc, and if you are close to budget not everything is possible.

Share this post


Link to post
Share on other sites

My idea was to make the code more simple not to save RAM, in my sprite routines when I've to draw a scaled bitmap I've to align it to 32 bytes and change the link address of the last object.

 

But maybe there's a better approach.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji 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.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...