FBlit source now open. - Page 3

Samurai_Crow · 10 March 2018, 18:26

Quote:

Originally Posted by PeterK

Ok, a particular task (game) can use the blitter directly and not through system calls like BltBitMapRastport(). That way, it can make a decision on every graphical object, whether to use FBlit or the blitter. FBlit may also be used directly, through fblit.library calls, I don't know.

Don't you know that BltBitMapRastPort calls QBlit to add a node to a rendering queue? The GameSmith runtime library only adds a background task to CPU blit in parallel to the blitter using the same rendering list. FBlit patches the QBlit function and probably others so only the CPU can blit.

PeterK · 10 March 2018, 18:38

No sorry, I don't know anything about QBlit or GameSmith. I just noticed that there is a QBSBlitPatch option in your FBlit configuration. But I have no knowledge about the details like you. I only learned how to configure FBlit for the icons on WB 3.1 or 3.5+. And it's doing a good job. Thanks for that tool!

Samurai_Crow · 10 March 2018, 18:58

Quote:

Originally Posted by PeterK

No sorry, I don't know anything about QBlit or GameSmith. I just noticed that there is a QBSBlitPatch option in your FBlit configuration. But I have no knowledge about the details like you. I only learned how to configure FBlit for the icons on WB 3.1 or 3.5+. And it's doing a good job. Thanks for that tool!

I am the maintainer of FBlit, not the author. I am glad you're able to use it though.

coder76 · 10 March 2018, 19:07

Quote:

Originally Posted by PeterK

@coder76
Usually FBlit uses graphical objects in FastMem and the blitter is restricted to ChipMem. You have to make a global decision where you want to store your images. Using FBlit has no advantages if your images are located in ChipMem. And FBlit can not split a call like BltBitMapRastport() into two parts. How should that go? Or should it play "one (call) for me, one for you"?

I don't know how FBlit works in detail, but of course you need to store your data in both fast and chip ram, if blitter and CPU operates on same objects. Mainly thought about fonts, icons and some window rendering which can have copies in both chip and fast ram of same data, and is static data. If there is a lot of dynamic data that changes whole time, it can become a performance problem to update them both into chip and fast.

Samurai_Crow · 10 March 2018, 19:17

Quote:

Originally Posted by coder76

I don't know how FBlit works in detail, but of course you need to store your data in both fast and chip ram, if blitter and CPU operates on same objects. Mainly thought about fonts, icons and some window rendering which can have copies in both chip and fast ram of same data, and is static data. If there is a lot of dynamic data that changes whole time, it can become a performance problem to update them both into chip and fast.

http://eab.abime.net/showthread.php?t=54913 shows that GameSmith is released from copyright. Use it for your game projects instead. FBlit is not as good for what you are trying to do.

PeterK · 10 March 2018, 19:37

Quote:

Originally Posted by coder76

... you need to store your data in both fast and chip ram, if blitter and CPU operates on same objects. Mainly thought about fonts, icons and some window rendering which can have copies in both chip and fast ram of same data, and is static data. If there is a lot of dynamic data that changes whole time, it can become a performance problem to update them both into chip and fast.

If you are talking about Workbench regarding icons and windows there is the problem that WB processes all windows and icons in single tasking mode, one after another, and it has a global setting for the type of memory. Only DOpus5 opens all windows with their own tasks. I don't see any chance to achieve a parallel blitting of Workbench objects. That's only an option for other programs, like games.

coder76 · 10 March 2018, 22:10

@Samurai Crow
Thanks for the idea, but I'm used to hack Amiga hardware directly with just asm and maybe C. Got some experience from past, so not starting from a clean table.

@PeterK
Yes, ok. It seems that AmigaOS would then need to be rewritten to use CPU and blitter at same time.

Samurai_Crow · 11 March 2018, 07:41

Quote:

Originally Posted by coder76

@Samurai Crow
Thanks for the idea, but I'm used to hack Amiga hardware directly with just asm and maybe C. Got some experience from past, so not starting from a clean table.

Good because those are the only two languages that GameSmith supports. The copper support needs work but the CPU assisted blitting is handy! Since it's released from copyright, I should build it into some Aros drivers or something.

coder76 · 11 March 2018, 12:19

Yes ok, but I still think GameSmith doesn't offer what I'm looking for. After reading some Atari Forums, I became interested in how one could implement software sprites on Amiga, and that means drawing sprites as fast as possible with CPU without blitter assistance. They use e.g. sprite code generators on Atari ST and Falcon which is some precomputed m68k code optimized for each sprite. Then one can also use preshifted versions of sprites to avoid using expensive bitshifts when plotting graphics with CPU, but they do require some 16 times more memory for word alignment.

Bitfield instructions are another possibility for software sprites that I have looked into, and pretty much nobody has used these, and they certainly do work, but I haven't yet made some performance comparisons how fast these are vs other methods.

Photon · 11 March 2018, 13:27

Quote:

Originally Posted by coder76

Can Fblit use CPU and blitter at same time for same tasks? on AGA machines with fastram, there is certainly enough bandwidth for CPU and blitter to work in parallell into chip ram. With 32-bit memory accesses for everything the bandwidth is 14 MB/sec to chip ram, but as you know blitter has only 16-bit access, bitplanes can be 64-bit (in 4X mode), and CPU has 32-bit memory accesses for 68020+. This means that CPU+blitter bandwidth can maximally be around 10 MB/sec into chip ram, which is quite an improvement over only blitter (around 3,3 MB/sec), or CPU only (7 MB/sec).

Doesn't work like that.

Romanujan · 11 March 2018, 13:58

Quote:

Originally Posted by Samurai_Crow

I am the maintainer of FBlit, not the author.

Looks like FBlit has now two maintainers: http://leblogdecosmos.blogspot.hk/20...ibrary-11.html

Samurai_Crow · 11 March 2018, 14:49

Quote:

Originally Posted by Romanujan

Looks like FBlit has now two maintainers: http://leblogdecosmos.blogspot.hk/20...ibrary-11.html

Cosmos has a habit of reverse engineering binary files. He probably didn't know the source code was public.

Edit: I see he got the source from the original author. We'll see if he sends a pull request. Unfortunately, changing the url to .com didn't put the post buttons in English and they were graphical so I couldn't read the French.

coder76 · 11 March 2018, 16:59

Quote:

Originally Posted by Photon

Doesn't work like that.

Could you be more specific? The tests on my Blizzard IV board on an A1200 with a 68030/50 MHz and fast ram gives over 10 MB/sec with cpu + blitter performing straight copies into chip ram at same time. This is with bitplane DMA off. On a 640x480 screen with 4 colors the bandwidth is still a bit above 9,0 MB/sec.

Edit: ok, had some trouble checking my results, it does seem that above holds only for using blitter channel D, and disabling rest channels. So you get a clear operation only as the straight copy. Using channel A is usually free, but not in this case, as it eats more chip bandwidth and slows down CPU. With A = D copy the speed of CPU declines pretty much and the above does not hold what I wrote.

Samurai_Crow · 14 March 2018, 11:15

Quote:

Originally Posted by Romanujan

Looks like FBlit has now two maintainers: http://leblogdecosmos.blogspot.hk/20...ibrary-11.html

It seems he didn't want his changes to be made public. Ah well....

Korodny · 14 March 2018, 17:20

Quote:

Originally Posted by Samurai_Crow

It seems he didn't want his changes to be made public. Ah well....

Which is probably a good thing, given that everybody who ever discussed code with him ran away screaming. Not to mention his complete disregard for other people's rights.

ancalimon · 16 June 2020, 17:52

Is there an updated version we can download?

Samurai_Crow · 16 June 2020, 17:59

Updated? Updated to what? Are you running into problems?

ancalimon · 16 June 2020, 18:02

Quote:

Originally Posted by Samurai_Crow

Updated? Updated to what? Are you running into problems?

Artifacts on screen.

Samurai_Crow · 16 June 2020, 18:08

Uh oh. I haven't looked at the source in years.

10 March 2018, 18:38	#42
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,383	No sorry, I don't know anything about QBlit or GameSmith. I just noticed that there is a QBSBlitPatch option in your FBlit configuration. But I have no knowledge about the details like you. I only learned how to configure FBlit for the icons on WB 3.1 or 3.5+. And it's doing a good job. Thanks for that tool! Last edited by PeterK; 10 March 2018 at 18:45.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Open-source scsi device	Don_Adan	Coders. System	92	05 January 2024 01:48
Please open source all the things	wXR	Amiga scene	382	21 April 2020 17:21
Open source CLI commands	Mrs Beanbag	Coders. System	13	10 December 2016 09:50
NewsRog goes Open Source	Paul	News	0	04 December 2004 16:37
BlitzBasic - Is now open source	Djay	Amiga scene	2	08 February 2003 01:09

10 March 2018, 22:10	#47
coder76 Registered User Join Date: Dec 2016 Location: Finland Posts: 168	@Samurai Crow Thanks for the idea, but I'm used to hack Amiga hardware directly with just asm and maybe C. Got some experience from past, so not starting from a clean table. @PeterK Yes, ok. It seems that AmigaOS would then need to be rewritten to use CPU and blitter at same time.

11 March 2018, 12:19	#49
coder76 Registered User Join Date: Dec 2016 Location: Finland Posts: 168	Yes ok, but I still think GameSmith doesn't offer what I'm looking for. After reading some Atari Forums, I became interested in how one could implement software sprites on Amiga, and that means drawing sprites as fast as possible with CPU without blitter assistance. They use e.g. sprite code generators on Atari ST and Falcon which is some precomputed m68k code optimized for each sprite. Then one can also use preshifted versions of sprites to avoid using expensive bitshifts when plotting graphics with CPU, but they do require some 16 times more memory for word alignment. Bitfield instructions are another possibility for software sprites that I have looked into, and pretty much nobody has used these, and they certainly do work, but I haven't yet made some performance comparisons how fast these are vs other methods.

16 June 2020, 17:52	#56
ancalimon Supernormal Join Date: Jul 2007 Location: Istanbul / Turkey Age: 43 Posts: 1,416	Is there an updated version we can download?

16 June 2020, 17:59	#57
Samurai_Crow Total Chaos forever! Join Date: Aug 2007 Location: Waterville, MN, USA Age: 49 Posts: 2,192	Updated? Updated to what? Are you running into problems?

16 June 2020, 18:08	#59
Samurai_Crow Total Chaos forever! Join Date: Aug 2007 Location: Waterville, MN, USA Age: 49 Posts: 2,192	Uh oh. I haven't looked at the source in years.

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