Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#62 closed bug (fixed)

Cybergraphics.library dependency

Reported by: Mikhail Malyshev Owned by: Thore Böckelmann
Priority: undecided Milestone: 3.9-2014R2
Component: undefined Version: 3.9-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Please look into this matter, MUI should start without problems when cybergraphics.library is not available, and not crash with a GURU. Older MUI checked for the cgx.lib on startup, and if it was not available happily continued to load, the current builds are hammering for it and come to a dead end. If some of the new functions heavily rely on some of the functionalities in CGX then those functions should be restricted in function but remain in adequate working condition (without candy).

Change History (14)

comment:1 Changed 50 years ago by Mikhail Malyshev

Status: pendingnew

comment:1 Changed 5 years ago by Jens Maus

This should be able to be implemented. However, lets make one thing clear:

  1. It has low priority for us
  2. If we implement that we will not tune MUI in any way that it will run nicer or better for non-cgx (non true color) screens. That means if MUI will look ugly, broken or has strange colors, we won't tune it any further.

If you can live with that fine, if not we will keep CGX dependency.

comment:2 Changed 5 years ago by Mikhail Malyshev

  1. Priority is fine, we can wait as long as it does not take forever.
  1. Here there is some confusion, from one side you say you will do fine tuning of MUI for non cgx and non true colour screens and at the same time if you do it, it will make it ugly and you will not do anything with it. This somewhat exclude both at the same time, since they are dependent issues.

Let me rephrase my point. We have 3.8 and even 3.9(2005) that work for everyone. So all that needs to be done is split the new fancy candy what ever stuff from a frozen state of previous versions. That means that the bells and whistles that require something new do not interfere with the 'legacy' part. And everyone is happy. Personally I don't see anything special in current builds that make it such a big problem to keep it functional.

PS: And yes, the world is moving forward, and that is good, but those that do not remember the roots are making a big mistake. (in terms of real life examples)

comment:3 in reply to:  2 Changed 5 years ago by Thore Böckelmann

Replying to Michael:

Let me rephrase my point. We have 3.8 and even 3.9(2005) that work for everyone.

Wrong! We just have MUI 3.8 and the current MUI 3.9. The "2005" MUI 3.9 you are constantly referring to is obsolete and was meant for early AmigaOS4 beta testers only. There has never been an official release for AmigaOS3 of that version and there is no point in repeatedly comparing that version to the current one.

comment:4 Changed 5 years ago by Mikhail Malyshev

I am just pointing out that the code that worked was there, no need to invent it, just reuse it when needed. And there was another one for MOS that also works fine. And that one is open to everyone.
All I am trying to do is to polish the product to a better state that will make the world brighter and happier. And we have an opportunity to compare and learn on the mistakes that have been done in the past so that we can avoid them in future.

comment:5 in reply to:  4 Changed 5 years ago by Jens Maus

Replying to Michael:

I am just pointing out that the code that worked was there, no need to invent it, just reuse it when needed. And there was another one for MOS that also works fine. And that one is open to everyone.
All I am trying to do is to polish the product to a better state that will make the world brighter and happier. And we have an opportunity to compare and learn on the mistakes that have been done in the past so that we can avoid them in future.

Michael, I certainly understand your desire but you have to finally acknowledge that it is up to us to decide what would be best for MUI and what not. And we have a clear roadmap for MUI these days and this clearly doesn't include improving MUI for old, obsolete systems like underpowered classic system with low screen resolutions. So you can bring up your desire a thousand times and we will a thousand times say no to it. Of course we will fix bug and crashes caused by new features. But our clear target is not to continue support for old systems but to get people to switch to more modern Amiga systems. So anyone wanting to keep their old A500, A1000, A2000, A3000 should please stay away from MUI 3.9 because we clearly consider the bare minimum to be a 68040/060 equipped A4000 with a proper CGX/P96 driven graphics card running in 16bit+ screen color modes. Even better (and actually our main target platform) for MUI 3.9 are UAE driven installation like WinUAE/AmiKit, etc. You simply have to face the fact that your Amiga won't live forever and that you should better switch to a more modern Amiga system instead of trying to force all new software still supporting old/obsolete hardware.

So again: We will do whatever we can to elimate crashes/bugs when runnig MUI3.9 on low color or underpowered Amiga classic systems. But we won't graphically tune MUI 3.9 to actually draw everything correctly. So please finally stop trying to convince us what would be the best since we already have gone through this discussion internally before and have made a decision: MUI 3.9 is clearly targeted for modern Amiga systems and not for your old miggy.

comment:6 Changed 5 years ago by Mikhail Malyshev

The problems raised here are still relevant to new systems too. There is nothing special or demanding in the current GUI design and if there is a restriction that can be avoided it should be, not enforced. The point is that the main skeleton should have no problems working, the advanced things are optional and if an application does not require them there nothing to stop it working properly.

PS: You will make a bad politician, unless you can give promises, accept proposals, find compromises, enlighten people and give hope for a better life to the tiny amiga community. It does not enforce any obligations on your side, you can say you have tried, but… but… but… (you know, how it's in real life).
Or maybe a ruthless leader, who will make us powerful again :)
(You - in this context is nothing personal, it's just a general description of what comes to mind and the overall situation)

Anyway, thanks for the support and keeping the dream alive.

comment:7 Changed 5 years ago by Thore Böckelmann

In 3663:

  • mastergfx.c: disable any truecolor support in case CyberGraphics is not available. This refs #62.

comment:8 Changed 5 years ago by Thore Böckelmann

I removed lots of unneeded dependencies from CyberGraphics and for me everything is working perfectly now if cybergraphics.library is explicitly made unavailable. Calls to cybergraphics.library should not happen anymore in that case. Please check yourself with the current nightly build.

comment:9 Changed 5 years ago by Thore Böckelmann

Milestone: MUI 3.9-2014R2
Status: newpending

comment:10 Changed 5 years ago by Mikhail Malyshev

Great work here, works on a plain AGA machine, have not noticed anything bad.
There is one problem that we have talked of before.
Since we don't have any palette tools for 8bit or less, it would be nice to at least introduce simple RGB sliders for this case. Otherwise it's impossible to pick a different colour then default 8.
This also reminds me we had an option to pick a colour ± 127 as an offset from the screen palette. This is gone for good in all modes or there is a chance to have that back?

comment:11 in reply to:  10 Changed 5 years ago by Thore Böckelmann

Replying to Michael:

This also reminds me we had an option to pick a colour ± 127 as an offset from the screen palette. This is gone for good in all modes or there is a chance to have that back?

No chance. Picking a random pen number does not guarantee any specific color, because this requires another application to set the intended color for that pen. AmigaOS offers pen sharing. If a specific color is required the system will return the pen number of an already allocated color.

Just using a pen number without knowing which color it refers to is the best way to miscolorize your GUI.

comment:12 Changed 5 years ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Resolution: fixed
Status: newclosed

In 3723:

  • mastergfx.c: optimized the dithering process by using a common web palette which offers a *MUCH* faster rendering. This closes #49 and closes #62.

comment:13 Changed 5 years ago by Thore Böckelmann

Milestone: MUI 3.9-2014R23.9-2014R2

Milestone renamed

Note: See TracTickets for help on using tickets.