AmigaOS 3.2 and beyond

[gulliver]

Originally Posted by loonsta

I tried to send Thomas an email, but it bounced because "the address could not be found or is unable to receive email"

using the email shown here http://m68k.aminet.net/package/util/libs/MMULib

Can anyone confirm this is him? https://eab.abime.net/member.php?u=68171

Yes, it is him on the second link.
I also sent you a PM with his email.

[dao]

Hello everyone.
First of all, thanks to all the developers for your effort!
In November of last year I gave my A3000 a second life. Now I'm programming in AmigaE, as a hobby obviously. The big problem is finding updated documentation... I waste a lot of time doing anything. So it would be a great help for everyone to have good manuals, an updated RKM (even if it was in PDF) would be the best gift for the Amiga community.
With good documentation, examples that cover basic but also complex topics, a development environment easy to install... with all of this, surely many developers like me would be encouraged to code and create new software.
Thank you!

[coldacid]

I'd say that's off topic, but yeah a proper printed (or printable) RKM with coverage for 3.x and 4.x would be a godsend. The wiki doesn't really cut it compared to real documentation.

[MazinKaesar]

Originally Posted by gulliver

Yes, please send me an email briefly introducing yourself (in my EAB user profile is my email address).

Email sent, hope I can help someway.

[Daedalus]

I'm less sure about printable manuals. I always like them myself, but I find myself mostly using searchable electronic manuals instead these days. OS4 has an excellent SDK browser that lets you search all the Autodocs and includes you have installed, including 3rd party ones you add like MUI. That's something I miss on OS3. Instead, I tend to use the electronic RKRMs as they're quick to search, navigate and copy & paste from.

Of course, putting the Autodocs and other information together into a large PDF isn't that big a deal really, but I can't imagine printed copies being a worthwhile activity for the low numbers of probable sales...

[Minuous]

@Daedalus:

OS3 has AutodocReader, I find it to be quite usable.

[Daedalus]

Thanks, I'll check it out!

[kamelito]

CBM used BIX, is it possible to put online all the datas that were in BIX. It Would be nice for history but also to have answer about problems.

[coldacid]

@Daedalus: I'm not saying already-printed, I'm just saying printable -- so that those of us who work better with a book at our side can run off a copy and do so.

[Daedalus]

To be fair, when you said "printed (or printable)", I took that to mean both suggestions - either ready-printed or printable.

[coldacid]

Unfortunately the English language is a bit short on syntax and operators for logic. Sorry for the confusion, eh.

[kamelito]

Not sure if it already possible but for example I’m using CED and want to open a shell using Amiga E to run a command I can’t. So if not already possible when you’re using a program it could be nice to be able to use any WB shortcuts using an extra key for example.

[kamelito]

@Olsen

Is this bug fixed ?
https://groups.google.com/forum/#!to...er/ylvCCTVmL88

[boemann]

Originally Posted by kamelito

@Olsen

Is this bug fixed ?
https://groups.google.com/forum/#!to...er/ylvCCTVmL88

That is an interesting link. Thanks

[Olaf Barthel]

Originally Posted by kamelito

@Olsen

Is this bug fixed ?
https://groups.google.com/forum/#!to...er/ylvCCTVmL88

Yes, as far as I can tell. When I came up with that workaround in 1997 I did not know how much was broken in the BltMaskBitMapRastPort() code, but Thomas fixed the many bugs more than a year ago. It wasn't just that the modulus value for the mask bitplane was incorrect. That was just the most visible symptom, if you will.

[Olaf Barthel]

Originally Posted by boemann

That is an interesting link. Thanks

In the end, nothing was really resolved. The bug remained, and the workaround found its place in various operating system components, as well as Picasso96. Trond Werner Hansen's solution still required that you knew exactly which destination bitmap you would use BltMaskBitMapRastPort() on, meaning that you could not use one single mask bit plane for all cases. The original API definition permitted this.

[kamelito]

So in the end we cannot use the gfx v39 calls to do a a single blit with 3 sources like we can by using the blitter directly? Like most games do because it is faster?

[Samurai_Crow]

Originally Posted by kamelito

So in the end we cannot use the gfx v39 calls to do a a single blit with 3 sources like we can by using the blitter directly? Like most games do because it is faster?

There's always QBlit() if it were better documented, that is. Of course it doesn't work on graphics cards though.

[Olaf Barthel]

Originally Posted by kamelito

So in the end we cannot use the gfx v39 calls to do a a single blit with 3 sources like we can by using the blitter directly? Like most games do because it is faster?

No, not with this BltMaskBitMapRastPort() anyway. Most of the graphics.library blitter operation building blocks use two sources only. Which means that BltMaskBitMapRastPort() reuses the available framework which is already in place.

BltMaskBitMapRastPort() breaks down into three separate blitter operations executed in a particular sequence.

Did you ever wonder why the AutoDocs for BltMaskBitMapRastPort() mention which minterms to use, and why you'd want to invert the source and blit through the mask? This is because BltMaskBitMapRastPort() was originally used for Workbench icon rendering, and the inversion operation was a quick way to mark an icon as selected.

BltMaskBitMapRastPort() was added to graphics.library in Kickstart 1.2. Prior to that it was a local Workbench function called BltMaskRastPort().

And no matter what the name is, BltMaskBitMapRastPort() was written in 'C' until it was rewritten in assembly language for graphics.library V39.

Reading the documentation again, I'm getting very annoyed all over again over the shortcomings of the graphics.library AutoDocs. So much of it is incomplete, misleading or baffling.

For example, because the blitter operations only use two sources, the number of useful minterms is very restricted. If I remember correctly, it comes down to 16. Why are these sixteen minterms, and their effects, not documented as part of the RKMs or the AutoDocs? Not everybody's happy wrestling with boolean algebra to start with...

Instead we get something which accidentally looks like gardening advice ("You plant your brassicas in May, cover them in mulch.") in the BltMaskBitMapRastPort() AutoDocs which spell out the actual combination of minterms from <hardware/blit.h>. Or we get three free samples (copy, copy inverted, ignore the source and invert the destination) in the BltBitMap() AutoDocs. If I remember correctly, nowhere does the documentation even state which two sources are used by graphics.library (the sources are B and C; A is never used).

That's a "pretty picture" of just about the entire graphics.library documentation, and no mistake Compare that to the exec.library or intuition.library documentation which tries to be much more precise and insightful.

[kamelito]

@Olsen
Any plan to fix the gfx lib? Autodocs and code? Make the gfx lib worth using for games like Chris Green told us in his demos (AABoing and Tmapdemo) and like states in the CD32 dev docs.