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 Games and Apps.

Interesting 3D Racing Game for Vampire?page  1 2 3 4 

Steffen Häuser

Posts 40
12 Jan 2023 10:40


1) -> pretty irrelevant for the games I did. I usually started with a game without sound, and added the soundcode then. The fps did not decrease.
 
  2) This might be relevant for a certain kind of games. For the 3D Games I work on this is irrelevant. Actually directly sending the data to screen (instead of to an intermediate buffer) is not a problem though (you just should go sure to implement proper Double or Triple Buffering, else it flickers). It usually doesn't have a big impact on performance though (I experimented a lot with such stuff). Remember also that this is only for software rendering anyways.
 
  3) Again does not speak against using Libraries. Texturemapper inner loops etc. can be written in Assembly language, and actually this is probably the area where you most profit of it. Asides from that - you use standard APIs.
 
  4) Again - more games could support this if a MiniGL (or subset of MiniGL) would support the Maggie chip. You are limiting it's usage by only allowing it to be used by ugly direct hardware hacking.
 
  5) This might of course be an issue as to if the compiler does not support those new registers. If an optimized compiler for this platform is not a possibility again - Assembler code for heavy parts of the instructions. Doing parts of the code in ASM does NOT mean to use ugly direct hardware hacking.
 
  The overhead for a library call is absolutely minimalistic and not relevant. I never said anything against ASM optimization of CPU hungry parts of the code. I said something against ugly direct hardware hacking.
 
  Remember also especially in 3D hardware a standard API will
 
  a) protect you if at one point your hardware changes
  b) enable you to do more adaptions from other platforms
  c) profit of the highlevel optimizations done on other platforms (remember a lowlevel optimization can NEVER beat a highlevel optimization)

Note this answer is NOT ideological. It is just about how things are ;-)
 
  Steffen Haeuser
 


Thellier Alain

Posts 141
12 Jan 2023 11:10


Yes the fix in StormMesa2010 make it use the hardware acceleration same as MiniGL so you can compile for MiniGL or StormMesa based on what library provide the more compatibility with your sources

(old)StormMesa could render as software or hardware but there was various bugs that make it erroneously fall back to software in some cases
So typically a game using hardware rendering could have some parts in the scene drawn as sofware so killing the performance
This is something we discovered with Wazp3D as it got an option (debug sepia) to show what parts are drawn with Wazp3D

Is there any tutorial sources about using maggie3D ?
There is the registers description for Maggie3D but setting up textures/mipmap/screen/zbuffer is not documented




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
12 Jan 2023 14:41


thellier alain wrote:

Is there any tutorial sources about using maggie3D ?
There is the registers description for Maggie3D but setting up textures/mipmap/screen/zbuffer is not documented

Yes all register of Maggie are in the SAGADOC register documentation of Amiga registers

The Apollo Dungeon Crawler source is available so see you to use them.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
12 Jan 2023 15:21


Steffen Häuser wrote:

1) -> pretty irrelevant for the games I did. I usually started with a game without sound, and added the soundcode then. The fps did not decrease.

I understand what you say,
I assume it does depend of course on your software and how many channels you use.
We all know that you can worst case, very easily burn the bigger part of a 68060 CPU with the extra overhead of AHI, audio mixing, audio conversion on Amiga.
   
 
Steffen Häuser wrote:

2) Actually directly sending the data to screen  ... It usually doesn't have a big impact on performance though

   
The overhead is very easy to see, and very easy to measure.
Its pretty clear how huge the impact on performance is on Amiga.
   
Your Amiga GFX cards are either Zorro2 or Zorro3.

The AMIGA Zorro2 Bus has a max speed of 3.5 MB/Sec
Performance of the Zorro3 bus varies, often 7-10 MB/sec
   
Lets say your screen is 640x480x32bit = 1.2 MB size per frame
 
Z2 3.5 MB/sec and one Frame is 1.2 MB - the problem is obvious.
Memcopy to a Z2 GFXcard will use 100% CPU time and only reach 3 FPS!!
 
Z3 7-10 MB/sec and one Frame is 1.2 MB - the problem is obvious.
Memcopy to a Z3 GFXcard will use 100% CPU time and only reach 6-8 FPS!!
   
