Log In  

Cart #draw_vs_update-1 | 2022-02-13 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

TO LOAD THIS CART in Pico-8, type in immediate mode, load #draw_vs_update

Press 🅾️ to swap between using _update() and _draw(). When in _draw() mode you may need to hold 🅾️ down a bit to get it to the opposite mode.

Yet this confuses me. Why is it that draw() runs faster than update() ?

And yes you can change it to update60() that does run faster, but still not as fast as draw().

P#106816 2022-02-13 02:53 ( Edited 2022-02-13 05:10)

I don't remember exactly why but the difference between draw and update is how they handle lag.
Update will halt a frame if there's lag and draw will keep on going but not draw a full frame I think? like draw part of it and then push the to the screen.
Not 100% sure but that's what I've always known. update and draw are not identical.

P#106820 2022-02-13 04:54

Thanks, @SmellyFishstiks. Yeah I was thinking - I don't know - something's just not right. Why is it everyone drops using _draw() in most of their code and is quite content with _update() in that alone ... I guess _update() is more accurate or something ?

Let me try something.

Very straight forward. I just added cls() in front of the pixel drawing, no change at all.

I seem to remember an earlier Pico-8 where the screen would draw if there was not enough time to do so, so my random pixel thing would tear frames. It's not doing that now.

Should we or shouldn't we use _draw() for maximum speed ?

In any case the speed of current _update() is a helluva lot slower than 30fps.

This is just not right. Here I updated the top with FPS from STAT(7). I checked my CPU usage too, it's the same either way using _draw() or _update().

P#106821 2022-02-13 05:11

Well I'm not sure you can really tell the tearing with random noise.. but it's fine to use _draw or _update,
But if you don't mind capturing input mid frame or the tearing than _draw would feel nicer probably than _update. though only during lagging.. which you don't want anyways ;p

P#106826 2022-02-13 06:46

To quote the manual in the program structure section:

    _DRAW() is normally called at 30fps, but if it can not complete in time, PICO-8 will attempt to 
    run at 15fps and call _UPDATE() twice per visible frame to compensate.

So _update() attempts to always run the expected number of times, while _draw() can be called by the engine less times if needed. As I understand, this is how most game engines run, just with modern 3d engines often having them on different threads and with some amount of CPU dedicated to separate physics calculations as well. I also have my own engine using Lua on top of SDL2 (with generic 5.4 rather than a custom version of Lua), so I can say from experience that it's really easy to set that up as long as you know that it's a thing engines should do.

Screen tearing shouldn't happen unless the engine is trying it's hardest to render as much as possible, monitor state be darned. I don't know if pico-8 uses SDL2's rendering api or imports openGL/whatever, but either case would allow a mandate for vsync. Since the manual doesn't mention vsync at all, I would assume that at some point it was switched on. From there, all the engine would need to do is not hand the screen state over to the actual rendering core if it detects that drawing didn't actually finish.

As for the difference between drawing in _update() and drawing in _draw(), it's possible the engine sets things up with the expectation of drawing in the _draw() and thus optimizes more under the hood. I would certainly expect batching draw calls to be easier when not having to guess when they need to flush. For flavor, you can think of this as being the console's graphics chip having to start and stop too much.

One other thing, it would make for a better test if you ran the cartridge separately with one of the functions commented out each time. Otherwise, you're still testing how pico-8 runs with both being expected.

P#106825 2022-02-13 06:46

Hi @kimiyoribaka.

One other thing, it would make for a better test if you ran the cartridge separately with one of the functions commented out each time. Otherwise, you're still testing how pico-8 runs with both being expected.

That's a good point at that. OK, here is the DRAW function only.

Cart #gikufukosu-0 | 2022-02-13 | Code ▽ | Embed ▽ | No License

It is rapidly flipping between 15fps and 30fps if you run it in immediate mode. If you run it online though it states 15fps which is incorrect.

Here is the UPDATE function only.

Cart #hegayihowi-0 | 2022-02-13 | Code ▽ | Embed ▽ | No License

It is staying at 15fps offline or online.

Let's do one more, a routine with FLIP() only.

Cart #mehuyuhufe-0 | 2022-02-13 | Code ▽ | Embed ▽ | No License

There is the screen tearing, and of course this can be fixed with the command, HOLDFRAME().

Cart #sudegunoni-0 | 2022-02-13 | Code ▽ | Embed ▽ | No License

Where it states it is running cleanly at 30fps and appears to be doing so.

