Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: AmigaOS and the Console Development - Part 1  (Read 7561 times)

0 Members and 1 Guest are viewing this topic.

Offline wawrzon

Re: AmigaOS and the Console Development - Part 1
« Reply #30 on: October 03, 2015, 12:20:37 PM »
Quote from: kolla;796768
I suppose the idea is "convinced".

kool!
 

Offline psxphill

Re: AmigaOS and the Console Development - Part 1
« Reply #31 on: October 03, 2015, 12:25:43 PM »
Quote from: olsen;796689
Now, what exactly will SetWriteMask() do in this situation? It has the effect of making display updates more costly if an interleaved bitmap is used (which is the standard case). Instead of moving one consecutive chunk of bitmap data, the blitter operations have to be broken up into individual planes again. Available bandwidth is used less effectively. This can be noticeably slower.

It won't be more costly in the standard case when only one bitplane is scrolled, if more than one is scrolled then the overhead is just waking the CPU up and getting it to kick off the next blit and in some cases you can do it with one blit anyway.

In fact not calling SetWriteMask() would make "the display updates more costly" in the "standard case" as "available bandwidth is used less effectively" (for the simple reason that you are copying up to 8 times the data with the blitter).

The way the autodoc is written I would only expect the call to only have an effect on planar screens, so there isn't a clear benefit to removing the call.
« Last Edit: October 03, 2015, 12:35:34 PM by psxphill »
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #32 on: October 03, 2015, 01:15:41 PM »
Quote from: psxphill;796770
The way the autodoc is written I would only expect the call to only have an effect on planar screens, so there isn't a clear benefit to removing the call.

Unfortuntely, this "non-standard case" you mention in this last sentence *is* the standard case for PPC, namely "chunky graphics". And that's exactly what the conversion to C was made for: The PPC "chunky graphics case". Believe me, you don't want your graphics software to emulate planar scrolling on chunky graphics, that is much more overhead than to scroll eight planes on a planar bitplane.
 

Offline itix

Re: AmigaOS and the Console Development - Part 1
« Reply #33 on: October 03, 2015, 03:01:42 PM »
Quote from: Hans_;796716
Quote

Good explanation. So the SetWriteMask() is only an optimization for non-interleaved planar bitmaps? It now sounds like SetWriteMask() should be removed in all cases for AmigaOS 3+.

Uh, no. We want to move away from people peeking and poking about in internal OS structures.


RastPort structure is not really an internal OS structure. For most purposes it is a parameter structure defining additional parameters to gfx operations. Drawing mode, write mask and so on could be just nth parameter to gfx operations and storing those parameters to rastport is a mere convenience to developers. From clean API design POV those parameters dont need separate getter and setter functions.

Introducing SetWriteMask() in Kickstart 3.0 was never necessary but just an example how CBM developers were lost in details.
My Amigas: A500, Mac Mini and PowerBook
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #34 on: October 03, 2015, 03:58:36 PM »
Quote from: itix;796774
RastPort structure is not really an internal OS structure.  
Says who? Look, the problem with gfx all over is that it never documented which structures are internal, and which are not. Is a struct ViewPort an internal structure?

Hard to say. It is documented. Should it be documented? Probably not.
Quote from: itix;796774
For most purposes it is a parameter structure defining additional parameters to gfx operations. Drawing mode, write mask and so on could be just nth parameter to gfx operations and storing those parameters to rastport is a mere convenience to developers.
Really? So for example, what is the difference between the APen, which must be set with SetAPen() or it does not function correctly, and the WriteMask, which is poked into the structure but still works? Does it work by accident? By intention?

The difference between the APen and the WriteMask is an implementation detail: The APen forces a recomputation of the MinTerms, the WriteMask does not. But that's simply "how gfx works internally", and it's really not spelled out that explicitly. Somehow, "you have to know".

It really boils down to that: Gfx is a big piece of junk, it is exactly "how not to write software", namely not defining proper interfaces. Gfx leaves it pretty much unclear which part of it is an interface, and what is internal, and where which part stops.


