[EDIT by Dominus:
When you read on in this thread, Dr. Code is in progress of porting Exult to Android via Java]

I'm interested in trying to make a working version of Exult to run on Android devices. But I found that in order to do this, a working model of the code has to be developed in Java, which could then be adapted to run on Android by switching out the platform specific graphics-handling.

The "working-model" should only be the game logic that parses the U7 game files, and handles running the game itself while making calls to the graphics and sound code.

Is there any additional code or anyone with notes out there that could help me with parsing the game-data files? If I had something that worked like a JUnit test that can verify if a game data file is valid or not, that'd be really helpful.

The arstechnica article is mentioning that the C++ toolkit is using JNI to hook into the java code. And if you've ever delt with JNI, you'd eventually realize it gets harder to maintain in the long run, especially when newer processors come out.

So, its best to not depend entirely upon the C++ toolkit just because Exult was developed in C. I'm just trying to plan ahead here instead of just banging out code for codes sake.

If someone manages to get started on this and/or get it working, please let me know at Ultima Aiera (http://www.ultimaaiera.com). I've been corresponding with Bioware Mythic, and they're getting pretty serious about seeing the Ultima games ported to mobile platforms...a working, reasonably non-buggy port of U7 to Android would probably be of interest to them, possibly even to the level of them giving it official sanction.

And no, I am not (to the best of my knowledge) kidding or being a jackarse.

:)
AsI wrote on your site, they should get someone to port Exult to Android and iOS. An experienced programmer should be able to do it. Basically Exult need sto be ported to SDL 1.3 and then you can go off :) (as has been done for ScummVM or Dosbox...)

--
Read the documentation and the FAQ are your friends! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!

1) It's Bioware Mythic (a.k.a. Bioware Fairfax), not Bioware (a.k.a. Bioware Edmonton) that's pushing this. That's a small distinction, as there is a lot of cross-communication between studios. But at least as far as technical distinctions go, Mythic is a separate studio from the one that pumped out Mass Effect, Dragon Age, and all the rest.

2) I don't know if they are hiring at this exact point in time, but their mid-to-long-term goal is to see the Ultima games ported to other platforms, especially mobile platforms. Paul Barnett, their Creative Director, is really stoked about iOS (iPhone/iPod Touch/iPad) ports, especially, though I'd imagine an Android port would also catch his attention.

At present, they don't have the means to develop such ports in-house; their time is given over to other projects of more immediate importance. However, I have spoken with Mr. Barnett personally, and he's told me flat-out that if someone comes up with a solid, reasonably stable port of e.g. U4 (or U7; I can't imagine he'd turn it down), he'd do damn near everything to make sure that it got published EA's mobile storefront(s?) (the App Store, and I'd assume the Android Store if they have one for that ecosystem).

If you've got more questions, drop 'em here and I can forward them to Mr. Barnett.

<rant>
Damn of course its only Android 1.6 or above..
I bought a stupid AT&T Backflip back in March and we're apparently Motorola's red-headed step child and are still on 1.5..
They say we're getting 2.1 and they're testing it but funny how for all of the non-US models of the phone they've cancelled it and decided they're staying at 1.5 for the best 'experience'...
Its the OpenGL they're having trouble with lately so Im guessing my phone wouldn't be up to playing Exult nicely anyways..
</rant>

It's not exult, but ultima7 works pretty well on my ipad via dospad (dosbox port). Should also work on iphone4 and I believe there's an android port of dosbox out there, although there's probably not anything as fast as the ipad running android yet.

For fun (strange idea of 'fun'), I've started converting Exult code to Java to run on Android. My initial goal is just to display one image from shapes.vga, but that involves a LOT of code. I'm pretty much just translating by hand from C++ classes to Java. Eclipse makes this relatively easy in the way it does syntax-checking as you write.

So far, I've written about 1200 lines of code and all I have to show is that I can read in the Avatar's shape.:-) But to display it, I need a palette, and that leads to bringing in most of the 'U7 file' code. Maybe tonight...

One thing that worries me about all this is that it doesn't look like an Android supports 8-bit palette graphics, which means we'll be doing a lot of converting from our 8-bit frame to its RGBA canvas. I don't know if an Android has enough CPU power for this.

@jeff, can yougive us some screenshots or photos of exult running on the android so far? Do you actually have an android or are you codeing halfblind through an android emulator? Your commits sound interesting ;)

@torgus, I'm sure the scummvm forums would be much more suited to find information on this.

--
Read the documentation and the FAQ are your friends! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!

I'll get a screenshot tonight, but don't expect a lot. What I'm doing is converting our c++ code to Java, skipping some things that I'll get to later and simplifying when possible. All that code (2000+ lines), and all I've got so far is the ability to render the flat terrains or paint a shape. No objects are created yet.

I only have the emulator to test with.

What worries me is performance. It doesn't seem like there's any builtin support for 8-bit graphics. So I'm painting into our own byte-array. Then on each 'blit', that gets transformed through the palette into a Color array, which then gets stored in a Bitmap (which looks like another big copy); and finally, that gets painted and stretched to fill the canvas/screen. That last operation is in the android library, so I'm hoping that maybe it's hardware supported. Seems like a lot of code being executed in Java for each screen refresh...

Maybe tonight I'll try to get the scene to scroll one tile on each refresh to see how many frames/second it can get.

Maybe it would make more sense to port the C++ code, but it doesn't sound as educational.:-) Also, I think debugging or getting support would be a real problem.

Looks very nice. Can't try it since I don't have an android. I'd root more for an iOS port :)
I'm still surprised that you need to do that much hard work for porting to Android. I was really sure that this would be much easier than porting to Java...
But as long as you are enjoying it... :)

--
Read the documentation and the FAQ are your friends! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!

A quick question though: you're trying to keep class to class compatibility between the codebases? There is a ObjectList class that is rather redundant considering the (rather excellent, except for very specialized uses, or primitive collections) java collections api.

The facebook album now shows that the actual NPC's are being created. The next step, which is probably going to take some time, is to have the Avatar be able to walk around.

What sort of interface should there be for moving the Avatar? I assume Android phones have a touch screen, but is there a common way to indicate dragging with a right-mouse button like we do in U7? Or would the arrow keys work, and then use the touch screen for dragging objects?

There are two places where you are using iterator in the oldest way possible. You should probably use a for each there. I would give you a diff file, but netbeans is being retarded and only allowing me to diff single files, so it would take more time for you to apply that than do it manually.

This won't speed anything up though. I suppose subversion commit rights are out of the question? I wouldn't actually touch the code, just refactor it around when not completely functional (that, now it appears to be).

Exult does use A*. I haven't added that to the Java version yet, but I plan to (although maybe that and a few other algorithms should be kept in C++ and use JNI). Generally, I'm trying to convert our C++ code fairly faithfully to Java, cleaning up a few things in the process. It's been a while since I've worked on Exult and this is giving me the chance to become familiar with the code again.

In ExultAndroid, you can walk right through walls now. Maybe I'll call that a feature.:-)

I'm wondering how the emulator speed compares with real devices. Anyone have experience with this?

source (note that clicking this link may not work, you may have to paste the link text into your browser window to actually download the zip file):
http://keithphw.freehostia.com/LineOfSight/src.zip
dependency jar (Java Topology Suite):
http://keithphw.freehostia.com/LineOfSight/jts-1.8.jar

There's some Android-specific code for handling events and painting the screen. The rest is pretty standard Java, I think.

Might be nice if someone implemented the Android Java libraries for use on a regular (Linux) PC. I'd imagine the performance would be a lot better, so I wouldn't have to wait 5 minutes for the debugger to get started.

DrCode posted earlier that he is only using an emulator. He wants feedback on how fast Exult is on a real device.

My experience with the official emulator was extremely poor speed for navigating the basic menus on a 2.4 ghz P4. I'm not sure how this runs in Wine, but there's a program called YouWave Android designed to run Android apps in Windows that is supposed to be focused on speed. I haven't tried it at all though.

I think I read somewhere that the emulator is close to the speed of real devices. I've noticed that it bogs down when receiving simulated events. For example, when I hold the shift key down on my real kbd, the emulator gets a stream of events, and gets really slow, even if I turn off my event handler.

As for doing a native port using SDL, someone could try that, and it might have a better chance of success. I want to get some experience with Java and Android development, plus I've lost contact with Exult's code for a few years; and that's why I'm doing it this way.

I unintentionally checked in the .apk file in our repository, though it hasn't been updated recently. Right now, you can just walk around as the Avatar (and walk through things), and click on items to see what they are. I've started writing the Usecode interpreter, but it will be a week or two before you can do anything useful.

So, yes, I would like to hear how the performance is on a real device. To run it, you'd store the STATIC directory under "/sdcard/Games/exult/blackgate", and it should work from there. But it's not very good at diagnostics yet if anything goes wrong.

Maybe you should remove the apk file, add an ignore on that file (so you don't add it again) and then upload the apk file you'd like feedback on to our snapshot space. You only need to sftp to our sourceforge webspace... We can then either add a direct link on the download page (i can do this once the file is uploaded once) or link to here...

You should be able to walk around (and through things) by holding the shift key and using the left mouse button. I notice that holding the shift key really slows down the emulator, so you can release it while keeping the mouse button down. You can also talk to NPC's now, but that's probably even buggier than scrolling around.:-) I'm going to try to get the opening working where the Avatar appears.

Hmm, I can't walk around. I start off on a black screen off the top left of the map. I can scroll around the map with the arrow keys, making the terrain and objects appear, and click on things, that's pretty much it. Don't see any alive NPCs either. Just a dead monk east of the Empath Abbey cemetery.

BTW, I've had little luck profiling. Trying it again tonight, it shows the most time spent reading in the item names and creating about 1300 name strings. Seems unlikely considering all the work that goes on painting and reading in objects (and sorting them).

Strange. I always find myself "avatarless" at the top left (or bottom left) of the map with a black screen, as if some initial repaint isn't happening. Only after scrolling around does the sea start to appear. I tried scrolling to Trinsic to see if the Avatar is there, but Exult always crashes before I can reach it.

I wonder, can it have something to do with the game files? I basically copied the patch, static and gamedat directory and the files from the root ultima directory that seemed important (all the files except TEMP... and SAVE...).

The only thing I changed in the code is change the base dir to "/sdcard/games/Ultima7"

Try it without the patch and gamedat directories. It will create gamedat using the initgame file in static. While I've been including code that accesses patch files, I haven't tried it at all, and there are lots of sections that I haven't included yet since I still consider this 'experimental' (or 'educational').

Also, you can see messages from the program in the 'logcat' view in the emulator, although I don't know where you could see them on an actual device.

You have to put the emulator in raw keyboard mode. There's a startup switch, '-raw-keys', or you can toggle it with ctrl-k.

I may change this, because holding a key down makes the emulator much slower. However, you can release the shift key after the Avatar is moving and continue just dragging with the mouse. Seems like there should be a better way, but I don't have a real phone to experiment with yet.

finally got back around and could try this out..it's crashing immediately after opening on my G2, using the APK that was previously posted. I've got the files sitting in /sdcard/Games/exult/blackgate as mentioned wayyy back, has the location for this changed? after launching it shows the Exult title bar with a blackscreen for about two seconds then force closes

trip report: doesnt run much slower than it's supposed to, far as I can tell (g2 clocked at 1.4ghz). avatar doesnt seem to run faster if you click towards the edge though, not sure if thats implemented. talked to iolo, got him to 'join,' wandered around trinsic without any crashes. nobody moves around and theres no 'interiors' but I'm guessing thats all just not in there yet.

all in all looks like a pretty solid start. holding shift and clicking to walk is odd, maybe not holding shift to walk and holding shift when clicking things to use/talk would be more intuitive/less work?

1. 'Blocking' - can no longer walk through things, but you can walk up stairs.
2. Roofs disappear when you walk inside.
3. Companions will walk around with you (but only if you stay close).
4. Books/scrolls display.

cool, glad to help. the only hangup i could think of with the non-shift click to move would be picking things up and moving them, but i guess a quarter-second 'long touch' on an item to pick it up would do the trick (or holding some other key?)

other than that list i guess also just an icon =D looking forward to future updates (like, super excitedly)

Neat. After some fiddling with files, I got it to work. I have a very modern android, which unfortunately lacks the key interface. I'm amused how I can use my 'laser scroll wheel' to move my view around the game map and double-click doors and lamps despite the avatar being stuck at the intro area.

Let me know if you're interested in some collaboration on the android api / java side. I'd love this excuse to learn the android API, and I'm pretty smooth with java.

The interface is going to be a challenge. For example, sometimes U7 pauses so you can click on something, like when you're using food. But there's no mouse cursor, so I'm thinking about how to let the user know this. Maybe we should show the 'click-on-an-item' cursor on the screen, have it move around with a light touch, and have it activate on a double click.

Perhaps that's also how the Avatar can move. We show one of the arrow buttons; you drag it around; and then double-click or press it harder (if all Androids can detect that) to control the Avatar.

Its easier to produce touchscreen phones than it is to produce ones with keyboards, and with current pricing schemes companies can charge more for touchscreen phones, so I imagine we'll be seeing more rather than less of them. Have an iPhone myself, so I wouldnt mind seeing an iPhone version. You could probably manage an onscreen keyboard for game particulars on an iPad version.

Many "mobile" games have touchscreen arrow controls for NSEW. A tap or double tap could be a click or double click. It would be a little awkward, but it could work. Not sure how to replicate a right click though. Maybe tap-and-hold? That would be awkward though.
---------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Thanks for the info. I'm still in the dark ages when it comes to phones.

I'm thinking there should always be a cursor drawn on the screen, normally one of the green arrows. To move the Avatar, you drag or hold down the arrow, and his speed depends on the distance to the arrow, just like in the original game. Then if you click or double-click anywhere else, you can activate objects or drag them.

You could make it so that if you tap and hold on the avatar, that would enable move mode, and then they would move towards where you dragged your finger, at a speed determined by how far the avatar is from your finger. That would seem the most intuitive movement interface for phones, though it may be difficult to program.

You could also maybe tap on the avatar and tap on a location to enable the pathfinding mode, or tap on the avatar and then an enemy, to enable combat AI to fight them.
--------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

One thing to keep in mind...
Some lower end Android phones (like mine) dont have multi-touch capability so you are only allowed to tap one point on the screen at a time. Could make it difficult for some...
Makes playing NES and SNES roms a pain in the butt hehe.

i think (after removing the shift) that the current touch to move works pretty well, if touching closer to the edge of the phone can make you move faster ala the original

as for keyboard v not keyboard, there arent a whole lot of keys necessary to play, other than the moving/clicking. maybe 4 onscreen transparent buttons in the corners or at the bottom or something for keyring, feed, map, and inventory? i realize there are more shortcuts in the game but those are all i can think of that are used regularly, and in the case of stats etc that can all be accessed from the paperdoll after hitting the inventory button

a few buttons onscreen isnt too intrusive, and keyboarded phones can just press their keys i guess! maybe with an option to turn off the onscreen versions if you dont need them in that case (similar to most of the emulators on the market)

I personally dislike the tilting of the phone movement. I can only speak of the iPhone, though...

I think a steering overlay for the thumb would be nice, with it using the arrow keys function and when you keep on a direction you get faster (the overlay should be placeable on each side).
So movement (not counting the double-click-pathfind-to-this-spot) would only be through this and the green arrow (or maybe use the crosshair instead) is for interacting.

An example could be this fromt he Dungeon Hunter game for the iphone. Along with an icon or two for turning on combat for example...
--
Read the documentation and the FAQ are your friends! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!

Hate how those interfaces take up almost literally half the display area, though. Having the interface as close to the original as possible (which is to say no gui unless you start needing it) is preferable to me. Ultimately up to whoevers programming it though, I suppose :-)
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Or if we're really masochistic we can program both interfaces and let someone choose :-)

And yes and no - some games are all graphics intensive like that, others are pixel games and tetris clones, so theres a fair diversity out there.
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands,ca

Ha, dungeon hunter is nothing, modern phone games can look like this: http://itunes.apple.com/de/app/infinity-blade/id387428400?mt=8
Infinity Blade looks stunning but lacks in story and is very short...
--
Read the documentation and the FAQ are your friends! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!

the new snapshot immediately crashes on my phone, in place upgrading the version that was on there previously, same /sdcard/Games/exult/blackgate folders/files. has anything changed re: where the files should be?

Added a new section on our download page for the Android snapshot and changelog. Since the Android port is not tied to our regular changelog, this looks better :)
(you might need to refresh the downloads page)

--
Read the documentation and the FAQ are your friends! There is no excuse for not reading them! RTFM
Read the Rules!
We do not support Piracy/Abandonware/Warez!

yup that did it, up and running again now. everything seems to still be going great, the movement works a-ok with one question: is it possible to make the area-which-counts-as-the-avatar a bit larger? as it is you have to be pretty precise to grab him to make him move, without hitting near him and not moving him, if that makes sense. i.e. a mouse cursor is easy to click him with but a fingertip is a bit less accurate. otherwise, going great

and i had way too much fun dragging the mayor around fyi i formally request this as a feature in the final build =)

Yea, I was wondering about using the touch interface with your finger, since the objects in U7 are so small. Maybe when you touch the screen, but aren't on an object, we should show a cross-hairs pointer. When you let up, we could remember the location (or maybe the object that it's on). Then if the next click is within a couple pixels, that's what we'd activate.

The latest snapshot should give you a 'too heavy' message when you try to drag the mayor.

The easiest way to give a larger target area for touch aiming is to make it the bounding box for the shape, but that may result in difficulties trying to select things very close to a NPC or the avatar. A better solution would be to increase the selextion area by x pixels, though that would be more difficult to program.
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Thanks! My biggest worry now is speed, especially in the emulator. My computer is a few years old, but shouldn't be all that shabby (Pentium D 2-core at, I think 2.8Ghz). I just added support for eggs, so now Iolo joins right away, and walking around with him is pretty slow. Or maybe the egg-detection is slowing things down. I'm worried that when I add pathfinding and NPC schedules, it will become impossible to use.

I'll work a bit on performance (blindly, since profiling didn't work the last time I tried), plus the user interface.

Running the Nexus One, unlocked, rooted, etc, so I'll take a look at this soon, and give feedback on performance.

Control Ideas:
-----------------
It is safe to assume that Android devices have a touch screen and either a ball-mouse or a d-pad that is clickable.

This would make a safe fallback of clicking the d-pad/mouse-ball to bring up inventory, tap to move, double-tap for double-click.

Optionally, mouse-wheel/d-pad to move when inventory is not displayed.

Additionally, since most (all?) phones out right now are essentially "widescreen" format, it would be safe to drop a couple on-screen buttons into the left-and right margins (combat mode toggle, perhaps?) without covering any of the playable area.

to Ray: not that its a huge number, but some devices are actually coming out with no trackpad/trackball. not just low end devices either but some of the big upcoming ones, like the Incredible HD. i dont know why, it seems kinda baffling to try to change the form factor now but who knows. sadly the only input method thats guaranteed to be on every device is the touchscreen, and even then youre not always guaranteed multitouch on every device or software version

Android platforms suffer from having very different input schemes. It may be beneficial to have a single-touch interface by default, and then the option to use additional other interfaces (dpad/trackpad/multitouch) to augment it. A single-touch touchscreen is really the only constant I think, so that would be the best "foundation"
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

Yes, for now I'm just going to assume that a touchscreen is present. For moving the Avatar, how about if dragging on the ground also starts him moving? Maybe with a double-click, holding down the second time.

I was gonna mention the input methods the other day and completely forgot to reply hehe..
But yeah Wizardry is right, best bet by default would be a single touch interface..

Lower end phones like my Backflip dont have things like trackballs or even a multi-touch display.. (Although we did somehow get a physical keyboard).. Out of the whole Motorola Cliq/Backflip family, only the CliqXT got MT capability in its 2.1 upgrade.

Leave the options in though I say!
Some phones have custom roms that enable things like multi-touch (the Backflip does although its still up in the air whether multi-touch is safe on the display and hardware) but the 'common man' might not be so technically inclined to root and mod his/her phone..

drcode, the doubleclick-hold anywhere to move you just mentioned sounds like a good spot to try. that avoids having to precision click the avatar at least when youre trying to move. still going to have to precision click a lot of other things but at this resolution shouldnt be tooooo much of a problem hopefully (scummvm on android had to deal with similar things and it works pretty alright most of the time)

you know since I mentioned it I went back and tried it again. this time it didnt do the earthquake at all. i mean it still 'happened,' everyone still danced around, but no vibration effect on the screen, not even at the edges.

I'm not overclocked this time though so I wonder if its a refresh rate/performance issue

just tried it again and got the couple pixels around the edges version that you mentioned, weird

