The entire source code for the project is freely available, but Marcolina highlights the physics portion for us here:
: If R
: !If I-1
The subroutine GO converts normal space coordinates to “Portal Space” for the entrance portal, while RO does the opposite for the exiting portal. When the player is only partially through the portal, the code draws a “shadow object” on the exiting side, but the player’s position is only moved once they’re entirely through.
Subroutine M represents the fun part: the satisfying launches through the air players can achieve by dropping through portals from high up on a ledge. M dictates how the game redirects the player’s velocity when going through the exit portal based on how fast they were going when entered the other side, but translated to the direction of the new portal.
Marcolina told Ars the code governing the portal gun and placement of portals was more complex than the bit controlling how the player moves. As in the original Portal, portals can’t be placed anywhere, but instead must be “bumped” from the location they’re shot to fit with the geometry of the level. “There needs to be a good amount of code in place to make sure the portals don’t get bumped into invalid locations, or even outside the level,” Marcolina said.
An implementation of the TI-83 version of the Portal physics engine from when Marcolina first began developing the game.
Marcolina also had to attempt to replicate the characteristic Portal level design, but under severe memory constraints (graphing calculators are barely modern devices any more, having only just recently gotten color screens). Apps in a graphing calculator are limited to executing 16 kilobytes of code, a severe constraint given the amount of animation involved, Marcolina said.
Overall, he favored levels that are more mentally challenging, like the earlier levels of the original Portal, rather than the later levels that require good timing and hand-eye coordination. “Levels that require extreme dexterity to solve wouldn’t work very well due to the less than optimal control,” Marcolina said.
While programming for graphing calculators admittedly doesn’t give Marcolina’s work a wide reach, he points out that the constraints of the platform teach him to be a better coder. “Oftentimes on computers, when you are first learning to code, going the lazy way has little effect on the end result because computers are so fast anyway that you can't tell the difference,” he said. “But on a calculator you have to work very hard to make sure you make every last instruction of your code be as useful as possible.”