... Alright so let's talk about timing. Update() is the only one not really playing ball here. Clearly it is not 15fps all the time, only if it gets too "busy" with what it is doing. Yet Pico-8 is STILL a virtual system. It should be possible to do any number of calculations or pixels without it ever falling under 30fps.

I guess what I'm getting at guys - is it appears to me that Pico-8 is "emulating" hardware inability. And I'm not so sure that is a great thing. Correct me please if I'm mistaken on this. I'd like to know why there are only 15fps in _update() despite us clearly running computers that can run millions of polygons without even breaking a sweat. The Ps2 emulator for PC for instance comes to mind.

P#106842 2022-02-13 18:04 ( Edited 2022-02-13 20:44)

yeah - that’s one of core principle of Pico8, this is a fantasy console running with an (artificially) limited cpu (akin to a 8mhz machine).

updating every single pixel with pset is simply over the frame budget at 30fps.

P#106855 2022-02-13 19:39 ( Edited 2022-02-13 19:42)

Well, flip. No pun intended, @freds72. Emulating hardware inability though, that takes emulation to a new step.

I know when the first 8-bit Nintendo emulators came out for DOS, they even emulated the hardware limitation of flickering when displaying more than 4-sprites on the same vertical line.

Later of course and in modern emulators they removed that entirely.

Well that's just frustrating about Pico-8. I'm still working on my project. If Pico-8 though just can't take advantage of someone's actual CPU, that - well that to me is just not right.

30FPS is fine. I guess I'd really like to see a programming language where everything you do is just BLINK and then the system neatly waits 1/30th of a second - you know where the pixels scroll like liquid across the screen.

Unless of course you deliberately create delays in your code like DELAY(milliseconds) Failing that though, yeah, BLINK for any code at all, no matter how complex. That'd be awesome. I think everyone would like that.

I also wrote a program HERE:


To demonstrate the power of cached calculations. Maybe ZEP will consider this and it will help speed up Pico-8 considerably.

P#106858 2022-02-13 20:34 ( Edited 2022-02-13 23:14)

The emulated CPU is one of the defining features of PICO-8, and what sets it apart from traditional game engines and other fantasy consoles. Not only does it drive creativity through constraints, but a nice side-effect is that PICO-8 games run the same for everyone - just like console games.

PICO-8 wouldn't be faster if it implemented "cached calculations" (aka memoization), since the limitations are entirely artificial. Calculating a square root is "slow", simply because Zep decided that it would take x cycles on his fake CPU. But you can implement memoization in your game if you need it, that could definitely make it run faster if you're calculating the same values again and again.

P#106863 2022-02-13 21:22

feel free to move on to other engines.
one of the key interest of Pico8 is to find the best algorithm working with the limits, including cpu constraints.

P#106864 2022-02-13 21:23

Yeah right, @freds72. Dream on. :) You know I'm not leaving Pico-8 for any reason. You are always the one suggesting that I leave Pico-8 is one reason I am not very fond of you.

@scambier, I know I'm not alone. Perhaps ZEP's new brainchild, still under production, Picotron,


will have some of these elements I mentioned.

P#106865 2022-02-13 21:45 ( Edited 2022-02-14 02:39)

@dw817 I would hugely, hugely, hugely recommend the online course Create a 2D Game Engine with C++ & Lua. Using what you learn from that, you can basically start writing your own fantasy console. I don't say that as, "Go write your own if you don't like PICO-8." But rather, "By trying to write your own, you will come to understand SO MANY things about why PICO-8 is the way it is and and does the things it does."

You'll start seeing all the little tiny decisions that pile up together to create a system like PICO-8. You'll also start to see why it doesn't do things a certain way and why it will probably never do things that way if it wants to still be the thing that it is. It's quite illuminating, I can tell you. You'll have dozens of moments of, "Well, I want my fantasy console to do X. Hmm... but that would mean I have to... OH. Oh! So that's why PICO-8 does it that way. Huh."

