Tag Archives: wireframe

Play your retro console on a modern TV

via Raspberry Pi

Want to connect your retro console to your modern TV? The latest issue of Wireframe magazine has the only guide you need…

“Get a Raspberry Pi. Done.” It’s probably the most frequently recurring comment we get across all videos on the My Life in Gaming YouTube channel, which often revolve around playing classic games on original hardware. Not everyone has held onto their old consoles through the years, so I get it.

 PS1Digital on a 4K OLED TV
PS1Digital on a 4K OLED TV

Software emulation, whether through a PC, Raspberry Pi, or any other device, is easy on your wallet and solid enough to give most people the experience they’re looking for.

But for me, the core of my gaming experience still tends to revolve around the joy I feel in using authentic cartridges and discs. But as you may have noticed, 2021 isn’t 2001, and using pre-HDMI consoles isn’t so easy these days. A standard CRT television is the most direct route to getting a solid experience with vintage consoles.

 Standard RCA cables with composite video. A direct HDTV connection is a poor experience
Standard RCA cables with composite video. A direct HDTV connection is a poor experience

But let’s face it – not everyone is willing to work a CRT into their setup. Plenty of people are content with just plugging the cables that came with their old systems (usually composite) into their HD or 4K TV – and that’s OK! But whether for the blurry looks or the input lag they feel, this simply isn’t good enough for a lot of people.

Down the rabbit hole

“There has to be a better way,” you say as you browse Amazon’s assortment of analogue-to- HDMI converters, HDMI adapters like Wii2HDMI, or HDMI cables for specific consoles by a variety of brands. You might think these are just what you’re looking for, but remember: your TV has its own internal video processor. Just like your TV, they’re going to treat 240p like 480i. Not only is it unnecessary to deinterlace 240p, but doing so actively degrades the experience – motion- adaptive deinterlacing takes time, adding input lag.

RetroTINK-2X MINI (left) and 2X Pro (right). The MINI pairs great with N64
RetroTINK-2X MINI (left) and 2X Pro (right). The MINI pairs great with N64

That Sega Saturn HDMI cable is going to deinterlace your gorgeous 240p sprite-based games so hard that they’ll look like some sort of art restoration disaster in motion. The dark secret of these products is that you’re buying something you already own – a basic video processor designed for video, not video games, and the result will likely not be tangibly better than what your TV could do. The only reason to go this route is if you have no analogue inputs and could not possibly invest more than $30.

So what is the better way? The primary purpose of an external video processor is to send a properly handled signal to your TV that won’t trigger its lag-inducing processes and turn your pixels into sludge – basically any progressive resolution other than 240p. Luckily, there are several devices in various price ranges that are designed to do exactly this.

There is lots more to learn!

This is just a tiny snippet of the mammoth feature in Wireframe magazine issue 49. The main feature includes a ‘jargon cheat sheet’ and ‘cable table’ to make sure any level of user can get their retro console working on a modern TV.

If you’re not a Wireframe magazine subscriber, you can download a PDF copy for free. Head to page 50 to get started.

You can read more features like this one in Wireframe issue 49, available directly from Raspberry Pi Press — we deliver worldwide.

The post Play your retro console on a modern TV appeared first on Raspberry Pi.

How not to code: a guide to concise programming

via Raspberry Pi

Updating a 22-year-old game brought Andrew Gillett face to face with some very poor coding practices. Read more about it in this brilliant guest article from the latest issue of Wireframe magazine.

In 1998, at the age of 17, I was learning how to write games in C. My first attempt, the subtly titled DEATH, was not going well. The game was my take on Hardcore, a 1992 Atari ST game by legendary game developer and sheep enthusiast Jeff Minter, which had been released only as an unfinished five-level demo.

A series of ultrabombs blowing up a snake.

A series of ultrabombs blowing up a snake.

The player controlled four gun turrets on the outside of a square arena, into which enemies teleported. While the original game had been enjoyable and promising, my version wasn’t much fun, and I couldn’t work out why. Making a decent game would also have involved making dozens of levels and many enemy types, which was looking like too big a task, especially as I was finding it hard to understand the intricacies of how the enemies in Hardcore moved.

