FBlit opensourced

[matthey]

It seems that FBlit is opensourced. That is nice as it is a very useful program.

It does significant difference for chip ram usage and speed. It makes games like Napalm screen scrolling smooth with hires screen modes.

I would like to know what are future plans with this? Long time ago I heard that original author has a plan to make specific fblit screenmode, which could be chosen from a requester. Anything like that?

Would it be possible to merge ftext and fscreen to fblit?

Cosmo's graphics.library attempts what you want. The documentation states:

"All access to the blitter removed for 030+/OCS/ECS/AGA/fastram"

and

"With this release, you are now able to remove forever these patchs :
 AmyWarp
 BlazeWCP
 CpuBlit
 FBlit
 FText
 IconBeFast
 Rpp
 SetPatch v44.38

There are now bluit-in, for unity and simplification."

A replacement graphics.library is better than a bunch of patches but Cosmo's library may do more than you want. ThoR's layers.library also improves window responsiveness substantially. These modules (and others) are best used with a custom kickstart and flash or MAPROM.

[matthey]

I have tried Cosmo's graphic library, it doesn't replace FBlit. With FBlit is possible start almost all chip ram hungry games from Workbench as it left almost all chip ram useless.

Some 200kb chip ram * is used with FBlit, Cosmo's Graphics library doesn't do that. It also has annoying color problem. I can use FBlit gui to choose apps and games to used with FBlit, this is not possible with replacement library.

Cosmo's graphics.library lacks a utility to allocate some "graphics memory" in fast memory on a case by case basis. It can't be done by default because of compatibility reasons but such a utility should be simpler than with FBlit (maybe even FBlit code could be borrowed for such a utility now that it is open source). Cosmo's implementation may not be the best but replacing the graphics.library with blitter free and RTG capable functions is the right idea. Development of a better graphics.library may depend on which way Amiga FPGA hardware goes. The blitter and graphics memory can be much faster on FPGA hardware making the original blitter using code usable again. Graphics memory can be as fast as fast memory so no utility to allocate graphics memory in fast memory should be necessary. A best performance FPGA Amiga may replace the blitter with a SIMD unit in the CPU though.

Cosmo's graphics.library is also slow. It decreases the overall system speed. I've tested this with A1200/030/50Mhz WB 3.1 & A1200/060/80Mhz WB 3.9.

Interesting. I don't see how it can be slower than the original graphics.library. Does it slow down the system compared to the original graphic.library (using the blitter) or compared to a FBlit enhanced system? Have you reported the problems? Have you tried a recent version of graphics.library?

I do not use Cosmo's graphics.library and am not suggesting that anyone should but people should be aware of available options. I use a P96 setup where much of the graphics.library code is replaced also (and the gfx hardware is often several times faster than AGA). I do use (a tweaked version for test purposes) ThoR's layers.library which is semi-official, mostly bug free and provides a big speedup for layer (window) operations. However, it doesn't replace the bottlenecks in graphics.library.