Jump to content

  • Log In with Google      Sign In   
  • Create Account

A Keyboard and the Truth



Pushing Ahead

Posted by , 20 July 2005 - - - - - - · 34 views

Found and Vaporized a few more save bugs yesterday (oy...)

Can't be positive but it looks like things are fairly stable now as far as saving is concerned.

For testing, I've saved smack dab in the middle of complex controlled sequences, involving lots of character motion and multiple scripts, and it comes back like nothing ever happened, so that is a good sign.


So, with that fixed, I am moving on to other things, namely, implmenting our, Company Logo/Intro/Credits.

At first we used Flash to mock some stuff up, and export to AVI, but this proved horrible.

The only way to save space was to use some compression codec, and then said codec would have to be distributed with the application, and installed.

We didin't want to get into that can of worms, so we decided to revive an old idea we had.


The Cinematic component was writen a long long long time ago (but not in a galaxy far away [grin]), and it's purpose was fairly simple.

Show images in sequence and with interpolated properties across key frames.


At the time, it fell far short of the glory, it was very hard to use and didin't have all the features I wanted.

Now however, I am going to re-tool this component and actually make it an engine component (so any game written with flare can have cinematics).

This integration we feel is fairly important, since during a cinematic we want to have everything else stop and full control go to the cinematic.

While this is achievable by the Application extension of the engine, it is a bit of a hack (multiplexing the User engine state), So instead we are going to create a new engine state for cinematics.

The goal we wish to reach is that playing a cinematic at any point is as easy as:

g_game.LoadCinematic("intro","data/intro.cine");
g_game.PlayCinematic("intro");


So what exactly is a .cine anyway?

A .cine file, like most files in the flare engine, is an xml document, which describes a component based 'movie'.

Here is what some sample XML would look like:


<?xml version="1.0"?>
<cine fps="30">
<layer type="image">
<image>data/frame0.gmb</image>
<keys>
<key frames="30" x="0" y="0" w="0" h="0" r="0" g="0" b="0" a="0"></key>
<key frames="30" x="0" y="0" w="0" h="0" r="0" g="0" b="0" a="0"></key>
</keys>
</layer>
<layer type="text">
<text>This is some text.</text>
<properties font="font1" size="32" halign="left" valign="top" wrap="true" clip="true"></properties>
<keys>
<key frames="30" x="0" y="0" w="0" h="0" r="0" g="0" b="0" a="0"></key>
<key frames="30" x="0" y="0" w="0" h="0" r="0" g="0" b="0" a="0"></key>
</keys>
</layer>
<layer type="sound">
<sound>data/sound1.ogg</sound>
<keys>
<key frames="30" alias="sound1" action="play"></key>
<key frames="30" alias="sound1" action="stop"></key>
</keys>
</layer>
</cine>



As you can see, the movie specifies at what FPS it would like to be displayed at, this is used by the TBM(Time Based Motion) system to make the movie play as closely as possible to the original intent.

The heart of a .cine contains a number of layers, layers overlap each other in decending order, so the last layer will appear on top of everything else. Each layer has a certain content type, at the moment only types "image", "text" and "sound" are supported.

A layer can have any number of "keys", a key is an instantaneous state of the properties of a layer, properties such as:

-x
-y
-width
-height
-red tint
-green tint
-blue tint
-alpha blend


A key also specifies how much space (in frames) it displaces, each subsequent key will be placed after the preceding key, in frame-time.

As time passes between these keys, thier properties will be interpolated (linearly, at the moment), using this functionality, more complex effects can be created such as, fading an image from 0 to 255 alpha, over the course of 30 frames.


When a .cine is loaded, the XML is parsed into an object model representing the movie, this object model can then be processed by the engine to produce the desired visuals.

.cine files have many pros and cons


Pros:
-very small file size compared to bitmaped video
-loads almost instantly
-less load on the system to play
-defined with XML, and so can have additional app-specific data
-no codec required

Cons:
-VERY hard to achive certain effects that bitmapped videos can
-No visual editors
-Doesn't look the same on all graphics adapter implementations


On the whole I think it is the best system for our needs =)




Beta Version 3.0

Posted by , 18 July 2005 - - - - - - · 35 views

Morning all =)

So, we have finally reached beta version 3.0

What is so good about 3.0 you might ask?

well...

1. Save/Load system implemented
2. Dialogue revised/spellchecked
3. Mana well trickle charges mana
4. lots of bugs fixed

