FBlit opensourced

[utri007]

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

It does significant diffrence 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 specifig fblit screenmode, wich could be choosed from requester. Anything like that?

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

https://github.com/SamuraiCrow/fblit

[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.

[utri007]

I have tried Como'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 possbile with replacement library.



*I have 640x512 8bit Workbench screen with background image.

[AmiDude]

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.

[utri007]

I didn't test a much. Just noticed that it usea a lots of chip ram, has wrong colors in directory opus and it doesn't speed up simcity2000 like FBlit does.

[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.

[utri007]

There is three main reasons to use FBlit

1st Workbench is faster with it, if you configure it so.
2nd With FBlit workbench uses chip ram very little. Usefull with many chipram hungry games
3rd Some games like SimCity2000 and Napalm are quite playable with hires interlaced screen mode. Scrolling is much faster and ofcourse they must be configured to FBlit.

None of these happen with Cosmo's Graphics library

[Oldsmobile_Mike]

I have a very simple approach to this:

- If your Amiga has a graphics card, use Cosmos' library
- If your Amiga uses AGA/ECS, use Fblit

Simple?  Done!  At least it's what gives me the best results, and I'm combining these with multiple other patches, as well.  I just wish Cosmos were still releasing public updates to his library, but I understand having to lock it down due to people trying to profit off his work.  I still scrounge the net to look for the latest versions, though!  

[kamelito]

I have a very simple approach to this:

- If your Amiga has a graphics card, use Cosmos' library
- If your Amiga uses AGA/ECS, use Fblit

Simple?  Done!  At least it's what gives me the best results, and I'm combining these with multiple other patches, as well.  I just wish Cosmos were still releasing public updates to his library, but I understand having to lock it down due to people trying to profit off his work.  I still scrounge the net to look for the latest versions, though!  

if you've a GFX Card and this one have a blitter isn't the P96 or CGX supposedly use that in place of the Amiga Blitter freeing the CPU for other things?
The advantage of Blitter is freeing the CPU if you replace Blitter functions by CPU routines then you loose that CPU. If the CPU is doing nothing that fine but if you render an image for instance in the background and using you Amiga aren't you loosing time? All in all for GFX Less Amiga a combination of the too would still be faster but it can be tricky to balance the too not knowing what is happening in your system. I suppose that some kinds of settings depending on CPU power and RAM speed could be done to use the too in conjunction for maximum perf.

Kamelito

[itix]

if you've a GFX Card and this one have a blitter isn't the P96 or CGX supposedly use that in place of the Amiga Blitter freeing the CPU for other things?

Amigablitter is still used for native bitmaps.

The advantage of Blitter is freeing the CPU if you replace Blitter functions by CPU routines then you loose that CPU. If the CPU is doing nothing that fine but if you render an image for instance in the background and using you Amiga aren't you loosing time?

Amiga blitters is slow that newer CPUs can do same operations but just faster. And they could have natve bitmaps in the fast ram saving precious chip ram.

So you get faster gfx operations and save chip ram (for the musc for example)"

[AmiDude]

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.



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.

It slows down screens (like Workbench) with lots of colors. Using FBlit is better on non-GFX card systems.

[guest11527]

if you've a GFX Card and this one have a blitter isn't the P96 or CGX supposedly use that in place of the Amiga Blitter freeing the CPU for other things?

Indeed. P96 is smart enough not to allocate bitmaps in chip memory if it does not have to. There is no reason to mess with the graphics library (especially Cosmos) given that P96 already replaces most of it, and is smart enough to off-load graphics operations to the CPU or the graphics board blitter if available.

Actually, one could write a P96 driver for the native chipset which could then offload all the blitting to the CPU if required. P96 is smart enough to shuffle bitmaps between the graphics board memory (here "chip mem") and fast memory as required.  

The advantage of Blitter is freeing the CPU if you replace Blitter functions by CPU routines then you loose that CPU. If the CPU is doing nothing that fine but if you render an image for instance in the background and using you Amiga aren't you loosing time?

Potentially, however, it's not quite that simple. In principle, the CPU can trigger the blitter and then return to the caller while the blitter is still running. However, if a screen has multiple bitmaps (so more than two colors), which is the norm, then normally the blitter has to be triggered multiple times. There are a couple of exceptions (screen bitmap is interleaved, operation is simple enough), but in general, the CPU has to wait for n-1 bitmaps to be completed before it returns with the blitter working on the last bitmap. So you do not gain much.

Even worse, the current implementation of the graphics library runs into a busy-wait to let the blitter complete, it does not perform smart things such as sending the CPU into a Wait(), where it could allow another task to take over.

The decision to use such a (IMHO stupid) design was based on the slow 68K CPU. Back then, the overall overhead of the CPU reacting on a blitter interrupt, and managing and mainting such interrupts was higher than just to run into WaitBlit(), so the design remained as stupid as it is today. Whether this estimate still holds for faster CPUs, i.e. busy-wait vs. Wait(), is unclear to me and is something that is probably worth trying. At least it could free the (much faster) CPU doing something useful instead of wainting for the blitter.

[utri007]

I haven't tested Cosmo's graphic library with my RTG system, but even if it works, it is not that essential as with AGA systems. AGA with 256 colors and 640x512 is bog slow, without FBlit it is unuseable. Speed difference is something like 4x faster with FBlit. I don't have any speed problems with my Spectum 24 or xPert Merlin with standard Graphics library.

[guest11527]

I don't have any speed problems with my Spectum 24 or xPert Merlin with standard Graphics library.

Actually, if you have a Spectrum 24, you don't have the standard graphics.library. You have either cybergraphics or P96, and both of them really replace (almost all) of the lower level graphics.library functions. There isn't much of the native graphics left with RTG graphics active.

[utri007]

Thanks all involved

Does anyone know current situation of FBlit? Is it developed know when it is open sourced?