Quote from: itix;796774
From clean API design POV those parameters dont need separate getter and setter functions.
From a clean API design POV, this structure should be undocumented, and you should use getters and setters. But gfx does not have an "API design". It is quickly hacked together, and it shows.


Quote from: itix;796774
Introducing SetWriteMask() in Kickstart 3.0 was never necessary but just an example how CBM developers were lost in details.

It is a necessary extension to create a somewhat clean interface for gfx, on a "best attempt" basis.

So for example, why would graphics card hardware have to read the write mask from the rastport? It could also store it somewhere else, in some other form. SetWriteMask() could very well be patched over, performing internal adjustments of whatever the graphics card software has to do.

Remember, SetAPen() also adjusts some internal graphics structures in "some way" you're not supposed to depend upon.

The difference between the APen and the WriteMask is really just an implementation artefact and not a "design choice".
 

Offline itix

Re: AmigaOS and the Console Development - Part 1
« Reply #35 on: October 03, 2015, 04:43:12 PM »
Quote from: Thomas Richter;796778
Says who? Look, the problem with gfx all over is that it never documented which structures are internal, and which are not. Is a struct ViewPort an internal structure?

Hard to say. It is documented. Should it be documented? Probably not.

From developer point of view ViewPort is not an internal structure. You just fill some data and pass pointer to MakeVPort(). Internally the OS could convert data to its own private, internal format. We know that the OS dont do that but it could have been designed to work like that...

Some parts work like this. For example to open window you can create NewWindow structure. Internally Intuition is not linking this structure to its private data but new structure, Window, is created instead. Unfortunately this structure is returned to the caller... but you get the idea. The struct NewWindow describes what you want and Intuition does its best to satisfy your request.

Quote
Really? So for example, what is the difference between the APen, which must be set with SetAPen() or it does not function correctly, and the WriteMask, which is poked into the structure but still works? Does it work by accident? By intention?

The difference between the APen and the WriteMask is an implementation detail: The APen forces a recomputation of the MinTerms, the WriteMask does not. But that's simply "how gfx works internally", and it's really not spelled out that explicitly. Somehow, "you have to know".

I know that SetAPen() calculates those silly minterms. But from implementation point of view there is no need to calculate this data in SetAPen(). Minterms could be calculated in drawing operations and results could be cached to some other private data structure.

In RTG systems SetAPen() is even less useful because there private minterms are not used anymore. However, at the time when SetAPen() is called it can't know this and it has to recalculate minterms just in case. If minterms were checked in RectFill()/Text()/whatever you could skip this minterm calculation when it is not needed by target bitmap.

Quote
It really boils down to that: Gfx is a big piece of junk, it is exactly "how not to write software", namely not defining proper interfaces. Gfx leaves it pretty much unclear which part of it is an interface, and what is internal, and where which part stops.

I agree.

Quote
From a clean API design POV, this structure should be undocumented, and you should use getters and setters. But gfx does not have an "API design". It is quickly hacked together, and it shows.

It depends. In Windows API you are passing loads of parameters through structures. They are just parameter containers, not internal OS structures that would be passed through to OS. RastPort should be just like this: a paremeter container.

Quote
So for example, why would graphics card hardware have to read the write mask from the rastport? It could also store it somewhere else, in some other form. SetWriteMask() could very well be patched over, performing internal adjustments of whatever the graphics card software has to do.

It can do that, even when setting write mask directly to rastport. For example when Text() is called the system could collect relevant parameters from RastPort to its own internal private structure and execute render function asynchronously on the target hardware.
« Last Edit: October 03, 2015, 04:54:37 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline psxphill

Re: AmigaOS and the Console Development - Part 1
« Reply #36 on: October 03, 2015, 05:19:14 PM »
Quote from: Thomas Richter;796771
Believe me, you don't want your graphics software to emulate planar scrolling on chunky graphics

The autodoc for SetWriteMask says that the device can ignore you, but if for compatibility they emulate it then technically you do want it to be called as someone might have done something funky like draw a background in the console they don't want scrolled.

However using SetMaxPen instead is probably the better option.
« Last Edit: October 03, 2015, 05:34:15 PM by psxphill »