I'm sure you agree with me that this is a major bottleneck - and avoiding it - is just great.




Steffen Häuser

Posts 40
15 Jan 2023 18:12


I agree on AHI. Was never a big friend of it, but it is the only Hardware-independent sound-API existing on Amiga (okay, there is OpenAL - but I have no idea how far this is - and internally it probably also uses AHI). My games all use AHI, but if I would do a 68k port I would also alternately do a Paula port (I assume this would run on Vampire ?) through audio.device.

Speed was pretty irrelevant on the kind of games I do about if I run AHI or Paula or disable sound. Probably due to the nature of these games.

I have to admit Zorro2 is not something I consider as something people still use. And your calculation would only be relevant for software renderer anyways (somewhat relevant still, but less so).

Note that most games (at least those were source-code is available on AmigaOS) are in 16 Bit, not 32 Bit. Already halfs the size ;-)

And again - this is relevant in the way you calculate it for software rendering.

And also again - for certain kinds of games you do not have the option to go a different route. You cannot do a raycaster or other 3D FPS with individual objects and stuff. You still can optimize a lot of things by only calculating objects which are "in sight" (by using a BSP tree for example, or a portal renderer) - but a full screen update still needs to be done.

Again - for certain types of games you CANNOT avoid this bottleneck.
The best you can do is to use 3D Hardware. And the best to make this happen is - having a 3D API for the platforms you support so that you do not use to reevent the wheel every time...




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
16 Jan 2023 10:44


Steffen Häuser wrote:

  I agree on AHI. Was never a big friend of it,
 

  We both agree.
  Probably all people with understanding of Amiga design will agree.
 
 
 
Steffen Häuser wrote:

    I have to admit Zorro2 is not something I consider as something people still use.
 

 
Of course you know we are here in an Amiga forum :)
 
For Amiga the following display options do exist
A) Amiga Planes with need to do Chunky 2 Planar conversion. This is limited by the write speed of the chipmemory.

B) Zorro GFX cards which all have the bottleneck we explained.
Only small resolution and limited colors are possible.
For example smooth Video playback in 640x480 is impossible because of the Zorro Bottleneck.

C) PCI cards with Bridges.
These bridges have the same bottleneck limitations as Zorro.
So you can also not do smooth video on them

D) Using Super-AGA
Has ~100 times higher throughput, removing this bottleneck.



Steve Ferrell

Posts 424
16 Jan 2023 23:37


Steffen Häuser wrote:

 
  The best you can do is to use 3D Hardware. And the best to make this happen is - having a 3D API for the platforms you support so that you do not use to reevent the wheel every time...
 
 

I agree with you 100%.  Having a 3D API also opens up a world of existing software that can be ported to the Vampire.  Until there's an OpenGL or MiniGL (or something like GLide) link-time library for higher level languages, the Vampire is going to suffer from a lack of software that can even take advantage of the Maggie. There's a lack of 68K assembly programmers out there and that won't get any better.  Even the folks at 3DFX understood this problem and created API's to support their VooDoo chipsets.  They understood that it was unreasonable to expect programmers to know assembly and also expect them to re-invent the wheel for every application they wrote. Expecting programmers to bang hardware registers and hand tune every app they create will only serve to drive programmers away from the Vampire, not draw them to it.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
17 Jan 2023 00:00


Steve Ferrell wrote:

Having a 3D API also opens up a world of existing software

 
Sure, this is a non argument, no one is debating that.
We all agree on this. :-)
 

But as you know the point of this discussion is about something completely different.
 
Of course a 3D APi helps porting sources - but the work is not done then. The point of our talk here, is that people can not just take a PC source - press one button - and expect to have a great running Amiga game.  This will result at best in a very bad port.
To make a good Amiga port a lot more needs be done.
   
 
Steve Ferrell wrote:

There's a lack of 68K assembly programmers out there and that won't get any better.

A person without 68k skills can not just take a PC OpenGL game execute "press one button to compile it" and have a good well tuned Amiga port.
If this would be possible then it would be cool - but this is not how programming works.
 
