Hey folks,
Been toying around slightly with Pico-8 as a break from bigger projects, and I'm wondering if there will ever be an increase to the possible resolution of pico-8?
I dig the limits being used to force creativity, though I do feel 128x128p only gets you so far and no amount of memory-banking between carts can get around that for game-scale, it was the same thing I took issue with on both Gamebuino consoles.
To note I'm not saying like "hey we should have mega-complex 240p with 3x more sprites and 90 more colours so we're basically just on a snes", but I do think even just an upscale to 160x144 would help so much. I'd looked at alternatives but clearly the community and scale of potential support and resources is here in pico-8. As much as I'd like something like the C64 res of 320x200, I think even just the Gameboy 160x144 on some kind of Pico-8+ with the necessary memory increase, maybe a tiny bit more for graphical allocation, would be great.
I mean I don't care too much for tic-80's widescreen option, but otherwise it's literally like 8p more on the vertical compared to pico-8. I think I aim for Gameboy-res just because it's an identifiable scale that has a lot of standardized examples from when it was an actual working resolution, compared to 128x128
Resolution increase or adjustment ? Never. You should watch ZEP's introduction, "Pico-8 And The Search For Cosy Design Spaces."
There is picolove -- https://github.com/picolove/picolove
but I don't know if that lets you mess with the resolution out of the box. You may have to patch it first.
As far as working within 128x128.. I know it sounds counter-intuitive but try experimenting with things like borders and letter-boxing. For whatever reason, framing your visuals in certain ways can actually make it 'feel' roomier, even as you're using up some of that screen real-estate.
Well I'm not trying to make things roomier, more just that if I try to communicate any greater detail (e.g. combining sprites to form 16x16 enemies or a player) then I just don't have the space to give them warning of an approaching enemy or something, e.g. like Sonic the hedgehog on the Game Gear where you had no space for visual warnings or player response to in-game threats
Well, in environments like PICO-8, you're meant to work within the constraints, much the same way devs did for the OG GameBoy and whatnot. I see your point and all (160x144 is decent and a bit more expressive), but have you thought about a different approach for communicating the threat? If you have space in your sound banks, why not a boss jingle? Or if you're not using the lower half of your sound, you can use it to get more graphic memory.
There are also various attempts to compress graphic data into strings, which then gets decompressed at runtime to address more graphic memory than what is available. They should be around the forums. Not sure which is most efficient, easy on tokens, or easiest to learn, though...
8192 tokens is quite a bit, but limiting enough to make you really think about what you're trying to accomplish with your game.
It's entirely possible that your game idea has simply outgrown the limitations imposed by PICO-8. And that's cool; it means you've put a lot of work into your idea and it's ready for the next step.
@enargy is right on the money with LÖVE, it even uses Lua just like TIC-80 and PICO-8, though with a different framework API. It's a general purpose 2-D engine that can adapt to whatever you need it for. It's next on my list of engines to learn, for this very use-case!
It would be nice to have a config that lets you override the pico-8 limitations. That way you could experiment with games outside it's scope but still be able to use it's built-in toolset. Perhaps as a way to balance this, they could make it so that a user would have to set their pico-8 to the same configuration in order to play that game.
Also, if pico8 makes you feel confined, take a look at TRS80 games, which had absolutely no ability to make graphics color and still had really good gameplay. Basically, they had 2 or 3 special characters that were solid blocks and that effectively made a screen of approximately 64x64 monochrome resolution. There's some good games there.
Instead of thinking of visual representation and accuracy of said visual representation, think of ways to convey that same representation in other ways than visual. i.e. you can use text if a blocky char picks up a single pixel and says, "ahhh, my favorite drink!"
There's more than one way to solve a problem than throwing more graphics and resolution at it. We've gotten to the point with modern gaming that it's considered 'bad' graphics if it's even the slightest bit abstracted, which is a shame.
Not only this, the higher the resolution, the more workload you have in front of you to do that work of detail.
So getting down to something that's 'just' enough but not 'too much' is rather enjoyable. Nothing feels like it's undoable, but there's not so much void to fill that it feels achievable to get something made.
Just my two cents.
The only thing I don't like about the square screen is that every single device is designed to watch movies, therefore we have widescreen as standard now, but that's a subject for an entirely different rant...
If resolution were to be increased it would have to cut from somewhere.
As the screen is 128x128 taking 8192-bytes, here are three ideas I've had spinning in my head for a-while.
[1] Increase to 256-fixed colors (red-6 green-6 blue-6) via changing the screen resolution to 64x128 where one pixel appears as 2-pixels wide. Takes 8192-bytes.
[2] Increase the screen resolution to 256x256 but then you only have 2-color choices for pixels, black and white. Takes 8192-bytes. As most of my original early GWBasic work and art are B&W, I would get a lot of use out of this. :)
[3] Change the resolution of the screen to 256x64 pixels (wide-screen). No change in colors, still 16-choices. Takes 8192-bytes.
@Xii had quite an interesting suggestion. Double-frame. Very unique. You run your cart at 60fps. Then draw a frame, then draw ANOTHER frame right on top of it. It blends the colors (black+white=gray) and the cart slows down to 30fps to compensate for the blend. Marvelous idea.
. . .
Now those of you wanting a 4x3 display today, it can be done. Take your 128x128 resolution and create a software resolution of 128x96 at the top where the bottom 97-128 pixels can be a custom set of controls you draw and design for mouse and Android screen touch.
Here is some code for that to get you started:
It sounds like the only options are horrendously awkward compromises. I can respect Pico-8's limits are for creativity, I just think maybe they're a bit too limited, at the very least for my taste.
I've moved on to PixelVision8 now anyway. Much more customization without losing the vibe which fits my taste.
You Could also try Pyxel. It's a fantasy console similar to pico-8 except that you write python instead of Lua. I've been playing around with it lately in an effort to get more comfortable using python. The API is almost identical to pico-8's. It doesn't have any memory limitations at all and the screen resolution is specified at the top of your cart code. The color palette is also fully customizable. It has all the same tools as pico-8 (tilemap editor, sound editor, sprites, etc) but it also makes it very easy to use whatever sound/sprite editor that you want if you don't like the included ones. I believe that it also lets you easily generate executables for sharing your carts but I haven't tried to do that yet. It works less like an emulator and more like a library/API though. You can include it in other python applications or even use it directly from your computer's terminal if you want which I think is pretty cool. Overall, I still prefer pico-8 but Pyxel is a nice alternative for when you want to break the limitations.
Also, TIC-80 is pretty good and can have its resolution changed.
Well like I said I've shifted over to PixelVision8 for now. I'm using its C# version but it has LUA on the front for prototyping and whatnot. Let's you set presets so you can pick NES limits, Gameboy limits, game-gear limits etc, affects resolution, tilemap size, spritesheet size, max sprites drawn at a time, the sound channels available, colours per sprite and a few other things.
I'm here personally because of a few things.
[1] Post your program online from clipboard data via "save @clip." That totally rocks in so many ways.
[2] Export to Windows EXE, HTML, JS, Mac, and Unix file minus your sourcecode. Maybe even Android APK before time. That'll cinch it for me.
[3] Splore. Not just play what's in the roster but organize 'em too. Favorites folder, search, etc.
[4] Load and save online data via CSTORE() and RELOAD(), up to 12288 bytes a pop - and you can have multiple files. Superb.
[4] Huge community. Have you counted the number of posts there have been in Pico-8 since its first arrival ? If not hundreds, thousands.
So - yeah, You guys ... we'll see how long you work with the wannabees. Ater a-while you may come right back here. :)
Hey it took me years to realize Pico is the best way to go for my code and projects. Maybe you'll get comfortable in the other lingos. Who knows ?
Sure we want this, they want that, etc. Maybe. In time. But isn't Pico-8 a great engine TODAY as it is ?
Well my bigger projects would be in Unity or eventually Godo once I can be bothered shifting to that for bigger 2D projects, but in terms of fantasy console stuff I think I wanted to recreate limits of actual older systems without either using extremely railroaded game-makers (e.g. GB Studio) or having to actually code them like they would've been done. So atm doing Gameboy-limit stuff in PV8 has been good fun. I can see why people like Pico8 for what it's worth I just don't think I'm looking to box myself into its limits specifically.
If you don't like the limits, then pico-8 is probably not for you as you have said. For me, having limits is one of the main reasons why I use pico-8. Before I used pico-8, Unity3D was my favorite tool. However, after using unity for a year or two I started getting overwhelmed by the complexity of my own projects and wanted to take a break and return to the basics and make something simple. I don't like having so much overhead when I just want to make small (relatively)simple things. I still use unity occasionally for bigger 3D projects(mainly VR right now), but it's nice to come back to the pico-8 environment where everything is pretty much as simple as you can get while still making it easy to just jump into a new project. Having the limits is what makes pico-8 special. I like to think of it as my game development vacation spot. A place I can return to every now and then and just sketch out ideas and try something new without having to dig through massive APIs or spend hours trying to get the settings just right to achieve the desired effect.
I can't really explain it but there is also just something about pico-8 that makes it absolutely perfect. No other fantasy console I have tried has achieved the same feeling that zep does with pico-8. In my mind, TIC-80 achieved a closer level of perfection than all the other pico-8 inspired fantasy consoles but it still fell short and it just doesn't have a community nearly as good as pico-8's.
While it might always be nice to make the resolution a little bigger, the map a little bigger, and relax some of the memory constraints,but that would be going against pico-8's mission of keeping it simple.
I don't want pico-8 to change much from the way it is now. there are a few minor tweaks that could be made but they don't have anything to do with the artificial limitations. If I really wanted to break the limitations, I would probably just learn SDL and make my own "pixely" game engine.
Well I do like limits, I just perhaps don't like Pico8's limits. I'm not put off by more complex projects and engines per-se, I have to use those in other projects and I'm used to it, but I saw fantasy consoles as a way to invoke designs of prior consoles, so for me being able to recreate the limits of the NES or Gameboy or Master System is a good thing, which is why PixelVision8 does it for me. It's not a finished product yet but it works really well.
Twould be nice to have no limits, Traslogan, but then ... I would never get anything done. :)
Took me 12+ years to write my own RPG Maker years ago, and I think the only reason I finished it for release was the fact I was finally running out of memory writing it.
Pico continues to grow. That's another reason I'm here. Some of these free or even not-free alternative fantasy consoles may not be growing as much or even at all.
Yes, I took a look at a few of 'em. Just ... not very versatile, not very diverse. And no promise of compilation to EXE minus source. That's important to coders right there.
@zep may in time give an option in time to remove limitations, unlimited graphics/memory, ability to import Mp3s and the like. But right now, it truly is a Fantasy Console and ... if I may coin his phrase.
It is cosy. :)
Nothing wrong with more participation in the fantasy console space. It's not a zero-sum game, and it's nice to see them implemented in other languages.
I try to think of it in terms of choice or flavor. People don't agree on flavors and yet there's no fighting, because we understand it's a subjective experience.
Writing games is the same thing. Use whatever makes your ideas come to fruition, and embrace it.
I'm still using PICO-8 but I would like to try LÖVE2D, pygame, and maybe others. I think PICO-8 is good for prototyping. If it's still fun at 128x128 then it's probably good enough to build on. :)
Although I'm not using fantasy consoles atm whilst I focus on my dissertation, I think PixelVision 8 is where my personal flavor of fantasy console lies. I like being able to set it to emulate Gameboy limits or NES limits and more when I please for different projects, but still gives me nice limits and has a good retro design to it where I still have to worry about 8x8 sprites and limited sprite capacity etc
I'd be very surprised (and a bit disappointed) if Zep ever changed the fundamental limitations of Pico-8. The limits are Pico-8. It's what makes it Pico-8 and not just an oddly packaged graphics library for Lua.
(But, ... I wonder if maybe one day there will also be Pico-16? We can always hope.)
Zep experimented with Pico-16 and rejected the idea!
See the very interesting talk linked from https://www.lexaloffle.com/bbs/?pid=67244#p
[Please log in to post a comment]
