Who's Online |
186 user(s) are online ( 125 user(s) are browsing Forums)
Members: 1
Guests: 185
flash,
more...
|
|
Headlines |
-
thumbnailmaker.lha - video/misc
Apr 26, 2024
-
mce.lha - game/utility
Apr 23, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
-
faad2.lha - audio/convert
Apr 22, 2024
-
seq.lha - audio/misc
Apr 22, 2024
-
libfaac.lha - development/library/audio
Apr 22, 2024
-
libfaad.lha - development/library/audio
Apr 22, 2024
-
image2pdf.lha - utility/text/convert
Apr 22, 2024
-
libharfbuzz.lha - development/library/graphics
Apr 20, 2024
|
|
|
|
|
Re: GCC, Dynamic structure creation method ?
|
Posted on: 2009/3/5 15:43
#182
|
Just popping in 
|
@abalaban
Many very correct C sources don't compile with a C++ compiler (most of the time for cast reasons, but not only). So, C++ is not a superset of C in this regard, else it would compile them without trouble.
|
|
|
|
|
|
Re: OWB 3.7
|
Posted on: 2009/2/26 14:54
#183
|
Just popping in
|
@afxgroup
Sorry, but downloading from megaupload, rapidshare & co just works with MorphOS and AROS OWB versions.
|
|
|
|
|
|
Re: apps wishlist for AmiCygnix
|
Posted on: 2009/2/19 2:50
#184
|
Just popping in
|
FFMpeg (also MPlayer, VLC and anything using the library) now reimplement rv10, 20, 30 & 40 (i.e all realvideo/audio flavours up to "real 10").
|
|
|
|
|
|
Re: The MUI vs Reaction slapfest thread (was OWB 3.6)
|
Posted on: 2009/2/13 15:11
#185
|
Just popping in
|
@joerg Quote:
Maybe in the MorphOS MUI 4.x, but definitely not in the AmigaOS MUI 3.9.
Even something extremely simple as the OWB 3.5+ GUI with tabs is impossible with MUI, unless you use 3rd party classes or implement your own replacement for Register.mui with support for dynamically adding/removing tabs and their page groups.
MUI4.x supports it natively. But anyway, adding dynamic tab add/remove is at most 100 lines of code with proper subclassing. Quote:
Some things MUI does were required on AmigaOS 2.x, but it was never updated to newer versions of AmigaOS, and never will be, and that's not just limited to core methods like GM_DOMAIN and attributes like WINDOW_CharSet/LAYOUT_CharSet, etc., it's the same for all other parts of MUI as well.
It's indeed bad if you can't make MUI evolve, but that's not a MUI issue, that's your issue. About these *_CharSet attributes, i'd say it's really not a well thought API. What about using a unique tag that all subclasses would inherit at will instead? Quote:
If you need to handle input from the GUI while processing something else, yes. But if not that's only the case for MUI, not with the AmigaOS BOOPSI classes which do the basic things (visual feedback for input like button presses, refresh handling in simple refresh windows, relayouting and rerendering on window resizes, etc.) in the intuition task instead.
So you're telling that if such a BOOPSI class crashes (which can easily happens when developping), then intuition is also dead, since they run in intuition context? Not great if you ask me. At least, with MUI, you're free to crash as many times as you want. :) Quote:
If there would be a better GUI toolkit for AmigaOS, for example if the AmigaOS 4.x port of Feelin would have worked, I would use it, but currently the BOOPSI classes included in AmigaOS is the best one.
If that wouldn't be the case, before I'd use MUI again, especially since it's outdated since years and will never be updated again, for example it's gadget classes don't even support a charset attribute which is mandatory since AmigaOS 4.x for GUIs, since other charsets than ISO-8859-1 are supported by AmigaOS...
Feelin may have some cool ideas (much inspired from MUI, btw), but it's *totally* unproven on real use. The only app using it is its prefs GUI, apparently. I wouldn't like to develop serious stuff with such an unproven toolkit. And once again, it's too bad you don't control MUI development. I guess that's the real reason for OS4 using "Reaction" instead of MUI (along with 3.5/3.9 legacy), actually, not all these weird statements about unresponsiveness, slowness and all... :)
|
|
|
|
|
|
Re: The MUI vs Reaction slapfest thread (was OWB 3.6)
|
Posted on: 2009/2/12 15:09
#186
|
Just popping in
|
@Rogue Quote:
Shows how much you know about BOOPSI.
BOOPSI notifications are rather raw to use. Maybe you should consider using MUI for real to know how powerful it can be when implemented properly. Quote:
t's a reality, and ignoring the reality will not help. If you look around, EVERY major MUI app will require external classes. Whether it is possible to write them without them is irrelevant. Take YAM, take IBrowse, they require these classes.
Taking YAM as an example is a cheap shot. Its author seems to have fun bumping any mcc (for nothing) and requiring the very latest version each time. That said, i find it funny you're so upset by using external classes when you yourself opened the door to the shared object hell in OS4, which is a way worse concept in every aspect (no proper version concept, no compatibility, ...). Quote:
The typical non-argument is to quote statistics. The most evolved/complex apps all use Windows.
statistics aren't an argument, but that should at least show you which toolkit developers prefer. Now you can of course assume most of them are ignorant who didn't see the holy light in Reaction or ClassAct. Quote:
Another non-argument. "XYZ is so powerful Mwahahaha". So lame.
You can choose to ignore MUI abilities. It's your problem. Quote:
Quote:
So, where are all these serious Reaction/Classact applications?
OWB and CodeBench come to mind immediately.
I can't tell about CodeBench, but OWB is certainly not a complex application GUI-wise (and i repeat, i'm only talking about the gui side, not owb itself). If you need to take an example, better take Aweb than OWB. Quote:
Snoddy sarcastic replies are not going to win an argument. They will only help to cement your appearance as a cult follower. People raise valid points and the only thing you do is try to ridicule. You close your eyes to any valid criticism.
Sarcasm seemed quite appropriate to the blind answers from R-Team. I mean, how "MUI is only good for simple apps" or "MUI is slow" is a valid point? Please enlighten us. Quote:
You will notice that I pointed out a number of flaws in Reaction as well. Denying them is useless. MUI has its own flaws, but the cult followers like yourself will always ignore these flaws and nitpick on the flaws of "the other side".
You can see external class concept as a flaw when abused (which i agree on, of course). But then you should also consider removing libraries concept from amigaos, maybe. Else someone could start abusing it and requiring external libs for his apps (shock, horror!). Quote: It's an useless discussion because you decided to cover your ears and close your eyes. I don't think i ever denied abusing external classes sucked (but how can it possibly the toolkit fault?). I just argued on the other points (mui too complex, too slow, only good for simple things). But maybe you imply argueing is useless on this forum.
|
|
|
|
|
|
Re: The MUI vs Reaction slapfest thread (was OWB 3.6)
|
Posted on: 2009/2/12 0:57
#187
|
Just popping in
|
@R-TEAM
So, where are all these serious Reaction/Classact applications?
Anyway, you seem to be quite ignorant about MUI and what it can bring. It may have been slower on 68020 (quite obvious given the extra functionality), but hey, these times are waaaaaaaaaaaaay behind, we're using ppc now.
But you're free to write top-notch applications using plain gadtools (in ASM of course, else it's too slow). :)
|
|
|
|
|
|
Re: The MUI vs Reaction slapfest thread (was OWB 3.6)
|
Posted on: 2009/2/11 23:18
#188
|
Just popping in
|
Funny thread.
People complaining about MUI making it harder to design complex GUI or being unresponsive when some processing happens just prove they don't have a clue about MUI.
Like shinkuro said, notification is an essential concept in MUI which reaction lacks (or if it exists, it's never used :)).
Then, builtin classes coming with MUI are more than enough to make any descent application. That myth a modern MUI app would require all the latest MCC is just plain wrong. For instance, In my projects, i generally avoid requiring any external class, actually. And for the record, MUI inherits and extends BOOPSI, and it can also use the good old original AmigaOS BOOPSI classes.
Also, when you need to process something in a GUI, you do it asynchronously or in an external thread. Otherwise, be it MUI, Reaction or any other toolkit, it will just block. If you don't know how to use a tool properly, don't blame the tool.
About Reaction, I think the most complex application using it is Aweb, which at least seems to do it partially right by using a class design, unlike most of the other (opensourced) reaction/classact GUIs i can see here and there (which are mostly frontends or very simple apps).
For a simple app, it's ok to have a basic design, but as soon as you do something somewhat evolved and meant to be maintained, you adopt a class-based design, or you'll just pull your hairs later.
Anyway, i think the statistics speak for themselves. The most evolved/complex apps almost all use MUI, and there's a reason for this...
That said, i'll agree on one point: if you don't control MUI sources/development, I can understand why you're insisting on using and enhancing Reaction. But it's no valid reason to bash MUI. Better try to achieve what MUI does by extending Reaction (and good luck :)).
|
|
|
|
|
|
Re: MAME any progress on a new version?
|
Posted on: 2008/12/18 15:31
#189
|
Just popping in
|
@jahc
SAM CPU is just too slow for cps2 systems, especially with current mame version (same for a G3@600), and that would be even without sound or display output. The most obvious solution would be to speed up the 68k emulation, which is not that trivial. Some intermediate layers could be tweaked too, and the cps video driver itself may be improved, but all this is not that easy and may not be efficient enough.
A better solution for SAM would be to port 0.3x to 0.6x MAME versions that were about 30% faster.
|
|
|
|
|
|
Re: MAME any progress on a new version?
|
Posted on: 2008/12/18 1:08
#190
|
Just popping in
|
@MamePPCA1
Regarding speed of morphos port, I mainly optimised blitting speed. About 4 times as fast as plain sdl port. But blitting time is only a fraction of the whole emulation process during a given frame of course. So for instance, SDL routine needed 4ms to display a 320x240-16bits surface, while i got it down to less than 1ms. So if you consider a game running at 60fps, you need to complete the whole emulation in less than 16ms. So 3ms is always good to take. For older games that only need a fraction of these 16ms, it can give sometimes a 100% speedup or more. But it's still good to take for systems that are close to use all the cpu.
But in the end, it's mostly the cpu speed that is the limit of course, optimisation or not. And for bigger games, this blit optimisation tends to be less important.
The other advantages of the morphos version is overlay output, builtin gui with snapshots support, history/gameinformation and so on. It's just feel less alien than a SDL app.
|
|
|
|
|
|
Re: MAME any progress on a new version?
|
Posted on: 2008/12/17 23:24
#191
|
Just popping in
|
@jahc
I saw super gem fighters (also CPS2) on Kal-L's A1 XE G4, and it was running at 45 fps, so frameskip was needed.
|
|
|
|
|
|
Re: MAME any progress on a new version?
|
Posted on: 2008/12/17 22:41
#192
|
Just popping in
|
@nubechecorre
For neogeo games, in the 0.9x times, even a G3@600 would handle them without any frameskip IIRC. As for capcom games, while cps1 (final fight for instance) was no problem, cps2 (sf alpha serie, marvel vs whatever, ...) surely doesn't run without frameskip on A1. And I've seen it myself.
About Street Fighter EX running fullspeed on A1, this sounds like wishful thinking. A G3@800 could at most run it at 50% speed (and I'm generous), and that's without considering the overhead caused by SDL.
Now maybe you don't consider a game not running at fullspeed like a problem. But when you actually want to play the game, it is. :)
|
|
|
|
|
|
Re: MAME any progress on a new version?
|
Posted on: 2008/12/17 15:25
#193
|
Just popping in
|
@Spirantho
You might still try the 0.120/0.121 version. This one is still fast enough to play CPS2 games or Psikyo games (SH2) at full speed on a G4 (at least without SDL. I'm not sure a plain port would manage it). Tell me if you need help to port the MorphOS version to OS4, btw.
|
|
|
|
|
|
Re: Necessary projects: (e.g. WxWidgets)
|
Posted on: 2008/12/4 15:47
#194
|
Just popping in
|
@abalaban
Just to close this off topic... :)
C++ is by definition more or equally cryptic than C since it's a superset of C (not always compatible to C, though).
Templates are quite an interesting concept, sure, but their current implementation is really not very good. And on a funnier note, I'm always amazed how long error messages can be when using templates and making a small mistake. I think that there could even be some contest about the longest (and useless) error message about c++ and templates. :)
References can be useful, but take some random code calling a method/function using references without looking at its prototype, you can't easily guess that the passed argument will be modified or not. Passing it by address just makes it clearer that it might be modified.
|
|
|
|
|
|
Re: Necessary projects: (e.g. WxWidgets)
|
Posted on: 2008/12/4 14:43
#195
|
Just popping in
|
@abalaban Quote:
Ok my turn to be a troll that's true that C++ is more complicated to port than C when you are still using 10 years old GCC with half working C++ support
For the record, I made several ports to MorphOS using GCC3.4.6 & GCC 4.2.0, especially for C++ projects. If GCC 2.95 is the only one officially supported, the later versions are available anyway, but unsupported, and for a good reason, but that's another topic. I also stumbled on code generation errors with these cutting-edge GCCs btw (which 2.95 was compiling flawlessly). :) There for the troll. :) Quote:
Ok serious again now, what I meant was that generally with well written C++ (no so common I admit) porting might consist "only" in porting some well defined classes really doing system operations, no need to hunt for the entire code looking for any fork() or execvp() calls
As for your fork()/execve() example, it's really badly chosen. Encapsulation/Separation has nothing to do with C or C++. In any good C or C++ project, you can have a well defined and separated backend avoiding you from reading the whole source code (mame being a good example for a C project, or ScummVM for a C++ example). C++ doesn't help more than C there, not at all. But I somehow fear you think OOP might only doable with C++ and not C, which is really really wrong. Quote:
Reading your post I guess you are really a pro-C guy, I remember I was too until I discover C++ back in 1997 which was really a revelation and an amazement. I can't see where C++ is more cryptic than C (try to explain C/=(A!=0?A:^A) which is plain C to an Eiffel fan or a Delphi adept you will see how understandable C is for them
I may be a pro-C guy, but I also know C++ for ten years now, and using it everyday at work (fortunately we avoid the most stupid and useless C++ extensions). But once again, your example is badly chosen since it applies to C++ as well. Let's take templates syntax, references and operators overloading as examples of syntax horrors and readability issue/error-prone code. :) And don't assume I don't know C++ enough (I know how to use the things I criticize), I just happen to not like them, and I'm not the only one. :)
|
|
|
|
|
|
Re: Necessary projects: (e.g. WxWidgets)
|
Posted on: 2008/12/3 23:00
#196
|
Just popping in
|
@Hans
The language may be defined with a standard by a committee and all, but I don't know any compiler that follows it completely. So that doesn't help much. :)
About ABI, well, you said it, there's no standard there too.
And about readability, you certainly can do awful things in C (or in any language for that matter), but since C++ adds sophisticated stuff (or should i say cryptical or obfuscated) compared to C, you can produce even uglier code in C++ (which often happens, unfortunately). But I don't say you can't have proper C++. My original point was just to disagree about the idea a lambda project should be more portable just because C++ was chosen over C.
|
|
|
|
|
|
Re: Necessary projects: (e.g. WxWidgets)
|
Posted on: 2008/12/3 21:07
#197
|
Just popping in
|
@abalaban
In general, anything C++ rather makes it more complicated than C to port (and not only on AmigaOS :)), but I fear this will be seen as a troll (even though it really isn't).
With C++, you don't really have a well-defined standard, unfortunately. As a consequence, each compiler interprets C++ as it likes. And even between gcc versions, you can get incompatibilites/weirdness. Let's not even talk about binary compatibily between libs compiled for a version linked to a project compiled for another version.
Even about readability (which can be helpful for a port :)), it can sometimes be harder to follow. Things like references, inheritance and templates can make it harder to follow codepath (of course it's doable, but it just takes more time). All this heavily depends on projects of course.
@spirantho
I think you never received my late reply about mame, but i still have mame morphos source code at hand if you want to have a well amigaized port (and not only a plain sdl port).
|
|
|
|
|
|
Re: [SAM] AmigaOS4.1 & DVPlayer
|
Posted on: 2008/11/21 15:15
#198
|
Just popping in
|
@afxgroup
While it can make sense to integrate a few changes, I generally prefer to avoid that, because it just gives more work to mplayer team to validate and "maintain" them (even if they can't really maintain anyway since they can't test this target). And in my case, I also have more important changes (cache2, dvdcss with cache support in mind, a few changes to make it easier to hook a gui) or new internal commands that only really apply for the morphos port. If I were responsible of the MPlayer project, I'm not sure I would accept intrusive changes.
And since I work on a svn local copy, It's really easy for me to merge changes, so IMO, it's not worth the trouble. But anyway, feel free to submit some changes if you wish. :)
|
|
|
|
|
|
Re: [SAM] AmigaOS4.1 & DVPlayer
|
Posted on: 2008/11/20 23:25
#199
|
Just popping in
|
|
|
|
|
|
|
Re: [SAM] AmigaOS4.1 & DVPlayer
|
Posted on: 2008/11/20 20:43
#200
|
Just popping in
|
@afxgroup ahum... The last email I received from you was in 19th july 2006, about integrating amigaos/morphos changes to mplayer svn (which I think isn't a good idea when they are intrusive). And since I have no spam filter at ISP level, I highly doubt I could have missed a mail if you really sent it. Just for your information and to stop weird rumours you seem to spread, the sources are obviously available (at least on request, if they aren't uploaded to my website), since I usually avoid to violate licenses. June version (no GUI in this one) was available at: http://fabportnawak.free.fr/mplayer-svn-20.06.2008-src.tar.gz Current versions (including the one with GUI module) are available at: http://fabportnawak.free.fr/src/That said, it would need more than a mere recompilation to make it compile or work: some MUI4 bits would have to be removed (for the GUI), and for MPlayer core/drivers, some MorphOS Blanker, Process, Dos64, Intuition, CgxVideo and CGX extensions are used, so it would require some adaptations there too (if possible).
|
|
|
|
|
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
