Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running OCS/AGA/RTG Demos

Playing Around With High Quality Texture Mappingpage  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
11 Dec 2017 11:30


Last night we started to play around with some texture mapping code.

Here is a very early result:
CLICK HERE 
The screen is rendered in 640 pixel width.
The texture routine uses bilinear texture filtering.
EXTERNAL LINK 
more to come


Stefano Briccolani

Posts 586
11 Dec 2017 12:08


Great work, Gunnar!
You're becoming the Jay Miner of the new millennium!


Mallagan Bellator

Posts 393
11 Dec 2017 14:56


That’s nice. That could lead to something really good


Manuel Jesus

Posts 155
11 Dec 2017 19:00


man... that texture instruction would look really nice pushing tie fighter textures around the screen in real time.... just sayin.



Niclas A
(Apollo Team Member)
Posts 219
11 Dec 2017 20:14


Why is there an AROS mouse pointer in the left upper corner? :)


Simo Koivukoski
(Apollo Team Member)
Posts 601
11 Dec 2017 20:35


It's our HW mouse pointer. I liked it more when it was a pink block.


Thellier Alain

Posts 141
12 Dec 2017 09:41


Nice
Does it mean that AMMX2 will have a texturing instruction ?
Something like RGBA=GetTexel(tex,u,v); ?




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
12 Dec 2017 10:25


thellier alain wrote:

Nice
Does it mean that AMMX2 will have a texturing instruction ?
Something like RGBA=GetTexel(tex,u,v); ?

 
Yes AMMX2 has texture ASM instructions.
 
A) DTX1
This instruction does extract one RGB texel from a DTX1 compressed texture surface.
   
B) PIXMRG
This instruction does linear interpolate 2 RGB texels.
 


Niclas A
(Apollo Team Member)
Posts 219
12 Dec 2017 16:48


Simo Koivukoski wrote:

It's our HW mouse pointer. I liked it more when it was a pink block.

Lol yes sounds much better :D i like pink.


Daniel Sevo

Posts 299
12 Dec 2017 18:37


Gunnar von Boehn wrote:

thellier alain wrote:

  Nice
  Does it mean that AMMX2 will have a texturing instruction ?
  Something like RGBA=GetTexel(tex,u,v); ?
 

 
  Yes AMMX2 has texture ASM instructions.
 
  A) DTX1
  This instruction does extract one RGB texel from a DTX1 compressed texture surface.
   
  B) PIXMRG
  This instruction does linear interpolate 2 RGB texels.
 

Not to be a wise ass, but its called DXT1 not DTX1 ;-)
Originally developed by S3 then adopted by Microsft as Direct X texture compression.. Couple of diferent algorithms depending on if you need to store alpha etc.. Hence DX..T..




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
12 Dec 2017 21:08


Little update

Video:

CLICK HERE 
The above video uses compressed textures.
In real time the texels are decompressed and bilinear filtered to create calculate screen.

Screen resolution is 640 Width.
Screen bitdepth is 16bit HICOLOR

The ASM rasterizer loop was tuned to be benefit from Super-Scalar and Fusing better, as you can see framerate is very smooth now.


Gregthe Canuck

Posts 274
12 Dec 2017 22:49


Very nice update.
 
Is this taking up all the core horsepower? Or... is the frame rate being limited?


Steve Ferrell

Posts 424
12 Dec 2017 22:58


Fantastic!  Maybe some talented programmer can give us a rotating textured cube demo. It's nice to see so much progress in Amiga Land after decades of stagnation.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 00:10


gregthe canuck wrote:

  Very nice update.
   
  Is this taking up all the core horsepower? Or... is the frame rate being limited?
 

 
The code needs relative much horse power.
 
The screen is 640x360.
Per rendered pixel, 4 texels (pixels) are loaded from compressed texture (memory), and uncompressed to RGB.
These 4 RGB values are mixed together and create the final Pixel color, for this they are weighted according to the subtexel coordinates.
 
With "normal code" several hundred instruction per rendered pixel are needed. A normal 68060 CPU would with this complex algorithm reach less than 1 FPS.
 
 
On the 68080 I use for this demo some new instructions - this help a lot to make it both look good and run faster.
 
But wrote the current raster texture code in 2 days.
There is certainly more room for improvement and tuning.
I'm sure the code can run 25% faster if better tuned.


Simo Koivukoski
(Apollo Team Member)
Posts 601
13 Dec 2017 00:17


Testing AMMX2 texture instructions:

EXTERNAL LINK


Gregthe Canuck

Posts 274
13 Dec 2017 00:59


Gunnar von Boehn wrote:

With "normal code" several hundred instruction per rendered pixel are needed. A normal 68060 CPU would with this complex algorithm reach less than 1 FPS.

That really shows how much benefit there is in the new core architecture combined with AMMX2.

Texture handling is a big deal for some games... these code samples/demo will help out with that going forward.



Gregthe Canuck

Posts 274
13 Dec 2017 01:00


Steve Ferrell wrote:

... It's nice to see so much progress in Amiga Land after decades of stagnation.

Absolutely! This team is rocking!


Thellier Alain

Posts 141
13 Dec 2017 10:00


>These 4 RGB values are mixed together and create the final Pixel color, for this they are weighted according to the subtexel coordinates.

So it still need much cycles : something like 4 x DTX1 and 3 X PIXMRG plus various ratio computing for weighting
A builtin AMMX function like ARGB=GetFilteredTexel(tex,u,v); will be more usefull

Also not all textures are DXT1 format nor RGB only : I mean reading a standardized ARGB texel from any format will be much more usefull
Same apply for writing pixels




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 10:47


thellier alain wrote:

So it still need much cycles : something like 4 x DTX1 and 3 X PIXMRG ...

Obviously it needs several cycles.
The operation does several Memory/Cache operations, therefore it by nature will have to need several cycles.

thellier alain wrote:

A builtin AMMX function like ARGB=GetFilteredTexel(tex,u,v); will be more usefull

Don't confuse routines with ASM instructions.
Having macro ASM instruction taking several cycles would not be good. The best solution is having key element instructions in ASM, which allow you to solve big problem by putting several ASM instructions together.

 
thellier alain wrote:

Also not all textures are DXT1 format nor RGB only : I mean reading a standardized ARGB texel from any format will be much more usefull
Same apply for writing pixels

Programming is done in layers.
The CPU has to provide the Key-elements.
On top of those you build routines
On top of those you build libraries,
on top of those you can build applications or programs.

The optimal CPU gives you powerful key elements - which execute fast.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
13 Dec 2017 11:05


thellier alain wrote:

So it still need much cycles : something like 4 x DTX1 and 3 X PIXMRG ...

Obviously it needs several cycles.
The operation does several Memory/Cache operations, therefore it by nature will have to need several cycles.

thellier alain wrote:

A builtin AMMX function like ARGB=GetFilteredTexel(tex,u,v); will be more usefull

Don't confuse routines with ASM instructions.
Having macro ASM instruction taking several cycles would not be good. The best solution is having key element instructions in ASM, which allow you to solve big problem by putting several ASM instructions together.

 
thellier alain wrote:

Also not all textures are DXT1 format nor RGB only : I mean reading a standardized ARGB texel from any format will be much more usefull
Same apply for writing pixels

Programming is done in layers.
The CPU has to provide the Key-elements.
On top of those you build routines
On top of those you build libraries,
on top of those you can build applications or programs.

The optimal CPU gives you powerful key elements - which execute fast.

Lets make some clearer examples.
The 68K architecture offers powerful "key-element" instructions like:
  MUL for doing a MULTIPLICATION,
  DBRA for doing a Decrementing of a counter, Comparing, and Looping

The goal is to make those powerful key functions fast.
68080 for example does a DBRA instruction in 0.5 cycles.
This is optimal.

Some RISC CPUs lack such powerful key instruction and need several instructions and several cycles to do the same. This makes these RISC CPUs cheaper, but also weaker.

The point of AMMX is to offer re-usable and extremely powerful instruction -  which execute each in 1 cycle each or less.
So having a PIXMRG instruction which executes in 0.5 cycles is optimal. You can combine several of those in your programs to solve bigger problems. This gives to programmer to flexibility so solve many problems and to decide which solution the programmer prefer to have.



posts 33page  1 2