Exult Forum

i think a small vertical bar of buttons on the left side (say 20px wide?) would be unobtrusive enough. whether the screen is squished or stretched would be incidental at that size

buttons for esc, i, s, c, k, t? tryin to think which would be most useful vs less used stuff like f/g/w

I also think that it is a good idea to have buttons common hot keys on the side. Maybe they can also be dragable.

data\pocketpc has a virtual keyboard that minimizes. That would probably be good for the Avatar name stuff. It seems too big for constant use on a lot of systems (206x83). keypad.shp seems to have some buttons that would be good for hotkeys.

There's a new snapshot with buttons down the side, some of which do something (T, I, S, Q). These are regular Android buttons at present, but I think they'd look better with letters from one of the U7 fonts. Note that 'Q' exits without prompting.

I'm trying something new with targeting: You drag the mouse (or finger) around, and the object underneath gets highlighted. Then you release to activate or choose that object.

Can you put up a new screenshot of this? I'd really like to see it

Just added it to my Facebook album.

works pretty good, i like em. is there a resource somewhere with the font somewhere in exult thats easily accessible, I could maybe whip up some 'themed' versions of the buttons

also discovered man it is hard to pick up a key in the game with fat fingers haha

I think you can use ExultStudio to export font shapes as .png files, and then we can use those images on the buttons.

Does the 'target' mode help for picking up small objects?
Guess I should work on 'zoom' fairly soon.

most things its ok, even things as small as buckets or food etc

but keys are a PITA since theyre like...5 pixels

Okay, 'zoom' will be the next feature as soon as I'm done with the 'stats' display.

ER... just realized the 'target' command does nothing for picking up an object. Any suggestions? Maybe a 'P' hotkey/button for picking up something and then giving it to someone? Or maybe 'T' should only select the object, and then you either double-click or drag it after it's been highlighted.

How about this?

Create a mode that allows the user to touch-screen select a box area. This opens up a more finger-friendly menu to choose among all objects within that box. Then you determine if you want to use it, or pick it up. Fingers just aren't pixel-perfect .

D.

I am interested in try the SDL port. I have several games, GemRB and ScummVM which use Pelya's SDL port, and they work surprisingly well.

Darren: That sounds pretty good.

@ShadowJack:
Discussion to port various games to pelyaSDL is currently on anddev.org
http://www.anddev.org/code-snippets-for ... 8-495.html

I tried building the current exult on pelay's SDL, but there are some linker problems currently.

If you would like to help, maybe you'd like to pay a visit to the thread.

@the Rest:
I still favor a full blown Java port of Exult like discussed here, but an SDL port would be able to follow the main branch better. I think both solutions are worth exploring.

@ShadowJack:

I've got a pelya port up and running, but the input needs a lot of tweaking to be usable. I haven't had much time to work on it though so I'll go ahead and get some patches posted on a new thread in case anyone else wants to experiment with it. I did get the music working - amazing what a difference it makes when you actually copy the ogg files over...

Ken

@KenC:

Could you please post your version of exult, or .diffs and build instructions? If its working, pelya can put it into the repository for pelyaSDL.

Sorry, I didn't notice you already posted it in a different thread.

I've continued working on this; but I wonder if it's still relevant, given the speed at which the native port is happening.

It still needs a good interface. Two reasons you started this project probably still exist.

1: To learn Java
2: To relearn the Exult code base


I don't think the Android port should use some third party SDL. It would be nice to use SDL 1.3 instead so that other systems can use it. The main difference with 1.3 should be needing to redo video since their backwards compatibility with it sucks and Exult will not even initialize video without changes. 1.3 should have better hardware acceleration than 1.2 for most operating systems.

If you don't feel like working on the Java port anymore, maybe you can work on an SDL port to Android. SDL 1.3 might actually get a release this decade.


One thing that could be done to easily fix some interface issues is just to have a patch that increases the size of the items that are troublesome to manipulate. This would also mean having a special patch for the Keyring Mod. Since the Mod doesn't seem to be actively develop with new features, it shouldn't be hard to maintenance.

Actually, I don't really mind the third party SDL port. I Just would like to have 1.3 support. That opens up the doors for an iPhone version that may even be able to share touchscreen code. (Of course, I don't have an iPhone or Android phone.)

