They should make a Windows like Amiga OS so it runs on a PC - Page 6

Karlos · Yesterday, 09:37

Quote:

Originally Posted by hammer

Commodore's RTG promise would cause FUD on GVP's EGS.

The problem with CGX and P96 is that they didn't really provide any new accelerated ways of doing graphical operations. They just patch graphics.lbrary drawing functions. Which is necessary and great for existing applications, but doesn't do much to help you if you want to do anything new in a performant way. It is to Amiga what GDI was is to Windows. The only really useful things you can do is to use those to allow you to *ensure* a BitMap is allocated in VRAM, query the precise hardware attributes (depth, format, dimensions, spans, etc) of that BitMap, the ability to lock it so that you can do unaccelerated software drawing on it*. Also, trying to lock and pin bitmaps this way is something that's not even best practise, since as Thomas says, the RTG layer is supposed to manage all this and ensure what's in VRAM is only what is necessary.

This also produces the interesting side effect that, unless you use a friend BitMap to try and ensure your new allocation is in VRAM, it typically ends up in Fast, until you want it render on it. At which point it's either transferred to VRAM, which is a massive overhead, or in some cases the system simply uses a software version of the routine to draw on the BitMap while it's still in fast memory.

Also, using friend bitmaps means you lose control over the format, since it has to be in a format that can be directly blitted, which more often than not means, in exactly the same format as the friend. I can't tell you the lunacy this results in when working on 3D drivers that have to use these allocator routines for allocating texture buffers.

None of these behaviours are conducive to high performance graphics programming.

*This is why so many games end up just rendering to fast ram and then frame copying to the RTG card.

Karlos · Yesterday, 11:27

Quote:

Quite frankly, this goes more in the direction of a 3D API which provides something in this area. This exists already. While I'm not against a "Direct Draw" like additional API for 2D, I doubt adding one will have much success. There is a lack of critical mass here that prevents it from getting successful.

Well, the 3D API is completely the wrong one for what I needed. Case in point. I had an abstract drawing class, that had three implementations in the end, selectable at runtime based on what was detected.

1. Pure software (locking bitmaps, direct software rendering)
2. Gfx/RTG (standard graphics.library)
3. Warp3D (direct screen space rasterization).

These were all required to render to RGB (15/16/32 bpp) targets, with colour information being passed as a 32-bit ARGB tuple, arbitrarily, per primitive. There are also shaded (basic vertical and horizontal gradients). Alpha was only used where supportable. The design worked on the concept I describe, in that you set up a number of primitives and then call a render operation. I did this because it was the only sensible way to do 1 and eventually 3, even if 2 didn't strictly need it.

In the end, 2 was by far the least capable and the only thing it could do better than 1 was basic rectangular fill/copy. It had to extend 1 anyway because the total graphics.librart routine overhead was so absurd for simple primitives that it was just faster to lock and draw in software. For example, one operation renders an array of point data, where each point has it's x,y,RGB data, discarding any outside either the bitmap dimension or any smaller rectangular clip area that could be defined. This is probably the worst possible case for 2, which was literally hundreds of times slower than 1. It's worth noting that 1 was also a lot faster than 3 for this.

In the end, 3 was the best of a bad bunch but demanded that you have an FPU, because it's intended to support the output of 3D transformation I wasn't using. There was also no way to blit in a manner that would allow the copied area to be refused for the draw fills because textures aren't bitmaps in the conventional sense, and even having pretty strong inside knowledge of my particular HW and drivers, there was no way I was going to hack that to work.

So the only one which ever worked fully was 1, which then was by far the slowest at any rectangle operations and 3 was the fastest by virtue of being able to reuse bits of 1 and 2 to support what the 3D driver API couldn't do or didn't do well.

What we really needed was for the system to provide a fast, efficient, easily HW mappable set of operations, but literally nothing existed. Today, you might get the majority of this with the compositor implementation in 4.1 and equivalent functionality in MOS.

As for more fully fledged API, I absolutely did not want the ludicrous indirection of GL and all that comes with it to do this, because every single 68K GL implementation utterly sucked at the time, having all the worst problems of the Warp3D implementation above with thr added overhead of GL abstraction on top. It also sucked if you didn't want to use GLUT for managing your display. GL was only useful for things written for GL and back then, very very little was written for GL that was expected to run well on a 68K.

Thomas Richter · Yesterday, 12:27

Quote: