Jump to content

angusj

Members
 View Profile  See their activity

  • Content Count

    132

  • Joined

  • Last visited

  • Days Won

    8

Posts posted by angusj

  5. Posted

    1 minute ago, timfrost said:

    I liked the Vectorize demo, but it seems that saving the monochrome image to SVG is not finished yet. Or did I miss something?

    Hi Tim. Yeah, writing to SVG is currently barely functional (unlike reading them). Also, you can't do it the way you write/save images of other formats. There is an SVG writing demo, but it's very primative. I think for the foreseeable future is best to consider SVG as read only.

  7. Posted

    Image32 is a 2D graphics library written entirely in Delphi Pascal.

    It provides an extensive range of image manipulation functions and includes a polygon renderer that supports a wide range of filling options.

     

    SimpleLayers.thumb.png.d60563d54908ff22672c7162644967d1.png

    Documentation:

    http://www.angusj.com/delphi/image32/Docs/_Body.htm

     

    Examples:

    http://www.angusj.com/delphi/image32/Docs/Examples.htm

     

    Download:

    https://sourceforge.net/projects/image32/

     

     

     

    • Like 15
    • Thanks 8

  9. Posted · Edited by angusj

    On 3/18/2021 at 2:19 AM, balabuev said:

    Here is my try. I've changed a lot in existing code (mentioned early comparers, equality comparers, etc.). Also, I've replaced returned string type in functions by PString, just because otherwise string handling takes too much time and algorythms comparison becomes not interesting. 

    As well I've added my own minimalistic implementation of hash maps (not universal).

     

    mapstest.zip

     

     

    Hi. I've downloaded and looked at your NameMapUnit unit and have the following comments:

    1. Firstly, great speed, so thanks and well done.

    2. I suggest adding an "InitialCapacity" parameter to your  TMapBase.constructor

    3. It seems to me that your TMapBase.Rehash method, which concurrently removes and reinserts items into FItems, risks some duplication. (OK, on further testing this doesn't seem to be a problem.) Anyhow, there may be a marginal improvement by reinserting TMapItem items instead of recreating them.

    Cheers.

  11. Posted · Edited by angusj
    Fixed tags

    Resource Hacker

    A resource editor for 32bit and 64bit Windows applications. It's both a resource compiler and a decompiler - enabling viewing and editing of resources in executables (*.exe; *.dll; *.scr; etc) and compiled resource libraries (*.res, *.mui). Resource Hacker also provides many options for compiling and decompiling resources from the command-line.

     

    http://www.angusj.com/resourcehacker/

     

    rh_dlg_ctrl.thumb.png.ff0726c0403c272246ef56a0a8472093.png

     

    Download: 

    http://www.angusj.com/resourcehacker/reshacker_setup.exe

     

    • Like 9
    • Thanks 9

  12. Posted · Edited by angusj

    On 12/29/2020 at 5:34 AM, Anders Melander said:

    On top of that we have a lot of poorly documented code that was contributed by cowboys [*] which are apparently no longer interested in fixing their bugs.

    Anders, I strongly disagree with your cowboys comment. There were and are only a very few Graphics32 contributors with write permissions to the library. And all of those contributors made significant contributions. None fit your profile of "Rides into town, shooting right and left and then rides out of town leading a mess behind". Yes, most of us have left, presumably for different reasons. As I've stated elsewhere, I finally left Graphics32 when I realised that it had reached the point that it needed to be completely rewritten, and even just trying to fix things (eg writing extensive documentation) was a waste of time.

  14. Posted · Edited by angusj
    grammar & clarification

    On 1/9/2021 at 7:13 AM, Anders Melander said:

     

    Turns out there's almost nothing gained from using that method. While the matrix setup (which runs only once) is slightly faster, the transformation matrix (which is used once per target pixel) is exactly the same and thus yields the same performance and result.

    Anders, I didn't claim that the Image32 projective transform algorithm was faster, but that it was more flexible.

    Projective transform require a set of 4 source coordinates and a set of 4 destination coordinates indicating source and destination quadrilaterals.

    While both algorithms obviously require the user to specify the destination quadrilateral, the Graphics32 algorithm simply uses the source image bounds as the source quadrilateral, whereas the Image32 algorithm allows the user to define a source quadrilateral too (which can be very useful).

     

    19 hours ago, c0d3r said:

    Do any of you plan to have your components to support 64-bit in near future?

    Both libraries support 64bit compiling. However, if you're referring to 64bpp (bits per pixel) images then neither library support this. Both libraries load and manipulate images using 32 bpp (hence the 32 in their names 😁), though images can still be saved to file using lower color resolutions.

     

    On 1/8/2021 at 9:49 PM, Anders Melander said:

    It's all about avoiding compromises that would hurt performance

    But too many options just makes a library unhelpfully complicated for the average user.

     

  15. Posted · Edited by angusj

    20 hours ago, Rollo62 said:

    Thanks, thats a fair goal, but wouldn't it have been better to start with a cleaned up GR32 branch then ?

     

    That was indeed my initial intention. However, the more I tried to remove what I considered obsolete code, the more problems I encountered as I found what seemed obsolete was still used by other parts of the library. For example TCustomBitmap32 has 14 different Line methods, 7 LineTo methods, 7 HorzLine methods and 7 VertLine methods. That really is excessive and IMHO should be removed and intead use the separate and much more flexible polygon renderer (in GR32_VPR).

     

    19 hours ago, Anders Melander said:

    Image32

    Image32 is more of a monolithic design - one class does everything.

    I'd disagree with Anders on that, though of course I could still greatly improve Image32's design.

     

    It's fair to say the TImage32 class that's at the core of my Image32 library does have a large number of methods related to loading and saving images, as well as a number of image manipulation methods (including hue adjustment and basic afine transformations - scale, rotate etc). But most of these methods (or similar) also appear in Graphic32's TBitmap32 class. IMHO Graphic32's TBitmap32 is much more monolithic, as it containing a whole host of line rendering methods (as mentioned above) and text (polygon) rendering methods too. These really shouldn't be there, as these operations are much better served by the functions found in Graphic32's Gr32_VPR unit. Further, TBitmap32's line rendering methods will only draw 1 pixel wide lines which is extremely limiting. So I would argue that my TImage32 class is much less monolithic than the TBitmap32 class.

     

    19 hours ago, Anders Melander said:

    I would be very surprised if Angus didn't use the techniques used in Graphics32 as inspiration. Although I know he loves to write things from scratch I doubt that he doesn't use Graphics32 as a reference. Anyway, I can only guess.

    Almost none of my Image32 libray uses code from Graphics32. The excepion to that is a small amount of code in my Image32_Draw unit where the polygon renderer uses a memory allocation technique I copied from Mattias Andersson's Gr32_VPR unit. (When comparing Image32 rendering performance with Graphics32, I couldn't figure out how Mattias' rendering was so efficient.) Nevertheless my polygon renderer is based on https://nothings.org/gamedev/rasterize , though it still isn't quite as fast as Mattias' renderer. I did also briefly copy Projective Transform code from the Graphics32 library (with attribution), but that was replaced some time ago with my own code adapted from some more flexible JavaScript code I found here https://math.stackexchange.com/a/339033/384709 (again with attribution).

     

     

    With regard to which library is better, I suggest if you're familiar with Graphics32, or if polygon rendering performance is critical, then use Graphics32. However, Image32 does offer several benefits over Graphics32. It's a much simpler library to learn and use IMHO and it contains better cross-platform support with both Lazarus and FMX options.

     

     

    • Like 2
    • Thanks 2
×