@Malignant: I've successfully compiled exult against the official SDL 1.3 for android (the Google Summer of Code port), but never got close to displaying anything on the screen. The Pelya port includes both SDL 1.2 and 1.3, so I can give a try building against 1.3 at some point and see how it works, although your comments about backwards compatilibity and initializing video don't sound encouraging.

@DrCode: Whether development continues on the Java port or not, I should think the ideas and work on improving the interface for android devices could be carried over to the native port. I don't really consider the native port playable at this point because of input problems (at least not on my N1), and I don't know when I'm going to have time to do any work or testing to improve that situation (I started working on this port before my daughter was born, and my free time has mysteriously dwindled since then).

@KenC:
I think pelya has broken SDL1.3 again, but he is always fixing it again afterwards.

About the native port interface: Once you get used to it, its quite playable. I managed to play to Cove without greater problems. But there is work to be done, of course.

> I've continued working on this; but I wonder if it's still relevant, given the speed at which the native port is happening.

I hope you continue working on it. I was really looking forward, not necessarily to Exult on Android, but simply having Exult in Java.
I see many advantages to a Java Exult:

- Porting to new, future platform would be less of an issue with Java.
- Many new, younger developers will be more inclined to work with Java code than with C/C++ code.
- Java enjoys the best support for 3rd party tools, libraries, scripting/inter language support. Once it runs on the VM, you can extend it in almost any language you like.
- A Java Exult might give the project a new boost due to the huge Java community.

Continuing work. The last major missing pieces are:
1. Combat
2. The starting menu screen.
3. The video at the start. (Wonder if we could just record the video, as it would be easy to play a standard video file.)

... and of course, lots of bugs, and interface issues involving the small touch-screen.

the intro video is already up here http://www.youtube.com/watch?v=JfqOZlNxbfI should be pretty simple to pull the video file out of it and convert it to whatever format it needs to be

no subtitles when the guardian talks tho

ripping the video and bundling it sounds like something the legal department wouldn't like...

Before doing that I'd rather leave the intro out. You want to play the game not watch the video (though, well, the endscene you might want to see)

Yes, Dominus is right. But maybe we could provide the videos as separate downloads like we do for the sound-effects.

Or... I think Android can play a video straight from a URL, so we could link to them on Youtube.

Can't you just rewrite the flic folder into Java and use the timings, etc. in the bggame and sigame files?

Size Patch

