Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro on Nokia 770 (part2)

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

Continue of the locked thread http://www.allegro.cc/forums/thread/561300

I have a patch with the following fixes:

  • problems with image distortion in 8-bit mode (because of improper alignment in 'ccolconv.c' which is important for ARM cpu)

  • crash in FLI playing code

  • added ENTER key as fire button to allegro demo game (as Nokia 770 does not have SPACE or CTRL buttons)

Also it adds ALLEGRO_ARM define for selecting conditionally compiled code that should be run on ARM cpu.

http://ufo2000.sourceforge.net/files/allegro-4.2-nokia770-fix.diff

One more notice for anyone who would like to try allegro on Nokia 770. It is important to use '-march=armv5te' optimization option, otherwise everything is a lot slower. For example 'clear_to_color()' function is twice faster with this optimization enabled.

The only thing remaining is to add proper fullscreen support and allegro will be ready to use on Nokia 770. At least I'm not aware of any other problems :) Also probably some performance critical functions written in ARM assembler would help to make it faster.

Looks like I'm having a serious communication problem. My emails do not reach allegro-developers mailing list and threads in this forum get locked after some time. I'll keep creating new threads once old ones become unusable and hope that some of the allegro developers will be kind enough to notice them :)

Thomas Fjellstrom
Member #476
June 2000
avatar

I've noticed your emails on the Mailing list, and threads here get locked after a week of inactivity.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Evert
Member #794
November 2000
avatar

Patch looks ok.
For the fullscreen problem, you may want to check the work that Hans de Goede has been doing over the past week. It looks very good, though I haven't tested it myself yet.

serge
Member #3,613
June 2003

Thomas said:

I've noticed your emails on the Mailing list, and threads here get locked after a week of inactivity.

Well, I get emails from the mailing list as a subscriber, but can't post there. It worked some time ago (maybe half a year ago), but now it doesn't :(

And locking threads after a week is a strange choice. I don't always have enough time for developing stuff that fast. Sometimes I take a break for a week or two, and then oops - thread is already locked :( Probably a lot of people feel the same. Especially it concerns the threads in 'allegro development' section, they are probably less frequently updated than some chit chat topics :)

Evert said:

Patch looks ok.

Fine, I'm ok with keeping my own patchset right now. More changes are to follow. I have written an ARM optimized version of memset function (with 16-bit and 32-bit variants), it beats standard memset on Nokia 770 providing twice better bandwidth! And I started playing with these optimizations because standard _linear_clear_to_color() is too slow in allegro (several times slower than standard memset) because of initializing data one byte at a time for 8bpp modes and 16-bits at a time for 16bpp modes. Using ARM assembler optimized function it is possible to boost clear_to_color performance many times! Now I'm working on optimized version of memcpy(), it should speed up _linear_blit() significantly :) If anybody is interested to have a copy of my code, just let me know.

In order to optimize that blit and clear_to_color function it is important to have direct access to bitmap memory, bmp_readXX() and bmp_writeXX() are inefficient on ARM (they are OK on x86 by the way as x86 probably has more advanced cache). The only architecture which has them implemented as not a simple pointer dereferencing macro is DJGPP. Maybe it is worth to have some define like NEED_NONTRIVIAL_BMP_READ for such platforms and make it possible to use some optimized variants of blitting functions which do not need these bmp_readXX() and bmp_writeXX() but use something like memset/memcpy instead?

Now a question about allegro architecture. Looks like at least in X11 mode it is not too efficient. Allegro keeps a double buffer internally and calls X11 functions to update regions of screen. So if my game implements double buffer, it has excess copying from memory bitmap to screen bitmap (which is actually also a double buffer in fact). It is probably impossible to get anything better without changing Allegro API. But something more efficient would probably be to draw directly on 'screen' bitmap and then calling something like update_screen(x, y, w, h) function.

I never worried about efficiency until started porting ufo2000 to Nokia 770, and it currently provides only about 10FPS.

Quote:

For the fullscreen problem, you may want to check the work that Hans de Goede has been doing over the past week. It looks very good, though I haven't tested it myself yet.

Thanks, it seems to works :)

ImLeftFooted
Member #3,935
October 2003
avatar

Quote:

Now a question about allegro architecture. Looks like at least in X11 mode it is not too efficient. Allegro keeps a double buffer internally and calls X11 functions to update regions of screen. So if my game implements double buffer, it has excess copying from memory bitmap to screen bitmap (which is actually also a double buffer in fact). It is probably impossible to get anything better without changing Allegro API. But something more efficient would probably be to draw directly on 'screen' bitmap and then calling something like update_screen(x, y, w, h) function.

If you use 'page flipping' it overcomes this extra buffer.

Evert
Member #794
November 2000
avatar

Quote:

And locking threads after a week is a strange choice. I don't always have enough time for developing stuff that fast. Sometimes I take a break for a week or two, and then oops - thread is already locked :( Probably a lot of people feel the same. Especially it concerns the threads in 'allegro development' section, they are probably less frequently updated than some chit chat topics :)

Yes, maybe the Allegro Development forum should be less restrictive in locking threads. It's one of the (many) reasons I personally prefer the mailing list over the forums for development.

Quote:

Looks like at least in X11 mode it is not too efficient. Allegro keeps a double buffer internally and calls X11 functions to update regions of screen. So if my game implements double buffer, it has excess copying from memory bitmap to screen bitmap (which is actually also a double buffer in fact). It is probably impossible to get anything better without changing Allegro API. But something more efficient would probably be to draw directly on 'screen' bitmap and then calling something like update_screen(x, y, w, h) function.

4.3 has this (but it still uses the 4.2 display driver) and can, in principle, do this more efficiently. For 4.2, there's not realy anything we can do though.

Quote:

If you use 'page flipping' it overcomes this extra buffer.

Page flipping doesn't actually work on X11 though (you can sortof fake it, but I doubt it gains you anything).

Kitty Cat
Member #2,815
October 2002
avatar

Quote:

Page flipping doesn't actually work on X11 though (you can sortof fake it, but I doubt it gains you anything).

Depends on how you use it. Since the page flip is done by using an extra large screen buffer, drawing directly to a "vram" bitmap would allow you to use Allegro's double buffering as normal double buffering. It'd store the changes off-screen then blit the new buffer when you show the bitmap. So you'd basically get:

game->screen buffer->x display
instead of
game->double buffer->screen buffer->x display

But by the same token, drawing directly to the screen causes Allegro to have to perform extra clip checks on each of the operations which, if you're drawing out-of-view, will always fail and waste time.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Go to: