#raspberry pi the web sprite

[izztreme-art-n-stuff]

Now it's time for the final final version of Cooking Gamma

I'm not going to rewrite it anymore because I need to move on with this series. A mid episode is a mid episode and I'll stick by it

Anyways, here you go:

[renpytom]

Ren’Py 7.4.2 Released

I'm happy to announce Ren'Py 7.4.2, the second patch release for the 7.4 series. This release fixes a number of issues found in Ren'Py 7.4, including some that only affect users that need accessibility options. Everyone should upgrade.

Ren'Py 7.4 is the the product of over a year of development, and one of the biggest releases of Ren'Py to date. This series of releases focuses on updating Ren'Py's internals so that Ren'Py is ready for its next 15 years.

Some of the bigger changes are:

A new model-based renderer. While this is opt-in for the moment, it opens the way to features that creators have been requesting for a long time, such as being able to recolor displayables, blurring the screen, and using Live2D to animate sprites. The model-based renderer is extensible with shaders, allowing for custom effects.

A new Python 3 compatibility mode has been added, to pave the way for Python 3 support in the next release. This mode changes the ways in which Ren'Py runs, to allow you to begin porting your game before full Python 3 comes out in Ren'Py 8.0.

Ren'Py's build system has been modernized, and the libraries underlying it have been updated. This allows 64-bit Windows to be supported.

The web platform has been updated, to allow for the incremental download of games.

This release also raises the minimum requirements to run a Ren'Py game. It is now required that a user's computer have OpenGL 2, DirectX 9, OpenGL ES 2, or WebGL to run Ren'Py. The model-based renderer requires OpenGL ES 3 or WebGL 2.

With these changes, there have been a few deprecations. Ren'Py no longer runs on Windows XP. The minimum version of macOS Ren'Py uspports is now 10.10. The 32-bit armv7l platform has been removed on iOS, as this platform hasn't been supported by Apple for several years. The Editra text editor has been removed, as it hasn't been supported for quite some time, and wasn't compatible with the new build system.

It's my hope that this release will enable creators to take on projects they couldn't before, and will provide a solid basis for the next releases of Ren'Py.

Downloads of 7.4.2 can be found at:

https://www.renpy.org/release/7.4.2

A full list of changes to Ren'Py can be found at:

https://www.renpy.org/doc/html/changelog.html

A list of changes that may require you to update your game can be found at:

https://www.renpy.org/doc/html/incompatible.html

Please also check out the credits and sponsor list.

This release is 7.4.2.1291.

The biggest fix, and the reason I recommend everyone upgrade, is that the say.vbs file (used for accessibility on windows) and some of the ANGLE files were missing from the Windows build.

In addition to that, some of the changes are:

* A new way of scanning for Java on macOS, which doesn't get confused by the Java browser plug-in.

* A fix to the scale_fast field being missing on the software renderer, which means errors in rendering would lead to a crash. (The missing ANGLE files made this more common.)

* Ren'Py no longer disables screensavers and power save. (It's possible to change this default.)

* A new build.include_i686 field, that determines if the 32-bit x86 binaries are included.

* A fix for a problem intersecting polygons.

* New config.context_fadeout_music and config.context_fadein_music variables, that determine music fadeins and fadeouts on context changes like loading.

* Better scanning for expressions in Live2D.

* A pair of focus fixes.

* A fix to webp support on the Raspberry Pi.

Thanks to everyone who worked with me on this release.

[blubberquark]

Python 3 and PyGame in 2018

Table of Contents

1. Why PyGame?

2. Why Not?

3. Explicit Is Better Than Implicit

4. Three Pain Points

5. Other Cool Libraries

6. More To Come

1 Why PyGame?

PyGame is a nice library for getting started with game development. It is a good way to learn programming in a "real programming language" while making games1. There is very "magic" going on in PyGame, and you can go from print("Hello World") to drawing a triangle on the screen and then to Pong or Tetris with a smooth learning curve.

PyGame is also an easy way to get your feet wet in game development if you know and use Python already, for example in machine learning or web development. That's how I came to learn PyGame.

2 Why Not?

PyGame is just a low-level library for creating windows, drawing on the screen, reading joystick input, and playing sounds. OpenFL, Löve2D, FNA and LibGDX fill similar niches in the Haxe, Lua, .Net and Java ecosystems, respectively. If you want a full-featured engine, use Unity3D, UE4, or Godot. If you don't want to learn to code, you will probably fare better with GameMaker or Stencyl2. If you want to tell an interactive story with little actual gameplay, maybe Twine or Ren'Py are more your thing.

3 Explicit Is Better Than Implicit

Maybe PyGame is not for everybody… However, if you do just want to make small 2D games, and don't want to rely on automagic functionality, PyGame could for you. That means you have to code your own game loop3, poll the keyboard or game pad, and update the screen yourself.

Your game loop will look something like this:

import pygame pygame.init() # ... # setup stuff here screen=pygame.display.set_mode(screen_size) clock=pygame.clock.Clock() running=True while running: clock.tick(30) events = pygame.event.get() keys = pygame.key.get_pressed() for e in events: if e.type==pygame.QUIT: running=False elif e.type==pygame.KEYDOWN and #... # handle jumping etcetera # ... # move sprites around, collision detection, etc # ... # draw pygame.display.update() pygame.quit()

The ease of just drawing pixels on the screen and the lack of hidden features sometimes makes it harder to get started making certain games genres. If you start from scratch in Unity3D, you already have a level and a camera and you can just create a sphere GameObject and check a box to enable the physics engine. If you draw a circle on the screen in PyGame, it's just pixels on the screen. These pixels don't know anything about cameras, raycasting, or physics, so if you want to move the view around, make your circle clickable, or have it bounce off walls, you have to connect the systems yourself. PyGame gives you tools to check for collisions, a Sprite class that is the closest equivalent to GameObject, and a way to find out where on the window the mouse was clicked.

If you want to use a pre-made physics engine like Box2D, or roll your own, you have to write some glue code, but PyGame will stay out of your way.

This can even be a tremendous advantage when you want to make a game like Tetris4, or like SimCity, where you don't want to use 3D collision detection and a physics engine anyway, and collision detection happens on a grid. A game like Braid, where you can rewind the entire game state, will also be much easier if you have full control over your game loop. You can do all these things in a big and opinionated engine, as Hearthstone (a card game made in Unity3D) has showed us, but if don't need these features, you sometimes have to code around them. If you code around features you don't need, or re-build your own systems on top of a commercial engine, you might end up writing more code than if you had just started from scratch5.

All of this goes double for tools like PuzzleScript, RPG Maker, GameMaker, Bitsy or Twine. These are all geared towards certain kinds of games, and while they make it really easy to make that kind of game, they make you jump through hoops if you want to build anything else.

4 Three Pain Points

Although I just told you that PyGame is a great library, it is not as popular among game developers as it should be. This is mostly due to three problems dating back to the Python 3 days: multi-threading, deployment, and HD screen resolutions.

Multi-threading: Due to the GIL, an unfortunate implementation detail in CPython6, you can't have two threads execute Python code at the same time. That means your multi-threaded Python programs will still run in parallel, but there will only ever be one thread running at any time. On a single-core machine, there is not that much to worry about, because you only have one core that can run code anyway, but on a multi-core machine, you can't really take advantage of the additional cores. Still, what you could do is have one thread handle input and draw to the screen, while another, long-running thread does complicated enemy AI calculations that take longer than one frame to complete. That won't make your code run any faster in aggregate, but it will can at least ensure that the tick-input-update-draw cycle of the game loop runs at a smooth frame rate while the AI takes a lot of time.

If you're using i/o operations from the Python standard library, long-running numpy code or clock.tick(FPS) in PyGame, these libraries do the right thing and tell the Python interpreter that they are entering a section of native code during which Python code can safely run in another thread. But in general, you could have a Python function that calls native code that doesn't return for a while, so the Python interpreter is executing the same line of Python and other threads can't run. If that bit of native code is waiting for input, your whole program will freeze until the input arrives, even if you have ten other threads waiting that could do useful things in the mean time.

There are two modules to help you with concurrency in Python 3: multiprocessing and asyncio. The first has been around since Python 2.6, and lets you execute Python code in another process. This is useful if you have long-running computations like enemy AI that you want to run on another core. The other, asyncio is new in Python 3.37. With asyncio, you can run multiple coroutines in the same thread. A scheduling object called an event loop will execute coroutines piecemeal whenever there is input available. Because asynchronous coroutines are basically Python functions with some extra syntactic sugar, you can have tens of thousands of them running at the same time, unlike processes or kernel threads, which need a comparatively large amount of RAM to create and some time to context-switch. The use case for asyncio is pretty much the opposite of the use case of multiprocessing: Lots of threads8 waiting for i/o instead of long-lived processes that crunch numbers.

Deployment: There used to be no simple and easy way to package Python 2 games for end users. Sure, you could ask them to install python, either from Python.org or from the package manager of their choice, and give them the source code. Or you could use py2exe or py2app and create portable versions of a python script, but you couldn't build Windows, Mac and Linux executables from the same configuration file, and only on the respective platform. There were multiple competing standards for packaging python modules as source distributions: distutils, setuptools, distribute, and distutils2.

In the mean time, a smart person invented cxfreeze, which would automatically package every single dependency, every resource file and library used by your program, into one big archive. Unfortunately, that approach tended to pull in a bunch of DLLs that are already present on most end users machines. You also need to have the script already running on the target platform to analyse the dependencies at runtime.

With Python 3, setuptools has won, and the others have been merged into it9. There is a new file format for packaging Python modules called wheels10, that lets users install modules with native code without a C compiler. PyInstaller11 lets you build self-contained, portable versions of scripts on Windows, Mac or Linux based on the specification, and pynsist12 lets you create a windows installer for a Python script from any platform, because it downloads windows-compatible wheels and includes them without setting up a cross-compiling environment. The Panda3D project is even working on a cross-platform binary packaging system for Python 3 games based on setuptools!

HD screens: The software-based rendering in PyGame gets slower proportionally to the number of pixels. If you draw a 16x16 character sprite onto the screen, that makes 256 pixels. If you blit a background picture into a 640x480 (VGA) window, that's 307200 pixels already. If you scale that window up to 1280x960, that's four times as many pixels, and 1080p full-HD resolution has 6.75 times as many pixels as VGA. Things that were quite fast at low resolutions become a real bottleneck on HD screens, and you really feel the burn when you run PyGame on devices with a slower CPU and a HD screen, like a phone or a Raspberry PI.

Even if you run your game logic at a low resolution, and just scale up the screen to HD with pygame.transform.scale in the final step, that still means moving lots of pixels around in software. Scaling your game up to full-screen on a HD display can easily take the majority of your processing time. And remember, we effectively have only one core!

If you could copy your 320x240 surface into a texture and scale up your pixel art with the GPU, you eliminate a major bottleneck. The GPU is surprisingly fast and energy-efficient in phones, tablets and on the raspberryPI.

Fortunately, instead of directly drawing pixels into your window, PyGame can give you an OpenGL context and let you use whatever OpenGL bindings you like. In the past, that would have been with PyOpenGL, or pyglet. With Python 3, we can use ModernGL. ModernGL is much simpler than the other two. It targets only modern versions of OpenGL. Unlike PyOpenGL and pyglet, there is no support for immediate mode or the old fixed-function pipeline. You have to use vertex buffer objects and custom shaders. It's fast, and it lets you do fancy post-processing effects in addition to scaling.

If you need more performance, or fancier effects, you can incrementally transition from drawing into PyGame Surfaces towards creating individual textures for your Sprites and rendering directly with OpenGL.

5 Other Cool Libraries

The missing level editor: Tiled13 is a great level editor. You can use PyTMX14 to read the maps files, and pyscroll15 to render them.

Discord Rich Presence: All the cool kids are on Discord16. With pypresence17, you can let your player's friends know what the game is called, which level they are on, and how many points they have scored. It definitely beats having "now playing Python3.exe" as your Discord status line.

Creating Videos: moviePy18 gives you a simple API to create, load and edit GIFs, WEBM and other video file formats.

6 More To Come

The problems I used to have in PyGame haven't disappeared, but in 2018 and with Python 3.6, they have become solvable. It is possible to started making games with PyGame, and to polish and deploy them on Steam and itch.io. There used to be a tool to deploy PyGame to Android phones and tablets, but that was based on Python 2.7 and some hacks to get everything to run. With the current effort to port PyGame to SDL2, we can soon deploy games written in PyGame to Windows, Mac, Linux, Android and all major consoles, which support SDL219

This post is longer than I thought already, so I'll take a break here. In the coming days I will write more about using the asyncio module to do i/o in PyGame without tanking your frame rate, using the moderngl module to scale up your pixel art, and trying out deploy-NG, a setuptools extension from Panda3D to distribute games to end users.

Footnotes:

1

I recommend Al Sweigart's tutorials at http://inventwithpython.com/, and http://inventwithpython.com/pygame/

2

Maybe you want to start designing games first instead of learning to program, so you start out with these tools, but I would recommend you learn at least a little bit of a real programming language as well, to get some perspective. If you learn C#, which is a real programming language, together with Unity or Godot, please look up which features are part of C# and which are unique to your engine.

3

To avoid common pitfalls with game loops, read these: http://www.koonsolo.com/news/dewitters-gameloop/ and https://gafferongames.com/post/fix_your_timestep/

4

I am speaking from experience here. We made a Tetris-like game in Unity, and it was not worth the trouble. You can see the result here, but it's nothing special: https://blubberquark.itch.io/tetrominions

5

