| Polygon Pushing Performance of the 080 | page 1 2 3 4 5 6 7 8 9
|
|---|
|
|---|
| | 
Louis Dias
(Needs Verification)
Posts 55/ 1
17 Oct 2018 14:19
| Fine.
A good TEST would be to port GLFrontier to use AMMX:
EXTERNAL LINK
Yes, this is a reverse-engineered Elite 2: Frontier
Note: there are software renderers in this game which may possibly be used to make an OpenGL api for 68k...Oh and Elite 2 is now shareware...
| |
| | 
Steve Ferrell
Posts 424
17 Oct 2018 19:23
| Louis Dias wrote:
|
Fine.
A good TEST would be to port GLFrontier to use AMMX:
EXTERNAL LINK
Yes, this is a reverse-engineered Elite 2: Frontier
Note: there are software renderers in this game which may possibly be used to make an OpenGL api for 68k...
Oh and Elite 2 is now shareware...
|
Reverse engineering an OpenGL game is not how you develop a 3D API for a platform. There's nothing to reverse engineer. The OpenGL API has already been designed, is well documented, and a subset of it has already been implemented on classic Amigas. It's called TinyGL. See: EXTERNAL LINK
Norbert Kett has been working on optimizing it for the Apollo-Core/AMMX but hasn't posted a progress report in some time. See: CLICK HERE
And here's the source code on Aminet: EXTERNAL LINK
| |
| |
Louis Dias
(Needs Verification)
Posts 55/ 1
17 Oct 2018 21:11
| @Steve Ferrell
Yeah...did you read thru the thread?
One of the "real 3D" games mentioned was Elite 2. Elite 2 is written in ASM. ASM was the direction discussed in that thread otherwise TinyGL would be far too slow. Wazp3D doesn't do perspective rendering... You need to understand that these apis aren't called OpenGL for a reason: they aren't full implementations of OpenGL...Elite 2 is shareware and the Amiga version was used to make ports for other machines. I linked the source code to the GLFrontier port... If only I was 20 (or 30) years younger...I would rip out the rendering code and rewrite what I could to use AMMX... I've only played the CD32 version with a ram expansion(SX-1)...
| |
| |
Steve Ferrell
Posts 424
18 Oct 2018 00:45
| Louis Dias wrote:
|
@Steve Ferrell
Yeah...did you read thru the thread?
One of the "real 3D" games mentioned was Elite 2. Elite 2 is written in ASM. ASM was the direction discussed in that thread otherwise TinyGL would be far too slow. Wazp3D doesn't do perspective rendering... You need to understand that these apis aren't called OpenGL for a reason: they aren't full implementations of OpenGL...
Elite 2 is shareware and the Amiga version was used to make ports for other machines. I linked the source code to the GLFrontier port...
If only I was 20 (or 30) years younger...I would rip out the rendering code and rewrite what I could to use AMMX...
I've only played the CD32 version with a ram expansion(SX-1)...
|
Yes, I read thru the entire thread and you obviously didn't, or you would have seen that I was the last person to post in that thread back in August of this year when I asked Norbert about any updates.
Ripping out the rendering code from a game and trying to use it as the basis for a 3D API for ANY platform is useless. There needs to be a standard, preferably an open standard, that programmers and developers will use instead of something totally proprietary.
And you will never get a full implementation of OpenGL on a classic Amiga, NG Amiga or even for an x86_64 system. It is under constant revision as it is a living standard. Extensions are added continuously.....Please educate yourself in regard to open standards and 3D API's. OpenGL has progressed from even being called OpenGL to being called Vulkan. Its latest features require such things as hardware texture and lighting, etc...things a Vampire will never have unless someone decides to develop a discrete 3D GPU for the Vampire that supports those OpenGL/Vulkan extensions, and that isn't going to happen. The chances that some hardware developer is going to develop a discrete 3D GPU (real or virtual) for a dead platform being replicated in a hobby FPGA board is close to 0.
There are many MODERN platforms even now that don't enjoy a full OpenGL/Vulkan feature-set/extensions and support so why are you complaining about them not being fully supported on a dead platform from 35 years ago that's now just a hobby on an FPGA hobby board?
The best we can hope for on a Vampire is an AMMX accelerated OpenGL 1.2/1.3 with its current limitations. More capable FPGA's in the future might allow for increased compatibility and more extensions, say OpenGL 2.0, or even possibly a virtual 3D GPU, but that's a huge stretch and still a long way off, if ever. So complaining that TinyGL isn't a full OpenGL implementation is just ridiculous, and it never purported to be a full OpenGL implementation. Hence, the name "TinyGL". And why should it? As there isn't any Vampire-specific (or classic Amiga) 3D hardware supporting a full implementation anyway. The version of OpenGL that I'm running right now on my nVidia GTX 1080 is a subset of the latest standard/extensions.
Even if someone ran with your idea of ripping the rendering code from an obscure shareware game to use as the basis for a 3D API on the Vampire, you'd still just have, "GASP", software-only rendering! So no improvement over what we already have now and an API that no developers are familiar with, let alone willing to develop in....not to mention a huge ZERO when it comes to cross-platform portability. And no guarantee that it would be any faster than TinyGL or any other subset of OpenGL.
And I do have something of a clue as to what I'm talking about. I make a damn good living as a software engineer and as owner of a LIDAR mapping and 3D modeling company. EXTERNAL LINK
Ninety percent of my coding is performed in C/C++ and the remaining 10% in other languages. OpenGL is used in over 90% of my apps with the remainder done in Microsoft's GDI, which I try to avoid for cross-platform portability and compatibility reasons.
My most recent foray into Amiga programming was last year when I updated the PLPLOT scientific plotting library to version 5.0.1 for classic Amigas. EXTERNAL LINK
More about PLPLOT: EXTERNAL LINK
| |
| |
Louis Dias
(Needs Verification)
Posts 55/ 1
18 Oct 2018 05:32
| You posted in a thread that hadn't been updated in a year. Congrats to you! You win!
| |
| |
Steve Ferrell
Posts 424
18 Oct 2018 05:58
| Louis Dias wrote:
|
You posted in a thread that hadn't been updated in a year. Congrats to you! You win!
|
Are you really an adult?
| |
| | 
Stephan Hamers
Posts 22
18 Oct 2018 10:28
| Yeah, I think it's getting a bit weird now. And I like reading this forum so you 2 better kiss and make up!! ;)
| |
| |
Louis Dias
(Needs Verification)
Posts 55/ 1
18 Oct 2018 14:35
| Steve Ferrell wrote:
|
Louis Dias wrote:
|
You posted in a thread that hadn't been updated in a year. Congrats to you! You win!
|
Are you really an adult?
|
Are you? Looked like you were wagging your wanker there. I've been a software developer since 1997 and recently completed a project for a client that renders their products based on a product configurator that I wrote using a 3D web api called threeJS (https://threejs.org/) but apparently I don't know anything...
| |
| | 
Andrew Copland
Posts 113
18 Oct 2018 16:32
| This thread is dead, I'm out.
| |
| |
Steve Ferrell
Posts 424
18 Oct 2018 19:54
| Louis Dias wrote:
|
Steve Ferrell wrote:
|
Louis Dias wrote:
|
You posted in a thread that hadn't been updated in a year. Congrats to you! You win!
|
Are you really an adult?
|
Are you? Looked like you were wagging your wanker there. I've been a software developer since 1997 and recently completed a project for a client that renders their products based on a product configurator that I wrote using a 3D web api called threeJS (https://threejs.org/) but apparently I don't know anything...
|
For weeks you kept insisting that adding an AKIKO chip to the Vampire was the way forward in adding 3D capabilities to the Vampire in spite of Gunnar and several other people explaining to you that it wasn't necessary and that an AKIKO chip has nothing to do with 3D graphics. Next, you kept insisting that simply adding a 3D GPU (or other co-processor) to the Vampire was the way forward in spite of the fact that the current Vampire design precludes if from having either a real or virtual GPU. A larger FPGA or a board re-design is required or both. And now you want us to accept that disassembling/reverse- engineering a 2D bitmapped shareware game that is only simulating 3D graphics in 2D and using its rendering code as the basis for a Vampire 3D API is somehow feasible. There's definitely a trend....
| |
| |
Louis Dias
(Needs Verification)
Posts 55/ 1
18 Oct 2018 21:15
| Steve Ferrell wrote:
|
Louis Dias wrote:
|
Steve Ferrell wrote:
|
Louis Dias wrote:
|
You posted in a thread that hadn't been updated in a year. Congrats to you! You win!
|
Are you really an adult?
|
Are you? Looked like you were wagging your wanker there. I've been a software developer since 1997 and recently completed a project for a client that renders their products based on a product configurator that I wrote using a 3D web api called threeJS (https://threejs.org/) but apparently I don't know anything...
|
For weeks you kept insisting that adding an AKIKO chip to the Vampire was the way forward in adding 3D capabilities to the Vampire in spite of Gunnar and several other people explaining to you that it wasn't necessary and that an AKIKO chip has nothing to do with 3D graphics.
Next, you kept insisting that simply adding a 3D GPU (or other co-processor) to the Vampire was the way forward in spite of the fact that the current Vampire design precludes if from having either a real or virtual GPU. A larger FPGA or a board re-design is required or both.
And now you want us to accept that disassembling/reverse- engineering a 2D bitmapped shareware game that is only simulating 3D graphics in 2D and using its rendering code as the basis for a Vampire 3D API is somehow feasible.
There's definitely a trend....
|
I think you have reading comprehension.
I suggested AKIKO since it already included a function to assist with Amiga graphics...so why not add more.Since a lot of these hardware 3D functions are simply software converted to hardware - having the team see a fully implemented API is the only way *the team* will be able to then convert those low level software functions into faster hardware functions. Again - you had a reading comprehension issue. You are correct...there is a trend here...
| |
| |
Stephan Hamers
Posts 22
19 Oct 2018 09:12
| Andrew Copland wrote:
|
This thread is dead, I'm out.
|
I'm in!
| |
| | 
Matthew Burroughs
Posts 59
19 Oct 2018 19:29
| Louis Dias wrote:
|
Fine.
A good TEST would be to port GLFrontier to use AMMX:
EXTERNAL LINK
Yes, this is a reverse-engineered Elite 2: Frontier
Note: there are software renderers in this game which may possibly be used to make an OpenGL api for 68k...
Oh and Elite 2 is now shareware...
|
Would pay for a proper boxed Vampire version.
| |
| |
Steve Ferrell
Posts 424
20 Oct 2018 02:03
| In an effort to get this thread on track, here is an idea about how to optimize polygon processing on the Vampire by using its built-in AMMX instructions to accelerate 3D geometry transforms, AKA changing the position of 3D geometry.
Assuming that the Vampire's version of AMMX is compatible with Intel's MMX instructions, and I seem to remember Gunnar confirming this, we have the PMADDWD instruction available (Packed Multiply and Add). This instruction can perform both a multiply and an add on four 16-bit values simultaneously. Therefore, it is an excellent match for the four-element multiply/adds operation which is needed for 3D geometry transformations.
I am not an assembly coder. I code in C/C++ so my question to Gunnar and others reading this is as follows. Are there any C/C++ optimizing cross-compilers or native 68k compilers available that would allow me to compile the code below using PMADDWD/AMMX without having to rely on _inline assembly calls and hand optimizing? That's something I'd like to avoid if possible.
for (i=0; i<200; i++)
{
R[0] = M[0][0]*V[0] + M[0][1]*V[1] + M[0][2]*V[2] + [0][3]*V[3];
R[1] = M[1][0]*V[0] + M[1][1]*V[1] + M[1][2]*V[2] + [1][3]*V[3];
R[2] = M[2][0]*V[0] + M[2][1]*V[1] + M[2][2]*V[2] + [2][3]*V[3];
}
It would be ideal if there was compiler optimization for AMMX code and an AMMX library that could be linked against. I suspect that the answer is still _inline assembly and hand optimization, but I thought I'd ask.
| |
| |
Steve Ferrell
Posts 424
20 Oct 2018 03:22
| @Lou Dias
I suggested AKIKO since it already included a function to assist with Amiga graphics...so why not add more.
Since a lot of these hardware 3D functions are simply software converted to hardware - having the team see a fully implemented API is the only way *the team* will be able to then convert those low level software functions into faster hardware functions. Again - you had a reading comprehension issue.
You are correct...there is a trend here...
|
I read, comprehend and remember quite well. Now you're being dishonest. Even as far back as July you were saying this to Matt Hey over at AmigaWorld.net EXTERNAL LINK
"@matthey AMMX is great but it still needs to be in a highly parallelized custom chip with access to chip ram that can process 256 triangles at once to compete with N64/PS1/Saturn/Jaguar era machines... Kind of a SuperAkiko that can do C2P on 1024 bytes at once along with AMMXx256... Apparently, I'm an A-hole for bringing this up..." Again, the AKIKO has nothing to do with 3D geometry or pushing polygons. Nor does AMMX need to placed into a custom chip. C2P has nothing to do with 3D transforms. And yes, you described yourself quite well in your comment to Matt.
| |
| |
Steve Ferrell
Posts 424
20 Oct 2018 03:24
| Now, back to pushing polygons on the 080... In an effort to get this thread on track, here is an idea about how to optimize polygon processing on the Vampire by using its built-in AMMX instructions to accelerate 3D geometry transforms, AKA changing the position of 3D geometry.
Assuming that the Vampire's version of AMMX is compatible with Intel's MMX instructions, and I seem to remember Gunnar confirming this, we have the PMADDWD instruction available (Packed Multiply and Add). This instruction can perform both a multiply and an add on four 16-bit values simultaneously. Therefore, it is an excellent match for the four-element multiply/adds operation which is needed for 3D geometry transformations.
I am not an assembly coder. I code in C/C++ so my question to Gunnar and others reading this is as follows. Are there any C/C++ optimizing cross-compilers or native 68k compilers available that would allow me to compile the code below using PMADDWD/AMMX without having to rely on _inline assembly calls and hand optimizing? That's something I'd like to avoid if possible.
for (i=0; i<200; i++)
{
R[0] = M[0][0]*V[0] + M[0][1]*V[1] + M[0][2]*V[2] + [0][3]*V[3];
R[1] = M[1][0]*V[0] + M[1][1]*V[1] + M[1][2]*V[2] + [1][3]*V[3];
R[2] = M[2][0]*V[0] + M[2][1]*V[1] + M[2][2]*V[2] + [2][3]*V[3];
}
It would be ideal if there was compiler optimization for AMMX code and an AMMX library that could be linked against. I suspect that the answer is still _inline assembly and hand optimization, but I thought I'd ask.
| |
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6233
20 Oct 2018 07:15
| Steve Ferrell wrote:
|
so my question to Gunnar and others reading this is as follows.
|
I agree that "3D geometry transformation" is an important part of 3D game calculation.
Also very important part is the "line rasterization". For the 3D geometry using Floating point has several advantages. The FPU is designed for floating point calculation.
APOLLO 68080 has the most powerful FPU of all 68K CPUs.
So we have a working solution here. For "line rasterization" we are working on a New-Subunit of SAGA which does this accelerated. You can imagine this as an build-in VOODOO.
| |
| | 
Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
20 Oct 2018 09:13
| Gunnar von Boehn wrote:
|
For "line rasterization" we are working on a New-Subunit of SAGA which does this accelerated. You can imagine this as an build-in VOODOO. |
Unexpected v4 feature, eh? :-)
Wazp3d supporting it to emulate w3d would be nice add on to SAGA library OR any other way to exploit it. Glad FPU helps, and hope V4 FPU will help some more. Some 3dfx multisample
EXTERNAL LINK
Rasterizing?
EXTERNAL LINK
1990s Voodo Nightmare game :-)
EXTERNAL LINK
| |
| | 
Adam Whittaker
(Needs Verification)
Posts 270/ 1
20 Oct 2018 16:05
| Vojin Vidanovic wrote:
|
Unexpected v4 feature, eh? :-)
Wazp3d supporting it to emulate w3d would be nice add on to SAGA library OR any other way to exploit it. Glad FPU helps, and hope V4 FPU will help some more.
|
why do you have such a hard on for V4 everytime somebody mentions anything you bang on about the v4... the v2 is here now cant you stop for just one second and let us all enjoy V2 - go put your dick in a V4 when they are actually on sale... I wont stop you lol
| |
| |
Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
20 Oct 2018 16:24
| Adam Whittaker wrote:
|
why do you have such a hard on for V4 everytime somebody mentions anything you bang on about the v4... the v2 is here now cant you stop for just one second and let us all enjoy V2 - go put your dick in a V4 when they are actually on sale... I wont stop you lol
|
Mind your language. Because v2 space is almost done with GOLD3/GOLD 2.11 and is very likely new bigger features will be v4 reserved. Only main 080 core MMX will remain the same in v2 and v4. Might be wrong here, but if this SAGA improvement comes to v2 GOLD3, it will be nice premium.
The other main reason is that V2 is not avail standalone, and my A1200 died quite long ago.
Plus looking forward to progress. Enjoy V2.
| |
|
Information about the Apollo CPU and FPU.