My first draft of this class quickly showed me the error of my ways, as the coordination of the multiple sub-sprites would be extremely difficult, due to scaling and flipping, for example. Especially scaling.
Unless.. the multiple subsprites were co-located - i.e. had the same position (which is a CENTRE position), even if this meant they had a lot of transparent content in them.
Once you do that, however, there's no longer any need for a composite class. You just mirror certain characteristics of the main sprite (position, scale etc.) on the subsprites, eliminating the need for a composite class.
Easier still, make the main sprite and the principal subsprite as a single sprite with all the necessary animations - say, the boat and its wake, and use a separate sub sprite for each of the other animations required.
So, long story short, no composite sprite class.
I'm now ready to start setting up a more satisfactory demo version with some interesting action, so I'll be working in Povray a lot - a condition that isn't conducive to much reporting from me.
I'd like again to appeal to anyone who wants to collaborate on the Povray side. I'd be delighted to share the load and the credit with you.
Meanwhile, and this is the problem with me, I've seen another possible use of the Jade engine and I keep thinking about that instead of getting on with what I should be doing!
(below) Junk sprite with bluescreening.
This is a "game" with just six scenes, and very little to do except pick up a candle and drop it, but the music and sound effects are there, and the options.
Try it if you dare. Actually it is very benign as alpha versions go. Other than its own running space and private data, it only uses the media player, and surrenders or pauses that whenever it loses focus.
It works for me on my Android Xoom, but I'm interested in the behaviour of other platforms.
From left to right the options are Quit, Restore, Save, Music On/Off, Inventory, Pause.
Double tap to pick up and drop the candle.
The next activity is definitely the prototype game. I've got all the elements I need in the engine now, I think. I just have to use these capabilities to write an acceptable mini game.
I've been a little disappointed by the appearance of some of my backgrounds on the Xoom. I'll experiment with less compressed jpg files.
package uk.co.amazonsystems.jade;
import java.util.ArrayList;
import android.content.Context;
import android.media.MediaPlayer;
import android.media.SoundPool;
import android.media.AudioManager;
public class JadeSound
{
// This class handles all sounds. There are two sound sources. Use soundpool for short
// transient sounds. A single soundpool does all the sounds.
// For background music and ambient sound, Use MediaPlayer. Each sound is a new mediaplayer.
// Only one sound can be running at a time. All such sounds are looped.
public static final int OK_SOUND = 0;
public static final int BAD_SOUND = 1;
public static final int NOSUCH_SOUND = 2;
public static final int BAD_PLAY = 3;
private SoundPool soundpool = null;
private static int CHANNS = 4; // Sound Channels
private String soundName; // current ambient sound name
private int [] SFX = new int[CHANNS]; // Stream IDs
private int priority = 1;
private int soundid[]; // Sound IDs
private Context thiscontext;
private MediaPlayer mp;
private ArrayList soundfiles;
private int buggins;
private boolean soundstate = true;
// Initialise
public JadeSound(Context JadeContext, ArrayList SFXFiles)
{
thiscontext = JadeContext;
soundfiles = SFXFiles;
if (soundpool != null) soundpool.release();
soundpool = new SoundPool(4, AudioManager.STREAM_MUSIC, 0);
int temp = soundfiles.size();
soundid = new int [temp];
for (int ii = 0; ii < temp; ii++)
{
int resid = getRaw(thiscontext, soundfiles.get(ii));
if (resid == 0)
{
soundid[ii] = 0;
}
else
{
soundid[ii] = soundpool.load(thiscontext, resid, priority);
}
}
for (int ii = 0; ii < CHANNS; ii++)
{
SFX[ii] = -1;
}
buggins = 0;
}
public int playSFX(String name)
{
return playSFX(name, 0);
}
public int playSFX(String name, int Loop)
{
int index = soundfiles.indexOf(name);
if (index == -1)
{
return NOSUCH_SOUND;
}
else
{
soundpool.stop(SFX[buggins]);
if (soundid[index] != 0)
{
int reply = soundpool.play(soundid[index], 1, 1, priority, Loop, 1);
if (reply == 0) return BAD_PLAY;
SFX[buggins] = reply;
buggins++;
if (buggins >= CHANNS)
{
buggins = 0;
}
}
else return BAD_SOUND;
}
return OK_SOUND;
}
public int playAmbient(String name)
{
// if the same sound name, just exit immediately
// we use the same mp we used last time, and keep playing the same song
if (soundName != null)
{
if (soundName.equals(name))
{
return OK_SOUND;
}
}
// if the media player still in use, reset it, release it and null it
if (mp != null)
{
mp.reset();
mp.release();
mp = null;
}
// remember the new sound name for next call
soundName = name;
// find the sound file in raw
int resid = getRaw(thiscontext, name);
// if it's not there, return
if (resid == 0)
{
return BAD_SOUND;
}
// Finally, create a media player
mp = MediaPlayer.create(thiscontext, resid);
// if it doesn't work, return
if (mp == null) return BAD_SOUND;
// Ambient always loops
mp.setLooping(true);
// start the playback
mp.start();
// if the song flag is false, pause it
// we may have to start it later
if (!getSoundState())
pauseAmbient();
return OK_SOUND;
}
public void pauseAmbient()
{
if (mp != null)
{
mp.pause();
}
}
public void resumeAmbient()
{
if (getSoundState())
{
if (mp != null)
{
mp.start();
}
}
}
public void pauseAll()
{
if (soundpool != null) soundpool.autoPause();
pauseAmbient();
}
public void resumeAll()
{
if (soundpool != null) soundpool.autoResume();
resumeAmbient();
}
public void closeSound()
{
if (soundpool != null)
{
soundpool.release();
soundpool = null;
}
if (mp != null)
{
mp.reset();
mp.release();
mp = null;
}
}
public void setSoundState(boolean state)
{
soundstate = state;
}
public boolean getSoundState()
{
return soundstate;
}
// Helper method that translates a filename in res/raw to a resource id
public static int getRaw(Context context, String name)
{
return context.getResources().getIdentifier(name,
"raw", context.getPackageName());
}
}
Having further considered the matter of the GUI, I've decided to base it all on sprites, rather than a special screen. It is probably neater, and certainly more efficient. So another carefully designed backdrop hits the wastebin.
Anyway, I've made a little progress with the game but I don't want to go too far without testing my changes on the emulator which I can't do right now.
re. Bundle management
For simplicity, it's best if the game restore string for orientation is the same structure as the optional game save file that's stored locally.
Therefore, I am not going to make use of the Key:value pair structure in the Bundle except to label the whole save string.
In addition, since the game may be updated/altered, the save string must always be forwards/backwards compatible.
Must watch out for possible duplicate keywords e.g. spritename/scenename both called "pause"; imagenames will often be the same as sprite/scene names. Partially identical names in the savestring could also be problem, as we search it for spritenames among other things. Perhaps all keywords in the string should be uppercase and preceded by a type letter. e.g. S for sprite, R for scene(room), G for general state markers.
re. Scene alteration
Mostly, changed or additional zones with new destinations. Occasionally, delete zone. Sometimes, different image(s) or music.
So, for any alteration - like an open door with a new exit, we just have a key in the save string that causes us, on restore, to call a method in JadeData which makes the alteration.
Sprite images will be collected full size. On scale change in the sprite, they will be re-scaled in the sprite's image list.
Decision 2:
View scaling will be done at doDraw time. After all, it's only one rescale per sprite.
Another decision is that Sprite position will be the position of the Sprite centre.
When to scale the Sprite image(s) for screen size? This should be done at scene change, not "just in time".
There is also a scale factor for Sprites which is independent of screen size, and can happen during a scene. This should be done "just in time".
The new Pause facility will act like an Inventory scene, with all the features previously supplied by Javascript buttons - music, save/restore, Inventory.
Contrary to my previous assumption, I think quite a lot of Bridge code will transfer across to Jade.
It appears that most graphics Android apps consist of a kind of basic Activity, and a separate Class, a subclass of View, for the work and the display. I'm currently wondering whether I should do the same, and include all the Sprite / Scene / Data Management etc. classes within the View subclass. I'm revising scoping rules etc.
I was originally planning to put the initialise data in an xml file, but I now feel that my BridgeData class is actually more efficient, involving less iteration and parsing at startup and restart.
I found the Vector class very handy in Bridge, but I guess it's time to use these smart list classes.
I shall retain the off-screen buffer model from Bridge, do all the original artwork at full size, do vector movement etc. off-screen, then blit it into the View canvas when it's done. So at each screen size and each orientation, I'll calculate suitable View dimensions. Then I'll leave it to Java to scale the OSB to the actual screen. This is instead of doing the screen construction inside a Thread.
As for the GUI, there will be a "Jade" button (actually a Sprite) on every screen. Touching it will pause the game and allow the user to make various choices (it will actually be a virtual scene, like Inventory and Limbo). Choices include music, save, restore.
There will be differences in the cursor and carrying GUI, due to touch rather than mouse screens.
I think I can retain the cookie format of save data.