So I abandoned that game and decided to replicate a different one – 1994’s MasterBlaster, a Bomberman-style game on the Commodore Amiga. MasterBlaster didn’t have a single-player mode or bots, so there was no enemy AI to write. And the level was just a grid with randomly generated walls and power-ups – so there was no real level design involved. With those two hurdles removed, development went fairly smoothly, the biggest challenge being working out some of the subtleties of how character movement worked.

The 2021 version of Partition Sector
The 2021 version of Partition Sector

The game, which I named Partition Sector, was finished in mid-1999 and spent the next 18 years on my website being downloaded by very few people. In late 2018 I decided to do a quick update to the game and release it on Steam. Then I started having ideas, and ended up working on it, on and off, for two years.

One of the biggest hurdles I came across when writing my first games was how to structure the code. I knew how to write a basic game loop, in which you update the positions of objects within the game, then draw the level and the objects within it, and then loop back to the start, ending the loop when the ‘game over’ criteria are met or the player has chosen to quit. But for a full game you need things like a main menu, submenus, going through a particular number of rounds before returning to the main menu, and so on. In the end, I was able to come up with something that worked, but looking back on my old code 20 years on, I could see many cases of absolutely terrible practice.

“I started having ideas, and ended up working on it, on

and off, for two years”

While most of my time was spent adding new features, a lot of time was spent rewriting and restructuring old code. I’m going to share some examples from the original code so you don’t make the same mistakes!

This is just a snippet of Andrew’s brilliant monster-sized tutorial, which you can read in full in the latest issue of Wireframe magazine. No subscription? No problem! You can read the rest of this post in full for free in PDF format.

Wireframe issue 48
You can read more features like this one in Wireframe issue 48, available directly from Raspberry Pi Press — we deliver worldwide.

The post How not to code: a guide to concise programming appeared first on Raspberry Pi.

Swing into action with an homage to Pitfall! | Wireframe #48

via Raspberry Pi

Grab onto ropes and swing across chasms in our Python rendition of an Atari 2600 classic. Mark Vanstone has the code

Whether it was because of the design brilliance of the game itself or because Raiders of the Lost Ark had just hit the box office, Pitfall Harry became a popular character on the Atari 2600 in 1982.

His hazardous attempts to collect treasure struck a chord with eighties gamers, and saw Pitfall!, released by Activision, sell over four million copies. A sequel, Pitfall II: The Lost Caverns quickly followed the next year, and the game was ported to several other systems, even making its way to smartphones and tablets in the 21st century.

Pitfall

Designed by David Crane, Pitfall! was released for the Atari 2600 and published by Activision in 1982

The game itself is a quest to find 32 items of treasure within a 20-minute time limit. There are a variety of hazards for Pitfall Harry to navigate around and over, including rolling logs, animals, and holes in the ground. Some of these holes can be jumped over, but some are too wide and have a convenient rope swinging from a tree to aid our explorer in getting to the other side of the screen. Harry must jump towards the rope as it moves towards him and then hang on as it swings him over the pit, releasing his grip at the other end to land safely back on firm ground.

For this code sample, we’ll concentrate on the rope swinging (and catching) mechanic. Using Pygame Zero, we can get our basic display set up quickly. In this case, we can split the background into three layers: the background, including the back of the pathway and the tree trunks, the treetops, and the front of the pathway. With these layers we can have a rope swinging with its pivot point behind the leaves of the trees, and, if Harry gets a jump wrong, it will look like he falls down the hole in the ground. The order in which we draw these to the screen is background, rope, tree-tops, Harry, and finally the front of the pathway.

Now, let’s get our rope swinging. We can create an Actor and anchor it to the centre and top of its bounding box. If we rotate it by changing the angle property of the Actor, then it will rotate at the top of the Actor rather than the mid-point. We can make the rope swing between -45 degrees and 45 degrees by increments of 1, but if we do this, we get a rather robotic sort of movement. To fix this, we add an ‘easing’ value which we can calculate using a square root to make the rope slow down as it reaches the extremes of the swing.

Our homage to the classic Pitfall! Atari game. Can you add some rolling logs and other hazards?

