Re: Found serious bug in win32 interface #2

Andrey Gusev wrote:
> * Luiz Americo Pereira Camara <luizmed <at> oi.com.br> [Thu, 31 Jan 2008 
> 01:16:58 -0300]:
>> Andrey Gusev wrote:
>> > * Mattias G&#228;rtner <nc-gaertnma <at> netcologne.de> [Wed, 30 Jan 2008
>> > 18:45:57 +0100]:
>> >> Zitat von Andrey Gusev <ag888 <at> rambler.ru>:
>> >>
>> >> > --- interfaces/win32/win32callback.inc (revision 13905)
>> >> > +++ interfaces/win32/win32callback.inc (working copy)
>> >> >  @@ -504,7 +504,7 @@
>> >> > if (ControlDC = 0) or not needParentPaint then
>> >> >  begin
>> >> >  DCIndex := Windows.SaveDC(PaintMsg.DC);
>> >> >  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
>> >> > + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
>> >> >  {$ifdef DEBUG_DOUBLEBUFFER}
>> >> >  Windows.GetClipBox(PaintMsg.DC, ClipBox);
>> >> > DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
>> >> > with
>> >> > clipping rect (',
>> >> >
>> >> > I can provide application that's confirm my rightfulness.
>> >> > But i don't wish to do it, until all child-control negative 
> effects
>> >> will
>> >> > debugged (by me), it need to LazReport designer functionality.
>> >> > If wished, try to place oversized TPaintBox on TScrollBox and try
>> it
>> >> to

Re: Wider use case for gamepack ?

> 
> First of all, I never wanted to bash your components and I think the CCR is a good place for them. I just don't
think that it should be shipped with lazarus. And you have every right to be proud of your work.
Fair enough. I didn't think it was being bashed, just that I needed to 
explain their purpose and features.

>> 2) As a result of 1, things like image scaling is already there - just 
>> use the same calls you would have used before to manipulate the sprite 
>> in ram before blitting.
> And as a result of 1 blending misses.
I'm not sure what you mean by this. This is a toolkit for 2D games, like
pacman or animated scenes in your app. Tilebased games etc. work fine,
why do you need blending in this environment?
> 
> Sounds good, only that the CPU instead of the GPU is doing the graphics work is so old school. Btw how do you
asure that a games runs at the same speed on different machines if you don't measure/have a framerate?
Not everybody HAS a gpu. Even if everybody did, that's not my target 
audience or developer.
I use a ttimer to handle all the screen updates, on each timer the 
user's character sprite is moved as per his request, ditto the game 
character sprites - and finally we flip the buffers - so in a sense 
there IS a fixed framerate - since there is a fixed number of screen 
updates per second- but it can be intercepted by other events if needed. 
In the openGL type idea though where you repaint as often as possible - 
there isn't really a framerate.
> 
>> 4) Lazarus native event handling - e.g. there is NO need for me to 
>> handle key/mouse events- lazarus does, and any device that works with 
>> lazarus toolkit you're using on the OS you are using will ALSO work.
> That's what I am using, too, at the moment and I am not really impressed. You can get mouse and more or less key

Re: I have a dream

En/na Marc Weustink ha escrit:

> For scrolling after a line is added, I don't know. Personally I hate it 
> when a memo gets updated and I want to read the contents the same time.

Well, there could be a property that controls this behavior.
Or scroll to the bottom only if the last line is visible (assuming that 
if it isn't visible you've manually scrolled to read old messages).
That's what, e.g., kconsole does, and I manually replicated it with a 
TSynMemo (I'm not sure it'll work with a plain TMemo), something like:

function TMyForm.AtBottom:boolean;
begin
   Result:=SMemo.TopLine>Smemo.Lines.Count-Smemo.LinesInWindow;
end;

procedure TMyForm.ScrollToBottom;
begin
   SMemo.TopLine:=SMemo.Lines.Count-SMemo.LinesInWindow+1;
end;

procedure TMyForm.test;
var autolast:boolean;
     i:integer;
begin
    autolast:=AtBottom;
    SMemo.lines.beginupdate;
    for i:=1 to 10 do SMemo.lines.append(IntToStr(i));
    SMemo.lines.endupdate;
    if autolast then ScrollToBottom;

Perl-script in lazreport documentation

Hi all,

Is this file: lazarus/components/lazreport/doc/cvs2cl.pl really
necessary? Wasn't it used once and can it be removed now?

Joost

Lord Satan <reimgrab <at> web.de>

Re: Wider use case for gamepack ?

On Fri, 01 Feb 2008 08:52:12 +0200
"A.J. Venter" <aj <at> outkastsolutions.co.za> wrote:

> I'm not sure what you mean by this. This is a toolkit for 2D games, like
> pacman or animated scenes in your app. Tilebased games etc. work fine,
> why do you need blending in this environment?
Special FX like particle systems, shots, etc. If you want to see what difference hw acceleration makes,
take a look at chromium B.S.U. It is a nice, old 2D shooter and runs on any OpenGL card with more than 4MB RAM.
Now imagine what you can do with nowadays cards.

> Okay I get it - you like using the graphics card :)
Exactly. They are developed for doing nicer and faster graphics than CPU based rendering can achieve. If it
is 2D or 3D doesn't matter, your gfx card can do it faster than the CPU and you have your CPU left for gamelogic
and other stuff. And GPUs are standard in nowadays computers, so why not use them? It's easy enough and you
can do it with FPC and Lazarus.

> I am well aware that SDL <> OpenGL - that is why I compared my suite to 
> SDL and NOT to openGL. It isn't OpenGL nor is it meant to be. We already 
> HAVE an OpenGL that works wonderfully. This is a toolkit that's meant to 
> do the same work the SDL does when you do NOT use the OpenGL wrapper. I 
> also don't intend to add an OpenGL wrapper to gamepack since the 
> environment it's created for (Lazarus) already contains one. 
Lazarus does not contain an OpenGL wrapper. It offers a rendering context component and bindings to the
API, that's a difference.

> The reason 
> people use SDL with OpenGL is to tap into it's event handlers and such - 
> since they are no longer using it's graphics features. This wouldn't 
> make any sense in GamePack as gamepack is JUST the graphics 
> features(specifically it's THOSE graphics features that are NOT already 

Re: I have a dream

Luca Olivetti ha scritto:
> En/na Marc Weustink ha escrit:
> 
>> For scrolling after a line is added, I don't know. Personally I hate 
>> it when a memo gets updated and I want to read the contents the same 
>> time.
> 
> Well, there could be a property that controls this behavior.

That would be cool. If you must read all the text memo, having it 
scrolling is a big nuisance. If text memo are individual lines, and the 
last one is then most relevant, then manually scrolling goes from a 
nuisance to an impossibility. If you need both, you may add a button to 
set the property according the need of the moment. If the widget has the 
property, you save extra coding.

IMHO when you have visual components, you should have in code what the 
program wants to do, in the component properties how to show it, without 
need of extra code.

Giuliano

--

-- 
Giuliano Colla

Whenever people agree with me, I always feel I must be wrong (O. Wilde)

Re: Reports

I never used LazReport, but do use FastReport in some Delphi projects. 
The problem is that I would like to embed the report into a form. 
FastReport (LazReport) can't do this.
>> Could I have some idea as to what you are using to generate reports? 
>> Do you use internal report generators like :LazReport or external 
>> ones? LazReport seems to be an incomplete implementation of 
>> FreeReport which is also way outdated. Can some one please give me 
>> some hints.
> I use lazreport, it works good. Not perfect but ok.
> Iam underway to add frChart wit TAChart again.
> I think its an good start to make it more stable and add missing 
> features.
>
> best regards
> Christian

Re: Reports

Yes, It can, you must use TfrxPreview component to accomplish that.

http://www.fast-report.com/en/documentation/frx3progr/FastReport%20components%20review/TfrxPreview.htm

Leonardo M. Ramé
http://leonardorame.blogspot.com

Andreas Berger escribió:
> I never used LazReport, but do use FastReport in some Delphi projects. 
> The problem is that I would like to embed the report into a form. 
> FastReport (LazReport) can't do this.

Patch for reading LRE encoded BMP files

Hi *,

attached is a small patch which enables the LCL to read RLE encoded BMP 
files (successfully tested with some hundreds of small 8 bpp bitmaps, 4 
bpp should work as well).

Maybe somebody wants to commit this small patch :)

Diff is against Lazarus 0.9.24

Regards,

Sebastian

426a427
>     FIsRLE: Boolean;         // Is data RLE compressed?
432c433
<     procedure SetupRead(nPalette, nRowBits: Integer; ReadPalette: Boolean); virtual;
---
>     procedure SetupRead(nPalette, nRowBits: Integer; ReadPalette, AIsRLE: Boolean); virtual;
443a445
>     property IsRLE: Boolean read FIsRLE;
4411c4413
< procedure TLazReaderBMP.SetupRead(nPalette, nRowBits: Integer; ReadPalette: Boolean);
---
> procedure TLazReaderBMP.SetupRead(nPalette, nRowBits: Integer; ReadPalette, AIsRLE: Boolean);
4415a4418
>   FIsRLE := AIsRLE;
4443a4447,4449

Determining Crossplatform functions

Could anybody tell me if GetKeyState (and family) is cross platform or 
not ? - if not, is there a cross platform equivalent?

I know that it is ultimately connected to the winapi, but does fpc/laz 
redirect to suit platforms ?

On this note, is it at all possible to know which functions are 
x-platform and those not ? - ie if they pass thru 'this' unit/chain, 
they are ok, else not.

Thanks