Hi,
Look at it here:
https://bugzilla.libsdl.org/show_bug.cgi?id=65--
Best Regards,
Dmitry Yakimov, http://www.activekitten.com
Hi,
Just tried it and it seams to work. Except I had a problem with endians -
eVC++ defines only _ARM, ARM and ARM, but not arm symbols. So SDL
tough that it was on a big endian machine.
All so if i explicitly set the bitsperpixel parameter of SDL_SetVideoMode
function (e.g. to 8) i get some weird colors - if set to 0 it is OK.
Regards SimonOn 3/2/06, Dmitry Yakimov wrote:
Hi,
Look at it here:
https://bugzilla.libsdl.org/show_bug.cgi?id=65–
Best Regards,
Dmitry Yakimov, http://www.activekitten.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hm, replaying to myself 
I tried to run some more tests and found the next problem:
At start i call:
surf = SDL_SetVideoMode (240, 320, 0, SDL_FULLSCREEN)
Then when I do:
SDL_Rect rect = {1,1,238,80};
SDL_FillRect (surf, &rect, uColor);
I get a bar at top of the screen as expected.
But then when i try to draw a line with putpixel:
x1 = 1;
y1 = 1;
x2 = 238;
y2 = 1;
if (SDL_MUSTLOCK (surf))
SDL_LockSurface (surf);
for (i = x1; i < x2; i++) {
bufp = (Uint8 *) surf->pixels + y1 * surf->pitch + i;
*bufp = sdlColor;
}
if (SDL_MUSTLOCK (surf))
SDL_UnlockSurface (surf);
It draws a line to about half of the screen.
surf->w = 240
surf->h = 320
surf->pitch = 480 ???
Any ideas what is going on?On 3/5/06, Simon Posnjak <@Simon_Posnjak> wrote:
Hi,
Just tried it and it seams to work. Except I had a problem with endians - eVC++ defines only _ARM, ARM and ARM, but not arm symbols. So SDL tough that it was on a big endian machine.
All so if i explicitly set the bitsperpixel parameter of SDL_SetVideoMode function (e.g. to 8) i get some weird colors - if set to 0 it is OK.
Regards Simon
On 3/2/06, Dmitry Yakimov wrote:
Hi,
Look at it here:
https://bugzilla.libsdl.org/show_bug.cgi?id=65–
Best Regards,
Dmitry Yakimov, http://www.activekitten.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hello Simon,
Sunday, March 5, 2006, 2:12:06 AM, you wrote:
surf->>w = 240 surf->>h = 320 surf->>pitch = 480 ???SP> Any ideas what is going on?
You’re getting a 16-bit surface?–
Best regards,
Peter mailto:@Peter_Mulholland
Yes, that was the problem… Thank you.
Regards simonOn 3/5/06, Peter Mulholland wrote:
Hello Simon,
Sunday, March 5, 2006, 2:12:06 AM, you wrote:
surf->>w = 240 surf->>h = 320 surf->>pitch = 480 ???SP> Any ideas what is going on?
You’re getting a 16-bit surface?
–
Best regards,
Peter mailto:darkmatter at freeuk.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi once more,
Why does SDL_AddTimer always return error “This platform doesn’t
support multiple timers” on WinCE?
Regards SimonOn 3/2/06, Dmitry Yakimov wrote:
Hi,
Look at it here:
https://bugzilla.libsdl.org/show_bug.cgi?id=65–
Best Regards,
Dmitry Yakimov, http://www.activekitten.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Just tried it and it seams to work. Except I had a problem with endians -
eVC++ defines only _ARM, ARM and ARM, but not arm symbols. So SDL
tough that it was on a big endian machine.
Fixed in CVS, thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentHi once more,
Why does SDL_AddTimer always return error “This platform doesn’t
support multiple timers” on WinCE?
Because the WinCE code isn’t set up with threaded timer support.
Dmitry, can you think of any reason why we couldn’t enable it?
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentHi,
I guess Sam tweaked a bit an original patch, it was _WIN32_WCE there.
Just tried it and it seams to work. Except I had a problem with endians -
eVC++ defines only _ARM, ARM and ARM, but not arm symbols. So SDL
tough that it was on a big endian machine.
Sam,
I think it is much better to disable using SDL implementations of
string.c because
WinCE platform contains memcpy, memset and other functions embedded in
coredll.dll that are much (several timer) faster even that DWORD copying (of
course faster that single char SDL copying routine). These routines use ARM
assembler tricks.
I’m to note that WinCE is an embedded platform without hdd and swap file, so
its memory manager is optimized for such scenario and SDL internal malloc just
won’t do.
So it is highly desirable to use:
#define HAVE_MALLOC 1
#define HAVE_CALLOC 1
#define HAVE_REALLOC 1
#define HAVE_FREE 1
#define HAVE_ALLOCA 1
#define HAVE_MEMSET 1
#define HAVE_MEMCPY 1
#define HAVE_MEMMOVE 1
#define HAVE_MEMCMP 1
#define HAVE_STRLEN 1
in config file.
Did you check loopwave subproject? Current CVS version can’t be compiled for
wince because missed wince specific changes.
Best Regards,
Dmitry Yakimov.
Hi,
We are to define MIPS and SH3 as well.
I guess Sam tweaked a bit an original patch, it was _WIN32_WCE there.
Just tried it and it seams to work. Except I had a problem with
endians -
eVC++ defines only _ARM, ARM and ARM, but not arm symbols. So SDL
tough that it was on a big endian machine.
Best Regards,
Dmitry Yakimov
WinCE platform contains memcpy, memset and other functions embedded in
coredll.dll that are much (several timer) faster even that DWORD copying (of
course faster that single char SDL copying routine). These routines use ARM
assembler tricks.
It you look at the latest CVS code, you’ll see that libc support has been
turned back on, so this should be enabled for the WinCE platform again.
Did you check loopwave subproject? Current CVS version can’t be compiled for
wince because missed wince specific changes.
What are the errors? I compiled and ran loopwave on the Pocket PC emulator
with no problems.
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentWe are to define MIPS and SH3 as well.
There are big and little endian versions of MIPS, but I’m assuming WinCE
only targets the little endian architectures.
I’ve changed SDL_endian.h in CVS to check for big endian symbols instead
of little endian symbols, which should help some of the more unusual cases.
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentHi,
It you look at the latest CVS code, you’ll see that libc support has been
turned back on, so this should be enabled for the WinCE platform again.
Things happens so fast. I’m going to be a CVS robot 
/ Did you check loopwave subproject? Current CVS version can’t be compiled for
/
/ wince because missed wince specific changes.
/
What are the errors? I compiled and ran loopwave on the Pocket PC emulator
with no problems.
Pocket PC does not have a command line, that was my question.
Ah, yeah, I found a code
if ( argv[1] == NULL ) {
argv[1] = “sample.wav”;
}
It is OK now.
Best Regards,
Dmitry Yakimov.
Hi,
It you look at the latest CVS code, you’ll see that libc support has been
turned back on, so this should be enabled for the WinCE platform again.
Things happens so fast. I’m going to be a CVS robot
Heheh, I’m trying to make up for being slow this past year.
Pocket PC does not have a command line, that was my question.
Ah, yeah, I found a code
if ( argv[1] == NULL ) {
argv[1] = “sample.wav”;
}
It is OK now.
Great, thanks for checking.
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentHi,
I do no know such a reason So are going to look into it.
/ Why does SDL_AddTimer always return error “This platform doesn’t
/>/ support multiple timers” on WinCE?
/
Because the WinCE code isn’t set up with threaded timer support.Dmitry, can you think of any reason why we couldn’t enable it?
Best Regards,
Dmitry Yakimov.