Sorry it takes so long, but just have lately very high motivation for all os4 stuff (dunno why), and so ported official 2.8 version. I.e., not the very latest git's code they had, but 2.8 one. If there will be needs, we can update to the very latest one.
hit open in new tab for fullsize:
That what done:
-- ported over gcc 11.3 + latest experemental binutils 2.40 (from 2023) -- latest SDL2 used -- added casual stack cookie of 1mb, so no possible crashes -- enabled LUA support -- enabled native clipboard text content support (so iffparse.library used) , code taken from AROS version -- enabled proper handling of all this paths with ":" , "/" and co, but sure something maybe be wrong somewhere -- build with -O3 optimisation
There are archive for tests before i upload it to os4depot:
EDIT: I did get the opportunity to download a test for a short time this new port of GraphX2. I did not find any problems, as it seems to run well on my X1000 in windowed and fullscreen modes. All I really did was draw some lines and shapes and fill with color and also change screen resolution. No problems there. I very briefly tried the text tool but found some fonts garbled. Perhaps it works only with bitmap fonts and not TT fonts.
Thanks!
Edited by mbrantley on 2023/11/2 10:57:59 Edited by mbrantley on 2023/11/2 10:58:43 Edited by mbrantley on 2023/11/2 10:59:17
I also tested their last ported version and it works very well, I don't know yet if I will actually use this painting program, but I saved it on the HD, it reminds me a lot of DPaint.
In the past I haven't been able to do much with painting programs, but that's probably my fault
Nevertheless, thanks for the current version.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
@kas1e If this is simple enough, can you check to compile grafx2 2.9, which is the latest version?
I did it on my own, but I lack the fixes you already have in place, and compared to the 2.5wip version on OS4Depot, this was slower. I wonder if your compilation will be better, or they changed something that makes it slow on our systems.
Also, my compilation crashes when I use compositing in SDL, but it works with software, and the ogles modes.
@George Can check tomorrow, but did you compare 2.8 build from this thread with os4depot one ? Is it same fast and problems start with your 2.9 build ? Or 2.8 one also slow ?
-- added casual stack cookie of 1mb, so no possible crashes -- enabled native clipboard text content support (so iffparse.library used) , code taken from AROS version -- enabled proper handling of all this paths with ":" , "/" and co, but sure something maybe be wrong somewhere
Can you share the changes you made to the Grafx2 sources of version 2.8 or provide a link to where to find them?
"..if someone wants to use GPL-covered software, he or she must give others full access to the source code of his or her modification. This allows anyone to verify how the software works and make their own changes and improvements."
It is possible that SDL2 versions run slower. I have rebuilt the 2.9 version under SDL1 for my own needs - it runs fast Comparison of 2.5wip vs 2.8 SDL2 vs 2.9 SDL1 Tested on Qemu A1.
Most noticeable slowdown with LUA demo (2.5wip version doesn't support LUA but runs a bit slower) You have a sub-version of SDL2 running, so I don't think it's QEMU's fault. Version 2.8 of SDL2 has an additional problem with fonts at my place.
It is possible. I am not sure though which version of SDL did the v2.5wip used. Because if it was the SDL2, then I guess some changes made it work slower.
Your videos look pretty good. It shows there is a huge difference between SDL v1 and v2. But I am not sure if we can compare them. What I mean is that SDL2 might provide more features in the program and the problem might be somewhere else. For example, grafx v2.8 and v2.9 using both SDL2 have a huge difference. It might be a matter of optimisation.
But your port seems to work pretty well. Unfortunately, Kas1e's changes are not available so you and me could include them. Also, maybe it would make sense to have two releases of the app, one with SDL 1 and one with SDL 2. Then the user can choose which one to use.
Version v2.5wip uses SDL1 - exactly SDL 1.2.13 (I checked in the contents of the binary). You can also check this via the configuration file. The SDL2 version uses the configuration file ‘gfx2-sdl2.cfg’ and the SDL version uses ‘gfx2.cfg’.
I recompiled the same code that I compiled the SDL versions with the same compilation flags for SDL2. The v2.9 SDL2 behaves in the same way as with you. Everything runs fairly smoothly. Moving the mouse causes the program to slow down terribly. I don't have any errors with fonts like I did with kas1e's 2.8 SDL2 and it works fine to switch the program to full screen on first startup. You could see this error in the video I posted yesterday. Maybe there is something in the code of the SDL2 version that spoils its operation on AOS4 or there is something that SDL2 for AOS4 does not cause this behaviour. It is also quite possible that there is a bug completely unrelated to AOS4 but is more noticeable.
I don't know if anyone is currently using gfx2 and there is a point in looking for a tech problem solution....
Maybe there is something in the code of the SDL2 version that spoils its operation on AOS4 or there is something that SDL2 for AOS4 does not cause this behaviour.
I think that this can be figured out by using a profyler and see which methods are taking more time. As you said, it might be from SDL2, and this could surface some issues.
I remember when I was doing the port of BlobWars Attrition (http://os4depot.net/?function=showfil ... ion/blobwarsattrition.lha) I found that a specific method in SDL was taking a lot of time and then I think I removed it, without much of impact on look and feel, but a huge impact in speed. I think it was SDL_SetTextureColorMod()