19-Apr-2024 11:26 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 150 items in your selection (but only 50 shown due to limitation) [1 - 50] [51 - 100] [101 - 150]
[News] MorphOS feature list outANN.lu
Posted on 11-Dec-2002 16:08 GMT by Alkis Tsapanidis150 comments
View flat
View list
Take a look at MorphOS-News, or here.
MorphOS feature list out : Comment 101 of 150ANN.lu
Posted by itix on 11-Dec-2002 22:42 GMT
In reply to Comment 98 (bhickman):
Small test proggies are not really good for performance tests.
MorphOS feature list out : Comment 102 of 150ANN.lu
Posted by catohagen on 11-Dec-2002 22:50 GMT
What version of Frogger is included and what about stability ?
Good to see Sebastian getting some cash for his work...
With already about 200 systems sold, that makes up a half-decent months salary
MorphOS feature list out : Comment 103 of 150ANN.lu
Posted by bhickman on 11-Dec-2002 22:53 GMT
In reply to Comment 101 (itix):
@itix
> Small test proggies are not really good for performance tests.
Still, it's good to have this information regardless of being meaningful or not. I've found the only really good performance test is that with your own eyes. Numbers are just numbers. The benchmarks help put the eye test in place when you are not able to get close to see them with your own eye.
- Bill
MorphOS feature list out : Comment 104 of 150ANN.lu
Posted by Nicolas Sallin on 11-Dec-2002 22:54 GMT
In reply to Comment 97 (Kulwant Bhogal):
APDF3 a hoax ?
No, it's even APDF v3.1 :-)
It's just not available for public, yet.
MorphOS feature list out : Comment 105 of 150ANN.lu
Posted by Mike Veroukis on 11-Dec-2002 23:00 GMT
In reply to Comment 93 (David Scheibler):
>MUI is faster than for example Reaction. Holger Kruse made some tests years
>back with his different Miami GUI modules. Also MUI is more or less the
>standard UI.
Ah, but it works very differently. let's say you have a standard Amiga app htat's busy doing something (say rendidering)mand you move it's window and it needs to redraw it's interface. Intiution redraws it for you.
MUI on the otherhand isn't like that at all. The interface won't be redrawn until the app is free to redraw it itself. I've seen this even in "good" MUI apps like YAM. This makes it seem VERY unresponsive and unprofessional. If that's the best the Amiga can do that's pretty sad.
- Mike
MorphOS feature list out : Comment 106 of 150ANN.lu
Posted by itix on 11-Dec-2002 23:07 GMT
In reply to Comment 105 (Mike Veroukis):
On the fast machine it shouldn't really matter.
MorphOS feature list out : Comment 107 of 150ANN.lu
Posted by Mike Veroukis on 11-Dec-2002 23:14 GMT
In reply to Comment 95 (bhickman):
>The only benchmarks I've seen from Petunia are those listed on the Petunia
>website.
In all fairness, I think it's silly to start benchmarking unfinished products. It's nice that Petunia is listing benchmark tests, but those are not final. Any real comparisons can only be done with the final release product, anything else will simply be misleading.
Of course same goes for the feature list in general. You can't really compare what's on paper, gotta put the two (MorphOS & AmigaOS4) side by side and compare them properly.
- Mike
MorphOS feature list out : Comment 108 of 150ANN.lu
Posted by Mike Veroukis on 11-Dec-2002 23:21 GMT
In reply to Comment 106 (itix):
>On the fast machine it shouldn't really matter.
I guess that's where we disagree. Some times the speed of the system has nothing to do with it, you could be downloading a large file (or a large e-mail in YAM's case).
I am of the belief that an App should never have to worry about redrawing itself. The app should tell the OS how it wants it's GUI to look like and the OS should take care of it from there. Intuition is built with this philosophy and MUI steps away from this. I believe the Amiga needs something new and ground breaking, and yes I know that's not easy but it needs to be done. MUI looks like a toy and that's because it is. We need something new and professional.
- Mike
MorphOS feature list out : Comment 109 of 150ANN.lu
Posted by brotheris on 11-Dec-2002 23:29 GMT
In reply to Comment 108 (Mike Veroukis):
Activate smart refresh in YAMs MUI prefs and see the difference. You will not believe it.
MorphOS feature list out : Comment 110 of 150ANN.lu
Posted by Kjetil on 11-Dec-2002 23:34 GMT
In reply to Comment 108 (Mike Veroukis):
I agree with you, how ever have not looked at MUI for PPC, so don’t know it performance out runs the problem that I have when looking at it.
MorphOS feature list out : Comment 111 of 150ANN.lu
Posted by itix on 11-Dec-2002 23:35 GMT
In reply to Comment 108 (Mike Veroukis):
> I am of the belief that an App should never have to worry about redrawing
> itself. The app should tell the OS how it wants it's GUI to look like and
> the OS should take care of it from there.
> Intuition is built with this philosophy and MUI steps away from this.
When Stefan Stuntz started developing MUI there was no way make this in Intuition. Other toolkits have similar refresh delays when using custom gfx.
MorphOS feature list out : Comment 112 of 150ANN.lu
Posted by Mike Veroukis on 11-Dec-2002 23:43 GMT
In reply to Comment 111 (itix):
>When Stefan Stuntz started developing MUI there was no way make this in
>Intuition. Other toolkits have similar refresh delays when using custom gfx.
Well, I understand that MUI is an amazing undertaking for any developer. I just think that the GUI should be part of the OS itself. What I mean by that is, it should be part of Intuition.library. In fact, I would like to see an Intuition.device for async GUI calls, but that's a different matter.
- Mike
MorphOS feature list out : Comment 113 of 150ANN.lu
Posted by Cheney on 12-Dec-2002 05:48 GMT
...now that Pegasos sales are iminent, if not ongoing,
could someone please add the country, names, addresses, and
phone numbers for all the Pegasos warrany contractors to this
feature list, and links at the relevant websites?
...of course dealers and distributors don't count unless
they really have the shop and repairmen on their
payroll, and in the same vicinity...thanx
MorphOS feature list out : Comment 114 of 150ANN.lu
Posted by priest on 12-Dec-2002 07:16 GMT
A featurelist!!!! NOW we're talking!!!
Well done Genesi boys.
(now... going back reading it...)
MorphOS feature list out : Comment 115 of 150ANN.lu
Posted by DaveW on 12-Dec-2002 07:27 GMT
In reply to Comment 91 (Fabio Alemagna):
Fabio, I notice you go for the personal insults rather too precipitously these
days. Why should I give you a direct answer when you were so clearly being deliberately
offensive.
Secondly you did not ask me for clarification in your lovely win friends and influence
people post, you just flamed me.
Now if you tell me you have read the rest of my posts on the subject in this thread
then I will tell you.
MorphOS feature list out : Comment 116 of 150ANN.lu
Posted by Fabio Alemagna on 12-Dec-2002 08:11 GMT
In reply to Comment 115 (DaveW):
> Fabio, I notice you go for the personal insults rather too precipitously
> these days.
Mike, personal insults? ME? Where?
" Oh, Dave, come on... that's all that you can say? Where are your _facts_? You're just spewing on something for the sake of it... no, wait, because it's MOS. Tell us, sir, why would MUI suck so greatly?
Facts, please."
What's personal and what's insulting in those words?
I rather noticed that it's been a few days that you are throwing shit at whatever is related to MOS or Pegaos, regardless of what it is, and regardless of whether it makes sense at all to throw shit at it.
> Why should I give you a direct answer when you were so clearly being
> deliberately offensive.
You should have given those details since the beginning. Why do you get so upset if someone questions your trolling behaviour, if you actually _have_ a trolling behaviour? I might have been provocative with my first question - and I aplologize for that - no doubt, but it was getting really annoying by your side, you know...
This time I wanted to hear details on why would MUI sucks, that's all. I could demonstrate to you it doesn't, if you cared to explain to me why you think it does.
> Secondly you did not ask me for clarification in your lovely win friends and
> influence people post, you just flamed me.
Hu? "win friends and influence people"? Is that supposed to be sarcastic or you really believe that? I don't think I have the power to influence anyone, in case it was not sarcastic.
Yes, I may have flamed you - and again I apologize for that - but your comment I was answering to was not one of the most polite ones, nor one you could argument about: you didn't provide _any_ arguments.
> Now if you tell me you have read the rest of my posts on the subject in this
> thread then I will tell you.
Yes, I have.
MorphOS feature list out : Comment 117 of 150ANN.lu
Posted by DaveW on 12-Dec-2002 08:32 GMT
In reply to Comment 116 (Fabio Alemagna):
Seems we might have misunderstood each other but the flame I was referring to was
calling me a troll.
Actually that post you referred to was a deliberate spoof of the one above but
does represent my past dealings with MUI use and development.
Perhaps it is my lack of skill with MUI showing itself but I never managed to
make an interface look less than clunky with it. In fact the only interface I have
see that IS less than clunky using it is Voyager - but then most of what Voyager
does with MUI could be done using other toolkits.
I never found a use for tying one gadgets events to anothers. The prefs program
was irritating and it was so slow on the 68k Amiga ( even my 060/50 ) with large
and complex user interfaces it was desperately irritating.
The advantage of skinning parts was also a disadvantage, you could get your UI
looking perfect and the way you intended it and some jerk comes along and puts it
on their system with weirdo settings and it looks butt ugly, and they moan at you!
I dont mind ( unlike others ) managing my own refresh events. Have had to do that
pretty much since my early GUI development days.
But part of it was that MUI itself was so exciting that it was easy to go overboard
and build complex user interfaces in the first place.
It taught me to simplify.
But I digress from the point, unless you are a careful designer and a restrained
developer you can end up with butt ugly user interfaces that are dog slow.
As I also said given that this isnt exactly 3.7 we are talking about here, its
a new PPC version it might be a pleasure to use and develop/test with.
Oh and as a user, people that did not package their custom classes with their
applications forcing you to go onto aminet to try and find them need their
backsides kicking.
MorphOS feature list out : Comment 118 of 150ANN.lu
Posted by Eva on 12-Dec-2002 09:04 GMT
In reply to Comment 17 (lakeside):
-----------------------
Now WHY THE HELL can't we get a list like this for OS4.0??? HELLO BEN/AMIGA INC???!!!?? Even if you don't like MOS you can't help but be impressed. I know I am! Details, details, details. That's all we want!!!
• Core OS
• OS Components
• 3D Graphics Support
• Applications / Utilities
• Miscellaneous
• specific software
• Appendix
---------------------
Because OS4 is a project , not a running OS.
The prob is that some people think that OS4 will be out FAST, STABLE, COMPATIBLE ... for January, while it will be a miracle if something decent (for decent I indicate something similar to the first Morphos beta released 2 yers ago) will be released for the end of 2003.
Anyway if someone want to look for the future waiting other months ...
MorphOS feature list out : Comment 119 of 150ANN.lu
Posted by Anonymous on 12-Dec-2002 09:24 GMT
In reply to Comment 95 (bhickman):
"> PS: The Petunia Demos are a bit bad to test beacuse IIRC they don't have built
> in timer function, so you have to stop by hand. Would be better if the author
> releases RC5/DES Benchmarks or Cinema4D or something similar (for example
> ProStationAudio benchmark tool) to compare.
Why so intent on FPU calculations, why not raw 68K speed tests"
LOL!!!
RC5 *IS* pure integer-only with no FPU required, and thus it is a raw 68k speed test.
Quit whinging!
MorphOS feature list out : Comment 120 of 150ANN.lu
Posted by It's MEEEE!!! on 12-Dec-2002 10:18 GMT
In reply to Comment 61 (Mike Veroukis):
You people have no clue about what MUI is or how it works, and yes it was slow on the old Amiga due the lack of power in 020/030/040 the combination of slow ECS/AGA and also due the fact that most people used to bloated it heavily with big patterns.
On the contrary on my 060+CGX system it always worked great, in Pegasos there's enough power in terms of CPU and GFX that MUI run faster than intuition on the original Amiga. This is without mention the fact that it has been heavily improved for speed and stability.
There's nothing to worry about MUI-PPC and a lot of benefit on it due of its flexibility.
MorphOS feature list out : Comment 121 of 150ANN.lu
Posted by It's MEEE!!! on 12-Dec-2002 10:42 GMT
In reply to Comment 105 (Mike Veroukis):
>> MUI on the other hand isn't like that at all. The interface won't be redrawn
>> until the app is free to redraw it itself. I've seen this even in "good" MUI
>> apps like YAM. This makes it seem VERY unresponsive and unprofessional. If
>> that's the best the Amiga can do that's pretty sad.
@ Mike
See, you never read the documentation, or worst never try to see what a particular setting do.
Activate "Smart Refresh" (For this app in particular / or for all in the main MUI prefs) and see what intuition does.
@ The rest of MUI haters
Did any of you realise the fact that you can have global configurations in MUI and also be able to maintain separate GUI configurations for specific apps? Like for example use different fonts, colours, patterns etc???
Which GUI system on any platform does something like this?
MorphOS feature list out : Comment 122 of 150ANN.lu
Posted by Ben Hermans/Hyperion on 12-Dec-2002 10:52 GMT
In reply to Comment 118 (Eva):
I should point that feature-list of OS 4 was frozen months ago and is available for review on the Amiga website.
Nearly all of that functionality is already completed now and fully tested.
MorphOS feature list out : Comment 123 of 150ANN.lu
Posted by Alkis Tsapanidis on 12-Dec-2002 10:54 GMT
In reply to Comment 92 (Mike Veroukis):
Don't forget the MorphOS (and OS4) does not use MUI 3.8.
MorphOS feature list out : Comment 124 of 150ANN.lu
Posted by Alkis Tsapanidis on 12-Dec-2002 10:56 GMT
In reply to Comment 97 (Kulwant Bhogal):
It's not a hoax. Either use a newer APDF or get the txt file instead.
MorphOS feature list out : Comment 125 of 150ANN.lu
Posted by takemehomegrandma on 12-Dec-2002 10:59 GMT
In reply to Comment 122 (Ben Hermans/Hyperion):
I look forward to see it running on an A1. It will be very interesting to see an A1+OS4 next to a Pegasos+MorphOS.
MorphOS feature list out : Comment 126 of 150ANN.lu
Posted by IT's MEEE!!! on 12-Dec-2002 11:01 GMT
In reply to Comment 117 (DaveW):
>> The advantage of skinning parts was also a disadvantage, you could get your UI
>> looking perfect and the way you intended it and some jerk comes along and puts
>> it on their system with weirdo settings and it looks butt ugly, and they moan
>> at you!
@ Mike
Well this is getting weird... the skinning abilities are wonderful as gives the user the ability to make his system looks the way he want.
The philosophy behind this is that: when you install an application it will look with your default MUI configuration, that is: your liked fonts, colours, button shapes and patterns.
This will make your system GUI look consistent through apps.
But if you want your application to look in a specific manner instead the one defined by the user (who knows his own taste better than you) in his system, the only thing you have to do is to include in your package the configuration stored on env: for this particular app, as well as your fonts and patterns of choice. Simple and easy.
Again I insist that you don't read the docs or played with the program.
This remembers me the old flame war between Dopus and Dopus Magellan, people argued the first was better and the second was rubbish, it was only because some people doesn't understood the concept behind Magellan II. With MUI is the same thing again and again, it gives too much functionality, some people get lost and miss the whole idea.
MorphOS feature list out : Comment 127 of 150ANN.lu
Posted by Alkemyst on 12-Dec-2002 11:05 GMT
In reply to Comment 106 (itix):
Yes it does matter
As its not always the speed of the machine that dictates when a program is finished what its doing before it updates its GUI.
Like Amirc.
When connecting to a server if you move amirc or even the connecting prompt, you will get un updated blank space of the size of the window you just moved.
& the updateing will not happen untill amirc has
connected & connecting can take some time.
MorphOS feature list out : Comment 128 of 150ANN.lu
Posted by Dietmar Eilert on 12-Dec-2002 11:07 GMT
In reply to Comment 105 (Mike Veroukis):
> The interface won't be redrawn until the app is free [...]
I've never used MUI, so please forgive me if I'm talking nonsense: wouldn't it be possible for authors to thoughtfully split their applications into separate tasks ? You could replicate the detachment of Intuition (by running your GUI in a prioritized task) or, easier, avoid blocking by moving the slow code into separate tasks.
Personally, I think a mixed approach is best: have some gui code run in the context of Intuition, offload expensive stuff to applications. That's what I did in GoldED: the user interace is all boopsi (ie. run by Intuition) but the boopsi gadgets delegate expensive operations (like scrolling a treeview) to the application (GoldED). The application then executes the indicated boopsi method in its task context.
MorphOS feature list out : Comment 129 of 150ANN.lu
Posted by Fabio Alemagna on 12-Dec-2002 11:49 GMT
In reply to Comment 128 (Dietmar Eilert):
> I've never used MUI, so please forgive me if I'm talking nonsense: wouldn't it
> be possible for authors to thoughtfully split their applications into separate
> tasks ? You could replicate the detachment of Intuition (by running your GUI in
> a prioritized task) or, easier, avoid blocking by moving the slow code into
> separate tasks.
Yes, it's perfectly possible.
On a side note, having the widgets run in the intuition.device's context is _silly_, because each widget's redrawing will block any other intuition's jobs: you can see this by using the colorwheel gadget. Nowadays, were the computing indistry is moving torwards componentized applications, it's just silly to have all of the components run inside one single task (input's): it not only slows everything down (and Reaction shows it very well), it also puts one of the most vital parts of the system - the input.device - at risk because of any possible fault of the widget it's currently handling, not to mention that having the input.device handle the application's gadgets is against any form of memory protection, which really pones many doubts on the effectiveness of the MP that AmigaOS4 implements.
MorphOS feature list out : Comment 130 of 150ANN.lu
Posted by amorel on 12-Dec-2002 11:53 GMT
In reply to Comment 118 (Eva):
"Morphos beta released 2 yers ago) will be released for the end of 2003.
Anyway if someone want to look for the future waiting other months ..."
Even then that`s very optimistic. Maybe add another year :-)
Even then, I wonder would the "30 orso" developers still wanting to be slaving away for little or no pay.
MorphOS feature list out : Comment 131 of 150ANN.lu
Posted by priest on 12-Dec-2002 12:13 GMT
In reply to Comment 122 (Ben Hermans/Hyperion):
Ben, You must understand that now when Pegasos and MOS1.0 deliveries are starting the community becomes more anxious for new AOS4 news.
Tell us something new about it, please. :)
How are things going?
Is the integrated AOS4 already running on top of PPC?
MorphOS feature list out : Comment 132 of 150ANN.lu
Posted by Dietmar Eilert on 12-Dec-2002 12:28 GMT
In reply to Comment 129 (Fabio Alemagna):
> On a side note, having the widgets run in the intuition.device's context is _silly_
> On a side note, having the widgets run in the intuition.device's context is _silly_
It may be silly but it simplifies development: You get a detached user interface (rendered by a separate global task) for free. If a gadget toolkit is provided which runs in the application context, basically a good idea, many programmers will be too lazy to separate application and toolkit by running them in individual tasks. Consequently, I think there should be a standard mechanism provided by such toolkit to run the rendering code in a separate task, which hides all complexities. I don't know if that is the case with MUI.
MorphOS feature list out : Comment 133 of 150ANN.lu
Posted by takemehomegrandma on 12-Dec-2002 12:51 GMT
In reply to Comment 131 (priest):
I second to that!
And if it IS running at this point it would be nice to see some videoclips from it. Screenshots are nice, but you don't get much of a feeling of the performance and response and so on. And since you have not showed it in public yet (on a show or similar), a movie clip would be a good way (the only way?) to show that off!
It would also be interesting if you could say something about release dates too. I know that this can be difficult, but at least a "fresher" estimation? People are actually buying the A1's now, so I guess that a lot of people would be interested to know when they can start using the mobos as Amigas!
MorphOS feature list out : Comment 134 of 150ANN.lu
Posted by DaveW on 12-Dec-2002 12:59 GMT
In reply to Comment 132 (Dietmar Eilert):
Yep, well said.
MorphOS feature list out : Comment 135 of 150ANN.lu
Posted by Rudi Chiarito on 12-Dec-2002 14:55 GMT
In reply to Comment 132 (Dietmar Eilert):
> Consequently, I think there should be a standard mechanism provided
> by such toolkit to run the rendering code in a separate task, which
> hides all complexities. I don't know if that is the case with MUI.
Been there, done that. You still can't hide all the complexities and corner cases. Separate tasks are desirable, but you still need to rely on the programmer's involvement and skills.
A trivial example is a listview. Both tasks will need to access the list of entries. How do you ensure correct operation even with concurrent accesses to the list? Think of when the main task needs to modify the entries and the rendering task needs to refresh the gadget because the user is dragging the window around. You can protect the list with a lock, but then you would be freezing the rendering task until the main task is done with its modifications. It could take seconds or even minutes - e.g. if data are being fetched from a slow network connection - for the main task to release its lock. You might need something like lock-free mutual exclusion.
I'm afraid there's no ultimate solution to take care of the lazy or sloppy programmer - unless you are willing to add a lot of redundancy into your toolkit.
MorphOS feature list out : Comment 136 of 150ANN.lu
Posted by Anonymous on 12-Dec-2002 15:42 GMT
In reply to Comment 122 (Ben Hermans/Hyperion):
Frozen? Your OS programmers send two or three messages a week which could be summarised as
"Um, we might do that for OS4.0, or we might not. Plenty of time yet to make that decision"
They explicitly said no OpenGL 1.3 for OS 4.0, you say it will happen. Since I know you couldn't program your way out of a paper bag Ben, how that's going to work - the programmer say it's not there and it's not going to be there until after OS 4.0, you say it's "Included"
Maybe you need to stop telling people that it's "frozen" and tell Friedens and other members of the OS4 team to actually freeze it.
MorphOS feature list out : Comment 137 of 150ANN.lu
Posted by Diermar Eilert on 12-Dec-2002 16:16 GMT
In reply to Comment 135 (Rudi Chiarito):
>Been there, done that. You still can't hide all the complexities and
But that is exactly what Intuition does. It hides all complexities in such functions as SetGadgetAttrs() to the extent that you only notice that there is another task when you wait for and receive Intuition messages.
If you are a toolkit designer and want to mirror the detachment of Intuition (but not with one global task), what you want to do is (a) provide a toolkit initialization function that launches a local toolkit task and (b) write SetGadgetAttr/GetGadgetAttrs-style functions which internally exchange messages with the toolkit task but hide these complexities from the programmer.
As to your listview example, this is easily solved via detaching the list from the listview. Of course you have to have such protocols.
MorphOS feature list out : Comment 138 of 150ANN.lu
Posted by Anonymous on 12-Dec-2002 16:55 GMT
Quake II executable? So that's why the MOS people so desperately wanted Hyperion's source code! To make Quake II a FEATURE of MOS. Sad!
MorphOS feature list out : Comment 139 of 150ANN.lu
Posted by Bladerunner on 12-Dec-2002 17:12 GMT
In reply to Comment 138 (Anonymous):
You know, not only Hyperion is able to do some porting stuff.. All my Respect to Hyperion for their bundle anyway, but really porting some code
can also other coders do! Beside that, did you complain, that actually all the newest scumm VM ports for Amiga OS are ported from the Morph OS version?
MorphOS feature list out : Comment 140 of 150ANN.lu
Posted by Rudi Chiarito on 12-Dec-2002 17:19 GMT
In reply to Comment 137 (Diermar Eilert):
> (b) write SetGadgetAttr/GetGadgetAttrs-style functions which internally
> exchange messages with the toolkit task but hide these complexities
> from the programmer.
They also hide the costs. What looks like a mere function call now involves a round-trip context-switch as well. You might get smarter and group messages to reduce the overhead, but this is exactly the kind of redundancy I was talking about.
A sloppy programmer might still be able to waste plenty of cycles through excessive message passing. Maybe the problem doesn't even show up when the developer tests the program on an uberfast system or with just a few items in a list, etc.; but when a final user stresses the same code on a slower CPU or on a busy system or with a much larger (realistic) workload, the issue becomes obvious in its full glory. Your archetipal sloppy programmer doesn't test for scalability.
> As to your listview example, this is easily solved via detaching the
> list from the listview. Of course you have to have such protocols.
Yes, in order to make things more transparent you will have to resort to more draconian solutions like disallowing the main task from obtaining the listview's list without detaching it first.
Which does not fully hide complexity from programmers, because you are now forbidding them from doing something that they might expect being able to do.
Which can cause spurious, confusing flashes/flickering (old list -> empty list -> new list). Unless, again, you take extra efforts.
MorphOS feature list out : Comment 141 of 150ANN.lu
Posted by Anonymous on 12-Dec-2002 17:34 GMT
In reply to Comment 139 (Bladerunner):
>You know, not only Hyperion is able to do some porting stuff.. All my Respect
>to Hyperion for their bundle anyway, but really porting some code
>can also other coders do!
Sure someone else could have if you want to be 100% technical, but I prefer embracing reality tightly.
>Beside that, did you complain, that actually all the newest scumm VM ports for
>Amiga OS are ported from the Morph OS version?
Last time I checked scumm VM was not included in OS3.1, 3.5, 3.9 or even proposed as a FEATURE of OS4.
MorphOS feature list out : Comment 142 of 150ANN.lu
Posted by Mark Olsen on 12-Dec-2002 17:43 GMT
In reply to Comment 141 (Anonymous):
FYI, the Quake2 mentioned in the featurelist doesn't have anything to do with Hyperion.
MorphOS feature list out : Comment 143 of 150ANN.lu
Posted by Alkis Tsapanidis on 12-Dec-2002 18:07 GMT
In reply to Comment 138 (Anonymous):
It's not the same port.... AT ALL...
MorphOS feature list out : Comment 144 of 150ANN.lu
Posted by Alkis Tsapanidis on 12-Dec-2002 18:07 GMT
In reply to Comment 141 (Anonymous):
The Quake2 port they had in the show was Mark Olsen's work, solely.
MorphOS feature list out : Comment 145 of 150ANN.lu
Posted by Anonymous on 12-Dec-2002 18:10 GMT
In reply to Comment 140 (Rudi Chiarito):
> They also hide the costs. What looks like a mere function call now involves a round-trip context-switch as well.
Yes. This has been the case since day one of AmigaOS, it works :-)
MorphOS feature list out : Comment 146 of 150ANN.lu
Posted by Fabio Alemagna on 12-Dec-2002 18:25 GMT
In reply to Comment 145 (Anonymous):
> Yes. This has been the case since day one of AmigaOS, it works :-)
Sure, it works slowly. Reaction shows it.
MorphOS feature list out : Comment 147 of 150ANN.lu
Posted by derf on 12-Dec-2002 19:44 GMT
In reply to Comment 136 (Anonymous):
"They explicitly said no OpenGL 1.3 for OS 4.0"
actually thats correct, well done. they are stuck to that list now, as they have been for ages, but for anything not on the list they dont know which version it will be in.
as an example, it was said in the last few days that OpenGL 1.3 compatability will most likely be in AOS4.1.
care to make any more examples of things 'on the feature list' that they say wont be in 4.0 ?
MorphOS feature list out : Comment 148 of 150ANN.lu
Posted by Anonymous on 12-Dec-2002 20:31 GMT
In reply to Comment 147 (derf):
Oh, this is just great. Now the fanatic freaks have started fighting about what one day might eventually end up in feature/TODO lists for hypothetical future OS revisions...
Waaah! Waaah! Developer X said he liked feature A and wouldn't mind seeing that included some time. So there!
Waaah! Waaah! But Developer Y said he's had a serious look at feature B, and says it could be really good to have. So there!
So what trademark will be applied to the OS that will be first with a pre-emptive ESP controlled 6 dimensional user interface in the year 3002? That is the hypothetical feature which will rule my decision about AOS 4.0 and MOS 1.0.
Amiga - So the World May Laugh
MorphOS feature list out : Comment 149 of 150ANN.lu
Posted by Dietmar Eilert on 12-Dec-2002 22:13 GMT
In reply to Comment 146 (Fabio Alemagna):
> Sure, it works slowly. Reaction shows it.
It doesn't show anything, because Reaction does not run as "local" toolkit task. It runs in the Intuition context, as global task, competing with other Intuition services, and is useless as reference point.
My suggestion for good toolkit design is to separate applications into user interface and backend. You thus have a minimum of two threads per application. This can be done today, and, in the case of MUI, remedies the problem of non-responsiveness in some situations. However, the frontend/backend design is not for the casual programmer: you have to deal with tasks, messages, signals, semaphores and deadlock issues.
That's why I suggest that the toolkit itself needs to be designed in such a way that the complexities of frontend/backend separation are hidden from the programmer. If the frontend/backend split is free, programmers will use it. Otherwise, many won't bother.
I know that this can be done, I've done it to a certain degree in the case of AFC library (the toolkit used by GoldED). This toolkit is, to put it mildly, not slower than MUI. But, frankly, speed has nothing to do with the whole issue. This is about user interface responsiveness of busy applications, not about speed. The performance of a gadget toolkit is primarily dictated by its rendering and layout code. The AFC toolkit is faster than MUI because it's gadgets are less complex and non-configurable, simple as that.
MorphOS feature list out : Comment 150 of 150ANN.lu
Posted by derf on 13-Dec-2002 09:31 GMT
In reply to Comment 148 (Anonymous):
my you took that quite hard didnt you ?
i pointed out when OpenGl was going to be included, and because he said the list wasnt final i asked to point to something that wasnt going to be in OS4.0
and then you went off on one
Anonymous, there are 150 items in your selection (but only 50 shown due to limitation) [1 - 50] [51 - 100] [101 - 150]
Back to Top