@all

New version on os4depot query.

New since last release:

--- New tool icons (now in modern way)
--- Made the tool icons smaller
--- Added Generate Gradient filter
--- Added shortcut for the pixel brush (i)
--- Made menus close more easily when clicking next to them

@afxgroup
Now all is ok :)

@ALL

New version on os4depot in upload query. Whats new:

-- fixed resizing bugs normally in our SDL (thanks to AfxGroup). No more jumping when resize, all works fine.

-- add code on checking for present/not present glcontext (that is related to our MiniGL, which do not check yorself when do glDeleteTexture on present context to avoid overhead). Because of it gLDeleteTexture no more crashes on exit (before was ugly hack to fix crash on exit, now its done in good way)

-- visual restructurisation of default look (new screenshot of rev_33 will be on os4depot when it will be grabbed from upload_query).

-- usual bug fixing and alt.

@328gts
Check that version, maybe now it will be fine with screensaver (maybe not:) ).

@afxgroup

Tested. 16/32 bit mode work fine (resizing also not jumping). The only problem now with depth = 0, because resizing are jumping. I think you just forget to add cheking on depth 0 , but because Depth=0 are used too from time to time in some SDL prods, imho that also need to add/fix.

But for 16/32 modes all works fine, cool, thanks :)

@Mrodfr

Yannick is not coder of LodePaint, he just a one who port it to AROS (and from which i got that it can be ported to AOS4). And he of course have no problems with speed on AROS because of fast CPU. Coder of LodePAint are Lode Vandevenne.

That "rerendering all the time" its about of structure of programm itself. Its done (initially, and now) just like modern games done, because it's easy to code i think (all in all, he is author, and do what he want and how he want of course).

I will ask of course author about "more speedup please if possible" , and about "rerender only actual area over mouse pointer", but not want to annoy he very well at one push, just becaus he will tired and drop aos support. Small steps and such .. I already write he some "suggestions" on which he works rigth now, so, need some patience..

I checked right now lodepaint page, and he commit new changes in trunk, in which i found many parts which was rewriting with having in mind some MiniGL features about which i say to him .

So, just some patience, and i think it will be faster in future.

@afxgroup

Way cool ! Thanks a lot !

Btw, you fix only that Depth bug, or also "jumping" one ?

@Kicko
Yep, toolbar images are suck a bit for moment :) (as well as Font for menus). I think it will changed soon.

Related to Layers, that what is in Manual about:

Quote:

@Mrodfr

Heavy CPU loading its just because lodepaint render yourself every frame (that not about SDL or OpenGL at all, its more about CPU raw power). For example 1.7ghz will be more than enough. LodePaint in terms of "engine" its just the same as any modern game, which rerender every frame and every seconds and alt. For example on my peg2 with 1ghz of cpu, when i resize window to 640x480, i have it working pretty fast (not checked CPU loading, will do it for interest later).

So, when application are opens, its not going to iddle state, its still rerender yourself every time. I ask main coder about making some kind of "check" on some kind of "if user do nothing, do not rerender", and if he will add that, then LodePaint will faster (but not when you will works with it, still redraw all the time will be).

Dunno from what come menus and gui, but for accessing to any file just type for example Work: and then use all those gadgets, or press drop down gadget and choice Progdir: and then move up. But better just write "work:". I will add a bit more "right" file open requester a bit later.

About resizing bug : its our SDL bug, and i already post here question about, and AfxGroup say that will fix it soon (i check sdl-page every few hours:) ).

Before i will post that bug to SDL bug tracker, i want to sum up a bit all the info, and maybe some other developers will say something new or confirm that problem are exist for now, so:

For SDL we have SDL_VIDEORESIZE event, which catch the moment when user trying to resize the window. Usually, code looks like this:

Quote:

What mean that after we create a first time window by SDL_SetVideoMode, later, by SDL_VIDEORESIZE event, we again call SDL_SetVideoMode, which resize our window.

The problem which i found in our SDL, its that if we have in SetVideoMode , depth more than 0 (16 or 32 for example), OpenGL content just does not updates. But with Depth=0 it updates fine. But that is wrong, because it should updates with any Depth (that logical). So, that is first real bug (imho).

Another one bug or "feature" its that SDL_SetVideoMode always "centered". I.e. on win32/linux, first time called SDL_SetVideoMode are centered, but later all that SDL_SetVideoMode calls over SDL_VIDEORESIZE event are not. Becayse when it centered all the time (as we have on os4 now) then it looks like window "jumping"). So, x1/y1 of window should be on the same place as initialy, and only x2/y2 are changed and data updates to the new positions (without centere the window).

Whyle the first one (about Depth = 0) is real bug, other one (about centered window) maybe possible to disable somehow in the code ?). Very possible that is not bug, but some feature which can be swith on/off by some flags passed to SDL_SetVideoMode fucntion.

For all who in interest, there is example archive from Hans webpage, where he do resizing with Depth 0, and it works (so, you can see how window jump-centered after resizing). Also you can change Depth 0 to 16/32 and will see how buggy it start to works with not updated OpenGL data.

