Anders Melander

You can't do the fade-in from the constructor because the form isn't visible at that point. So: Create the form. Set MasterAlpha=0 Show the form Fade in I suggest you simply override ShowScreen: procedure TGameBaseScreen.ShowScreen; begin ScreenImg.Bitmap.MasterAlpha := 0; inherited; // Form is made visible here FadeIn; end; And there was an endless loop in the Fade in method. This one works: procedure TGameBaseScreen.FadeIn; var EndTickCount: Cardinal; TickCount: Cardinal; Progress: Integer; Alpha, LastAlpha: integer; const MAX_TIME = 1000; // mS begin ScreenImg.Bitmap.DrawMode := dmBlend; // So MasterAlpha is used to draw the bitmap TickCount := GetTickCount; EndTickCount := TickCount + MAX_TIME; LastAlpha := -1; while (TickCount <= EndTickCount) do begin Progress := Min(TickCount - (EndTickCount - MAX_TIME), MAX_TIME); Alpha := MulDiv(255, Progress, MAX_TIME); if (Alpha <> LastAlpha) then begin ScreenImg.Bitmap.MasterAlpha := Alpha; ScreenImg.Update; LastAlpha := Alpha; end else Sleep(1); TickCount := GetTickCount; end; ScreenImg.Bitmap.MasterAlpha := 255; end;

Get a dog.

By bad; Change this: Progress := Max(TickCount - EndTickCount - MAX_TIME, MAX_TIME); to this: Progress := Max(TickCount - (EndTickCount - MAX_TIME), MAX_TIME); EndTickCount = StartTickCount + MAX_TIME <=> StartTickCount = EndTickCount - MAX_TIME so Elapsed time = TickCount - StartTickCount <=> Elapsed time = TickCount - (EndTickCount - MAX_TIME)

Something like this: procedure TGameBaseScreen.FadeIn; var EndTickCount: Cardinal; TickCount: Cardinal; Progress: Integer; Alpha, LastAlpha: integer; const MAX_TIME = 1000; // mS begin ScreenImg.Bitmap.DrawMode := dmBlend; // So MasterAlpha is used to draw the bitmap TickCount := GetTickCount; EndTickCount := TickCount + MAX_TIME; LastAlpha := -1; while (TickCount <= EndTickCount) do begin Progress := Max(TickCount - EndTickCount - MAX_TIME, MAX_TIME); Alpha := MulDiv(255, Progress, MAX_TIME); if (Alpha = LastAlpha) then begin Sleep(1); continue; end; ScreenImg.Bitmap.MasterAlpha := Alpha; ScreenImg.Update; LastAlpha := Alpha; TickCount := GetTickCount; end; ScreenImg.Bitmap.MasterAlpha := 255; Application.ProcessMessages; end;

True. Luckily nobody does that 🙂 Here's the bitmap resized with TAffineTransformation.Scale(0.1, 0.1) and TKernelResampler with TCubicKernel: So pretty much as bad as yours: But anyway, I think we can conclude that the problem isn't with the cubic filter itself but more with how it's applied.

So: A problem in your implementation - or rather a consequence of the way you have chosen to implement resizing images. Or did I misunderstand what you just wrote?

It looks to me as if there's a problem in your implementation... Here's what I get with a selection of Graphics32 kernels: Box Cubic Linear Cosine Spline Hermite Yes, there are differences but IMO they all look good. Even Spline which shouldn't really be used for down-sampling. Ignore the black line at the top of each image; It's caused by a bug in Firefox's clipboard handling of 32-bit RGBA bitmaps: https://bugzilla.mozilla.org/show_bug.cgi?id=1866655 https://forums.getpaint.net/topic/124628-1-px-line-on-top-of-every-image-pasted-into-firefox-from-paintnet/ https://github.com/graphics32/graphics32/issues/257

FWIW, I agree with @Khorkhe; The documentation for the Equal operator appears to be wrong.

Yes, you are going to use IOTA but you really need to read up on this topic until you understand it. The basic steps you must take is something like this (pseudo code; don't try to compile it): // Open the file in the IDE (BorlandIDEServices as IOTAActionServices).OpenFile('my_unit.pas'); // Get the file "module" var Module: IOTAModule := (BorlandIDEServices as IOTAModuleServices).FindModule('my_unit.pas'); // Iterate the module files for var i := 0 to Module.GetModuleFileCount-1 do begin // Get a module file editor var Editor: IOTASourceEditor; if not Supports(Module.GetModuleFileEditor(i), IOTASourceEditor, Editor) then continue; // Make the editor visible Editor.Show // Get an editor view if (Editor.GetEditViewCount = 0) then continue; var EditView: IOTAEditView := Editor.GetEditView(0); // Set the caret position var Position: TOTAEditPos; Position.Col := 1; Position.Line := ... EditView.SetCursorPos(Position); // Scroll to make caret visible and 15 lines down from the top Position.Line := Max(1, Position.Line-15); SetView.SetTopPos(Position); end;

There's one in DWScript: https://github.com/EricGrange/DWScript/blob/c3a26f0e68a5010767681ea1f0cd49726cd4af5d/Source/dwsUtils.pas#L3169 I haven't used it though but knowing Eric, it's probably both fast and well tested. Pity about the 3-space indents though; Very French 🙂 Other than that: https://github.com/search?q=lang%3Apascal+iso8601&amp;type=code

Please google color quantization and dithering. Because that's exactly what you are doing.

You probably don't have the privileges to query all processes. Try running the application as administrator or elevate privileges from within your application. https://stackoverflow.com/questions/1435911/c-process-checking https://stackoverflow.com/questions/34511670/sedebugprivilege-and-openprocess-on-another-account

Sure, I could have sugar coated it better. The point was really that when the expectations turns out not to match reality then one should question the expectations first.

- Once you think about it.

Yes, that's normal. Right click in the Events pane, select Properties and then unselect Process, Thread and Module messages. Unless you really need the information it's just noise.

Is it a known problem that the VCL misinterprets the valid range of TScrollBar's PageSize and Max properties? TScrollBar enforces the rule that PageSize must be <= Max but Windows requires that PageSize be <= Max-Min+1... This means that if one sets PageSize=Max it is still possible to move the scrollbar +/-1 unit. One work around seems to be to set Min to 1 - because TScrollBar forgets to take Min into account when validating PageSize 🤦‍♂️ https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo

I think the MS documentation, while a bit terse, is clear enough; It specifies how the different properties and their limits relate to each other. The Delphi documentation though is severely lacking. If they had tried to document it properly they would probably have discovered that they got it wrong.

Maybe you should think a bit more about that. Ideally until it is no longer a mystery. What possible reason could there be for that limit? The 16x16 default is a big clue...

BL.Location := FloatRect(x1, y1, x2, y2);

It doesn't; It uses the map file.

Okay. It would be so much easier if you actually read and answered the questions I have asked you. The position and size of the layer determines where the bitmap is drawn. Isn't that what you are seeing?

I have no idea what you mean

And what is the actual result?

Show us what you mean; We still can't read your mind. What does it look like? What do you want it to look like?

My bad. That should have been: BL.Location := FloatRect(ImgView.Bitmap.Width/4, ImgView.Bitmap.Height/4, ImgView.Bitmap.Width/4*3, ImgView.Bitmap.Height/4*3); as a rect is (x1,y1, x2,y2)