I am sure that LISTVIEW has adjustable width of the slider, but don't know how it is with the LISTBROWSER.

@Alfkil
Quote:
OK, but as I said I'll look into the code first to find the reasons (potential places) of speed issues on AmigaOS. Only if I understand the code and find these places I will begin to fix speed problems.

As of compiling C++ projects on AmigaOS4.1 it's not that big problem for me (even though I've got loaned Sam440ep). But if I need to use cross-compiling I'll contact you of course.

I guess that AmigaOS developers are helping you with the project in some way?

@Alfkil

All right, I've got account there but first I just look into the Qt code to see if I can be of any help. I'm rather good at analyzing the code, but I'll see if Qt isn't too big problem for me ;)

I've got a few projects at the moment (Amiga classic ones), but I'll try to find a time for Qt.

Regards
Robert

As Alfkil said, the MiniGL or composition is used to render graphics, thus the rendering is actually hardware accelerated.

In my opinion Qt speed can be in conjunction with the abstraction layers used by it and disproportions between Qt and AmigaOS philosophy. The authors of Qt hadn't AmigaOS in mind when writing Qt, so the comparision to other devices and systems may be inappropriate.

What I mean is that Qt uses own classes for Timer, Keyboard events, Mouse events etc., while AmigaOS uses timer.device, input.device (window.class) etc. Proper transformation of Qt into AmigaOS philosophy may solve the problem. It might be useful to look what parts of Qt are requiring the most CPU or GPU load and improve the algorithms. I'd like to notice that the biggest problem with regular porting to AmigaOS (I'm not saying here about Qt) is to not look into the code of the program. Frequently this leads to speed problems.

It MAY require changing (adapting to AmigaOS components) some of the interiors of the Qt in order to get the good speed. I understand that we may need to avoid such solution (to not cause other problems).

I'd really like to dig into this problem (Qt speed), cause programming is my passion, and I've had speed problems for a long time with my programs for classic Amiga aswell. I solved many of these problems. :) I know C++ from some books and from the subject in University, but I'm not much experienced (not much practice).

I really appreciate Alfkil's work, because Qt seems to be large library and adapting it to Amiga is a great work.

Hey!

I'm posting because I've just started my little blog where I will post everything related to my work for Amiga. Details below.

Important thing: I just today logged in to Amigans and noticed two PMs from Alfkil and Joeled regarding Qt. I'm sorry, but I can't help at the moment with Qt! I'm too novice developer for such big projects. I asked about Qt speed because it's really a thing I'm very interested in (program's speed and abstract layers). And I strongly believe that Amiga software can be fast!

So, returning to the blog topic, I've got some dreams about some new games for Classic Amiga, I've got enough skills to make some and I'm progressing. The first entry in the blog is related to the new game being developed by me: Astroblox (Astro blocks). It is a game similiar to well-known puzzle Sokoban where you have to place blocks into destination places, but with new graphics.

If you wish to visit my blog go to: http://minniatian.republika.pl . It's a site built by me in pure HTML. The old entries will remain there and new ones will be put on top of them. Today I placed there a screenshot from actual game graphics and some code in C. The game should be portable to AmigaOS 4.x in the future as it is written using system calls.

Best wishes to Amigans!
Robert

Quote:
I think that if the Event Handling of Qt is the reason of slow speed we must think about doing proper transformation of Qt events -> into -> IDCMP Events of Intuition Windows. The ReplyMsg() for example must be called immediately after receiving message with GetMsg(). Such transformation which doesn't produce system overhead on AmigaOS is quite easy to do. And we don't need to change anything in the Qt core. What do you guys think about it?

Thanks for the link!

Hello!

First I'd like to send greets to Alfkil for his work on Qt. You're doing great job!

Second I'd like to ask, what is the problem in general with speed of Qt apps ported to AmigaOS 4 using Alfkil's native Qt port? Maybe it requires discussion to solve the problem with the speed of Qt apps? I posses some knowledge of native programming for Amiga and AmigaOS (been programming for it since years) and I'm offering my help to get Qt faster on AmigaOS 4.

It couldn't be that Qt on similiar (in terms of performance) platform (for example Windows) is running fast, but on AmigaOS 4 it is running slow. What is the reason?

@Deniil
Quote:
The platforms the problem exists:

- Sam440ep
- AmigaONE

The platform the problem doesn't exist:

- Amiga+PPC+Paula

So it's true the problem lies in AHI sound card driver.

I worked around the problem and it seems OK! Music from my player is just nice, I'm listening to it right now (music from Lemmings 2)

I just call
AHI_ControlAudio(actrl, AHIC_Play, FALSE, TAG_DONE);
AHI_ControlAudio(actrl, AHIA_PlayerFreq, frequency, TAG_DONE);
AHI_ControlAudio(actrl, AHIC_Play, TRUE, TAG_DONE);

With the neighbourhood of the 2 perimeter functions setting the frequency doesn't produce noises. All right, now the production of Diamond Player 2.0 can progress further

It is currently a program written in C++ with the use of its many interesting features. MOD and MED modules are for example the childs of abstract Music Module class, also audio output is a template in Music Player class, so there is a possibility to use different audio output methods like audio.device for example or AHI like it is now.

The workaround doesn't cause any problems (only there is a tiny, almost unnoticably break when changing frequency). Cheers.

Really no reply about this? I need to solve this problem for my music player.

Hello Amigans,

After a long period I'm back to business and I'm planning to finish some software for Amigas equipped with AmigaOS 4. These software is as follows:

- "Robbo" clone - a clone of logical game from 8-bit platform Atari XL/XE.
- "Reco Draw" - a painting program as an expansion of my Icon Edit.
- "Diam Play" - a music player program with my own implementation of replayers. The advantage of this replayer is that it is possible to scroll through patterns.

Also some software developing tools may be created by me during development process.

Best regards to the Amiga community.
Robert "RNS Amiga Club" Szacki

@SSolie

I have one question: Do you plan to make AmigaGuide or HTML format version of Autodocs from Software Developer Kit for AmigaOS 4? For now they are only in plain text format. Or can you give permission to place the documentation in such format? Or the Wiki is to be the only place where the updated documentation is placed?

There's a trick to calculate BytesPerRow if PixelsPerRow is given. Here are appropriate equations:

BytesPerRow = (PixelsPerRow + 7) >> 3;

So you add 7 then divide by 8. This way the nearest ceiling BPR value is given (taken from: ceiling of a real number is the nearest integer number not smaller than this number).

This way the WordsPerRow can be calculated as well:

WordsPerRow = (PixelsPerRow + 15) >> 4;

This can be used for example Blitter operations, because Blitter works on 16-bit words.

I guess this is a problem with software drivers for AmigaOne 500 audio device or even the AHI on AmigaOS 4.x itself.

For example I've got a problem with audio programs on Amiga 1200 with BlizzardPPC board, those ones which were using high-level AHI routines all played slow and noisy, that's why I wrote player program Diamond Player.

Have you tried DiamPlay on your AmigaOne 500? Is it also replaying MODs or MED modules slowly and with low playback quality?

I was just about to create such thread, seriously! I wish to join the thanks to AmigaOS developers.

I'm a proud owner of AmigaOS 4.0 Classic on Amiga 1200T PPC and also I've got loaned Sam440ep with AmigaOS4.1. I was pretty impressed when first launched AmigaOS 4.0, the system was looking exactly or similiar to Windows in terms of beautifulness of desktop and usefulness.

You guys at AmigaOS development team are making a very nice job at keeping AmigaOS up to date. I am a programmer aswell and a computer science student and made some small utils for AmigaOS 4.0 already. I decided to make programs to AmigaOS (not only 4.0, but also earlier versions because I'm classic fan) to keep these systems with latest software.

My programs are for now quite small but fast and running natively. I thing that the most important factor in porting on or making software for AmigaOS 4.x is to keep the quality and program efficiency at optimal level.

Greetings!

I'm posting this letter from Timberworf latest Beta. It's working great on Sam440ep - it's better and faster than old OWB. So well done! Thank you for your hard work! Keep it up!

Thanks everyone for answers. I send best wishes to Fab for his Odyssey browser and Rogue and his team for Timber Wolf.

AHI in AmigaOS4.1 (but not in AmigaOS4.0) has bug which reveals itself when you change player frequency (with AHI_ControlAudio function and AHIA_PlayerFreq) while playing module (when AHIC_Play is set). Once frequency is changed - the audio output become very noisy. Interesting is fact that there is no such bug in AHI for AmigaOS4.0 classic.

I need to change frequency to properly handle frequency changes in MED music modules. On A1200 PPC it worked, but on Sam440ep it doesn't (audio become noises when frequency is changed).

For now I use software interrupt to handle replaying timing, but it's not best method.

@Rogue

What I was going to notice is that less modern browsers like OWB works rather slow even on powerful machines (haven't tried MUI-OWB because can't update my system because it's loaned). And there is even more complex browser like Firefox ported. So natural thing is that it will be slower than even OWB unless drastically optimized.

I post this from latest Firefox 13.0.1 and the program got significally speed boost! The pages are scrolled much faster. So it is possible to optimize.