Compilation are trivial: gcc SDL-GL-basic.c -lSDL -lGL.

Any suggestions, testing and such are wellcome.

@wawa

If you use GCC, better just download latest trunk, and search in all the files on words amigaos4. It will be defines with AROS together, so, you just need to add there aos3 define for saying to compiler to do the same. So, that will be all the "major" changes. Minor ones refers to just wrong includes, some undifined types and such. But if you compile it already, then imho you need check all that amigaos4/aros defines and add the same for os3

@Antique

Not sure that we can radically speedup it with our current OpenGL (slow) realisation (which also use Tranformation, Lighting and CLiping in Software Mode all the time). Also that Warp3D layer beetwen, which overhead our MiniGL very much. But author try to do more and more optimisation, so, very possible it will be faster in future (still, it will be indeed fast when we will have MESA and x1000 :) ).

EDIT: btw, try latest build (where i fix resizing), and for make it works a bit faster, resize it as small as you can (it will be 640x480), and on my 1ghz its can be called "fast". Yes, not so big area for work, but for some simply load/save/change/crops/alpha-change/etc tasks will be more faster.

@All
New version in upload query on os4depot. For this time i fix resizing bug (now it works fine). And looks like that is bug of our SDL implemetation in combo with SDL_SetVideoMode + resize/opengl flags. With depth = 0, all works as must. But if you set depth 16 or 32, then it just works wrong. When i will sure that is bug in our SDL, i will inform it deeply on sdl page.

@ALL
New version in the Upload query on os4depot for now. New since the last (rev30) build:

-- new toolbar look (now it looks really modern, and not like before with win3.1 like look). Its not AISS, but still, very nice.
-- internal clipboard support (so, now all those copy/paste/cut menus are works). Amiga-specific ctrl+c and ctrl+v are not supported at moment, so, only internal usage in the programm itself for now.
-- Added "gradient line" tool, it can only draw lines of 1-pixel thickness, but with gradient from left to right color
-- Made the add/remove borders and rescale filters support all 4 color modes
-- Fixed another color slider bug

Enjoy!

@328gts
Looks like some OpenGL collisions .. Maybe not enough video memory ?

Btw. Right now do with lodepaint that nasty thinks:
loaded picture, add alpha channel on it by some manipulations, resize it, and save as png = have normal transparent icon. Good that at last i can do such easy but from time to time need it for me fucntions in one app on aos4.

@328gts
Yep, its indeed more or less usable now. I can do at last those primitive and simply thinks with alpha channels, rotating, resizing, cropping and such in modern style. Of course its for now far from "perfect" as in terms of speed, and in terms of some bugs (which i think 100% here, just not detected very fast by me).

I think if some day we will have new Mesa about we all talk in last 1-2 years, without that Warp3d layer beetwen, then it will "fly" even on 600-700mhz cpus and rare video cards :) But even for now its imho good to have. It was boring for me always swith to mspaint or to photoshop when i need to do not so heavy (but still not allowed on any amiga pain apps) thinks. Now i can do all of this with lodepaint :) Hope programm will mature more and more.

@ALL

For everyone in interest, there is a new version of LodePaint for AOS4. Many new functions was added, many changes was done (not by me, by original author). And the most important - he clean up a code a bit, which help me to detect where crash on exit happenes exactly and i can fix it.

Here (in archive) also a new manual/docs and alt as well as full changelog og just for everyone who in interst about "what exactly was done from the last times".

Also it compiles now with all that enabled optimisation (-O3) and such, so, it also must be faster than the first version.

Because programm are works normally now (i mean have no crashes on exit), i upload it on os4depot, and for now you can grab it here

Enjoy, have fan, and report any bugs here.

ps. thanks to Yannick, he upload my changes related to aos4 also to sourceforge, so, now it mostly download trunk/compile/test work.

@freddix

Tested. They all looks nice , but i personally prefer Relief one.

Btw, if you will make it as real screen-blanker, then imho you just can add all of this to the "module preferences" menu. And lets user choice any look, any screen lesolution and alt.

@freddix
Quote:
Usual choice :) Or outdated and default, or new and modern. If we all over opengl already, so why not ..

@freddix

I mean that colors itself of boing-ball are looks like 256 colors textures (i mean not that they different, but just like color of ball looks a bit "outdated" initially. I mean texture itself). It's like flat color, and not gradietn (which looks better imho). But that is imho of course, and not big deal :)

btw, maybe also "shadow" are missted here, and because of it, all looks like "not in the depth".

@freddix

Looks very nice, but, gamma of the ball itself are too bit "not true color" ? Maybe add some kind of fog/light for the ball itself , and make red/white colors a bit more "smooth/true-colors like" ?

ps. new version of amidark are coming ?:)

@ChrisH

Imho the major slowing down there is because of Amycygnix as a layer. For sure if it will be done some day native, it will be faster even without code-optimisation.