AmigaOS 3.2 and beyond

[Olaf Barthel]

Originally Posted by kamelito

@Olsen
Any plan to fix the gfx lib? Autodocs and code?

Tough one, graphics.library being what it is. A small step towards making it better would be to review the AutoDocs, take notes on what is lacking in quality and content and then finally edit the documentation. Next step, review the header files and document the data structures and constants. Next step after that, review the example code and apply the same principles again. Final step of that process: take a look at the RKM contents and get really worried about what could be rewritten/added here to make this more useful and generally relevant.

Not the kind of task everybody's looking forward to, though. We'd have to catch up with almost 35 years of neglect

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.

You are probably thinking of specialfx.library, which was then in development primarily for the benefit of the CD32, but it also shipped in early developer test versions for the A1200 and A4000.

There was even a fairly complex and complete demo for the A4000T which came with full source code (at least for developers). I wish I could remember what its name was, so that I could dig for it in the archives. Basically, it streamed an animation generated with VistaPro, overlayed with sprites and different display resolutions, sort of a small demo version of what the "Microcosm" gameplay was like on the CD32. This particular demo, however, was designed for the A4000T and would use specialfx.library, if I remember correctly.

[kamelito]

Just using V39 gfx but I’m surprised that it is so bad. Maybe games and multimedia should use the specialfx.library but you’ve to release it with docs and includes.
“ hazy: Some AAA stuff will get "built-in" like with the current chips, some
may only be available via RTG drivers, and I suspect some will get really
hot under specialfx.library. ”

[Samurai_Crow]

Graphics.library has been unable to create a majority of Amiga special effects and that extends beyond 3 input blits too. MrgCop() only merges linked lists of instructions rather than sorting sublists of cmoves with an implicit cwait in the structure header and all encodings of cmoves macro-converted at compile time rather than runtime. MrgCop() is the bane of system-friendliness.

[brett71]

Something I would like to see in AmigaOS 3.2 or later is a new version of the Installer which can also uninstall applications that are no longer needed and undo the changes gracefully that were made when the application was installed. Something similar to how installing and uninstalling software works in Windows. Backwards compatibility would be nice...

[gulliver]

Thank you all for the suggestions and feedback.

There are a few of your ideas that are already being worked on for AmigaOS 3.2.
Others will probably have to wait till we have the manpower to materialize them.

Again, thank you for engaging into this ongoing conversation.

[Minuous]

@brett71:

On Windows, the applications generally provide an uninstallation script. Doing the same is also an option for Amiga application developers.

Having the OS attempt to do this itself heuristically can be asking for trouble. Not all changes are easily reversible, nor necessarily wise to reverse, for instance.

[Thomas Richter]

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

Of course you can, they are just part of a different function family, and exactly where games expect them. The whole Bob/VSprite/AnimObj/AnimComp machine does 3-source blits: Source, mask and target, and it is exactly targetted at what games require: Moving objects.


BltMaskBitmapRastPort() is not a 3-comonent blit but emulates them by two blitter operations because there is a technical insufficiency in the blitter hardware that disallows that. The problem is that the above function takes a srcx/srcy parameter pair. While this seems unrelated to the issue, the trouble is that if you think about it, then the BltMaskBitMapRastPort() function requires two masks, one is the mask supplied, the other is the boundary of the rastport. While you may believe that the mask of the A channel of the blitter can do that for you, when thinking about it you will find that a single 16 bit FWM mask and another 16 bit LWM mask is not sufficient to address all cases if you have a target boundary (due to the layer bounds of the rastport) and a source x coordinate (due to the input parameter).


So what graphics does in the end is to hand-compute a suitable mask with the CPU which has the width of one blit line, with edges such that it excludes pixels outside the rastport *AND* outside the source which needs to be shifted due to srcx, puts that temporary mask into a TmpRas or the last chance memory of gfx, and loads the A channel with this "full width mask". Channel B is the source, channel C the destination, channel D the target. There is no fifth channel for the input mask, so two blits are required. It would have worked if the LWM and FWM would be wider than 16 bit, but they are not.


The reason why the animation engine gets away with this restriction is that the bobs are always word-aligned, i.e. there is no SrcX. Then, a 16 bit FMW/LWM is enough.


Morale of the story: If you want to use 3-source blits, use the animation system. That's exactly what it is good for. BltMaskBitMapRastPort() is only for rendering graphics, but not for animation.

[kamelito]

@Thor thanks for the clarifications. I’ll look into it.
You mean the GELs animation system? Was it updated for v39/40? Like for interleaved bitmap?
Ps you’ve been missed

[hUMUNGUs]

Finally The Richter is back :-)

[Thomas Richter]

Originally Posted by kamelito

You mean the GELs animation system?

Yes.

Originally Posted by kamelito

Was it updated for v39/40? Like for interleaved bitmap?

No, and no. It was neither necessary to update it, nor possible. It is not necessary because the modulo value of a (target) interleaved bitmap is correct and describes the offset from one row to another consistently, so blitting blindly from or to a interleaved bitmap with a non-interleaved aware function "just works", though potentially slower than necessary. It is not possible because the bob source is in a non-bitmap format that is non-interleaved, so even if it had special support for interleaved, it could not take advantage of the interleaving. The only advantage of interleaved bitmaps is that sometimes you only need one big blit for multi-bitplane (>2 color) bits if source and target are interleaved. Unfortunately, the source of the Bob is planar, and cannot be made interleaved as it does not use a bitplane structure. Another example of an insufficient abstraction in graphics, unfortunately.



You may now wonder why BltMaskBitmapRastPort() got it wrong given that the source and target bitmap modulo values are all consistent in the interleaved case which means "it should just work right". The answer is that the mask is not a bitmap, and the above function builds a bitmap for it to run it through the lower levels. Unfortunately, it did this incorrectly so by just copying the modulo value and taking this as the width of the mask. However, modulo != width for interleaved bitmaps, and that's where it was all screwed up.

[kamelito]

What I wanted to do was patching a game that hit the hardware by system calls. So if the gfx is done in interleaved b/c it is faster I can’t. So is a game.library heavily targetting games a possibility while being system friendly?

[kamelito]

specialfx.library, see post from Spencer Shanson (please share it
If you also read what he said about V39 in gfx lib (devcon 1993), double buffering for smooth animation (no flicker), allocbitmap() with friend bitmap for fast blitting into the bitmap (one blit), and plan for 3.01 I wonder why the Gels animation system is not tailored to take advantage of these new functions or why a substitute does not exist.

https://groups.google.com/forum/#!se...w/aiYzz-BO13QJ

[brett71]

Originally Posted by Minuous

@brett71:

On Windows, the applications generally provide an uninstallation script. Doing the same is also an option for Amiga application developers.

Having the OS attempt to do this itself heuristically can be asking for trouble. Not all changes are easily reversible, nor necessarily wise to reverse, for instance.

Yeah, I know what you're saying. I think that's along the lines of what I was thinking, that an uninstall script would be generated during the install, but could be processed by the same executable to undo the changes made. I always thought it was a bit of a pain to try to manually track down everything a particular application might have installed in C: or LIBS: or changes to the startup-sequence. On the other hand, the Amiga doesn't suffer from the same sort of .DLL Hell than a Windows machine does...

[Daedalus]

Part of the problem there is that there's also no way of an uninstaller knowing if any installed common components (e.g. in LIBS: or C: ) are required by any other program. So, you install program A that needs random.library in LIBS:. Then you install program B that also uses random.library, but didn't install it as there was already a copy in LIBS:. Then you uninstall program A, which put random.library in place and so removes it again. Program B stops working, maybe even crashes, and you're left scratching your head about what changed.

[daxb]

Yes, such uninstaller isn't possible for everything. It had to be in the system from the beginning to work. Now it is too late. On the other hand, it is not that difficult to manually uninstall software. In many cases it is just delete program directory. If you use an installer you can use the installers log to see what files are copied. For system stuff like c, libs, devs, fonts, ... and you don't know if that is still used by other software, just leave it. Shouldn't waste much space. Renaming can help to see if it is still used by something. You should get an error message or something like that. Problem is that all installed software needs to launched/checked.

[Jope]

An uninstaller would need some kind of semaphore database with a new row for every copied shared file.. Which would naturally then mess itself up somehow and cause headaches. :-)

[DarrenHD]

Thanks for everyone's work on OS 3.2! Can't wait! I was wondering if there is any kind of AmiDock in 3.2? I heard rumours of a new 3.2 rom, and another method (perhaps) to remove the boot reset after modules are loaded. Would be nice, but better yet full roms.

One other question, did you get any positive communications/cooperation from Frank Mariak (CyberGraphX)? Would be nice. I'm still using CyberGraphX on my A2000/060/CyberVision 3D.

By the way, and I know the OS4 Radeon driver has it's own history...but it would be immensely nice somehow to back-port the OS4 Classic Warp3D Radeon support to Warp3D/OS 3.x. Voodoo cards have reached "vintage" status and go for outrageous prices on eBay, if you can even find one.

Thanks
Darren

[Gorf]

Originally Posted by Jope

An uninstaller would need some kind of semaphore database with a new row for every copied shared file.. Which would naturally then mess itself up somehow and cause headaches. :-)

we could call it "register"

I would rather prefer apps that are self-contained (in a drawer or pseudo-drawer like on Mac) - any necessary assigns can be done at the programs start.
There are many programs that do that already ...

But the OS could provide some intelligent trash bin: if a program-drawer is moved to trash it starts looking for related files in WBStartup, some entries in the startup sequence, ... it could do that by searching for similar names and/or by looking at the installer-script if this is available in the program-drawer...

[DarrenHD]

Originally Posted by Gorf

we could call it "register"

I would rather prefer apps that are self-contained (in a drawer or pseudo-drawer like on Mac) - any necessary assigns can be done at the programs start.
There are many programs that do that already ...

But the OS could provide some intelligent trash bin: if a program-drawer is moved to trash it starts looking for related files in WBStartup, some entries in the startup sequence, ... it could do that by searching for similar names and/or by looking at the installer-script if this is available in the program-drawer...

OS4 has AmiUpdate which has a Rollback feature...perhaps that could be looked at for OS 3.x. I would put an uninstaller as a very "low" priority, however. Lots of other stuff should be updated/fixed/included before that in my opinion.

[utri007]

I would suggest do not develop it any more. Any new feature is going to broke something and cause problems with older software. Using OS3.1.4 has several show stopper features for me, at least it shouldn't require new rom or rom modules. There is a problem if I use it with kickstart 3.1 and load modules with loadmodules command. I can't boot to OS without startup-sequence. And if using a rom, then lefting Workbench library out of kickstart is causing unsovable problems. or (at least I don't accept solution) Seems that I can't solve that problem with 1mb rom with older workbench.library inside of it.