Who's Online |
35 user(s) are online ( 18 user(s) are browsing Forums)
Members: 0
Guests: 35
more...
|
|
|
|
|
Re: OWB 2.2
|
Posted on: 2008/8/1 2:24
#1301
|
Just can't stay away 
|
@jahc Quote: Nice work! Do you think there will be any further optimisations? Not that large ones any more, like in Blastoise using the AmigaOS4 font engine instead of libfreetype makes the biggest speed difference. First I'll add all AmigaOS4 features of Blastoise to Doduo, then check if supporting multiple windows or tabs is posssible now, and only after all of that is done I'll try to make it faster.
|
|
|
|
|
|
Re: OWB 2.2
|
Posted on: 2008/8/1 2:20
#1302
|
Just can't stay away
|
@xeron Quote: It was libjpeg.so i was missing. All required shared objects are in the readme.
|
|
|
|
|
|
Re: OWB 2.2
|
Posted on: 2008/8/1 2:18
#1303
|
Just can't stay away
|
@TrevorDick Quote: Well done! I have sent you a small donation towards your excellent work. Small?  It's the highest single donation I got since years, I even got donations smaller than just the PayPal fees of your donation already  Many thanks!
|
|
|
|
|
|
OWB 2.2
|
Posted on: 2008/7/30 0:33
#1304
|
Just can't stay away
|
In OWB Doduo 2.2 I've implemented the AmigaOS4 font support, which is much faster than libfreetype. It doesn't look as good, but at least on an AmigaOne the speed is usable now.
|
|
|
|
|
|
Re: PerfectPaint and XPKMaster.library
|
Posted on: 2008/7/29 16:34
#1305
|
Just can't stay away
|
@nubechecorre Quote: i have downloaded and installed PerfectPaint with the lastest update available from AmiForce. I also installed the libraries that it needs to run under amiga os 4.0 but i cannot find the xpkmaster.library.. i look into os4depot.net but i only found a glue.file.. anyone could help me to find out this library ? A PPC native xkpmaster.library was included on at least one of the OS4 CDs, AFAIK it's not available anywhere else, only m68k versions.
|
|
|
|
|
|
Re: Makefile problems...
|
Posted on: 2008/7/26 14:38
#1306
|
Just can't stay away
|
@Spirantho Quote: I get the same error with gmake though.. no rule to target.
This is using UNIXoid pathnames throughout, and this time the files do exist... But the sources are not in the same directory as the object files. Either you have to add explicit rules for all files, or try with VPATH = ../common:../amiga added to the makefile and using SRCS = string.cpp utils.cpp
|
|
|
|
|
|
Re: Makefile problems...
|
Posted on: 2008/7/26 14:27
#1307
|
Just can't stay away
|
@salass00 Quote: @joerg
Quote:
By deleting "make" and renaming "gmake" to "make" each time I update it, the version which uses AmigaOS paths is useless.
Or simply learn to type "gmake" when compiling unix programs. Doesn't work for makefiles which start make in subdirectories and don't use $(MAKE) for it. And it has nothing to do with unix programs at all, none of my AmigaOS programs can be build with the AmigaOS path make either.
|
|
|
|
|
|
Re: Makefile problems...
|
Posted on: 2008/7/26 13:15
#1308
|
Just can't stay away
|
@Spirantho Quote: However, the problem kinda remains because I'm actually using
SRCS = ../common/string.cpp ../amiga/utils.cpp
et al.
Because I'm using make with gcc it's expecting UNIX-like paths... so the files aren't found. Or something.
I could probably get the Makefile to find the file but then GCC wouldn't find them, I reckon.
How do people get round this? By deleting "make" and renaming "gmake" to "make" each time I update it, the version which uses AmigaOS paths is useless.
|
|
|
|
|
|
Re: OWB Doduo
|
Posted on: 2008/7/25 21:39
#1309
|
Just can't stay away
|
@Mlehto Quote: Ok, if any others, you or os core developers don't see it like problem, but I will. It is definetly mess and destroys AmigaOS understandable, clean and friendly environment from _point_of_view_of_user_. You are just used to it and don't notice things which are much worse than the shared object naming any more, asl.library was just one example, but there is more. For example why C: instead of Commands:, S: instead of Scripts:, DEVS: instead of Devices:, LIBS: instead of Libraries:, T: instead of Temp:, and the worst one, why are filesystems and handlers in a L: assign? hand Ler? Makes no sense at all and I'd call it anything but understandable
|
|
|
|
|
|
Re: OWB Doduo
|
Posted on: 2008/7/25 8:45
#1310
|
Just can't stay away
|
@Hans Quote: An example on how to deal with per-application global data would be helpful. SDK:Documentation/CompilerTools/gcc.pdf, 3.17.34 AmigaOS PPC options Quote: Well, if GCC used newlib by default instead of requiring you to use the -mcrt=newlib parameter then more people would use newlib. I reported this bug several times, but it was only fixed in the last public SDK 
|
|
|
|
|
|
Re: OWB Doduo
|
Posted on: 2008/7/25 2:08
#1311
|
Just can't stay away
|
@Mlehto Quote: If it is possible to give different location compare to posix ( \lib vs SYS:SObjs ) it should be possible to change naming... It wouldn't have been a problem to use different names in SOBJS: (but only there, in SDK:(Local/)newlib/lib the original names have to stay), it just doesn't make any sense to have different names, and for the already existing ones it's too late anyway or you'd have to rebuild all programs using them (or create soft links in SOBJS: which would be even worse IMHO). The names of AmigaOS libraries are often crap as well, for example asl.library 
|
|
|
|
|
|
Re: OWB Doduo
|
Posted on: 2008/7/25 1:58
#1312
|
Just can't stay away
|
@Hans Quote: People writing native software should use Amiga libraries. I'd still prefer it if people converted shared-objects to libraries where ever possible. I created an example how to convert a static link library to an AmigaOS4 shared library some years ago ( bz2.library), but since it's a little bit more work (and this easy example only works for libraries without global data, converting libraries with global data is much more work) AFAIK nobody ported additional shared libraries that way. One problem probably was that such libraries can only work with programs using newlib, but some people still are, or at least were, using clib2 several years after it was replaced by newlib. Now we have lots of newlib-only shared objects instead of newlib-only AmigaOS libraries ... If I would have had to port all the libraries OWB needs to AmigaOS4 myself, no matter if as static libfoobar.a, shared libfoobar.so or AmigaOS foobar.library, I wouldn't even have started porting OWB to AmigaOS4. If you want new native software instead of ports you just have to wait about 50 years until something comparable to OWB 1.24 can be competed by a single spare time developer instead of the 4-5 months for the port But of course not everything is as complex as a Browser, a replacement for AbiWord could be rewritten from scratch in only about 10 years.
|
|
|
|
|
|
Re: Amidvd bug ?
|
Posted on: 2008/7/23 20:36
#1313
|
Just can't stay away
|
@Ricossa Quote: I dont't thing this is simply a filesystem bug, because I was able to transfer the files from a flash card onto my hd... But you can't transfer them back, copy them for example to RAM: or just read them. As long as the 'R' bit isn't set nothing, incl. AmiDVD, can read the files.
|
|
|
|
|
|
Re: OWB Doduo
|
Posted on: 2008/7/23 20:32
#1314
|
Just can't stay away
|
@corto Quote: I already mentionned it on AW.net but it's nice to see this project is (almost ?) covered like an official port. Probably because it is an official port Roadmap, ReleaseNotesDoduo, SuccessStory.
|
|
|
|
|
|
Re: OWB Doduo
|
Posted on: 2008/7/23 20:25
#1315
|
Just can't stay away
|
@Hans Quote: So how is progress with doduo? Currently none, when OS 4.1 is released I'll have more time and continue with it. Quote: I noticed that integration of the Amiga port was listed as a goal in one of the milestones on OWB's trac site. I suppose that this will be attempted once you have doduo ported completely. The initial plan was a private beta of Doduo in June and the public release in September, that way there would have been enough time to integrate the AmigaOS 4.x and Win32 ports, but they made it public after only 2 or 3 weeks and there will be something like a Doduo 1.1 with the ports integrated released in September instead.
|
|
|
|
|
|
Re: Want to Purchase DVDRW for A1. Which would you recommend?
|
Posted on: 2008/7/19 16:20
#1316
|
Just can't stay away
|
@Mikey_C Quote: Hmmm, so far, from the looks of it, you all agree to disagree - seems like its pot luck so far!  Nobody mentioned bad experiences with Plextor drives yet, but they cost about twice as much (50-60 Euro) as Asus, LG, LiteOn, Samsung, Optiarc (Sony/NEC), etc. drives (25-35 Euro). Maybe it's worth it if you burn a lot of CDs and DVDs, but for most people only occasionally burning a CD or DVD it's not IMHO. It's best is to get the exact model someone is using successfully in an AmigaOne already, just selecting one by brand isn't, IIRC even some Plextor drives were just relabelled BenQ drives.
|
|
|
|
|
|
Re: Want to Purchase DVDRW for A1. Which would you recommend?
|
Posted on: 2008/7/18 14:32
#1317
|
Just can't stay away
|
@Mikey_C Quote: Above says it all, is there a particular model you would recommend? obviously it has to be IDE and internal.
Your recommendations welcome.
(am replacing the internal CDRW because, I found out last night that neither AMIDVD or MakeCD seem to want to work with it.) With AmiDVD there were no problems at all yet, at least none reported, with LG and Plextor drives. The most problematic ones are AOpen and Pioneer drives, although I got DVD+R working with Pioneer drives it required a special workaround making it slower. On os4welt.de is a list of drives tested with AmiDVD: http://os4welt.de/html/tt/HWListe/Brennen/AmiDVD.html (with the Sony DRU-820a burning CD-R doesn't work, with all other listed DVD burners there are no problems left with AmiDVD AFAIK).
|
|
|
|
|
|
Re: AmiDVD & Dual Layer
|
Posted on: 2008/7/17 2:21
#1318
|
Just can't stay away
|
@Snuffy Quote: I usually go with make image. 'Flying' is not IO stable. It doesn't matter with buffer underrun free recording, and the errors Swoop gets are before writing has started in a part of AmiDVD which is identical for images and on-the-fly burning.
|
|
|
|
|
|
Re: AmiDVD & Dual Layer
|
Posted on: 2008/7/17 2:13
#1319
|
Just can't stay away
|
@Swoop Quote: I get the same error using either 8x or 2.4x discs.
Is there anything else I can try? Since the error codes are no standard ones but vendors specific I have no idea what they mean, but obviously your drive doesn't recognise the 2.4x discs correctly either since the write speed AmiDVD gets from the drive is wrong, it's just the default/max. speed which is returned as well for example if there is no disc in the drive.
|
|
|
|
|
|
Re: Licence
|
Posted on: 2008/7/11 19:06
#1320
|
Just can't stay away
|
@orgin Quote:
orgin wrote:
@joerg
I read through MPL and APL. Bit too rich for me to get a full gripe of what it all means. Some stuff, like the US government stuff, seems to not fit in there. I hope someone joins in that can read though them and give us some insight and tell us if it can be used to fulfill the Open Amiga ideas.
The details are only interesting for, and comprehensible by, lawyers. The basic ideas are BSD: No restrictions. Can be used for Open Amiga, but doesn't enforce open source. MPL/APL: What was released as open source has to stay open source incl. all changes made to it, but it's limited to the individual source files and doesn't add restrictions to other software incl. other source files linked into the same executable or library. Ideal for something like Open Amiga if you want to enforce open source. Except for for coding examples/templates, to make it possible to use them as base for own software without having to release the sources they should use a BSD licence instead. LGPL: All sources of an executable or a library, even if it's just using a single LGPL function, have to be open source. Doesn't add restrictions to software just using a LGPL library (but only if it's dynamically linked, i.e. an AmigaOS .library or a shared object, everything statically linked with LGPL code has to be LGPL). Usage for Open Amiga is very limited, it could only be used for tools and libraries which are a complete replacement or something new, not for improvements of existing parts since none of the sources can be used in software with another licence. GPL: Extremely virulent crap which isn't usable for anything, especially not libraries since any software just using the library has to be GPL as well. The Linux kernel has an exception invalidating the most important GPL points, without that all software running on Linux would have to be GPL. May even affect generated data, IIRC GCC has an explicit statement that the code it generates isn't covered by the GPL. If you think it's usable for anything you either don't understand it, or you are as mad as Richard M. Stallman and should consult a psychiatrist immediately One example for the GPL nonsense on AmigaOS is YAM, it's GPL but violates it by using the non-GPL MUI libraries and classes (at least on AmigaOS 3.x where MUI isn't part of the OS, AFAIK there is an exception for OS parts). GPL software isn't allowed to use libraries with another licence. Of course there are much more licences, but for the most important parts everything else is just a variant of one of the 4 above ones.
|
|
|
|
|
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
