Graphics Processor Object

[Cyprian]

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.

 

Should I use branch then?

 

 

[+CyranoJ]

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.

 

Should I use branch then?

 

 

Hardware bug, GPU Objects fire on every line.

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

[Cyprian]

ok, thanks

[SCPCD]

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 September 29, 2020 by SCPCD

[Cyprian]

1 hour ago, SCPCD said:

In the most up to date JTRM

do you mean this one http://www.jagware.org/jag_uploads/dev/docs.zip?

[SCPCD]

Yes exactly.

 

[swapd0]

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?...)

[+CyranoJ]

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.

[swapd0]

Yes I know that, but IMO it's a waste of time to use a branch object to skip a GPU Object.

[Cyprian]

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?

[matmook]

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.

 

 

[+CyranoJ]

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.

[swapd0]

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.

 

[matmook]

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. 

[+CyranoJ]

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.

[Seedy1812]

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
 

 

[swapd0]

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.

[+CyranoJ]

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....

[swapd0]

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.

 

 

[+CyranoJ]

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.

[LinkoVitch]

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.

[swapd0]

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.