sdlBASIC Proposed changes

[RetroMan]

A thread dedicated to posting proposed changes to sdlBASIC after discussion.

If you have a feature you would like to see added to sdlBASIC but are not a developer, please consider posting it in the "sdlBASIC Wish List" thread.

[gersen]

Wait command:

The wait command used to burn up cpu time until fixed by vj roby. The code is here under /src/sdlBrt/SDLengine:

Code:

//waitTime(t) : wait t milliseconds
int waitTime(int t)
{
Uint32 ticks;
ticks=SDL_GetTicks()+t;
while(ticks>SDL_GetTicks()){
SDL_Delay(5);
getevent();
if (stopkey()==-1)return -1;
if (autotimer()!=0)return -1;
}
return 0;
}

The "fix" was to add the line.... "SDL_Delay(5);"

Seems to me if you are going to introduce SDL_Delay(), then  it would be cleaner just to replace the whole routine  a la:

Code:

//waitTime(t) : wait t milliseconds
int waitTime(int t)
{
SDL_Delay(t);
return 0;
}

Opinions please

gersen

[menn]

why not? there isn't any lost functionality you can't put back in if say, a person needs the sdl_getticks, right? i assume that sdl_delay exits when key is pressed or a mouse is clicked?

[gersen]

Don't think so menn, so if that's needed, best leave things as they are.

[Jacob]

Maybe you could use a timer and do something like this:

Code:

const int TIMER_TIMED_OUT = 0x01010101;

Uint32 RemoveTimer( Uint32 interval, void *param )
{
if( SDL_RemoveTimer( (SDL_TimerID)(*id) ) == SDL_FALSE )
return 1;

SDL_Event Event = { SDL_USEREVENT, TIMER_TIMED_OUT, NULL, NULL };

if( SDL_PushEvent( &Event ) )
return 1;
else
return 0;
}

int waitTime( int t /* time in ms */ )
{
SDL_TimerID id = 0;
id = SDL_AddTimer( t, &RemoveTimer, (void*)(&id) );

if( id == NULL )
return 1;

SDL_Event Event;
SDL_WaitEvent( &Event );

if( Event.code != TIMER_TIMED_OUT )
SDL_RemoveTImer( id );

return 0;
}

EDIT: Didn't actually test this, and there might be a need to cast id to a void* instead of just a plain SDL_TimerID pointer.

EDIT2: Fixed what the previous edit noted and some other things.

EDIT3: Forgot about removing the timer if user generated an event.

[gersen]

Thanks Jacob, but you're way in front of my programming ability. I've tested the wait command, and it doesn't quit on a key press or mouse click, but just like yabasic, only drops out with an error on Control C.

So I really can't see what's wrong with a simple

Code:

//waitTime(t) : wait t milliseconds
int waitTime(int t)
{
SDL_Delay(t);
return 0;
}

Perhaps I'm missing something. It's not really important, just my preference for simple code. I have read SDL_Get_ticks is more accurate than SDL_Delay , but vj roby added the SDL_Delay(5) line to the routine which kind of negates that.

Regards

[Cybermonkey]

Perhaps I'm missing something. It's not really important, just my preference for simple code. I have read SDL_Get_ticks is more accurate than SDL_Delay , but vj roby added the SDL_Delay(5) line to the routine which kind of negates that.

Regards

COUGH  ... the sdl_delay was taken into code on my advise. I myself have the idea from the not so well-known QuickCG.
Here an example:

void waitFrame(double oldTime, double frameDuration) //in seconds
{
  float time = getTime();
  while(time - oldTime < frameDuration)
  {
    time = getTime();
    SDL_PollEvent(&event);
    if(event.type == SDL_QUIT) end();
    inkeys = SDL_GetKeyState(NULL);
    if(inkeys[SDLK_ESCAPE]) end();
    SDL_Delay(5); //so it consumes less processing power
  }
}

[gersen]

I wish you had also asked him to add it to InputS, it's another cpu hog.

[Jacob]

I'm not really sure if you guys were actually looking to make this work differently or if you just wanted something that would wait x seconds and then continue or if it should wait x seconds or till the user inputs something.

Bo I messed around with waitTime some more, not sure if you guys are interested, or if the overhead of this is too much, or if it's "safe" or if it has hidden "bugs"... You get what I'm saying, right? Anyway, this worked under Windows when compiling with Visual Studio(Note pragmas were just because i was too lazy to set the project up correctly for SDL):

