TSI include, new image file format

[DoubleDutch]

Do you have a check to ensure the instructions are available for the processor, if not then a fallback?

[Thorium]

Do you have a check to ensure the instructions are available for the processor, if not then a fallback?

Yes.
It even checks if the CPUID instruction is available. So the code will even run on a 386. ^^
Even if i don't think it makes much sense to use it on a 386.

In detail:
With the 0.3 version of the TSI include you will have to call Tsi_Init() one time befor you use any procedure of it. The init procedure will first check if the CPUID instruction is available, if not it will disable MMX and SSE2 using.
If CPUID is available it will check if MMX and SSE2 are available.
After that the procedures will dynamicaly choose which implementation to use: MMX, SSE2 or simple assembler. Depanding on what your CPU is supporting. This checks are only done on x86. For x64 we can assume that every CPU is at least supporting SSE2.

[DoubleDutch]

I think one of the VIA x64 chips may not support SSE2, not sure though.

[Thorium]

I think one of the VIA x64 chips may not support SSE2, not sure though.

Thanks for the info. I searched on the VIA website for informations about that but don't find anything reliable. So i will build in a check for x64.

I even not found a real technical document or manual on the VIA website. o.O
The white paper says just nothing with much words.

3.4 High Performance Media Computation
The VIA Nano processor places significant emphasis on high-performance floating-point execution. It can execute four floating-point adds and four floating-point multiplies every clock. It uses a completely new algorithm for floating-point adds that results in the lowest floating-point add latency of any x86 processor—two clocks for any format (SP, DP, DE, packed or scalar). Similarly, the floating-point multiplier has the lowest latency of any x86 processor—three clocks for SP multiply, and four for DP and DE.
In addition, the integer data path for SIMD integer (SSEx) instructions is 128-bits wide, and almost all SSEx instructions (including all shuffles) execute in only one clock.

That says exacly nothing about the supported instruction sets.

[ts-soft]

All VIA C7 and higher supports SSE2

[Thorium]

All VIA C7 and higher supports SSE2

Hm ok.
I decided to but in a check for x64 anyway. It don't hurts performance and it's just a few bytes in code size. So there will be no surprise if someone actualy have a x64 CPU that is not supporting SSE2. I even don't knew that VIA makes CPU's until DoubleDutch wrote about it.

[DoubleDutch]

Thats a good idea, there are all kinds of companies doing 'compatibles' that may not be fully compatible.

[mar]

Great work!

What image depth does it support?
Is it also possible to decode 16 bit gray images?

Mar

[Thorium]

Great work!

What image depth does it support?
Is it also possible to decode 16 bit gray images?

Mar

Only 32bit true color plus alpha channel at the moment.
If there is interesst i can add more modes.

[blueznl]

If it's explicitly for games, and to load stuff at maximal speed, then I wonder why it would have to offer support for other formats... Is there something I'm overlooking?

[Thorium]

If it's explicitly for games, and to load stuff at maximal speed, then I wonder why it would have to offer support for other formats... Is there something I'm overlooking?

Well grayscale is special because it is used for height maps, for 3D terrain creation. So it would fit the purpose of the TSI format.

At the moment i think i will not build in indexed colors (1/2/4/8 bit depth). Because this depths tend to be very slow on new graphic cards. Well new is relative, this is a fact for a some years now. It would make sense to save a image with less than 257 colors as indexed to reduce file size and convert it back to 32bit on decoding. But there will be no need for that if my compression is ready. It should take care of that problem.

[DoubleDutch]

3+1 (2 bit), 7+1 (3 bit), 15+1 (4 bit), etc up to 255+1 (8-bit) are popular game image formats because they can be used with palettes.

[Thorium]

3+1 (2 bit), 7+1 (3 bit), 15+1 (4 bit), etc up to 255+1 (8-bit) are popular game image formats because they can be used with palettes.

That was a long time ago. Using palettes today does nothing else than slowing your game down.

[DoubleDutch]

But it makes easy work of creating new objects - just by changing palettes - you can them copy them to 32 bit images.

[Thorium]

But it makes easy work of creating new objects - just by changing palettes - you can them copy them to 32 bit images.

Of course, i don't thought about that.
Then it's the questen if i add support for indexed colors if i add support for multiple palettes in a single file.