Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

OpenGL On Vampire Cardspage  1 2 3 4 5 6 

Asaf Ayoub

Posts 26
18 Mar 2017 22:47



Maybe a command similar to Cuda Lop3 could help.

8.7.7.6. Logic and Shift Instructions: lop3

Compute logical operation on inputs a, b, c and stores result in destination d.

http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#axzz4bihuGGFT



Thellier Alain

Posts 116
20 Mar 2017 14:01


@Gunnar

I dont have the time to go IRC just to found some informations

Note: we can also use fixed size 16.16  for clipping: I have just implemented it yesterday in my PatchCompositeTags program and it works fine
Here it is the code for cutting a segment A---B between two points  at a given limit to a new point P using integers only

A-------|-------------B
        limit

result is

A-------P

(This dont include the test poly (in/out screen) nor the full clipping code that every GL implementation already have)

#define CUT(val)    P->val= A->val + (ratio*((B->val - A->val)>>16) );
#define RATIO(val)  ratio=(limit - A->val) / ((B->val - A->val)>>16); P->val=limit;
/*==================================================================*/
inline void ClipX(struct Point3D *P,struct Point3D *A,struct Point3D *B,LONG limit)
{
register LONG ratio;

  RATIO(x)
  CUT(y)
  CUT(z)
  CUT(u)
  CUT(v)
  CUT(w)
}
/*==================================================================*/
inline void ClipY(struct Point3D *P,struct Point3D *A,struct Point3D *B,LONG limit)
{
register LONG ratio;

  RATIO(y)
  CUT(x)
  CUT(z)
  CUT(u)
  CUT(v)
  CUT(w)
}
/*==================================================================*/
inline void ClipZ(struct Point3D *P,struct Point3D *A,struct Point3D *B,LONG limit)
{
register LONG ratio;

  RATIO(z)
  CUT(x)
  CUT(y)
  CUT(u)
  CUT(v)
  CUT(w)
}
/*==================================================================*/




Michael Nurney

Posts 281
26 Mar 2017 11:02


just incase no one has videoed this on a Vampire2

here it is.

EXTERNAL LINK


Wawa T

Posts 695
26 Mar 2017 12:35


what?


Roy Gillotti

Posts 398
27 Mar 2017 14:58


michael nurney wrote:

just incase no one has videoed this on a Vampire2
 
  here it is.
 
  EXTERNAL LINK 

Link seems to be broken.


Mr Niding

Posts 444
27 Mar 2017 17:44


EXTERNAL LINK


Thellier Alain

Posts 116
18 Apr 2017 12:24


Hello

Here it is a cut down version of Cow3D that include a soft renderer that dont use FPU
(This code is not the Wazp3D one but derivated from the “no fpu” drawpoly function I recently made for PatchCompositeTags/WinUAE )
Include zbuffer+gouraud+alpha not yet perspective (as the original cow don’t use it so cant serve to test that…)

  EXTERNAL LINK 
The really important parts (for speed) are in Vampire3D.c/ FillPoly(); and Vampire3D.c/ DrawEdge();
[ Of course this is C for tutorial reason but will need to be translated to ASM+AMMX ]
CoW3D6V.c only contain a part of the demo code from classic Cow3D but nothing that draw pixels really

As Norbert Kett  said certainly it will need some kind of GetTexturePixel/ SetTexturePixel feature in Vampire
Perhaps having some textures unit implemented like

Define and lock the textures that we will use:

SetTexture0(screenpointer ,width,height,pixelformat); // pixelformat like ARGB32 RGB24 R5G6B5 etc
SetTexture1(texturepointer,width,height,pixelformat);

Then in FillPoly

