@samo79

I think i suck, and i forget to replace by new catalogs, sorry, will do it today and reupload agan.

@afxgroup

I build that version right now, and benchmarks are VERY GOOD ! Also i see your benchmarks, and you 100% right, it the same BIG difference for me. Very cool. For example, if we will compare with MORPHOSs SDL speed for now on the same hardware (in uppear post), and that one which i have for now:



That mean, that OS4 version for now are faster than morphos ones in 300% in SW mode, and for example in 32x32 blits 640x480 in HW it also faster in 2 times for now !

I even cab see the differences beetwen old SDL and new one visually while Bench test are works.

I should to say that is what i call "radical speedup" ! Very good.

@afxgroup

Just to avoid creating of new thread about the same, i bring that one.

As i see you start to works on SDL again, and your latest update (r42) was about adding a preliminary version of p96WritePixelArray replacement. I check the differences, and found that before BltBitMapRastPort() functions was used. And that cause a bit of interest from me : what fucntions are faster ? As far as i remember, in last time we all blame p96 pretty much (bottlneck, old, bad designed), and that make me curios what are better: that BltBitMapRastPort from graphics.library, or that p96WritePixelArray from p96 ? I check the docs, but there is nothing about which one are better or faster .. Maybe you already do some tests with it and can say about it more ?

@ALL

New version in upload query on os4 depot. Remember that almost all of work done by Yannick, i only add mouse wheel-support and fix few little typos. Also xenic help pretty much (As well as trixie and saimo79 and all others :) )

So, new since last release:

General ones:

-- Corrected misinterpretation of relative coordinates,
-- Corrected handling of default stroke colors
-- Conversion of inkscape/sodipodi figures is now ok
-- gradient fill is converted to black
-- Added menu entry for importing SVG through svg2fig
-- Added free hand drawing mode for polyline/polygon/spline using the middle mouse button)
-- Renamed correctly middle/right mouse button function pointers
-- Added fields in preference for SVG import and free hand drawing and upped up revision
-- Created temporary missCat.h file to store message strings missing from catalog
-- Added key action for freehand drawing (Left ALT)
-- Added panning (CTRL + Left mouse button)
-- Started work for speed improvment in AA mode. Right now if only one part of the display is corrupted, it is redrawn without AA (a hit on R refreshs the whole display)
-- Improved freehand drawing behaviour, distance between points is the relative to zooming factor
-- removal of drawing artifacts on border of display while panning with AA enabled
-- Correction for line drawing corruption especially when zooming in and out
-- Better scrolling for low speed display
-- Tuned a bit pan and free hand drawing feature behaviour
-- Other small bug-fixes

AOS4 related changes:

-- Reworked totally zoom window, works ok on OS4 now and added zoom factor gadget.
-- Added support of mouse-wheel for zoom in/out (for now, it works while active those windowses: attribute, toolbar, mode, font, zoom).
-- Fixed all the problems with loosing of decorations on custom screen, now, with clonning or when you choice any mode, it will have the same look as your WB.

Also i compile that version with including debug information (for better bugs-catching), so, at this moment binary a bit huge. But all who have any bugs, can now send me GR outputs via PM and i will check where bugs is happenes.

Enjoy !

@samo79
there is now icon for directory and latest catalogs (i hope:) )

@tonyw

Nope, i not know that. For now it works for everyone except mr2 (when he trying to type a text), and for 328gts (when he just trying to run it). How it crashes for you, and did you have all latest stuff (os4.1update2, last libs and as usual) ? Did you delete old prefs, install all in new directory and so on ? It crashes for you from first run, or while you use program ?

I will build today a new version, with debug info, so, you can send me your crashlog too.

Or maybe you even can check the code on SF, and found where your NULL pointer bug happens ?


ps. did you fix your problems with lodepaint ? (i answer you in the mail that you need update your SDL library).

@tonyw

In AmiFig LUA only using for 2 scripts (which spawn 2 graphical interfaces, which just GUI for fig2dev programm). So, if you can write such interface on Reaction, then will be pretty cool.

For now i not include any LUA scripts to aos4 version, because it possible to do all manually. But its a bit suck of course, and better to have 2 reaction based replacements (or maybe even AREXX scripts).

@samo79

There some problems with making wheel-zoom-in-out working while main area are active, but it works when other windowses are active. I think we should release it even like that because of all other fixes and alt (tomorrow)

@sba

Btw, maybe a bounty will a bit motivate you to work more on it ? Imho 1-2 thousands can be collected for such important project with no problems.

@djrikky
Quote:

Nope, i am russian. While i think english are more than enough in general, if you still will do site multi-language, i can help with russian then.

@xenic
I also add mouse-wheel support for os4 in amifig (zoom-in / zoom-out), but for now i add it only when those windowses are active:

win_toolz
win_attribute
win_modes
win_zoom

The main active window are handles in the win_another.c file, but, something wrong here for now with wheel handling..

@fingus
Your index page looks pretty nice. Pretty nice designed, while simply, but good for eyes. And domain name looks good too. For sure Rikky should move all his stuff on your domain.

