Log In  
Page:
1
2

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?

P#13816 2015-09-08 05:31 ( Edited 2016-06-25 23:53)

This would have to be changed at the core (replacing 30fps limit with 60fps and making it drop to 30fps instead of 15).

P#13820 2015-09-08 06:59 ( Edited 2015-09-08 10:59)

Great, I'd like to see it happen

P#13823 2015-09-08 07:28 ( Edited 2015-09-08 11:28)

I second that idea! Smooooth pixels!

P#13849 2015-09-08 10:43 ( Edited 2015-09-08 14:43)

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 :)

P#13850 2015-09-08 10:44 ( Edited 2015-09-08 14:47)

+1
...an additional 60hz option would be really great to have.

P#13865 2015-09-08 14:58 ( Edited 2015-09-08 18:58)

@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.

P#13926 2015-09-09 13:49 ( Edited 2015-09-09 17:49)

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)

P#13932 2015-09-09 16:43 ( Edited 2015-09-09 20:43)

And... yes! I think that is a good idea if devs could choose, via code, 30 or 60 FPS.
Retro style doesnt mean less FPS, I think...

P#15542 2015-10-18 15:13 ( Edited 2015-10-18 19:13)

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.

P#15543 2015-10-18 15:29 ( Edited 2015-10-18 19:29)

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.

P#22123 2016-06-02 18:16 ( Edited 2016-06-02 22:17)

it's marked as resolved, but i'm not sure exactly how or why that might be?!

@zep ?

P#22127 2016-06-02 20:05 ( Edited 2016-06-03 00:05)

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?

P#22132 2016-06-02 20:36 ( Edited 2016-06-03 00:36)

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.

P#22141 2016-06-02 21:59 ( Edited 2016-06-03 02:00)

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?

P#22163 2016-06-03 04:21 ( Edited 2016-06-03 08:21)

Sorry, but with 128px in both dimensions, what do you want to move that fast? An object moving softly at 60fps would leave the screen after two seconds... You wouldn't get sub-pixel positioning with 60fps...

P#22167 2016-06-03 05:28 ( Edited 2016-06-03 09:28)

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. :)

P#22171 2016-06-03 05:56 ( Edited 2016-06-03 09:56)

I'd really like to be able to use 60fps. I can't think of any good reason to limit it at 30. 60 would look much smoother. Most old systems ran at 50 or 60, so having the limitation makes the Pico-8 feel less like a retro machine.

P#22172 2016-06-03 06:03 ( Edited 2016-06-03 10:03)

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.

P#22174 2016-06-03 06:37 ( Edited 2016-06-03 10:40)

@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.

P#22175 2016-06-03 08:24 ( Edited 2016-06-03 12:24)

@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".

P#22226 2016-06-03 23:58 ( Edited 2016-06-04 03:58)

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.

P#22237 2016-06-04 02:14 ( Edited 2016-06-04 06:14)

@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:

https://youtu.be/nntoT-5BWqM?t=7m23s

(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:

http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm

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.

P#22242 2016-06-04 05:36 ( Edited 2016-06-04 09:44)

I'd still love 60fps too

P#22243 2016-06-04 06:24 ( Edited 2016-06-04 10:24)

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".

P#22244 2016-06-04 06:26 ( Edited 2016-06-04 10:29)

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?

P#22251 2016-06-04 08:07 ( Edited 2016-06-04 12:07)

@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? ;)

That said, it would be interesting to see if you can double the framerate e.g. by modifying the exported Javascript or the PICO-8 binary.

P#22252 2016-06-04 09:23 ( Edited 2016-06-04 13:23)

@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.

P#22260 2016-06-04 11:10 ( Edited 2016-06-04 15:45)

Am I wrong in thinking it's possible to explicitly call flip()? Would it be possible to call it twice per 30fps _update() in some way?

P#22262 2016-06-04 12:18 ( Edited 2016-06-04 16:18)