ULONG PixRGBA32=GetTexture0Pixel(x,y);      /* so the code will dont have to know if Tex is 32/24/16/15 bits
ULONG TexRGBA32=GetTexture1Pixel(u,v);

Then do modulate TexRGBA32 = Color32 * TexRGBA32 (in a way that will need to be defined …)
Then do alpha PixRGBA32 with TexRGBA32 (idem…)

SetTexture0Pixel(x,y,PixRGBA32);                    /* so the code will dont have to know if Screen is 32/24/16/15 bits

x y can be UWORD
but it will be smarter if they are “fixed” ULONG (I mean integer part in upper 16 bits and decimal part in lower 16 bits)  as it will allow to directly use the current (fixed) u v value without any copy operation

You can bufferize the animation in Cow3D with typing ‘b’ so the rotation is no more computed so better to show the draw speed

Alain Thellier


Chris Holzapfel

Posts 53
18 Apr 2017 12:59


Can't open the link.

ERREUR 404 - Document non trouvé



Thellier Alain

Posts 116
18 Apr 2017 13:39


Oupps made a typo, sorry

EXTERNAL LINK


Daniel Sevo

Posts 299
18 Apr 2017 22:23


Impressive stuff Alain.  Never thought Id see Quake run without FPU ;-)

  How will TinyGL behave on Apollo with FPU? (Ok, its taking long time to arrive, but I'm assuming its still just a matter of ironing out the bugs?)
 


Vojin Vidanovic

Posts 770
14 Sep 2017 20:37


Daniel Sevo wrote:

    Impressive stuff Alain.  Never thought Id see Quake run without FPU ;-)
   
      How will TinyGL behave on Apollo with FPU? (Ok, its taking long time to arrive, but I'm assuming its still just a matter of ironing out the bugs?)
     
   

   
    Good question. May 2017 video of MC running Quake with unoptimized TinyGL could be joke on our side.
    EXTERNAL LINK   
    But, hope all improvemenets and tweaks, esp. video driver and at least FEMU will bring decent speed.
   
    Quake, is great game once fully expanded. Hope our port will support the packs.
    https://en.wikipedia.org/wiki/Quake_(video_game)#Expansions
 
  P.S. I am interested to know how No TinyGL ClickBooms port behave.
 
  On Apollo 1260 (Apollo 1260 accelerator card in the trapdoor clocked at 80Mhz and 64Mb of RAM).
  EXTERNAL LINK   


Mallagan Bellator

Posts 381
15 Sep 2017 10:14


Gunnar von Boehn wrote:

Norbert Kett wrote:

    i made a quick calculation: if i assume the CPU runs at 100MHz, and i want 30 frames / second, and 640x400 pixels. then i have 13 CPU cycles to compute one pixel which is not too much. usually an application need to compute many other things too. so, if i'm correct without a special texturing HW we can not achieve ps2 quality. i feel AMMX wont help.
   

   
  The Calculation is a good start.
  But mind we also decode VIDEO in 640x400 at 30 FPS - with no problem.
  We also play DOOM in 640x400 smooth - without problems.
  And this even without using MMX!
  So we have already proved that we can do this resolution.
 
 
  Now show us what instruction/operations are needed per texel.
  Then we can do the clock counting!
 
  ;-)

I think doom should run at 30 fps in 1920x1080 no problem, or at least 1280x720 ;)
Nah, I'm kidding. But 960x540?


Mallagan Bellator

Posts 381
15 Sep 2017 10:18


Norbert Kett wrote:

TinyGL originally supported only 256x256, now: from 64x64 to 2048x2048.
 

That's really not half bad!!


Fernando Pereira

Posts 68
15 Sep 2017 10:40


Mallagan Bellator wrote:

Norbert Kett wrote:

  TinyGL originally supported only 256x256, now: from 64x64 to 2048x2048.
 
 

  That's really not half bad!!

2048x2048! Nice! The roguelike game I'm developing has a an atlas texture of that size. That would make things SOOOOO much easier to port it to Amiga.


Mallagan Bellator

Posts 381
15 Sep 2017 10:41


wawa t wrote:

but doom is a 2d engine providing an illusion of 3d action, while an implementation of even a subset of some historical version of ogl, is still a true 3d multipurpose engine, demanding its share in complexity and flexibility. if tinygl is going to be a base for porting applications it cannot be that tricky and restricted. it might be possible to have it implemented within reason only with integer aritmetics, it seems that is what os4 people (hans) are doing when they use compositing to fake 3d in demos, still im not sure it will alone gain enough speed to have your average simple 3d game port to run on a vampire n a playable speed, say some 10 fps..
 
  edit: norbert, you have beat me to it;)

First of all, I heard that doom was the first game to include a real 3d engine, "unlike Wolfenstein 3d". I do have to say, though, that they look pretty similar. Second, what is "fake" 3d? If it moves triangles around in a 3d manner, isn't that 3d? No mater if it's hardware rendered or software rendered.

Also, on my 040@40mhz I run doom in 15 fps and quake at roughly 5-10 fps. With proper fpu, the vampire can do alot better, period


Mallagan Bellator

Posts 381
15 Sep 2017 10:49


Gunnar von Boehn wrote:

 
  If someone likes to do this, then I'm happy to help on the ASM tuning. And if needed we can always cheat by adding new instructions if we identified very useful cases.

Sometimes, cheating can be a very beautiful thing ;)


Saladriel Amrael

Posts 126
15 Sep 2017 10:50


EXTERNAL LINK  explains Dooom engine.
 
  Long story short, it is 2.5D: environment is drawed to look like a real 3D one and can rotate around Z Axis. But that's it!
  Maps are 2D and walls are always rendered perpendicular to floor because you can't rotate the view around Y or X axis.
 
  Think it as Dungeon Master on steroids (well it is a bit of a oversemplification, but can set your mind to understand the difference between Doom and Quake engines)
 


Gunnar von Boehn
(Apollo Team Member)
Posts 4763
15 Sep 2017 11:11


Mallagan Bellator wrote:

First of all, I heard that doom was the first game to include a real 3d engine, "unlike Wolfenstein 3d".

Real 3D engines are games like
ELITE, STAR-GLIDER, VIRUS ...

DOOM and CASTLE-WOLFENSTEIN are similar in math.
And both "cheat" a little on the 3D calculation to run faster.

Quake uses more complex math.


Vojin Vidanovic

Posts 770
15 Sep 2017 11:17


Gunnar von Boehn wrote:

  Quake uses more complex math.
 

 
  True, pre-Quake titles could be dubbed pseudo 3d.
  Also, until Glide mode Quake was using no h/w acceleration,
  beyond heavy FPU calculations, and was quite impossible
  to be run on 486 and Cyrix and AMD P5 class CPUs.
  So it was Pentium driver, and as such its great to see
  ClickBoom port can be used on 060 class Amiga.
 
  ClickBoom ports is claimed to support Picasso
  EXTERNAL LINK 
  Dont know is it better then WinQuake port
EXTERNAL LINK  EXTERNAL LINK 


Mallagan Bellator

Posts 381
15 Sep 2017 20:28


Saladriel Amrael wrote:

  Maps are 2D and walls are always rendered perpendicular to floor because you can't rotate the view around Y or X axis.
 
  Think it as Dungeon Master on steroids (well it is a bit of a oversemplification, but can set your mind to understand the difference between Doom and Quake engines)
 

I did make stages in the Amiga port of DEU, I know how that works.

posts 119page  1 2 3 4 5 6