@Mrodfr

The good debugger never will be easy for users (you need to know how code, you need to know what is breakpoints, assembler in general and assembler instuctions, you need to know what is stack pointers, what is stack, memory layoyts and so on). Any debugger its mostly for developers, not for end users. And in general it will not help simply user in any way (only a few maybe, in a very few situations). But will be help a lot to developers, while they works. And of course, it will help to found bugs, but again by developers only. Knowing how to use debugger, its big area of other side of programming, and its requeres some programming skills in any way.

Valgrind are good too, yes, but its not debugger. Its more likely "bug hunting tool", which are good to have too of course, but that is not gebugger (too different purposes). The good example of wellknown debuggers its GDB on linux and Olly on Win32.

@xenic
Ok, then let's use ados script for for now. Btw, Yannick add missing include to win_zoom.c. And check plz last revision (196). In rev 195 Yannick add that: "Screen option for fig2dev and ras2vec shall not be written anymore if nothing is written in the field (old bug not noticeable under ARSO as the option is used)". Will it help us to avoid usage of that script ?

@328gts, mr2
I will build the next version with debug info support, and then, we can try agan on your crashes , and then crashlogs can help (for now they only show that somethere are problems, but not exact information).

@samo79
Yannick add your translation to svn (rev196).

@alfkil

If you want to make a real debugger (like GDB or kind), then imho it should be logical as possible and easy (but easy not mean less features of course). The list of "wishes" can be very big (i can write such, if you in real interest), but in general, just making it GDB like, or Monam (old 68k debugger) like , or any other debugger like. Mostly they all have the same features, just differently designed.

Imho will be cool to have something like one "working window", where you can type commands (not only pressing buttons by mouse), type addresses and so on, and other windowses some of which can be only for info, some of them can change values too.

-- list of C functions from libc
-- list of user functions if -g was provides.
-- disassembler window
-- hex-viewer window
-- registers info window (with all those stack pointers, r0-r32 registers,etc)
-- information window (address from which in memory process will be started, how big is it , and other stuff which can help to do debugging).
-- memory stack window (to show current memory state while programm working)

It also should be (imho) interactive. I.e. you can do "step" by assembler instructions (not over full functions).

For example when you run programm, and it works, you can for example press "pause", then go for example to disassemble window, where you can interactive do "step" command.

Well .. its all the same features as on any other debuggers on any OS.

For example, for Win32 i like a lot OllyDebugger (one of the best ones for win32):

Screenshot1

Screenshot2

Or few simply ones:

CPC debugger (WIN32, but for Z80 cpu)

syser debugger (DOS)

They all do the same, and their look almost the same on every OS, be it or AOS3 (dtp , monam , sasc debuger), or win32, or linux with gdb/any_front_end (i mean look of UI, which give developer all possible information in easy way).

Of course for example GDB are fully interactive, but only one window are here, which are pretty much changed by full interactive mode, by which you can do all what you need. Also there is many front-ends to make GDB the same as all other GUI debuggers ..

@samo79, djrikky
Btw, i made a little video of "windowthumbs" in action. Maybe some other that-topic-readers will in interest about one more solution. But because of some "eye-candy" it take a time to spawn, swith (you need to detect which window you want and where is it), while in compare with my one you just swith it fast without any info,and you can do your work faster. But that is matter of tasty

Video of "windowthumbs" here (youtube).

@samo79, djrikky

There is also one more alt+tab swither, called WindowThumbs. Its can handler alt+tab too, also can works as commoditie, but not only swith beetwen windowses as my one, but spawn a graphical line, with thumbs. Pretty good one, but not reactive fast in some place (expectually when you choice SCALE options), for better thumbs look.

@djrikki

:) That old song about making WB better, but we can only hope, or do those sucking little commodities which will help a bit :)

Imho Hyperion developers can add to FKEY one more options like "swith beetwen windowses", and add the same code as i do. So, users can set any key-combo for that, and while it will be not eye-candy, it will works (better than nothing).

@xenic

Quote:

Yes, i already said that to Yannick 2 days ago, and he add that, but later, in new commit , he remove that (i think because he just messing with other win_zoom file). I will ask him again about that.

Quote:
Hm.. I send for him all the changes which you send for me.
Looks like he just missed that part. Can you please send exactly part of code with that changes, and i again will annoy him about.


Quote:

Maybe for keeping "the same" for everything, better to say for users "install lua.lha from os4depot" ? To avoid different mess.

Did you check btw those Lua scripts, will they work on aos4 ? Or maybe there something aros specific in it ?

@samo79
Imho we should ask Fab, about how much money he want to make port of his OWB to os4 :)

@fingus

For me FF in current state absolutly unusable. You can load one-two sites and then crashes heavy :)

Realted to OWB , there is nothing what we can change. Joerg say pretty clear, that he will not add anything to OWB, because if was designed not for desktop browser :) Only if anyone else will start to works on it, or maybe someone will port Fab's OWB from MorphOS. But its indeed sad .. OWB on OS4 in current stage are very cool. Sadly if it will dead-end :(