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
Hi! I have worked a bit with implementation. But just a bit... I'm not able
to do anything before middle of June, but then I will do it. So, please,
keep it for me.
--
E.I.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasca
> > > Any comments are welcome.
> >
> > I'll be doing the SDL translation. (there already is some in contrib/sdl)
> >
> > What FPC version are you going to target? 1.0.x, 1.9.x or both?
>
> Actually, I was simply going to build an interface on top of
> SDL4Freepascal that provides GRAPH function c
> > I have had an interest in creating an sdlgraph unit for a while, and have
> > been planning for a few months. I didn't really know that there was other
> > talk about this, although I suspected it. So today, I looked around and
> > saw some interest, and this listed as a project.
> >
> > I am
> I have had an interest in creating an sdlgraph unit for a while, and have
> been planning for a few months. I didn't really know that there was other
> talk about this, although I suspected it. So today, I looked around and
> saw some interest, and this listed as a project.
>
> I am starting t
I have had an interest in creating an sdlgraph unit for a while, and have
been planning for a few months. I didn't really know that there was other
talk about this, although I suspected it. So today, I looked around and
saw some interest, and this listed as a project.
I am starting this project
28 matches
Mail list logo
