As I'm working rather deeply in coding for the next Sorcery project, I am running into a nasty little thing that when the screen scrolls it jumps back when the cursor is able.
@zep: Suggest using CTRL [ and CTRL ] to shift the viewpoint of the source-code to center it if need be and reset to zero when ENTER is hit.
And before you think my tabs big they are not. I use 2-spaces per indentation so this can visually be a problem with complex and deep level nesting.
I know this doesn't help with your question, but...
An oft-repeated piece of wisdom among long-time programmers is that if your nesting pushes too far to the right, you should take it as a sign that it might be time to break out some of the outer-to-mid-level nested stuff into its own functions.
This, because when you get nested that far to the right, it implicitly means that your function is also very long, and that can lead to what I think of as "outer logic blindness" where you stop seeing what the outer levels are doing with the inner levels and start to miss outer-level logic bugs and such.
It's not a hard and fast rule, and may not apply here, and is usually a lot more important on teams vs. solo programmers, but I thought it was worth a mention.
I've been delegated the primary programmer on this project so no worries about the code not being understood.
They're doing all the art, logos, music, sound, opening pages, and screens - so this is my job.
I remember GFA had this ability though.
You could hold CTRL ] and the view would actually shift the source-code display 2-characters to the left. It was refreshing to actually write some decent nested code without the viewer going wonky on me as most languages do.
And in this particular case - no, there's no easy way I can see to break it down to smaller modules as there are multiple conditional checks and loops that all need to be there for the final status and execution of the code.
The good news is this is the most tedious and difficult routine in the whole of it. Once I get this its downhill sailing.
In some circles, you'd be told you're indenting too much and it's a sign you need to break the task up into smaller parts. :P Not sure how applicable it is to your code.
Realistically we all know code gets messy.
An odd thing I've noticed is literal tab characters show up as single-width spaces in the PICO-8 editor. A configurable tabstop option (defaulting to 2?) would be nice, and it could reuse code from the other double-width characters in-editor. Nope, you can do this in config.txt, under tab_stop. Thanks to @Felice for the tip!
Even more realistically, one can use an external editor and reload the cartridge when they go back to PICO-8. Or, write your code in a separate file and "#include" in your cartridge during development.
Then you'd copy-paste the code from your file before release. It's not perfect but it'll work! Nope, PICO-8 is smart and does this on export.
It's configurable in the config.txt file. Type "folder" in pico-8 to get to your 'carts' folder and go to the parent folder from there. Set tab_width to 2.
I'm still pretty irritated that @zep didn't set the default to 2 when he introduced this option... *baleful stare at zep*
@Munro: Are you talking about #includes that are inside the lua file that you're #include-ing? If so, then yes that will break since #include is not recursive.
If you mean starting a new cartridge with an #include, you need to save it first, so it has a path to reference when it looks for files to include.
(see pico-8.txt, heading "#INCLUDE")
@zlg neither. I have a saved p8 with #includes to other files. I can export without error. When I run the exported application I get a "could not include #". Exporting itself is fine but running it throws an error. Are your exported files able to run?
I read the manual. It singles out pngs and binaries as being able to flatten #includes but not any other formats. (and bins don't seem to work either at least on windows)
I'd love it if pico8 could flatten all formats.
Wait, really? A file included with #include can't #include another file? That's... weak.
I mean, one level is infinitely better than zero, but still.
If zep's just trying to avoid infinite include loops, it's not that hard to have an include stack and check new includes against the existing stack. There are no conditional directives that can affect whether or not the parser reads an #include, so if it finds a loop, it's always going to be an infinite one.
I agree with you there, @Felice.
The top of my current Blitz project for instance:
Framework brl.d3d9max2d Import maxgui.drivers ' necessary for frameless window Import brl.directsoundaudio Import brl.wavloader Import brl.freetypefont Import brl.retro Import brl.jpgloader
Framework just means its the first INCLUDE file, the others IMPORT are include too. But if you look at them, they TOO have multiple IMPORTS in them so its imports within imports, especially brl.freetypefont. - Can't see any other reason why not to have this ability of nesting includes in Pico-8, except as you said to perhaps avoid an infinite loop.
[Please log in to post a comment]