Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2007-08

sdlgraph, pre-alpha

23 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Evgeniy Ivanov

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 console from which app was executed).
And I didn't implement color conversion from pascal constants to SDL colors. It's temporary 1 color (255).

If you remember we were talking about it in April (or May). I've created sf.net project, but it is in Processing Queue. So, here are the temp links:

Unit: http://itmo.vingrad.ru/files/sdlgraph.pas.txt

Example: http://itmo.vingrad.ru/files/test.pas.txt

Build script (you need to fix paths):
http://itmo.vingrad.ru/files/build.sh.txt

P.S. Thanks you for your answers about the graph modules and to authers of graph*.inc and *Go32* module - the code is very nice. Also I find some things I want you to have a look. They're in TODO of the sdlgraph.pas: {Graph inc and pp notes
TODO: in modes.inc 421-430. Maybe delete lowNewMode..highNewMode case? else section does the same! But with this section code it is easier to read the code
TODO: in modes.inc 181: Overloaded procedure initmode(var mode: TModeInfo); isn't used. I've looked only in modes.inc, so it may be my mistake

TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode = Init640x480x32k
}

Best Regards, E.I.

Reply by email

Jonas Maebe
to Evgeniy Ivanov
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 top to something like this:

***
Copyright (c) 2007 Evgeniy Ivanov

This file implements the sdl support for the graph unit

See the file COPYING.FPC, included in this distribution, for details about the copyright.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ***

You're of course free to also include your email address and a link to your website, like you have done in the version you put on the web.

Show quoted text 5 lines
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).

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.

Also readln function need to be hooked too (It works when alt+tab to console from which app was executed).

This will indeed be difficult. It's probably best to create a generic "wincrt"-like unit (sdlcrt?) which can be used together with the sdl graph unit. Full input/output support can also be added to it over time, similarly to how the regular crt unit also takes over all input/ output.

Show quoted text 11 lines
If you remember we were talking about it in April (or May). I've created sf.net project, but it is in Processing Queue. So, here are the temp links: Unit: http://itmo.vingrad.ru/files/sdlgraph.pas.txt Example: http://itmo.vingrad.ru/files/test.pas.txt Build script (you need to fix paths): http://itmo.vingrad.ru/files/build.sh.txt

Very nice!

P.S. Thanks you for your answers about the graph modules and to authers of graph*.inc and *Go32* module - the code is very nice.

Carl will be happy to hear this :)

Show quoted text 8 lines
Also I find some things I want you to have a look. They're in TODO of the sdlgraph.pas: {Graph inc and pp notes TODO: in modes.inc 421-430. Maybe delete lowNewMode..highNewMode case? else section does the same! But with this section code it is easier to read the code

No, it doesn't do the same: the lowNewMode..highNewMode case uses IntcurrentNewDriver, while the else case uses IntcurrentDriver. It's to transparently support both the old and new mode selection logic.

TODO: in modes.inc 181: Overloaded procedure initmode(var mode: TModeInfo); isn't used. I've looked only in modes.inc, so it may be my mistake

It is used by all platform-specific graph units (also by your sdlgraph unit) to initialise a new mode.

TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode = Init640x480x32k }

Fixed, thanks.

Jonas

Reply by email

Evgeniy Ivanov
to Jonas Maebe

2007/8/22, Jonas Maebe :

Show quoted text 22 lines
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) 2007 Evgeniy Ivanov This file implements the sdl support for the graph unit See the file COPYING.FPC, included in this distribution, for details about the copyright. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. *** You're of course free to also include your email address and a link to your website, like you have done in the version you put on the web.

Ok, no problem. I will do it in the way you have told. I'm waiting when they will register the project (there is sdlgraph on sf.net, but it's old and empty, they need to check it).

Show quoted text 9 lines
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). 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. I may patch graph.inc, graphh.inc and modes.inc to add ability to hook such routines (Shapes/Lines) like Bar3D. It will not take any effect on currently written modules (Current Bad3d may be Bar3Ddefault and to be added to Bar3D proc if it's not assigned). Of course if you will approve it (I don't see any reason to make it just for my needs).

Show quoted text 9 lines
Also readln function need to be hooked too (It works when alt+tab > to console > from which app was executed). This will indeed be difficult. It's probably best to create a generic "wincrt"-like unit (sdlcrt?) which can be used together with the sdl graph unit. Full input/output support can also be added to it over time, similarly to how the regular crt unit also takes over all input/ output.

