Hyperion Entertainment Message Boards

samo79 wrote:As far as i understand latest version of this library should be the 54.9 in FE,

No, the latest/last public one is 53.4 from 2012-04-14 (check http://amiupdate.amigaos.net/). FE should not have a Picasso96API.library at all, since it is now merged into graphics.library.

BTW, I can't see you picture, so I'm not sure which version from 2009 you have found.

so why my OS4.1 FE contain an old Picasso96 library of 2009 ??

I think someone must have acidentally left it there on the system used to build the ISO, although I can't imagine how an old one found its way there.

At any rate, you should be able to just delete it, it should never be needed any more. (If you want to play it safe, start by renaming it.)

Best regards,

Niels

Edit: Removed my nonsense remark about Kicklayout ...

Elwood wrote:Samo, there is NO more Picasso96 stuff in AmigaOS since FE:
> dir libs:Picasso96API.library
DIR : file not found

Are you sure you installed on a blank partition?
It seems you installed on top of an old system.

Well, on the Sam440 installation disc the file is actually present in the System/Libs dir. But it will not be active any more.

Best regards,

Niels

Elwood wrote:Are you sure you installed on a blank partition?
It seems you installed on top of an old system.

But this library is present on my Final Edition CD, so it was installed .. didn't know that in reality the library was removed completely as still visible on the benchmark page (54.x version): http://www.hdrlab.org.nz/benchmark/gfxb ... esult/1558

nbache wrote:No, the latest/last public one is 53.4 from 2012-04-14 (check http://amiupdate.amigaos.net/). FE should not have a Picasso96API.library at all, since it is now merged into graphics.library.

Ok then, however it didn't found any updated library if i start AmiUpdate (of course if the file is now obsolete there is no need for) ... but yep strange to see included an old release instead of the latest

nbache wrote:BTW, I can't see you picture, so I'm not sure which version from 2009 you have found.

Ah, I reupload the image then, see the previews page

nbache wrote:At any rate, you should be able to just delete it, it should never be needed any more. (If you want to play it safe, start by renaming it.)

Ok will rename it

samo79 wrote:didn't know that in reality the library was removed completely as still visible on the benchmark page (54.x version): http://www.hdrlab.org.nz/benchmark/gfxb ... esult/1558

If I understood it correctly, graphics.library when loaded now creates a "dummy" Picasso96API.library in memory, so old software will still work, but all calls are directed to the corresponding routines in graphics.library.

Ah, I reupload the image then, see the previews page

Yep, works now.

Best regards,

Niels

It would be nice if you, os4 team, have the courage to open your Bugs database like these 2 single persons.

https://muidev.de/query

It could be nice to know if it's a waste of time to report bug.

With FE, single users have the feeling to be BetaTesters, it could be nice to see that all our bugs were still reported by the True Army of BetaTesters

Conclusion, humility is a good quality, to be betatested !

zzd10h wrote:It would be nice if you, os4 team, have the courage to open your Bugs database like these 2 single persons.

https://muidev.de/query

It could be nice to know if it's a waste of time to report bug.

With FE, single users have the feeling to be BetaTesters, it could be nice to see that all our bugs were still reported by the True Army of BetaTesters

While I don't see the bug database being made public, I assure you that your bug reports do make a difference. Fixes to some of the problems identified are already being tested. I can't say when bug-fixes will be released, but I can say that we are definitely paying attention to bug reports.

Hans

Hans wrote:While I don't see the bug database being made public, I assure you that your bug reports do make a difference. Fixes to some of the problems identified are already being tested. I can't say when bug-fixes will be released, but I can say that we are definitely paying attention to bug reports.

In my opinion there would be many advantages in choose this way.

1 - First if somethings similar would be done, we could "as advanced users" verify easily if a bug was already reported by others or not
2 - Second: we could easily verify if a bug was already fixed or not instead of just pray during the wait
3 - Sometimes a particular "bugged" component may requires an intermediate testing phase on which advanced users may participate, in MUI a lot of not easy reproducible bugs were discovered and then solved only thanks to this.
4 - This would make the entire development more transparent and professional for end-users, in a short time we might have a lot system's components stable and heavy tested, not to mention that this method would open the door to a comfortable way for any eventual feature request during the development.

In short, we would not saw the current situation in which we found ourselves with this "final release" where too many problems have affected the use of the system by creating discontent ..

Hans wrote: While I don't see the bug database being made public, I assure you that your bug reports do make a difference. Fixes to some of the problems identified are already being tested. I can't say when bug-fixes will be released, but I can say that we are definitely paying attention to bug reports.
Hans

To some extent I have to agree with samo79. I think that the number of bugs reported after major releases and AmiUpdate releases is an indicator that the beta testing isn't as effecient as it should be. Plenty of open-source applications have bugzillas where a user can check if something has already been reported and avoid reporting it again. OS4 isn't open-source but I think it would benefit everyone if there was a bug database that is accessible only to registered OS4 users where you could enter the name of an OS4 component and get a list of reported problems. It would eliminate at least half of the duplicated reports in these forums.

I can ,however see the problem with an expanding the beta testing to more users. There wouldn't be much incentive for people to purchase new releases if the changes are already available to most users for beta testing.

xenic wrote:I can ,however see the problem with an expanding the beta testing to more users. There wouldn't be much incentive for people to purchase new releases if the changes are already available to most users for beta testing.

We beta testers are also paying for our release CDs. Full price. The incentive for me is to see the "party" going on (as Trevor would put it ).

But if some of you feel you can contribute to the beta testing, why not try asking to be accepted as such? I'm not sure if they are planning to expand the team at the moment, or how to make your interest known, hopefully someone in charge can comment on that.

Best regards,

Niels

xenic wrote:I think that the number of bugs reported after major releases and AmiUpdate releases is an indicator that the beta testing isn't as effecient as it should be...

The beta testing team consists entirely of unpaid volunteers constrained by an NDA. They do their best given the circumstances and I personally applaud them.

I also don't believe that testing improves quality. Testing only reveals quality. The quality is either there or it is not there. It is the developers that are responsible for the quality of the product. So if the beta testers don't reveal a few bugs that really isn't the problem. The real problem is the bugs shouldn't be there in the first place. We are working on various strategies to improve the product quality but yet more beta testing isn't one of them. Think more automated testing and such.