Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro on Nokia 770

This thread is locked; no one can reply to it. rss feed Print
Allegro on Nokia 770
serge
Member #3,613
June 2003

Nokia 770 is a debian linux powered PDA which uses GTK for GUI and has fully featured X server:
http://en.wikipedia.org/wiki/Nokia_770_Internet_Tablet

We are trying to port ufo2000 to Nokia 770, so the first step is to ensure that allegro runs flawlessly on it.

Here is the first report.

I have compiled allegro using:

  1. ./configure --without-asm

  2. make

It built without any problems, though XF86VidMode extension does not seem to be available on nokia 770 and fullscreen mode does not work. Sound is supported using esd driver. Keyboard support works correctly and the device has the following hardware buttons: arrow keys, enter, esc, F4-F8. Mouse is simulated by touchscreen.

After compilation I run some examples and most of them work. Unfortunately demo game crashes almost immediately after start, though it shows something on the screen and plays some sounds before that. The crash is somewhere in 'pack_*' function.

Another problem is that in some demos image is somewhat distorted (4-pixel horizontal stripes look reversed). I'll try to provide a screenshot later. That's probably related to the fact that ARM CPU is very sensitive to alignment and unaligned read/writes of 32-bit values provide somewhat unexpected results (address is first aligned, data read and then rotated). But that distorted image problem appears only when blitting sprites to screen in unaligned locations, when using backbuffer for image preparation and blitting it to screen everything looks ok.

So I guess almost everything is fine and allegro has a great potential for running on this platform. Also it is very good that allegro has built-in fixed point math support as ARM cpu does not have floating point unit. So the fact that allegro was born in old i386 times is a good thing, now it can shine again on portable devices :)

As for the problems, the most annoying are the lack of fullscreen support and image distortion. Most likely they both should be fixed somewhere in 'xwin.c', but I'm still trying to figure how it works. Some help with allegro X11 driver would be appreciated.

ReyBrujo
Moderator
January 2001
avatar

Try compiling the debug version. Most times crashes are caught with an assert when the parameters are wrong. That would help quite a lot to the developers.

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

BAF
Member #2,981
December 2002
avatar

And last I knew, Allegro didn't use fixed point math, it converted to float and back for some maths.

Evert
Member #794
November 2000
avatar

Quote:

As for the problems, the most annoying are the lack of fullscreen support and image distortion. Most likely they both should be fixed somewhere in 'xwin.c'

If XF86VidMode is not available, there's nothing you can do to get the same behavior (though you could create a window the size of the screen and place it so that the decorations fall off the edge of the screen).

Quote:

but I'm still trying to figure how it works. Some help with allegro X11 driver would be appreciated.

You're free to clean it up or rewrite the thing from scratch ;)
Seriously, the X11 graphics driver is rather a big mess. It's been a while since I touched it, but if you have specific questions, feel free to ask!

Quote:

And last I knew, Allegro didn't use fixed point math, it converted to float and back for some maths.

For some, yes. But I guess floats are available through software emulation (slooooow), so it'd still work. Either way, patches to improve the fixed point math are, of course, welcome.

kazzmir
Member #1,786
December 2001
avatar

Quote:

Seriously, the X11 graphics driver is rather a big mess.

Oh I dunno. Its quite big, true, but every time I look through it I decide that its fairly logical. Taking a superficial look at the OS X code or the QNX code might lead people to thinking its a big mess as well. Theres just a lot of stuff the code does..

Evert
Member #794
November 2000
avatar

Quote:

Its quite big, true, but every time I look through it I decide that its fairly logical. Taking a superficial look at the OS X code or the QNX code might lead people to thinking its a big mess as well.

I did some things with the X11 graphics driver a while back (hardware cursors, mostly, but also adding the X11 icon and making it triple buffer so I could test that too. There might have been one or two more things). I thought some things were more complex than they had any real reason to be, but that probably refers mostly to the mouse cursor handling (if you've tried to make sense of that, you'll probably know what I'm talking about). I also think the XLOCK()/XUNLOCK() used to be rather complicated, but I think Elias and Chris managed to sort that out.

I've never looked at the QNX code, but what I've seen of the MacOS X code looks fairly straightforward. I don't think anything beats the DirectX driver for being hard to follow though.

Elias
Member #358
May 2000

About the fullscreen not working, the below code is an attempt to switch the Allegro window to fullscreen. The XVidMode extension is there to change the actual screen resolution of X11, which probably is not possible on the Nokia 770 - so the extension would make no sense.

1#include <allegro.h>
2#include <xalleg.h>
3 
4static void switch_fullscreen(void)
5{
6 char *names[] = {
7 "ATOM",
8 "_NET_WM_STATE",
9 "_NET_WM_STATE_FULLSCREEN"
10 };
11 Atom atoms[3];
12 
13 XLOCK();
14 XInternAtoms(_xwin.display, names, sizeof(names) / sizeof(names[0]), 1, atoms);
15 XUnmapWindow(_xwin.display, _xwin.window);
16 XFlush(_xwin.display);
17 XChangeProperty(_xwin.display, _xwin.window, atoms[1], atoms[0], 32, PropModeReplace,
18 (unsigned char *)&atoms[2], 1);
19 XFlush(_xwin.display);
20 XMapWindow(_xwin.display, _xwin.window);
21 XFlush(_xwin.display);
22 XUNLOCK();
23}
24 
25int main(void)
26{
27 allegro_init();
28 install_timer();
29 install_keyboard();
30 int w, h;
31 get_desktop_resolution(&w, &h);
32 set_color_depth(desktop_color_depth());
33 set_gfx_mode(GFX_AUTODETECT_WINDOWED, w, h, 0, 0);
34 
35 switch_fullscreen();
36 
37 line(screen, 0, 0, w - 1, h - 1, makecol(255, 255, 255));
38 
39 while (readkey() >> 8 != KEY_ESC);
40 return 0;
41}

--
"Either help out or stop whining" - Evert

kazzmir
Member #1,786
December 2001
avatar

Heres some code from xsnow that finds the correct root window to draw on, just in case some other program has taken that over like KDE.

1static Window
2VirtualRootWindowOfScreen(screen)
3 Screen *screen;
4{
5 static Screen *save_screen = (Screen *)0;
6 static Window root = (Window)0;
7 
8 if (screen != save_screen) {
9 Display *dpy = DisplayOfScreen(screen);
10 Atom __SWM_VROOT = None;
11 int i;
12 Window rootReturn, parentReturn, *children;
13 unsigned int numChildren;
14 
15 root = RootWindowOfScreen(screen);
16 
17 /* go look for a virtual root */
18 __SWM_VROOT = XInternAtom(dpy, "__SWM_VROOT", False);
19 if (XQueryTree(dpy, root, &rootReturn, &parentReturn,
20 &children, &numChildren)) {
21 for (i = 0; i < numChildren; i++) {
22 Atom actual_type;
23 int actual_format;
24 unsigned long nitems, bytesafter;
25 Window *newRoot = (Window *)0;
26 
27 if (XGetWindowProperty(dpy, children<i>,
28 __SWM_VROOT, 0, 1, False, XA_WINDOW,
29 &actual_type, &actual_format,
30 &nitems, &bytesafter,
31 (unsigned char **) &newRoot) == Success
32 && newRoot) {
33 root = *newRoot;
34 break;
35 }
36 }
37 if (children)
38 XFree((char *)children);
39 }
40 
41 save_screen = screen;
42 }
43 
44 return root;
45}

Given the DefaultScreen() of the XDisplay it will return a window you can actually draw on. I dont know if this has anything to do with the Nokia 770 but Im just throwing it out there in case it does and someone finds it useful.

Elias
Member #358
May 2000

Having Allegro draw to the root window would be a nice X-specific example program :) And I guess it wouldn't be too hard to do.

--
"Either help out or stop whining" - Evert

kazzmir
Member #1,786
December 2001
avatar

Hm, you mean a new graphics mode GFX_XROOT_WINDOW or something?

serge
Member #3,613
June 2003

ReyBrujo said:

Try compiling the debug version. Most times crashes are caught with an assert when the parameters are wrong. That would help quite a lot to the developers.

Yes, I'll compile debug version and will try to fix all the problems I can find. But I got device only 2 weeks ago, so I'm still getting familiar with embedded development. Currently I just installed gcc (using apt-get) on the device itself and compiled allegro 4.2.0 from SSH session. It revealed that the device does not have too much memory (64MB) for doing any development directly on it and allegro compiled only after enabling swap on flash memory card :) I'll have to install development environment and crosscompiler on my desktop PC for more or less serious programing for this device.

Elias said:

About the fullscreen not working, the below code is an attempt to switch the Allegro window to fullscreen. The XVidMode extension is there to change the actual screen resolution of X11, which probably is not possible on the Nokia 770 - so the extension would make no sense.

Thanks, this fullscreen switching code works!

I also found that allegro demo was crashing in intro_screen() function (most likely in FLI playing code), so after disabling the intro, it works. I added fullscreen switching code and KEY_ENTER as fire button. It provides about 40 FPS in dirty rectangles mode and 20 FPS in double buffering mode. In dirty rectangles mode the image is distorted, with double buffering it is ok. So this little game is at least playable on this 250MHz ARM CPU in 640x480 screen mode :)

About image distortion - here is a screenshot from exsprite example:
http://ufo2000.lxnt.info/files/n770/exsprite_screenshot.png
This problem only shows up in 8-bit mode (the device has 16bpp screen). Should I dig somewhere in MAKE_FAST_PALETTE8 and related code?

1#define MAKE_FAST_PALETTE8(name,dtype) \
2static void name(int sx, int sy, int sw, int sh) \
3{ \
4 int x, y; \
5 for (y = sy; y < (sy + sh); y++) { \
6 unsigned char *s = _xwin.screen_line[y] + sx; \
7 dtype *d = (dtype*) (_xwin.buffer_line[y]) + sx; \
8 for (x = sw - 1; x >= 0; x--) { \
9 unsigned long color = *s++; \
10 *d++ = _xwin.cmap[(_xwin.rmap[color] \
11 | _xwin.gmap[color] \
12 | _xwin.bmap[color])]; \
13 } \
14 } \
15}

By the way, isn't a single table lookup enough for '8bpp -> truecolor' conversion? Maybe this code could be optimized? Though I don't know anything about X11 programming yet and allegro X11 display driver internals are not very clear to me right now.

Elias
Member #358
May 2000

Quote:

Thanks, this fullscreen switching code works!

I'll try modifying the X11 code so if the requested mode is exactly the size/color-depth of the desktop, or the size and no XVidMode extension is available, it will use this code instead.

Quote:

By the way, isn't a single table lookup enough for '8bpp -> truecolor' conversion? Maybe this code could be optimized? Though I don't know anything about X11 programming yet and allegro X11 display driver internals are not very clear to me right now.

Hm, yes, it should. Apparently the code you pasted will first convert the palette entry to r, g and b with 3 lookups, or them together, and then do another lookup on that.. very odd indeed. If you can figure out what's going on and convert to a single lookup, that would be great..

I added it to todo.txt for now.

--
"Either help out or stop whining" - Evert

serge
Member #3,613
June 2003

Elias said:

I'll try modifying the X11 code so if the requested mode is exactly the size/color-depth of the desktop, or the size and no XVidMode extension is available, it will use this code instead.

Thanks, that would be great.

By the way, should I use 4.2 or 4.3 SVN branch for working on these ARM and Nokia 770 portability fixes?

Evert
Member #794
November 2000
avatar

Quote:

I'll try modifying the X11 code so if the requested mode is exactly the size/color-depth of the desktop, or the size and no XVidMode extension is available, it will use this code instead.

Elias: any chance of getting your patch ready today or tomorrow?

Quote:

By the way, should I use 4.2 or 4.3 SVN branch for working on these ARM and Nokia 770 portability fixes?

I'd say 4.2, and let us handle backporting the fixes to 4.3. Then when 4.3 is about getting ready for its first release, check what needs to be fixed there.
The main reason I think this is the way to go is that fixes to 4.2 can go into 4.2.2 and up, but fixes to 4.3 won't be released in a stable version for a while.

serge
Member #3,613
June 2003

Elias said:

Hm, yes, it should. Apparently the code you pasted will first convert the palette entry to r, g and b with 3 lookups, or them together, and then do another lookup on that.. very odd indeed. If you can figure out what's going on and convert to a single lookup, that would be great..

Well, seems like I have found what's happening. Function _xwin_private_select_screen_to_buffer_function selects color convertion functions. That inefficient code with 3 extra table lookups seems to be some kind of fallback which is used only in rare circumstances (probably even never). It does not work in my case at all (neither on Nokia 770, nor on my x86 desktop PC). Real code that does color conversion is in 'ccolconv.c'. Image distortion is caused by unaligned memory access in _colorconv_blit_8_to_16 function. Nokia 770 has little endian byte order, but is sensitive to alignment, so current allegro conditionally compiled code does not work well. Looks like I'll have to watch all the places in the sources which deal with byte order. FLI format decoding functions also have some endian dependent code, most likely that's why FLI playing crashes.

I'll try to make some patch for branch 4.2 in the next few days. Seems like an extra define like ALLEGRO_ARM or ALLEGRO_STRICT_ALIGNMENT will be required.

edit: As I see, Allegro delevopers are currently busy preparing 4.2.1 release, so I don't want to get in the way. I'll try to investigate that alignment problem better, get some benchmarks for reading/writing aligned and unaligned 32-bit data on x86, amd64 and arm ('_colorconv_blit_8_to_16' function contains some extra logic to combine data for accessing memory using dwords). It would be interesting to see if there is any positive effect of such optimization (in both aligned and unaligned case). I'll come with some patch eventually and I hope that Allegro 4.2.2 will have maemo in its list of supported platforms. And if anybody else gets Nokia 770 in his hands as well, feel free to join :)

Go to: