Problems with latest WinCE CVS

The latest cvs NEARLY built, with one minor error: SDL_CDROMInit in
src/cdrom/dummy/SDL_syscdrom.c should be SDL_SYS_CDROMInit. No other fixes
were needed for it to compile and operate.

There is one odd problem though. When I call
SDL_SetVideoMode(width,height,32,SDL_ANYFORMAT) it fails with “Cannot create
DIB section”. A version modified to get the Windows error produced a more
helpful message – “the parameter is incorrect”. Wow, that sure narrows it
down! 9.9

But when I call SDL_SetVideoMode with 16BPP, it works fine. I can only guess
that under Windows CE, it’s failing to properly query the video surface type
then attempting to create a 32-bit video surface on a 16-bit screen.

Hi,

The latest cvs NEARLY built, with one minor error: SDL_CDROMInit in
src/cdrom/dummy/SDL_syscdrom.c should be SDL_SYS_CDROMInit. No other fixes
were needed for it to compile and operate.

What target and evc have you used?
Try to define DISABLE_CDROM and DISABLE_JOYSTICK in project
options (if it is not there already).

There is one odd problem though. When I call
SDL_SetVideoMode(width,height,32,SDL_ANYFORMAT) it fails with “Cannot create
DIB section”. A version modified to get the Windows error produced a more
helpful message – “the parameter is incorrect”. Wow, that sure narrows it
down! 9.9

What version of WinCE have you used?
I have tested it on WM2003 SE and it worked OK.

In trying to port eggtimer to Windows CE, I’ve noticed something strange –
time spent in sleep mode is not counted. So I can run eggtimer set to 2
minutes, turn off the PDA, wait 5 minutes then turn it back on, an the timer
won’t know 5 minutes have passed! This may not be a big deal on a PC where
sleep state isn’t used often, but PDA’s sleep all the time.

Use GetSystemTime and SystemTimeToFileTime.
Nothing doing, when a device is sleeping, your precise timers do
not work.

You can use Microsoft Emulator community preview to test real WinCE
device on your computer.
http://msdn.microsoft.com/mobility/windowsmobile/downloads/emulatorpreview/default.aspx--
Best regards,
Dmitry Yakimov, ISDEF member
ActiveKitten.com

Hi,

The latest cvs NEARLY built, with one minor error: SDL_CDROMInit in
src/cdrom/dummy/SDL_syscdrom.c should be SDL_SYS_CDROMInit. No other
fixes were needed for it to compile and operate.

What target and evc have you used?
PocketPC 2000, built via EVC3. There’s advantage to EVC4 that I’ve seen
unless you need WinCE.net, which SDL does not.
Try to define DISABLE_CDROM and DISABLE_JOYSTICK in project
options (if it is not there already).
Thanks, I had DISABLE_JOYSTICK but not DISABLE_CDROM. I still think that typo
was legitimate, though – that function did not fit the name of the rest in
the dummy driver. It’s just never mattered 'cause nothing uses it.

There is one odd problem though. When I call
SDL_SetVideoMode(width,height,32,SDL_ANYFORMAT) it fails with “Cannot
create DIB section”. A version modified to get the Windows error
produced a more helpful message – “the parameter is incorrect”. Wow,
that sure narrows it down! 9.9

What version of WinCE have you used?
I have tested it on WM2003 SE and it worked OK.
WinCE 3.0 on my compaq ipaq 3850. A bit old, but as long as it continues to
support SDL and induce me to remember my appointments it does what I need.

I’ve noticed another graphical behavior change in SDL – it doesn’t pop up
"windows" anymore, just graphic areas attached to the upper left, but I
figured that was to better fit in with Windows CE…

Use GetSystemTime and SystemTimeToFileTime.
Shouldn’t that be in SDL though, not eggtimer? See one of my previous posts,
in which is working source for that.On October 1, 2005 02:05 pm, Dmitry Yakimov wrote:

Thanks, I had DISABLE_JOYSTICK but not DISABLE_CDROM. I still think that typo
was legitimate, though – that function did not fit the name of the rest in
the dummy driver. It’s just never mattered 'cause nothing uses it.

That’s actually in the higher-level code (SDL_CDROMInit() calls
SDL_SYS_CDInit()). It shouldn’t be in the dummy driver.

The only place that SDL_CDROMInit() is referenced is in src/SDL.c, and
it’s wrapped in an “#ifndef DISABLE_CDROM”, so it should be safe to
remove from the dummy driver…

…which I just did. Let me know if everything blows up.

Use GetSystemTime and SystemTimeToFileTime.

Shouldn’t that be in SDL though, not eggtimer? See one of my previous posts,
in which is working source for that.

I’m inclined to think it should be in SDL (your patch is on my TODO
list, btw). Dmitry, if you disagree, please speak up.

–ryan.

Nothing blows up :)On October 1, 2005 06:50 pm, Ryan C. Gordon wrote:

That’s actually in the higher-level code (SDL_CDROMInit() calls
SDL_SYS_CDInit()). It shouldn’t be in the dummy driver.

The only place that SDL_CDROMInit() is referenced is in src/SDL.c, and
it’s wrapped in an “#ifndef DISABLE_CDROM”, so it should be safe to
remove from the dummy driver…

…which I just did. Let me know if everything blows up.

Hi,

There is one caveat - for example - we use SDL for game (nothing
unusual :).
And we write a game loop like:

int time0 = SDL_GetTicks();
while(game_is_playing)
{
slice = SDL_GetTicks() - time0; // in ms
UpdateLogic(slice);
Render();
}

It allows the game to be smooth, and it works for SDL 1.2.9.
After this update when user turn off a device and then turn it on a
slice value became very big. And the game may finish immediately.

Usually SDL is used for games, not for the clock applications.
(for example in my alarm clock application Chronos for PPC I used GetSystemTime
for all time calculations). I suppose we should not apply this patch
because it could make existing games unstable.>>> Use GetSystemTime and SystemTimeToFileTime.

Shouldn’t that be in SDL though, not eggtimer? See one of my previous posts,
in which is working source for that.

I’m inclined to think it should be in SDL (your patch is on my TODO
list, btw). Dmitry, if you disagree, please speak up.


Best regards,
Dmitry Yakimov, ISDEF member
ActiveKitten.com

Hi,

There is one caveat - for example - we use SDL for game (nothing
unusual :).
And we write a game loop like:

int time0 = SDL_GetTicks();
while(game_is_playing)
{
slice = SDL_GetTicks() - time0; // in ms
UpdateLogic(slice);
Render();
}

It allows the game to be smooth, and it works for SDL 1.2.9.
After this update when user turn off a device and then turn it on a
slice value became very big. And the game may finish immediately.
I’ve had problems like that anyway, on lots of platforms. In a time-sharing
preeemptive-multitasking environment it’s a guarantee that your application
WILL be suspended at the worst possible time, and should gracefully deal with
that. Maybye have a maximum allowable timeslice for a certain framerate.

Usually SDL is used for games, not for the clock applications.
(for example in my alarm clock application Chronos for PPC I used
GetSystemTime for all time calculations). I suppose we should not apply
this patch because it could make existing games unstable.
I’d say they weren’t stable in the first place, banking on a timesharing OS
not suspending them at inconvenient times.On October 2, 2005 02:18 pm, Dmitry Yakimov wrote:

Hi,

Probably you are right. Time slice may be big in ANY multiprocess
environment, this is by design.
And developers must protect their application from it by defining a maximal possible value.

Choosing between two evils :slight_smile: I’d say that I prefer your patch, using
it you can do things without digging into GetSystemTime and WinAPI, using only
SDL and C.

Ryan, I suppose it is a good and useful patch for SDL for Pocket PC and we should
include it.

Monday, October 3, 2005, 2:03:10 AM, you wrote:

TM> On October 2, 2005 02:18 pm, Dmitry Yakimov wrote:

Hi,

There is one caveat - for example - we use SDL for game (nothing
unusual :).
And we write a game loop like:

int time0 = SDL_GetTicks();
while(game_is_playing)
{
slice = SDL_GetTicks() - time0; // in ms
UpdateLogic(slice);
Render();
}

It allows the game to be smooth, and it works for SDL 1.2.9.
After this update when user turn off a device and then turn it on a
slice value became very big. And the game may finish immediately.
TM> I’ve had problems like that anyway, on lots of platforms. In a time-sharing
TM> preeemptive-multitasking environment it’s a guarantee that your application
TM> WILL be suspended at the worst possible time, and should gracefully deal with
TM> that. Maybye have a maximum allowable timeslice for a certain framerate.

Usually SDL is used for games, not for the clock applications.
(for example in my alarm clock application Chronos for PPC I used
GetSystemTime for all time calculations). I suppose we should not apply
this patch because it could make existing games unstable.
TM> I’d say they weren’t stable in the first place, banking on a timesharing OS
TM> not suspending them at inconvenient times.–
Best regards,
Dmitry Yakimov, ISDEF member
ActiveKitten.com