CompuServe Thread

I think the 1-pixel-right thing is because an old bug was fixed. It used-to-be that sprites were offset right by one pixel….

I think the 1-pixel-right thing is because an old bug was fixed. It used-to-be that sprites were offset right by one pixel….

How about this one: running the calculator from the CLI crashes the system. By the way, I think 1.2B4 has very few bugs (i.e. bearable) and therefore I am currently doing all my work on it.

How about this one: running the calculator from the CLI crashes the system. By the way, I think 1.2B4 has very few bugs (i.e. bearable) and therefore I am currently doing all my work on it.

A bug thread is a good idea, Brian! Here's what I've noticed so far. 1. A persistent bug in all versions to date: "list s" does not work from the CLI. "list s/" or "list s:" or "list :s" does. 2. ScrollLayers() was fixed in pt. When writing to an Intuition, GimmeZeroZero window in a workbench screen with a superbitmap larger than 640 pixels wide, Text() now will write lines longer than 640 into the superbitmap (unlike versions 1.2 beta 2 and 1.1). But if the text line crosses the 640 boundary, a few characters on either side of the boundary are smeared. Characters further beyond the boundary come out okay. (This is revealed by scrolling with ScrollLayers(). I am pretty certain that ScrollLayers() is not the problem.) The nature of the smearing depends on the window options. For example, if I make the window BORDERLESS!SIZEBBOTTOM, then ALL characters to the left of about 640 in a line longer at are okay. I suspect Text() is still buggy, but it may be something else. ClearEOL() still will not clear the superbitmap beyond 640 in windows like the above. It apparently has the same bugs as before. I worry about this, because I have not done systematic checks of other graphics functions writing across the 640 boundary in that kind of window, nor have I checked what happens at the 200 erbitmap. 3. Neither the Epson nor the Epson JX-80 driver recognizes the letter quality mode for the PRT: device set in preferences, when used with an Epson FX-80. Surely the FX-80 is THE standard Epson, and nearly THE standard printer?! 4. As we all know, the CLI does not include line editing on the command line, except for backspaces. I for one vote to classify that as a bug, in a machine of AMY's quality. 5. DiskDoctor in the toolkit does not recover valid data blocks on a track with any garbaged data–at least that's my interpretation of why it throws away uncorrupted files. 6. Clicking on the "searching for fonts" message on the workbench freezes the system. That's all for now. –David

A bug thread is a good idea, Brian! Here's what I've noticed so far. 1. A persistent bug in all versions to date: "list s" does not work from the CLI. "list s/" or "list s:" or "list :s" does. 2. ScrollLayers() was fixed in pt. When writing to an Intuition, GimmeZeroZero window in a workbench screen with a superbitmap larger than 640 pixels wide, Text() now will write lines longer than 640 into the superbitmap (unlike versions 1.2 beta 2 and 1.1). But if the text line crosses the 640 boundary, a few characters on either side of the boundary are smeared. Characters further beyond the boundary come out okay. (This is revealed by scrolling with ScrollLayers(). I am pretty certain that ScrollLayers() is not the problem.) The nature of the smearing depends on the window options. For example, if I make the window BORDERLESS!SIZEBBOTTOM, then ALL characters to the left of about 640 in a line longer at are okay. I suspect Text() is still buggy, but it may be something else. ClearEOL() still will not clear the superbitmap beyond 640 in windows like the above. It apparently has the same bugs as before. I worry about this, because I have not done systematic checks of other graphics functions writing across the 640 boundary in that kind of window, nor have I checked what happens at the 200 erbitmap. 3. Neither the Epson nor the Epson JX-80 driver recognizes the letter quality mode for the PRT: device set in preferences, when used with an Epson FX-80. Surely the FX-80 is THE standard Epson, and nearly THE standard printer?! 4. As we all know, the CLI does not include line editing on the command line, except for backspaces. I for one vote to classify that as a bug, in a machine of AMY's quality. 5. DiskDoctor in the toolkit does not recover valid data blocks on a track with any garbaged data–at least that's my interpretation of why it throws away uncorrupted files. 6. Clicking on the "searching for fonts" message on the workbench freezes the system. That's all for now. –David

I've just checked out the v 1.2 Beta 4 and have a few more observations to add. * Why were the complementing colours changed?! If an area of the screen was complemented in previously released versions, white changed to black while blue changed to red. The new version complements white to blue, black to red. This changes a lot of stuff in my code because I complement zones all over the place. I also scroll the raster with the fill colour set to the normal colour, fill in the text then complement and everything has worked out fine. Now will I have to set the scroll and other colours depending upon the version of Intuition I am using?! Isn't life tough enough already for Amiga programmers? * The new "improved" complementing messes up the rendering of STRING gadgets. The cursor shows up as white when the gadget is clicked on, then if the gadget is deselected the cursor position changes to a black area, not back to blue. * Menus that use an item as a toggle now look really messy. I have menu entries that are checked if active or enabled, non-checked if disabled. If the item is selected when it is checked, the menu disappears, then flashs back then disappears again. This is even worse if the item is "shift clicked", that is press the left button while the right button stays depressed. In this case, the menu disappears for a moment then reappears! This whole thing appears to be a workaround for a beta 2 problem where clicking on a checked item returned MENUNULL! It's really unacceptable in its current condition. These are the only problems I've encountered so far (haven't really tried that much with it yet though). Generally beta 4 seems to run faster, which is a welcome improvement! – Chris Bailey (Batteries Included)

I've just checked out the v 1.2 Beta 4 and have a few more observations to add. * Why were the complementing colours changed?! If an area of the screen was complemented in previously released versions, white changed to black while blue changed to red. The new version complements white to blue, black to red. This changes a lot of stuff in my code because I complement zones all over the place. I also scroll the raster with the fill colour set to the normal colour, fill in the text then complement and everything has worked out fine. Now will I have to set the scroll and other colours depending upon the version of Intuition I am using?! Isn't life tough enough already for Amiga programmers? * The new "improved" complementing messes up the rendering of STRING gadgets. The cursor shows up as white when the gadget is clicked on, then if the gadget is deselected the cursor position changes to a black area, not back to blue. * Menus that use an item as a toggle now look really messy. I have menu entries that are checked if active or enabled, non-checked if disabled. If the item is selected when it is checked, the menu disappears, then flashs back then disappears again. This is even worse if the item is "shift clicked", that is press the left button while the right button stays depressed. In this case, the menu disappears for a moment then reappears! This whole thing appears to be a workaround for a beta 2 problem where clicking on a checked item returned MENUNULL! It's really unacceptable in its current condition. These are the only problems I've encountered so far (haven't really tried that much with it yet though). Generally beta 4 seems to run faster, which is a welcome improvement! – Chris Bailey (Batteries Included)