Why removing it completely ? Does it do any harm existing there ? (I don't think so IMHO.)
Imho it must be removed just because its old and must die at all with all those rare freaks and retro fans :)) But if say seriously, having 68k support on kernel level stop aos4 from growing up. I see no problem to just put all that 68k support code to "box", just like win32 with ms-dos support, or macos_some_version with older macos.
That will give for aos4 coders more freedom, when they will make aos4 more mature in todays standards. Imho making memory protection, resource managment and alt will not possible with having in mind 68k api support.
Making it "in box" will solve many problems, and more of it: euae have chipsets support , while petunia are just 68k support, what for new blood/users (which we need) have no sense.
Stuff that seems a bit redudant (to me anyway): Picasso96Mode PlayCD (TuneNet plays CDs anyway) MEmacs
Doesn't really work: IconEdit - doesn't seem to work with the OS4 icons?
Prefs drawer is tricky to navigate, especially if you are new to OS4, e.g. difference between input and amigainput, AHI or Sound? 3 printer prefs. Quite a few prefs programs with similar names/functions, difficult to know where to find different options sometimes.
Something that would be nice improvement: enhanced trashcan with ability to restore files to original location, handling files with same name, trashcan.docky in AmiDock.
Imho it must be removed just because its old and must die at all with all those rare freaks and retro fans :)) But if say seriously, having 68k support on kernel level stop aos4 from growing up. I see no problem to just put all that 68k support code to "box", just like win32 with ms-dos support, or macos_some_version with older macos.
At the moment 68k is the only productive apps we have, and currently EUAE is not that user friendly.
Quote:
That will give for aos4 coders more freedom, when they will make aos4 more mature in todays standards. Imho making memory protection, resource managment and alt will not possible with having in mind 68k api support.
It may improve the operating system, but it is applications that attract users.
Quote:
Making it "in box" will solve many problems, and more of it: euae have chipsets support , while petunia are just 68k support, what for new blood/users (which we need) have no sense.
Once the Amiga has a larger user base, radical OS changes can be made. What will attract new blood/users will be the applications to do what ever interests them, at the moment classic legacy apps are our only option.
I (for example) not use any 68k program on my os4. Only 1 time in half of year, running some games/demos over euae for 30 minuts , just to see that it works. All the stuff which i really use every day - os4 native (and i think i am not alone with it for now).
Many people are saying 3D is somehow bad like we were going to get many recent DirectX11 level of games ported from Windos and Xbox. All games ported to Amiga are 10-15 years old Quake3 and Freespace2 and so on. Those games were targeted to 200-500 MHz Pentiums. So I think those games should work just fine on current (or shortly coming) 600-1800 MHz hardware. And MiniGL has a lot of OpenGL features already AFAIK. So i don't think replacing 3D subsystem is that important right now IMHO.
No, we need better (Mini)OpenGL performance, because lots of programs & games ported by (for example) kas1e do not run very well (esp on Sam440). Look at LodePaint, the bottleneck is OpenGL due to it redrawing everything every frame. There are lots of 2D & 3D game ports that use OpenGL, which ran far slower than they should. And even Quake 3 doesn't run fast enough (ok for single player, no good for multiplayer).
And MOS shows that our OpenGL could be at least *2 faster on the same hardware (Pegasos). And Hans seems to think the 3D bottleneck is in one particular place (I forget), and so presumably would not need a complete rewrite.
ChrisH wrote: And MOS shows that our OpenGL could be at least *2 faster on the same hardware (Pegasos). And Hans seems to think the 3D bottleneck is in one particular place (I forget), and so presumably would not need a complete rewrite.
The major bottleneck is Warp3D. It's an old API that doesn't support things such as hardware accelerated transformation, clipping and lighting. There are other things that could provide a performance boost, but basically, Warp3D has got to go.
I'm in favour of ditching MiniGL for MESA as soon as possible. MiniGL provides us with something usable right now, but MESA will provide OpenGL 2+ support.
@Swoop Like others I DON'T use petunia much (if at all) and 68K stuff is ultra easy with runInUae (which I use for games mind you).
@Hans @ChrisH
I agree that before any SMP or 64Bits or even MP, we need new 3D drivers to replace Warp 3D and a native port of MESA. Even with no MP, no SMP and no 64Bits we would receive (all of us even Sam users) a TREMENDOUS impact, something that cannot be said for the rest because:
1)SMP and 64Bits would only apply to x1000 users
2)MP and 64Bits are often not felt by "mere" home users (as written elsewhere, well written applications are rock solid even with no MP and very few apps REALLY take advantage od 64bits/memory larger than 4GB).
@IamSONIC Quote: 4. Adding support for the digital outputs of modern sound cards.
Digital output of my ESI Juli@ sound card works just fine ! And AFAIK it's not the CPU converting sound from digital to analog. It's the hardware on your sound card that does the job.
I originally wrote Quote:
4. Adding support for the digital outputs of modern sound cards. In drivers and their related control panel. This would also boost DVD playback (especially) on the low entry OS 4 machines, cause currently the cpu has to convert the digital ac3 audio stream to stereo which costs a significant amount of performance. When using digital audio out - no need for audio processing -> just pass through !
What you mean is that your sound card converts everything (you normally hear with the analog stereo plug) to digital audio which is called PCM Audio, what i mean is (marked bold in my own quoted text) is AC3 - Audio and that you can hear anything from it, you have to install this tiny piece of software OS4 AC3 Audio Codec.
And this tiny piece of software is 100% executed by the CPU in our Amigas, without it, at least with DvPlayer you will hear no Sound when playing mpeg files muxed up with AC3 Audio ! But when just passing through the AC3 Audio Stream the CPU and the Audio Chip have to do a really easy job, cause the DECODING is done by external AC3-Decoder Hardware such as an amplifier.
I would really like to this http://os4depot.net/index.php?functio ... workbench/prefscenter.lha incorporated into the OS - something like the WBStartup-Manager for Preferences. The shortcomings of the recent version is the dependance on icon datatype (which leads to conflict with other software...) and the fact, that there's nothing to customize: Most of us have additional preferences programs in the prefs drawer - these should be addable, maybe with user definable sections.
This stuff is really obsolete and should be removed from the OS. I mean, they should be made optional at OS install time, or downloadable from somewhere (to satisfy the few users who might need them). Considering the questions asked here and at aw.net, these programs can really confuse users, both total newbies and ex-Amigans.
Quote:
Prefs drawer is tricky to navigate, especially if you are new to OS4, e.g. difference between input and amigainput, AHI or Sound? 3 printer prefs. Quite a few prefs programs with similar names/functions, difficult to know where to find different options sometimes.
Yes, the Prefs drawer makes sense to a seasoned Amiga user but a newcomer would find the prefs-program names unintuitive and confusing.
#1 @nubechecorre Seeing new softwares coming to os4 and new games, i'd like to know your opinion about future development of Amiga OS..
Veryslow! (Oops 'very' just bumped into 'slow'!)
#10 @ varmfskii ...the focus for development on AmigaOS 4.x should be on those things that make creating and porting applications simpler. ..
I always wanted to see a good native Basic and IDE for the A1. I like solving problems in higher languages.
#17 @ Swisso ...some form of anti-virus/anti-spyware and Firewall should be considered given the impending explosion of interest in our favourite OS.
You can't be serious. How big of a 'explosion'? I would say a million or more Amigans might start a ball rolling and it would not be a free service.
#25 @ Swoop At the moment 68k is the only productive apps we have, and currently EUAE is not that user friendly...What will attract new blood/users will be the applications to do what ever interests them...
Yes, exactly! Hence, my 'hang-up' for a native Basic language to workaround too.
I (for example) not use any 68k program on my os4. Only 1 time in half of year, running some games/demos over euae for 30 minuts , just to see that it works. All the stuff which i really use every day - os4 native (and i think i am not alone with it for now).
Whereas I on the other hand wouldn't have much use for an OS4 machine if it didn't run 68k apps. If I have to run them in an emulated environment, I might as well use UAE on the PC and sell my A1 for a lot of money!
Besides, taking 68k out will do squat for improving the OS. Most of the problems stem from memory protection and the likes which are legacy API issues with very little to do with 68k except they were both used on the Amiga 25 years ago. You'll still have the same API under OS4, it just runs on a different CPU. And why emulate these APIs in a sandbox when it's there natively anyway, and so will run much, much faster?
If you use aos4 for 68k, imho better use winuae already (imho of course). From other side, i personally have no problems if there will be still Petunia, but if its stop aos4 from growing up (on API level), then i am for sure up to removing 68k completely and without any cry. Basically, we not have any good solution for 68k support. We have petunia in os4, but not have chipset support. We have EUAE , but not have JIT inside. We already in situation when we not have normal support of classic stuff, so why need to bother about it, just remove it and spend time on making MP/SMP/good 3D.
But i think it's already on that level, when aos4 developers do not have any priority related to 68k support. I think Rigo can say more about :)
@kas1e I don't think he meant he used OS4 for *only* 68k apps, I think he meant he used many 68k apps *in addition to* OS4 PPC apps. Which is pretty much what I do.
And I don't image that (for example) ClipHistory would work as expect, if it had to run in UAE ! There are still a lot of useful 68k utilities that I couldn't live without.
And I don't image that (for example) ClipHistory would work as expect, if it had to run in UAE ! There are still a lot of useful 68k utilities that I couldn't live without.
Imho then better start to rewrite or found replacement for aos4 native, because imho, soon 68k support will be removed from os (maybe not right now, but will be).
- Program running on AOS4 like ambiword or Gimp,.....(for promoting AOS4 with known programs)
For the 3D (because It's ridiculous to have 3D 2 times slower than MorpHOS):
First step: Hyperion let alain thellier and matthey improve Warp3D 68k by accessing them the original sourcecode of warp3D and by adding the AOS4 change on the 68k version. This mainly for correcting hits or problems on 68K and AOS4 platform.
After new and unified Wap3D version could be made for Aos3 and aos4.
Or
Let alain just add hardware support on his wazp3D that mean add Hyperion hardware accelerated drivers (voodoo, Permedia, radeon,....) on wazp3D. After compile AOS4 version of Wazp3D for AOS4 as a replacement as warp3D.
Second step: Ask alain thellier if he would like to do MESA for AOS4. Maybe Hans and alain could work together to get rid of warp3D.
Why the warp3D phase ?? Because surely making a good and updated MESA/OpenGL for tghe amiga will take long time to do...
Please Hyperion, think about this and no let the amiga with slow 3D forever...
AOS4 betatesters, talk about this subject on your private AOS4 Mailing List together....
This is, of course, My point of view...
bye.
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
The bad think, that Rogue have no interest to give for anyone warp3d sources for fix. I do not know why he just not put it the same way as SDL or MiniGL already. He not have time work on it, but not want to give it for anyone who have time for work on it :) He also not answer me on the latest mail, in which i ask about which bounty will be better: improve minigl (with removing warpd at all) for making all the current cards works faster, or, making a bounty for gallium/mesa (for all new gfx cards). That all a bit bad, and show that he just not in interest to see that someone else will works on warp3d.
Alain already make wazp3d from _scratch_, and its already way better than any current warp3d driver on any os. Sadly that Rogue sit on sources, and wait somethink :)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