Please don't write an engine from scratch! People like Jon Blow, Tommy Refenes, John Carmack, David Pittman or Notch wrote their own 3D engines for various reasons. That said, if you actually need a big 3D game engine for your game, please don't write your own on top of PyGame. You are not John Carmack (unless you are, in which case you should stop reading this because you know more about programming than I do). Use Panda3D or Godot if you want something that is open source and Python-based (Godot Python support is still in beta, but getting there). Or use one of the commercial engines listed above.

6

I'm simplifying massively here. Look up the Global Intepreter Lock if you want to know more. The GIL also allows PyGame to call SDL functions without worrying too much about whether SDL is thread-safe. It's not all bad.

7

Only with Python 3.5 it has become really usable, though, and they are still working out the kinks in the API.

8

I mean that as in lightweight threads, Erlang threads, green threads.

9

You can still find distutils in Python 3 for backward compatibility reasons.

10

http://pythonwheels.org

11

http://www.pyinstaller.org/

12

https://pynsist.readthedocs.io/en/latest/

13

https://www.mapeditor.org/

14

https://github.com/bitcraft/PyTMX

15

https://github.com/bitcraft/pyscroll

16

It manages to combine the good parts of Skype, Slack, and TeamSpeak, but it's not open source. https://discordapp.com/

17

https://github.com/qwertyquerty/pypresence

18

https://zulko.github.io/moviepy/

19

SDL2 already runs on the Nintendo Switch, for example. Unfortunately, the licensing terms of the Switch developer kit prohibit you from publicly sharing code that targets the Switch API in public. You have to contact Ryan Gordon and ask him for access, after signing the NDA. I am not a lawyer, this is not legal advice, but as far as I understand it, although the licensing terms of PyGame and SDL allow you to share the code, Nintendo could still sue you for breach of contract. That problem is not unique to PyGame though. A similar workaround exists in the Haxe world, where you have to contact Lars Doucet to get access to a version of OpenFL for Switch. There is also a homebrew version of Python available at https://github.com/nx-python/PyNX, but the NDA might prohibit you from using homebrew and reverse engineering.

[philipholt]

The PICO-8 Virtual Fantasy Console is an idealized constrained modern day game maker

I love everything about PICO-8. It's a fantasy gaming console that wants you - and the kids in your life and everyone you know - to make games!

How cool is that?

You know the game Celeste? It's available on every platform, has one every award and is generally considered a modern-day classic. Well the first version was made on PICO-8 in 4 days as a hackathon project and you can play it here online. Here's the link when they launched in 4 years ago on the forums. They pushed the limits, as they call out "We used pretty much all our resources for this. 8186/8192 code, the entire spritemap, the entire map, and 63/64 sounds." How far could one go? Wolf3D even?

"A fantasy console is like a regular console, but without the inconvenience of actual hardware. PICO-8 has everything else that makes a console a console: machine specifications and display format, development tools, design culture, distribution platform, community and playership. It is similar to a retro game emulator, but for a machine that never existed. PICO-8's specifications and ecosystem are instead designed from scratch to produce something that has it's own identity and feels real. Instead of physical cartridges, programs made for PICO-8 are distributed on .png images that look like cartridges, complete with labels and a fixed 32k data capacity."

What a great start and great proof that you can make an amazing game in a small space. If you loved GameBoys and have fond memories of GBA and other small games, you'll love PICO-8.

How to play PICO-8 cartridges

If you just want to explore, you can go to https://www.lexaloffle.com and just play in your browser! PICO-8 is a "fantasy console" that doesn't exist physically (unless you build one, more on that later). If you want to develop cartridges and play locally, you can buy the whole system (any platform) for $14.99, which I have.

If you have Windows and Chrome or New Edge you can just plug in your Xbox Controller with a micro-USB cable and visit https://www.lexaloffle.com/pico-8.php and start playing now! It's amazing - yes I know how it works but it's still amazing - to me to be able to play a game in a web browser using a game controller. I guess I'm easily impressed.

It wasn't very clear to me how to load and play any cartridge LOCALLY. For example, I can play Demon Castle here on the Forums but how do I play it locally and later, offline?

The easy way is to run PICO-8 and hit ESC to get their command line. Then I type LOAD #cartid where #cartid is literally the id of the cartridge on the forums. In the case of Demon Castle it's #demon_castle-0 so I can just LOAD #demon_castle-0 followed by RUN.

Alternatively - and this is just lovely - if I see the PNG pic of the cartridge on a web page, I can just save that PNG locally and save it in C:\Users\scott\AppData\Roaming\pico-8\carts then run it with LOAD demon_castle-0 (or I can include the full filename with extensions). THAT PNG ABOVE IS THE ACTUAL GAME AS WELL. What a clever thing - a true virtual cartridge.

One of the many genius parts of the PICO-8 is that the "Cartridges" are actually PNG pictures of cartridges. Drink that in for a second. They save a screenshot of the game while the cart is running, then they hide the actual code in a steganographic process - they are hiding the code in two of the bits of the color channels! Since the cart pics are 160*205 there's enough room for 32k.

A p8 file is source code and a p8.png is the compiled cart!

How to make PICO-8 games

The PICO-8 software includes everything you need - consciously constrained - to make AND play games. You hit ESC to move between the game and the game designer. It includes a sprite and music editor as well.

From their site, the specifications are TIGHT on purpose because constraints are fun. When I write for the PalmPilot back in the 90s I had just 4k of heap and it was the most fun I've had in years.

Display - 128x128 16 colours

Cartridge Size - 32k

Sound - 4 channel chip blerps

Code - Lua

Sprites - 256 8x8 sprites

Map - 128x32 cels

"The harsh limitations of PICO-8 are carefully chosen to be fun to work with, to encourage small but expressive designs, and to give cartridges made with PICO-8 their own particular look and feel."

The code you will use is LUA. Here's some demo code of a Hello World that animates 11 sprites and includes two lines of text

t = 0 music(0) -- play music from pattern 0 function _draw() cls() for i=1,11 do -- for each letter for j=0,7 do -- for each rainbow trail part t1 = t + i*4 - j*2 -- adjusted time y = 45-j + cos(t1/50)*5 -- vertical position pal(7, 14-j) -- remap colour from white spr(16+i, 8+i*8, y) -- draw letter sprite end end print("this is pico-8", 37, 70, 14) print("nice to meet you", 34, 80, 12) spr(1, 64-4, 90) -- draw heart sprite t += 1 end

That's just a simple example, there's a huge forum with thousands of games and lots of folks happy to help you in this new world of game creation with the PICO-8. Here's a wonderful PICO-8 Cheat Sheet to print out with a list of functions and concepts. Maybe set it as your wallpaper while developing? There's a detailed User Manual and a 72 page PICO-8 Zine PDF which is really impressive!

And finally, be sure to bookmark this GitHub hosted amazing curated list of PICO-8 resources! https://github.com/pico-8/awesome-PICO-8

  Writing PICO-8 Code in another Editor

There is a 3 year old PICO-8 extension for Visual Studio Code that is a decent start, although it's created assuming a Mac, so if you are a Windows user, you will need to change the Keyboard Shortcuts to something like "Ctrl-Shift-Alt-R" to run cartridges. There's no debugger that I'm seeing. In an ideal world we'd use launch.json and have a registered PICO-8 type and that would make launching after changing code a lot clearer.

There is a more recent "pico8vscodeditor" extension by Steve Robbins that includes snippets for loops and some snippets for the Pico-8 API. I recommend this newer fleshed out extension - kudos Steve! Be sure to include the full path to your PICO-8 executable, and note that the hotkey to run is a chord, starting with "Ctrl-8" then "R."

Editing code directly in the PICO-8 application is totally possible and you can truly develop an entire cart in there, but if you do, you're a better person than I. Here's a directory listing in VSCode on the left and PICO-8 on the right.

And some code.

You can expert to HTML5 as well as binaries for Windows, Mac, and Linux. It's a full game maker! There are also other game systems out there like PicoLove that take PICO-8 in different directions and those are worth knowing about as well.

What about a physical PICO-8 Console

A number of folks have talked about the ultimate portable handheld PICO-8 device. I have done a lot of spelunking and as of this writing it doesn't exist.

You could get a Raspberry Pi Zero and put this Waveshare LCD hat on top. The screen is perfect. But the joystick and buttons...just aren't. There's also no sound by default. But $14 is a good start.

The Tiny GamePi15, also from Waveshare could be good with decent buttons but it has a 240x240 screen.

The full sized Game Hat looks promising and has a large 480x320 screen so you could play PICO-8 at a scaled 256x256.

The RetroStone is also close but you're truly on your own, compiling drivers yourself (twitter thread) from what I can gather

The ClockworkPI GameShell is SOOOO close but the screen is 320x240 which makes 128x128 an awkward scaled mess with aliasing, and the screen the Clockwork folks chose doesn't have a true grid if pixels. Their pixels are staggered. Hopefully they'll offer an alternative module one day, then this would truly be the perfect device. There are clear instructions on how to get going.

The PocketCHIP has a great screen but a nightmare input keyboard.

For now, any PC, Laptop, or Rasberry Pi with a proper setup will do just fine for you to explore the PICO-8 and the world of fantasy consoles!

Sponsor: OzCode is a magical debugging extension for C#/.NET devs working in Visual Studio. Get to the root cause of your bugs faster with heads-up display, advanced search inside objects, LINQ query debugging, side-by-side object comparisons & more. Try for free!

© 2019 Scott Hanselman. All rights reserved.

      The PICO-8 Virtual Fantasy Console is an idealized constrained modern day game maker published first on http://7elementswd.tumblr.com/

[suzanneshannon]

The PICO-8 Virtual Fantasy Console is an idealized constrained modern day game maker

I love everything about PICO-8. It's a fantasy gaming console that wants you - and the kids in your life and everyone you know - to make games!

How cool is that?

You know the game Celeste? It's available on every platform, has one every award and is generally considered a modern-day classic. Well the first version was made on PICO-8 in 4 days as a hackathon project and you can play it here online. Here's the link when they launched in 4 years ago on the forums. They pushed the limits, as they call out "We used pretty much all our resources for this. 8186/8192 code, the entire spritemap, the entire map, and 63/64 sounds." How far could one go? Wolf3D even?

"A fantasy console is like a regular console, but without the inconvenience of actual hardware. PICO-8 has everything else that makes a console a console: machine specifications and display format, development tools, design culture, distribution platform, community and playership. It is similar to a retro game emulator, but for a machine that never existed. PICO-8's specifications and ecosystem are instead designed from scratch to produce something that has it's own identity and feels real. Instead of physical cartridges, programs made for PICO-8 are distributed on .png images that look like cartridges, complete with labels and a fixed 32k data capacity."

What a great start and great proof that you can make an amazing game in a small space. If you loved GameBoys and have fond memories of GBA and other small games, you'll love PICO-8.

How to play PICO-8 cartridges

If you just want to explore, you can go to https://www.lexaloffle.com and just play in your browser! PICO-8 is a "fantasy console" that doesn't exist physically (unless you build one, more on that later). If you want to develop cartridges and play locally, you can buy the whole system (any platform) for $14.99, which I have.

If you have Windows and Chrome or New Edge you can just plug in your Xbox Controller with a micro-USB cable and visit https://www.lexaloffle.com/pico-8.php and start playing now! It's amazing - yes I know how it works but it's still amazing - to me to be able to play a game in a web browser using a game controller. I guess I'm easily impressed.

It wasn't very clear to me how to load and play any cartridge LOCALLY. For example, I can play Demon Castle here on the Forums but how do I play it locally and later, offline?

The easy way is to run PICO-8 and hit ESC to get their command line. Then I type LOAD #cartid where #cartid is literally the id of the cartridge on the forums. In the case of Demon Castle it's #demon_castle-0 so I can just LOAD #demon_castle-0 followed by RUN.

Alternatively - and this is just lovely - if I see the PNG pic of the cartridge on a web page, I can just save that PNG locally and save it in C:\Users\scott\AppData\Roaming\pico-8\carts then run it with LOAD demon_castle-0 (or I can include the full filename with extensions). THAT PNG ABOVE IS THE ACTUAL GAME AS WELL. What a clever thing - a true virtual cartridge.

One of the many genius parts of the PICO-8 is that the "Cartridges" are actually PNG pictures of cartridges. Drink that in for a second. They save a screenshot of the game while the cart is running, then they hide the actual code in a steganographic process - they are hiding the code in two of the bits of the color channels! Since the cart pics are 160*205 there's enough room for 32k.

A p8 file is source code and a p8.png is the compiled cart!

How to make PICO-8 games

The PICO-8 software includes everything you need - consciously constrained - to make AND play games. You hit ESC to move between the game and the game designer. It includes a sprite and music editor as well.

From their site, the specifications are TIGHT on purpose because constraints are fun. When I write for the PalmPilot back in the 90s I had just 4k of heap and it was the most fun I've had in years.

Display - 128x128 16 colours

Cartridge Size - 32k

Sound - 4 channel chip blerps

Code - Lua

Sprites - 256 8x8 sprites

Map - 128x32 cels

"The harsh limitations of PICO-8 are carefully chosen to be fun to work with, to encourage small but expressive designs, and to give cartridges made with PICO-8 their own particular look and feel."

The code you will use is LUA. Here's some demo code of a Hello World that animates 11 sprites and includes two lines of text

t = 0 music(0) -- play music from pattern 0 function _draw() cls() for i=1,11 do -- for each letter for j=0,7 do -- for each rainbow trail part t1 = t + i*4 - j*2 -- adjusted time y = 45-j + cos(t1/50)*5 -- vertical position pal(7, 14-j) -- remap colour from white spr(16+i, 8+i*8, y) -- draw letter sprite end end print("this is pico-8", 37, 70, 14) print("nice to meet you", 34, 80, 12) spr(1, 64-4, 90) -- draw heart sprite t += 1 end

That's just a simple example, there's a huge forum with thousands of games and lots of folks happy to help you in this new world of game creation with the PICO-8. Here's a wonderful PICO-8 Cheat Sheet to print out with a list of functions and concepts. Maybe set it as your wallpaper while developing? There's a detailed User Manual and a 72 page PICO-8 Zine PDF which is really impressive!

And finally, be sure to bookmark this GitHub hosted amazing curated list of PICO-8 resources! https://github.com/pico-8/awesome-PICO-8

  Writing PICO-8 Code in another Editor

There is a 3 year old PICO-8 extension for Visual Studio Code that is a decent start, although it's created assuming a Mac, so if you are a Windows user, you will need to change the Keyboard Shortcuts to something like "Ctrl-Shift-Alt-R" to run cartridges. There's no debugger that I'm seeing. In an ideal world we'd use launch.json and have a registered PICO-8 type and that would make launching after changing code a lot clearer.

There is a more recent "pico8vscodeditor" extension by Steve Robbins that includes snippets for loops and some snippets for the Pico-8 API. I recommend this newer fleshed out extension - kudos Steve! Be sure to include the full path to your PICO-8 executable, and note that the hotkey to run is a chord, starting with "Ctrl-8" then "R."

Editing code directly in the PICO-8 application is totally possible and you can truly develop an entire cart in there, but if you do, you're a better person than I. Here's a directory listing in VSCode on the left and PICO-8 on the right.

And some code.

You can expert to HTML5 as well as binaries for Windows, Mac, and Linux. It's a full game maker! There are also other game systems out there like PicoLove that take PICO-8 in different directions and those are worth knowing about as well.

What about a physical PICO-8 Console

A number of folks have talked about the ultimate portable handheld PICO-8 device. I have done a lot of spelunking and as of this writing it doesn't exist.

You could get a Raspberry Pi Zero and put this Waveshare LCD hat on top. The screen is perfect. But the joystick and buttons...just aren't. There's also no sound by default. But $14 is a good start.

The Tiny GamePi15, also from Waveshare could be good with decent buttons but it has a 240x240 screen.

The full sized Game Hat looks promising and has a large 480x320 screen so you could play PICO-8 at a scaled 256x256.

The RetroStone is also close but you're truly on your own, compiling drivers yourself (twitter thread) from what I can gather

The ClockworkPI GameShell is SOOOO close but the screen is 320x240 which makes 128x128 an awkward scaled mess with aliasing, and the screen the Clockwork folks chose doesn't have a true grid if pixels. Their pixels are staggered. Hopefully they'll offer an alternative module one day, then this would truly be the perfect device. There are clear instructions on how to get going.

The PocketCHIP has a great screen but a nightmare input keyboard.

For now, any PC, Laptop, or Rasberry Pi with a proper setup will do just fine for you to explore the PICO-8 and the world of fantasy consoles!

Sponsor: OzCode is a magical debugging extension for C#/.NET devs working in Visual Studio. Get to the root cause of your bugs faster with heads-up display, advanced search inside objects, LINQ query debugging, side-by-side object comparisons & more. Try for free!

© 2019 Scott Hanselman. All rights reserved.

      The PICO-8 Virtual Fantasy Console is an idealized constrained modern day game maker published first on https://deskbysnafu.tumblr.com/

[mobilenamic]

V-Play is Now Felgo – New Release & Roadmap

Today marks a big milestone: V-Play is now called Felgo and got a new facelift. In this article you will learn:

Why we did the rebranding from V-Play to Felgo

Why this will benefit you

What the Felgo roadmap looks like

How to update to the latest Felgo release

Reasons for Rebranding V-Play to Felgo

The first official version of V-Play was released 2012. We started to work on the first alpha versions in 2009. Back in these days, the main focus area was games. Thus the first APIs were tailored for making cross-platform game development simple and fast to develop.

Interestingly, we saw that many customers used the V-Play APIs and the underlying Qt framework to develop mobile business apps, not only for games. Because many of the APIs we provided were also useful for apps. In addition, a new trend in app development emerged: business apps started to have custom UI and many animations, similar as they are used in games.

This led to a first release of V-Play Apps in 2015. This release contained a specialized set of APIs as part of the V-Play framework to make development easier for software engineers targeting mobile apps, in addition to the already available game APIs. Features like abstracting the different native navigation paradigms of iOS + Android to a single Navigation component, or the native style for Android Material design or Apple Cupertino design made these APIs popular and increased the growth of V-Play developers. Since this release, the most common question we got was:

“But V-Play is only for games, right?”

The answer to this question is and always has been: NO. It is perfectly suited for mobile app development. And it allows a lot more things like:

Develop for desktop platforms with a single code base

Develop for embedded & IoT platforms

Develop for the web (see the roadmap section below)

Cloud services for user authentication, data storage, chat, gamification services and more

In addition, we provide

App Development Services to create a mobile app for you or together with your dev team

Qt Trainings

Qt Consulting services

With such a wide field of use cases and services, the initial name held us back and caused a wrong first impression. This is going to change today.

V-Play is now called Felgo All products and tools, website content, social pages and dev accounts like our Github page are now called Felgo.

What does Felgo mean?

Felgo is an acronym for the 2 V-Play founders names, Christian FELdbacher and Alex LeutGOeb. It is a short & catchy name, easy to type and remember. It allows to become more independent of the actual product and services and provides flexibility for all the new features to come.

What does the Felgo Rebranding Mean for Me as a developer?

Most importantly, all your existing apps work without modification – you do not need to change your existing code after updating to today’s Felgo 3.0 release. New features, however, will only be only for the new Felgo import. The new import makes it easier to develop with Felgo. See the upgrade guide below how to change it.

You can reach the new website on https://felgo.com. All previous links to the v-play.net domain still work and are redirected to this new domain.

The new name allows us to grow even faster than before, because there is no wrong first impression that Felgo is a games-only framework. Felgo is for games, apps, and many more use cases. Accelerated growth means even more features you can expect.

And as a bonus, you will have an easier time telling your co-workers and friends about Felgo and what you can use it for.

Felgo Roadmap

We have been working on several bigger additions for Felgo that will be available in the coming months. You can expect these new features:

Felgo Cloud Build: you will be able to let your app or game build in the cloud, either on our servers or on-premise. You can connect your Git repository or upload a zip file to perform all steps needed in the development process of apps: build, sign, upload for testing or release to the app stores. This service will be available for mobile, Desktop, embedded and Web. It will also allow you to distribute an app to the iOS App store without a Mac, and build for all platforms in parallel.

Web Platform Support: You will be able to publish your existing app to the Web with a single code base.

Felgo Cloud IDE: Setting up a working development environment for the many target platforms can be tricky and time-consuming. With our new cloud-based development IDE, you can develop and even publish any app to all target platforms, without any development setup. You will be able to connect your Git repository, and then test, debug and preview your app in the browser, and then deploy it to mobile, desktop, embedded and web platforms. Combined with the Cloud Build service, you can distribute your app or build updates from within your browser.

Felgo Hot Reload: We have seen great development satisfaction after the Felgo Live Code Reloading feature, which allows you to see changes in your code instantly on all connected devices, for iOS, Android, embedded & Web. With the upcoming Hot Reload feature, you will be able to iterate and develop even faster, because also the state of the app is preserved at a live reload.

Native App Integration: it will become a lot easier to integrate native iOS & Android code to your Felgo apps. You will also be able to integrate a Felgo app or single pages easily into an existing native app.

Embedded & IoT: We will make development for Raspberry Pi, Arduino, i.MX and other popular embedded platforms easier.

If you’d like to get early access to any of these topics, just contact us.

What’s New in the Felgo 3.0 Release – Upgrade Guide

1. Apps, Games and Plugins Combined in Felgo

You no longer need to use different import statements when working with Felgo. The components of the Felgo Apps, Felgo Games and Felgo Plugins API modules are all available with a single import Felgo 3.0 statement:

import Felgo 3.0 // old: // import VPlay 2.0 // import VPlayApps 1.0 // import VPlayPlugins 1.0 import QtQuick 2.0 App { // Storage, required import VPlay 2.0 before Storage { } // NavigationStack, required import VPlayApps 1.0 before NavigationStack { Page { title: "AdMob Page" // AdMob Plugin, required import VPlayPlugins 1.0 before AdMobBanner { adUnitId: "ca-app-pub-3940256099942544/6300978111" // banner test ad by AdMob testDeviceIds: [ "" ] banner: AdMobBanner.Smart anchors.horizontalCenter: parent.horizontalCenter anchors.top: parent.top } } } }

With many recent additions, the line between the Apps and Games SDK got less clear. For example, the Storage type is also relevant for apps but was part of V-Play Games module. The SocialView, which is based on app components, replaced the VPlayGameNetworkView in the Games module, and so on.

You can combine both app and game components in your Felgo app. The unified import for all components now further simplifies this.

Felgo is still compatible with the old V-Play imports. Your existing V-Play projects still work as they used to, without any changes.

But we suggest to update your projects for the Felgo import as soon as you can. The V-Play modules are now deprecated and not maintained further. You can thus only get the latest features and components of future Felgo updates with the new module import.

In case you run into troubles or face an issue after upgrading to Felgo, don’t hesitate to contact us.

2. Improved Component Names

Especially for the Felgo Games module, many components used to have a ‘VPlay’ suffix, which is now removed. This helps to keep component names short and the code is easier to read:

import QtQuick 2.0 import Felgo 3.0 GameWindow { activeScene: scene Scene { id: scene // old: SpriteSequenceVPlay SpriteSequence { id: spriteseq defaultSource: "spritesheet.png" // old: SpriteVPlay Sprite { name: "walk" frameWidth: 32 frameHeight: 32 frameCount: 4 startFrameColumn: 1 frameRate: 20 to: {"jump":0, "walk": 1} } // old: SpriteVPlay Sprite { name: "jump" frameWidth: 32 frameHeight: 32 frameCount: 4 startFrameColumn: 5 frameRate: 10 to: {"walk":1} } } // SpriteSequence Row { spacing: dp(4) anchors.centerIn: parent AppButton { text: "walk" onClicked: spriteseq.jumpTo("walk") } AppButton { text: "jump" onClicked: spriteseq.jumpTo("jump") } } } // Scene } // GameWindow

Note: Some of the renamed components in the V-Play SDK have colliding names with Qt components. For Example, the Qt Quick module also holds a SpriteSequence or Sprite type. Qt Creator auto-resolves the types with the imported modules in the QML file. At the moment, the most recent import gets precedence to earlier ones. The above example thus uses the Felgo SpriteSequence and Sprite types, because we import Felgo after Qt Quick.

To avoid issues and mix-ups due to this auto-resolve, you can make sure to always use a specific module by setting a custom module identifier for the import. This is how you could use the Qt Quick types in the above example, without changing the order of imported modules:

import QtQuick 2.0 as QtQuick import Felgo 3.0 GameWindow { activeScene: scene Scene { id: scene QtQuick.SpriteSequence { // ... QtQuick.Sprite { // ... } } // SpriteSequence } // Scene } // GameWindow

This is the full list of components with a removed ‘VPlay’ suffix in their name:

Scene3DVPlay → Scene3D

CameraVPlay → Camera

AnimatedSpriteVPlay → AnimatedSprite

SpriteVPlay → Sprite

SpriteSequenceVPlay → SpriteSequence

TexturePackerAnimatedSpriteVPlay → TexturePackerAnimatedSprite

TexturePackerSpriteVPlay → TexturePackerSprite

TexturePackerSpriteSequenceVPlay → TexturePackerSpriteSequence

SoundEffectVPlay → SoundEffect

ParticleVPlay → Particle

When you update your project to the new Felgo 3.0 import, please also make sure to use the new names for these components if you use them. The name changes only apply for the Felgo module import. Your existing project with V-Play imports is not affected and can still use the old names.

3. Renamed FelgoGameNetwork, FelgoMultiplayer and SocialView

With the rename of V-Play to Felgo, the game network and multiplayer components got renamed as well. The VPlayGameNetwork type is now FelgoGameNetwork, and VPlayMultiplayer turned into FelgoMultiplayer.

As the VPlayGameNetworkView and VPlayMultiplayerView are in the process of getting deprecated, they do not get the Felgo name. These types have ‘VPlay’ removed and are available as GameNetworkView and MultiplayerView. Only the SocialView, which is the new default UI for social services, will see updates and fixes in the future and is the preferred component to use:

import Felgo 3.0 App { FelgoGameNetwork { id: gameNetwork gameId: 285 secret: "AmazinglySecureGameSecret" multiplayerItem: multiplayer } FelgoMultiplayer { id: multiplayer appKey: "dd7f1761-038c-4722-9f94-812d798cecfb" pushKey: "a4780578-5aad-4590-acbe-057c232913b5" gameNetworkItem: gameNetwork } SocialView { id: socialView gameNetworkItem: gameNetwork multiplayerItem: multiplayer } }

4. Felgo Project Configuration and FelgoApplication

To integrate the Felgo SDK in your project, set CONFIG += felgo in your *.pro configuration:

# allows to add DEPLOYMENTFOLDERS and links to the Felgo library and QtCreator auto-completion CONFIG += felgo # old: CONFIG += vplay # uncomment this line to add the Live Client Module and use live reloading with your custom C++ code # for the remaining steps to build a custom Live Code Reload app see here: https://felgo.com/custom-code-reload-app/ # CONFIG += felgo-live # old: CONFIG += vplay-live

The previous CONFIG += v-play setting is still supported. To use live reloading with custom C++ code, the CONFIG += v-play-live setting changed to CONFIG += felgo-live as well.

If you use Felgo Plugins in your project, link the iOS Plugin Frameworks with the FELGO_PLUGINS configuration:

ios { QMAKE_INFO_PLIST = ios/Project-Info.plist OTHER_FILES += $$QMAKE_INFO_PLIST FELGO_PLUGINS += admob # old: VPLAY_PLUGINS += admob }

In your main.cpp, the Felgo application and Live Client includes and class names also got renamed:

#include <QApplication> #include <QQmlApplicationEngine> #include <FelgoApplication> // old: #include <VPApplication> // uncomment this line to add the Live Client Module and use live reloading with your custom C++ code //#include <FelgoLiveClient> // old: #include <VPLiveClient> int main(int argc, char *argv[]) { QApplication app(argc, argv); FelgoApplication felgo; // old: VPApplication vplay; // ... // to start your project as Live Client, comment (remove) the lines "felgo.setMainQmlFileName ..." & "engine.load ...", and uncomment the line below //FelgoLiveClient client (&engine); // old: VPLiveClient client (&engine); return app.exec(); }

Similar to other changes of this update, the previous class names and includes are still supported as well.

5. Deprecated Components

With the power of Felgo Apps at hand, there’s no need to use outdated controls that were part of the Game module. You can take advantage of Felgo Apps Controls and Qt Quick Controls 2 for your games instead.

To make the difference clear and match the name pattern of Felgo app controls like AppButton, those game controls now prepend ‘Game’. In case a ‘VPlay’ suffix was used, it is removed:

ButtonVPlay → GameButton

SliderVPlay → GameSlider

SwitchVPlay → GameSwitch

TextFieldVPlay → GameTextField

ScrollViewVPlay → GameScrollView

Those types are also marked deprecated and won’t receive updates anymore. We advise to not use these types in future projects

You can read more about the latest changes and previous additions in the change log.

How to Update Felgo

Test out these new features by following these steps:

Open the Felgo SDK Maintenance Tool in your Felgo SDK directory.

Choose “Update components” and finish the update process to get this release as described in the Felgo Update Guide.

If you haven’t installed Felgo yet, you can do so now with the latest installer from here. Now you can explore all of the new features included in this release!

For a full list of improvements and fixes to Felgo in this update, please check out the change log!

We are looking forward to exciting times ahead and to many more great apps developed by you, powered by Felgo!

Happy coding.

The post V-Play is Now Felgo – New Release & Roadmap appeared first on Felgo.

V-Play is Now Felgo – New Release & Roadmap published first on https://medium.com/@TheTruthSpy

[glennmalcolm]

Everything STEM. Do All Methods of Learning to Code Require a Device and an App?

Coding in schools is big business. Everywhere you turn there's a STEM organisation vying for your attention alongside Barack Obama himself. With STEM, or it’s brethren, STEAM, covering all bases from ex-MIT students and employees through to a multitude of KickStarter campaigns it seems that if you have an idea for children to learn to code you'd better get busy and sort your Chinese manufacturers out, STAT.

STEM + Device. What's the real goal?

With this influx of coding opportunities for educators, parents and children alike, there's almost always a 'thing' attached [a ‘thing’ in this case is defined as an attachment by which the application that controls it makes the money]. If your product doesn't have (and I need to try to differentiate this from Nursery ages and up) an iPad 'thing' to connect, a wooden 'thing' to control, a blue plastic 'thing' to program, a stand alone robot 'thing' to learn from an app (though not strictly coding), Raspberry Pi 'thing', another Pi 'thing' or the many, many, many Arduino 'things' that range from the brilliantly simple to the absurd then children will simply not be able to learn to code in the way POTUS once directed. Then there's the premier league trio: WeDO, LEGO and Tetrix. All Hail!

Something’s not quite right. If your students are learning about instructions then all is good as too, if your students are below seven years old. But what about further along the track? If you are learning to program, do you need an attached 'thing'? LittleBits for example, lets you work only on the 'thing' because it is the thing. 

What I really do like about these ‘things’ is the engagement they offer. What I don't like about them is that there is usually little to no support for the average layman teacher, the expectation that you 'just gotta tinker and you'll understand’ and, in some of the cases, where to give a class worth of kids the experience of 'hive' learning, they are exorbitantly expensive for what they really are. And, if you want to be trained or a club for your students, then you'd better be prepared to fork out a lot of cash for, in my experience, very little in return.

This is an age old situation though: have idea, prototype, build, take to market and sell to an education department of unsuspecting heads of school for an unnecessarily high uptick (TTS Bee Bots for $70+ we're looking at you). The other side to this is that the coding aspect to them is now 'appified'. Appified is a disgusting term however needs must.

Apps for this, Apps for that

There's an app for everything. I understand that control is necessary for these types of devices. However, the snag is there is another fork to this dilemma of learning alongside these devices. The fact that many now come with a game. It's almost as if, collectively, we assume any child can't learn nowadays without instant gratification within a linear trajectory. There are a number that fall into this kind of trap. It's also happening where learning programming structures natively is becoming a game too unless it's a Scratch-like platform and even these are being morphed.

The apps usually work a little like this: offer an example of a few steps, child copy steps (no or few deviations) and then, if it's correct then a bell goes off or an animation lets you know you're a winner or loser. This is also happening on Hour of Code. It's nice to dip your toe but the learning beyond this is thin. It enthuses our students however, wouldn’t it be great to have a Khan’s Academy type approach minus the app and let my students work in the browser.

The Walled Garden

Nothing is more prevalent than this is Apple's Swift Playgrounds. While I really like how enthralled our kids are with it and, if you have an iPad, then it's readily available. The problem is that it's Apple's ecosystem and that tight grip on what you can, can't and how you're allowed to do things is there for all to see. I find the learning path to learn programming is basics is patchy.

Questions I always ask every time I look into Swift Playgrounds are: Can you do this in the browser? No. Can you freely make errors? Yes and no. Can you fix errors? Sometimes. Can you make your own fixes? Sometimes. Does the learning progress depth and breadth in equal measure? No. Do I build anything ? Not really. Can I learn loops? Yes and no. Can I freely apply these loops? No. Well yes, if I complete the game and open XCode. When do I learn how lists are applied? Right after the exhaustive learning of nested loops. Is this the right spot without allowing me to apply in my own way? And, can I make an App directly in this?

If you look here at Touch Develop you can use all languages in one place all in the browser. You have tutorials and, you showcases of other designs and builds to edit much like in Scratch. Wouldn't it be nice if Swift Playgrounds was like this?

It is this aspect that is rather frustrating as a teacher of computing and IT. The unifying problem with coding like this in schools and education as a whole is that it has no real goal or end product beyond something akin to a high score. At this sort of level of understanding, you would want your students to apply their own thinking to a goal, say, a simple game with scores and an array of non-playing characters.

As we know with successful apps such as this is that they are copied and replicated with little change to the outcomes. Children still plough through them thinking they're coding when in reality they can't apply this area of learning to another level of logic on another platform - seldom have I seen a child move from this to XCode smoothly.

Appification Versus Open Standards

I think the level of learning to program and build simple algorithms is lost because of this as children have some level of expectation that the app, whatever it is, will guide them from A to Z and kind of do it for them. And, sometimes with an arbitrary score along the way: Well done, you've won a badge for making Mr. Blob move forward and turn through an orchard seven times.

The gold standard here for primary aged students is of course, Scratch. We all know and love Scratch. It's based on SmallTalk an open source platform and it remains open because its very foundation is to 'remix' whatever you create - whatever you make is open by default. There's a version 2.0 that is web based making it immediately linked and cross platform. There are open plugins for devices. There's even Scratch Jnr. on iOS which has one tiny foot in my gripe above (however this is not as guilty as that Daisy programming app for the under 5’s). It's just a shame that the original Scratch 2.0 is built on Adobe Flash/ Air. Nevertheless, its level of accessibility is very low and its level of complexity can be very high (Universities edit the source for robotic control).

It's accessible for one reason and this will fire a few people up: You explore based on an introduction by someone who has previously used and successfully built with it. As a seven to ten year old it’s extremely rare for a child to just discover it by chance. If you did then you were already looking for this kind of thing and all hats off to you - we need more of your kind! If you are at this age and you 'just found it' then I'm intrigued as to how. And, that person who introduces it shows you, nay, inspires you to try out a series of loops and controls to make a sprite around a screen.

Beyond this, Scratch has a fantastic help section (and community) that guides you with a vast array examples. Want to build your own Pac-Man? no problem. Want to build your own version of Minecraft? Then start that journey. This is how it works for the large part and without an app to offer you a badge, score and yeehar along the way.

Sonic Pi

Programming Music

There is, I believe, a third way though and that is Sonic Pi produced by Sam Aaron. Sonic Pi is a fantastic platform for coding music, and not just plinky plink piano synth stuff, real live and in time beat and melody mixing. It too is open source, available on most platforms (no mobile just yet) and is based on assisting children to try things out for themselves with text rather than blocks. The syntax is basically Ruby and the console you type into recognises grammatical errors should there be any. The saving grace here is that you have four areas in front of you and one of them is an examples and working glossary section all written in jargon-less support. An ‘Runtime error’ tells you what and where the error is. And, should you be mid mix, then it continues to play the musical loops and doesn’t just stop. And the premise? If a ten year old child can’t understand the individual processes (just like Scratch it can get very, very complex but each part is very accessible) then it doesn’t go into the next update.

The way Sonic Pi works, is that you code music in real time. You can be as basic as you wish. There is not real formatting rules as such. You could, as in Scratch, make very lengthy strings of instructions to make a musical algorithm. It may look completely bonkers, but, as the opening splash screen points out ‘there are no mistakes, only opportunities’.

The real selling point of Sonic Pi is that it codes music IN TIME. This is huge. The mechanics behind this is kind of lost on the layman, however the timing aspect of this is the reason it actually works. Just think about a MIDI keyboard and its scale. Each key is numbered and the numbers either get higher or lower. Musical notes do the same. When you play each note is up to you - this is time. How you do this is up to you, your mood and, as you sell your final album to go platinum, your hopes, dreams and fears. I jest. However, even as your first production piece ends (it may sound like Ross at Central Perk) you will have something approaching an accompaniment.

Where Sonic Pi differs though is how you code. You code beats and samples in time making live shows of coding. This is completely different to nearly any other type of programming. Think of a programming sequence that is not HTML or Javascript (HTML is not strictly programming) as you can see this in modules such as web emulators or something like Mozilla Thimble. With these languages you have to build then hit run and see if it works. The end result is one of three things: it doesn’t run, it runs but has errors strewn across it or it runs. You don’t run the code and see it actually working or in this case, hear it working. You physically play the code. This is a magnificent method to help kids see, hear and learn to code through text because they are free to type without being disappointed that their code is broken… for the third time this hour. This is the App-less safety net of discovering. No high scores. No badge-like fads and no bling, bling doo dads.

As and teacher and leader of technology I firmly believe that the STEM wagon is bloated with money grabbing devices. They are synced to game-like apps that in the long term apply little to no success for children to understand programming practices. And these practices require a blend of self discovery, support and rote learning. I understand the benefits of inquiry based learning and the merits it returns however, in this realm, you, as ‘guide on the side’, had better know what to do when that app can’t provide that solid goal the children are seeking and teach how to program the behaviours the device requires. Because, if you can’t support in this way then you are either resigned to allowing the children to use it like a remote controlled toy or quickly move on to something more in-depth. Tamagotchi, if you remember, was a passing fad but then Barack didn’t globally address it.

Be inspired and watch Sam live coding.

[izztreme-art-n-stuff]

Decided to redraw the cover for The Tearing

Made it more vague and less of a clusterfuck

Sorry MegaByte fans, I've reduced him to eyes

Just gonna...

[izztreme-art-n-stuff]

Final fanfic preview

And it's just Red casually being a menace

Cool

[izztreme-art-n-stuff]

This Panda is cunt, just so you know

And he'll always be a cunt because he's a reoccurring villain, but not in the usual User way

Trust me, he has a lot of plans

[izztreme-art-n-stuff]

New Candy Rush reboot, with Raspberry Pi

[izztreme-art-n-stuff]

New animatic in the works

[izztreme-art-n-stuff]

The back cover for Cooking Gamma

You're probably wondering why the number is 10 when it's the second episode, and that's because it's 2 in binary. I'm doing binary numbers for all of RB:RJ's back covers from now on. Only RB:RJ though, my other fics will have normal numbers.

Edit: Deleted link for reason of being rewritten

[izztreme-art-n-stuff]

Finally, after nearly a year of procrastination, the second episode of RB:RJ is here! If there's anyone that likes this bizarre fic, come get your food, and sorry it took so long.

Side note: I actually like how I did the series logo on this cover. Help it, it's sinking.

Edit: Deleted link for reason of being rewritten

[izztreme-art-n-stuff]

Episode 2 is coming soon...after I rewrite the whole thing :/

Let's just say I wasn't happy with how the first draft was going, it was repetitive and boring and not something I wanted to read. So I'm remaking from, well, not entirely from the ground up but pretty close.

There's still a Gordon Ramsey parody, though it more of the user themselves playing a more sadistic version (100% the user here is 12 lol) rather than it being a random npc. And it still has cooking in it, just in different form.

[izztreme-art-n-stuff]

So, Cooking Gamma is in peer review, though not sure how much could be fixed

It's pretty mid, but at least palatable to me personally

Though one thing I love through all these rewrites is the interaction between Blinn and Raspberry

They just...click, honestly. They're just a good dynamic and potential partnership