Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Announcements and Press Releases => Topic started by: Elwood on February 14, 2005, 04:10:07 PM
-
Brave AmigaOS coders stand up!
So you think AmigaOS is great? Then bring some great products to it!
This is your chance to contribute to AmigaOS and put your name into the hall of fame. You'll get popularity, recognition from the community and last but by no means least, you'll get the hardware to run your beloved new AmigaOS on.
This contest was made to help the platform by bringing cool products to it. Its here to help you to work for something and create the best program of all. This is why there are strict rules and there is a validation process in order to enter.
Only the best apps will be accepted because the Amiga community deserves the best software.
You are encouraged to form a group if you feel the need to. So you can "hire" coders and betatesters to shape up a great project.
Also consider that when your program is done, you may make it commercial or why not licence it to some Amiga company. Who knows?
What are you waiting for? Go code!
Click here (http://www.intuitionbase.com/DevContest/) to read more and to enter.
-
Edited by Admin: Trolling
-
You have a point about MUI beeing discriminated
I have an idea for a project, but I dont like to choose Reaction becorse MUI is just that easyer to code for.. so as I see it its only making it harder to complete :-/
-
I consider myself AmigaOS coder (AmigaOS being 1.x, 2.x, 3.x here), aswell as MorphOS coder.
I don't want to sound pissy, but this discrimination of AmigaOS 4.0 doesn't sound sane to me.
-
@Rogue
Don't worry, you don't.
I'm sure some my programs work under AmigaOS4, too. I can't test though.
@Everyone
The rules of the contest limit the target system to AmigaOS4 only, using many AmigaOS4 only components. With requirement of Reaction and other OS4 components, it's close to impossible to develop the program on anything else but OS4. Since OS4 is only available for AmigaONE, the contest is pretty much limited to existing AmigaONE users.
Wouldn't it make much more sense to give more flexibility, and thus make it possible to develop the program on AmigaOS 3.x, AROS, MorphOS, WinUAE, Amithlon etc? Obviously the final competing entry would still need to be OS4 native binary, but with portable code that wouldn't be too hard.
I am sure the contest would be much more of a success with wider audience. Limiting to Amiga coders with AmigaONE just limits too much, IMO.
Finally, I believe giving the AmigaONE system to someone who doesn't already own one would be much more sensible in promoting the AmigaONE platform.
Just my .02 euros.
-
My main problem with MUI is that folks write code that depends on various MUI classes that you then have to hunt down and install and sometimes the ownership of those things move, the websites change, the class ceases development, etc. etc. The lack of centralized ownership makes maintenance and installing a pain in the arse.
If MUI 3rd party MUI classes were simply licensed by developers that need them so that they could be iuncluded in the distro then that would help the end user and hopefully get rid of the 68k ppc compatibility problems that come up but setting up my MUI apps was a hassle.
With Reaction at least you know that all the UI componants are already installed.
As to the matter of portability, if your functionality is too closely tied to your UI engine then you are always going to have problems. If you separate out your function from the presentation sufficiently then porting from MUI to Reaction to Carbon to Windows to whatever should be much easier. It'll probably help keep your code more understandable too.
-
The rules of the contest limit the target system to AmigaOS4 only, using many AmigaOS4 only components.
Yeah, so what's your point? It's their contest, it's their rules - you might as well complain that you can't submit a WIN32 app into the contest as well. :roll:
And as far as I can see, this is a nice idea, but more might be needed then simply giving away a free AmigaOne. I mean, any developer who makes an OS4 app probably already has one. I think it would be a good idea to give away money, as money can be a great incentive for people to invest their own time into a market that is otherwise not likely to give them a return.
- Mike
-
@Piru
Since OS4 is only available for AmigaONE, the contest is pretty much limited to existing AmigaONE users [..] Finally, I believe giving the AmigaONE system to someone who doesn't already own one would be much more sensible in promoting the AmigaONE platform.
Wrong. It's open to Classic Amiga developer with OS3.9 and NDK and cross-compiler. OS4.0 is developed with the maximum source compatibility possible with OS3.9 in mind. :-D
IMHO this contest is aimed to encourage classic developer to (re)start using their 1200/4000 and producing nice code. And, the judges all have (AFAIK) an AmigaOne or Blizzard/Cyberstorm, so they can aid developer in the OS4-porting task.
With requirement of Reaction and other OS4 components, it's close to impossible to develop the program on anything else but OS4
That's the whole purpose of the contest: pushing up the platform again on the road. About Reaction, you should be glad it's the only tool allowed..I still remember the troubles MorphOS had with its proprietary GUI toolkit not fully owned by the core team... :-)
Having stated all this, I think all your fears are plainly unfounded. :-)
-
My main problem with MUI is that folks write code that depends on various MUI classes that you then have to hunt down and install and sometimes the ownership of those things move, the websites change, the class ceases development, etc. etc. The lack of centralized ownership makes maintenance and installing a pain in the arse.
This is another reason because MUI wasn't chosen as default GUI toolkit for OS4, dear piru. :-)
-
I don't understand why you complain when anyone attempts to write an "non compatible AmigaOS4" application without MUI (and therefore tending to exclude the old AmigaOS) while none complains when the MOS developer do the same exact thing.
So maybe in the future, before saying *there is no application for OS4 that justify an AmigaOne*, remember that the only solution to advance the platform is to cut definitely with the past.
-
Wrong. It's open to Classic Amiga developer with OS3.9 and NDK and cross-compiler.
From the website:-
If your program is based on an OS3 program or an Open Source one, you can't just recompile the software for OS4.
How should I code?
Use OS4-specific features (hooks, reaction classes, vitualised memory...etc). It means you must use Reaction.
Use OS4 newlib runtime library
How exactly are you supposed to develop, test, and debug an application which only runs on OS4.0 on a OS3.9 system? Simple answer: You can't.
Yes, you can compile an OS4 binary with the cross-compiler but that's not much use if you can't run it.
I've used cross-compilers every day for five years in my job but I've always had the target platform (PS1, PS2, GC, XBox etc) sitting next to me or under my desk as well.
It's simply not possible to work without easy access to the platform you're developing for.
-
@lando
You develop on 3.9, then port and RELEASE on os4.0. In this way you can take part in the contest.
Then again, you forgot two simple things I stated before:
1) os3.9 and os4.0 APIs are quite similar. Os4.0 has some enhancements yes, but these doesn't broke retrocompatibility. It's somewhat like to port from linux 2.0 on i386 to linux 2.4 on i686.
2) many member of the grand jury of the contest have one (or more) A1 available and they're more than willing to help the contestants bugfixing their software before the deadline. So, the contestants do have that machine under the desk.
So, let me rephrase your statement: it is possible to work without easy access to the platform you're developing for. It's an Amiga, not your average PC. :-D
-
MUI always just slowed things down on my Amiga and every program I ever got that required MUI had an interface that had little to no interface design and I had to screw with the settings just to get it to work OR, I was required by the program itself to CHOOSE how I wanted things to look before I could use it. Lame.
-
Suit yourselves - if people decide against MUI and broader Amiga platform support out of old prejudices, they're only limiting their options. It's counter productive, but hey, it's their choice.
-
You develop on 3.9, then port and RELEASE on os4.0. In this way you can take part in the contest.
Then again, you forgot two simple things I stated before:
1) os3.9 and os4.0 APIs are quite similar. Os4.0 has some enhancements yes, but these doesn't broke retrocompatibility. It's somewhat like to port from linux 2.0 on i386 to linux 2.4 on i686.
2) many member of the grand jury of the contest have one (or more) A1 available and they're more than willing to help the contestants bugfixing their software before the deadline. So, the contestants do have that machine under the desk.
So, let me rephrase your statement: it is possible to work without easy access to the platform you're developing for. It's an Amiga, not your average PC.
Sorry, but it's not quite that simple. Believe me, I tried, it didn't work, so I bought an A1. Now, I haven't been working as hard on my project as I could have been but the porting of my old 3.9 code to 4.0 code is still in progress after 3 weeks, I've only skimmed the surface of the specific OS4 features.
Compiling a binary for OS4 is one thing, as Lando states, but then what... you give it to someone to test, it crashes, they tell you what and where, send you the Reaper Log, you send a new executable back which is possibly fixed, doesn't work... the circle continues. It is possible, but it's a pain in the backside!
Just because the APIs are 'similar' doesn't mean its just a matter of typing MAKE on OS4 with your 3.9 source code, it simply won't work. You could stuff a lot of #ifdef __amigaos_4__ in there I suppose.
Besides, if it's got to use ReAction how do you test that with a 3.9 app (ClassAct is not a solution here)? And use the OS4 specific features you're meant to be using as stated in the rules, application.library, AmiDock etc etc. Anyway, I'm a big fan of MUI and as it's in a native OS4 form now, I don't see why it should be banned.
I'm ranting... I'm off :-P
-
@batman
I find this competition idea very good, but
1) os3.9 and os4.0 APIs are quite similar. Os4.0 has some enhancements yes, but these doesn't broke retrocompatibility. It's somewhat like to port from linux 2.0 on i386 to linux 2.4 on i686.
You are missing the point. OS 4.0 PPC API implements OS 3.0 API (except some OldOpenLibrary(), TaggedOpenLibrary() etc.) but there are also new API calls which are not available in 3.9. That is what makes this competition problematic (IMO + standard disclaimers here).
Cross compiling itself is not problem. Even StormC (the one that supports PPC ELFs) can generate OS4 compatible binaries if you know what you are doing.
-
Sounds pretty cool to me! Now to learn how to code ....
:roll:
-
Anyway, I'm a big fan of MUI and as it's in a native OS4 form now, I don't see why it should be banned.
two reasons for the ban:
1) stuntz almost screwed MOS with his greediness. Reaction (by the way, it is the sequel of ClassAct) doesn't have this problem because its creator gave all the copyrights to the AmigaOS IP owner long ago (and he still maintain it).
2) as fluffy mcdeath said before, the main problem with MUI "is that folks write code that depends on various MUI classes that you then have to hunt down and install and sometimes the ownership of those things move, the websites change, the class ceases development, etc. etc. The lack of centralized ownership makes maintenance and installing a pain in the arse."
-
You are missing the point. OS 4.0 PPC API implements OS 3.0 API (except some OldOpenLibrary(), TaggedOpenLibrary() etc.) but there are also new API calls which are not available in 3.9. That is what makes this competition problematic (IMO + standard disclaimers here).
Maybe I'm missing the point here, but I had the possibility to give a rapid look to the SDK and I found that code suited for 68k could run without any problem and using only OS3.0 API (if well coded, of course).
The only differences are the way developers have to interact with gnu compilers and the new (compulsory) method for automagically opening and closing libraries and interfaces introduced with OS4.0.
-
Yeah mui should be released under gpl just as the did with ambient..
-
Batman wrote:
1) stuntz almost screwed MOS with his greediness.
That's a very unfair statement
Stefan Stunz, like everyone else, wants paid for hard work, and he has done a lot. If he was greedy, he'd have left this tiny community a long, long time ago.
2) as fluffy mcdeath said before, the main problem with MUI "is that folks write code that depends on various MUI classes that you then have to hunt down and install and sometimes the ownership of those things move, the websites change, the class ceases development, etc. etc.
That's not even an argument - who doesn't distribute the class with their app? Maintaining MUI classes isn't what it used to be, especially with MUI 3.9 (never, ever had a problem with it). And what is it exactly that stops people releasing 3rd party ReAction classes you need to track down and install? Both ReAction and MUI and modular, and so have absolutely the same weaknesses in being modular.
One difference though - MUI is a lot easier for people to develop for. If you want more devs for OS4, you should be making it easy for them, not dragging them down into dogma that wouldn't have been out of place on a 1998 UseNet MUI vs. ClassAct flamewar and making it harder.
-
The only differences are the way developers have to interact with gnu compilers and the new (compulsory) method for automagically opening and closing libraries and interfaces introduced with OS4.0.
Not true, but if you believe you're right then I'm not going to continue arguing with you :-)
-
Maybe I'm missing the point here, but I had the possibility to give a rapid look to the SDK and I found that code suited for 68k could run without any problem and using only OS3.0 API (if well coded, of course).
Depends how it is coded. If you use mainly ANSI C functions there are less problems. But it is still possible to write code that compiles perfectly for 68k but goes wrong for PPC target (68k varargs...).
Even hooks can cause headache. In older OS4 kernel versions you had to use 68k stub to get working PPC dispatcher for MUI (this was fixed later, i dont know what was issue), how one is expected to sort them out without proper test environment? What if you made a typo and you call GetInterface() by wrong name? When testing on OS3 you cant spot these things and GetInterface() calls wont show up in SnoopDos either. There are just many issues... Everyone is free to try and do what he wants, though.
-
Bout MUI:
MUI does exist in a useable and free form for all major "Amigas", you may not allways be able to use the setting in the unregged version, but thats all there is.
This version wouldn't disappear even if Stunzi decides on a drama-tantrum, it's native and new apps can be coded for till the sun make BOOOM.
In such a case you would have 2 kinds of SW:
1) things that aren't developed anymore, those also don't need a newer version of MUI.
2) things that are still developed, those could be reworked (with relativ ease) to one of the MUI-clones (Zune or even Feelin).
ReAction on the other side is only available for OS4 and (in an allredy moothballed version) 68k. There also next to no chance that the ReAction-API would survive the introducion of real MP without changes. You can just forget about binary-compability in that case.
All in all I would say that the future of ReAction is atleast as uncertain as of MUI, and that doesn't even take into account that most active&productive coders detest it.
MUI-classes also don't have to be a problem, just write:
- all used classes must be native and distributed with the main archive (unless found on OS4-CD).
- add blacklist for problematic classes here
-
Batman wrote:
1) stuntz almost screwed MOS with his greediness.
That's a very unfair statement
I don't think that was unfair, if you view those event from a MOS user point of view... ;)
That's not even an argument - who doesn't distribute the class with their app?
Many 68k apps still relies on two well known and freely available MUI custom classes. The developers assumed their user already installed them, and it's a very very bad of coding, IMHO.
Maintaining MUI classes isn't what it used to be, especially with MUI 3.9 (never, ever had a problem with it).
I don't have MUI 3.9, so I cannot express my opinion. Can you explain the improvement in maintaining MUI classes apart from the necessary mental re-education (in siberian camps hopefully) of developers not used to check for custom classes during install/load phase?
And what is it exactly that stops people releasing 3rd party ReAction classes you need to track down and install? Both ReAction and MUI and modular, and so have absolutely the same weaknesses in being modular.
One difference though - MUI is a lot easier for people to develop for. If you want more devs for OS4, you should be making it easy for them, not dragging them down into dogma that wouldn't have been out of place on a 1998 UseNet MUI vs. ClassAct flamewar and making it harder.
Maybe you're right. But some time ago I discussed about one of ReAction developer about improvement in the upcoming release, and I realized that what REALLY differentiates ReAction from MUI is not the easeness of use, but the documentation and support provided for it: MUI has better one.
-
The entire MUI vs. Reaction discussion is quite pointless: the end result is the same. To my knowledge Reaction is not available for older platforms, so if you want to develop your application, you'll need an AOne to begin with. That makes the prize a little weird to say the least. In fact, the jury writes: " ... First, if your app runs in 68k with no Enforcer hits, there is great chance that it runs on OS4, it's a start. Then, you can make a public call to ask help from OS4 owners to betatest for you, or even to code with you. We are a community. Work together. ..." Yeah. Right. Excuse me while I laugh. This coding by proxy is a nightmare. No machine, no development. Period. Especially when you consider the second problem I have with this contest:
It stresses uniqueness and usefulness to an uncomfortable degree. The jury does not want 'another simple utility', or 'seen-many-times software'. Pray tell, what can one think of which hasn't been done on other platforms numerous times already? I understand that the jury wants high quality programs, which is perfectly understandable. But unique programs take a long time to develop, if only because of their feature lists. I also fear the jury has fallen into the trap of thinking that an Amiga is somehow special, that somehow pixies will magic away the fact that it is running stock standard hardware.
Of course anyone has the right to lay down sets of rules for contests. But I agree with other people in this thread that the limitations will harm the contest more than result in Good Stuff. At this point I would be thrilled with any new application for OS4, rather than expecting people to create killer apps straight away.
My two eurocents.
-
Even hooks can cause headache. In older OS4 kernel versions you had to use 68k stub to get working PPC dispatcher for MUI (this was fixed later, i dont know what was issue)
The issue where hooks that where called directly, not via Utility/CallHookPkt. If this stayed within the 68k emulator, it wasn't a problem, but if the custom class was PPC native and the call was made by a 68k program then this wouldn't work. It has been fixed in the meantime.
About MUI, I didn't make the rules (in fact Hyperion has nothing to do with the contest), but plainly there are three major complaints I have with MUI (which can all be circumvented but mostly aren't):
- Rendering done on App context means that if the app is busy it will not "visually" react to input, unless the app is multithreaded (OTOH it will not crash input.device on a buggy class).
- Due to MUI's configurability, some apps look crap unless you use the same configuration as the author. Discipline is required on the authors behalf to at least test the app with the default MUI config.
- Due to the myriad of different custom classes and the fact that lots of functionality is duplicated, it is sometimes difficult to keep up-to-date with an application's requirements for custom class versions. MUI could use some sort of automatic update server that keeps all classes available (say, via Aminet) and automatically installs missing classes.
But if I start a program and the first thing I need is to install half a dozend custom classes, I quickly loose interest.
-
- Due to the myriad of different custom classes and the fact that lots of functionality is duplicated, it is sometimes difficult to keep up-to-date with an application's requirements for custom class versions.
That is quite much due to lack of new MUI releases during past years. Since list.mui was not advancing nlist.mcc was made. Then came betterstring (and newstring + textinput), betterbalance, nlisttree (listtree.mcc author disappeared) and dozen crappy toolbar classes. But MUI 3.9 added many new features and more is coming.
There are also many MUI custom classes because MUI is simply popular.
-
mui...popular... ok if u say so.
i used and still use MUI because i must.
i know mui is easier to develop for and much more powerfull in certain sections but reaction can get there in time.
Anyway i must admit that mui has gone from dog slow to superfast in the 68k -> ppc step and for that im not complaining at all.
So much better to use a standarized gui system than the likes of mui as if you guys actually tried to do a professional skin for all your apps or whatever that use mui...well then you guys would see that one cant get every app to look the same and thats bad.
-
That is quite much due to lack of new MUI releases during past years. Since list.mui was not advancing nlist.mcc was made. Then came betterstring (and newstring + textinput), betterbalance, nlisttree (listtree.mcc author disappeared) and dozen crappy toolbar classes. But MUI 3.9 added many new features and more is coming.
That doesn't help the problem, though. Yes, there is always a problem when there is no central steering committee, and yes, MUI 3.9 added more features, it still doesn't cure the big issue though that you always have to download a heap of custom classes to actually get something to run, and hope that interdependencies don't kill you.
There are also many MUI custom classes because MUI is simply popular.
This also doesn't invalidate my original point.
And there is still the other issues. Granted, well-done applications like e.g. IBrowse do not suffer from the "identical config as the author" problem, but many of them do.
And I am not saying Reaction is superior or more powerful or anything like that.
-
That's not even an argument - who doesn't distribute the class with their app?
Quite a few actually. If a programmer is going to use another's library, why not just ask to distribute it with their program. It's just annoying to look at a ReadMe and see that it uses this lib by this guy, that guy, and the other guy. Yeah, the programmer include the custom libs he made, but you have to download whole pages for just one lib is annoying. It's especially frustrating when you can't find it. This is one reason I don't like MUI and don't use it unless I really have to. When I have to use MUI, because I can't find a similar program that doesn't use it, if all the libs are not there. Well, it gets deleted, didn't need to us that program that badly.
I also find that it is a resource hog. Not to mention, how many GUI toolkits do I need to have installed? My system at one point had the native OS toolkit, MUI, ClassAct, and I think another one (something I needed for some odd little program at one point). I feel we only need One GUI Toolkit.
It's not Linux with KDE, Gnome, etc., etc., etc., ...
Reaction is the offical GUI toolkit. Take it or leave it. From what I understand MUI on OS 4.0 is just there for backward compatability.
Not to mention is MUI 4.0 going to make it to Amiga OS 4.0?
-
:lol: in the spirit of this thread I would like to point out that this OS4 app comp discriminates against windows!! now if I could submit say (insert misc. M$ type app here) running on windows wouldnt that promote OS4 nicely for you? :lol: