@Hans:
Thanks for your feedback.
Regarding CPU-hogging:
- Only Limpid clock and CPUInfo were running in the background.
- Low CPU usage: CPUInfo showed an idle CPU usage during all my tests of only 3-5%.
- Switching off 3D effects seemed to help a bit, but it might be a coincidence.
- All drives uses DMA (although, there were no disk activity while running the tests)
- Limpid clock had priority -1 in all my tests, -5 in some. It didn't remove the issues.
- I played around with task priorities on the scroller, and tried up to +30. It got better (solved the issue completely in many cases, but not all).
A theory could be that the running tasks not necessarily uses much CPU, but accidently runs in the time-critical period when the vertical blanking occurs, which lead to a slight delay.
I don't know.
Idea:
My personal opinion is that operations that has to do with graphics and audio should never be disturbed in a way that makes the disturbance visible/audible for the user.
And all this should be handled automatically by the OS.
This is one of the things I like so much about the Classic Amiga system (both the HW DMA channel priorities + software interrupt priorities).
F.ex.: What if exec was fine-tuned to always prioritize vertical blank interrupts before anything else?
So, if the CPU is working on a task, and such an interrupt occurs, that task should be "paused", and the blanking task should start immediatly.
When that interrupt task is finished, the "paused" task should start again.
This way, we don't risk that tasks that accidently are running while the screen needs to be refreshed, prevents timing-critical tasks like vertical blanks.
Could this be doable?
Or maybe it works like this already, and just needs some "fine tuning"?
(It would be very cool if it could).
Hans wrote:
Do you adapt your animation to the frame-rate? If not, it's worth doing....
...it's worth reading this physics tutorial.
Interesting read. I will have this in mind when I reach a bottleneck in my game.
Until now, my strategy has been to render each frame fast enough to make it ready for each vertical blank.
Hans wrote:
Composite3DDemo
This is cool! Impressive that's possible to achieve 3D effects by using 2D graphics operations.
Hans wrote:
Lack of examples for smooth animation.. Something simpler and in plain C would definitely be worth having in the SDK.
Agreed.
Working examples is a very good thing, I think; Both simple and advanced ones.
And books also, which explains the conceptual ideas, how things plays together, and recommended practices.
Examples have helped me a lot, as well as books like the Amiga ROM Kernel reference manuals, which helps to see the "big picture" and get a better understanding.
If only there existed such books updated for OS4 on NG Amigas..
And of course; Examples and articles all those nice people on the internet makes available for others.
Actually, one of the triggers that made me start working on my game (in addition to really get to know how to program OS4), was to exploit the possibilities for making smooth, hardware accellerated 2D operations with almost zero CPU usage.
And I wanted to program towards native Amiga libraries, instead of using frameworks like SDL (which I have no interest in).
This is the only way I could be sure I got the most out of the hardware (better control, less overhead).
Well, not 100% sure, as "hitting the hardware" directly isn't allowed anymore (although it would have been really, really cool just to have tried it on my Sam, just to getting to know its limitations better and how the hardware works "under the hood").
On my Sam, I have seen several simple 2D-scrolltexts consuming 100% CPU, which I found very strange.
I wanted to find out if this happened when using "classic" native OS4 library calls like graphics.library also.
I got really motivated when I saw that you could do blitting operations without consuming CPU at all, just like on the classic.
Actually; It was possible to blit the whole screen several times, so those OS-procedures seems to work quite good.
This proved to me that those specific 2D graphics procedures were HW accelerated.
