I have now such picture-- is it like DOS one?The palette color values were sent via the Port. So it means that they are from 0 to 63 instead of 0 to 255.
What is DOS look?
(Arrow keys work OK, but colors...)
Nice @Mr.MadguyIt's allocated in OnCreate, freed in OnDestroy and it's "local" form variable. It shouldn't be memory leak.
One memory leak though: the Header is allocated each time.
Note that TLazIntfImage could be optimized by using a palette.How can I do it? TLazIntfImage doesn't provide direct access to palette and direct TRawImage usage doesn't work for me (see CODE6). Once I set RawImageDesc.PaletteColorCount = 256, screen just goes blank.
Can you give me your times with this version?CODE1: 32ms
Does not seem possible to me that BGRA would be so slow. And neither that accessing bitmap pixels would be so fast. For the DIB too, I find the timing very low.Oh, of course 0.48ms
Good. Posted your version to github!Thanks. I will suggest a fork if I can make the TLazIntfImage with palette work.
(for next update, pls format the unit1.pas - indents should be 2 spaces, no tab's)
Where is this final version?This and RunError(204) at termination. Mine version works properly.
By the way, what was the display error with Code5 with my version on your computer? Can you provide a screenshot?
About TImage, that does not provide the actual drawing times, at least on MacOS and Linux.
This and RunError(204) at termination. Mine version works properly.Hmmm, though your version did not work on my computer.
And what was wrong with my version? Blank screen? May be I should set Alpha to $ff?This and RunError(204) at termination. Mine version works properly.Hmmm, though your version did not work on my computer.
Thanks for the screenshot. It seems there is a problem of alignment, maybe because without an alpha channel, it makes 3 bytes long pixels.
Here is a pull request to hopefully fix that using RGBA format. It is a tiny bit slower by 0.5 ms on my computer.
https://github.com/Alexey-T/Voxel_demo_Lazarus/pull/1
Yes, I welcome pull-req so I don't need to merge by hands.
Good, tkx. If you can 'isolate' that pit of doom, in some small win32 demo- it may help to fix it...
We can 'isolate' the slowdown on some demo? I didn't read code detailed.
Looks like there is some difference between calling UpdateImage inside and outside of OnPaint. Outside is 4x slower for me. It can be fixed via adding "and not(defined(CODE2))" to OnTimer event.
circular
(Run inside IDE)
______________________________________________________________________________
| CPU : 3 GHz Intel Core i5 6 cores |
| OS : MacOS Catalina (64bit) |
| FPC : 3.2.0 |
| LAZARUS : 2.0.10 |
|____________________________________________________________________________|
| METHOD | CODE 1 | CODE 2 | CODE 3 | CODE 4 | CODE 5 | CODE 6 |
|=========|==========|==========|==========|==========|==========|===========|
| Debug | 63 - 112 | 140 - 143| N/A | 1 - 2 | 2 - 3 | ? |
|---------|----------|----------|----------|----------|----------|-----------|
| Release | 21 - 75 | 79 - 81 | N/A | 1 - 2 | 1 - 2 | ? |
|----------------------------------------------------------------------------|
Note that drawing outside of OnPaint event is not possible on MacOS.
EDIT: I tried running BZScene on MacOS but it doesn't compile. The unit BZSystem uses linux and users units but they are not found.
Maybe someone will make pull-req for CODE7?
Seems like CODE7 is even faster than CODE3, because it doesn't have any bitmap copy operations at all. But in case of Panel1.Canvas there shoudn't be difference, because it requires one bitmap copy anyway.
HiI've said about both cases. Yeah, CODE7 isn't better in case of TPanel, but it is in case of TImage. And CODE6 doesn't work properly, because if I enable palette, screen just goes blank. Palette is disabled and without it red color is used.
I take a look to your code
CODE7 is a little bit less efficient rather than CODE3
In CODE3 the "Bitmap" is direclty displayed on Canvas and is more efficient than CODE7.
In CODE7 you don't see the "copy" because the display is managing internally by the TImage
Your CODE6 is bugged, the landscape is in a red shade
Note in the code from repo we have deleted the TImage Bitmap is directly displayed on Panel.Canvas
Yeah, CODE7 isn't better in case of TPanel, but it is in case of TImage.I guess you're not getting it. TImage rendering is drawn in another event, so the actual drawing on the screen in not taken into account. Hence you get a lower time, but it does not count everything.
I guess you're not getting it. TImage rendering is drawn in another event, so the actual drawing on the screen in not taken into account. Hence you get a lower time, but it does not count everything.I understand it. I've already said, that TImage does one bitmap copy internally, that my program doesn't count. And TPanel would require this step to be done manually anyway, so using DIB section is pointless, except may be it has more optimal internal implementation, than pure DIB. I just tried to say, that overall one bitmap copy is faster than two in case of TImage.
That's a good question. I suppose dependencies do not depend on the build mode either.I don't know, how to do it. Hardcoding search paths isn't good idea. And there is no easy way to do it, as for example add "-PLCL -PBGRABitmap" options to build mode. So here it is. With little optimization for ModeY - DosMemPut should be faster. There is even faster way - to access memory directly. But it requires asm code, I guess, as it's the only way to deal with selector in 32bit mode.
{$ifdef lcl}{$endif}Uses Classes, SysUtils{$ifdef lcl}, Forms, BgraBitmap, Controls, Graphics, Dialogs{$endif};
You could tryI use {$IFDEF go32v2} and it completely removes whole Windows code. Problem is - it's IDE packages, that refuse to compile.Code: [Select]{$ifdef lcl}{$endif}
use it in your uses definition to bring in things like forms and bgrabitmap ie.Code: [Select]Uses Classes, SysUtils{$ifdef lcl}, Forms, BgraBitmap, Controls, Graphics, Dialogs{$endif};
I have not tested but it may help