For the last couple of weeks I’ve been trying to come up with a good semi-automatic resource-loading framework for Plasmacore.  For each revision I added a new feature or two to Slag; I ended up not truly needing most of them but they’re good features nonetheless.  Here’s a quick overview of the new features – mostly by example.

Automatic Properties

First we have automatic properties that can be used when you have a single init method that stores each of its arguments into a property you’ve just defined.  Here’s an example of old code:

  class Person
    PROPERTIES
      name : String
      age : Int32

    METHODS
      method init( name, age ):
  endClass

Here’s the same code with automatic properties:

  class Person( String name, Int32 age )
  endClass

or even just:

  class Person( String name, Int32 age );

You can add additional properties and methods as you like.

In-Line Classes

Slag now supports in-line classes that work pretty much just like Java’s anonymous classes.  In addition, “METHODS” is now the default member category (so you can omit it if you start a class definition with a method), which makes in-line method definitions easier.  An example:

  class Operator
    method init:
    method apply( Real64 lhs, Real64 rhs ).Real64: abstract
  endClass
  ...
  method test( Real64 left, Operator op, Real64 right ):
    println( op.apply(left,right) )
  ...
  local Operator plus = Operator() with
        method apply( Real64 lhs, Real64 rhs ).Real64: return lhs + rhs
      endWith

  local Operator minus = Operator() with
        method apply( Real64 lhs, Real64 rhs ).Real64: return lhs - rhs
      endWith

  test( 5, plus, 3 )  # prints: 8
  test( 5, minus, 3 ) # prints: 2
  test( 5, Operator() with
        method apply( Real64 lhs, Real64 rhs ).Real64: return lhs * rhs
      endWith, 3 )  # prints: 15

Delegate Properties

Delegate properties allow you to specify that any unresolved method calls or property accesses be forwarded to one property in particular.  This is of particular use when you want to make one object that is essentially a proxy for another.  Example:

  class String
    PROPERTIES
      data : delegate Array<<Char>>
      hash_code : Int32
    ...
  endClass
  ...
  local String mesg = "Delegate *this*!"
  println( mesg.count )  # same as saying "mesg.data.count" - prints: 16

Only one property can be defined as a delegate.  Underneath the mechanism is very simple: at compile time failed member accesses are reevaluated with the delegate property.

caseNext

caseNext is handy in a which where you want to do something different every time based on a counter but you don’t really care what the case values are.  It just takes the previous case value (literal integer required), adds one to it, and makes that the new case.  For example, to load a different graphic (my plan is revealed!) each time a method is called:

  method load_next.Logical:
    load_index++
    which (load_index)
      caseNext: img_alpha = Image("alpha.png")
      caseNext: img_beta = Image("beta.png")
      caseNext: img_gamma = Image("gamma.png")
      caseNext: return false
    endWhich
    return true

If you started with “case 5:” then the first caseNext would be a shorthand for “case 6:”.  If you start with caseNext (as above) then it resolves to “case 1:”.

Some odds and ends:

ITEM: We finished up Wyrmhunter for the iPhone a week ago and submitted it to Apple.  They haven’t gotten around to approving it yet, but we’re hopeful it’ll be soon.

ITEM: One of the last major things was a revamp of my dynamic texture sheet management system.  With its already limited drawing speed, the best bet for the iPhone is to place all images on one big texture (or several), queue up a bunch of triangles as different images are drawn, and then render everything at once.  Even better is if you don’t have to lay things out yourself but can have Plasmacore do it for you as you dynamically load and unload images.

My initial stab at the problem worked well in some cases and very poorly in others.  I started out with one big region of unused texture.  Then after the first allocation I split it into several chunks – one used, the others not.  I decided to make everything below the used area one chunk and then the remaining strip to the right another chunk.  If the original free chunk were:

CC
CC

Then after allocation “A” it would be:

AB
CC

The problem was that I could end up with a whole lot of “B” chunks of various sizes that didn’t quite fit together.  There would sometimes be plenty of room to put something but no chunk large enough to put it in.  It was fragmentation but worse: it wasn’t that there were used areas, it was that the free areas were adjacent but slightly disjoint.

I beat my head against the problem for about a week and tried 6 or 7 different approaches.  I felt that the key was being able to span multiple free regions, but if I used regions as they became available then they were too disjoint, and if I used some sort of grid layout then the search area was too big.

Then finally I finally hit on the solution: when I allocated a region I would split the entire layout area (including all regions used and unused) along both axes to make the allocated region the exact right size while keeping all cells lined up at all 4 edges.  Imagine an Excel spreadsheet where you’ve randomly adjusted the widths of some columns, the heights of some rows, and filled in random cells – that’s what my texture sheet would look like after some heavy cycles of allocation and freeing.  Incidentally two adjacent empty rows become merged again, as do two adjacent empty columns.

The allocation algorithm is this: scan all regions row by row.  If a region is unused and unmarked, see if it’s the corner of a space that will fit the image (ensure available width at region is <= necessary width, then ensure available height at each region is <= necessary height).  If the space is big enough, mark the all of the rows as in use that are wide enough all the way down, mark all of the columns that are high enough all the way to the right, add the space to a list of possibilities, and continue searching.

The neat thing is that by marking the possible matches as you go you really cut down on the number of candidate spots you have to check for – and each candidate region you find is a corner already.

For example, say we had allocation A already and free regions B, C, and D:

ABB
CDD

When we try to fit in a new allocation we’ll find spots B (corner of BB/DD) and C (corner of CDD) – and that’s it!  The other possible spots will already be marked as used as we find the top-left B and then C.  Between the two, we’ll pick the one that has the best {exact match, matching width, matching height, smallest area} crossed with the one that has {no gaps above, has gaps above}.

I hope you can see what I’m getting at here… I tried drawing some nicer graphics and so on but it was getting way too complicated for what it was worth.  Anyhow, the code is in and it’s working beautifully.

ITEM: I’ve now turned my attention to porting Plasmacore to Android – it’s pretty virgin territory and, like Google itself, I think Android could be a sleeping giant (albeit a slightly unwieldy, slightly dorky giant).  Over half of us at Plasmaworks now have G1 phones.  I still like my iPhone but I’ll admit there’s a lot of nice stuff about Android.

I got stuck for a while on an esoteric gcc pointer bug that cropped up in my Slag VM code.  It only happens when you have a certain optimization level turned on, which Android does by default.  Say I have a pointer to integer “ip” – I could retrieve an integer at that address and increment the pointer to the next value with:

int x = *(ip++);

This is equivalent to:

int** ip_ptr = &ip;
int x = *((*ip_ptr)++);

which is equivalent to:

int x = *((*(&ip))++);

What I really wanted to do was access a double instead of an int at that position and then advance “ip” to point past the double.  I had:

double n = *((*((double**)&ip))++);

I made it a macro and was using it in a place or two, but it was Bug City on Androids gcc configuration.  I went back to doing it a simpler way across a couple of steps.

ITEM: Finally let me tell you about an interesting discovery.  Some stray unicode characters were exposing a UTF-8 encoding/decoding bug in my compiler + VM.  What I didn’t realize is that Vim (and apparently other editors…?) load and save text files in UTF-8 already – I had assumed Vim would only operate on raw bytes.   UTF-8, by the by, is a scheme to translate text that would normally be 2 bytes per character into 1 byte per character for most symbols and then 2 or 3 bytes for the less common symbols.

I just finished implementing an automatic texture sheet system for iPhone Plasmacore.  By default it automatically places image textures onto a single 1024×1024 texture sheet, creating additional sheets if you run out of room.  In addition I’ve transparently buffered all drawing calls, so drawing 50 images will just store up 100 triangles and then render them all at once later.

There’s significant speed-up over my previous implementation, but you’ll still have to be careful.  The results:

• I altered the system to redraw at 30 fps instead of 60.  Even a blank screen can’t quite hold steady at 60 fps, so I’d rather aim for a steady 30 fps on iPhone.  No changes required to your Plasmacore programs.
• iPhone Plasmacore can draw about 9280/x square images in 1/30 second, where x is the size of a single dimension of the image (16 px or higher; smaller images are roughly the same).  [Edit: make that "9280 / sqrt(x)" where x is the number of pixels per image].  So around 580 16×16 pixel images, 290 32×32 images, or 145 64×64 images.
• Sound effects will probably slow it down a bit more; I need to do some further testing with that.

Looking good for modestly complex games!

I’ve been doing some initial drawing tests on the iPhone with so-so results.

Turns out it uses a graphics chip that renders different tile sections of the screen in parallel.  I couldn’t find any info on how big the tiles are offhand.

Here are my very informal results. [Clarification: I'm drawing tile/sprite images as a series of individual calls, each with its own 2D transform]

In 1/60th of a second, the iPhone can draw about:
24 textured polygons in the same spot, quarter-screen size or less.
OR 75 spaced-out polys (32×32 in this case)
OR 6 full-screen polys.

Notes:
- This is with a tight drawing-only loop.  Logic & sound adds a bit of overhead – not an excessive amount but then again every bit hurts.
- Things that didn’t significantly improve the speed: turning off texturing, turning off back-buffer clear, turning off alpha blending, using texture formats with fewer bytes per pixel.

In light of this I’m gonna tweak Plasmacore for iPhone so that it’s CYOB (Clear Your Own Backbuffer).  Not to save time clearing the backbuffer, but to allow you to get tricky (if you want) and only redraw altered portions of the screen.  The good news is that Plasmacore (as usual) will still update() at 60fps no matter how slow the draw() is going, so things might get a little rougher but they won’t get slower.

A final tip will be to avoid drawing font-based text – use prerendered words!

I’ve been encountering some programming situations lately that cried out for some aspect-oriented features that weren’t in Slag – until tonight!

A bit of background: aspect-oriented programming (AOP), in a nutshell, is being able to write your program as independent layers of functionality that are merged together to create the final result. For example, mixing drawing code in with your game logic is frowned upon, since if you need to entirely re-do either of those aspects – or port your software to a different system – then you’ve got to wade through everything looking for the bits and pieces you need to change.

This Slag code can be tough to maintain:

  class Spaceship
    METHODS
      method init: set_position; load_graphics
      method update: ...
      method draw: ...
  endClass

  class Laser
    METHODS
      method init: set_position; load_graphics
      method update: ...
      method draw: ...
  endClass

while this AO Slag code behaves the same and is easier to work with in the long run:

  class Spaceship
    METHODS
      method init: set_position
      method update: ...
  endClass

  class Laser
    METHODS
      method init: set_position
      method update: ...
  endClass
  ...
  overlaying augment Spaceship
    METHODS
      method init: underlying; load_graphics
      method draw: ...
  endAugment

  overlaying augment Laser
    METHODS
      method init: underlying; load_graphics
      method draw: ...
  endAugment

* * *

In retrospect I realize that Slag’s AO features were focused on creating static class definitions and what it needs are some AO features to assist dynamic calls between objects.

Prime example: Plasmacore v2 operates on a system of view windows, each with its own 2D transformation matrix (usually there’s just one window, btw). For a view to be drawn it needs to push its transformation matrix onto the transform stack, draw itself, and then pop off its transformation matrix.

To allow the draw() method to be easily overridden I can’t put the transform adjustments in that method itself, so what I end up with is:

  view.push_transform
  view.draw
  view.pop_transform

It’d be really nice to allow an application programmer to just call “view.draw” and have the transforms automatically pushed and popped. There’s various kludgy ways to do it – especially renaming the actual draw to something else – but I came up with a more elegant way that was fairly quick to implement.

Slag v2 now has wrapper methods. If you call a method “fn” and there’s a method “fn-wrapper” defined, fn-wrapper() is the method that ACTUALLY gets called, and it should call the original fn() at some point. The View class would now look like this:

  class View
    METHODS
      method draw: ...

      method draw-wrapper:
        push_transform
        draw
        pop_transform

From the outside you’d just call “view.draw” and it would actually call “view.draw-wrapper”.

The reason why you couldn’t do this with an ordinary aspect is that the calls to push/pop transform would become embedded in the actual draw code, which would make overriding draw() a hassle.

All of that is almost true.  There’s an additional twist – Murphy noticed a flaw in this new system and suggested a very elegant solution!

The problem is, say that class Beta extends Alpha and Beta defines draw-wrapper but Alpha doesn’t. In accordance with the standard rules of polymorphism, if you were to write:

  local Alpha a = Beta()
  a.draw

then it would call Beta::draw() without calling Beta::draw-wrapper() since the call context is class Alpha and the compiler can’t know for sure that the object will have the wrapper method.

The solution is to take any class with both “fn” and “fn-wrapper” defined and, in the compiler, change the names to be “fn-inner” and “fn”, respectively. The name is unchanged in base classes without wrapper methods, and the wrapper methods take on the original name in extended classes so that they’re called polymorphically.

I added wrapper methods into the compiler tonight – only took me about an hour after getting the idea ironed out!

I just programmed this up for a friend who’s wrestling with good ol’ dynamic allocation issues in C++.  It’s a “smart pointer” class that takes all the hard work out of managing dynamic memory.  You can find this kind of stuff elsewhere on the net too, but here’s my take:

smartpointer.h

#ifndef SMARTPOINTER_H
#define SMARTPOINTER_H
//====================================================================
//  smartpointer.h
//
//  2009.04.12 by Abe.Pralle (at) gmail.com
//  This code is released to the public domain.
//====================================================================

#include <iostream>
using namespace std;

template <class ObjectType>
class SharedReference
{
  public:
    int count;
    ObjectType* object;

    SharedReference( ObjectType* object )
    {
      this->object = object;
      count = 1;
    }

    void retain() { ++count; }

    void release()
    {
      if (--count == 0)
      {
        delete object;
        delete this;
      }
    }
};

template <class ObjectType>
class Ref
{
  private:
    SharedReference<ObjectType>* ref;

  public:
    Ref()
    {
      ref = 0;
    }

    Ref( ObjectType* object )
    {
      ref = new SharedReference<ObjectType>(object);
    }

    Ref( const Ref<ObjectType>& other )
    {
      ref = 0;
      operator=(other);
    }

    ~Ref()
    {
      if (ref) ref->release();
    }

    void operator=( const Ref<ObjectType>& other )
    {
      if (other.ref) other.ref->retain();
      if (ref) ref->release();
      ref = other.ref;
    }

    void operator=( ObjectType* object )
    {
      if (ref) ref->release();
      ref = new SharedReference<ObjectType>( object );
    }

    ObjectType* operator*()
    {
      if (ref) return ref->object;
      else return (ObjectType*) NULL;
    }

    ObjectType* operator->()
    {
      if (ref) return ref->object;
      else return (ObjectType*) NULL;
    }
};

#endif // SMARTPOINTER_H

#include <iostream>
using namespace std;

#include "smartpointer.h"

class Fruit
{
  public:
    const char* name;

    Fruit( const char* name ) { this->name = name; }
    ~Fruit() { cout << " [deleting " << name << "]" << endl; }
};

Ref<Fruit> make_fruit();
void mess_with_ref( Ref<Fruit> fruit );

int main()
{
  Ref<Fruit> fruit = make_fruit();

  cout << "I have an " << fruit->name << endl;

  fruit = new Fruit( "grapes" );
  cout << "Now it's some " << fruit->name << endl;

  mess_with_ref( fruit );

  cout << "Still " << fruit->name << "!" << endl;

  Ref<Fruit> fruit2 = fruit;
  cout << "If I have two references to " << fruit->name << endl;
  fruit = new Fruit( "strawberries" );
  cout << "And I set one of them to some " << fruit->name << endl;
  cout << "Then I still have some " << fruit2->name << endl;

  return 0;
}

Ref<Fruit> make_fruit()
{
  Ref<Fruit> apple = new Fruit( "apple" );
  Ref<Fruit> orange = new Fruit( "orange" );
  return apple;
}

void mess_with_ref( Ref<Fruit> fruit )
{
  fruit = new Fruit( "some kind of weird pear" );

  Fruit* f = *fruit;
  cout << "Got the object pointer back to " << f->name << endl;
}

 [deleting orange]
I have an apple
 [deleting apple]
Now it's some grapes
Got the object pointer back to some kind of weird pear
 [deleting some kind of weird pear]
Still grapes!
If I have two references to grapes
And I set one of them to some strawberries
Then I still have some grapes
 [deleting grapes]
 [deleting strawberries]

iPhoneCore (Plasmacore for iPhone) is nearing completion!

Item 1:  I had an interesting issue today.  I’d just got my graphics all drawing when I noticed that my bitmap text was blurry.

Using a trick I’d learned in DirectX, I first tried subtracting 0.5 from each drawing coordinate to compensate for center-of-texel sampling like you have to do in DX.  The text was instantly crisp.  However:

I then thought I’d see if lines & points needed a 0.5 adjustment, so I drew some lines on the edges of the screen.  This graphics test worked fine on the simulator, but on the actual iPhone another problem appeared: floating point error was messing up pixel precision!  If I drew lines in screen columns 0, 1, 2, 3, and 319, then line 0 wouldn’t show up, lines 1 & 2 would both be in column 1, column2 would be skipped, and columns 3 and 319 would be fine.

I tried tweaking the orthographic projection matrix several different ways: glOrthof(0,319,479,0,…), glOrthof(0,320,480,0,…), glOrthof(0.5,319.5,479.5,0.5), and glOrthof(1,320,480,1).  None of them were accurate for all pixel positions.

Finally, after hours of screwing around, I realized I could ditch the floating point-based pixel-to-unit OpenGL ES transformation matrix and do a better job of it myself using doubles instead of floats!

[Side bar: how many numbers on the number line between 1.0 and 2.0?  Infinitely many!  How much memory do you need to be able to represent any number between 1.0 and 2.0 with complete accuracy?  An infinite amount!  So computers use an approximation scheme referred to as "floating point numbers".  The original "float" type has 32 bits and works okay.  The expanded "double" type uses double the amount of memory (64 bits) and has twice the accuracy.  Computers originally only supported integer arithmetic and did floating point calculations in software, so for a while floats and doubles were much slower than integers.  These days most computers have built-in floating point math (via FPU's = Floating Point Units).]

I set the OpenGL transformation matrix to be the identity matrix.  Then OpenGL expects coordinates in the range -1.0..1.0, so I made the following 2D transformation matrix of doubles:

[ 1.0/160.0, 0.0, -1.0;
0.0, -1.0/240.0, 1.0;
0.0, 0.0, 1.0 ]

I was then able to transform pixel coordinates (0..319,0..479) with pixel-perfect accuracy!  Not only that, but it clarified my bitmap text drawing to where I didn’t need any -0.5 translation – in this case, it think the original benefit of -0.5 was more from compensating for floating point error more than it was from compensating for any sort of texel sampling setting.

Item 2:  With my bitmap text working I did some integer versus double speed calculations on the iPhone hardware.  Adding 1 to an integer sum a million times (in the Slag virtual machine) took 0.60 seconds whereas adding 1.0 to a double sum took 0.68 seconds.  Not bad – it’s totally awesome that doubles aren’t hella slow or anything!

http://www.gamasutra.com/php-bin/news_index.php?story=22093

“We are always going to be dealing with a succession of low-level, non-critical, non-fatal failures that we can then kind of attenuate and make less frequent and make less severe,” the Far Cry 2 developer continues.

“The only way that I can think of at this stage to kind of manage that problem is to embrace it and say, ‘Great. Let’s make sure that we’re prototyping things. Let’s make sure that we’re putting stuff into the game as fast as possible so that we can see if we’re even on the right path with it.’”

Interesting piece:  http://www.gamasutra.com/php-bin/news_index.php?story=22002

An excerpt:

…the early days of Ultima Online were infamous for the game’s wild and chaotic economy. Zachary Booth Simpson wrote a classic analysis of UO in 1999, detailing some of the more notable problems experienced at launch:

- the crafting system encouraged massive over-production by rewarding players for each item produced
- this over-production led to hyper-inflation as NPC shopkeepers printed money on demand to buy the worthless items
- players used vendors as unlimited safety deposit boxes by setting the prices for their own goods far above market value
- item hoarding by players forced the team to abandon the closed-loop economy as the world began to empty out of goods
- player cartels (including one from a rival game company!) cornered the market on magical Reagents, preventing average users from casting spells

]]> http://abepralle.wordpress.com/2009/01/29/creating-balanced-in-game-economies-gamasutra/feed/ 1 Abe Pralle http://abepralle.wordpress.com/2009/01/25/86-int16-int8-unified-logical-type/ http://abepralle.wordpress.com/2009/01/25/86-int16-int8-unified-logical-type/#comments Sun, 25 Jan 2009 22:09:49 +0000 Abe Pralle http://abepralle.wordpress.com/?p=131 ]]>

While giving a presentation the other day, someone asked me why Slag had so many primitive types.  I’d never really thought about it before – I just started out with equivalents of Java’s 8 types as a baseline and added two more I was keen on (unsigned 8-bit Byte and Ternary types).

The question got me thinking though, and I realized that two of my types were dead weights: Int16 and Int8.  No one really uses them – I don’t use them.  They just complicate the compiler and VM by having two kinds of 16-bit values (Int16, Char) and two kinds of 8-bit values (Int8, Byte).  So they’re gone: I’m taking them out of my gen2 stuff right now.

Furthermore, I’ve decided to combine the Boolean and Ternary types to create a unified Logical type.  A true/false Boolean is useful for the usual reasons, and then the yes/no/void Ternary only became useful when I allowed it to be used in any place where a Boolean is expected.  With that being the case, there’s really no reason to have both.

My new Logical type can have values of true, false, and void (with alternate literal names gt, eq, and lt).  void means “not applicable”, essentially.  Any logical operation like and, or, or not will treat both false and void as false – the only difference will be that “==false” and “==void” (or !=…) will give different answers.  Note that using Logical in place of Boolean will work exactly the same as you’re used to; it’s only when “void” values may be involved that you have to be a little careful about comparing things to false versus void.

After the dust settles, here’s a quick run-down of the remaining 7 primitive types:

• Int64 – a 64-bit signed (can be positive or negative) integer.  Useful for random numbers, timestamps, and for indexing and counting data more than 2 GB in size (the upper limit of an Int32).
• Int32 – the standard signed integer made popular by generations of 32-bit CPUs.  Big enough to store most whole numbers you would want to work with while taking up half the space of an Int64.
• Char – an unsigned (non-negative) 16-bit value.  Used to represent character codes from the Unicode table.  Each text string is made up of an array of Chars.
• Byte – an unsigned 8-bit value.  Files and RAM are made of bytes.
• Real64 – a 64-bit real number (aka “double”).  The standard for calculations involving real numbers.
• Real32 – aka “float”.  Not nearly as precise as Real64, but still used heavily to store 3D game models and terrain since that’s a lot of data and it only takes half the space that Real64 data would.
• Logical – a qualitative rather than quantitative type, Logical can have the values true, false, and void.  For example, a checkbox could be true if checked, false if not checked, or void if disabled.  “not true” is “false” while “not false” and “not void” both result in “true”, allowing Logical to be used in the same way as Java’s Boolean type when desired.