2007/8/29, Tomas Hajny <[EMAIL PROTECTED]>:
>
> I think that I know the way to
> > not
> > implement sdlcrt and use the current crt unit.
> > But it needs thread and pipe, I never used them, but it won't be
> > complicated.
>
> I guess that it might be useful to discuss your idea regarding cooperat
Evgeniy Ivanov wrote:
> 2007/8/26, Jonas Maebe <[EMAIL PROTECTED]>:
>>
>> Done. You can see it at
>> http://svn.freepascal.org/svn/fpc/trunk/packages/extra/graph/
>>
>> Please base your further development on the version of sdlgraph.pas
>> you can find there, as I made some minor changes (added mis
2007/8/26, Jonas Maebe <[EMAIL PROTECTED]>:
>
> Done. You can see it at
> http://svn.freepascal.org/svn/fpc/trunk/packages/extra/graph/
>
> Please base your further development on the version of sdlgraph.pas
> you can find there, as I made some minor changes (added missing
> InternalDriverName cons
On 26 Aug 2007, at 13:54, Jonas Maebe wrote:
May you add it to your cvs (to the fpc project)?
Done. You can see it at
http://svn.freepascal.org/svn/fpc/trunk/packages/extra/graph/
Please base your further development on the version of sdlgraph.pas
you can find there, as I made some minor c
On 23 Aug 2007, at 17:42, Evgeniy Ivanov wrote:
I've changed licence (the top of the file) as you've told. And
fixed speed
of Bar3d and other routines (added timer for flipping - not best,
but it
works). You may test it if you want :)
http://itmo.vingrad.ru/files/sdlgraph/sdlgraph.pas
htt
Hi!
I've changed licence (the top of the file) as you've told. And fixed speed
of Bar3d and other routines (added timer for flipping - not best, but it
works). You may test it if you want :)
http://itmo.vingrad.ru/files/sdlgraph/sdlgraph.pas
http://itmo.vingrad.ru/files/sdlgraph/test.pas
http:/
isn't that the basis
for any software implemented graphics routine: drawing pixels ?
No.
That is what the graphic card hardware does. The software requests same
to do graphic primitives (like draw rectangle, draw line, copy
rectangle). As the main bottleneck is the interface between the C
It's asm, it should be faster than pascal code.
I don't think that this makes a noticeable difference.
IMHO the main speed difference is the count of calls to graphic
primitives that are done internally in the display card hardware (such
as draw pixel, draw line, draw rectangle, draw circle
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
> the flipping could/should be done from a
> separate thread,
>
What should I use: ThreadVar from fpc or SDL_Thread? Both are
cross-platform.
--
E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
>
>
> On 22 Aug 2007, at 20:59, Evgeniy Ivanov wrote:
>
> I guess the problem is that you blit the entire screen after every
> drawing operation. It will be faster when drawing lines at a time,
> but still slow. In theory, the flipping could/should be don
On Wednesday 22 August 2007 19:18, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> >> Why is calling via a procvar very much slower than a normal call ?
> >> It's just an extra memory fetch (hopefully in cache) ?
> >
> > Jonas meant that each pixel is drawn separately. The procvar is not
> > t
On 22 Aug 2007, at 20:59, Evgeniy Ivanov wrote:
Hm... I've tried such thing:
procedure sdlgraph_HLine(x,x2,y: smallint);
begin
SDL_DrawLine(screen,X,y,x2,y,255);
SDL_Flip(screen);
end;
The same. I will try to find the true way, but I'm not sure that it
can be
without locking overhead. I
On 22 Aug 2007, at 21:18, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Why is calling via a procvar very much slower than a normal
call ? It's
just an extra memory fetch (hopefully in cache) ?
Jonas meant that each pixel is drawn separately. The procvar is
not the issue.
Before me
Michael Van Canneyt wrote:
>> Why is calling via a procvar very much slower than a normal call ? It's
>> just an extra memory fetch (hopefully in cache) ?
>
> Jonas meant that each pixel is drawn separately. The procvar is not the issue.
Before me going too far in unknown territory, but isn't tha
On Wed, 22 Aug 2007, Micha Nelissen wrote:
> Jonas Maebe wrote:
> > No, it is still slow. You indeed do not have locking overhead, but you
> > are still calling nonBuf_DirectPutPixel via a procvar for each pixel
> > which has to be drawn (from hlinedefault). That is still very slow.
>
> Why is
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
>
>
> On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote:
>
> > 2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
> >>
> >>
> >> It is because you do not redirect the line drawing directly to SDL,
> >> but instead use the default line drawing routines. Those are in
Jonas Maebe wrote:
> No, it is still slow. You indeed do not have locking overhead, but you
> are still calling nonBuf_DirectPutPixel via a procvar for each pixel
> which has to be drawn (from hlinedefault). That is still very slow.
Why is calling via a procvar very much slower than a normal call
On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote:
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
It is because you do not redirect the line drawing directly to SDL,
but instead use the default line drawing routines. Those are indeed
very slow, because they call a procedural variable (directputpix
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
>
>
> It is because you do not redirect the line drawing directly to SDL,
> but instead use the default line drawing routines. Those are indeed
> very slow, because they call a procedural variable (directputpixel)
> for each pixel which has to be drawn).
On 22 Aug 2007, at 12:26, Evgeniy Ivanov wrote:
Bar3D is indeed one of the few routines which cannot be hooked
currently. As long as you hook the line drawing it should be plenty
fast though.
No, I tryed. It is in the test.pas. It works very very slow.
It is because you do not redirect the
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
>
>
> Congratulations! Just one note: please do not make it GPL, because
> that would mean anyone using that unit would have to make their
> program also GPL. Instead, please change the text at the top to
> something like this:
>
> ***
> Copyright (c
On 19 Aug 2007, at 23:28, Evgeniy Ivanov wrote:
Hi! I did it. And working with its implementation.
Congratulations! Just one note: please do not make it GPL, because
that would mean anyone using that unit would have to make their
program also GPL. Instead, please change the text at the to
Hi! I did it. And working with its implementation.
I need to do some hooks to speed up the module (Bar3d). But I have network
problems and my dial up doesn't me allow to google much (I don't know how to
hook functions/procedures).
Also readln function need to be hooked too (It works when alt+tab to
23 matches
Mail list logo
