BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: BT81x and VERTEX2F  (Read 13318 times)

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
BT81x and VERTEX2F
« on: January 25, 2019, 11:28:34 AM »

I am a bit disapointed now that the BT81x still has the handbrakes VERTEX2F und VERTEX2II in place with no alternative.
The need to shift the coordindates into the bit-positions only wastes time.
Especially since by default pixel precision for VERTEX2F is 1/16 - and for whatever reason that is.

Looking thru the user-manual I recognize though that it is just not possible to add a VERTEX3F command.
VERTEX2F is 0x01nnnnnn and VERTEX2II is 0x10nnnnnn, neither a 0x00nnnnnn or a 0x11nnnnnn would work because that would make it indistinguishable from the other commands.
This might be the reason why this has not been touched.

However, there would be a way out.
There are 21 reserved bits in VERTEX_FORMAT.
Bit 3 could have been used to change the format of VERTEX2F:
Bit 0...13 = Y
Bit 16...29 = X

With 1 bit less in resolution as a trade-off the frac-value of 0 would be -8192 to 8191, same as 1 and so the maximum pixel precision would be 1/8 pixel.

Can we have this as a patch please for both the FT81x and the BT81x?
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 733
    • View Profile
Re: BT81x and VERTEX2F
« Reply #1 on: January 25, 2019, 02:28:23 PM »

Hello,

Thank you for your suggestion, it is an interesting approach and one which I will pass on to the development team.

Best Regards,
BRT Community
Logged

pauljiao

  • Jr. Member
  • **
  • Posts: 53
    • View Profile
Re: BT81x and VERTEX2F
« Reply #2 on: January 31, 2019, 09:29:48 AM »

Quote
There are 21 reserved bits in VERTEX_FORMAT.
Bit 3 could have been used to change the format of VERTEX2F:
Bit 0...13 = Y
Bit 16...29 = X

With 1 bit less in resolution as a trade-off the frac-value of 0 would be -8192 to 8191, same as 1 and so the maximum pixel precision would be 1/8 pixel.

I think your idea shall be Bit 2 (starting from Bit 0) ,i.e. the THIRD bit, other than bit 3 is used in VERTEX_FORMAT.
But I do not know what benefit it may bring to you.
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT81x and VERTEX2F
« Reply #3 on: January 31, 2019, 08:37:03 PM »

Nope, bit 3 of VERTEX_FORMAT was correct.
Bit 0..2 are already in use for "frac", although only with a range from 0 to 4.
Bits 3 to 23 are marked as "RESERVED".

While new meaning could be assigned to frac values of 5/6/7, using one of the reserved bits should be more intuitive since the table for the frac values would look very similar to what it is now.

0  1 pixel     -8192 to 8191
1  1/2 pixel  -4096 to 4095
2  1/4 pixel  -2048 to 2047
3  1/8 pixel  -1024 to 1023
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 30
    • View Profile
Re: BT81x and VERTEX2F
« Reply #4 on: February 13, 2019, 06:08:03 PM »

Your goal is to align the coordinates of the vertex instruction on the 16bit boundary, correct?

Something like this may give you some mileage:
Code: [Select]
short x, y;
short xc = (1 << 14) | (x & 0x3FFF);
short yc = (y << 1) & 0x7FFF;
dl32(VERTEX_FORMAT(1));
dl16(yc);
dl16(xc);

Shift one coordinate, and mask the stray bit of the other one.

A more ideal solution then, instead, could be to have a vertex format instruction that sets the precision of each coordinate individually.
« Last Edit: February 13, 2019, 06:33:14 PM by Kaetemi »
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT81x and VERTEX2F
« Reply #5 on: February 16, 2019, 06:48:27 PM »

The goal is to avoid the shifting of bits entirely.

We now have this:

01xxxxxx xxxxxxxx xyyyyyyy yyyyyyyy

This means that the x-coordinate has to be shifted.

Changing the format to this would turn that shifting into a copy operation:

01xxxxxx xxxxxxxx 00yyyyyy yyyyyyyy


This is of couse a non-issue with any static coordinates since the pre-processor should turn that into 32 bit constants already.
This is a bottleneck however when you try to animate things and more than a handfull or coordinates need to be calculated on the fly from variables.
Logged

Kaetemi

  • Newbie
  • *
  • Posts: 30
    • View Profile
Re: BT81x and VERTEX2F
« Reply #6 on: February 18, 2019, 01:33:23 PM »

So imagine a VERTEX_FORMAT(1, 0) that would individually set the precision of your X and Y coordinates. You'd be able to align both your coordinates to the byte boundary, and just mask away the stray precision bit. That may be simpler than having a special purpose vertex format.

Is bit shifting an expensive operation on your target platform?
Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 389
    • View Profile
Re: BT81x and VERTEX2F
« Reply #7 on: February 18, 2019, 06:05:39 PM »

Well, I just tried to went for the solution that would be the easiest to implement and has the least impact.

And yes, bit-shifting of 15 bit values into 32 bit is expensive.
Especially on 8 bit controllers which kind are the designated target for EVE.
But it is also more expensive on 32 bit controllers than just copying the values to where they belong.
Logged