(Also, even though the Pikuma course uses C++, don't be scared off by that. I don't know C++ at all, or rather, I didn't when I started. The instructor does not assume you are a well-versed C++ programmer. It was still very accessible to me and I was able to get through it without too much trouble.)

P#106882 2022-02-14 05:25 ( Edited 2022-02-14 05:26)

@MBoffin, you are partially correct.

I had written a Fantasy Console called IF back starting on the Apple ][ years ago and working my way up from there, Commodore Amiga, IBM-Dos, IBM Windows 3.1, IBM Windows 95, and started to slow down when Windows XP came out.

I have never worked or programmed on the Macintosh computer.

But back on the Apple ][ computer, at the time it was a text only system I wrote but worked a whole lot better than most BASIC programming languages even today.

Everything had an identity and everything had a default. Any thing that was unknown to the language could still be interpreted by its defaults.

It was bliss to work in with no restraints for data types and of course it was written in a time before the mouse so the interface to me was perfect as I have a little muscle spasms today - accounts for my high speed typing.

I have programmed in a variety of languages including C++. The whole concept to me of the BEST programming language to work in is one that runs really no matter what and is already in execution before you lift your finger off the ENTER key.

Where you can stop a program and flash-freeze the actual computer and all its data at that point so you can return to it later for reference or debugging.

If the program crashes it is because you ordered it to crash based on certain circumstances, the default of course being you misspelled a known command, yet that too can also be managed and harnessed.

It is instantaneous in its decisions, it allows forwards and backwards running of statements including recursive variable usage, and of course includes onboard load/save state as either digits, filename, or time elapsed.

I realize what I wrote back for the Apple ][ even today is more advanced than Pico-8 structure-wise, yet many of the ideas I have come up with for Pico-8 for ZEP have already come to fruition, I am glad for that.

  • I don't program as intensely as I used to - especially since I am also writing book chapters and tutorials for other systems and theories of systems that are not even programming related.

As I am aging I am slowing down a little bit in my coding and planning of code, but my brain is always active, seeking ways of making things simpler and better in any capacity, not just on the computer.

I reject many of the standard ways programming languages are developed today so this tutorial you suggest would force me to unlearn what I know. And this is definitely not the first time this has happened for education - in many of its different and varied facets.

Me rejecting conventional standards. I always have, I always will, and I will always succeed where others fail. Because to me:

"The unknown is only the unexplored."

And you can quote me on that.

Bottom line, as many of my polite suggestions have made the cut and have made Pico-8 what it is today, I am here to stay. Flattery, carrot, jar of honey, paid tutorial, whatever, no lures will pull me away from my post.

I am wanted here even if you small few others completely hate me in every possibly way merely for my dedication and devotion. Get over yourself.

Also as many of you, I have invested too many man-hours into this marvel of a programming language - to be dissuaded by venerable veterans even today.

The original topic which I think many have somehow forgotten was:

"Update() vs Draw() Why is it faster ?"

This answer has been reached understanding that the overall belief anyway is that ZEP is interested in maintaining a crippled hardware appearance for nostalgic reasons solely to maintain the "fantasy console" ambience.

It has absolutely nothing to do with anything else.

I have to accept this because surely there is no deception on that part of those that relayed this was the correct answer.

In truth more and more I am beginning to believe Pico-8 was neither written in a fast nor efficient programming language itself - and the speed flaws and limitations we see are Pico-8 already running flat out and incapable of doing any more than we've already seen - especially as far as horsepower goes.

I hate to come to this conclusion but that certainly makes a lot more sense to me than someone deliberately crippling their own OS to maintain a limited flavor of a non-existent environment.

So it is up to us the programmers to work within the constraints of this permanently slowed OS which is either done through deliberation or actual limitations - with clever code and innovative programming, just as @freds72 stated ...

@MBoffin, we can continue this conversation if you like - to explore what any programming language =CAN= easily do today, but I'd rather not clutter up this thread anymore with off-topic talk that others and myself already have done.

P#106887 2022-02-14 07:37

> In truth more and more I am beginning to believe Pico-8 was neither written in a fast nor efficient programming language itself - and the speed flaws and limitations we see are Pico-8 already running flat out and incapable of doing any more than we've already seen - especially as far as horsepower goes.

lol no. It's written in C on top of SDL. The "crippled" CPU as you call it is an intentional design decision. Actually, the CPU cost of several API functions have changed over the years, following feedback from developers about consistency issues.

P#106888 2022-02-14 07:46 ( Edited 2022-02-14 07:56)

@dw817 I'm not sure if you've watched zep's talk from Practice 2018, but your comments above suggest that maybe you have not? I would suggest watching it, as it is a great talk about his design philosophy and why the limitations are the way they are in PICO-8. I don't know if you'll agree with that design philosophy, but maybe it'll help illuminate the reasoning behind PICO-8's constraints, including artificially limiting CPU. (I can assure you, it's very much an artificial limitation, not badly written code.)

I think I'm okay with not continuing this conversation. I mostly chimed in just to suggest the course of study above, as it helped me so much and I just plain enjoyed learning what it taught. That, combined with the video I just linked, is all I really have to contribute to the discussion. Cheers!

P#106889 2022-02-14 08:33