Nice idea. I may do it. I think that the best way for this is to use SDL-terminal (I have never used it, but it must be pretty nice). But it isn't in JEDI-SDL (so, it must be wrapped to .pp). But I prefer to use readln to give user a chance to see the screen created by graph (and close after any key was pressed). There are many old programmes with it. The "+" of SDLgraph is that it may be used with old code and you may add any JEDI-SDL routine (timer or SDL_mixer and so on) using global screen variable. Sorry for my poor English, but I think you will get the idea.

Show quoted text 13 lines
If you remember we were talking about it in April (or May). I've > created > sf.net project, but it is in Processing Queue. So, here are the > temp links: > > Unit: http://itmo.vingrad.ru/files/sdlgraph.pas.txt > > Example: http://itmo.vingrad.ru/files/test.pas.txt > > Build script (you need to fix paths): > http://itmo.vingrad.ru/files/build.sh.txt Very nice!

Thanks a lot! :)

Show quoted text 18 lines
P.S. Thanks you for your answers about the graph modules and to > authers of > graph*.inc and *Go32* module - the code is very nice. Carl will be happy to hear this :) No, it doesn't do the same: the lowNewMode..highNewMode case uses IntcurrentNewDriver, while the else case uses IntcurrentDriver. It's to transparently support both the old and new mode selection logic. > TODO: in modes.inc 181: Overloaded procedure initmode(var mode: > TModeInfo); > isn't used. I've looked only in modes.inc, so it may be my mistake It is used by all platform-specific graph units (also by your sdlgraph unit) to initialise a new mode.

Thanks, sorry my inattention.

Show quoted text 5 lines
TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode = > Init640x480x32k > } Fixed, thanks.

You're welcome :)

E.I.

Reply by email

Jonas Maebe
to Evgeniy Ivanov
Evgeniy Ivanov wrote 5 lines
> 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 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). And directputpixel then calls through to SDL, which every time must recalculate the pixel position on the screen (instead of just adding 1 to the horizontal or vertical coordinate in case of horizontal/vertical line drawing).

Show quoted text 9 lines
I may patch graph.inc, graphh.inc and modes.inc to add ability to hook such routines (Shapes/Lines) like Bar3D. It will not take any effect on currently written modules (Current Bad3d may be Bar3Ddefault and to be added to Bar3D proc if it's not assigned). Of course if you will approve it (I don't see any reason to make it just for my needs).

I really don't think it will be needed.

Show quoted text 20 lines
> This will indeed be difficult. It's probably best to create a generic > "wincrt"-like unit (sdlcrt?) which can be used together with the sdl > graph unit. Full input/output support can also be added to it over > time, similarly to how the regular crt unit also takes over all > input/ > output. Nice idea. I may do it. I think that the best way for this is to use SDL-terminal (I have never used it, but it must be pretty nice). But it isn't in JEDI-SDL (so, it must be wrapped to .pp). But I prefer to use readln to give user a chance to see the screen created by graph (and close after any key was pressed). There are many old programmes with it. The "+" of SDLgraph is that it may be used with old code and you may add any JEDI-SDL routine (timer or SDL_mixer and so on) using global screen variable. Sorry for my poor English, but I think you will get the idea.

Yes, sounds good.

Jonas

Reply by email

Evgeniy Ivanov
to Jonas Maebe

2007/8/22, Jonas Maebe :

Show quoted text 9 lines
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). And directputpixel then calls through to SDL, which every time must recalculate the pixel position on the screen (instead of just adding 1 to the horizontal or vertical coordinate in case of horizontal/vertical line drawing).
 Hm... I really forgot to hook Line (but wrote the routine). But HLine and
VLine are hooked and the speed problem is in the Bar function, it has such
code:
           for y:=y1 to y2 do
              Hline(x1,x2,y);
