@sinisrus

Yeah, NotePad++ would be fantastic. It's my favourite test editor on any platform. So intuitive.

Best regards,

Niels

A screenblanker capable of loading any shader (like shadertoy).

@joerg

Quote:

Would be easy to test, but I have no access to AOS4 at the moment. Only ever had Classic PPC Version with WinUAE on older PC that is stored away.

Test: have a Test task block in ObtainSemaphore() on a semaphore that never gets released and look what the task's TDNestCnt is while it's blocked waiting.

Quote:

Atomic instructions alone are not enough. It works for the "fast-path". That is when at time of the MutextObtain() call the mutex is not owned by anyone. If this isn't successful then the mutex must go the "slow-path" way. That involves thinks like adding the task to the wait queue of the semaphore. This is not safe without something that prevents other tasks from doing the exact same thing at the same time.

The MutextObtain() autodocs themselves say:

-->8--

"if the mutex isn't locked when this function is called on it, it will acquire the lock without the use of Forbid/Permit locking"

-->8--

This suggests that the slow-path uses Forbid/Permit. But to be sure could be tested same way as obtainsem-test.

To test whether "Forbid()/Permit()" really always triggers reschedule could be tested like this:

- create a pri 0 task that busy loops in the background and does nothing else. That task would always be TS_READY.

- in the main task (pri 0) in a loop do:



Assuming SysBase->DispCount contains task dispatch count in AOS4 (like it does in AOS Classic)

@All
Thanks!

But we for sure know that with 2GHZ and old PCi-E + memory speeds, and fact that we big-endian (so double swaps sometimes) and with limitation of 1.8gb (even with Extmem max is +2more gb in "some" cases) , we can't use for real some functionality of modern apps.

With Blender, we for sure will not be able to handle "big" stuff, that for granted. Just not enough memory, etc. But for small stuff that can fits very well. Of course i can add usage of ExtMem, but it will not help to the level that you can do whatever you want with.

The same goes to video editors. But even having half of functionality working, will be much better and more than we may hope year or two ago.

@caseyac
Quote:

Yeah, i have those in todo, but at current state they not that good /finished (i tested them on my Win11). But surely they will be matured enough in next weeks/months. They all share the same core, and while being Rust based looks pretty much portable. So those in todo for sure.

@sinisrus
Yeah looks good too, Krita looks pretty tasty.

@Georg
Quote:In AmigaOS 0.x-3.9 and maybe AROS, but ExecSG isn't based on any old AmigaOS exec sources (there were none anyway, only useless m68k asm code) nor did it try to re-implement it 1:1.
A lot in ExecSG is very different to older exec versions, incl. the task scheduler.

Quote:No idea how the old signal semaphores are implemented in ExecSG, and Procure()/Vacate() is probably not supported at all. Maybe they are, at least partially, based on Mutexes instead.
The IExec->Mutex*() functions aren't based on Forbid()/Permit() but on PPC atomic instructions.

@Caseyac +1

Audacity
Notepad++
Krita
Paint.net
Inkscape

What about a port of the ArtCraft apps (the Adobe application clones)? Especially PhotoCraft and LightCraft. https://github.com/storytold

Been reading a long time, first comment though!
This is amazing and looks performant enough, at least for basic modeling! Much, much better than Blender 5.x on a Raspberry Pi 5! Blender on RPi5 is practically unusable - lots of lag, even with the interface menus (it has to be run in software rendering on RPi). This is smooth as butter compared to that :)

Great!

Wow!

I'd like to see Inkscape on the Amiga.

Lightwave RTG then Blender 5.2.2?! Amiga is coming back to its strengths!

@kas1e
Wow. Someone read my mind. I was just thinking of the possibility of a Mesa-Blender. I was thinking more along the lines of Blender 2.5,
before the introduction of Cycles. I don't know how possible it is to render without GPU acceleration. Obviously, we'll see; but this is really impressive so far.

The current Amiga Blender has some things, aside from using minigl, that need attention. Some of the export options don't work,
and it'd be nice to see some improvements in stability and rendering options.

@kikems
I think you're right. Current Blender is much heavier than it used to be. Kas1e, though, has managed to pull off some Scotty style miracles of late.
I'm anxious to see what comes next.

Wow!It is what I am waiting for. Amiga needs modern productivity software then SuperFrog clones. I'm standing in line for this.

@kas1e

Wow this is magic stuff

Awesome, but maybe Blender 5.x is too complex for OS4 and PPC.
For AmigaOS4 and a PPC processor running between 1.5 GHz and 2 GHz, Blender 2.83 or 3.x might be a better option.
If it runs but is sluggish or quickly runs out of memory, it is better to use an older version that performs better on limited hardware. From version 2.83 onwards, any Blender feature outperforms—by a factor of ten—any other 3D app known on the Amiga.

I think it is more important to have a version with balanced performance, rather than the latest version with requirements that exceed the machine's capabilities.

The current version 5.x is slow, even on modern computers that are already 6–8 years old.

Oh!! Nice!!

@kas1e

What a crazy guy! So does that mean I'll soon be able to edit, cut, and trim my YouTube videos directly on my X5000 using Blender?

Wow. Such progress at every turn.