In Amiga history, there were many of "real bad ports".
Those games ran bad and looked terrible on Amiga.
They were a numbers of bad or not tuned at all conversions to Amiga.
Frankly the Amiga users hated them. We dont need more of those.
   
Good conversions / Good Amiga games need a lot effort,
they need real coding and they need tuning.
We all know games which were tuned with love to detail for Amiga.
And we all love and admire these Amiga games.
 
     
Steve Ferrell wrote:
 
Expecting programmers to bang hardware registers and hand tune every app

 
Yes, this is exactly how good Amiga ports are done.
To make a good Amiga game, you have to do a lot of hand tuning and you have to use all the Amiga advantages possible.
All good Amiga games are done exactly like this.
And if the game is not tuned for Amiga then the game will run very bad. Its really simple.

We all know this.




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
17 Jan 2023 07:33


Steve,
       
as stated before the team is working on the 3D API.
What you ask for is good and reasonable and we work on it.
       
I shared you my point of view,
my view about Amiga coding is based only on my Amiga coding experience.
     
Let me give you some examples of what I did on Amiga:
  - wrote many demos,
  - wrote several games for Amiga,
  - wrote several applications
  - ported and help porting several games to Amiga
  - helped tune many games for Amiga
  - tuned several drivers, as IDE driver and GFX drivers
  - tuning of many operating system functions
     
My experience was very often the same.
Straightforward compiling your average C game resulted in an unsatisfying result like 8-10 FPS, and after month of heavy hand tuning you got a nice and good result like 40-60 FPS.
     
We this for many games, Diablo, Sonic, Doom, you name them.
We saw the same even on basic drivers like GFX routines, IDE driver,  string and OS functions.
 
Yes, API are enablers.
One famous API is SDL.
AMIGA has SDL support since over 10 years.
Yes this made porting SDL games easier.
But this was not a "magic bullet".
We did not get thousands of swift and perfect running SDL Amiga games over night.
 
We got some good games, but all good games were heavily hand tuned.
   
Based on my experience you need to hand tune to get satisfying results.
In my experience you need to write Assembly to get a good result.
If you not want to write Assembly - then you will need to develop a much better C compiler than existing today.
   
I think developing a better C compiler is very difficult - Learning 68k assembly seems to me to be much less work.
 
 
How about you get something experience in compiling and developing and tuning something for Amiga?
I look forward to hear then your experience.

Different people might have made different experience.
My opinion is based on my personal experience.
If other people have made different experience, they might look at this from another angle.
This does not mean that different opinions are "right or wrong".
All I can do is provide my experience and explain it.



Steffen Häuser

Posts 40
29 Jan 2023 16:02


Gunnar von Boehn wrote:

   
Steffen Häuser wrote:

    I have to admit Zorro2 is not something I consider as something people still use.
   

   
  Of course you know we are here in an Amiga forum :)
 

Even on an Amiga forum Zorro2 is old stuff not really relevant anymore. What is an Amiga ? It is a machine running AmigaOS natively.


  For Amiga the following display options do exist

Modern games (now I am not talking on games types which actually profit of planar display - I am not doing such games) use Chunky display through Cybergraphx or P96 which all decent Amiga Hardware should support. Actually for the OS 4 version of Heretic 2 I did not even bother about keeping the HAM-c2p  thingy in I had in the original OS3.x version.

> C) PCI cards with Bridges.

Or PCI Cards fitting directly into the hardware (some Amigas support this, you know ? ;-) )
 
> D) Using Super-AGA
> Has ~100 times higher throughput, removing this bottleneck.
 
I'd suggest writing a CGX or P96 Driver for it. Even at a not-full functionality the c2p (I assume this is a planar mode ?) could be hidden in WritePixelArray. Or if no CGX or P96 some other API to avoid the need of an ugly direct hardware banging.

Then you get both good speed (if this speeds it so much as you say) and easy handling.

But also

