I was about to make this comment in the thread http://www.allegro.cc/forums/thread/552648 but I didn't want to hijack it, and this is a separate topic anyway. In the thread I linked someone was mentioning about DX3 support and Allegro and I was noting how "old" Allegro is might be helpful to me.

I have been considering looking to see how hard it would be to port Allegro to Windows Mobile DirectX. Mobile DirectX is based off of the real DirectX, version 8. Porting Allegro to Mobile DirectX will allow Allegro games to run on Windows Mobile devices including PDAs and smartphones. Many PDAs are still at 320x200 resolution, but there are PDAs now (including mine) that do 640x480 res at 16 bit. So here Allegro's typical old-school style is helpful as the number of 320x200 and 640x480 games is high. Also some PDAs (like mine) are starting to come with hardware acceleration. My PDA has an Intel Marathon video card, which has 16MB of video RAM and is basically equivalent to an NVIDIA TNT2 card.

But -- the embedded devices that WM runs on are all ARM devices now. None of them have a math coprocessor, so there is no floating point math. So Allegro also happens to be well suited with its fixed point math functions and lookup tables for fixed point trig. ARM processors can do 32-bit integer math well, and run up to 624 mhz from what I've seen. Even the OpenGL-ES implementation that the Marathon card supports is all fixed-point math.

We all spend time lamenting about how Allegro was meant originally for a 25mhz machine that has low-level access and only software graphics... Well, now we have a case for that again in cell phones and PDAs.

Since Allegro was designed really to use only a minimum of DX features and the DX3 feature set, there's probably not anything that Allegro uses that isn't supported by the PDA, with the exception of good keyboard support and mice. This is probably the most important, because it means a game issue. All WM5 devices are required to have a 5 way D-pad, and every device I've seen has at least 4 buttons. So basically you are at the control level of an NES, but a ton of Allegro games will be able to fit into that control scheme and require minimal reconfiguration, although support should still be left in Allegro as WM5/Win CE supports keyboards for sure via IrDA or Bluetooth and possibly BT mice as well (I'm not sure on mice). The d-pad and phone buttons are mapped like keyboard keys.

What do you guys think -- am I crazy?

A rough order of steps to achieve this would probably be first to get a version of Allegro that is completely portable C code -- that means no ASM code for x86 of course and will compile cleanly on Visual Studio 2005 (a requirement for WM5 development). After that would be to remove all features of Allegro that don't make sense on PDA or add too much bloat. After that would be to remove floats were used, if possible. Once we have a trimmed down desktop version then we start porting to the mobile APIs. Ideally this trimmed down version is a direct subset of all Allegro functionality to make games source compatible between PDA/smartphone and desktop.

In theory, it is already there.

Under Linux I can give --enable-asm=no parameter to ./configure and allegro will compile without asm routines. Using that I can get Allegro to compile with Intel compiler really easily. I think if you find a way how to disable asm on windwos you could get it to compile with MSVC too.

Only problem is that there might be some things that still want to use some asm routines. These are mostly platform specific things and will probably have to be redone anyway on a new platform.

I think that is a little bit complicated in the sense that it will not be a "real" allegro then. Though I think it is possible to disable some parts of Allegro with compiler/preprocessor flags.

I'm not 100% sure but I think allegro doesn't use floats internally

A x50v or x51v?

I just picked up a 51v and it's sweet as hell, heh. Gonna start messing with OpenGL|ES over the break.

As for this project idea, SDL has been ported to wince, so perhaps it could be used or even wrapped to allegro?

Marcello

Of course, it has to for functions with floats in their signatures, but floats are also used in a few other places too. You should be able to convert those to fixed without any real hassle.

Just #define ALLEGRO_NO_ASM.

I have an x51v. I think that OGL-ES as the primary or initial path isn't the best for two reasons. First is that if I understand correctly, only x50 and x51 support OGL-ES. Secondly, All WM5 devices and I believe all WM5 smartphones are required to have at least a software implementation of Mobile DirectX. However, x50 does not have Mobile DirectX unless it has been upgraded (at a cost) to WM5, since it comes with WM2003SE.

The second reason why I was thinking to go with Mobile DX is that it is supposed to be based off of DX8 and I am thinking that since the Windows port already uses DirectX that it would be easy to port, and DirectX should use hardware accel where possible and software otherwise.

To support all devices we really do need to support both, if we want hardware accel. The GAPI has been around for a very long time for low-level graphics but it isn't hardware accelerated I don't think. Using GAPI will provide support I think all Windows Mobile devices that are worth considering now, but will provide the worst performance. Games were always kind of shady before, and MS is now trying to change these things by providing DirectX in mobile devices to start providing a consistent and complete platform to build upon. Honestly I see it as as big of a deal for gaming on PDA as it was for Windows 3.1 to 95. Before DirectX, gaming in Windows was more or less of a joke and was limited effectively to things like Solitare and poor performing other games. On PDA now it seems you either have to settle for awkward APIs and low performance or implement solutions that aren't compatible across different PDAs.

Maybe thats cause one of the planned distro's for AllegroPro was AllegroCore?