the only major components that are still outstanding are...

1. The intro cinematic
2. The credits cinematic

and of course, the beta functions without them =D

this week, testing will begin on v3, and I will be working on improving the graphics and audio adaptors.

who will be testing v3?

well, Seriema is apparently away for a while, and rob loach is away as well.

So I have chosen one new beta tester for the present:

Superpig

YAY!!!! =)

he will likely be the first person to beta v3


Testing Day 4

Posted by , 15 July 2005 - - - - - - · 41 views

Not much happened yesterday, testing wise.

Ive removed my focus from the configuration window bug, since I have bigger fish to fry.

Right now my focus is on the save system, and removing the bugs from it.

Last night while debugging it I ran into a strange bug, which was causing it to crash.

Upon further examinaton it turned out that I was doing some HOOOORRRRIIBBLE =D

For Instance:


script=new Script();
script.Load(file);
process=new ScriptProcess(script);
process.ResumeExecution();
m_processes.InsertObject(process);


Looks fine and dandy? well it's not =D

the issue comes from these two lines:

process.ResumeExecution();
m_processes.InsertObject(process);

now, ResumeInstruction makes a script execute,
now depending on the script, this function could totaly finish before it even gets to inserting the process into the processes list.

This is bad because the executor is responsible for removing the process from the list. So if it did finish (and try to be removed) before it even got to the insertion, then it would insert it after the fact, WHICH IS BAD!!!! =D

so, a simple swap of things fixed it, not sure what I was smoking when I coded that ;)

m_processes.InsertObject(process);
process.ResumeExecution();


Somthing you may find funny =D

Saving is done through our engine by a pair of functions, Pack and Unpack, both of which pass an Archive object which is used for saving and loading data to/from file, respectively.

I discovered that the classes MWDoor and MWChest, were not overriding these functions, and as such were not getting thier state (such as opened,locked,blocked...) saved.

So a simple addition of a function and a few calls to arc->PackByte() and it's unloading counterpart UnpackByte(), saved the state.

However, when i run the program, I now have no doors =D

*scratches head*

now wait just a minute! [grin]

After a bit of searching I discovered that while I did override Pack and Unpack, I failed to call super in either [grin]

This of couse did not forward the superclass chain of processing and esentially did not save anything about the door object save for the few states in the subclass.

I found it rather funny =)




The current issue with the save is actually quite interesting =)

The save and load work fine, until i cast a single spell, or more precicely, added a sprite to the 'undersprites' layer.

if i save after this point the save goes fine
but when i try to load it again it cant seem to find said sprite in the reloaded objects list, strange indeed, and will require lots of tracing to insure that i am saving things properly *ugh* [grin]



Testing Day 3

Posted by , 14 July 2005 - - - - - - · 78 views

So day3 of testing went well.

Map4 Bug

Apparently Seriema's bug was indeed valid, I mispelled a variable name in one of the script functions on map4.

This is of course the only reason (IMO) why implcit variables suck, since if explicit declarations were neccisary it would have told me that $lphalpien was not declared, wherein $lphaliphen was =)

This bug was caused by my lazyness =D,
Before release I noticed a few issues I wanted to clean up and set about to do it. However I did not test all of these changes, and this one bit me in the butt =D

Naturally, this is an iron clad rule of development, and I am normaly good at following it, however I guess I was a little tired that day =D

Needless to say, this bug has been fixed, and the fix distributed to the testers =)

The Quit Bug

After some more testing, Seriema and I determined that the quit bug is being caused by somthing in the configuration dialog.

This dialog is made by CreateDialogIndirectParam, using an in-memory made template (evil). I am very unexperienced with dialogs and such, so I do not doubt this to be a valid reason.

It sounds like perhaps somthing is being left resident from the dialog and causing the process not to terminate. But I am unsure exactly what that could be at the moment =D

The Longest Test

Last night MW witnessed the longest test from ShoeStringGames,
They played for about three hours, and with some guidance from me (would have taken longer otherwise, due to proper exploration and all), they managed to find several (four i think) artifacts, and level about 6 times, as well as aquiring new runes (from purification) to make better spells, and getting better items to increase stats =D

All in all it was great, the gameplay seems to be going as we planned, and so far nothing has been too problematic. Durring this 3 hour test, not one showstopper bug killed the party =D
And most other comments were for added features, such as Mana Trickle Charge while near the well, which we are going to do =D








Games & Links

Recent Entries

Recent Comments



PARTNERS