- Software rendering where something like Super-AGA will be relevant will - as to games - only be relevant for a specific TYPE of games. Of course great that it exists, but for the type of games I create it will not really be relevant. Something like your 3D Chip (assuming one of my future games would run on your platform of course) would be MUCH more relevant. Software rendering is basically to expand the amount of supported systems, adding some lowend systems "were possible" (that's why for Heretic 2 for OS3.x I had a HAM-mode c2p added as option which converted the 16 Bit chunky data and displayed it on a HAM screen).

And optimizing the screen-copying (whether by chunky-copy or c2p) will only achieve minimal speedup (believe me, I know this, 20 years ago I created a lib called "chunkyppc.library". It's idea was basically - have a call for Open Screen, one for Close Screen, one for copying data on it - no complicated stuff like Screens, Windows, Bitmaps, etc. - all in one go. ASM optimized copy functions, and whether it is chunkycopy or c2p will all be handled internally.

Sadly the speedup - despite optimization - was much less than what I hoped for. On the other hand ONE speedup on C-language level or even better ALGORITHMIC level can have like 30% speedups... I found such a case recently. The speedup had NOTHING to do with either banging the hardware or using ASM - just with improving the algorithm (one which was called very often).


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
29 Jan 2023 18:14


Steffen Häuser wrote:

 
Gunnar von Boehn wrote:

     
Steffen Häuser wrote:

        I have to admit Zorro2 is not something I consider as something people still use.
     

     
    Of course you know we are here in an Amiga forum :)
   
 
   
    Even on an Amiga forum Zorro2 is old stuff not really relevant anymore. What is an Amiga ? It is a machine running AmigaOS natively.
 

 
This would mean than computer is an AMIGA - as any computer can run AROS.
 
To me an Amiga is a computer with Amiga chipset.
 
An Amiga is an Amiga - when it can play Giana Sister - without emulation!
 
 
Steffen Häuser wrote:

 
Gunnar von Boehn wrote:

    For Amiga the following display options do exist
 

   
    Modern games (now I am not talking on games types which actually profit of planar display - I am not doing such games) use Chunky display through Cybergraphx or P96 which all decent Amiga Hardware should support. Actually for the OS 4 version of Heretic 2 I did not even bother about keeping the HAM-c2p  thingy in I had in the original OS3.x version.
   
    > C) PCI cards with Bridges.
   
    Or PCI Cards fitting directly into the hardware (some Amigas support this, you know ? ;-) )
   

 
  Yes,  I know very well.
  This is the NATAMI.
  This was build by us.
 
  Its an AMIGA with PCI.
 
 
 
 
Steffen Häuser wrote:

 
Gunnar von Boehn wrote:

    > D) Using Super-AGA
    > Has ~100 times higher throughput, removing this bottleneck.
 

 
  I'd suggest writing a CGX or P96 Driver for it.
 

 
  Of course we have these drivers. Does not everyone know this?
  I mean over 10,000 Amiga users do use Super-AGA with either P96 or CyberGFX today.
 
 
Steffen Häuser wrote:

    Even at a not-full functionality the c2p (I assume this is a planar mode ?) could be hidden in WritePixelArray. Or if no CGX or P96 some other API to avoid the need of an ugly direct hardware banging.
 

  Super-AGA support both PLANA and Chunky in hardware.
   
 
 