HLine is hooked and works quickly. But it locks the screen every time it is
executed (but calls DirectPutPixel without locking (that's why it is fast):
procedure sdlgraph_HLine(x,x2,y: smallint);
var
temp:DefPixelProc;
begin
 temp:=DirectPutPixel;
 ;   // It doesn't lock the screen as
sdlgraph_DirectPutPixel. It's quick.
 Slock;
 HLineDefault(x,x2,y);
 Sulock;
 DirectPutPixel:=temp;
end;

If to do the same (using nonBuf_HLine) with Bar3D it would be very fast.

E.I.

Reply by email

Jonas Maebe
to Evgeniy Ivanov
Evgeniy Ivanov wrote 30 lines
2007/8/22, Jonas Maebe : > > > 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). And directputpixel then calls > through to SDL, which every time must recalculate the pixel position > on the screen (instead of just adding 1 to the horizontal or vertical > coordinate in case of horizontal/vertical line drawing). Hm... I really forgot to hook Line (but wrote the routine). But HLine and VLine are hooked and the speed problem is in the Bar function, it has such code: for y:=y1 to y2 do Hline(x1,x2,y); HLine is hooked and works quickly. But it locks the screen every time it is executed (but calls DirectPutPixel without locking (that's why it is fast): procedure sdlgraph_HLine(x,x2,y: smallint); var temp:DefPixelProc; begin temp:=DirectPutPixel; ; // It doesn't lock the screen as sdlgraph_DirectPutPixel. It's quick.

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.

Bar3D's speed is fine if you have a fast hline implementation (like for e.g. go32v2 in most modes).

Jonas

Reply by email

Micha Nelissen
to Jonas Maebe
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 ? It's just an extra memory fetch (hopefully in cache) ?

Micha

Reply by email

Evgeniy Ivanov
to Jonas Maebe: No, it is still slow. You indeed do not have locking overhead, but you are still calling…

2007/8/22, Jonas Maebe :

Show quoted text 39 lines
On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote: > 2007/8/22, Jonas Maebe : >> >> >> 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). And directputpixel then calls >> through to SDL, which every time must recalculate the pixel position >> on the screen (instead of just adding 1 to the horizontal or vertical >> coordinate in case of horizontal/vertical line drawing). > > Hm... I really forgot to hook Line (but wrote the routine). But > HLine and > VLine are hooked and the speed problem is in the Bar function, it > has such > code: > for y:=y1 to y2 do > Hline(x1,x2,y); > HLine is hooked and works quickly. But it locks the screen every > time it is > executed (but calls DirectPutPixel without locking (that's why it > is fast): > procedure sdlgraph_HLine(x,x2,y: smallint); > var > temp:DefPixelProc; > begin > temp:=DirectPutPixel; > ; // It doesn't lock the > screen as > sdlgraph_DirectPutPixel. It's quick. 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.
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 reimplement Bar3d with adding locking - very quick. I think it is the fastest HLine implementation

Bar3D's speed is fine if you have a fast hline implementation (like

for e.g. go32v2 in most modes).

It's asm, it should be faster than pascal code.

E.I.

Reply by email

Michael Van Canneyt
to Micha Nelissen: Why is calling via a procvar very much slower than a normal call ? It's just an extra…
Micha Nelissen wrote 7 lines
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 ? It's just an extra memory fetch (hopefully in cache) ?

Jonas meant that each pixel is drawn separately. The procvar is not the issue.

Michael.

Reply by email

Micha Nelissen
to Michael Van Canneyt
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 that the basis for any software implemented graphics routine: drawing pixels ?

Micha

Reply by email

Jonas Maebe
to Micha Nelissen
Micha Nelissen wrote 10 lines
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 that the basis for any software implemented graphics routine: drawing pixels ?

Yes, but not with a call and location calculation per pixel (and who knows what else SLD_putpixel does behind the scenes). And in case of horizontal lines, you usually draw several pixels at a time (or at least blit them using a fillchar/word/dword-like routine).

Jonas

Reply by email

Jonas Maebe
to Evgeniy Ivanov: 2007/8/22, Jonas Maebe : Hm... I've tried such thing: procedure sdlgraph_HLine(x,x2,y:…
Evgeniy Ivanov wrote 12 lines
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 reimplement Bar3d with adding locking - very quick. I think it is the fastest HLine implementation

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 done from a separate thread, which only does the flipping once per vertical refresh of the monitor. I don't know whether SDL provides access to this information though.

> Bar3D's speed is fine if you have a fast hline implementation (like > for e.g. go32v2 in most modes). It's asm, it should be faster than pascal code.

That is not why it is that much faster. That code would be almost equally fast if it were written in Pascal. I wrote it in assembler because I liked doing that, not because it was needed for speed reasons.

Jonas

Reply by email

Vinzent Hoefler
to Micha Nelissen: Before me going too far in unknown territory, but isn't that the basis for any software…
Micha Nelissen wrote 9 lines
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 that the basis for any software implemented graphics routine: drawing pixels ?

According to Michael Abrash: No, it's not. Linedrawing is more like it.

Vinzent.

Reply by email

Evgeniy Ivanov
to Jonas Maebe: I guess the problem is that you blit the entire screen after every drawing operation. It…

2007/8/22, Jonas Maebe :

Show quoted text 10 lines
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 done from a separate thread, which only does the flipping once per vertical refresh of the monitor. I don't know whether SDL provides access to this information though.

Thanks a lot! Now I understand how I may speed up it. There're no flipping once per vertical refresh, but there is flipping of needed rect (not entire screen). I will try to use it with separate thread.

E.I.

Reply by email

Michael Schnell
to Evgeniy Ivanov: 2007/8/22, Jonas Maebe : Hm... I've tried such thing: procedure sdlgraph_HLine(x,x2,y:…
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, draw text, copy surface rectangle (for 2D); or complex stuff like the construction of volumes bodies or view point change for 3D) are called.

-Michael

Reply by email

Michael Schnell
to Micha Nelissen: Before me going too far in unknown territory, but isn't that the basis for any software…
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 CPU and the graphic card, the count of those calls should be as low as possible. That is why drawing single pixels always is a really bad idea.

-Michael

Reply by email

Evgeniy Ivanov
to Michael Schnell

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://itmo.vingrad.ru/files/sdlgraph/build.sh

http://itmo.vingrad.ru/files/sdlgraph/sdlgraph.ppu

May you add it to your cvs (to the fpc project)?

E.I.

Reply by email

Jonas Maebe
to Evgeniy Ivanov
Evgeniy Ivanov wrote 16 lines
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://itmo.vingrad.ru/files/sdlgraph/build.sh http://itmo.vingrad.ru/files/sdlgraph/sdlgraph.ppu 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 changes (added missing InternalDriverName constant, and some Mac OS X changes).

Thanks,

Jonas

Reply by email

Jonas Maebe
to Jonas Maebe
Jonas Maebe wrote 8 lines
> 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 changes (added missing InternalDriverName constant, and some Mac OS X changes).

Also, Michael, could you maybe create an svn login for Evgeniy with write access to the packages/extra/graph/ directory?

Thanks,

Jonas

Reply by email

Evgeniy Ivanov
to Jonas Maebe: Done. You can see it at http://svn.freepascal.org/svn/fpc/trunk/packages/extra/graph/…

2007/8/26, Jonas Maebe :

Show quoted text 9 lines
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 constant, and some Mac OS X changes).

Thanks a lot! Nice.
I will try to do it stable in September. 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.

2007/8/26, Jonas Maebe :

Also, Michael, could you maybe create an svn login for Evgeniy with write access to the packages/extra/graph/ directory?

It would be pretty good. I will be able to commit without troubling anybody.

E.I.

Reply by email

Tomas Hajny
to Evgeniy Ivanov
Evgeniy Ivanov wrote 16 lines
2007/8/26, Jonas Maebe : > > 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 constant, and some Mac OS X changes). > > Thanks a lot! Nice. I will try to do it stable in September. 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 cooperation with Crt unit little bit more here (at least I'm interested what your plans are).

Tomas

Reply by email

Evgeniy Ivanov
to Tomas Hajny

2007/8/29, Tomas Hajny :

Show quoted text 10 lines
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 cooperation with Crt unit little bit more here (at least I'm interested what your plans are).

The problem with input is caused by SDL thread. And the same problem we may find in C programmes, see C example (I took it from SDL tutorial, it's huge because they decide to show some sdlutils things):

#include <stdio.h>
#include <stdlib.h>
#include "SDL.h"
void Slock(SDL_Surface *screen);
void Sulock(SDL_Surface *screen);
void DrawPixel(SDL_Surface *screen, int x, int y, Uint8 R, Uint8 G, Uint8
B);
void DrawScene(SDL_Surface *screen);

/* ------------------------------------------- */
int main(int argc, char *argv[]){

 if ( SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO) < 0 ){
   printf("Unable to init SDL: %s\n", SDL_GetError());
   exit(1);
 }
 atexit(SDL_Quit);
 SDL_WM_SetCaption("SDL Gfx Example #1","ex1");
 SDL_WM_SetIcon(SDL_LoadBMP("icon.bmp"), NULL);
 SDL_Surface *screen;
 screen=SDL_SetVideoMode(640,480,32,SDL_HWSURFACE|SDL_DOUBLEBUF);
 if ( screen == NULL ){
   printf("Unable to set 640x480 video: %s\n", SDL_GetError());
   exit(1);
 }
 int done=0;
 /*while(done == 0){
   SDL_Event event;
   while ( SDL_PollEvent(&event) ){
     if ( event.type == SDL_QUIT ){
      done = 1;
     }
     if ( event.type == SDL_KEYDOWN ){
       if ( event.key.keysym.sym == SDLK_ESCAPE ){
         done = 1;
       }
     }
   }
   DrawScene(screen);
 } */
// New code to show input problems
DrawScene(screen);
printf("Enter any number to finish the programme");
scanf("%d",&done);

}

/* ------------------------------------------------------ */ void Slock(SDL_Surface *screen){

if ( SDL_MUSTLOCK(screen) ){
if ( SDL_LockSurface(screen) < 0 ){

     return;
   }

}

}

/* ------------------------------------------------------ */ void Sulock(SDL_Surface *screen){

if ( SDL_MUSTLOCK(screen) ){

   SDL_UnlockSurface(screen);

}

}

/* ------------------------------------------------------ */ void DrawPixel(SDL_Surface *screen, int x, int y, Uint8 R, Uint8 G, Uint8 B){

 Uint32 color = SDL_MapRGB(screen->format, R, G, B);
 switch (screen->format->BytesPerPixel){
   case 1:  // Assuming 8-bpp
   {
     Uint8 *bufp;
     bufp = (Uint8 *)screen->pixels + y*screen->pitch + x; *bufp = color;
   } break;
   case 2: // Probably 15-bpp or 16-bpp
   {
     Uint16 *bufp;
     bufp = (Uint16 *)screen->pixels + y*screen->pitch/2 + x; *bufp = color;
   } break;
   case 3: // Slow 24-bpp mode, usually not used
   {
     Uint8 *bufp;
     bufp = (Uint8 *)screen->pixels + y*screen->pitch + x * 3;
     if(SDL_BYTEORDER == SDL_LIL_ENDIAN){
       bufp[0] = color;
       bufp[1] = color >> 8;
       bufp[2] = color >> 16;
     }else{
       bufp[2] = color;
       bufp[1] = color >> 8;
       bufp[0] = color >> 16;
     }
   } break;
   case 4: // Probably 32-bpp
   {
     Uint32 *bufp;
     bufp = (Uint32 *)screen->pixels + y*screen->pitch/4 + x;
     *bufp = color;
   } break;
 }

}

/* ------------------------------------------------------ */ void DrawScene(SDL_Surface *screen){

 Slock(screen);

for(int x=0;x<640;x++){
for(int y=0;y<480;y++){

     DrawPixel(screen, x,y,y/2,y/2,x/3);
   }

}
Sulock(screen);
SDL_Flip(screen);
}

/* ------------------------------------------- */

The same as in the sdlgraph (or fpc programmes with JEDI-SDL and readln/crt routines).
SDL creates it's own thread. I don't know how (maybe forks), but it's details.
So, I decide that we need to catch input in the separate thread with SDL routines, like

while(done == 0){

   SDL_Event event;
   while ( SDL_PollEvent(&event) ){
     if ( event.type == SDL_QUIT ){
      done = 1;
     }
     if ( event.type == SDL_KEYDOWN ){
       if ( event.key.keysym.sym == SDLK_ESCAPE ){
         done = 1;
       }
     }
   }

And then put (pipe) it to the standart input (to the fpc input). We may create this thread in the initMode routine and kill in the closeGraph. All code may be written in Pascal, it's just an example. My friends helped me with this idea and also advised to use int mkfifo(const char * pathname, mode_t mode);
or its pascal prototype.

E.I.

Reply by email