I was wondering if it'd be possible to have 60 frames per second option added in future?
Right now Pico-8 runs at 30fps.
NES, SNES, Master System, MegaDrive/genesis could run at 60fps, if you programmed correctly. Otherwise you could drop to 30fps. Or if you lived in Europe you'd get 50/25.
MSX2+ computers could be overclocked through software to double CPU speed.
I'd like this so animations run more smoothly.
Maybe it's possible now through a POKE?
Doubling the fps would increase the system requirements as well. It would also break some carts if they do calculations in the draw loop. Which you should never do, but still. Changes like these could however be done without breaking anything if there was a version tagged to each cart; just run all carts compiled before v0.1.1 at 30fps.
For authentic old school feel though, _update() and vsync should be completely dropped and everything should be hardcoded to the FPS.
Ahh, the glorious days of PSX gaming where a big explosion would slow down the music and sound effects...
And who can forget Final Fantasy 9 and the 12 hour Steiner sword quest. The game runs at 83% speed (50HZ vs 60HZ), but the clock still runs the same, so actually, you have only 10 hours to get the sword in the PAL version :)
@John: Internally the system is cycle count limited based on functions and opcodes executed. Technically, it would be relatively simple to make the game run at 60 FPS, and just half the maximum cycle count. That would make the only increase load the additional 4bpp frame buffer to display buffer copy.
A switch in memory/an extra function to change the flip() and _update() frequency would be the best solution imo. The cycle speed would remain the same, so it would be harder to maintain the full framerate but would benefit certain types of games greatly.
Might also be better for variable framerate games, since dropped frames would only duplicate the previous frame over 1/60 seconds instead of 1/30. (though I haven't seen any games forego the normal draw update setup yet)
Throwing my two cents here:
I really could care less about the framerate, 30 fps is just fine for actiony things. Look at Nuclear Throne.
But for the bunches of people asking for that, a switch in the Drawstate bank would probably be optimal.
Did anything ever come of this? There's a visual trick I'm playing with that would benefit a lot from a 60hz refresh.
I don't care if cpu frequency doesn't change. I can deal with having only half of the cpu cycles per frame. That feels like a reasonable (and realistic) tradeoff. Had to bite the bullet once and make everything 2x as fast because 30hz wasn't cutting it on a snes game. :) Painful but worth it.
Would this change mean that (some new) Pico-8 games no longer run on a raspberry pi or a pocket c.h.i.p? It would be a shame for kids playing on those might start to miss out.
I guess what I'm asking is what are the performance requirements of the virtual console in host system hardware terms, both for the current 30FPS and this proposed 60FPS?
I guess zep is the final word on what perf implications there are, but if the only change is that _flip waits up to 16.67ms instead of 33.33ms, and otherwise the number of "cycles" per second stays the same, then the only additional overhead would be 30 additional backbuffer flips per second. That should be pretty cheap, even if it's a copy, considering the low resolution.
Also, PICO-8 is, after all, still an alpha. I think it would be unrealistic to expect it not to change in backwards-incompatible ways at times. But again, that's zep's call.
I think the choice to use 30Hz is a really odd one and I would really love the possibility to use 60Hz.
30Hz could still be supported by some simple way to set the time for both the _draw and _update-functions, and I guess it would be easy to detect old carts and automatically run them with the old update-rates?
Things do more than just move in a straight line at 60fps. They could go in circles, they could animate, etc.
You should try not to assume that other people will do with a feature what you would do with it. Letting people wander in and out of the box is how innovation happens. :)
In my opinion, Pico-8 is simply the wrong platform, if you want to go for 60 frames. Believe me, I'm experienced enough to know what you can do with which feature and 60 fps don't bring any benefit to a screen of 128x128 pixels with 16 colors. Not worth breaking the existing machine.
@SunSailor: It wouldn't have to break anything if you as a developer was given the option of 30 or 60 (and perhaps other refreshrates aswell), and it could simply detect old carts and automatically run them in 30 fps.
60fps would open up more options for developers.
@SunSailor: There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy. Again, you shouldn't assume your notion of what a feature is useful for is remotely definitive or comprehensive.
However, to humor you, I'll offer up one very easy example of the usefulness of 60hz: A driving game. The smoother the gameplay, the better the experience. Driving games need not be demanding, either. Old games like Pole Position, Buggy Boy, or even old top-downs like Rally-X, should all be performant enough on a PICO-8 to run at 60hz and doing so would improve the experience for the player.
This is to say nothing of demoscene-style programs, which seek to entertain through awe rather than gameplay. Consider a PICO-8 contest: See who can come up with the most impressive visual demo running at 60hz. That would be fun and would probably produce some interesting results and possibly some useful tech for others to use in their own apps.
Speaking of which, I think you'd do well to go watch some demoscene stuff, if you haven't before. It might open your eyes to what people can do that you never considered or imagined. It always does for me, and I usually consider myself to have been there and done that for almost any definitions of "there" and "that".
IMO 30 Hz is just another challenge of the platform. I don't think anything is unplayable because of the 30 Hz refresh, similarly to the resolution hardly being a real limiting factor if you just use the pixels smart enough.
Also, you have to think if the need for 60 Hz is simply just so that the code can be slow enough to drop the framerate back to 30 Hz. :) Can't think of any demoscene-style thing that would look amazing at 60 Hz but suck at 30 Hz.
I do agree, however, that a smooth, stable vsynced 50/60/whatever Hz scrolling is the sexiest thing about retro platforms. Not sure if it is even possible anymore with weird screen refresh rates and OS multitasking and so on. And I do agree 15 FPS is a bit too slow for action games.
@kometbomb: Tons of demoscene stuff does what they call "interlace", but since old home computers like vic-20 and c64 actually output 240p60 and not 480i, it isn't true interlace, it's just flickering back and forth between two images at 60Hz.
They use it to create more colors by blending the ones in the hardware palette. This is how most of the semi-realistic looking images on c64 are created. A c64 doesn't otherwise have anywhere near the colors needed to portray a face clearly. See here, for instance:
(You can't see the flicker on youtube because they tend to post-process the video with a temporal blur to make the blended colors visible to those viewing at less than 60fps on youtube.)
See also here, notably IFLI and SHIF modes:
Kinda surprised here that anyone's arguing against 60Hz, since it's always been a part of what we now call retro hardware and which PICO-8 is mimicking. I don't think any of that era's machines ever output at 30Hz. I mean, if you guys want to run at 30Hz, then run at 30Hz. Why limit others from what they would like to do? I could see not wanting 120Hz or 72Hz because that's not consistent with the model hardware, but 60Hz is totally in line with it.
Simply because this alters the way Pico-8 runs at the moment. You would need a "go60hz()"-function to stay fully compatible with existing cartridges. That's the one and only reason and I don't see any use for such heavy altering - which would mean a complete new hardware generation. For a successor of Pico-8 - you're welcome, maybe 32 colors, a bit more screen size and definitley much, much bigger cartridges. But not for the existing "generation".
The existing generation is still in alpha. You can't reasonably expect things to be set in stone already. But that's beside the point.
We already have a register to change the x- and y-resolution, or to add x- and y-mirroring. Hardly anyone knew about it until someone wrote a demo for it. That ability hasn't been breaking anyone's game.
Zep could add another bit to the register that says refresh is 60Hz. From your point of view, there's no difference. Old games run unmodified. New games can set the bit. Or use an API call. But a real retro platform would just have them set the register directly. :)
I really don't get why you see it as "heavy altering". All it would be doing is firing off _flip() twice as often if the game asks to run at 60. Nothing else would change. At all. Why are you so concerned?
@Felice: Yes, that's about the only thing I had in mind that absolutely requires a high refresh rate (and, you could argue, a CRT screen, which also PICO-8 doesn't have).
Not trying to be annoying etc. and I do respect everyone's opinion on this but: the discussion about wanting to limit what others would like to do is kinda silly in the context of a very limited fantasy console platform, isn't it? ;)
@kometbomb: Actually, an LCD with lightboost enabled functions pretty much the same as a CRT. Same raster behavior, same persistence, same irritating dark-band artifacts if you try to film it. ;) If you dig oldschool display behavior and miss it on these smeary flat things we have now, definitely look into lightboost.
As for whether or not it's okay for people to want to limit what others can do on a fantasy console, I'm just saying it's not their call. It's zep's console. If zep doesn't want PICO-8 to be able to refesh at 60Hz, then that's his prerogative, but I don't see why anyone else should be trying to nix it when it doesn't even affect them.
For me, it would be fun to play around with PICO-8 at 60Hz. Isn't that the point of PICO-8? To have fun playing with pretend hardware? For everyone else, it makes no difference if it's added or not. Why be so negative about it? Just feels like the idea is getting wet blankets thrown on it for no good reason.
I'm not suggesting we add 1080p and 8 cores. I'm just suggesting we let it do something the consoles and home computers it's philosophically descended from could do 30 years ago.
@Felice: One thing I really "miss" about using a television with a computer is the RF interference buzzing. Well it was annoying but still. :)
Maybe people think making PICO-8 "better" means it is less special. And so their own creations are less special too.
@kometbomb: boy, no need to get personal! I can assure you, that my creations neither benefit, nor get harmed by 60hz. I'm just discussing, that it doesn't make any good sense to the Pico-8 concept and I brought valid arguments. Maybe some people here are simply to sold to the 60hz idea on the other hand?
But you're right that far, that lowering each restriction of Pico-8 makes it less a limited and thus interesting platform. There are projects to pick up the concept on a pure lua approach, without the Pico-8 infrastructure. Why not give those a try, there 60hz are no problem. If your project can benefit that much from it, maybe a more substantial lobby for it raises? Or try PyGame, which can bring a similar kind of fun.
@SunSailor: Ah sorry, I didn't mean that as an insult or anything. If anything, I would feel like that myself. The limits say to me something like "you can do this in a simple way" and if there are less limits it's more like "you should use this more complicated ~correct~ way to do things here's the manual it's on page 4543" and I would never finish anything because nothing ever stops you trying to do even better.
|it would be fun to play around with PICO-8 at 60Hz|
Well, lucky you! If you're experienced with a hex editor and know how to change one byte, for the low low price of $0.00 this could be yours!
At offset 357E3: change 3D 88 00 00 00 to 3D 44 00 00 00
At offset 4300A: change C1 E1 08 to C1 E1 09
At offset 2E805: change 3D 88 00 00 00 to 3D 44 00 00 00
At offset 3D926: change C1 E1 08 to C1 E1 09
At offset 30253: change 3D 88 00 00 00 to 3D 44 00 00 00
At offset 3ECE6: change C1 E0 08 to C1 E0 09
Mac OS X: (thanks matt)
At offset 40391: change 3D 88 00 00 00 to 3D 44 00 00 00
At offset 514E0: change C1 E1 08 to C1 E1 09
First patch puts it at 60fps, second patch adjusts the limiter, and third patch fixes stat(1)
Please don't release a cart requiring this tweak or an angry mob with pitchforks and eggs will assult your house and throw rotten tomatoes at you.
Patcher for Windows and I dunno ... bsdiff patches for Linux? may be generated upon request, it's annoying to create them.
@SunSailor: Thing is, you're still pretty much as limited as you would be at 30Hz. You can't do more work just because you can poke a virtual video register twice as often.
In fact, if you want to run 60Hz, you're actually imposing an ADDITIONAL restriction on yourself, which is that your update and draw have to run in half of the time. Seems like more of a challenge, not less. For me, that's where the fun lies.
I pose a question: what about people who choose to do more work per frame, but at 15Hz refreshes? Are they also violating the spirit of PICO-8 by not running at 30? They're doing an end run around the CPU cycle count restriction to get more complex AI, physics, or rendering. Isn't that exactly the same thing you're arguing against, except it's the CPU time that's doubled instead of the framerate?
I think Felice has a good point; if PICO-8 had a built-in optional 60 Hz mode that changed literally nothing else, it would be an additional restriction to use no more than 50% CPU time in your _update() function.
That seems like it would be a cool option to have without interfering with any existing functionality!
I like how the 60 Hz mode doesn't give your code more time to execute. IMO this way it's a very nice "realistic" tradeoff. :)
Perhaps it would be interesting to see higher resolutions as well, but in a similar way so a high resolution mode that doubles the resolution halves the color count and so on.
EDIT: Also, gamax92, you're a pretty smart guy.
I was just looking at picolove (implementation of pico8 in love2d) and noticed that picolove has a setfps() function.
That made me think that you could also dial down the fps, to something very low, for games that didn't require high screen refresh, such as Minesweeper, turn by turn RPG, etc.
I'm sure this would extend the battery life of a PocketCHIP for the games that did so.
Such functionality would be nice, and quite easy to implement without breaking existing carts. Just make it a part of graphics mode by adding two bytes which would give a total of 4 possible refresh rates 0:30fps (to preserve compatibility) 1: 60 (which is what this thread is about), 2: forced 15fps (usable when your cart sometimes drops to 15fps but not always and you want it consistent but can't optimize any further) 3:5 fps - for games that don't need that much refresh but need some cpu time such as strategy games.
But yeah, probably won't happen.
I bought PICO-8 to have some casual fun making 2D games (as opposed to my day job where I work on large, complex software) but I was kind of disappointed when I fired it up and saw that the games only ran at 30fps. I don't remember having any consoles as a kid where the games always ran at 30fps. The first game I remember playing that always ran below the display refresh rate was StarFox, and then lots more games once the 3D consoles started coming out (Super Mario 64 ran at 30fps, etc.)
It's still kind of fun to play with as it is, but like lots of other people who commented in this thread, I think 60fps would be a nice option that carts could enable by writing to some memory address.
It's good to see that the devs listen to the community for implementing features (especially if it's still in alpha, where features are being added).
It probably won't make a difference to a majority of users, but this does allow the "official" potential to be stretched a bit more.
[Please log in to post a comment]