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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rudolph

Pages: 1 ... 25 26 [27]
391
Discussion - EVE / Re: BT81x and VERTEX2F
« 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.

392
Discussion - EVE / Re: ASTC viewer?
« on: February 16, 2019, 07:24:36 PM »
Thanks for the tip!

It is a bit of work to set it up, especially since the screen editor keeps forgetting where it got the last picture from.
But it allows for a nice side-by-side comparision of the same image using different levels of compression.
So in a way, this is even better than a viewer.


And regarding the blob, I am asking because
a) one might want to use the flash functions of the BT81x and write to the flash directly
b) I wonder what happens if I change the 64MBit flash that comes pre-installed with a module to a bigger one

393
Discussion - EVE / Re: BT81x and VERTEX2F
« 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.

394
Discussion - EVE / ASTC viewer?
« on: February 09, 2019, 10:24:03 AM »

395
Discussion - EVE / Re: BT81x and VERTEX2F
« 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

396
Discussion - EVE / 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?

Pages: 1 ... 25 26 [27]