This patch increases the size of many shapes by either using an alternate frame or resizing the image and adjusting the outline. It should work with BG, SI, and the Keyring Mod. (I don't know if this Java port supports patching and mods yet.)

Things like increased gem size and venom look a bit off. Most shapes should look alright. Hidden keys are more visible but I can't really increase the size of the buckets or plants.

Malignant: Rewriting the animation code in Java is probably what I'll do.

And patches are, in theory, supported, but I haven't tried yet and might have skipped over some of the code. As it gets more complete, I go back and fill in the gaps.

I've gotten pretty far, to the point where I have a combat question:

In Exult, it seems like an NPC or the Avatar will stop attacking an enemy when that enemy falls asleep (because his HPs go too low). Is this how the original worked, and does it make sense?

i seem to remember that being the case, cuz i specifically remember having to doubleclick the downed enemies for a coup de grace

man thats thinkin way back tho...

You probably want to make get_effective_alignment work properly for party members who are neutral alignment since the Avatar starts out that way in SI. I think the cheat to add party members doesn't change the alignment to friendly either. Since Exult doesn't do this at the moment, it makes Combat_schedule::find_opponents unnecessarily complicated and likely screws up in some places like the patrol schedule.

I'm thinking something like the following for the beginning of get_effective_alignment (for C++ Exult).

Yep, that's the way it used to be. Simply run U7 in DOSBox for comparison. Makes sense, too, forcing the player to murder a helpless enemy - the Avatar wouldn't do something like that, would he?

Exult currently kills them if all opponents are unconscious which is something I broke when I fixed enemies not killing party members if they were disabled.

Okay, I think I see now. Since I haven't done a sync in a long time, what I'm seeing is that if the party members are all asleep, the attackers ignore you and them, and there's nothing to do until you wake up. Sounds like you fixed that.

Another possible bug: The dragon's breath weapon has a 'ready' spot of 1, and this means that Exult's 'ready_best_weapon' routine doesn't identify it as usable. So the only time dragons actually use it, I think, is when it happens to get added to the right spot by chance during the creation of the monster. Perhaps non-human 'monsters' should be able to use a weapon from any spot, but I don't know if that would break anything. For example, are orc's given the 'human' shape class?

Whoops, nevermind! I see you already fixed that.

I added a fix for the dragons and some other spells a short while ago but just added the extra slots needed. (SI uses different slots than BG for these) I also made a tweak to better check shield equipping. They were done in revisions 6823 through 6825.

Okay, I think I see now. Since I haven't done a sync in a long time, what I'm seeing is that if the party members are all asleep, the attackers ignore you and them, and there's nothing to do until you wake up. Sounds like you fixed that.

Yes, but I forgot to exclude party members from attacking asleep npcs. (or it only applied to non-party members in the first place. I haven't checked the code.)

There's also a problem with combat at a short distance (distance of 1 or 0?) that was likely broken by the not having large npcs (like dragons) hit themselves fix.

Blech! Can't seem to connect to web.sourceforge.net to upload anymore:

Add correct host key in /home/jeff/.ssh/known_hosts to get rid of this message.
Offending key in /home/jeff/.ssh/known_hosts:12
RSA host key for web.sourceforge.net has changed and you have requested strict checking.

Okay, figured it out. Computers sure are a PITA.

There's a new version out there with lots of features (and probably lots more bugs).

I still need to find a way to enable easier moving and targeting of small objects.

I decided to force base party alignment to friendly and fixed the regression that caused party members to attack unconscious npcs.

Hey, I just got a real Android phone, and I now realize that the UI needs a LOT of rework. First, those buttons down the left side looked fine in the emulator, but they're way too small for my fingers on the phone. I'll have to replace them with bigger and fewer buttons.

Then the target mode is almost useless because the cursor is under your finger where you can't see it. I think the cursor should be a few mm. to the left and above where you're touching, so you can see what's being highlighted. Then, the 'target' should just select and highlight the object, so you can have the choice of clicking it to activate, or dragging it to put it somewhere. But that should also display a little offset from where your finger is so you can see what's going on.

I'm still thinking about this and probably won't be able to work on it for a few days. Most of the other functionality is done, other than the opening screen and the videos. But there are loads of features I haven't tested at all yet, which is why I haven't put out a new snapshot.

He he, a real device certainly seems to put it all into the right perspective again
Happy working on it and if you can you should post another screenshot with targeting and/or the buttons and such...

Button size should be variable due to differing finger size, display size, and resolution capabilities.

*rant*
it would be nice if we could add all the buttons and their function in trunk so we can have a more unified gui on all the different platforms. Right now every console/phone port does its own.OTOH there are always special needs for each platform...
*rant*

Yea, this is tricky. My phone (LG Optimus V) doesn't even have a keyboard. I see that all the apps bring up a virtual kbd when you start to type in a text field, but I haven't seen how to do that yet for our file save/restore box.

The other Android port has asked to be added to Exult trunk. Taking a look at their code might help you with ideas. Maybe you could try collaborating a bit now that your own port has gotten pretty far.


Edit:

Maybe you could try collaborating a bit now that your own port has gotten pretty far.

This quote pertains mainly to interface.

Dr. Code seems to have found time to work on this a bit lately. (2 commits this week)

Yep! I'm working mostly on user-interface issues, now that I have a real phone and can see how difficult it is to play on a small touch-screen. I've implemented 'zoom' via a menu button, though I'm struggling with crashes. Next is to have 'pinch-to-zoom'.

It also looks like I'm going to need to write a completely new 'save/restore' screen as a native Android dialog for those of us without real keyboards.

The target ('T') command has changed: It now shows a cursor, and you don't have to put your finger on it to drag (which made it hard to see what you were dragging it onto). When the cursor is over an object, it gets highlighted in red, and releasing your finger is like double-clicking it. I think we need something similar for picking up and dropping objects. Another change is that in conversations, you can drag with your finger, and each choice gets highlighted when you move over it; then releasing will select that choice.