Android port via Java - continued discussion

Ed · Post by Ed » Fri Jan 21, 2011 8:09 pm

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

Post by **Malignant Manor** » Fri Jan 21, 2011 8:14 pm

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.

Post by **drcode** » Wed Jan 26, 2011 6:16 pm

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.

Post by **Dominus** » Wed Jan 26, 2011 6:35 pm

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

Post by **drcode** » Thu Jan 27, 2011 1:51 am

Just added it to my Facebook album.

Ed · Post by Ed » Thu Jan 27, 2011 2:34 pm

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

Post by **drcode** » Thu Jan 27, 2011 5:26 pm

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.

Ed · Post by Ed » Thu Jan 27, 2011 5:30 pm

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

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

Post by **drcode** » Thu Jan 27, 2011 6:17 pm

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

Post by **drcode** » Sun Jan 30, 2011 1:42 am

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.

Darren__ · Post by **Darren__** » Mon Jan 31, 2011 9:53 pm

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.

ShadowJack · Post by **ShadowJack** » Wed Feb 02, 2011 5:13 pm

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.

Post by **drcode** » Wed Feb 02, 2011 5:32 pm

Darren: That sounds pretty good.

Summ · Post by **Summ** » Wed Feb 02, 2011 9:08 pm

@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.

KenC · Post by **KenC** » Thu Feb 03, 2011 4:34 am

@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

Summ · Post by **Summ** » Thu Feb 03, 2011 1:04 pm

@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.

Summ · Post by **Summ** » Thu Feb 03, 2011 2:18 pm

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

Post by **drcode** » Wed Feb 09, 2011 12:00 am

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

Post by **Malignant Manor** » Wed Feb 09, 2011 12:15 am

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.

Post by **Malignant Manor** » Wed Feb 09, 2011 4:15 am

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.)

KenC · Post by **KenC** » Wed Feb 09, 2011 6:06 am

@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).

Summ · Post by **Summ** » Thu Feb 10, 2011 3:57 pm

@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.

TDI · Post by **TDI** » Thu Feb 10, 2011 4:59 pm

> 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.

Post by **drcode** » Fri Feb 11, 2011 5:52 pm

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.

Ed · Post by Ed » Mon Feb 14, 2011 1:44 pm

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

Post by **Dominus** » Mon Feb 14, 2011 9:26 pm

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)

Post by **drcode** » Mon Feb 14, 2011 11:31 pm

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.

Post by **Malignant Manor** » Tue Feb 15, 2011 1:08 am

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

Post by **Malignant Manor** » Tue Feb 15, 2011 6:36 am

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.

Post by **drcode** » Wed Feb 16, 2011 3:14 am

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.

Post by **drcode** » Thu Feb 24, 2011 6:23 pm

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?

Ed · Post by Ed » Thu Feb 24, 2011 7:40 pm

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...

Post by **Malignant Manor** » Thu Feb 24, 2011 8:30 pm

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).

Code: Select all

	int real_alignment = alignment;
	bool avatar = (this == gwin->get_main_actor());
	if (is_in_party() || avatar)
		real_alignment = friendly;
	if (!(flags&(1get_main_actor())
		return friendly;
	int real_alignment = alignment;
	if (is_in_party())
		real_alignment = friendly;
	if (!(flags&(1<<Obj_flags::charmed)))
		return real_alignment;
	else switch(real_alignment)

TheOtherAlex · Post by **TheOtherAlex** » Thu Feb 24, 2011 8:31 pm

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?

Post by **Malignant Manor** » Thu Feb 24, 2011 8:38 pm

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.

Post by **drcode** » Thu Feb 24, 2011 10:30 pm

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?

Post by **drcode** » Thu Feb 24, 2011 10:37 pm

Whoops, nevermind! I see you already fixed that.

Post by **Malignant Manor** » Thu Feb 24, 2011 10:38 pm

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.)

Post by **Malignant Manor** » Thu Feb 24, 2011 10:42 pm

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.

Post by **drcode** » Fri Feb 25, 2011 12:36 am

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.

Post by **drcode** » Fri Feb 25, 2011 12:43 am

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.

Post by **Malignant Manor** » Fri Feb 25, 2011 4:47 pm

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

Post by **drcode** » Tue Mar 08, 2011 4:54 am

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.

Post by **Dominus** » Tue Mar 08, 2011 2:32 pm

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...

Post by **Malignant Manor** » Tue Mar 08, 2011 3:28 pm

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

Post by **Dominus** » Tue Mar 08, 2011 4:12 pm

*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*

Post by **drcode** » Wed Mar 09, 2011 7:38 am

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.

Post by **Malignant Manor** » Wed Mar 09, 2011 6:35 pm

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.

Post by **Malignant Manor** » Sat Jun 11, 2011 10:16 pm

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

Post by **drcode** » Mon Jun 13, 2011 6:12 pm

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.