Playing Around With High Quality Texture Mapping | page 1 2
|
---|
|
---|
| | Gunnar von Boehn (Apollo Team Member) Posts 6253 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 143 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 6253 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 6253 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 6253 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 143 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 6253 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 6253 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.
| |
|