It’s already a day or two ago that the new site went online, it isn’t completely finished yet but it’s far enough to be shown.
The site is now powered by Drupal and the blog is running WordPress.
What I like the most about it, is that the blog looks almost the same as the rest of the site, that’s because the theme is based on the Absynthe theme.
Although Absynthe is originally a WordPress theme it has been ported to drupal. (link)

Have a look around: http://pagesofadventur.sourceforge.net

Comments are welcome!

A while back I talked about a new artist.
Here’s something he worked on:

Click to enlarge

Here’s another development update, it isn’t an exciting one mainly because there hasn’t changed a lot since the last.
The biggest change this time is converting the use of the scene id by the scene’s name.

It has several advantages to use the name instead of the index.
Here’s the situation before the change:
swappoint(54, 8, static) {
destination = 3,0,11,1
}
As you can see the destination is to scene 3. But which scene is scene three?
That depends on the order of the scenes which are defined in the World file:
Home
HomeInn
Farm
CastleHall
Artefact
The counting starts by 0, so the third scene will be the Castle Hall.
But what if the order of the scene changes, this means we need to change every destination to point to the new index.

Luckily this isn’t the case any more, the new swappoint code will look like this:
swappoint(54, 8, static) {
destination = CastleHall,0,11,1
}
Although the index of the scenes is still decided by the World file it isn’t important any more since it checks the scene name.

I hope to make more changes but I’ll be unable to do so the next few days.

The new loading system is in revision 108. It’s been a long time since the last update, and although there aren’t many changes some of them are quite big. One of the most important changes is the new loading system. There’s now a separate loading thread that loads the resources in the background. And while the loaderThread is loading the main thread will display a loading screen. This causes faster load times and PoA doesn’t freeze any more while loading.

How does it work?
The concept is quite simple, you have two threads running, the one loads the needed resources and the other waits until the resources are loaded. Although this sounds easy it turned out to be a real challenge. One of my first and biggest problem was the fact that openGL runs in one thread and isn’t thread safe. So any action requiring openGL commands must be run in the openGL thread. To “solve” this problem I’ve split the loading of resources in two, loading and preparing.

In the loading process the data is read from files as much as possible.
When the main thread has time left (at the end of an update cycle) the thread will prepare a resource if there’s one to be prepared.

The components
The loading system consists of multiple components, these are divided over two threads, the main thread and the loader thread.

• ResourceHandler, contains all the resources of the game and checks if they are loaded when needed.
• ResourceLoader, used to communicate between the main thread and the load thread.
• Loader Thread, waits for resources to appear in the ResourceLoader’s load queue and loads them.
• Resource, an interface that can be implemented by classes so that they can be added to the ResourceLoader.
• ResourceStack, a special resource containing other resources which will be loaded and prepared after each other.

Following a resource

To explain the process of loading a resource I’m going to give an example of an NPC which is being loaded at the start of the game. The game starts and the player continues his save game. The main thread loads empty NPCs, Scenes, Items, etc…

They only contain there name, ID and location, which is used to determine if they should be loaded for a certain scene. The empty entities get added to the ResourceHandler’s list and that’s where our NPC is now, waiting to be loaded.

The game needs to load the scene to start with and asks the ResourceHandler if all the needed resources are loaded. If not, which is most likely at the start of a game, the game requests an ResourceStack. The ResourceHandler loops his list and adds any resource that’s inside the needed scene. And our NPC is in it.

Now the game gives the ResourceStack to the ResourceLoader which will put it in his load queue with the highest priority. And signals the LoaderThread. If the LoaderThread has finished a resource or is sleeping it will react and gets a new resource to load. In this case the resource stack, since it is set with the highest priority.

Now the loading begins and the ResourceStack loops his resources and call their load method. When it’s our NPC’s turn it will load his stand and walk images. To prevent rewriting a lot of code I made an Image wrapper which behaves almost the same as a normal Slick Image. The difference is that it will only load the image data and when needed prepares the Image for use in the main thread.

The ResourceStack finishes the loading and the LoaderThread reports back to the ResourceLoader and he will place the stack inside the prepare queue.

While the game updates it will check if there are resources being loaded. If so the main thread will in the meantime prepare resources since that needs to happen in the main/GL thread. And the images of our NPC are prepared.

Why the new loading system?
You might wonder why I’ve changed the loading system. One of the things you must realize is that the old loading system was rubbish. It loaded everything at the start, didn’t use some sort of deferred loading so the screen would render a loading screen and then freeze until everything was loaded.

What’s next?
Although it works it still contains a lot of bug. I hope to fix most of them in the next few weeks.

There hasn’t changed much since the last update because I was very busy this week. But I have some good news. The artist allowed me to commit my recent changes together with the new menu, HUD and player graphics.

What has been implemented is a “basic” worldmap and particle effects. Here’s a short video demonstrating some particle effects:

PagesOfAdventure Particle Effects from Edward Lii on Vimeo.

Particles can be placed in two layers. In the background, above the background tile layers, and in the foreground, above the foreground tile layers. Luckily Slick delivers a simple but powerful particle editor, Pedigree.

As I promised I’m going to keep you updated. I’ve mostly been working on weather effects and adding more audio effects. Let’s see what has been added:

First of all there’s now a basic implementation of weather.
Here’s a demonstration video:

PagesOfAdventure Weather effects from Edward Lii on Vimeo.

How does it work?
Every SceneState has an ArrayList of weather effects. The effects are loaded from the scene file and are declared like this:
weather = Overlay,0,0,0,0.6
weather = Rain,-0.1,1.5,2
weather = Thunder,5000,0.5
The effects will be updated and rendered in this sequence. The first effect is the Overlay effect, this will draw a color on top of the scene. In this case it’s a semi-transparent black.
The second effect is the rain effect, the rain has an speed of -0.1 along the x-axis and a 1.5 along the y-axis. There are two drops per 100x100px.
And the last weather effect is thunder. This will show a flash which slowly fades away. In this case a new flash will appear after ~5sec (5000 ms).

To make sure the weather isn’t moving with you it gets the Camera class passed with every update which contains the changes along the x and y-axis.

After a thunder flash a random thunder sound will be played. In total there are twelve sounds which I found on openGameArt.org here:
http://opengameart.org/content/thunder-rain-and-wind

Sound effects
I’ve also been working on some sound effects.

• Menu buttons now produce a click sound.
• Added PlaySound effects for conversations and EventPoints.
• Added Audio points which can play sounds with an radius, the further away the softer it sounds.
• No background music is now possible.