Hickup on Classic MacOS

SDL Development
1

I think I figured out the slight hesitation on the little testsprite
program (which part of my explorative app is based on) - when the
program starts up, the files stdout and stderr are created in the
directory and that coincides with the slight hickups. The files are
empty - it seems that even though printf isn’t being called, the files
are formed anyway. Any way around this? Or do I just do something
non-animated for a moment to cover up the hickup?

Cheers,
Mike

Michael Vanecek wrote:> I re-initialized the disk on the Rev-C iMac, upgraded to MacOS 9.0 and

reinstalled everything and went into SDL-devel and the test progs
compiled with nary a problem. I can’t say whether it was a problem with
the old MacOS 8.5, or whatever the previous owner had done to it. I plan
on upgrading the RAM to 512Mb (from 96 now) and the harddrive to a 40 or
60 Gb and drool over all the neat SDL stuff on Mac.

One Q - the testsprite application has a slight hickup just as it starts
up before resuming animation - it starts, stops briefly and then
continues. An app I’ve been putting together to teach myself SDL (using
some of this and some of that) also does the same thing. I’m using the
basic SDL_Getticks() function on my learning application. Could the Mac
be hesitating to do the math once it all starts, or is there something
else I should be aware of (Mac quirks like Endian stuff or math stuff?).
Another possibility is that it takes an extra moment to load the event
functions which are after all the images and animations are loaded…

Thanks,
Mike

–
http://dotfile.net/ - Dedicated to Open Source Software

2

Crack open src/main/macos/SDL_main.c and remove the part where the files
are created, replace with fclose() on stdout and stderr.On Friday, January 4, 2002, at 06:27 PM, Michael Vanecek wrote:

I think I figured out the slight hesitation on the little testsprite
program (which part of my explorative app is based on) - when the
program starts up, the files stdout and stderr are created in the
directory and that coincides with the slight hickups. The files are
empty - it seems that even though printf isn’t being called, the files
are formed anyway. Any way around this? Or do I just do something
non-animated for a moment to cover up the hickup?

Cheers,
Mike

Michael Vanecek wrote:

I re-initialized the disk on the Rev-C iMac, upgraded to MacOS 9.0 and
reinstalled everything and went into SDL-devel and the test progs
compiled with nary a problem. I can’t say whether it was a problem
with the old MacOS 8.5, or whatever the previous owner had done to it.
I plan on upgrading the RAM to 512Mb (from 96 now) and the harddrive
to a 40 or 60 Gb and drool over all the neat SDL stuff on Mac.
One Q - the testsprite application has a slight hickup just as it
starts up before resuming animation - it starts, stops briefly and
then continues. An app I’ve been putting together to teach myself SDL
(using some of this and some of that) also does the same thing. I’m
using the basic SDL_Getticks() function on my learning application.
Could the Mac be hesitating to do the math once it all starts, or is
there something else I should be aware of (Mac quirks like Endian
stuff or math stuff?). Another possibility is that it takes an extra
moment to load the event functions which are after all the images and
animations are loaded…
Thanks,
Mike

– http://dotfile.net/ - Dedicated to Open Source Software

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

3

I’m having a problem with SDL_ttf: when I use TTF_RenderText_Blended to
render a text string, then blit the resulting surface onto my main
surface, there are solid rectangles where the letters should be. I
replace the function call with TTF_RenderText_Shaded and it works fine. I
set the color key and alpha value on the text surface before blitting and
still get the same (bad) results.

Source code attached for the brave. It’s minimal - just sets up a screen
and blits a surface returned by TTF_RenderText_Blended onto the screen.

I will exchange copious amounts of praise for any suggestions you can give
me. =)

Thanks,

Walter Rader

4

Here’s the source that is giving me trouble.

#include “SDL.h”
#include “SDL_ttf.h”
#include <stdlib.h> // exit, atexit

int quit = 0;

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

SDL_Surface *screen;
TTF_Font *font;
SDL_Surface *text, *temp;
SDL_Color white = { 0xFF, 0xFF, 0xFF, 0 };
SDL_Color black = { 0x00, 0x00, 0x00, 0 };
SDL_Rect dstrect = { 20, 70, 0, 0 };

SDL_Init(SDL_INIT_VIDEO);
atexit(SDL_Quit);
TTF_Init();
atexit(TTF_Quit);

screen = SDL_SetVideoMode(300, 200, 0, SDL_ANYFORMAT);

font = TTF_OpenFont("c:\\winnt\\fonts\\arial.ttf", 26);
TTF_SetFontStyle(font, TTF_STYLE_NORMAL);

// *************************************
//  TTF RENDER CALLS ARE RIGHT HERE!  =)
//
// This one works fine:
//text = TTF_RenderText_Shaded(font, "This is a test.", white, black);
// But this one just returns blocks rather than letters:
text = TTF_RenderText_Blended(font, "This is a test.", white);

