Conversion

hello,
i am trying to convert a program from ggi to sdl. its almost done but
i still need help in some functions.
Could you help me out please by providing their equivalent in SDL.
the functions are :

ggiSetGCForeground();
ggiFillscreen();
ggiFlush();
ggiAddFlags(); /* asynchronous mode so that usleep OK*/

and specialy ggiSetGCForeground().

thank you so much for your help.
Simon

It is possible that no one on the list has used GGI. In any case, there
is a larger pool of potential assistants if you explain what each of
these functions does.On Nov 5, 2004, at 5:13 PM, Simon HEBBO wrote:

hello,
i am trying to convert a program from ggi to sdl. its almost done but
i still need help in some functions.
Could you help me out please by providing their equivalent in SDL.
the functions are :

ggiSetGCForeground();
ggiFillscreen();
ggiFlush();
ggiAddFlags(); /* asynchronous mode so that usleep OK*/

and specialy ggiSetGCForeground().

thank you so much for your help.
Simon


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

[quoting who originally ask the question, but I since deleted their post]

ggiSetGCForeground();
ggiFillscreen();
ggiFlush();

I think these three would be something like:

SDL_FillRect(dest_surface, NULL, some_color);
SDL_Flip(dest_surface);

SDL_MapRGB() is the typical way you’d get the color value (a uint32).
I’m often lazy and just generate the color right then, like so:

SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 255, 0, 0));

for a red window/screen, for example.

ggiAddFlags(); /* asynchronous mode so that usleep OK*/

Uh… no idea even what that comment means, sorry!

-bill!On Sat, Nov 06, 2004 at 12:52:51AM -0500, Donny Viszneki wrote:

  • ggiSetGCForeground() --> this function set the foreground color used
    in drawing operations in a visual

  • ggiFillscreen() --> this function fills the entire virtual screen

  • ggiFlush() --> this function flush pending output --> waits for the
    visual to finish pending accelerator commands, and in some targets, it
    refreshes the framebuffer.

  • ggiAddFlags() --> is a macro that set or unset the specified flags

those are the functions with the details.

thank you guys so much for your help.
SimonOn Fri, 5 Nov 2004 23:12:14 -0800, Bill Kendrick wrote:

On Sat, Nov 06, 2004 at 12:52:51AM -0500, Donny Viszneki wrote:

[quoting who originally ask the question, but I since deleted their post]

ggiSetGCForeground();
ggiFillscreen();
ggiFlush();

I think these three would be something like:

SDL_FillRect(dest_surface, NULL, some_color);
SDL_Flip(dest_surface);

SDL_MapRGB() is the typical way you’d get the color value (a uint32).
I’m often lazy and just generate the color right then, like so:

SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 255, 0, 0));

for a red window/screen, for example.

ggiAddFlags(); /* asynchronous mode so that usleep OK*/

Uh… no idea even what that comment means, sorry!

-bill!


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Simon HEBBO wrote:

  • ggiSetGCForeground() --> this function set the foreground color used
    in drawing operations in a visual

SDL doesn’t have any such drawing context, and the only drawing that SDL does is a filled rectangle that takes the color as an argument.
so, this routine doesn’t mean much to SDL, perhaps you just need to track a fgcolor in a variable to use in your own drawing routines.
but that is not related to SDL directly…so that’s up to you to implement.

  • ggiFillscreen() --> this function fills the entire virtual screen

use SDL_FillRect

  • ggiFlush() --> this function flush pending output --> waits for the
    visual to finish pending accelerator commands, and in some targets, it
    refreshes the framebuffer.

SDL doesn’t do “pending” operations. it may require a call to SDL_UpdateRect or SDL_Flip to update the screen to the current state, depending on whether you used double buffering or not.
And if you have a hardware single buffered surface, then it will be updated immediately or as soon as SDL_Unlock is called after a previous SDL_Lock is called.

  • ggiAddFlags() --> is a macro that set or unset the specified flags

what flags? SDL only has per surface flags, audio flags…basically things that have many different functions and meanings.
there’s no one flag interface.

-LIM-

Jonathan Atkins wrote:

Simon HEBBO wrote:

  • ggiSetGCForeground() --> this function set the foreground color used
    in drawing operations in a visual

SDL doesn’t have any such drawing context, and the only drawing that
SDL does is a filled rectangle that takes the color as an argument.
so, this routine doesn’t mean much to SDL, perhaps you just need to
track a fgcolor in a variable to use in your own drawing routines.
but that is not related to SDL directly…so that’s up to you to
implement.

  • ggiFillscreen() --> this function fills the entire virtual screen

use SDL_FillRect

  • ggiFlush() --> this function flush pending output --> waits for the
    visual to finish pending accelerator commands, and in some targets, it
    refreshes the framebuffer.

SDL doesn’t do “pending” operations. it may require a call to
SDL_UpdateRect or SDL_Flip to update the screen to the current state,
depending on whether you used double buffering or not.
And if you have a hardware single buffered surface, then it will be
updated immediately or as soon as SDL_Unlock is called after a
previous SDL_Lock is called.

Hmm. Let me nitpick here.
SDL does pending operations, and SDL_UpdateRect of SDL_Flip effectively
ensure that these are finished.
Taking care about the screen area on which you SDL_UpdateRect() can
improve your rendering performance, btw.

Stephane

Stephane Marchesin wrote:

Jonathan Atkins wrote:

SDL doesn’t do “pending” operations. it may require a call to
SDL_UpdateRect or SDL_Flip to update the screen to the current state,
depending on whether you used double buffering or not.
And if you have a hardware single buffered surface, then it will be
updated immediately or as soon as SDL_Unlock is called after a
previous SDL_Lock is called.

Hmm. Let me nitpick here.
SDL does pending operations, and SDL_UpdateRect of SDL_Flip effectively
ensure that these are finished.
Taking care about the screen area on which you SDL_UpdateRect() can
improve your rendering performance, btw.

a pending operation would mean that the drawing routine was queued and handled by
a server, like X11 does. X11 requires that you flush/sync etc… if you want
to be sure that your drawings have actually finished. And since you nitpicked
I am talking about plain X11, not MITSHM or anything like DGA.
OpenGL also has pending ops due to a similar construction to X11. Which is
why it also have a sync function.
SDL completes all drawing operations that you do immediately (as far as queueing
is concerned) so that there is no flush. no sync. with a single buffered hardware
surface this is apparent. The fact that software buffers and double buffers seem to
be pending is not really a “pending” operation. the operations are completed. Your
flip/updaterect only does another operation to change the screen “now”. Any flushing
that might be done, is done by SDL, all the time, depending on the video driver you use.
So, it doesn’t really help to call anything SDL does a pending operation, since there’s
no output command queuing going on. You do something, it’s done.

-LIM-

Simon HEBBO wrote:

  • ggiSetGCForeground() --> this function set the foreground color used
    in drawing operations in a visual

SDL doesn’t have any such drawing context, and the only drawing that
SDL does is a filled rectangle that takes the color as an argument.
so, this routine doesn’t mean much to SDL, perhaps you just need to
track a fgcolor in a variable to use in your own drawing routines.
but that is not related to SDL directly…so that’s up to you to
implement.

You should use SDL_gfx. It is a small library written for SDL which
provides drawing primitives (like drawing basic shapes, and
transforming images.) Check out this page:
http://www.ferzkopp.net/~aschiffler/Software/SDL_gfx-2.0/

If you scroll down you should probably find the equivalent calls for
all the functions you need to convert!

Good luck.On Nov 7, 2004, at 12:57 AM, Jonathan Atkins wrote: