Recent

Author Topic: New version of BGRABitmap  (Read 198788 times)

bobby100

  • New Member
  • *
  • Posts: 18
Re: New version of BGRABitmap
« Reply #585 on: July 28, 2020, 10:56:11 pm »
Hi, I have a problem with BCSVGViewer and my svg file - the text is rendered in huge proportions.
The SVG file is created with Inkscape and it load fine in other programs. In problem.jpg (in attachment) you can see some black lines - it is part of letter W.
I just load the svg from a file, no processing is done.

circular

  • Hero Member
  • *****
  • Posts: 3440
    • Personal webpage
Re: New version of BGRABitmap
« Reply #586 on: July 28, 2020, 11:23:50 pm »
Conscience is the debugger of the mind

circular

  • Hero Member
  • *****
  • Posts: 3440
    • Personal webpage
Re: New version of BGRABitmap
« Reply #587 on: August 02, 2020, 10:21:29 am »
New version of BGRABitmap v11.2.1 with quick fixes
https://github.com/bgrabitmap/bgrabitmap/releases

Compilation fixes
- fix resource path for tests on MacOS
- fix DrawPart overload (to compile BGRAControls on Linux)
- move BGLControls to separate directory to fix compilation on Lazarus 2.0.10

Runtime fix
- avoid undefined size when deserializing image from empty stream

Utility functions
- more utility functions for TBGRAMemOriginalStorage (Empty, EnumerateFiles, FileExists)
- add TAffineBox.Inflate
- gamma correction option for Contour filter
- more functions for TGrayscaleMask
- add TRectF.Include(TPointF)
Conscience is the debugger of the mind

lainz

  • Hero Member
  • *****
  • Posts: 3699
  • Leandro Diaz
Re: New version of BGRABitmap
« Reply #588 on: August 02, 2020, 10:40:35 pm »
Thankyou  :) ;)

circular

  • Hero Member
  • *****
  • Posts: 3440
    • Personal webpage
Re: New version of BGRABitmap
« Reply #589 on: August 08, 2020, 04:55:15 pm »
You're welcome. Yet another version with more fixes (including the bug in SVG mentioned by bobby100).

BGRABitmap v11.2.2
https://github.com/bgrabitmap/bgrabitmap/releases

New features
- add FillMask function for all image types
- add TBGRAMemoryStreamBitmap type to use memory stream as placeholder for pixel data (in BGRADefaultBitmap unit)
- add stream access in multifile types (if available)
- add RectF(TRect) function

Bug fixes
- TGrayscaleMask: add missing overload keyword
- TBidiTextLayout: fix overflowing paragraph bounds in text layout
- BGRAText: fix multithreading text errors by not reusing the same TBitmap instance in BGRAText
- Canvas2d: render only visible text when using non vectorial text renderer (avoids memory error with very big text)
- BGRASVG: fix bug in unit conversions
Conscience is the debugger of the mind

lainz

  • Hero Member
  • *****
  • Posts: 3699
  • Leandro Diaz
Re: New version of BGRABitmap
« Reply #590 on: August 08, 2020, 05:00:00 pm »
Thanks =)

You had the opportunity to try it in android?

circular

  • Hero Member
  • *****
  • Posts: 3440
    • Personal webpage
Re: New version of BGRABitmap
« Reply #591 on: August 08, 2020, 05:10:45 pm »
Not yet.  :'(

I am going to install it on MacOS and see what happens.
Conscience is the debugger of the mind

lainz

  • Hero Member
  • *****
  • Posts: 3699
  • Leandro Diaz
Re: New version of BGRABitmap
« Reply #592 on: August 09, 2020, 05:54:02 pm »
Ok. I was looking that you're interested in the ZenGL thread, that's great too, it has or had Android support as well. As well iOS, so maybe you can try on iPhone as well.

circular

  • Hero Member
  • *****
  • Posts: 3440
    • Personal webpage
Re: New version of BGRABitmap
« Reply #593 on: August 09, 2020, 05:59:14 pm »
Yeah that could be great. Though there seem to be some compatibility issue with 64 bits.
Conscience is the debugger of the mind

lainz

  • Hero Member
  • *****
  • Posts: 3699
  • Leandro Diaz
Re: New version of BGRABitmap
« Reply #594 on: August 09, 2020, 06:06:48 pm »
Ok, yes the transition from 32 to 64. Did you live the transition from 16 to 32? I think I've used only 32 bit apps, and some 16 on Windows 95.

circular

  • Hero Member
  • *****
  • Posts: 3440
    • Personal webpage