SDL_SetColorKey(text, SDL_SRCCOLORKEY|SDL_RLEACCEL, 0);
SDL_SetAlpha(text, SDL_SRCALPHA|SDL_RLEACCEL, 255);
temp = SDL_DisplayFormat(text);
SDL_FreeSurface(text);
text = temp;

SDL_BlitSurface(text, NULL, screen, &dstrect);
TTF_CloseFont(font);
SDL_UpdateRect(screen, 0, 0, 0, 0);
SDL_FreeSurface(text);

SDL_Event event;
while (true) {
    if ( SDL_PollEvent ( &event ) ) {
        if ( event.type == SDL_QUIT ) {
            quit = 1;
            break;
        }
    }
}
return ( 0 ) ;

}

5

Remove the above lines, then you’ll see the text. Or you want to
use SDL_DisplayFormatAlpha() instead.

Regards,
.paul.On Mon, Jan 07, 2002 at 07:29:20AM -0800, Walter B. Rader wrote:

SDL_SetColorKey(text, SDL_SRCCOLORKEY|SDL_RLEACCEL, 0);
SDL_SetAlpha(text, SDL_SRCALPHA|SDL_RLEACCEL, 255);
temp = SDL_DisplayFormat(text);
SDL_FreeSurface(text);
text = temp;
6

“Walter B. Rader” wrote:

text = TTF_RenderText_Blended(font, “This is a test.”, white);

SDL_SetColorKey(text, SDL_SRCCOLORKEY|SDL_RLEACCEL, 0);

I don’t think you want to use a colour key with that surface, since it
has an alpha channel.

[…]

temp = SDL_DisplayFormat(text);

And here you remove the alpha channel (since the display has none).
Either use SDL_DisplayFormatAlpha(), or nothing at all (since you are using
RLE)

7

Crack open src/main/macos/SDL_main.c and remove the part where the files
are created, replace with fclose() on stdout and stderr.

I’m curious - would it be possible that the redirects could only be done
if an environment variable was set? like SDL_REDIRECT_STDIO or the like?
or vice versa, where it would be -disabled- if the environment variable
was set?

I don’t know how MacOS-classic handles environments so… but there’s
been a few messages relating to this over the last couple of months.

I am quite aware that many platforms do not -have- stdin/stdout/stderr in
any valid way (windows comes to mind) - but why would a complete program
need to be using these on said platforms?

Of course, another idea is to add an SDL “log” facility that by default
outputs to stderr, along the lines of umm g_log (see glib, part of Gnome
core libraries)

Just tossing out to see what y’all think. These are all -very- simple
changes and look harmless to the API to me (although logging would be an
extension and perhaps the environment var to -disable- redirect would be
the best way)

G’day, eh? :slight_smile:
- TeunisOn Sun, 6 Jan 2002, Darrell Walisser wrote:

8

Crack open src/main/macos/SDL_main.c and remove the part where the
files
are created, replace with fclose() on stdout and stderr.

I’m curious - would it be possible that the redirects could only be done
if an environment variable was set? like SDL_REDIRECT_STDIO or the
like?
or vice versa, where it would be -disabled- if the environment variable
was set?

Please forgive my previous response. I had forgotten that there is a
better way to this that has been put into SDL for this specific purpose.
I don’t know how I forgot it, I worked to create this darn thing in the
first place :wink:

The way to fix this is to change the “output to file” flag by holding
down the command key when the app starts up (while double clicking on
the app). This option is stored in a Preferences file on disk; to make
the change permanent, copy the ‘clne’ resource from the preferences file
(in the System Folder/Preferences/ Preferences, to your
application’s resource fork.

I am quite aware that many platforms do not -have- stdin/stdout/stderr
in
any valid way (windows comes to mind) -

Sure, Windows as stdin/stdout/stderr too. This is pretty much guaranteed
on an ANSI C implementation. Of course, not all platforms have a
complete C implementation, or even a hard disk/storage to store files
to :wink:

but why would a complete program
need to be using these on said platforms?

For debugging output…so users have some diagnostic info for fixing
problems and/or reporting them to people who are able to solve them.

Of course, another idea is to add an SDL “log” facility that by default
outputs to stderr, along the lines of umm g_log (see glib, part of Gnome
core libraries)

Probably beyond the scope of SDL. Developers will probably want to
customize the log file behavior of their programs, and we also don’t
want to constrain people to using C-type logging in C++ programs.

Just tossing out to see what y’all think. These are all -very- simple
changes and look harmless to the API to me (although logging would be an
extension and perhaps the environment var to -disable- redirect would be
the best way)

This is a good idea, but the problem is that you will have to set the
environment variable explicitly in the program (with SDL_putenv()),
since Mac OS has no concept of environment variables as global entities
on the system or for a group of processes.On Friday, January 11, 2002, at 05:54 PM, winterlion wrote:

On Sun, 6 Jan 2002, Darrell Walisser wrote: