Zalo DS Blog

A little bit of what I've been working on

2020-01-08T06:55:00.002+01:00

Happy New Year everyone! Since I posted this on twitter in summer I've been willing to sit a little bit and write a small post talking about all the things I have been coding during the past year and a bit further

ZGB

This year we celebrated the ZGB Jam 2 and released 8 new games (see myprevious post). I am still working on the engine and am very happy with how it has evolved over the years. A total of new 13 games were released during 2019 and there are at least a couple more games in development that I am aware of. Working on an engine is cool but getting people to use it on their own is really satisfying

My contribution for this year was Kaijuu Feeder. I was happy with the result and would have loved working a litte bit more on it. Sadly I don't have time for that

I love working on ZGB and still have great plans for the future but I just dedicate it a few weeks along the year

Z3D

Most of my spare time is dedicated to Z3D, the 3d engine that I used to create Whack Mania, Rokoban and Jumping Jack (and other title that I have decided not to release yet) Because the last thing I published with the engine was the Wii ports back in 2016 it really makes sense to think that I have abandoned the project... so let's recap a little bit

Z3D is a 3d cross platform engine available for Nintendo DS, Windows, Wii, Android, IOS and Nintendo 3ds. It hasn't been relased yet because is not as much user friendly as I'd like it to be. Because of that in mid 2018, tired of all the issues caused by 3ds max, I started working on an editor inspired by (not gonna lie to you) Unity3d. I work with Unity3d on my daily basis so at some point I thought it would be great to have an editor like it for homebrew games (or at least try to do it). Here is the list of features I have implemented so far

ZIMGUI

Prior to Unity3d I never heard before of Immediate mode GUIs. As a programmer I grew up with editors like Borland C++ Buider, Visual Studio, NetBeans, Eclipse and some others all of them using what is known as Retained GUIs. Although easy to use, for small tools nothing beats IMGUI. People not very skilled are capable of writing complex tools for Unity3d. Try to build a C++ UI using Visual Studio, try to maintain that! IMGUI lacks performance (as if working with Eclipse didn't) but since it is designed for editor tools (you can use it on games, but... don't do it) it is perfectly acceptable

The Unity team have been kind enough to write a few docs here and there showing how its implementation works
- https://blogs.unity3d.com/2015/12/22/going-deep-with-imgui-and-editor-customization
- https://docs.unity3d.com/Manual/gui-Basics.html

There are also a few open source alternatives that are worth taking a look at
- DearIMGUI
- Nuklear

In the end I decided to create my custom solution for several reasons:
- The way events are handled in both solution is different from how Unity handles them
- Performance can be better, you don't need to draw all the editor windows every frame
- Lack of some features like dockable windows (which still seems to be a WIP) and customization options
- Although very portable I'd need to invest time to get them working on some platforms that I support (like the Wii or the DS). If I create my custom solution with the code I already have I won't have that problem. I am planning to add more platforms in the future and I don't want to have a 3rd party library avoiding me to do so
- I felt skilled enough to try and create my own library and I wanted to give it a try

You can of course say that there is no point on reinventing the wheel but, hey! I am building a game engine from scratch here so maybe it's a little bit late for that :P. I have already implemented:
- Labels
- Buttons

- Checkboxes

- Combo boxes / enum combo boxes, thanks to Reflectpp enum combo boxes are handled automatically given an enum tye

- Textfields

- Color picker
- Scroll bars
- Trees

- Views, which are capable of handling views within views and automatically display scroll bars when needed

- AsssetField

REFLECTION

There is something I love from Unity and that's its easiness of use. One of its strongest points is how easy it is to configure components parameters in the editor. This is achieved using reflection available in C#, and it's automatic, the user doesn't need to create any custom inspector (although he can if he wants to)
C++ does not support reflection. Again, there are a few solutions available. A quick search in google will show you some popular options
- https://preshing.com/20180116/a-primitive-reflection-system-in-cpp-part-1/
- https://github.com/rttrorg/rttr
- http://pfultz2.com/blog/2012/07/31/reflection-in-under-100-lines/
- http://donw.io/post/reflection-cpp-1/

some of them are pretty cool, but again I didn't fully like them because:
- since my engine will work on legacy platforms I wanted a solution that worked on c++ 98 (not c++11 and definitely not c++17)
- I wanted a solution that required the minimun steps from the user. Having to declare a var and then add its reflecion info in the cpp are 2 steps, and I know it can be done with just one
- I wanted to have all that Unity offers on its editor: inheritance, composition, vectors, enums, strings

In the end I came up with a library called Reflectpp, and decided to make it open source. It is available on github

ZEDITOR

With both ZIMGUI and Reflectpp I could start working on the editor. Just like Unity and other engines like Godot I loved the idea of the editor being implemented with the engine itself, that way porting it to MacOS or Linux when the time comes will be much easier. In this editor I have started working on the next windows:
- Scene: lets me navigate through all the objects
- Game: shows how the game is going to look like
- Hierarchy: shows a list of all the objects available and how they are parented
- Resources: shows a list of all the resources available in the current build
- Inspector: displays the information (using reflection) of the current selected object

How the editor looks right now (click to enlarge)

For these windows I had to spend a lot of time working on some features like

Handles

Besides ZIMGUI I needed another system to manipulate 3d objects. It also works as immediate mode but in this case it lets me manipulate 3d objects in space. I have gizmos for:
- Translate
- Rotate
- Scale

Custom inspectors

Automatic inspectors are ok for small components but when I started serializing my materials info I realized I needed to be able to create some custom inspectors. In the future I'd like to add also custom editors and custom properties
Again, I needed to do this in a way that resulted easy for the final user. Take a look at how any of my materials are displayed with and without custom inspector

The Asset manager

The last thing I've been working on is an asset manager. The asset manager mantains a database of assets for the project and must be capable of
- given a path, load the asset in that path and if it has already been loaded increase its internal reference count. The asset manager must avoid loading the same asset twice
- given an asset, return the path where this asset was loaded from. This is very useful in the inspector Window when the user clicks on an AssetField and you see a bounce animation in the resources Window showing where it came from

The AssetManager works with Assets. so far I have created Assets for:
- Textures
- Meshes
- Materials

TO DO

And this is more or less what I've been working on. There is still a lot of work to do before releasing anything. During the next months I'll continue working on the AssetManager, adding more assets:
- Fonts
- Sounds, this two will be easy to update
- Animations, the way they are handled right now makes it hard to share information between duplicated nodes. Animation retargeting works pretty well though
- Prefabs, this is probably where most work needs to be done. I'd love to have nested prefabs too
- Scenes... still need to check if I need a separate asset for scenes instead of using prefabs for them (like Godot does)

But the work with the asset manager won't be finished when I have all this. I also need to work on
- Adding assets to the project: right now I have a text file with the list of assets and the export options for the different platforms. This works, but is very primitive. I like how Unity handles it, automatically adding all the content contained into the project folder but then stripping unused content from the build
- Uniquelly identifying assets for serialization. Unity uses UUIDs for this and meta files for each file added into the project. Also there is the concept of file ids for assets contained within assets (for example a component inside a prefab)
- Automatically updating loaded assets when the content on disk has changed

There is a lot of stuff to be done but since it's my hobby I will continue working on it. I just wanted to write a quick post showing you all the things I have been working on and also let you know that I am still alive and kicking even though is getting hard to find time to dedicate to all this :)

ZGBJAM 2

2019-08-04T17:28:00.000+02:00

The ZGBJAM 2 was hold during the weekend August 26t-28th, 2019. This is the second edition of our mini-jam focused on the creation of games for the Game Boy and specifically using ZGB. We'll be happy if more people were to join us (actually someone did!) but in the meantime this mini-jam has become a great excuse to share a good weekend with some friends and we even created a few games in the meantime!

A total of 8 entries were submitted even with the absence of Tatos and Deebrol who made some fantastic games the past year

Espeto Blast! by sergeeo

Collect the falling sardines and throw your espetos into the pipes (some kind of internal joke, but it is a fun game anyways :P) As usual the music is awesome

El topo y los pájaros by David Erosa

The title is in spanish meaning "The mole and the birds". You are a mole, so throw carrots to the birds to avoid them getting into your lair

Guardian Ghost by Maikel Ortego

A game with randomly generated dungeons and using colors for the GameBoy Color
Probably the most ambitious game of the jam and the one that helped me fix a couple of memory bugs in the engine

Hungry Birds by Joshua Frisby

This one was a big surprise because it was made by someone from internet. The mechanic is simple, you make 3 birds jump with three different buttons and you need to get the food and avoid the rocks. It has music!

Hungry Monster by Raúl Vaquero

Get the food and avoid the rest of falling objects with some cool animations

Feed the Kaiju by Zal0 (me!) and abishai

This was my entry! Drop the claw, get the chicken and feed the kaiju! I did this game joining forces with Emilio becuase the past year I realize I needed some extra help if I wanted to make something decent

Muffin the alpaca by Fronze

Run across the infinite Alpaca's Valley and get all the apples you can

Soviet Snake by Daniel Márquez

If you like good music this is the game for you. Ah, and it also has a snake game on it!

Although things have changed a little bit in the past years with more and more games being created for the old handheld (specially since the release of GB Studio) I still think there is room for ZGB. In my opinion both engines are targetted to different groups of developers with GBStudio more focused on artists with no knowledge of programming at all and ZGB being more targeted to (high level) coders. There is even a third group of developers who love asm and squeezing the machine. I think there is room for all of us out there

I have a big list of features to implement but since the first ZGBJAM I have been specially working on making stuff easier to use in general. Here is the list of things I have been worwing on during the past weeks:

since both GBTD and GBMB don't support input arguments people were forced to manually export and save after making any change. Also the exported info is not good enought since they only give you access to sprites and map data but you cannot get the height, width, bank and other interesting parameters forcing users to declare all these fields in their code (and having a lot of issues when changing one of them). Thanks to the good documentation of the file format (found here) I was able to create my own exporter finally getting rid of all these limitations. I'd like to create my own editors one day but in the meantime this solution is good enough
I have added a modified version of pngb to the pipeline meaning you can finally import pngs and use them for splash screens without requiring the help of external tools
A few bugs were fixed and specially a few of them related to memory management (I had the 2nd OAM buffer declared in the middle of the RAM) and collisions (I am sure there are still a few stupid decisions in the code because of how the old SDCC forced me to do things)
All the tutorials have been reviewed and updated with the new workflow

I wish I had more time to dedicate to this project but I hope you understand that this is kind of my side-side-project and that when I started it I never expected it to become what it is today. I hope soon I can publish a little bit of what I've been working on all these years.

I finished the ZGBJAM first edition post asking if there will ever be a second edition of this jam. I'm happy it actually happened. Will there be a 3rd one? Please, make it happen!

ZGBJAM

2019-01-07T16:04:00.001+01:00

Summer has become that time of the year when I stop everything I am working on and focus on ZGB for a few weeks. The bitbitjam wasn't finally hold this past year and we were missing a bit of retro-action so I talked with sergeeo (who takes care of the Familiar Game Jam) about holding a 48h mini-jam specifically for the Game Boy and using only the ZGB engine. The jam was online but a small group of people gathered together on my current company Genera Games.

As usual to avoid people bringing their creations before the start of the jam we picked a theme: bouncing. The jam was celebrated during the weekend of July 27th-29th 2018. You can still access the jam website and play all the 8 entries:

Upwell by Tatos

A Downwell demake wannabe that even caught the attention of Ojiro Fumoto

Boun-Ma-Ze by Deebrol

Bouncing is the only thing you can do to avoid being killed by enemies in a maze

Axebound by MaikelOrtega

An unfished prototype of a warrior throwing bounding axes to cephalopods. There is a color version available too, and it has bg music!

Dungeon Ball by sergeeo

A platform game where you have to guide your bouncing ball to the end of the level avoiding spikes. The music is great!

Deck Bouncer by Fronze

Guide the ball to the end of the level changing its direction with the proper card

Shield Bouncer by me!

You need to guide a bouncing ball with your shield to the end of the level. After this 2 years this is the first Game Boy game I had worked on alone

Basket Case Boy by David Erosa

You have to place the proper platform to make the ball enter the basket

Buggy Troll Minigolf by Daniel Márquez

A minigolf with an amazing power bar

All the games are playable on emulators and also on real hardware (a couple of them can be playable directly on your browser too). If you want to take a look at how the jam was taking place take a look at this link on twitter

This jam was the first time where I was able to see people using ZGB in person for the first time and thanks to that I fixed a few things that were causing a lot of issues:

ZGB installation process has become way simpler that it was. Instead of a lot of links to download the files I had prepared a package that contains everything and from now on you just need that package and set the ZGB_PATH
Backslashes on ZGB_PATH were causing a lot of headaches since msys requires slashes on paths. This has also been automatized
Fixed file header dependencies. A lot of bugs were caused when changing a header file (exporting sprites or bitmaps for example) but not recompiling the sources using it. This is now integrated in the makefile. Build times are a bit longer now but you no longer need to rebuild the whole project all the time
The number of steps required to add a new sprite have been reduced a lot:
- By using C X-macros (thanks Carlos for your great post!) now all sprite and map info is declared on ZGBMain.h
- Headers for sprites and states are no longer needed (you can still declare them if you want)
Fixed Game Boy Color sprites palettes isue

The tutorials have also been updated with all these changes

Sadly there are some other stuff I can't do much about. The Game Boy is an 8-bit machine with lots of limitations and this is the first thing to consider when developing for it. It doesn't have float points so fixed point 8:8 is your only choice here, understanding how it works and using the fixed type declared in GBDK is the way to go. Because the theme of the jam was bouncing using fixed was almost mandatory.

Will there be a ZGBJAM 2? If people are interested on it, of course. We also hope this new year 2019 that there will be a new edition of the bitbitjam, we were really missing it last year!

Simple yet powerful FSM implementation

2018-11-01T19:52:00.002+01:00

There is one thing common to all the games I have worked on and all the languages I have used: state machines, or how they are called nowadays: FSMs (finite state machines). You don't really need to learn anything before starting to use them and probably you have already used them without even knowing it. As seen in the Game Programming Patterns at some point you end up using them naturally.

But, event though the idea is pretty simple and intuitive, iterating it and creating something that really makes your life easier it's a bit more complicated than it seems. I'd like to show you how I have been iterating my FSM over the years and what are the main problems that I have seen in other approaches

1. The initial approach: using enums

Before starting to code anything it will be good to review what exactly an FSM is. I am going to copy the definition from the Game Programming Patterns book:

- You have a set of states that the machine can be in

- The machine can only be in one state at a time

- Each state has a set of transitions that causes the machine to change from one state to another

Do you see how I have skipped the part where the author is assuming input or events are tied to state changes? That was on purpose. I'll talk about it later but in my opinion FSMs become really complicated because of that assumption. State changes should happen whenever we directly tell the FSM to change its state.

Using enums we can create an state machine very similar to the one we have in the Game Programming Patterns book (I am going to use C# and Unity on this post):

public class ObjectWithFSM : MonoBehaviour {
 public enum State {
  STATE_0,
  STATE_1,
  STATE_2
 };
 public State currentState;

 public void SetState(State newState) {
  switch(currentState) {
   case State.STATE_0:
    //State 0 exit
    break;

   case State.STATE_1:
    //State 1 exit
    break;

   case State.STATE_2:
    //State 2 exit
    break;
  }

  currentState = newState;

  switch (currentState)  {
   case State.STATE_0:
    //State 0 enter
    break;

   case State.STATE_1:
    //State 1 enter
    break;

   case State.STATE_2:
    //State 2 enter
    break;
  }
 }
 
 void Update() {
  switch (currentState)  {
   case State.STATE_0:
    //State 0 update
    break;

   case State.STATE_1:
    //State 1 update
    break;

   case State.STATE_2:
    //State 2 update
    break;
  }
 }
}

The update of this class is managed by an internal FSM that processes one of the states only. If at any point I want to change to a new state I just need to call SetState passing the new State. Adding new states is as simple as adding new enums and creating new cases for them.

This approach is pretty simple and it works, I used it a lot back in the days of J2ME and still use it a lot when I want to write some quick code. I have actually being using this approach for my recent Game Boy games wit ZGB (like in polka sheep)

The main problem with this approach is that anytime you want to use this FSM you need to copy this template from scratch, no OOP is used. There is actually a good reason for this, back on the days of J2ME a new empty class added 130 bytes to your final build so we tried to avoid it at all cost (we had a limit of 64kb). But, it is 2018 and just an empty Unity project is around 20mb so we no longer need to worry about that (thank good!)

2. Using Object Oriented Programming

Let's try to define an FSM class that we can reuse. This is the simplest thing I came up with:

public class FSM : MonoBehaviour {
 //Base class for all states, only the required methods need to be overriden 
 public class State {
  [HideInInspector]public FSM fsm;

  public virtual void Enter() {}
  public virtual void Update(){}
  public virtual void Exit()  {}
 };

 //Current state being handled in this FSM
 public State currentState { private set; get;}

 public void ChangeState(State newState) {
  //Exit the current state
  if(currentState != null)
   currentState.Exit();

  //Change to the new state
  currentState = newState;

  //Enter the new state
  if(newState != null) {
   newState.fsm = this;
   newState.Enter();
  }
 }

 void Update() {
  //Update the currentState
  if(currentState != null)
   currentState.Update();
 }
}

This class keeps a reference to a single State that is set using the ChangeState function, and updates it (I am using the Update function available in Unity). In case we want to change to another State we just need to call ChangeState passing this new state as argument. Here is an example of how to use it:

public class ObjectWithFSM2 : MonoBehaviour {
 [System.Serializable]
 public class State0 : FSM.State {
  public override void Enter(){
   Debug.Log("Entering state 0");
  }

  public override void Update(){
   Debug.Log("Updating state 0");
  }

  public override void Exit(){
   Debug.Log("Exit state 0");
  }
 };

 [System.Serializable]
 public class State1 : FSM.State {
  public override void Update(){
   Debug.Log("Updating state 1");
  }
 };

 public State0 state0;
 public State1 state1;
 FSM fsm;

 void Start() {
  fsm = gameObject.AddComponent< FSM >();
  fsm.ChangeState(state0);
 }

 void Update() {
  if(Input.GetKeyDown(KeyCode.A)) {
   if(fsm.currentState == state0)
    fsm.ChangeState(state1);
   else
    fsm.ChangeState(state0);
  }
 }
}

This is just a class with two states that uses an internal FSM to process them. Pressing the key A it changes between the two of them, A few things that it s worth commenting in this code.

- I have defined State0 and State1 as System.Serialiable for 2 reasons:

Unity will automatically create and instance of them in the editor (so we don't have to allocate them manually)
Public vars will appear in the inspector so you can assing them in the editor (this also answers the question in the Game Programming Patterns book: Where are the State Objects? Based on my experinece this is the best place to put them, you don't need to constanlty destroy them when changing from one to another and you don't need static allocations, every instance has its own states)

- State0 overrides the 3 methods: Enter, Update and Exit but State1 only implements Update. The more states you create the more you realize that not all states do stuff entering or exiting, so it is a good idea to leave the implementation empty on the base class.

- All states keep a reference to the fsm after Enter has been called. This is useful to access the GameObject containing the FSM and from there the Monobehaviour containing the states (using fsm.GetComponent< ObjectWithFSM >()) that is not directly accessible from internal classes

This new FSM is much better than the previous one. We can reuse it, just need to add an FSM to our Objects and all the set of States we need... but it has a big problem that sooner or later arises. Let me show it to you with an example.

I used this FSM on Touch Racing 2. The FSM of the Main Menu was something like this:

The game starts on the Main Menu showing the three vehicles, from there you either go to the Options menu or select a car and go to the Car Menu. In the Car Menu a list of pieces is displayed: the chasis, the wheels, the engine and so on. If the user clicks on any of them then he's tken to the Pieces menu where he can select any of the different car pieces. The back option is always there to go back to the previous menu too.

Both the Car Menu and the Car Piece display different things depending on which option was selected on the previous menu. If the user selects the boat on the Main Menu then the Car Menu will center the View on the boat but if he chooses the Offroad the Car Menu will do the same with that car. We need to store which car was selected in a variable when exiting the Main Menu. Things get more complicated in the Car Piece menu, because it depends in both the selected vehicle and the selected piece, but no problem: we can just add another varible for the selected piece and properly set it when exiting the Car Menu

So the flow is like this: the user selects a vehicle and we store the selection on the var selectedVehicle. Then he selects a part and we store that on the var selectedPart. Great! This all fits perfectly!

Soon things start to get a bit more complicated. In TRN2 when you buy a vehicle piece it takes some time until it arrives, if that happens when the game is in the background a local notification is thrown informing the user the new piece has arrived. When the user enters after this the game must show a popup and then go directly to the Car Piece state and show this piece. The problem is that because we haven't gone through Main Menu and Car Menu neither selectedVehicle nor selectedPart has been assigned, and the game will likely crash

This is really easy to fix, just assign the variables before entering the Car Piece state and everything will just work. Yes, but the problem is: you can still enter the car piece from any other part of the code where these vars hasn't been assigned. For example when the user has enough money to buy one of the pieces a popup appears informing him: "Hey you can now purchase a new part. Do you want me to show it?", if the user click yes then the game changes to the Car Piece state and again we need to remember to assign the variables or it won't display the right info! Oh, and don't forget the gacha machine: when the user wins a new prize the menu also changes to Car Piece to show the new adquisition

We have also forgotten one thing, the Car Piece state automatically selects the next piece the user should buy to progress in the game (by design). But in all these cases we also need another variable to tell the state which piece we want to be selected instead. In at least three parts of the code I needed to write

 vehicleIdx = _vehicleIdx;
 pieceSelected = _piece;
 defaultPieceIndex = _defaultIndex;
 fsm.ChangeState(carPieceState);

And because code duplication must be avoided In the end I ended up with a special function to move to the Car Piece State

void ChangetoStateCarPiece(int _vehicleIdx, PieceSelected _piece, int _defaultIndex) {
 vehicleIdx = _vehicleIdx;
 pieceSelected = _piece;
 defaultPieceIndex = _defaultIndex;
 fsm.ChangeState(carPieceState);

This function was handy but still someone could easily call fsm.ChangeState(carPieceState) without setting the required vars because nothing was forcing him to do so.

This was just an example of how something very simple can become a horror to maintain. I saw the same pattern repeated several times in other usages of this FSM clearly indicating that it had a serious problem and was far from perfect.

3. State enter parameters

If we could pass some parameters to the Enter funcions of the State class we will force the programmers to pass these arguments always before entering certain states. The problem is that each state requires a different number of parameters and of different types. A naive approach to fix this will be passing an object[] or a HashTable or event a List< object >. But certainly this

Hashtable t = new Hashtable();
t.Add("vehicleIdx", _vehicleIdx);
t.Add("pieceSelected", _piece);
t.Add("defaultPieceIndex", _defaultIndex);

fsm.ChangeState(carPieces, t);

not only doesn't solve anything because any programmer could easily forget to add any of the required parameters (or all of them) but also this code is allocating a HashTable before entering the state and when entering we need to search the parameters. Instead of solving the problem we have created two new ones

In C++ whenever you need to create a function that could work with parameters of different types you end up using templates (or void* if you want to irritate everyone :D). In C# there are generics, which work in a similar way. Templates and generics will fix the problem with having different types of parameters but not the number. Again, based on my experience, I have never passed more than 3 parameters so we could do something like this:

public class FSM2 : MonoBehaviour {
 //Base class for all states, only the required methods need to be overriden 
 public class StateBase {
  [HideInInspector]public FSM2 fsm;

  public virtual void Update(){}
  public virtual void Exit()  {}
 };

 public class State : StateBase { public virtual void Enter() {} }
 public abstract class State1Param  < T >         : StateBase { public abstract void Enter(T p); }
 public abstract class State2Params < T0, T1 >    : StateBase { public abstract void Enter(T0 p0, T1 p1); }
 public abstract class State3Params < T0, T1, T2 >: StateBase { public abstract void Enter(T0 p0, T1 p1, T2 p2); }

 //Current state being handled in this FSM
 public StateBase currentState { private set; get;}

 bool ChangeStateBase(StateBase _newState) {
  //Exit the current state
  if(currentState != null)
   currentState.Exit();

  //Change to the new state
  currentState = _newState;

  if(_newState != null) {
   _newState.fsm = this;
   return true;
  }
  return false;
 }

 public void ChangeState(State _newState) {
  if(ChangeStateBase(_newState)) _newState.Enter();
 }

 public void ChangeState< T >(State1Param< T > _newState, T p) {
  if(ChangeStateBase(_newState)) _newState.Enter(p);
 }

 public void ChangeState< T0, T1 >(State2Params< T0, T1 > _newState, T0 p0, T1 p1) {
  if(ChangeStateBase(_newState)) _newState.Enter(p0, p1);
 }

 public void ChangeState< T0, T1, T2 >(State3Params< T0, T1, T2 > _newState, T0 p0, T1 p1, T2 p2) {
  if(ChangeStateBase(_newState)) _newState.Enter(p0, p1, p2);
 }

 void Update() {
  //Update the currentState
  if(currentState != null)
   currentState.Update();
 }
}

Notice how I have declared the Enter functions as abstract this time because it doesn't make sense to have any of the states with parameters without the Enter function required. Using this new FSM we could now declare the Car Piece state like this:

[System.Serializable]
public class CarPieceState : FSM2.State3Params< int, PieceSelected, int> {
 public override void Enter(int _vehicleIdx, PieceSelected _piece, int _defaultIndex) {
  //Select _defaultIndex of piece _piece and vehicle _vehicleIdx
 }
};

and then in order to enter this state we should call ChangeState like this

//-1 in this case indicates the default selection (selecting the next piece the user needs to purchase)
fsm.ChangeState(carPieceState, 0, PieceSelected.Piece0, -1);

or the code won't compile. There is no need to specify the template arguments in ChangeState since the compiler is capable of infer them.

We can finally sleep happily knowing that no one could break the behaviour we wanted to have! I wish I had had this piece of code when I was coding TRN2!

Ok, this is the FSM I wanted to show you. But we are far from done. Let's see why adding some new features to our class may always not be such a good idea...

4. Using graphs

I am gonna be honest with you: I hate graphs. I don't like Playmaker, or the Animator State Machine and neither the new shaderGraph feature available in Unity. Using graphs as replacement of regular programming is a big mistake. People end up making noob mistakes, code duplication (hyper duplication) being the worst of them. Sadly this kind of stuff is very common:

It is funny, until you are the one who has to fix all that mess in order to continue adding content to a project you have been assigned to.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.Martin Fowler, 2008."

Having said that I think a post talking about FSMs would be incomplete without talking about State Machine Behaviours in Unity. These are basically scripts that you can attach to states in the animation machine state and then you just need to override the desired functions OnStateEnter, OnStateExit or OnStateUpdate (sounds familiar?). If you are interested on State Machine Behaviours and how to use the Animator as an FSM take a look at this post

Using State Machine Behaviours we could recreate the TRN2 menu FSM like this

Some people love this because with a single peek they can easily get an idea of how the FSM of the main menu works. And I agree, this is similar to the graph I draw at the beginning of this post to show you the FSM I had. The problem is that this representation is not true, you can still navigate to any state you want, just call Animator.Play and you can navigate from the Options menu to Car Piece even thought they are not linked. In other words the graph you see in the Animator is not the graph you have. This is the real graph:

The main problems that I've seen with FSMs is how state entering restrictions are undesrstood. Even the Game Programming Patterns book seems to indicate that you can only enter an specific state if you have a transition coming from another specific state (with an arrow linking them). According to this the restriction to get into the Car Piece state is to pass first through the Car Menu State and properly assign the required variables there.

But what happens if we need to enter the Car Piece state when a new part has arrived, a new prize is given on the gacha machine or the game encourages you to buy a new piece? It doesn't seem like this code is capable of adapt to changes like these easily

In my opinion (and this has worked like a charm for me) the restriction to enter an specific state is to pass the required enter parameters. You should design states that work perfectly if they receive all the required enter parameters, with zero dependencies to the other states

So, again, what benefits do we get from using the Animator state machine and State Machine Behaviours?:
- A graph that doesn't represent the real transitions we have
- We can't pass enter parameters which solved one of the main problems of our FSM
- Plus, we lose the ability to assign scene objects since Animator Controllers are not instantiated on the scene

I am sorry, get your own conclusions, but I totally discourage the use of Animators as FSMs (and totally encourage you to reinvent the wheel sometimes, because that's the only way to improve it)

5. The Back Queue

One of the things everyone implementing FSMs tend to do sooner or later is to add a stack of states to keep a history of the states it has been through and easily navigate back (this is what the Game Programming Patterns book refers to as a Pushdown Automata). Before entering a new state the current one is pushed into the stack and then when going back it is popped from there automatically.

Let's get back to TRN2 Menu. All its states except the Main Menu have a back functionality. If we are on the Main Menu and then move to the Car Menu we could automatically go back by just popping the state from the stack. The same way if we reach the Car Piece state we could go back twice since we passed through Main Menu and Car Menu.

The first problem appears when we enter the Car Piece state directly (when a new part arrives, a prize is given in the gacha machine or the game suggest the user a new part to purchase). We won't have a back stack there unless we create a fake one (manually adding states) or add some ugly conditions saying that, if the stack is empty, then move the Car Menu.

The second problem is even worse. Imagine you use a stack for an FSM like the one in the Game Programming Patterns

the stack will constantly grow because you never go back to the previous state in FSMs like this. You need to make sure that you clear the stack before changing to a new state or add a boolean to your FSM indicating if you want to use the stack or not.

What if instead of using a stack we add a new enter parameter to some states to indicate which state they should go in case the back button is pressed? This is actually not very helpful in TRN2 because the back button in Car Pieces always goes to Car Menu (by design), so we don't need the stack or the extra return parameter, but imagine we could enter the options menu from any of the other states. Then it will make sense to do something like this:

[System.Serializable]
public class OptionsState : FSM2.State1Param< FSM2.State > {
 private FSM2.State stateBack;
 public override void Enter(FSM2.State _stateBack) {
  stateBack = _stateBack;
 }

 public void OnBackClicked() {
  fsm.ChangeState(stateBack);
 }
};

and then when the back button is pressed, OnBackClicked is called and will return to the state passed as paramater. You may have already realized that there is a problem with this... We can safely do this in the Main Menu

fsm.ChangeState(optionsState, stateMainMenu);

but if we try to pass the stateCarMenu or the stateCarPieces it won't even compile because these states need enter parameters. Notice also how this is another reason why the back stack is incompatible with an FSM with States with enter parameters. Luckily there is a solution for this. Instead of passing an State to go back, we could pass a function callback

[System.Serializable]
public class OptionsState : FSM2.State1Param< System.Action > {
 private System.Action onBack;
 public override void Enter(System.Action _onBack) {
  onBack = _onBack;
 }

 public void OnBackClicked() {
  onBack();
 }
};

and then we can enter the OptionsState from either the CarMenu state

[System.Serializable]
public class CarMenuState : FSM2.State1Param< int > {
 int vehicleIdx;
 public override void Enter(int _vehicleIdx) {
  vehicleIdx = _vehicleIdx;
  
  //some other stuff
 }

 public void OnBack() {
  OptionsState optionsState = fsm.GetComponent< TRN2Menu >().optionsState;
  fsm.ChangeState(optionsState, () => { fsm.ChangeState(this, vehicleIdx); });
 }
};

or the CarPieces state:

[System.Serializable]
public class CarPieceState : FSM2.State3Params< int, PieceSelected, int> {
 int vehicleIdx;
 PieceSelected piece;
 int defaultIndex;
 public override void Enter(int _vehicleIdx, PieceSelected _piece, int _defaultIndex) {
  //Select _defaultIndex of piece _piece and vehicle _vehicleIdx
 }

 public void OnBack() {
  OptionsState optionsState = fsm.GetComponent< TRN2Menu >().optionsState;
  fsm.ChangeState(optionsState, () => { fsm.ChangeState(this, vehicleIdx, piece, defaultIndex); });
 }
};

That's it

I have been iterating this FSM a lot during the past years. Even though it is just 60 lines of code that doesn't mean there isn't a lot of work behind it

I have actually iterated it a bit more. You may be wondering how you could create States that are Monobehaviours at the same time (I'll leave it to you, but if you need help just let me know)

There is also a problem that I haven't been able to solve happily: when you call fsm.ChangeState() during the Update function of any of the States the rest of the lines of code in that Update will continue to execute even though it is no longer the current state. Throwing an exception and catching it on the FSM could work but I don't think using exceptions for this would be a good idea... If you have a solution for it I'll be happy to hear it

Also if you are interested on a C++ implementation you can take a look at it here (FSM.h FSM.cpp) It is a bit different and it uses some specific engine functions but you can get the idea

Properly doing cameras interpolation through a target (II)

2017-08-14T07:21:00.000+02:00

This is the 2nd post on the series Properly doing cameras interpolation through a target:

- Properly doing cameras interpolation through a target (I)

- Properly doing cameras interpolation through a target (II)

Having fun interpolating cameras? Let's take a look at some issues of the Camera interpolator we started on the previous post and fix them

The Rotation issue

If you test the interpolator a little bit you'll see it behaves very well even with moving objects. Because it focuses on the target it doesn't matter if it is moving or not, on any step of the interpolation it places itself on the target position and then interpolates from there.

But there is an issue interpolating between rotating cameras. Make the target rotate by adding the next script to it

and then set any of your cameras as children of the target so they rotate with them. Now pay attention to what happens when you interpolate from this camera to itself:

instead of staying still it does a little annoying movement. This doesn't happen if you stop the rotation. The reason why this is happening is because we are interpolating the rotation in world space, and because the target is rotating this value is changing every frame and so an interpolation appears. So how should we store the rotation then? There are 3 possibilities:

- Relative to cameraFrom

- Relative to the target (same as the position)

- Relative to the cameraTo

we have already seen why it is not a good idea to keep things relative to cameraFrom, so let's focus on the other two. At first one could think that since we are already keeping the position relative to the target then it would be a good idea to do the same with the rotation, but no. In a few cases where I have tested cameras interpolation, the target tends to continue rotating after changing its camera (a car on a curve for example) and that gives a weird sensation because everything rotates around it if we attach a camera directly. Instead the camera we are interpolating to is a camera that is prepared to handle the movement of the target (it will continue being the main camera after the interpolation) so it looks like a much better candidate. This is mostly based on experience so if I don't convince you then you should experience it by yourself (and let me know your thoughts).

So, yeah, we are gonna keep the rotation relative to the camera target. The good thing about this is that the end rotation will always be the identity (since the identity rotation relative to the camera target is the rotation of the camera itself). And the way to calculate one rotation in Unity relative to another is by doing

relativeRot = Quaternion.Inverse(referenceRotation) * worldRotation

changin just lines 56 and 83 we have the problem solved

The Fov interpolation issue

The current interpolator not only interpolates position and rotation, but also the parameters of the camera: fov, near and far. There is an interesting issue with the way we are interpolating the fov. In order to see it, place two cameras with different fovs in the same position and displace them in their local z so that they render the target in a similar screen position. This is what happens when you interpolate between them:

It actually seems as if the camera were moving forwards and then backwards. Why is this happening? Take a look at how the height of the camera on the target position (marked in red) is currently being interpolated:

The height is actually growing and then shrinking instead of being kept constant. This happens because interpolating the fov linearly doesn't actually make the height being interpolated linearly too (If one of the angles of a triangle grows 50% that doesn't make the opposite side grow by 50%)

There are two ways to solve this: we have to interpolate the height first and then we could either interpolate the fov and then calculate the local z or we could interpolate the local z and then calculate the fov. In my experience interpolating the fov looks smoother and is bit more friendly to the eye, so we'll go for that option. The three parameters (fov, height and local z) are connected like this

This is what happens if you just interpolate the fov and then calculate the local z:

as you can see the height is kept constant (marked with the red line) but now the near and far values are the ones moving (in this case there is an instant where the target is actually not being rendered). This is because the z now is not moving linearly and because the near and far values are relative to this z they are displaced. We need to interpolate the near and far values with the same t used for the z. The way to calculate this t is

float tZ = (z - z0) / (z1 - z0);

where z was calculated based on the fov interpolation and z0, z1 the initial and final values. Also we need to make sure that z1 and z0 are different to avoid a divission by zero, if that happens we just need to use the same t used for the fov interpolation (there is no displacement on z, so near and far won't be displaced). Now if we used this tZ to interpole near and far we get this:

And this is how the Refresh function should look like:

Orthographic Cameras

So far we have been interpolating between cameras using perspective. But there is another type of cameras available in Unity by default (and is also a type of Cameras very common in videogames).

Instead of a fov, in Unity, orthographic cameras are defined by an orthographic size which according to the documentation represents half of the screen height. Also, orthographic cameras have their projection lines parallel between them. Although they look very different at first it is posible to create a perspective camera that looks very similar to an orthographic one, and this is the trick we are gonna use to interpolate to and from them.

On a perspective camera the lower the fov the more parallel the projection lines become. They will become parallel at infinity but we don't need to go that far to make an interpolation that looks good. We have already seen a way to keep the height constant while interpolating the fov. Now take a look at what happens when we pick a perspective Camera and interpolate its fov to 0,1 (and then calculate its local z)

It's not orthographic at the end, but close to, and good enough for an interpolation. We need to do this conversion in three different parts of the code:

- At the beggining of the interpolation, if the previous one is finished, to retrieve the current values of the previous camera
- At the beginning of the interpolation, on CameraFrom
- Every Frame, on CameraTo (since it could be moving)

Because of this I ended up creating a small internal class CameraParams that stores all the info and also manages the conversion. The code with all the changes is the next one

Avoid Linear interpolation

We are almost done. Just a small tweak to improve the script a lot. So far we have been using a linear interpolation (getting t from interpolationTimeAccum / interpolationTime). Linear interpolations in videogames always look bad, you should avoid them at all cost in order to make things feel more natural.

Luckily in Unity it is very easy to add curves using the type AnimationCurve, and then we just need to change this

float t = interpolationTimeAccum / interpolationTime;

into this

float t = interpolationCurve.Evaluate(interpolationTimeAccum / interpolationTime);

you can find the final script here

Done

Pfiuuu! We are finally done. This is something I wanted to do for a long time. I am pretty happy with the result. I have tried to explain all the issues I saw when I finally sat down and coded it (and also my memory is really bad so having all this written here will be very helpful for me in the future).

You can of course skip it to the end and just grab the script and use it, it's up to you. I have shown you how to do this on Unity but if you understand it, it shouldn't be a problem to use it anywhere. As usual what really matters is the knowledge, not the language or the program you are using.

Please drop me some comments with your doubts of your opinion about the post, it makes me happy to read them :)

Happy camera coding!

Properly doing cameras interpolation through a target (I)

2017-08-08T18:33:00.000+02:00

This is the 1st post on the series Properly doing cameras interpolation through a target:
- Properly doing cameras interpolation through a target (I)
- Properly doing cameras interpolation through a target (II)

Not sure everyone knows, but I am the kind of player that one day is enjoying the latest Zelda and the next day can be playing a Nintendo64 game on my favourite emulator. I don't play too many games (not that I ever had, usually when I was a kid I could get 5-6 different games a year, so I am fine with this) but the few ones I do I like to get to at least one of the endings.

Jumping from Banjo Kazooie to Zelda Breath of The Wild I could appreciate an evolution on the cameras Interpolation both games were doing. This is something that I wanted to work on for a long time, so after seeing it every night in Zelda BOTW I decided to implement it once and for all.

When Banjo crosses the bridge there is an interpolation between two cameras, but while it's happening the character moves from side to side of the screen giving a weird sensation

In Zelda Breath Of The Wild a cameras interpolation happens when you use the teleport. The gameplay camera changes to a new one that shows Link from a closest angle. Link always stays in the middle of the screen

By cameras interpolation I refer to the animation that happens when changing between two different cameras, moving from the first one to the second. Bear in mind this is not always necessary, the change could be inmmediate

A very basic Camera Interpolator

Ok, let's start from a simple Camera interpolator. I'll be using Unity this time. Basically we want an script that given two cameras, disables both of them and activates a new one that moves from the first one to the second, and when it finishes it disables this new camera and enables the second one. When moving from the first one to the second we want to interpolate: position, rotation, fov, near clip plane and far clip plane. Something like this will do

Any time that we want to interpolate we should call InterpolateTo passing the two cameras and the time we want it to last. The var interpolationTimeAccum will be incremented during every call to LateUpdate and all the camera parameters will be interpolated until it reaches interpolationTime.

Now in order to test this script let's create a new script that allows us to easily select the cameras we want to select for the interpolation. The first thing that comes to my mind is an object that keeps a list of cameras and every time we press a number in our keyboard it interpolates to the camera in that index. Something like this:

I am also disabling every single camera except the first one because we only want one of them to be active at a time. In order to test these new scripts let's create a new scene with a cube and some cameras around it (on its front, bottom, left, right, front and back, for example). We also need an extra camera that will contain the CameraManager.cs script and an extra GameObject containing the Cameras.cs with all the cameras and the reference to the CameraManager. This is how it should look:

This script really interpolates through all the cameras but it has some issues:
- The cube is not on screen all the time even though we are just rotating around it
- The interpolation cannot be interrupted, you need to wait until it finishes before interpolating again
- InterpolateTo doesn't really need the fromCamera, we could assume this camera is the last one we were interpolating to
- All the cameras have AudioListeners and this causes a lot of warnings (this is a Unity related issue but since it is the engine we are using we'll take care of it)

A little improvement

Let's focus for now on fixing the three last issues that are actually not related to the interpolation itself but have more to do with the usability of the script.

The first two issues are easy to solve if instead of storing the fromCamera we keep a record of its position, rotation, fov, near and far. If the interpolation is interrupted then the current values of these variables will be the new interpolation sources.

The AudioListener issue can also be fixed disabling the AudioListeners instead of just the Camera components (this is much better than fully disabling the GameObject since there might be other script that need to continue running). Since we are going to use this in several points of the script, let's create a function fort his purpose.

You might be worried that we are no longer keeping track of the source camera. But actually it is much better if we forget about it, for several reasons:
- It could be destroyed at any time during the interpolation (giving us a NullPointerException that will cause a crash)
- It doesn't look ok to interpolate from a Camera that is still moving, you can test this a little bit with the previous script if you don't trust me
- We are not really interpolating from a camera, same that a moving object moving from A to B could change its target to C any time and won't be interpolating from A or B just a point in the middle.

We also need to update the Cameras.cs script

You can now interrupt the interpolation any time and all the AudioSources issues will no longer be happening, but still when interpolating between some cameras the box gets offscreen, this is easy to see interpolating between the front and back cameras

Interpolating through a target

So what we want is to keep the box inside the boundaries of the screen at all times. Let's start by thinking if this is possible or not. Could we always have the box visible? If it is visible from cameraFrom and it is visible from cameraTo then I can think of an interpolation on screen coordinates were the box moves from the left of the screen to the right at the same time that is interpolating its rotation. Let me help you to visualize it, this is what we are looking for:

If you think on screen coordinates instead of world coordinates it seems a little bit more obvious. Now, how could we implement this?

Maybe you are thinking that you could use the lookAt function from the Quaternion class. You could just interpolate the positions between the two cameras while always looking at the target. This will work in some situations but not in all of them, because the lookAt function always keeps the target in the center of the screen. If you pay attention to the screenshots you'll see that I have on purpose placed the target on the screen sides.

What if we create a camera that allows us to point to a target but not necessarily in the middle of the screen? The next script does exactly this:

If you add this to a camera and assign a target and an offset, then rotating the camera (manually in the editor) will rotate around the target but will not be centered on the screen

How does this script achieve it?
- It keeps the current rotation
- Then it resets its position and is placed on the target position
- From there it applies a (local) translation with the given offset

If we could represent the position of our cameras with a target, a rotation and an offset from it then interpolating the rotations first and then the offsets would give us the intepolation we are looking for.

Given a target position P and a Transform T the offset that T needs to move from its position to P is the position of P relative to T. The inverse of this value is what is needed to move from P to T.position. In Unity this is expressed as

Vector3 offset = -T.worldToLocalMatrix.MultiplyPoint(P);

The reason why we are using P relative to T instead of just P is because we need to Translate the camera in local space. Now putting all the pieces together, we can improve our CameraManager like this:

pay special attention to lines 57 and 88, that is where the magic happens. Also it is important to interpolate the rotation first and then do the translation so this last one happens in the right direction. You might have also noticed that InterpolateTo now has an extra param: the target. If you want to use the interpolation without a target then you should assing cameraTo as target (lines 34,36), and then the interpolation will look like the old one.

Ok, we are gonna leave it here for now. This interpolator is much better than the one we started with. You can play with it a little bit if you want, but bear in mind that is not final. It has a few issues that I will solve in the next post. In the meantime if you find there is something that doesn't make sense or you have a question, please let me know in the comnents ;)

BitBitJam 4 - Polka Sheep

2017-07-31T20:45:00.004+02:00

It's hard to believe it's been a year already. I started doing some coding stuff for the Game Boy the past year for the bitbitJam 3. Me and sergeeo came up with Pretty Princess' Castle Escape and that was the begginning of ZGB a little engine for making games on this now 27th years old console.

I have been improving the engine a lot during the past year, but for this bitbitJam I wanted to work on something that's been annoying me the whole time: the compiler (see this post). If you've been following the scene you might already know that the current version of the GDDK is using an obsolete version of SDCC. I decided to sit down for a while and see if I could evolve it to use the latest one. The first thing I found was gbdk-n and interesting update to the library that uses the latest version of the compiler but it lacks one fundamental feature: banks support

A further investigation actually leaded me to this post in the Game Boy Development Forum. From there I managed to create a Makefile and see what the problem was exactly. The makebin tool that comes with SDCC doesn't support roms bigger than 32k (in other words, it doesn't support banks) that's correct, but taking a better look at the generated ihx file I realized I couldn't actually do much because no offsets (code 04, extended linear address) were actually present at all on the file. So basically, both the linker and the Makefile had problems...

From there I could have started taking a look at the linker that comes with SDCC which seems to be an updated version of the old one. That's when I realized... maybe the old linker was still working fine? So I did a quick test and created a new Makefile that was using the new compiler and the old linker and voila!: SDCC 3.6.0 is now the compiler supported for ZGB. Take a look at my Makefile to see how I am doing it.

Of course this is just an intermediate solution, someone should take a look at the linker used by SDCC and fix it and also the makebin should be fixed too. In the meantime it would be good if someone could update the current gbdk to use this intermediate solution.

Happy with this advance I was ready for the BitBitJam 4! The theme of the jam this year was Velcro Sheep and there was an extra limitation this year: One Key.

I must admit at first I didn't like the theme or the limitation. I was planning to do a Zelda game this time, and it was impossible to fit it with these limitations. I am not really a fan of one key games (and by key they clearly stated an input key so no keys to open a door or giving clues or other ways to skip the limitation LOL). This whole situation just forced all us to follow the rules, which is not bad at all. This is a Jam, and that's part of the funny thing. If you want to create an specific game, no one is forbidding you to do it today...

Once again I teamed up with Sergeeo (music + art) and this time we also were joining forces with Kirblue (level design), because we already realized we needed someone who could create some great levels and the game will be much better if we did that. This was the state of our game on Saturday evening (if you want to know more about the bg music just read Sergeeo's postmortem)

Along the week we were polishing it a little bit more and at the end we came up with Polka Sheep: a game where you need to help the main character to rescue his friends who had been captured into mysterious giant bubbles using his velcro power!

The game can be downloaded here .Leave us some comments with your feedback, we always like to read them. Source code is also available here

A week after the jam the voting started and hey... we were ranked #1 I'd like to thank everyone for voting us, it really made us very happy. But since there are a lot of really cool games there, I encourage you to take a look at all of them, it is totally worth it!

There is also something else that made me happy. Two other games of the jam were built using ZGB: Sticky Hooves In The Temple Of Vel-Cro and Velcroid

The fact that some people are starting to use ZGB means all the effort I put on it was worth the effort. There was also another game made with ZGB: Velcro Golf by brovador that sadly wasn't finished in time for the jam

Also if you are interested on Game Boy development I would like to recommend you to take a look at Imanolea's timelapse (the bg music is from Jet Set Radio!!) of his game Sheep Kaboom and if you understand spanish then you also have the video of the full development process.

After the jam I also added a few improvements to ZGB:

- Started to optimize a few core parts in assembly (since the latest SDCC allows me to mix C and asm I can now do this)

- Implemented double OAM buffer (this fixes flickering with sprites and they will no longer be splitted into two, so now you can use big sprites safely)

- Fixed the bug that was causing a random tile in the background to not be properly updated sometimes

I will continue the development of ZGB during this year, so get ready for the BitBit Jam 5!!

ZGB, a little engine for the Game Boy

2017-01-03T13:03:00.002+01:00

2016 has been an interesting year for the Game Boy scene. I remember back in 2015 talking with people developing for the Game Boy saying lots of docs with important info had been lost over the years and that the scene was dying... Well, I am not sure what happened, but in this past year I've seen some really cool games like: carazu, Rocket Man, Where's my cake?, Soup Raiders: Jailbreak, Biotic Limit, Snake Bird, Araku Hime: The Red Princess, Guns & Riders... it seems that the game boy scene has revived!!

Besides Pretty Princess' Castle Escape and Super Princess' 2092 Exodus I have been working on an engine that at some point I decided to name ZGB. This is the engine that both games are using. Some of its features:

- 4 directional scroll that allows maps bigger than 32x32. This is done updating the current row and column as the scroll moves.
- Sprites pool, that will help you manage everything that is moving on screen. It will also handle the creation and destruction of new sprites on screen
- Animations
- Collisions, sprite vs sprite and sprite vs background
- Automatized build support. Just 3 lines of code
- Bank management. Easy to select the bank for every file on the project and transparent bank switching in most cases
- Fonts and printing, and also some tools that will help to debug some values
- Music, using the legacy version of gbt-player
- Sound effects, using the fixed version of the sound sample that comes with the gbdk

ZGB is available on github. You can take a look at all the things you can do with it and there is a tutorial showing you how to create a game step by step. You can also download the source code from Pretty Princess' Castle Escape and Super Princess' 2092 Exodus and see how they do their stuff (or even create some rom hacks if you want :P)

There is a tutorial showing you how to code this

Just for clarification: this is not the definitive engine for the Game Boy. It is written in C using gbdk and that adds a lot of extra garbage on the code . Also there are some parts that still could be optimized a lot. But I think it is good for people who want to do something relatively fast (You know what other options you have if you really want to squeeze the machine). I think it perfectly fits on a game jam.

There will be more game jams in 2017. I'd like to ask you to give ZGB a try. You'll make me very happy if you create something fun with it (I might even cry). I have already fulfilled one of my childhood's dreams and would like to see you doing it too: create a videogame for the Game Boy.

Happy coding!

ZGB on github

Super Princess' 2092 Exodus

2017-01-02T13:23:00.000+01:00

Initially developed for the gbjam5 this is the second game I develop for the Game Boy and also together with sergeeo doing the art and music.

The gbjam5 ran from October 1st 2016 at 7:00 AM to October 10th 2016 at 7:00 AM. 399 games were entered, wow! Contrary to the bitbitJAM the games were not required to work on real hardware, actually the games just needed to be thematized as Game Boy games. I already had the engine I created for Pretty Princess' Castle Escape and I wanted to give it another try. Most of the time I spent on the bitbitJam was actually on the engine and not the game itself, so I knew we could do something better.

The first version of Super Princess' 2092 Exodus was developed in 48 hours. It only contained one level (7 screens) but it was more complete than Pretty Princess. I saw there was still a lot of improvements that could be done on the engine so I decided to continue working on it for a while. At the same time we also wanted to improve the game after the jam, so since them we have:

- Improved the jump (that was the main complain from people)
- Added 2 new levels, with their music, tileset and maps
- Added the screen transition similiar to the one you see in Megaman Games
- Moving Platforms
- 5 new enemies
- Better menus
- Sound effects
- An ending!

The game is not hard but it isn't easy either... in other words you won't finish it on your first try, just like videogames used to be. If you get killed, just try again

We are very happy with the result and hope you all enjoy it. You can play it here (just remember the experience is much better if you download the rom and play it on an emulator, or even better on real hardware)

Source code is also available on github

Game Boy Development - Tips and Tricks (III)

2016-12-04T12:18:00.000+01:00

This is the 3rd post on the series Game Boy Development - Tips and Tricks

Game Boy Development - Tips and Tricks (I)

Game Boy Development - Tips and Tricks (II)
Game Boy Development - Tips and Tricks (III)

7. SDCC Issues

No matter how you look at it, the SDCC that comes with the GBDK has some serious issues. Here I am going to talk a little bit about some of them that I have been able to isolate an reproduce 100% and the workarounds I was forced to use.

1. Minus unary operator (-) doesn't work with numbers bigger than 130

The minus operator used for negating a number either gives you a random value or crashes. You can easily test this with the next code:

void Test0() {

INT16 n = 1000;

INT16 tmp = -n;

//Printing -n crashes

printf("%d neg: %d", n, tmp);

}

For some reason it only fails with numbers bigger than 130, so you can safely use if with 8 bits values (because the biggest 8 bit signed is 127). You shouldn't use it with unsigned values for obvious reasons.

The workaround is simple but annoying, use the next macro that negates a two's complement number

#define NEG(A) (0xFFFF - A + 1)

void Test0() {

INT16 n = 1000;

INT16 tmp = -n;

//Workaround

printf("%d neg: %d\n", n, NEG(n));

}

2. Extra cast is required for adding an 8-bit value to an unsigned 16-bit value

I have to admit I wasn't sure at first it this was a bug or not. Mixing signed and unsigned values is always complicated but when you start using unsigned values is going to happen sooner or later. I just wrote a similar code on Visual Studio using shorts and ints and it seem to be a bug according to that.

Calling the next function with v0=100 and v1=-50 outputs 306 instead of 50

void Test1(UINT16 v0, INT8 v1) {

printf("%d ", v0 + v1);

}

At least for this one there is an explanation. The compiler is converting v1 to unsigned (256 - 50 = 206) and adding that value wich gives that result.

If Instead of writing the test as a function with two parameters we declare the vars as local:

void Test1() {

UINT16 v0 = 100;

INT8 v1 = -50;

printf("%d ", v0 + v1);

}

then it outputs 50. This is probably resolved by the compiler but because of the lack of consistency there is definitely something wrong going on here

The workaround is simple (but once again annoying), you just have to force a cast like this:

void Test1(UINT16 v0, INT8 v1) {

printf("%d", v0 + (INT16)v1);

}

3. Right Shift operator (>>) doesn't work with 16-bit values

Similar to the unary minus, the >> operator either crashes or gives you a random value. The next code crashes:

void Test2() {

UINT16 v16 = 50;

UINT16 n = 2;

printf("%d ", v16 >> n);

}

Also 50 >> n or v16 >> 2 will crash but if you write 50 >> 2 that works, I think the compiler is resolving that on compilation time. The workaroud I found here is a big surprising since it uses the operator itself. You just need to use the next function:

INT16 DespRight(INT16 a, INT8 b) {

return a >> b;

}

void Test2() {

UINT16 v16 = 50;

UINT16 n = 2;

printf("%d \n", DespRight(v16, n));

}

that seems to stop some kind of optimization that at the end is breaking up everything... strange

The Left Shift operator (<<) seems to work without problems

4. Comparing 8 bit value from struct with another 8 bit value fails

This one was causing a very odd behaviour on my engine making some sprites not properly being spawned. Calling Test3 here with a value of 5 will output 1 (TRUE)

struct StructTest {

UINT8 v8;

};

void Test3(UINT8 v8_0) {

struct StructTest test = {0};

printf("%d ", (UINT16)(test.v8 == v8_0));

}

This won't happen if you use 16-bit values instead. I found a couple of workarounds here, you can either change the order of the comparison:

void Test3_fix(UINT8 v8_0) {

struct StructTest test = {0};

printf("%d ", (UINT16)(v8_0 == test.v8));

}

or cast the values to 16-bit

void Test3_fix(UINT8 v8_0) {

struct StructTest test = {0};

printf("%d\n", ((UINT16)v8_0 == (UINT16)test.v8));

}

Something interesting is that if you write the code followed by the workarounds like this:

void Test3(UINT8 v8_0) {

struct StructTest test = {0};

printf("%d ", (UINT16)(test.v8 == v8_0));

printf("%d ", (UINT16)(v8_0 == test.v8));

printf("%d\n", ((UINT16)v8_0 == (UINT16)test.v8));

}

then it outputs the right value (¿?¿?) in the 3 cases

That's all for now. I have created a public repository wit the tests here, feel free to contribute and if you find any mistake on anything I said please let me know. I have tried to compile all this using gbdk-n which works with the latest version of sdcc but since it doesn't support printf I haven't been able to test it. Also gbdk-n doesn't have proper support for banks yet and that is a big problem.

Getting the Wii core back

2016-09-11T19:32:00.001+02:00

One of the things that has been bothering me over the past 4 years is not being able to compile for the Wii. I had support for it a few years back, but then I introduced several improvements and never found the time to work on them for the Wii.

Recently with the 3ds port a bit more stable I decided to get it back. There are other platforms I want to support in the future but before that it is important to get all my cores up to date. Taking advantage of all the things I did for the 3ds and all the improvements that had been added to Dolphin during all these years I had finally updated it!

And of course I had compiled a version of

Rokoban

and Whack Mania

If anyone is still playing Wii homebrew games out there, please let me know your thoughts!

Game Boy Development - Tips and Tricks (II)

2016-07-31T17:17:00.001+02:00

This is the 2nd post on the series Game Boy Development - Tips and Tricks
Game Boy Development - Tips and Tricks (I)
Game Boy Development - Tips and Tricks (II)
Game Boy Development - Tips and Tricks (III)

5. The game loop

Most of the examples I've seen contain a main loop similar to this

void main() {
<game initializations>
while(1) {
wait_vbl_done();
...
<process input>
<your frame update>
}
}

this is a good starting point. Waiting for the vblank interruption prevents your game from running faster than it should. If you start with this and keep coding you'll eventually notice a frame rate slowdown. A high slowdown actually, and that is because your frame update at some point takes more time than what is available between 2 vblanks, but you are still waiting an extra vblank.

1. Skipping vblank wait when we don't need it

One way to improve the previous code will be:

void vbl_update() {
vbl_count ++;
}

void main() {

//Subscribe vbl_update to vblank interruption
disable_interrupts();
add_VBL(vbl_update);
set_interrupts(VBL_IFLAG);
enable_interrupts();

while(1) {
if(vbl_count == 0)
wait_vbl_done();
vbl_count = 0;
...

}
}

in this new code we have declared an interruption that will store in a var the number of vblanks that have happened during the current frame. If there are more than one we no longer need to wait to the vblank and we can continue processing. Bear in mind this can duplicate your framerate up to x2 specially in situations where your processing takes more than one vblank just for a few instructions

2. Frame skipping

This is a good improvement, but it can be improved even more by using frame skipping. As its name says it consists of skipping the painting of some frames to save processing time and this way keeping the game logic running without suffering an slow down. So let's say your game is running at 60Hz meaning your fixed update time is 0.016 secs aprox, in normal conditions you will update your logic 0.016 secs, paint, update 0.016 secs, paint... and so on. Then at some point you realize that updating your logic takes more than 0.16 secs and in order to prevent an slow down you start dropping frames like: update 0.016 secs, update 0.016 secs, paint, update 0.016 secs, update 0.016 secs...

In the Game Boy the painting happens automatically and it takes 0 processing time from your main loop. The only thing you need to do is prepare the OAM table and update the scroll coordinates and it will just happen. So just doing two consecutive updates during one frame iteration will not help up us at all

Once thing we can do though is processing several updates together. Instead of updating 0.016 secs and then update 0.016 secs we can do one single update of 0.032 secs which basically means multiplying all your updating calculations by 2 (which is a very simple operation as we saw), like this:

...
while(1) {
if(vbl_count == 0)
wait_vbl_done();
delta_time = vbl_count ? 1 : 0;
vbl_count = 0;
...
}
...

so now we have a var called delta_time that is 1 or 0 depending on having to do frame skipping or not. If for example in some of your updates you were doing

sprite.x += 1;
you just need to change it to:
sprite.x += 1 << delta_time;
x << 0 is the same as multiplying by 1 and x << 1 is the same as multiplying by 2

On this implementation we are just skipping one frame, doing 2 will be complicated because that cannot be done with a shift operator. Skipping 3 will be posible but If you need to do that you should probably take a look at your calculations and try to optimize a little bit (I mean your update is taking 4 times what it should...)

3. Keeping the scroll movement smooth

Even though your game is not running at 60Hz you can still do your scroll being updated at 60Hz if you update the scroll position registers during the vblank interruption. In order to do this you should store your scroll position in a variable during your update process and then refresh the scroll position registers during vblank. But instead of doing

SCX_REG = scroll_x;

update them like this:

if(old_scroll_x < scroll_x)
old_scroll_x ++;
else if(old_scroll_x > scroll_x)
old_scroll_x --;
SCX_REG = old_scroll_x;

where scroll_x is the current x position of the scroll and old_scroll_x is the position in the previous frame. If your scroll was moving faster than one pixel per frame sometimes you can improve this with an small spring interpolation

if(old_scroll_x < scroll_x)
old_scroll_x += (scroll_x - old_scroll_x + 1) >> 1;
else if(old_scroll_x > scroll_x)
old_scroll_x -= (old_scroll_x - scroll_x + 1) >> 1;
SCX_REG = old_scroll_x;

And you should do the same for the y axis. You can check the full implementation here

6. Funny things in the world of 8 bits

Here is a list of some of the things that made me waste some time because I am not very used to work with these kind of limitations

- printf implementation only works with 16bits values. Funny when this is the only method you have to get some debug info and you realize you are printing all that info incorrectly. If you want to print the values of 8bits vars ensure you do a casting:
printf("signed:%d - unsigend %u", (INT16)signed_8_x, (UINT16)unsigned_8_x)

- lcc optimizes array indexing using ints, which in 8bits limits array access to 128 as stated in the documentation. It also says that for statically allocated arrays this doesn't apply. At some point of the implementation of the SpriteManager I started seeing some weird behaviour and it took me a while to discover that actually when accessing sprite[10] the 10 was calculated as sizeof(struct sprite) * 10 instead of sizeof(struct sprite) * (UINT16)10 giving me te wrong address of sprite 10 and causing some weird behaviour

- As seen above it is actually a very bad idea to randomly acess an element of an array of structs because it contains a multiplication. Instead it is a good idea to create an array of pointers to the elements of the array on startup and use this array instead

- I've read in lots of places that structs have a lot of problems and you shouldn't use them... as far as I have seen there are no problems using them (except for the array accessing issue which actually makes sense for optimization purposes)

- Also, I've read in lots of places that you cannot use pointers to functions. I have successfully used pointers to functions of 0 and 1 parameters. And the GDBK uses this for interruption handler!

- There are a lot of tutorials telling you how to do things... you'll be surprised to see some of them contain errors and you should use them as reference but never as the absolute truth. Once again check this post from AntonioND

- As a final conclussion... is the GBDK a mess like lots of people are saying on lots of forums and blogs? I have been using it for a month and I can tell you that is a lie. I am not gonna say working with it is easy but that's not the GBDK's fault alone. First there is the SDCC which is the compiler the GBDK is using and probably the one people should be blaming. There is a new version of the GDBK using the latest version of SDCC here, I didnt' have the time to test it. But most of the things people seem to complain about are more related to a lack of C knowledge (and again, this is not a good enviroment for learning it) and the limitations of having to work with and 8-bit machine. The creators of the GBDk are perfectly aware of this as you can see here

Game Boy Development - Tips and Tricks (I)

2016-07-28T07:43:00.001+02:00

This is the 1st post on the series Game Boy Development - Tips and Tricks
Game Boy Development - Tips and Tricks (I)
Game Boy Development - Tips and Tricks (II)
Game Boy Development - Tips and Tricks (III)

As promised here is the first post with some advices based on my experience programming for the Game Boy during the Bit Bit Jam 3.

1. Choosing your SDK

The Gameboy has some different SDks you can choose to work with. The two main ones are the GBDK and the RGBDS. Choosing between any of them depends on what you want to accomplish and what skills you have. Check the next table with pros and cons of each one

GBDK	RGBDS
C and asm	asm (better than asm in GBDK*)
Slower if you use C	Asm is always faster but requires experience
Faster to write programs in C	Assembly is very low level, requires more time
Reliable for a jam	If you are not an skilled programmer you might not finish your jam entry
Horrible SDK for learning C because of the 8bits limitations, no debugger....	Perfect for learning asm. You can even use a debugger with the BGB emulator

With all these in mind, I chose GBDK because I have a lot of experience with C and C++ and I was feelling more confident to finish the game with it.

*so I've heard, because I didn't have the chance to try it

2. Getting your environment ready

I will suggest spending some time doing this, it can save you from lot of problems that will happen that last hour before sending the game. Code completion, launching the emu after compiling and the ability to add or delete files from your project easily are the things you should focus to get before starting your project.

A couple of weeks before the jam I started playing with GBDK and getting my development environment ready. Same as I did for the 3ds, Ds and the Wii I started configuring visual studio and some makefiles (see this post for more info). Most of the tutorials I followed along the internet were using some dos .bat files but I was looking for something more general. I created a makefile that:

- Compiles any source found under the folder src, so you don't have to specify the list of files to compile

- Parse the extension of the file to select the bank (anything.c will be on bank0, anything.b1.c will be on bank1, anything.b2.c on bank 2 and so on...)

- Automatically changes the unsigned char of the resources exported by GameBoy Map Builder and GameBoy Tile designed to const unsigned char

And some other features that you can check here. The important thing is having a confortable environment so you only have to worry about coding the videogame

If you are under Windows you will need a way to run makefiles. Since I have been using devkitpro for a long time I already had msys installed. One funny thing that I noticed is that the version of make that comes with devkitpro doesn't display any compilation errors so I guess the stderr is not properly configured. If you have the same problem you just need to download the last version of make for windows here

3. Banks

I would recommend reading the full documentation of the GBDK prior to any development. And specially trying to understand banks, what they are and how they work. AntonioND explains it pretty well on this post. The idea is very simple. If you take a look at the size of variables of the GBDK you'll see that the size of a pointer is 2 bytes. The maximum address you can point to with 2 bytes is 65535 (2^16). In these addresses the gameboy needs to get access to everything, not only the rom. Basically it needs 32kb for internal registers: sound, video, power, etc (you can find the complete list here if you are curious) and then there are other 32 kb for rom access(the cartdridge data). These 32kb are splitted into two: a fixed part that is always accesible (called bank0) and a swapable part (by default set to bank1). You can change the starting address of bank1 and make it point to addresses beyond 65535. Each group of 16386 (16kb) is known as a bank

So the idea is splitting your code along any of these banks and before excuting any part of it swapping the start address so the code can be reached. Take some time to understand this because it is extremely important. And also pay attention to the next things:

- You can only swap banks from code that is stored in bank0. Actually you can swap banks from any bank if you dare but your program will crash and it has an easy explanation. In any computer no matter how big or small it is there is a register (usually known as EIP) that contains the address of the next instruction to be executed. If no jump occurs then this register will automatically advance to the next register and execute the next instruction and basically that's how programs run. So, what will happen if you are in bank2 for example and swap to banks3? The EIP will execute the command to change the bank (in bank2) then it will advance to the next register and will try to execute the next command. The problem is that this comand that was supposed to belong to bank2 now belongs to bank3 and it can be literally anything. An easy solution to this is calling a function on bank0 (always accesible) that swaps banks, do the job on that new bank and then before returning swap banks back to bank2

- Lcc errors. You will eventually find a message like this from the compiler "warning : possibly wrote twice at addr 407a (21>21)". This will happen everytime you write code larger than 16kb and part of it ends in addresses that belong to the next bank. When this happens you should start moving your code to another bank

- Try to fill all banks with some info. If you have decided your game is gonna take 4 banks then the size of the game will be 64kb (16kb per bank) event if you don't fill them. Because of this it is a good idea to put some info in each bank from the beginning, otherwise you won't see the message I was telling you before when a bank gets full and your program will randomly crash at some point

- A stack can be very helpful to deal with bank swapping. Implementing a stack is very simple, you can check my implementation here. Once you have a stack implemented you can use it to move between banks like I do here. Everytime I want to change to a new bank I call PUSH_BANK and when I finish I just call POP_BANK so it automatically leaves me on the previous bank. Using this technique I was able to call gbt_update that automatically changes the bank to bank1 on my vblank interruption and then return to the bank I was previously working on calling REFRESH_BANK, fixing the issue AntonioND is stating on this post

4. Basic Maths

The Gameboy isn't very powerful and it can't even deal with multiplications or divisions, so you should avoid them at all cost (you can use them, but the performance will suffer). Most of these multiplications and divisions can be replaced by simpler operations, like:

- instead of multiplying by any power of 2 use the shift left operator (<<). Specially for multiplying by 2 use x << 1

- instead of dividing by any power of 2 use the shirft right operator (>>). Specially for dividing by 2 use x >> 1

- instead of the module operator (%) with any power of 2 you can do a mask. For example for getting the module 8 of a number do x & 0x7 (7 is 111 in binary so using & here turns everything except the last 3 digits into 0 which is what we want)

- the gbdk manual encourages you to use unsigned values. Take into account that these values are always bigger than 0. So doing something like 3 - 4 will result in an overflow giving you 255 (or 65535 if you are using 16bits) and checking if this is < 0 will unexpectecly return false. The best way I found to deal with this is masking against 0x8000 (1000 0000 0000 0000 in binary) and checking that the result is 0 (that 1 in the highest bit will only happen after an overflow)

BitBitJam 3 - Pretty Princess' Castle Escape

2016-07-26T08:00:00.000+02:00

The bit bit jam is a retro jam based on old systems up to 16 bits. The jam lasts one week and you can use any technology you have developed before that week. The game must work in real hardware.

Before the jam starts a theme is randomly selected and this year it was "Red Hot Princess Carnage". A total of 20 games were presented. You can take a look at all of them here, and also you can check the winners on each different category: best theme, best platform usage and funniest game

This year I ended up joininig forces with sergeeo. He was in charge of the music and graphics and I was working on all the coding stuff. Together we created Pretty Princess' Castle Escape for the old nintendo Game Boy. Althought we finished the game on time we continued working on it after the jam and finally we have released a new version we consider final. Check it out here!

We'd like to thank all the guys playing it and specially the ones who have uploaded some videos:

Also special thanks to David Colmenero for organizing the jam and for convince me to participate

During this week I'll be posting a few entries with my experience developing using the GBDK providing some info that I hope will be usefull for someone. Stay tuned!

Rokoban for Nintendo 3DS

2016-01-05T14:24:00.001+01:00

Rokoban is not a new game. I already released it on Nds and later on the Wii (and it won the 4th place on the Wii Homebrew Competition organized by tehskeen in 2008). After that I was going to release a new version for IOS and Android about 4 years ago. Although very close to finishing it, I had to abandon it because back on those days I needed to start working on Whack Mania.

Together with me working in this new version was Juanmi, making all the graphics. He actually finished all his work but I never got the time to put it all together. After the release of Whack Mania the engine had changed so much that making it work again was a bit complicated.

That was until this past summer when I actually realeased Whack Mania for 3ds. I was thinking which other project I could work on after it when william341 in the gbatemp forums suggested me to work on Rokoban. There are other projects I was thinking of but then I did a quick test and in a couple of days (holidays, yeah!) it was running again. Althought making it work is just the first step I decided to focus on it, the good thing was I already had all the graphics and menus :)

A few months have passed and finally I am going to release it hoping you will enjoy it and it will become a good contribution for the 3ds scene which as of today keeps growing and growing. Also I am going to finish what I started 4 years ago with poor Juanmi and he is gonna see his job finally released

Download it from the links below. The game is available in 3ds, cia and 3dsx format. There is also the Windows version if you wanna give a try on your PC. I also have an Android and IOS build but I don't really know what to do with them...

Download: Rokoban 3DS

Download: Rokoban Windows

As usual, please leave me your feedback in the comments. Thanks in advance!

Familiar Game Camp

2015-08-13T22:40:00.000+02:00

The Familiar Game Camp was celebrated the past August 1st-2nd at Málaga, in the south of Spain (sadly we didn't find the time for visiting the beach :_(... )

It was a weekend for meeting nice people and sharing our experiences, and also meeting the new generations. There were workshops for chiptunes, pixel art and Gameboy development and talks about the Familiar Game Jam, Publishing on Steam, Game Art, AltGames and Not Games and what to do with your free time.

This time I didn't want to talk about some technical stuff so my talk was a bit more related to what I do with my free time, based on my experience along all these years of videogames development.
Here are the slides of the presentation I offered
- Programar por Trabajo vs Ocio (spanish)
- Coding for Work vs Fun (english)

You can find some posts covering the event here:
- Official website (with links to all workshops and talks)
- Sergeeo's post (he is the one organizing so you should take a look)
- Crónicas de #FamiliarGameCamp
- Twitter #familiargamecamp (I have stolen all the photos from there, yeah)

Some of us were missing the Game Conga, but maybe next year it will happen... :D

I hope to see you again soon!

Whack Mania on Nintendo 3DS

2015-08-13T00:57:00.002+02:00

Remember Whack Mania? You should if you know me, but just in case here is a video to refresh your memory

I have finished porting my little engine to the nintendo 3ds meaning the game is now working too. As you can see

I needed to to a few changes before releasing it:
- Since the game was thought to use a touch screen I had to adapt the controls a little bit (I could have used the touchscreen but I wanted to have the 3d effect instead
- I have reviewed all the levels and kept only those that I considered fun enought (from 40 levels, there are only 14 here... you can take a look at my postmortem to see why :P)
- I had made myself sure that the game doesn't have any memory issues and it is stable (and it is now). Also I needed to check it was working using the Homebrew Launcher, cia or 3ds formats
- Some other minor changes I don't remember right now. But the good thing is that the code is exactly the same that I used for the IOS or Android version

Here is the link if you wanna give it a try. The game looks awesome on the 3ds :)

Download: Whack Mania 3DS

3DS Homebrew Tips and Tricks (III)

2015-07-19T14:04:00.001+02:00

This is the 3rd post on the series 3DS Homebrew Tips and Tricks
3DS Homebrew Tips and Tricks (I)
3DS Homebrew Tips and Tricks (II)
3DS Homebrew Tips and Tricks (III)

6. Adding sound permissions to 3ds files

Searching on the forums about sound you will find posts saying you cannot have sound using 3ds or 3dsx format (for example take a look af the F.A.Q in the blargsnes site or their wiki). So I spent a few days implementing my sound driver using the cia format that was supposed to be the only one supporting sound

That was hell. Everytime I needed to change anything I had to create the cia, transfer that to the console somehow (microsd management turned out to be the best option), delete the previous cia and install the new one. There wasn't anyway that I was aware of to automatize the whole big process.

Then I found this post clearly stating that the only thing you needed for having sound support in 3ds files is adding ns:s, am:u and csnd:SND service access on your rsf. Take a look here.

With the new ninjhax 2.0 released it seems that sound is also supported now on 3dsx files

7. Avoid GPU_TRIANGLE_FAN

It took me a few weeks to catch a random crash (the best of them) on one of the tests I was doing. At the end it turned out it was caused by using GPU_TRIANGLE_FAN somewhere on my code. After replacing that with just GPU_TRIANGLES it never happened again.

Talking about this on #3dsdev on the irc channel there seemed to be at least one other person having the same issue. Probably there is still something wrong on the ctrulib with them so I would recommend not using them if you can.

8. Using RomFS

RomFS is the file system used by 3ds and cia files to store resources inside the rom itselt. Although there are some tools available for extracting it from dumped roms and then putting it back, the ctrulib doesn't have support for it yet.

I thought it would be great if I could distribute my apps without any external dependencies so I took a look into it.

There are two ways to include a romfs into your builds:

- The first is creating it with an external tool (like RomFS Builder) then using the -romfs option when calling makerom.

- The second hasn't been fully implemented (according to 3dbrew) but it worked for my particular case. On the rsf file you should add

RomFs:

# Specifies the root path of the file system to include in the ROM.

RootPath : "../bin/romfs"

The rootpath is relative to your makefile's location

With any of these options you will have a rom that includes a file system with the resources. Now, how do you get access to them? Take a look at the code I posted on this thread.

This code only gives you access to the romfs. Now because we don't have support for this filesystem we have two options:

- Implement it

- User another known Filesystem

I went for the second one. Since I worked a lot with .zip files when I ported the engine to Android I decided to use the same thing here. So basically, my filesystem is a zip file containing all my resoures placed inside a romfs.

Since this zip is the only file available on my romfs I just do a search of the string "PK" from the beginning of the romfs and there is my zip file located. Hacky, but works pretty well

9. Painting steps: clean, render, transfer and swap

As I said before my starting point was the gpu example. If you spend some time trying to understand how it works you'll soon realize this is what happens after the GPUCMD_Finalize() command:

- GPUCMD_FlushAndRun is called and the command list is processed making the rendering

- GX_SetDisplayTransfer is called after that and the content of the framebuffer is trasnferred to the specified LCD framebuffer

- GX_SetMemoryFill is called, cleaning the color and depth buffer

- gfxSwapBuffersGpu is finally called, swapping buffers (because the ctrulib by default uses double buffer)

This process happens for a single render, if you are using the 3D effect it will happen twice, once for each screen (I am just simplifying it)

So basically: we render the current frame, transfer it to the proper LCD, clean the frame and then do the double buffer swap. Anything strange here? We are cleaning the screen for the next frame before the next frame actually happens, and that's a bad idea because:

- At some points on my code I was changing the clear color and that was delayed one frame.

- At some points on my code I wasn't interested on cleaning the color buffer for a specific frame and it was being cleaned in advance

This is actually easy to fix if you move that call to GX_SetMemoryFill to the beginning (before calling GPUCMD_FlushAndRun). Don't forget to move also the call to gspWaitForPSC0, and ensure that you actually want to clear the current color buffer or depth buffer.

10. Improving the 3D steresocopic effect

Another problem that I found with the gpu example is that no matter how you place the 3D slider on the console it is very hard to the get the feelling of 3d. Taking a look at the code I found these calculations being done for each eye:

mtx44 m;

loadIdentity44((float*)m);

translateMatrix((float*)m, interaxial*0.5f, 0.0f, 0.0f);

gsAdjustBufferMatrices(m);

what this is doing is adding a translation to the whole render process for each eye. So basically moving the camera to the left for the left eye and to the right to the right eye. It just doesn't work well. I changed it into this

mtx44 m;

loadIdentity44((float*)m);

rotateMatrixY((float*)m, -slider * 0.06f, false);

gsAdjustBufferMatrices(m);

which rotates the camera instead of displacing it for each eye. This works way more better :)

And that's it. I have concluded these series of posts. I just hope anything I had been writing these days will be useful for someone and I would like to see more homebrews released on this amazing console. Specially games.

Happy coding!

3DS Homebrew Tips and Tricks (II)

2015-07-18T10:22:00.000+02:00

This is the 2nd post on the series 3DS Homebrew Tips and Tricks
3DS Homebrew Tips and Tricks (I)
3DS Homebrew Tips and Tricks (II)
3DS Homebrew Tips and Tricks (III)

3. Application Icon, banner and RSF

If you are going to distribute your creations on cia or 3ds format then you are going to need a banner and an icon. For this I am using bannertool cerated by Steveice10. You can find a compiled version of it on this thread

- Icons: you create icons using this:

bannertool makesmdh -s $(APP_TITLE) -l $(APP_DESCRIPTION) -p $(APP_AUTHOR) -i icon.png -o icon.smdh

where icon.png should be a 48x48 image. You can define AP_TITLE APP_DESCRIPTION and APP_AUTHOR somewhere else in your makefile, like this

APP_TITLE := "Jumping Jack"
APP_AUTHOR := "Zalo"
APP_DESCRIPTION := "My very first game for the 3DS"

Icons should alse be distributed with your 3dsx file so the homebrew launcher can display information about your homebrew

- Banners: you create banners using this

bannertool makebanner -i banner.png -a audio.wav -o banner.bin

where banner.png is a 256x128 image (you can use transparency) and audio.wav I am not sure but I am always using 16 bits, 44100 Hz and stereo for them

- RSF: this files are configurations files for your project. You need a different one depending if you are going to build a cia or a 3ds. There are two good examples on Rinnegatamante's Lua Player Plus for 3DS. Here is the rsf for 3ds with audio support (see point 6) and the rsf for cia files. You only need to edit the BasicInfo and TitleInfo usually. For the TitleInfo you are gonna need a UniqueId. It is recommented to use and ID between 0xF8000 -0xFFFFF or 0xFF000 - 0xFF3FF which is used for Evaulations and Prototypes, ensuring you won't have a collision with a released app. To ensure you don't collide with another homebrew take a look at this post

The banner, the icon and the rsf are required for makerom to create your 3ds using the command

makerom -f cci -o $(PROJECT_NAME).3ds -rsf gw_workaround.rsf -target d -exefslogo -elf $(PROJECT_NAME)_stripped.elf -icon icon.bin -banner banner.bin

or to create your cias using the next one

makerom -f cia -o $(PROJECT_NAME).cia -rsf cia.rsf -target t -exefslogo -elf $(PROJECT_NAME)_stripped.elf -icon icon.bin -banner banner.bin

[Update: take a look at the 3DSHomebrewTemplate created by Steveice10, those are probably the best makefiles around]

4. Pica Texture Format

Textures are optimized on the 3DS GPU in a special format optimized for cache called Pica Texture Format. This means that in order to use it with the GPU_SetTexture function, first you need to convert it (either on real time or preprocessing it first)
It took me a while to get the code working for this (as you can see on this thread). But yeah, you just need to copy the code I posted there (actually I forgot to do it and I just did it now)

5. Sideways framebuffer

The framebuffer on the 3ds screens is sideways. Meaning it really goes like this:

In other words, what you really have is an screensize of 240x400, so if you don't do anything special this is what you'll get:

Usually you don't want this (not in the 3DS specially, because if you rotate the console you cannot have the 3D effect working). You need to do three things

- Everywhere in your code where you need the screen size, use 400x240 (which is what we want)

- When you set the viewport size make sure you swap the params. In other words, call

GPU_SetViewport((u32*)osConvertVirtToPhys((u32)gpuDOut),(u32*)osConvertVirtToPhys((u32)gpuOut), y, x, h * 2, w);

- You need to premultiply your projection matrix by this one

float mtx_projection_tmp0[16] =
{
0.0f, 1.0f, 0.0f, 0.0f,
-1.0f, 0.0f, 0.0f, 0.0f,
0.0f, 0.0f, 0.5f, -0.5f,
0.0f, 0.0f, 0.0f, 1.0f
};

which basically swaps the x and y axis and also converts z from [-1, 1] to [-1, 0] because those are the viewport coordinates for the 3DS.

Now you can use the typical functions for creating a projection matrix, ortho, oblique... this is important if you are working on a cross platform environment. Creating a particlar case for a specific platform is a bit annoying and will cause you problems

3DS Homebrew Tips and Tricks (I)

2015-07-17T07:30:00.000+02:00

So, as I said on my previous post I am gonna start a series of posts talking about some things that might be useful for those of you intereseted on developing for this machine. For me this is just a hobby and I cannot dedicate 100% of my time, just 1 hour a day and a little bit more during the weekends, so being stuck on something is a bit frustrating.

I have spent much more time stuck on some stuff and searching on forums than actually coding. Hoping that this will help you I have made a compilation of the things that would had saved me a lot of time if I had knew how they were before.

This is the 1st post on the series 3DS Homebrew Tips and Tricks

3DS Homebrew Tips and Tricks (I)

3DS Homebrew Tips and Tricks (II)

3DS Homebrew Tips and Tricks (III)

1. 3dsx, Cia and 3ds

These are the 3 formats that you can compile your programs into.

- 3dsx this is the format that the ctrulib (which is the SDK for homebrew in 3DS) supports officially. If you are gonna release something you should distribute it under this format. You need to execute the Homebrew Launcher to use it. You need to execute ninjhax for that. The problem is, some of us cannot do this, either because we don't have Cubic Ninja or because we have updated our emunands beyond 9.2 and now it doens't work anymore (take a look at this post)

- Cia this is the format that you use for stuff that needs to be installed in the console (as channels). Some people doesn't like it because it has been used a lot for piracy (way more than for homebrew). You need to use a CFW (Custom Firmware) and then a CFW installer in order to use it. You don't need a flaschcard for this but your console needs to be on 4.5 firmware

- 3ds this file is the oficial format supported by nintendo. You need a flashcard for this and that's why some people doesn't like it.

As I said the makefiles that come with the ctrulib only support building for 3dsx. If you want to create your own makefiles supporting those formats you can take a look at the ones used in GameYob. You still need to take a look at how to create banners, icons and sounds but I will cover that on the 3rd point.

2. Setting up a good Developement environment

I am not going to cover here how to get started with 3ds homebrew. You can take a look at my previous post here. In sort you need to download devkitpro and from there devkitARM. I don't recommend installing ctrulib from devkitpro. The version that comes with it doesn't include examples and it is hardly up to date. Your best option is getting ctrulib from github and compiling it yourself. You need to be careful because then you are gonna be working with a library that is not stable but you can always take a look at the changes and see what's going on. I usually update it once a month unless there is an important update.

Take some time compiling and running the examples. If one of them doesn't work take a look at the last time it was updated and try again with a branch created on that day. If you are planing to do 3d games the best start point for you is the gpu example.

Once you reach the point when you have compiled and executed some examples and played with them a bit using programmers notepad (or any other text editor you want) you might start considering using another IDE a bit more powerful

The one that I am using is Visual Studio 2010 but what I am gonna post here should be very similar in any other version.

- Create a makefile project

- Linking it to our Makefile
Go to Project properties and configure it like this:

- Build command line:

make

- Clean commands:

make clean

- Rebuild command line:

make clean

make

you can now close visual studio go where you have created this project and copy it into the folder of the example you want to compile. After that if you open it and compile, it will run the makefile and create a 3dsx as expected. Rebuild and clean will also be working as usual

- Adding intellisense

Add the next paths into the Include Search Path

- C:\devkitPro\devkitARM\arm-none-eabi\include

- C:\devkitPro\devkitARM\include

- C:\devkitPro\libctru_git\libctru\include

where C:\devkitPro is the folder in your harddrive where you have installed devkitpro

Now code completion should be working as well as going to function declaratinos.

- Creating a external tool for copying contents into the console

- In yout makefile add a target called install similar to this:

install:

cp ../bin/$(PROJECT_NAME).3ds g:/

@echo Done

- Go to Tools/External Tools

- Add a new Tool called Install like this

- Now Create a New Toolbar called Homebrew (Tools/Customize/New...)

- Go the Commands tab and select the toolbar created. Press Add Command and in Tools search select External Command 7 (yeah.. this is a bit ughhh... but it works)

You should now see your new ToolBar located in the Toolbars and a the button Install on it

Now when you compile you just need to put the SD on your computer, press Install, wait for the message "Done" and put it back on your console to execute

This is very useful if you have a flashcard and you work with the 3ds format. Actually this is the fastest way to work. Compilation times are big and you need to reduce it the maximum posible (bear in mind that sometimes you just change the value of one var and recompile and you need to see the results as soon as posible). This is how I usually work

- I run the latest build on my 3ds and see that something doesn't work

- I take a look at the code, detect what's happening and make some changes. Then press F7 to compile

- While compiling I stop the build on the 3ds (by pressing the home menu and then closing the app)

- I take out the flashcard form the console, then the micro SD inside it and put it on my laptop

- By that time the compilation has finished so I jsut press Install

- I wait for the "Done" message, take out the micro SD from my laptop, and plug it in on the flashcard

- I put the flashcard on the console, select the rom and run it

This is usually about 20 seconds, which is not bad. And it is actually faster than sending the build via FTP (because you need to launch the client on the console for that, then send it form your computer, then close it... and it fails a lot).

It is even worst if you work with cias, because you need to install them on the internal SD and you cannot remove the SD while on emunad (the console freezes). You can again send the content via wifi (using the tool from nintendo is the best way, see this post) but it takes too much time.

Again, this is up to you, but for applications that are big I highly recommend getting a flashcard and working with 3ds files directly.

Jumping Jack for 3DS

2015-07-15T19:00:00.000+02:00

Time for some releases!

As some of you know I have spent the last few months doing some coding for the 3DS. I have finally finished the porting of my little engine so it is now time for some posts talking about the experience and some things I wish I had knew before I started doing this. I am gonna be doing this during this week and the next one

But first. I want to release my first homebrew on this console: Jumping Jack 3DS. This is basically a port of the same game I released a few years ago for the Wii

I already wrote a post about it here

And here is the link if you wanna give it a try

DOWNLOAD: Jumping Jack 3DS

UPDATE: this is now working for ninjahx 2.0

Familiar Game Jam 4 - Dancing with wolves!

2015-05-10T14:42:00.000+02:00

So, yeah, one more time our favorite jam was celebrated in Seville during the weekend of 20-22 March 2015. This jam is just growing and getting better with every new edition, all thanks to sergeeo. This time it was celebrated on what we call the Enjoy room on my current company Genera Games. So, for some of us that meant staying at the office the whole weekend (just changing from one room to another). Totally worth it :)

There were 48 presential participants plus more teams working from their places, ending up with a total of 32 videogames. If you want to join the next one pay atention to the twitter account because this last time the presential places flew away in a few hours. You can take a look at the games on the gamejolt website (google chrome not recommended, because Google has recently stopped supporting the Unity player and most of the games use it)

The topic in this edition was movies from the nineties. So we had to chose a movie from that period and make a videogame based on that. And also the game had to cotain two different endings. You can imagine all of us searching on the internet the top charts from that time. We finally ended up chosing Dancing with Wolves, for several reasons. First, after all these years there aren't any videogames of that film. Second, we've been talking about making a dancing videogame during a long time. And third, we were sure nobody else were going to pick the same one :D

This time I was on a team with two of my workmates pedmuitor and brovador. I was in charge of the graphics (same thing happened on the First Familiar Game Jam, so I am kind of a senior jam artist ^_^U). During the first day we weren't sure if I should work on 3D or 2D. I finally went for 3D and started using 3ds max after all these years. I think it was a good decission because I could do lots of animations that in 2D would have been a pain (and less fun)

I didn't code a single line of code this time. Pedmuitor and Brovador did all the job. And if you are asking who did those wonderful menus it turned out brovador is a secret graphic designer. So basically the three of us were able to do this videogame you can play here (remember, no chrome)

It would be very unfair not to mention our music man. I never mentioned it before, but in the Familiar Game Jams there is a team of 3-4 guys doing the music for all the games. This time we were working with Carlos Vallejo who did a great job, you can listen to the music he did for us here

After the jam finished there was one week for meditating an voting. Our game received an overall score of 3.58 (over 5) and was ranked #9. Thanks everyone who voted us (except those who gave us low scores :D).

Take a look at the games (you can sort them by ranking) and enjoy. I'd like to finish this post with a video that was posted on youtube a few days after the jam took place showing you what a good time we had. See you on Familiar Game Jam 5!

PS: some links covering the event:

- Prize ceremony on sergeeo's blog (spanish)

- Undead Aubergine enterview and their postmortem (spanish)

- JuegaRPG (spanish)

- GameCrimes

- GeekyJuegos did some great articles about several games of the jam (including ours) (spanish)

- Jupiter Hadley post also take a look at her video compilation series covering all the games

Freakend 2015

2015-04-20T23:29:00.000+02:00

The Freakend 2015 took place during the past 6th,7th,8th of March in San Agustín de Guadalix (Madrid, Spain). What's the freakend you might be wondering. It is basically an event where some people from the industry in Spain gather, talk about videogames, drink and eat pizza. Don't let the name confuse you, in spanish the word freak is used instead of geek, so imagine an event called geekend about videogames and there you go.

This has been the 4th one if I am not mistaken and my 2nd one. Also this has been the first year that the Freakend Android was celebrated, but that's another story. After the good experience of the last year I wanted to repeat again. I don't live in Madrid right now and this kind of events allow me to keep in touch with some old friends (it was good to meet arturogdg and chrisghead after all these years and also Diegobez and flipper83) and follow the status of some companies and the games they are doing.

Besides drinking and eating there are a series of very interesting talks along the whole weekend. On this event there were not only programmers, but also game designers, artists, producers, musicians... with such a mix it is hard that every speak was interesting for everyone, but we had the schedule from the beggining, so in case you were not interested in one of them you could always get along with people outside the main room. I actually attended all of them (I couldn't pay too much attention during saturday morning because I was finishing my own one)

In case you missed them, here are some links to the videos on youtube:
- Hernán y Mirella – GamesYouHear

- Rafael Muñoz – Testing automatico en videojuegos

- Javier Cantón – “Como guardar 6 floats en 32bits”

- Gonzalo de Santos – Desarrollo homebrew en nintendo 3DS: (it's-a me!!)

- Nacho Lasheras – Anatomia de GUI:

- Cesar Monterde – Tutoriales:

- Kike – Postmortem de Heart & Slash:

I wanted to talk about the 3ds scene. Because I had already done an introduction here in Seville on February (see my previous post), this time I wanted to talk a bit about the exploit itself. How does some people gain control of a machine that from start has been secured to avoid launching any unsigned program? Also I introduced the current state of the 3DS homebrew scene. Besides the video here are the slides in bot spanish and english

3DS Homebrew (Spanish)
3DS Homebrew (English)

I'd like to thank again Diegobez who was in charge this year and who did a great job, and flipper83 the creator of the event for insisting me during so many years on attending the event. And for teaching me that just being on a desk doing some stuff is not enought. You need to go out, meet some people, get some feedback, let others know you, etc. The freakend is a perfect opportunity for all this. See you next year!

PS: here are some links to other blogs covering the event (in spanish)
http://visualstudioex3.com/blog/gamedev/eventos/resumen-del-freakend-2015/
http://www.otogami.com/blog/freakend-2015/
http://geeks.ms/blogs/aperez/archive/2015/03/10/evento-freakend-2015.aspx

http://blog.kartones.net/post/Freakend-2015-and-my-Gameboy-Powerpoint-like-ROM

Pixels and Coffe 3DS workshop

2015-03-15T00:46:00.000+01:00

The past February 10th I was given the chance to offer a workshop introducing the homebrew development on the Nintendo 3DS. At first I was planning to actually talk about the DS but being a console that is becoming obsolete I decided to go for something more actual (I thought it'll be more interesting). This time it was organized by the guys from Pixels and Coffe (if you live in Seville and don't know what I am talking about you should take a look)

Lot of people came and I was happy to share with them one of my hobbies although there were some moments of chaos (ctrulib not compiling, emulators not launching...). I talked a bit about the history of the scene, the emulators, the exploits and we were compiling a Hello-world sample that I run on my 3DS using Ninjhax

Now it would be great if someone will try and join the community but honestly I don't think that is gonna happen :D

Anyways, thanks to everyone who came that day. I hope you had such a good time as I did and you actually learned something. Here are the slides in spanish and english if you want to take a look

3DS Homebrew (spanish)
3DS Homebrew (english)

PS: I am always delayed with it but next post I will be talking about the freakend and the other presentation I offered there
PS2: oh, and the new Familiar Game Jam is just around the corner!

Familiar Game Jam 3 (one month later, yippiee!)

2014-11-19T00:07:00.001+01:00

The third edition of the Familiar Game Jam took place the last October 17-18-19th. The Familiar Game Jam takes place in Seville (Spain) twice a year and the main purpose of the event is making a game in 48 hours based on the theme selected by the participants and surviving to tell your grandchildren

In this edition the chosen theme was misanthropy and the surprise element was neon lights. 27 games were presented on a jam that edition after edition grows in number of participants and quality of the games

The Rodriguez Team. From left to right: Chetrut, Rafa, Jesús and me.
Missing here are Sergio (music) and Javi Zumer (sound effects)

It is a good opportunity to meet new people. I was on a team called The Rodriguez (don’t ask) and our product was called GameJamthropy, a Game Jam simulator were you try to code your great game but people talking doesn’t let you so you need to shut them up throwing beers into their heads

We really suffered the last two hours before finishing it, and at some point I was doubting we were going to have a working product, but at the end we manage to do it not without some errors (like that shader not compiling in windows causing all the game look completely pink)

Two weeks after the jam I went with Chetrut to the award’s ceremony and to our surprise the game was given the jury’s award. We would like to thank everyone again for this. Also we found a video on youtube of someone playing it and having some fun which is always very rewarding (and it has a lot of views!)

Being happy with GameJamThropy we decided to continue working on it, fixing the errors and today I have uploaded the final version so far. The code is available on github (it is not a good code to learn anything from, so don’t get too excited ;)) Wanna give it a try and show the world how good your coding skills are? (or how bad :P?) We have implemented higscores for that!

PLAY GAMEJAMTHROPY ON GAMEJOLT

Here are some other articles covering the event
- A playlist with videos of all the games that were presented
- Anait Games talking about it
- Juegonautas
- Offical twitter account
- The offical video that I cannot link properly becuase blogger is shit sometimes

See you on the fourth edition!

Zalo DS Blog

A little bit of what I've been working on

ZGB

Z3D

ZIMGUI

REFLECTION

ZEDITOR

Handles

Custom inspectors

The Asset manager

TO DO

ZGBJAM 2

ZGBJAM

Simple yet powerful FSM implementation

1. The initial approach: using enums

2. Using Object Oriented Programming

3. State enter parameters

4. Using graphs

5. The Back Queue

That's it

Properly doing cameras interpolation through a target (II)

The Rotation issue

The Fov interpolation issue

Orthographic Cameras

Avoid Linear interpolation

Done

Properly doing cameras interpolation through a target (I)

A very basic Camera Interpolator

A little improvement

Interpolating through a target

BitBitJam 4 - Polka Sheep

ZGB, a little engine for the Game Boy

Super Princess' 2092 Exodus

Game Boy Development - Tips and Tricks (III)

This is the 3rd post on the series Game Boy Development - Tips and Tricks Game Boy Development - Tips and Tricks (I) Game Boy Development - Tips and Tricks (II) Game Boy Development - Tips and Tricks (III)

7. SDCC Issues

1. Minus unary operator (-) doesn't work with numbers bigger than 130

2. Extra cast is required for adding an 8-bit value to an unsigned 16-bit value

3. Right Shift operator (>>) doesn't work with 16-bit values

4. Comparing 8 bit value from struct with another 8 bit value fails

Getting the Wii core back

Game Boy Development - Tips and Tricks (II)

This is the 2nd post on the series Game Boy Development - Tips and Tricks Game Boy Development - Tips and Tricks (I) Game Boy Development - Tips and Tricks (II) Game Boy Development - Tips and Tricks (III)

5. The game loop

1. Skipping vblank wait when we don't need it

2. Frame skipping

3. Keeping the scroll movement smooth

6. Funny things in the world of 8 bits

Game Boy Development - Tips and Tricks (I)

This is the 1st post on the series Game Boy Development - Tips and Tricks Game Boy Development - Tips and Tricks (I) Game Boy Development - Tips and Tricks (II) Game Boy Development - Tips and Tricks (III)

1. Choosing your SDK

2. Getting your environment ready

3. Banks

4. Basic Maths

BitBitJam 3 - Pretty Princess' Castle Escape

Rokoban for Nintendo 3DS

Familiar Game Camp

Whack Mania on Nintendo 3DS

Download: Whack Mania 3DS

3DS Homebrew Tips and Tricks (III)

6. Adding sound permissions to 3ds files

7. Avoid GPU_TRIANGLE_FAN

8. Using RomFS

9. Painting steps: clean, render, transfer and swap

10. Improving the 3D steresocopic effect

3DS Homebrew Tips and Tricks (II)

This is the 2nd post on the series 3DS Homebrew Tips and Tricks 3DS Homebrew Tips and Tricks (I) 3DS Homebrew Tips and Tricks (II) 3DS Homebrew Tips and Tricks (III)

3. Application Icon, banner and RSF

4. Pica Texture Format

5. Sideways framebuffer

3DS Homebrew Tips and Tricks (I)

This is the 1st post on the series 3DS Homebrew Tips and Tricks 3DS Homebrew Tips and Tricks (I) 3DS Homebrew Tips and Tricks (II) 3DS Homebrew Tips and Tricks (III)

1. 3dsx, Cia and 3ds

2. Setting up a good Developement environment

Jumping Jack for 3DS

DOWNLOAD: Jumping Jack 3DS

Familiar Game Jam 4 - Dancing with wolves!

Freakend 2015

Pixels and Coffe 3DS workshop

Familiar Game Jam 3 (one month later, yippiee!)

This is the 3rd post on the series Game Boy Development - Tips and Tricks

Game Boy Development - Tips and Tricks (I)

Game Boy Development - Tips and Tricks (II)
Game Boy Development - Tips and Tricks (III)

This is the 2nd post on the series Game Boy Development - Tips and Tricks
Game Boy Development - Tips and Tricks (I)
Game Boy Development - Tips and Tricks (II)
Game Boy Development - Tips and Tricks (III)

This is the 1st post on the series Game Boy Development - Tips and Tricks
Game Boy Development - Tips and Tricks (I)
Game Boy Development - Tips and Tricks (II)
Game Boy Development - Tips and Tricks (III)

This is the 2nd post on the series 3DS Homebrew Tips and Tricks
3DS Homebrew Tips and Tricks (I)
3DS Homebrew Tips and Tricks (II)
3DS Homebrew Tips and Tricks (III)

This is the 1st post on the series 3DS Homebrew Tips and Tricks

3DS Homebrew Tips and Tricks (I)

3DS Homebrew Tips and Tricks (II)

3DS Homebrew Tips and Tricks (III)