@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.

P#22264 2016-06-04 13:19 ( Edited 2016-06-04 17:19)

@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.

P#22267 2016-06-04 13:39 ( Edited 2016-06-04 17:39)

@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.

P#22268 2016-06-04 13:55 ( Edited 2016-06-04 17:55)

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!

Windows:

At offset 3F84: change C1 FA 06 to C1 FA 05
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

Linux 32bit:
At offset 7652: change C1 FA 06 to C1 FA 05
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

Linux 64bit:
At offset 7F11: change C1 FA 06 to C1 FA 05
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 6211: change C1 FA 06 to C1 FA 05
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.

P#22269 2016-06-04 14:38 ( Edited 2016-06-04 20:47)

@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?

P#22271 2016-06-04 14:46 ( Edited 2016-06-04 18:55)

@gamax92: Woo, you rock! The cycle count is still the same number per flip, so I'll have to keep my usage below 0.5, but at least I can play with it now! :D

Cheers, mate!

P#22272 2016-06-04 14:52 ( Edited 2016-06-04 18:52)

Nice work gamax92!

I guess it's not possible to POKE the change temporarily?

Anyway, for Mac owners...

Mac OS X:
At offset 6212: change C1 FA 06 to C1 FA 05

P#22276 2016-06-04 15:26 ( Edited 2016-06-04 19:36)

I second the 60 fps option, and from time to time I bitch about it here. The great thing about old games from the golden age of video games is the high frame rate. I just don't get why Pico-8 is running 30 fps.

P#22423 2016-06-06 15:29 ( Edited 2016-06-06 19:29)

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!

P#22430 2016-06-06 17:51 ( Edited 2016-06-06 21:52)

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.

P#22444 2016-06-07 02:25 ( Edited 2016-06-07 06:26)

Doubling the resolution quadriples the color count. These are the modes I have in Nano89, which all use exactly the same amount of memory:
256x256px monochrome
128x256px four colors
128x128px 16 colors
64x128px byte based rgb

P#22446 2016-06-07 02:49 ( Edited 2016-06-07 18:34)

That's I was looking for, "halves the bits per pixel". Squashed pixels probably are quite nostalgic for a lot of people.

P#22447 2016-06-07 02:57 ( Edited 2016-06-07 06:57)

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.

P#22506 2016-06-08 08:03 ( Edited 2016-06-08 12:03)

Not sure how the PocketCHIP works at all but there's also an entry in config.txt that changes the base sleep per frame: frame_sleep_ms

It's set to 5 but say you can try 20 for helping to save power for things like laptops.

P#22530 2016-06-08 17:09 ( Edited 2016-06-08 21:09)

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.

P#22572 2016-06-09 18:03 ( Edited 2016-06-09 22:03)

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.

P#22909 2016-06-15 04:11 ( Edited 2016-06-15 08:11)
P#23528 2016-06-24 01:41 ( Edited 2016-06-24 05:41)

Nice :)

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.

P#23529 2016-06-24 01:45 ( Edited 2016-06-24 05:45)

Maybe someone can clarify this bit for me: Will code that ran at 20% CPU (stat(1) = 0.2) at 30 fps run at 40% CPU (0.4) at 60 fps? Do typical games run pretty hot or is there plenty of headroom at 60 fps?

P#23532 2016-06-24 01:57 ( Edited 2016-06-24 05:57)

According to this, I think my reaction to this news is:

RECTFILL(FELICE.X1, FELICE.Y1, FELICE.X2, FELICE.Y2, 11)

In other words, color me happy. :D

:
:
:

Why can't I just say things normally...

P#23537 2016-06-24 05:19 ( Edited 2016-06-24 09:21)

Yay!

I wonder if you can use _update and _update60 at the same time?

P#23538 2016-06-24 05:21 ( Edited 2016-06-24 09:23)
Page:

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 22:54:18 | 0.040s | Q:86