Our Harry character will need to be able to run backwards and forwards, so we’ll need a few frames of animation. There are several ways of coding this, but for now, we can take the x coordinate and work out which frame to display as the x value changes. If we have four frames of running animation, then we would use the %4 operator and value on the x coordinate to give us animation frames of 0, 1, 2, and 3. We use these frames for running to the right, and if he’s running to the left, we just mirror the images. We can check to see if Harry is on the ground or over the pit, and if he needs to be falling downward, we add to his y coordinate. If he’s jumping (by pressing the SPACE bar), we reduce his y coordinate.

We now need to check if Harry has reached the rope, so after a collision, we check to see if he’s connected with it, and if he has, we mark him as attached and then move him with the end of the rope until the player presses the SPACE bar and he can jump off at the other side. If he’s swung far enough, he should land safely and not fall down the pit. If he falls, then the player can have another go by pressing the SPACE bar to reset Harry back to the start.

That should get Pitfall Harry over one particular obstacle, but the original game had several other challenges to tackle – we’ll leave you to add those for yourselves.

Pitfall Python code

Here’s Mark’s code for a Pitfall!-style platformer. To get it working on your system, you’ll need to  install Pygame Zero.  And to download the full code and assets, head here.

Get your copy of Wireframe issue 48

You can read more features like this one in Wireframe issue 48, available directly from Raspberry Pi Press — we deliver worldwide.
Wireframe issue 48
And if you’d like a handy digital version of the magazine, you can also download issue 48 for free in PDF format.
A banner with the words "Be a Pi Day donor today"

The post Swing into action with an homage to Pitfall! | Wireframe #48 appeared first on Raspberry Pi.

Code a Light Cycle arcade minigame | Wireframe #47

via Raspberry Pi

Speed around an arena, avoiding walls and deadly trails in this Light Cycle minigame. Mark Vanstone has the code.

Battle against AI enemies in the original arcade classic.

At the beginning of the 1980s, Disney made plans for an entirely new kind of animated movie that used cutting-edge computer graphics. The resulting film was 1982’s TRON, and it inevitably sparked one of the earliest tie-in arcade machines.

The game featured several minigames, including one based on the Light Cycle section of the movie, where players speed around an arena on high-tech motorbikes, which leave a deadly trail of light in their wake. If competitors hit any walls or cross the path of any trails, then it’s game over.

Players progress through the twelve levels which were all named after programming languages. In the Light Cycle game, the players compete against AI players who drive yellow Light Cycles around the arena. As the levels progress, more AI Players are added.

The TRON game, distributed by Bally Midway, was well-received in arcades, and even won Electronic Games Magazine’s (presumably) coveted Coin-operated Game of the Year gong.

Although the arcade game wasn’t ported to home computers at the time, several similar games – and outright clones – emerged, such as the unsubtly named Light Cycle for the BBC Micro, Oric, and ZX Spectrum.

The Light Cycle minigame is essentially a variation on Snake, with the player leaving a trail behind them as they move around the screen. There are various ways to code this with Pygame Zero.

In this sample, we’ll focus on the movement of the player Light Cycle and creating the trails that are left behind as it moves around the screen. We could use line drawing functions for the trail behind the bike, or go for a system like Snake, where blocks are added to the trail as the player moves.

In this example, though, we’re going to use a two-dimensional list as a matrix of positions on the screen. This means that wherever the player moves on the screen, we can set the position as visited or check to see if it’s been visited before and, if so, trigger an end-game event.

Our homage to the TRON Light Cycle classic arcade game.

For the main draw() function, we first blit our background image which is the cross-hatched arena, then we iterate through our two-dimensional list of screen positions (each 10 pixels square) displaying a square anywhere the Cycle has been. The Cycle is then drawn and we can add a display of the score.

The update() function contains code to move the Cycle and check for collisions. We use a list of directions in degrees to control the angle the player is pointing, and another list of x and y increments for each direction. Each update we add x and y coordinates to the Cycle actor to move it in the direction that it’s pointing multiplied by our speed variable.

We have an on_key_down() function defined to handle changing the direction of the Cycle actor with the arrow keys. We need to wait a while before checking for collisions on the current position, as the Cycle won’t have moved away for several updates, so each screen position in the matrix is actually a counter of how many updates it’s been there for.

We can then test to see if 15 updates have happened before testing the square for collisions, which gives our Cycle enough time to clear the area. If we do detect a collision, then we can start the game-end sequence.

We set the gamestate variable to 1, which then means the update() function uses that variable as a counter to run through the frames of animation for the Cycle’s explosion. Once it reaches the end of the sequence, the game stops.

We have a key press defined (the SPACE bar) in the on_key_down() function to call our init() function, which will not only set up variables when the game starts but sets things back to their starting state.

Here’s Mark’s code for a TRON-style Light Cycle minigame. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.

So that’s the fundamentals of the player Light Cycle movement and collision checking. To make it more like the original arcade game, why not try experimenting with the code and adding a few computer-controlled rivals?

Get your copy of Wireframe issue 47

You can read more features like this one in Wireframe issue 47, available directly from Raspberry Pi Press — we deliver worldwide.

And if you’d like a handy digital version of the magazine, you can also download issue 47 for free in PDF format.

The post Code a Light Cycle arcade minigame | Wireframe #47 appeared first on Raspberry Pi.

Code your own Pipe Mania puzzler | Wireframe #46

via Raspberry Pi

Create a network of pipes before the water starts to flow in our re-creation of a classic puzzler. Jordi Santonja shows you how.

A screen grab of the game in motion
Pipe Mania’s design is so effective, it’s appeared in various guises elsewhere – even as a minigame in BioShock.

Pipe Mania, also called Pipe Dream in the US, is a puzzle game developed by The Assembly Line in 1989 for Amiga, Atari ST, and PC, and later ported to other platforms, including arcades. The player must place randomly generated sections of pipe onto a grid. When a counter reaches zero, water starts to flow and must reach the longest possible distance through the connected pipes.

Let’s look at how to recreate Pipe Dream in Python and Pygame Zero. The variable start is decremented at each frame. It begins with a value of 60*30, so it reaches zero after 30 seconds if our monitor runs at 60 frames per second. In that time, the player can place tiles on the grid to build a path. Every time the user clicks on the grid, the last tile from nextTiles is placed on the play area and a new random tile appears at the top of the next tiles. randint(2,8) computes a random value between 2 and 8.

Our Pipe Mania homage. Build a pipeline before the water escapes, and see if you can beat your own score.

grid and nextTiles are lists of tile values, from 0 to 8, and are copied to the screen in the draw function with the screen.blit operation. grid is a two-dimensional list, with sizes gridWidth=10 and gridHeight=7. Every pipe piece is placed in grid with a mouse click. This is managed with the Pygame functions on_mouse_move and on_mouse_down, where the variable pos contains the mouse position in the window. panelPosition defines the position of the top-left corner of the grid in the window. To get the grid cell, panelPosition is subtracted from pos, and the result is divided by tileSize with the integer division //. tileMouse stores the resulting cell element, but it is set to (-1,-1) when the mouse lies outside the grid.

The images folder contains the PNGs with the tile images, two for every tile: the graphical image and the path image. The tiles list contains the name of every tile, and adding to it _block or _path obtains the name of the file. The values stored in nextTiles and grid are the indexes of the elements in tiles.

wfmag46code
Here’s Jordi’s code for a Pipemania-style puzzler. To get it working on your system, you’ll need to install Pygame Zero. And to download the full code and assets, head here.

The image waterPath isn’t shown to the user, but it stores the paths that the water is going to follow. The first point of the water path is located in the starting tile, and it’s stored in currentPoint. update calls the function CheckNextPointDeleteCurrent, when the water starts flowing. That function finds the next point in the water path, erases it, and adds a new point to the waterFlow list. waterFlow is shown to the user in the draw function.

pointsToCheck contains a list of relative positions, offsets, that define a step of two pixels from currentPoint in every direction to find the next point. Why two pixels? To be able to define the ‘cross’ tile, where two lines cross each other. In a ‘cross’ tile the water flow must follow a straight line, and this is how the only points found are the next points in the same direction. When no next point is found, the game ends and the score is shown: the number of points in the water path, playState is set to 0, and no more updates are done.

Get your copy of Wireframe issue 46

You can read more features like this one in Wireframe issue 46, available directly from Raspberry Pi Press — we deliver worldwide.

wfcover

And if you’d like a handy digital version of the magazine, you can also download issue 46 for free in PDF format.

The post Code your own Pipe Mania puzzler | Wireframe #46 appeared first on Raspberry Pi.

Make your own virtual reality 3D Shooter

via Raspberry Pi

In the latest issue of Wireframe magazine, Mark Vanstone shows you how to turn a 3D shooter into a VR game for a variety of viewers, from Google Cardboard to gaming headsets.

Our shooter, now in VR format. Blast aliens from the sky as they fly over the mountains.

Browser development has really matured of late, with a number
of exciting new features coming to the fore. Where WebGL was well supported, the new WebXR (previously WebVR) is now becoming standard
in modern browsers. JavaScript ES5 has now been superseded by ES6, and with these new technologies, making browser-based apps – and specifically 3D games – is now a serious proposition. The other part of VR technology, the hardware, has also evolved – as mobile tech has become more powerful, so have the opportunities for cost-effective VR experiences.

With a mobile phone you can create a stereoscopic display for use with a simple Cardboard viewer.

If you have an old mobile phone, perhaps an Make your own virtual reality 3D Shooter B iPhone 6 or a Samsung S7, you can get a Google Cardboard headset for £6 and turn it into a rudimentary VR viewer. In this article, we’ll show you how to set up a 3D shooter to run not only on that hardware, but also on other viewers such as the Gear VR or Daydream, and even gaming headsets such as the Oculus, HTC, or Valve. All of these have web browsers built in which can support WebXR or a 3D display, and although there are some differences between how they work, the process of displaying a 3D scene is mostly the same on all of them, so we can use the Three.js JavaScript library.

Three different VR headsets on a white background
There’s a wide range of VR viewers and headsets on the market, from Google Cardboard to pricey gaming headsets like the Oculus, HTC, HP, Microsoft, and Valve ranges.

To begin, we’ll start with the Three.js 3D shooter we made in Wireframe #32 – if you missed it, you can download a copy. We’ll use the same models and much of the same code. The first change, though, is to update the code to run as an ES6 module. The non-module version of Three.js is being phased out at the end of 2020, so it’s probably best to get with the times and use the new stuff. As with our earlier shooter, you’ll need to run this code from a secure web server, which, for mobile phones and gaming headsets, will mean uploading it to somewhere suitable, but if you want to see it running, you can play it at technovisual.co.uk/vr.

Basic VR viewers

Now we need to consider the hardware we’re going to use to run our game. Let’s start at our baseline, Google Cardboard, and work up from there. Available from many outlets online (including Google’s store), it’s a cut-out kit, which you fold up to create a viewer.


From a browser window inside a gaming headset environment, you can launch a Three.js VR experience

There are two lenses to look through, two magnets in a recess on the side, and velcro tabs to hold a mobile phone. The magnets on the side serve as a selection mechanism which we’ll explore later.

Next, we have Gear VR-style viewers. There are many different types, priced from around £12 to £40, and these are essentially a better-built plastic version of the Cardboard but with a button on top to act as a selector. Phones of varying sizes can be used, and as long as the device isn’t more than about four years old, it should be up-to-date enough to run the 3D software.

For example, the six-year-old Samsung S5 is capable of displaying VR, but it’s a bit too slow to make the experience pleasant, whereas a five-year-old iPhone 6 is quite capable of displaying simple VR scenes smoothly. (With
iPhones, you may need to switch on Experimental Features in the Safari settings, however.)

Proper pro kit

Gaming headsets are a bit different, since they have a built-in screen in the headset, and – in the case of the Oculus Go and Quest – an Android computer in there as well. Tethered headsets use the power of a connected computer to generate the display, and all of them use a slightly different
Three.js system from the cheaper viewers to generate the 3D display.

As time goes on, it’s likely that more mobile phones will be compatible with
the VR software used by the untethered gaming headsets. Gaming headsets also have sensors that track your movement as well as the tilt of the headset, providing six degrees of freedom.

Get the rest of the tutorial in Wireframe #44

This is just a taste of the comprehensive guide included in the latest issue of Wireframe magazine. If you’re not a subscriber, you can download a PDF copy for free from the Wireframe magazine website. Start at page 50 and work your way through to create your own VR shooter game.

And if you want to take advantage of Wireframe magazine’s latest subscription deal, you can get it for just £10 at the official Raspberry Pi Press online store.

The post Make your own virtual reality 3D Shooter appeared first on Raspberry Pi.