Consistency I can understand would be important - to make sure it flows properly and smoothly.


Yes I have seen the video, downloaded it, and viewed it many times. In fact I have presented that very URL to many people joining Lexaloffle in the past. You did not see this ? SMH.

"Cosy Spaces" was the brunt of the conversation and I'm fully aware of this - yet I am also fully aware ZEP has indeed taken many of my suggestions to heart and made them part of future Pico-8. I could shut up as I think many of you want me to, but then you would not have the nice version of Pico-8 we have today.

. . .


Let's get a few things straight. I'm here in Pico-8 for a few reasons. Let's go over these.

  1. Enlarged Pixels. I am a pixel artist, especially when it comes to B&W. While years ago I could draw on a massive scale, today I like to do small 8x8 pixel art and today in fact have hundreds of pictures I've drawn and ported from one computer system to another.

  2. Compilation Time. It takes no time at all to run a program. Today most game programming languages can take anywhere from 1-second to 1-minute to compile something as simple as, "Hello world." Being able to run code immediately is a huge benefit.

  3. Built-in IDE. There are a great many game programming languages out there that do not contain this and in fact want you to use Notepad or some other text editor. I never did like this and always prefer to see an IDE that works harmoniously with the system.

  4. Little CPU Usage. Many game programming languages, especially the early ones would peg your CPU usage at 100% even for very simple programs. Pico-8 does not do this.

  5. Unique Arrays. Pico-8 has the unique ability of creating arrays within arrays such as a={} a[0]={} And quite unique with a["apple"]="fruit" Even Blitzmax cannot do this or this kind of variable handling and while you can have arrays thus, global a[nn,nn,nn] it requires numeric indexes and cannot create an array within an array.

  6. The Big Board. Pico-8 is capable of modifying every single pixel close to 30fps. While blitz can do this if you shrink the screen to 128x128, many other programming languages will not run well if you attempt this, even in shrinking the screen.

  7. Onboard Sprite Editor. Pico-8 has this. While other Fantasy Consoles have since copied Pico-8, this is a nice feature to have instead of having to rely on an external image editor. You have 256 8x8-pixeled sprites to work with, each pixel capable of holding any of 16-colors including black and white.

  8. SFX And Music. I'm aware Pico-8 has its own SFX and MUSIC editor though I would've preferred import of audio such as Ogg or Wav. Nonetheless I have already written many carts and a few full games in Pico-8 making use of the SFX system for my programs. Pico-8's onboard sound editor lets you create music and sound quite similar to what you would get on the Atari 2600 with 4-channel audio.

  9. Mapper. Pico-8 comes with an onboard mapper allowing you to design rooms, dungeons, and maps. It is quite intuitive and easy to use. You are given 128 tiles across by 64 tiles down to work with, or 128x128 if you sacrifice half of your available 256 8x8-pixel sprites.

  10. Community. Pico-8 has a strong community with many people and many people's opinions, sometimes users directly clashing against another single individual user (as can be seen in this post). Yet mostly we get along quite well. In this, code or comments for either new or existing Pico-8 carts is written pretty well every 5-10 minutes of the day.

  11. Out Of The Box. Once you have purchased Pico-8 you don't need to install additional libraries, add system requests, or even change the configuration. It runs right out of the box and this is something vital to me in any code today.

  12. Configuration. If you are not 100% content with the way Pico-8 can run then you have massive configuration options available which after a year of coding with the default configuration I finally did decide to change to my liking.

  13. SPLORE. Pico-8 has built in it a game menu (Explore) that lets you play any game uploaded from the Lexaloffle website and sorts them under FAVORITES, NEW, FEATURED, WORK IN PROGRESS, JAM, LUCKY DRAW, and SEARCH. Even if you don't code but are an avid game player, this ability alone to access literally thousands of games is completely worth the purchase of Pico-8.

  14. Support. Pico-8 is a growing thing and is definitely supported by the community, especially if any user has a suggestion that is deemed positive to @zep. If ZEP likes it then it does indeed get added into the newest release. This is different from many other game programming languages in that often the author is either not interested or posts a "finished" product that will not see changes in the future.

  15. Source Code. If you post your code online here, the source-code is open and available to everyone. This is quite different from many other game programming languages that can only export EXE or HTML making this quite difficult to post online where others can retrieve and learn from how it was made.

  16. Sharing. Pico-8 programs can be posted online as easy as typing save @clip in the editor and pressing CTRL+V in any message on the Lexaloffle website. That is unique and incredible compared to many other systems where you could only post as a binary attachment the EXE or HTML.

  17. Distribution. Pico-8 while it can indeed be run from the system or online it also has the ability to be compiled to a true HTML (Web application), .JS, Windows EXE (Binary), Macintosh executable, and Linux executable.

  18. Does Not Hardware Snap. Some of the earlier game development systems would invoke hardware methods to change your resolution to 320x240 or what have you. If you are running 2 monitors as I am, it can cause chaos with the 2nd. Pico-8 does not do this and while it uses the standard OpenGL for graphics, it does not 'tweak' your monitor and all drawing is always at a software level.

  19. Size. Not source-code size which for any system could always be small, no, I am referring to in this particular case the size of an export to external EXE which is about 5mb and contains 3-files. Other game making systems can go as high as 50-100mb for something as simple as, "Hello world." and take minutes of compilation.

  20. Immediate Mode. This is missing from many game-developing tools today and allows you to type commands that are run immediately, especially useful for debugging and setting new variables when you stop your code and continue it afterwards. Also using PRINT to view values or calculations.

  21. Import And Export Of Images. Some early game development languages might let you import images to assist you in your program but would not let you export them. Pico-8 can easily do both taking your imported image, resizing it and changing to match its unique 16-color palette - with no work on your part.

  22. Market. Once you have Pico-8 you are entitled and welcome to write and sell your game with no money or membership being required to send back to the Pico-8/Lexaloffle company. This is different from other companies some of which require percentage royalties or paid monthly memberships. Pico-8 lets you freely market your games with no restrictions.

  23. Video. Pico-8 is the only programming language to my knowledge that lets you record an animated GIF video of your cart in action. This is especially useful to show interesting animated aspects of your program and to point out errors in other existing codes.

  24. Multi-Cart. Pico-8 has the ability of leaving one program to call another located on the Lexaloffle website. This allows for such things as holiday cart menus which highlight and execute a select set of Pico-8 carts to match the season. It also allows users to develop more than one program should the artificial limitations of the system be reached.

  25. Online Loading For Offline Use. You can type something as simple as load #cartname to load that particular Pico-8 cartridge directly into the system where you can examine, play, and modify it. Just look for the cart name under the artwork where the PLAY button is. And of course you can save this cart to your hard-drive for later play and work.

  26. Joystick And Input. Pico-8 is not like other game systems that require a keyboard. While you are certainly welcome to use a keyboard for your input, which is configurable by the way, you do not have to and Pico-8 is already well-equipped to handle your wireless or wired joystick for game play. Pico-8 comes with some primary input buttons. (Start) (O) (X) and the four arrow-keys. It is also equipped to handle 3-other player inputs. Pico-8 can also read the entire keyboard if you so desire in your code.

  27. Mouse. While many game programming languages allow for the mouse, some earlier ones do not. Pico-8 however does. Not just reading the left and right mouse button but the middle button and roller as well. This makes for some versatile input when matched with its already robust joystick and keyboard input.

  28. Itch.io. The website http://www.itch.io. is chock full of both free and commercial games. Pico-8 carts can be uploaded here and sold to the public if you so choose. I myself have posted one of my complete games there and did in fact make a bit of profit in money. It was mostly out of curiosity I posted it there though and unless I write something groundbreaking, all the other games I've written to date are free to all.

  29. Input. Pico-8 is one of the rare few programming languages that you can access absolutely everything with keyboard without ever having to touch the mouse. Alternatively if you enjoy working with the mouse, it too, is acceptable and can access all features and functions of the system as well.

. . .

I have been here since 2016 and have written over 4450 messages and coded and modified 207 Pico-8 programs online and have 54 projects in folders that are offline. I am currently working on a project I hope to post in the next week.

I have also downloaded 12553 Pico-8 programs written by others for offline examination. I have them neatly kept in a folder to this date.

I wrote and marketed videogames when I was 12-years old. I have access to a computer and coding every single day, and as many of you know I type about 135wpm. Life is keeping me extremely busy right now as I am helping my ailing Godfather and family.

Yet please don't talk down to me as if I'm a new user. Giving me advice for something you already know that I know. I don't like it. I don't think anyone would, and for that I am locking this thread. I'm sorry but that is what I am reading into here and I really don't want to get into another shouting match of replies with veteran users telling me how little I really know. It's disgraceful, it's beneath you, but you do it anyways.

You can find the very first post I made in Pico-8 HERE:


... I hope to meet on better terms when I finish my current Pico-8 product.

P#106912 2022-02-14 17:34 ( Edited 2022-02-15 04:43)

[Please log in to post a comment]