i have compiled it from the latest sourceforge source anyway. yes it builds so seems moreless all includes and libs are in place. the only aos4 define i see is the one that defines lpi_amiga, ive set it in devcpp preprocessor definitions, but i have an impression that it isnt taken into account anymore when a custom makefile is used. how do i define in makefile? -DLPI_AMIGA as a compiler option? is that right?
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:) ).
been playing with lodepaint for a good while last night and I must say it is quite a nice intuitive paint program ..no crashes at all and just need better overall speed for slower machines which hopefully will come in future updates
@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:
If layers are implemented (they are not yet) then they shouldn't cause confusing behaviour when you're not actually using them. That means:
* If you didn't make multiple layers, there won't appear multiple layers. Floating selections aren't layers, nor are geometric primitives or texts. * Cropping and resizing should work on the entire image by default, independent of layers, unless a command to do it only on the current layer is specifically enabled. * There should never be drawn something that looks like a selection rectangle around a layer or an image. A white/black dotted line is reserved only for selections to avoid confusion.
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). /[quote]
Ok, not SDL or OPENGL, just only a matter of PCU power.
I don't know this kind of "other world" application allways render all and forever, even when doing nothing. A good method to sell computer, but I understand that on game (when all the screen move forever).
the basic thing is just render the picture window when drawing,.... but It's even not the case.
Hum, I like more a lot my amiga now
ask yannick to render just the window the pointer is positionned on, for gaining speed on small CPU power computer.... of course if possible on his platform.
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
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.
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:) ).
--- 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
@Samo Yep, will add to "amiga specific todo list" :)
@Mrodfr I talk about speed with author, and that what he answer to me:
Quote:
Speeding up the LodePaint GUI by only rerendering certain parts is very hard afaik. I've studies such options, but no, I don't think I can do anything like that now. Unlike a "normal" GUI, the GUI of LodePaint isn't event-based, but works like a computer game with a game-loop where everything is redrawn. Only drawing in areas where the mouse changed is hard because: other things than the mouse can also change the screen (e.g. an operation that finished after calculating a while, or a key press). Rerendering a part of a window with alpha translucency requires that what is behind it to be rerendered too. Some things might be animated.
There's no system at all built in the LodePaint GUI to detect when a redraw is needed and to only redraw windows for which it is needed, and it's hard to make.
The only thing there currently is, is a hidden "standby" system, where if you didn't move the mouse for 30 seconds or so, it redraws only 2 frames per second instead of the regular 40 or 60 FPS. This to save a lot of GPU processing power when the program isn't being used.
Also, if you draw on the painting's texture with the mouse with a brush, then only the affected part of the texture is uploaded to the video card again (and saved in undo), instead of the complete texture, otherwise drawing on it with a brush would go way too slow. So it's optimized where easily possible.
So, that mean, that for now, radical speed up will have no place (maybe later). Our hope its new MESA :)
works like a computer game with a game-loop where everything is redrawn
He's obviously never written an Amiga game, or in fact any game on any 8/16-bit system...
Quote:
There's no system at all built in the LodePaint GUI to detect when a redraw is needed and to only redraw windows for which it is needed, and it's hard to make.
I don't see why this is so hard (but I am not volunteering to do it either!), since IMHO this is "merely" an optimisation that you should expect to add at some point (whatever the program). But if it already works "fast enough" on monster PCs, then I guess there is no motivation to do it
LodePaint works fast on a PC with 256MB RAM, Athlon XP 1700MHz and Geforce3 video card.
Dunno can we called tht config a monster.. But anyway, we all understand that is not "amiga specific" programm, and only can hope for some optimisation later. But as i point, also our realisation of MiniGL thorugh Warp3D slowing down it a lot. Anyway x1000 will more that enough imho (even with current version of minigl over warp3d, and alt).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
..no crashes at all and just need better overall speed for slower machines which hopefully will come in future updates