Re: New version of BGRABitmap
« Reply #595 on: August 09, 2020, 10:00:46 pm »
Yes, I've used PCs when they were 16-bits. The transition towards 32-bit did go rather easily as there was much compatibility. In fact, the computer booted in 16-bit and then programs could go to 32-bit if they wanted to. So I don't remember any transition issue personally.

I remember that when programming in Turbo Pascal in DOS, I was using the 16-bit mode. The main restriction for me was memory, either allocating memory or video memory. I remember rarely adding 32-bit assembler instructions by adding $66 byte before assembler instructions.

Code: [Select]
db $66; mov ax, bxwould in fact be
Code: [Select]
mov eax, ebx
That was without actually switching entirely to 32-bit mode. I did not know how to do that. Some games would do, generally using DOS4GW. You could see a few lines written in the DOS terminal when launching those games before they would switch to graphics mode:
Code: [Select]
DOS/4GW Protected Mode Run-time   Version 1.97
Copyright (c) Rational Systems, Inc. 1990-1994

Windows would also use 32-bit mode. So there was a 32-bit version of Pascal. Things were quite similar in fact, except that pointers would now be just one number. In 16-bit mode, you had two numbers: a segment and a 16-bit offset. The actual address was segment*16 + offset. So you needed sometimes to take that into consideration.

Programming under Windows was a bit frustrating to me in the beginning because it was not obvious to switch to fullscreen graphics and you had to write CreateWindows and similar calls to the API to make the interface. Things became better when Delphi arrived.

This 32-bit mode was "protected" as DOS4GW banner says. It means that you could not access any memory and so you would not crash your computer when you messed up with a pointer. Back then in 16-bit, you could have to press Ctrl-Alt-Del to reboot quite often until you got your pointers right. Or even turn off and on the computer manually.

So 32-bit was not just about bigger numbers, it made everything easier and safer. And at the same time, 16-bit programs would still run. Either in a console under Windows or by staying in the real DOS and running the game from there using the command line. In protected mode though, you can not change system memory if you want to.

The real incompatibilities for 16-bit came when Windows would replace completely DOS. Some DOS games would still work fine under Windows, but not all of them. It felt a bit awkward that even fullscreen games would need to be programmed for Windows in order to function properly, even though they would not use the GUI.
« Last Edit: August 09, 2020, 10:06:55 pm by circular »
Conscience is the debugger of the mind

lainz

  • Hero Member
  • *****
  • Posts: 3699
  • Leandro Diaz
Re: New version of BGRABitmap
« Reply #596 on: August 10, 2020, 01:33:04 am »
Interesting.

I remember just playing 16 bit games, with this console
https://en.wikipedia.org/wiki/Sega_Genesis#/media/File:Sega-Genesis-Mk2-6button.jpg

I remember my fingers getting damaged with that small controller.

winni

  • Hero Member
  • *****
  • Posts: 1762
Re: New version of BGRABitmap
« Reply #597 on: August 10, 2020, 01:56:42 am »
Hi!

I had the biggest problem with the missdesign of the Intel 386: The maximum data chunk was 64k. So you were allways working with pointer lists  to handle bigger amounts of data (pictures).

That was a big disadvantage compared to the Atari ST with Motorola 68000 where you could  allocate a picture in one go - if you had enough memory.

Great help was a guy from Finnland who wrote the unit HugeArray. With the help of it you could allocate as much memory as was available for Delphi16.

Yes, 32 bits were a big progress, but Win95 was awful slow on your old hardware. You had to buy some new.

Winni


circular

  • Hero Member
  • *****
  • Posts: 3440
    • Personal webpage
Re: New version of BGRABitmap
« Reply #598 on: August 10, 2020, 09:48:30 am »
I had the biggest problem with the missdesign of the Intel 386: The maximum data chunk was 64k. So you were allways working with pointer lists  to handle bigger amounts of data (pictures).
I suppose you mean 8086. Indeed using the same segment you would have only 64k.

Quote
Yes, 32 bits were a big progress, but Win95 was awful slow on your old hardware. You had to buy some new.
Indeed, at the time of Win95, you needed to have some time before it would boot up. Or try to optimize the system by deactivating services.
« Last Edit: September 11, 2020, 01:33:30 am by circular »
Conscience is the debugger of the mind

bobby100

  • New Member
  • *
  • Posts: 18
Re: New version of BGRABitmap
« Reply #599 on: September 10, 2020, 05:11:42 pm »
In Lazarus/Online Package Manager - it is still showing 11.2.1.0 as the latest version.

 

TinyPortal © 2005-2018