Steffen Häuser wrote:
 
    And optimizing the screen-copying (whether by chunky-copy or c2p) will only achieve minimal speedup (believe me, I know this, 20 years ago I created a lib called "chunkyppc.library". It's idea was basically - have a call for Open Screen, one for Close Screen, one for copying data on it - no complicated stuff like Screens, Windows, Bitmaps, etc. - all in one go. ASM optimized copy functions, and whether it is chunkycopy or c2p will all be handled internally.
 

 
  My point was something different.
  My point was to not need the copy.
  A copy not needed to be done at all - might even faster than on optimized copy, what do you think?
 
 
 


Steffen Häuser

Posts 40
30 Jan 2023 06:59


Final comment from me on this. I was thinking of not writing anything, but that AROS-comment I cannot leave standing.
 
 
 
 
Gunnar von Boehn wrote:
  This would mean than computer is an AMIGA - as any computer can run AROS.
 

 
  I said AmigaOS. I did not say AROS.
 
  And saying "AROS is the same like AmigaOS" (which you just did) for me is like (as I know now!!!) for you someone saying "Custom Chips do not matter for the question of what is an Amiga".
 
  Let's agree to disagree. I am not interested in System Wars.
 
  > An Amiga is an Amiga - when it can play Giana Sister - without >emulation!
 
  I do not agree. This is your opinion, I do not share it. I could write more on this but I choose not to, to not lengthen this thread.

If you took offense to any of my comments, please take my sincere apologies. Nothing was meant in an offensive way.
 
  Thanks on the info regarding CGX/P96 on Vampire system. Very interesting! (Is Super-AGA still fixed to the old PAL/NTSC resolutions, if yes, which resolutions need to be supported, or is it allowing "standard resolutions" like 640x480, 800x600 etc. ? I assume no more Flicker in Interlaced Mode ? Sorry if these are dumb questions, I do not own a Vampire)
 
 
  On the doublebuffering discussion - for specific kinds of games you are right. For games based on Q2 engine you have a preparation buffer which is copied on-screen - both with and without doublebuffering. If you try to directly use video memory as the buffer (avoiding the copy step) you get a lot of flicker due to overdraw. For some games on such an engine it might be worse than for others (admit, never tried it on Q2 itselves like that). For H2 for example a copy step is absolutely needed, regardless of DBuf or not. Too much overdraw. Which essentially also causes the fps rate for Fullscreen and Workbench Window is exactly the same (myselves prefer playing fullscreen, in WB Window everything is smaller!)
     


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jan 2023 08:44


Steffen Häuser wrote:

  For H2 for example a copy step is absolutely needed, regardless of DBuf or not. Too much overdraw. 
 

 
  Can you explain this more.
  Why is this copy step needed?
 
  Can you help me understand what you meant by "you get flicker because of overdraw"? Can you please explain this in detail?
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jan 2023 08:50


Steffen Häuser wrote:

(Is Super-AGA still fixed to the old PAL/NTSC resolutions, if yes, which resolutions need to be supported, or is it allowing "standard resolutions" like 640x480, 800x600 etc. ?

Super-AGA does Support PAL/NTSC and other resolution:
Default MODE-IDs:
$01 = 320x200                       
$02 = 320x240                       
$03 = 320x256                       
$04 = 640x400                       
$05 = 640x480                       
$06 = 640x512                       
$07 = 960x540                       
$08 = 480x270                       
$09 = 304x224                       
$0A = 1280x720                     
$0B = 640x360                       
$0C = 800x600                       
$0D = 1024x768                     
$0E = 720x576                       
$0F = 848x480                       
$10 = 640x200 

Super-AGA does support Amiga PLANAR screen with 8 Planes, EHB, HAM6 and HAM8.

Super-AGA does support ATARI ST PLANAR format (1bit/2bit/4bit).

and Super-AGA does support the following Chunky formats

$01 = 8bit (indexed)               
$02 = 16bit R5G6B5                 
$03 = 15bit 1R5G5B5                 
$04 = 24bit R8G8B8                 
$05 = 32bit A8R8G8B8               
$06 = YUV                       



Steffen Häuser

Posts 40
30 Jan 2023 11:01


Gunnar von Boehn wrote:

Steffen Häuser wrote:

  (Is Super-AGA still fixed to the old PAL/NTSC resolutions, if yes, which resolutions need to be supported, or is it allowing "standard resolutions" like 640x480, 800x600 etc. ?
 

 
  Super-AGA does Support PAL/NTSC and other resolution:
  Default MODE-IDs:
  $01 = 320x200                       
  $02 = 320x240                       
  $03 = 320x256                       
  $04 = 640x400                       
  $05 = 640x480                       
  $06 = 640x512                       
  $07 = 960x540                       
  $08 = 480x270                       
  $09 = 304x224                       
  $0A = 1280x720                     
  $0B = 640x360                       
  $0C = 800x600                       
  $0D = 1024x768                     
  $0E = 720x576                       
  $0F = 848x480                       
  $10 = 640x200 
 
  Super-AGA does support Amiga PLANAR screen with 8 Planes, EHB, HAM6 and HAM8.
 
  Super-AGA does support ATARI ST PLANAR format (1bit/2bit/4bit).
 
  and Super-AGA does support the following Chunky formats
 
  $01 = 8bit (indexed)               
  $02 = 16bit R5G6B5                 
  $03 = 15bit 1R5G5B5                 
  $04 = 24bit R8G8B8                 
  $05 = 32bit A8R8G8B8               
  $06 = YUV                       
 

Thanks, this is extremely helpful. Sounds to me that no special handling would be needed for the case that I should support 68k in future software. A lot of these modes are supported in all my software ($2, $5, $0c, $0D coupled with $2 and $3 and $4 and $5 on the color side). But if one of the others is deemed important in most my projects it would be a matter of some minutes to add a new resolution mode. I really asked just to get information as to "what is important". Maybe the 320x200 would still important for lowlevel systems, and maybe the 640x512 as this is a really usual resolution on Amiga ?

I can do HAM8, but chunky looks much better (Heretic 2 for example in HAM8 looks not as good as it does in Chunky 16 Bit). All my recent games can handle all sorts of 16 Bit or 15 Bit modes existing - at least I think it was HAM8, might have been HAM6, can't remember, 20 years ago and stuff.

As to the other question you posted (on the copying)

basically these games (other games of course might do this different) draw something, then draw something on top, then again draw something on top. If this causes "flicker" depends on how much it is done in the game (talking on the non-doublebuffer mode).

Okay. You might try the "let's directly draw to the hardware, and use doublebuffering".

You are right.

That might skip the copying. But I think if I will be doing a 68k version in my of my future games, this is a modification which could be implemented in mere minutes.

Again thanks, had not thought of this ;-) Good that you asked.

Now that I think of it, I think my original H2 port had this option for the software renderer in fullscreen with some sort of obscure console variable ;-)

As to HAM8 vs. Chunky 16 Bit, is there a performance "preference" ? Or does it simply not matter which of them you choose, for matters of speed ?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
30 Jan 2023 14:16



As to HAM8 vs. Chunky 16 Bit, is there a performance "preference" ? Or does it simply not matter which of them you choose, for matters of speed ?

For a First Person Shooter, in my opinion 16bit chunky(word) is much better than HAM.


Steffen Häuser

Posts 40
31 Jan 2023 07:45


Absolutely agreed ;-) Looks much better (Ah, so I assume Planar 16 Bit Modes still have the same restrictions like Classical HAM Mode ?) I guess then the "way to go" for games really is chunkymode for SuperAGA too. Makes it easier for developers not to have two kinds of gfx output ;-)