Code:

#include <SDL/SDL.h>

#pragma comment(lib,"SDL.lib")
#pragma comment(lib,"SDLmain.lib")

const int TIMER_TIMED_OUT = 0x01010101;

int InternalWait( void *Time )
{
SDL_Delay( *(Uint32*)(Time) );
SDL_Event Event;
Event.type = SDL_USEREVENT;
Event.user.code = TIMER_TIMED_OUT;
Event.user.data1 = NULL;
Event.user.data2 = NULL;
SDL_PushEvent( &Event );
return 0;
}

int waitTime( int t /* time in ms */ )
{
SDL_Thread *Thread = SDL_CreateThread( &InternalWait, (void*)(&t) );
SDL_Event Event;

while( SDL_WaitEvent( &Event ) )
{
if( Event.type == SDL_USEREVENT )
{
if( Event.user.code == TIMER_TIMED_OUT )
break;
}
else if( Event.type == SDL_KEYDOWN )
break;
else if( Event.type == SDL_KEYUP )
break;
else if( Event.type == SDL_MOUSEBUTTONDOWN )
break;
else if( Event.type == SDL_MOUSEBUTTONUP )
break;
}

SDL_KillThread( Thread );

return 0;
}

int main( int argc, char **argv )
{
SDL_Surface *Screen = NULL;
SDL_Init( SDL_INIT_EVERYTHING );
Screen = SDL_SetVideoMode( 640, 512, 32, SDL_HWSURFACE );
SDL_Flip( Screen );
waitTime( 10000 );
SDL_Quit();
return 0;
}

This waits 10 seconds or till the user presses a key, whichever comes first.

[menn]

Don't think so menn, so if that's needed, best leave things as they are.

that was my mistake. it looked like maybe the function was losing something, but i figured if it did he couldjust put it back in the next minor version. from what i'm reading now it only "traps" (or rather doesn't interfere with) ctrl-c calls, which is good (otherwise it could lock the user out of the system.) it doesn't (as far as i can tell now) stop for any other keyboard or mouse events- so you're right, you can take most of that stuff out. i really hope this question didn't result in too much extra work.

[gersen]

I just compiled and tried a test with the simple version. (Should have done so at the start of ths thread). It's a no go, Control C ceases to work along with other IO. Seems that getevent and others have to be polled regularly, having one big SDL_Delay just sits there unresponsive to Contol C.

Jacob's routine looks good if we wanted to break out the delay loop with a keystroke. That would be different to current though.

[Jacob]

You could always just edit the loop to only break on say.... SDL_QUIT and SDLK_ESCAPE, no big deal, takes a few seconds?

[menn]

You could always just edit the loop to only break on say.... SDL_QUIT and SDLK_ESCAPE, no big deal, takes a few seconds?

you'd want to break for ctrl-c. but not escape, user might want to map esc to something else, like "are you sure?" in general i don't think esc should work (in any interactive program) like ctrl-c. sdl_quit is probably necessary, so that you can click the x to quit. personally i'd like to stay as true to the original as possible, but if the original locked and used all the cpu instead of breaking for ctrl-c and clicking close window, i'm happy to part with tradition on both of those "features."

[Cybermonkey]

I just compiled and tried a test with the simple version. (Should have done so at the start of ths thread). It's a no go, Control C ceases to work along with other IO. Seems that getevent and others have to be polled regularly, having one big SDL_Delay just sits there unresponsive to Contol C.

Jacob's routine looks good if we wanted to break out the delay loop with a keystroke. That would be different to current though.

It mustn't wait SECONDS! sdl_delay(5 ms!!!) That's just to decrease CPU usage from 50% (on a dualcore) to about 20% ...

[Jacob]

It mustn't wait SECONDS! sdl_delay(5 ms!!!) That's just to decrease CPU usage from 50% (on a dualcore) to about 20% ...

Still, that's a hack that doesn't really solve the problem, the "real" solution is to use a timer with an interrupt or to use a secondary thread(Or similar), either solution ends up taking near 0 % CPU power as long as there's no input to process. What's worse is that you start putting an artificial limit on how fast you can process input. Sure, 5 ms isn't a lot and the user will most likely not notice this in any way, but... Just saying.