also, and i guess this is more a further down the road option, but without a graceful exit from the app, if you leave and come back in it comes back in a weird state of confusion (Iolo starts his opening schtick even tho you're already there, etc). just thought id mention haha

The earthquake needs to be rewritten, but I haven't gotten around to it yet (low priority). It's a thread/race condition. What I'm learning about Android programming is that you can't have the main thread stall doing something that takes more than a second or two. So the screen painting, usecode interpreter, and save/restore run in separate threads.

The next snapshot will have the save/restore screen implemented. Got to see if I can detect when there's no keyboard so I can give default names.

Now I wonder how it would have been to port Exult in C++ using JNI like someone suggested above. Would it just be a single thread taking over the machine?

from what ive read i think yeah it just bruteforces everything thru a single thread which probably isnt great for performance? i cant imagine itd work well for something like this once scheduling etc is implemented

but i will openly admit my java background is...well i dont know if 'terrible' is the right word but its certainly not good haha

1. If it crashes right away, try removing the contents of the 'gamedat' directory and try again.
2. The opening scene is turned off in this version.
3. It doesn't restore games from the main Exult yet, but I hope it eventually will.

Let's leave the iphone out of this thread... ;)
But yes, iphone on the App store is not a very promising outlook. Same as Scummvm, a version that requires a jailbreak would be welcome ;)
Though personally I'd not use it on an iphone... On an ipad, though, sure would love it....

If it was on an iPad, I may actually buy one, because it would be pretty awesome. Especially if it supported TFL :P

Actually, speaking on that matter, there wont be/isnt any special accomodations I need to consider for having TFL work on these other platforms such as android, is there?
----------
Peter M Dodge
aka Wizardry Dragon
www.thefeudallands.ca

The Android port is a special case, as it is a rewrite and thus will have to have support for mods, patches, new games reimplemented. And later changes to the main branch need to be manually ported back into Android. So there are a lot of possibilities for it to break at times.
An iOS port wouldn't need that much rewrite. For iOS you only need to port current SVN to SDL 1.3 (which could be done through a compatibility header) and to make an xcode project file for it. Then you could probably already make it compile and run on iOS. You wouldn't be able to use it though, since the touch interface needs to be coded in as well ;)

Definitely not ExultStudio.:-) But I'd like to get all the rest working, but skipping support for some things. LIke the music might require the .ogg files, where normal Exult supports lots of different options.

And yes, rewriting might be a dumb thing to do, since changes to the mainline will have to brought in by hand.

DrCode, you might want to start a new thread with all the needed info in the first post. This thread already has more than 150 posts.

Quote:

For iOS you only need to port current SVN to SDL 1.3 (which could be done through a compatibility header)

There's more that needs to be done. There's some things defined in functions that had to have special definitions.

I have an for Win32 (probably works in other OSs without ES support) that compiles, but it fails when it tries to render. It seemed to crash at SDL_SetVideoMode (in window or fullscreen). Fullscreen only detected support for 16 bit.

Edit: The 8-bit video check in Image_window::static_init() was wrong. I have no idea why 32 bit isn't showing up.

Edit 2: SDL_VideoModeOK returns the actual res it can display which was 24

Edit 3: Screw it since it would cost $500 for a license to distribute it with the dlls on all Embedded platforms. ($100 dollars for only Iphone rights)

It certainly makes for a quicker proof of concept -- nothing dumb about that.
I think you'll be fine, so long as you separate the android-specific interface code as much as possible at this early stage, and then later if you want, you can conveniently wrap around updated 'native' exult cpp code (which both android and iOS will accept compilation for).

This may also require simultaneously separating some interface-specific stuff from exult, depending on how you want to go about that. I've never looked at exult code before so I don't know how platform-agnostic or SDL-independent the majority of the codebase is ...But maybe I will some time. Right now I'm knee-deep in xu4.

I don't know about performance on actual phones, but playing ogg files works fine on the emulator (probably because it's not truly emulated, but going straight to the sound system on the host computer). Right now, I'm doing what's simplest, and am pretty happy at how simple the audio code is in this version compared to classic Exult (which supports many different platforms and formats).

One major bug the trunk has is that the first time it changes the hour, the npcs will stop what they are doing and go to the next schedule (even if it is the same schedule and location). There's also an awkward pause that they do when changing.

Edit: Exult wasn't saving schedule locations properly so it returns 0. I've got a fix the first hour change in the trunk. I'm going to add the missing z coordinate in some unused spot (Exult Studio can set z locations for schedules).