AmigaOS 3.2 and beyond

[Michael]

Another nail into Guru's coffin. It was heavily connected to the chipset, and since OS moved towards RTG support it had to go. How many years was it with us? And that is only a fraction of Amiga's life. Time to move forward and cherish memories, and not getting amused by frustration.

[coldacid]

Originally Posted by Michael

What's wrong ? We have english and french versions.
If you advise what's required, it might just be implemented now.

Since I don't speak French, I can only assume that canada_français.country is correct, but for canada.country the decimal separator and time/date format strings have never been correct. I have no problem doing the work to fix the files up myself, but I need the chunk spec so I can properly update the file.

[boemann]

Originally Posted by Warty

@Boemann, about the textedit.gadget, can you share any more information?
- any built in 'save'/'load' functionality? if so, what does that look like?
- any provision for user-supplied markup? not the syntax highlighting that an app might provide, but bold, italic, etc.
- curious about performance. Running on bare 68000 is mentioned a few times, but I think of the old 1.x notepad app, and you could actually see the characters get drawn as you typed them. In general, Amiga editors and word processors always seemed slow to render characters, compared to same-generation Macs. I never knew if that was because every Amiga programmer had to write their own low level rendering (the mac toolbox (or whatever the ROM was called) provided a decent chunk of fast asm routines that could be used for stuff like that), or if it was more related to how intuition/KS worked overall.

Anyway, excited for the new text gadget, sounds great.

load and save is not done directly to file. As a programmer you have to implement that yourself. You basically give the gadget a buffer and it copies the text in either direction. This buffer needs to hold everything which naturally is a waste of memory, but for 3.2 I'm not improving on that.

User supplied markup is not supported in 3.2. The rendering engine actually does support it (same code that renders syntax highlighting), but the editing and undo/redo code doesn't and will mess it up so it is not enabled.

Performance is as said tested regularly on A500 but naturally you will not get miracles. There is only so much a 68000 can do. It is not really the copy pixels to screen that is the biggest problem and on an A500 the blitter is faster than asm anyway. Some of the tricks to get decent performance is to not render things more than once and to only render things that change. There is also performance to be gained from structuring the data the right way.

[Thomas Richter]

Originally Posted by Warty

- curious about performance. Running on bare 68000 is mentioned a few times, but I think of the old 1.x notepad app, and you could actually see the characters get drawn as you typed them. In general, Amiga editors and word processors always seemed slow to render characters, compared to same-generation Macs. I never knew if that was because every Amiga programmer had to write their own low level rendering (the mac toolbox (or whatever the ROM was called) provided a decent chunk of fast asm routines that could be used for stuff like that), or if it was more related to how intuition/KS worked overall.

Multiple factors add to the slowness of Notepad, and it is an interesting example of "failed software design". The old notepad keeps its text in a linear buffer, with line breaks indicated as LF (0x0a) and font and rendering changes as CSI sequences. Whenever you insert a character, it rescans its buffer, which takes its time.



To give an example. ViNCEd has a sane design where lines are represented as separate structures, and inserting or editing lines only requires updates of a line, and not scanning the full buffer.



A second factor is the Kick 1.3 "Text" function which renders glyph by glyph by a single blit, thus even if you draw 20 characters, the blitter is started 20 times instead of first fitting the glyphs in the buffer and blitting them in one go, as 2.0 does it.

[Warty]

Originally Posted by boemann

load and save is not done directly to file. As a programmer you have to implement that yourself. You basically give the gadget a buffer and it copies the text in either direction. This buffer needs to hold everything which naturally is a waste of memory, but for 3.2 I'm not improving on that.

User supplied markup is not supported in 3.2. The rendering engine actually does support it (same code that renders syntax highlighting), but the editing and undo/redo code doesn't and will mess it up so it is not enabled.

Performance is as said tested regularly on A500 but naturally you will not get miracles. There is only so much a 68000 can do. It is not really the copy pixels to screen that is the biggest problem and on an A500 the blitter is faster than asm anyway. Some of the tricks to get decent performance is to not render things more than once and to only render things that change. There is also performance to be gained from structuring the data the right way.

Thanks for the additional info. I must have a low threshold for excitement, but I'm pretty thrilled it has an undo stack built in. I *#$*@# hate programming undo stacks. The whole-buffer-at-once thing is going to put some practical performance limits in (especially for 68000s @ 7MHz), but probably something clever can be though of to deal with that for larger docs. Formatting: for next time then!

[Warty]

Originally Posted by Thomas Richter

Multiple factors add to the slowness of Notepad, and it is an interesting example of "failed software design". The old notepad keeps its text in a linear buffer, with line breaks indicated as LF (0x0a) and font and rendering changes as CSI sequences. Whenever you insert a character, it rescans its buffer, which takes its time.

I had to try it again after that info, and did some pasting... fascinating! it inserts each character one by one. I didn't remember that. Strange app. I'm sure someone had 8 hours to design it or something.

[malko]

Regarding the "GURU MEDITATION" parenthesis, just discovered that the Nintendo DS use the same wording
Former Amiga engineers ?

Source : Wikipedia

[coldacid]

Probably just homage. There's a number of other systems and software out there that use the message as well that have no Amiga connection other than some developers probably enjoyed using one as kids.

[Minuous]

Originally Posted by coldacid

Oh, by the way, will we finally get a correct country file for English Canada? If I could have the spec for the IFF CTRY chunk I could supply a corrected canada.country with the generally accepted locale values here.

The format is documented in prefs/locale.h.

I did some investigation and it looks like the decimal point is indeed wrong, it should be "." instead of ",". For the thousands separator, it would appear that the official separator is " ", even though "," is widely used (which is the same situation as here), so that should probably stay as " ".

[coldacid]

Minuous: I've side-channeled updates for canada.country and canada_français.country via another dev. The date/time strings as well as the currency code all needed correction as well, since (at least in English Canada) we are still de facto on 12h time, but with correct / European date ordering instead of that horrid American format.

[Tigerskunk]

Originally Posted by malko

Regarding the "GURU MEDITATION" parenthesis, just discovered that the Nintendo DS use the same wording
Former Amiga engineers ?

Source : Wikipedia

It's a homage. The Guru is a part of early computer geek culture, and you see it again and again somewhere over the years..

[nikosidis]

What you can do for a future classic update is a more advanced joystick interface "lowlevel.lib" Add support for analogue joysticks.

[Tigerskunk]

I hope you guys removed or renamed "GimmeZeroZero()" as well, such a silly nonsense function call name cannot be tolerated in a serious OS.

[Olaf Barthel]

Originally Posted by Steril707

I hope you guys removed or renamed "GimmeZeroZero()" as well, such a silly nonsense function call name cannot be tolerated in a serious OS.

Naming things well is reportedly one of the traditionally hard challenges in computer sciences (and real life, too, I guess). And it probably doesn't get any less challenging if you've spent so much time implementing the code for the upcoming CES that you're not getting enough sleep

GimmeZeroZero is an odd feature. I wonder whether the original Intuition had all non-borderless windows sport the GimmeZeroZero property by default. Without the GimmeZeroZero property, rendering to the window contents needs to be adjusted to skip the window borders, which is not always an option, e.g. line drawing becomes harder if you have to figure out where the clipping needs to take place. Also, you could get the same visual results with InstallClipRegion(), you'd just have to adjust the origin of the top left corner of the area surrounded by the border a bit.

I think GimmeZeroZero is in the best company as far as naming stuff in this domain goes

[Olaf Barthel]

Originally Posted by malko

Regarding the "GURU MEDITATION" parenthesis, just discovered that the Nintendo DS use the same wording
Former Amiga engineers ?

Working for Nintendo? Probably not: these engineers were more likely to work for other companies in the same general Silicon Valley area.

The "Guru Meditation" could be described as an intentionally puzzling message produced by a computer, not intended for anyone but the Gurus who put it there. That's a meme, which begs to be imitated

[Thomas Richter]

Originally Posted by Olaf Barthel

GimmeZeroZero is an odd feature. I wonder whether the original Intuition had all non-borderless windows sport the GimmeZeroZero property by default. Without the GimmeZeroZero property, rendering to the window contents needs to be adjusted to skip the window borders, which is not always an option, e.g. line drawing becomes harder if you have to figure out where the clipping needs to take place. Also, you could get the same visual results with InstallClipRegion(), you'd just have to adjust the origin of the top left corner of the area surrounded by the border a bit.

I think GimmeZeroZero is in the best company as far as naming stuff in this domain goes

Well, at least the naming of "GimmeZeroZero" is logical, even though it is slang. But I never understood the actual implementation of this feature, namely to give the rendering region of the window a separate layer. Which means additional work when the window is moved, which can be seen on old slow machines. The contents shifts independent from the window frame, really odd. Double resources, twice as slow, additional overhead for nothing.



Actually, *NOT* making GimmeZeroZero the default is also bewildering me as it requires the application writer to implement some "soft clipping" for the window frame borders himself instead of leaving this to layers, which can do the same just more reliable.



If I had to re-implement this type of logic, I would always make an installation of a clip rect and a rendering offset the default. Pretty much similar to what X11 does, which just draws the decoration around the existing window body, but does not allow drawing into the decoration (as intuition does). Actually, the Pascal "windowlib" I provided as abstraction for intuition does exactly that, to ease the life of the programmer.

[Tigerskunk]

Same reason why we have 'Firewalls' and 'Daemons'.

[aros-sg]

Originally Posted by Thomas Richter

If I had to re-implement this type of logic, I would always make an installation of a clip rect and a rendering offset the default. Pretty much similar to what X11 does, which just draws the decoration around the existing window body, but does not allow drawing into the decoration (as intuition does). Actually, the Pascal "windowlib" I provided as abstraction for intuition does exactly that, to ease the life of the programmer.

x11 has child windows (windows inside windows) and there the window managers create a new window for the border decoration and then re-parent the application window into that border window (parent window of application window = border window). So in X11 you actually have two windows (or layers), too, like with GZZ.


In AROS you can attach one clip rect to a rastport, with the special feature that the right/bottom of it can be relative to layer width/height (-> is not scared about evil async window resizing). This is a ~"runtime" clip rect applied in addition to ~"compiled" layer clip rects.

[Thomas Richter]

Originally Posted by aros-sg

x11 has child windows (windows inside windows) and there the window managers create a new window for the border decoration and then re-parent the application window into that border window (parent window of application window = border window). So in X11 you actually have two windows (or layers), too, like with GZZ.

Thanks for correcting this. Indeed, window decorations are a separate window indeed.

Originally Posted by aros-sg

In AROS you can attach one clip rect to a rastport, with the special feature that the right/bottom of it can be relative to layer width/height (-> is not scared about evil async window resizing). This is a ~"runtime" clip rect applied in addition to ~"compiled" layer clip rects.

This sounds like fixing the problem at the wrong spot. It is not the rastport that is resized as rastports do not have sizes, but rather intuition resizing the layer as part of the window. It would be the job of intuition of fixing "its own" cliprect as it is also responsible for resizing the layer of the window.


That intuition does not implement GZZ by means of cliprects is something that bewilders me.

[aros-sg]

Originally Posted by Thomas Richter

That intuition does not implement GZZ by means of cliprects is something that bewilders me.

Layer cliprects are slow and can eat lot of memory. If you have a smart refresh window with an installed clipping region to inner window area, and the window is hidden behind some other window. Then the hidden areas are backed up twice. And the clipping region will regularly be NULLed and then re-installed by Intuition when doing things like rendering gadgets or window border frame. In case of (partly) hidden smart refresh windows changing clipping region includes blitting stuff around as you know.