English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.Apps

 
 
Thread Tools
Old 28 November 2006, 14:38   #1
Bloodwych
Moderator

Bloodwych's Avatar
 
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,757
Questions regarding FBlit and workbench

I've discovered how to get Fblit working with Scalos so I can add it to the ClassicWB setups where appropriate. In the past people complained they couldn't get Fblit to work with Scalos, and since they wanted big flashy high colour workbenches they decided to run without it (and the ClassicWB).

For those who don't know, Fblit hands blitter functions to the CPU which can allow important things such as saving CHIPRAM by forcing Newicons and certain graphical functions to use FAST. It can also speed things up (depending on your CPU).

Before adding Fblit to the ClassicWB, I need to know a few things:

1. Anyone have any compatibility issues with running Fblit? I've avoided adding any patches to the classicwb base install that cause any kind of compatibility issues in comparison to a default workbench. If compatibility issues are present, I may add it as an option during install along with a warning.

2. Does Fblit suffer any performance loss with a standard A1200 020 in comparison to using the standard blitter? Or do you really need an 030 and higher before off-loading blitter functions?
Bloodwych is offline  
AdSense AdSense  
Old 28 November 2006, 15:53   #2
ppill
CON: artist
ppill's Avatar
 
Join Date: Feb 2006
Location: Poland
Age: 36
Posts: 1,126
Send a message via Skype™ to ppill
FBlit is a fine piece of software. It was one of those programs I simply had to have in my startup-sequence when I worked on my a1200 setup(AGA+68040/40) next to MCP. Speed, Chip memory conservation... you name it. It came with an array of parameters that could be used to make sure it didn't clash with other patches. When set up correctly there are no issues whatsoever. Patching is like a form of art . If any problems crop up just tell us what they are.
There are also other patches worth considering for inclusion:
Syspatch
FText
PatchControl

just to name a few.
ppill is offline  
Old 28 November 2006, 15:59   #3
ppill
CON: artist
ppill's Avatar
 
Join Date: Feb 2006
Location: Poland
Age: 36
Posts: 1,126
Send a message via Skype™ to ppill
Quote:
Originally Posted by Bloodwych
2. Does Fblit suffer any performance loss with a standard A1200 020 in comparison to using the standard blitter? Or do you really need an 030 and higher before off-loading blitter functions?
I guess that with a stock a1200(020+CHIP+AGA) installing FBlit wouldn't make any sense assuming it would work(I think it needs FAST). But when some Fast ram is available the whole system picks up in speed even with the built-in CPU.
ppill is offline  
Old 28 November 2006, 16:09   #4
Bloodwych
Moderator

Bloodwych's Avatar
 
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,757
Thanks, some useful info there.

I've noticed the memory saving function of Fblit seems to only work with newicon image data and not the regular icon data in Scalos. Do you know if that's the same on normal workbench systems?

For instance, on a 64 colour newicon system it offloads quite a bit to fastram.

However, on a 16 colour normal icon (WB 3.0-3.1) system nothing is offloaded to fastram.
Bloodwych is offline  
Old 28 November 2006, 16:36   #5
ppill
CON: artist
ppill's Avatar
 
Join Date: Feb 2006
Location: Poland
Age: 36
Posts: 1,126
Send a message via Skype™ to ppill
I'm not an expert when it comes to system functions FBlit patches (or other for that matter )but I guess that NewIcons use a special technique(when the rtg option is used) to process the gfx data outside of Chip ram and only use it when they appear on the screen. Something the pre 3.5 workbench icon.library doesn't offer. But it's just a speculation.

Here's a quote from FBlit's guide:

Quote:
Being able to use rastport/bitmaps outside Chip memory is not really of
any great benefit in itself, since usually a rastport's bitmap will
simply be the screen's bitmap on which the rastport appears, and
therefore must be in Chip memory. It became necessary as a result of the
next part of FBlit. When all bitmaps are allocated with planes in Fast
RAM, temporary bitmaps allocated for overlapped window regions will also
go in Fast RAM, so parts of rastports can end up outside Chip memory
under certain circumstances.

Having the OS able to use Fast RAM for non-displayable bitmaps is all
very nice, and maybe useful for programmers who know about it and want
to take advantage of it, but it makes no difference to existing
software.
ppill is offline  
Old 28 November 2006, 17:00   #6
Bloodwych
Moderator

Bloodwych's Avatar
 
Join Date: Jun 2001
Location: I'm behind you!
Posts: 3,757
Thanks for your help. I'll have a play around and see what's worth using in my ClassicWB packages.
Bloodwych is offline  
Old 16 November 2015, 20:56   #7
TenLeftFingers
Registered User

TenLeftFingers's Avatar
 
Join Date: Sep 2013
Location: Ireland
Age: 37
Posts: 739
Sorry to raise the dead but this seems as good a place as any wrt google search results others will come across.

I've installed fblit but jpeg and iff images (the only ones I have to hand) still use chip ram.
Any ideas why that would be?
TenLeftFingers is offline  
Old 16 November 2015, 21:31   #8
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,147
The graphics shown on-screen still need to use Chip RAM, it's only off-screen storage that gains a benefit. So an application loading the JPEG into RAM will use Fast RAM, but to actually display it, it will need to open a window which is in Chip RAM and put it there.

It could also be that the software you're using is forcing the image to be decoded into Chip RAM for some reason, though it shouldn't... What are you using to view them? What size and depth are they? What depth is the screen you're displaying them on?
Daedalus is offline  
Old 16 November 2015, 21:45   #9
TenLeftFingers
Registered User

TenLeftFingers's Avatar
 
Join Date: Sep 2013
Location: Ireland
Age: 37
Posts: 739
Thanks Daedalus, I didn't realise that Well, the screen mode is HIGHGFX 1024x768 with 8 colours, so 4 bits. I've tried scaling between 404kb and 11kb.

I'm trying multiview to preview them and WBPattern to set them as a background but only having success with one of my images. The f1e5zt.jpeg file displays fine (but tiled) after a few seconds but the koala.jpeg one causes an out of memory error with multiview and WBPattern does nothing with it.

Edit: I seem to be having better luck with the png datatype since installing it. Maybe I should just stick with that format.
Attached Thumbnails
Click image for larger version

Name:	koala.jpeg
Views:	98
Size:	11.5 KB
ID:	46273   Click image for larger version

Name:	f1e5zt.jpeg
Views:	135
Size:	93.1 KB
ID:	46274  

Last edited by TenLeftFingers; 16 November 2015 at 22:18.
TenLeftFingers is offline  
Old 17 November 2015, 10:49   #10
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,147
Yep, 1024x768 is quite big, though 8 colours is only 3 bits so you're saving a fair bit of chip RAM there. you need to remember that the image file size doesn't always correlate with the amount of RAM required to decode it or display it. So it's the original pixel dimensions and depth that matter, not the file size.

JPEGs are generally 24-bit, so take 3 bytes per pixel to hold in RAM, even if you can only see 8 colours. So your koala there, even though it's massively compressed, still takes up around 2.3MB of RAM to load, and at least 300KB of Chip RAM to display at 3 bits. Your Stunt car Racer image, even though it's a larger file size, only takes 0.75MB to load and 94KB of Chip RAM to display. (They're minimum theoretical values that depend on the datatypes etc. playing nicely with FBlit.)

PNG might be a better way to go then, although personally I'd recommend converting whatever image you want to use to IFF-ILBM and saving it at the same colour depth as the screen you're using. That will make sure it takes the minimum amount of RAM to display. It will also be the quickest to load since no real decompression or conversion needs to be done when it's loaded.

Last edited by Daedalus; 17 November 2015 at 10:55.
Daedalus is offline  
Old 17 November 2015, 17:27   #11
TenLeftFingers
Registered User

TenLeftFingers's Avatar
 
Join Date: Sep 2013
Location: Ireland
Age: 37
Posts: 739
I knew decoding would mean a change in the demands the image placed on the system but I didn't realise it was _that_ skewed between different formats. Thanks again, I will use IFF-ILBM from now on as I would also like to edit images and every byte helps!
TenLeftFingers is offline  
Old 17 November 2015, 17:41   #12
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,147
Yep, it's all about the decoded image, the initial format doesn't really tell you much. It's easy to work out, too:

(width*height*bit depth) / 8

to get the size of the image in bytes, regardless of the file size. IFF has the advantage of being able to save in just the number of bitplanes you want, which saves disk space and loading time as no conversion is necessary when it matches the screen's bit depth. Just remember that Workbench locks the first 4 pens, so it might help to set them in PPaint or whatever and remap the image before saving.
Daedalus is offline  
Old 17 November 2015, 18:57   #13
TenLeftFingers
Registered User

TenLeftFingers's Avatar
 
Join Date: Sep 2013
Location: Ireland
Age: 37
Posts: 739
Quote:
Originally Posted by Daedalus View Post
Yep, it's all about the decoded image, the initial format doesn't really tell you much. It's easy to work out, too:

(width*height*bit depth) / 8

to get the size of the image in bytes, regardless of the file size. IFF has the advantage of being able to save in just the number of bitplanes you want, which saves disk space and loading time as no conversion is necessary when it matches the screen's bit depth. Just remember that Workbench locks the first 4 pens, so it might help to set them in PPaint or whatever and remap the image before saving.
Cool, that is easy! Well, except for the bitplane/remap part which I don't understand but I'll read up on the terminology
TenLeftFingers is offline  
Old 17 November 2015, 22:16   #14
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 1,147
It's pretty easy Normally JPEGs are 24-bit, so that's 24. An 8-colour IFF file is 3 bits, 16 is 4 and so on. So loading a 640x480 JPEG is:

(640*480*24)/8 = 921,600 bytes (normally Fast RAM)

and to display it in 8 colours:

(640*480*3)/8 = 115,200 bytes (normally Chip RAM).
Daedalus is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Two Workbench Questions... wXR Amiga scene 16 29 January 2015 17:43
Could you help me with fblit, systempatch, afa_os ? ancalimon support.Apps 0 01 January 2010 04:08
Magic workbench beginners questions JACK98 support.Apps 11 06 February 2009 14:25
Fblit and Newicons and Fastram???? yadster support.Apps 21 13 September 2003 03:51
Workbench questions mtb support.Apps 18 06 October 2002 19:46

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 01:14.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2016, vBulletin Solutions, Inc.
Page generated in 0.22791 seconds with 14 queries