I meant just for the sake of performance.




Gunnar von Boehn
(Apollo Team Member)
Posts 6207
31 Jan 2023 08:00


Steffen Häuser wrote:

(Ah, so I assume Planar 16 Bit Modes still have the same restrictions like Classical HAM Mode ?)

Please mind the 16bit mode is Chunky, not planar.

Steffen Häuser wrote:

  I guess then the "way to go" for games really is chunkymode for SuperAGA too.
 

 
Yes I think this is most easiest and has good performance too.
As the PC source is coded for this already it should work "out of the box".
 


Steffen Häuser

Posts 40
31 Jan 2023 11:44


Yeah, I misunderstood you before. I thought you had both a Planar and a Chunky 16 Bit Mode. Reading comprehension failure by me, you presented the information pretty clear actually.

And yeah, should work out of the box.

Actually one thing I find most exciting on Super-AGA.

What do you think ? COULD Commodore in their final days have made (purely technical, not that they in the end were such a failure) something like Super-AGA ? Or was it only made possible by advances in chip-making which were not possible back then ?

As from all I read from you, it sounds like the logical followup on AGA.

If I read in comparision the info available on AAA and Project Hombre prototypes - well. For me Super-AGA sounds ways more exciting.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
31 Jan 2023 12:10


Steffen Häuser wrote:

As from all I read from you, it sounds like the logical followup on AGA.

Thank you.

I think many features that Super-AGA provides were on to "todo" list by the Amiga developers.

- they wanted a Chunky modes.
- they wanted 16bit audio, they wanted more audio channel
- they wanted 3D acceleration


posts 65page  1 2 3 4