Yes we are as soon as I am happy with testing it
Edit: there’s an old saying in Finland:
“Merge first, ask questions later”
We need a bigger TO-DO list:
- Make femtoIDE examples/tutorials.
- Remove all the old tutorials (PokittoSim, online IDE, EmBitz), alternatively we could move them to a new category in the forum
PokittoLib Legacy. - Fix MicroPython.
- Clean PokittoLIb.
- Remove PokittoSim (does not support C++ 17).
- Remove gamebuino/arduboy support.
- Remove the none working examples.
- Move all the functions From
POKITTO_HWtoPOKITTO_CORE.
I think examples could be a separate repo in the future
- What would FemtoIDE examples demonstrate? Java?
- I agree about moving the examples to their own repo
- Fixing MicroPython is already in the list of things I’m going to do, in the first post of this thread.
- PokittoSim will need fixing, not removing.
- Gamebuino/Arduboy support is partially gone already.
- The HW and CORE separation is useful.
- Change the c++ examples from EmBitz to femtoIDE projects, make getting started tutorials for femtoIDE (for new commers)
- How you are going to fix PokittoSim?
- You only remove the screen update function still lot to remove (Audio, GUI, Battery, Backlight, other support files).
- If we remove the simulator, why we need the separation?
I agree with deprecating the online IDE, but some people still use EmBitz so I don’t think we should deprecate it just yet.
I was halfway through suggesting this before I spotted your comment.
Though I already suggested this in the ‘to do’ list:
Hopefully we’ll eventually bring these back as separate libraries.
The problem with PokittoSim is that it means the work of maintenance is doubled for certain functions.
I think most people use the emulator anyway, so removing it might be an option.
(I’d definitely want to do a public vote on removing that though.)
I was saying we should depricate the getting started tutorials that use EmBitz not EmBitz it self.
Right now our best option for new commers is femto, FManga did a great job making it
In that case, I think we should still keep the tutorials,
but ‘lock’ them and move them to a designated ‘archive’ section to make it clear that they are only kept for reference purposes.
Which reminds me…
Rather than completely removing the information about the deprecated screen modes,
I think it would be better to move them to a ‘deprecated’ section (in a ‘details’ block) so that the information is still available for historical purposes,
but it is clear that that functionality is no longer available.
If nothing else, these things are an important part of the Pokitto’s story (or history),
so it would be nice to keep a remnant of them rather than allowing them to degrade to word-of-mouth stories.
Being a bit of a newcomer to the community and pokitto development I went through all the various tutorials using the various IDE options (back before my windows machine started having issues) and when @FManga suggested trying FemtoIDE due to my issues with the SD card access it was the only one I hadn’t tried and ended up being by far the simplest and easier setup. Download the appropriate zip file and run it. The best part is (coming from mostly Arduino development) it seems perfectly content to let you use an external editor and jump back to it for building. The only real improvement needed is the compile output history getting cropped with all the lengthy warning messages, any warnings/errors in your project’s code could easily get buried, so -1 for that.
I give it a +10 for built in debugging support using the emulator and gdb, with the option of also using j-link for hardware debugging. I’ll give it another +20 for the detailed breakdown of Flash and RAM usage when clicking on the elf file (that alone is what convinced me to not look back on the CLI build method).
That doesn’t mean it should be the only option (much like people are also free to not use the Arduino IDE at all), but it does greatly simplify the development process from creation to full release. The simplicity, features, and benefits of FemtoIDE seems like it would be the best bet for centering all future tutorials around, especially since there’s very little involved with the setup and use of the IDE which allows the tutorials to focus more on the actual coding. This in turn makes it easier for people to use the environment of their choosing, and there’ll always be help from the community to get any particular setup working.
All in all it’s definitely another amazing product from @FManga. Now if we can just convince him to make a game.
While the emulator environment should be the final goal for developing programs for Pokitto,
PokittoSim is currently the most productive way to make programs. That is mostly due the excellent debugging features in CodeBlocks. It is also the only environment where audio works correctly outside HW.
I think that’s probably subject to opinion,
which is why I’d ideally like to do a public vote to gather people’s opinions.
Does the simulator not work in FemtoIDE?
If so, that’s another good reason for being rid of it.
Requiring people to use more than one IDE if they want to compile their game for both hardware and simulation is a bit much.
I don’t know what’s broken yet, I’ll have to see when I get to it.
True, there are some things that could still be removed. I’m not sure if Audio is one of them, though. I was under the impression that it does things that can’t be done otherwise, but I’m not sure as I haven’t gone through that code yet.
I’m assuming we won’t remove the simulator, at this point. Especially since I want FemtoIDE to be able to compile games to PC and webassembly.
Just to be clear, I don’t intend to deprecate any IDEs, except, maybe, the online one. Only if it really gets in the way. People should be able to code in whatever environment they want.
We do need to make sure the tutorials/examples get updated as well, but that might be just beyond the scope of this cleanup. Got to draw the line somewhere, and if the examples get moved out to their own repo, then just deleting them in my PR would be good enough.
Definitely!
Agreed about the maintenance overhead, but it’s going to be worth it. Debugging with the simulator is better/easier and being able to run our games fullspeed in the browser would also be a good option.
I think having legacy and current documentation just makes things more confusing. We should update the tutorials and bury the dead code.
If you really want to document things like screen modes that have seized to exist, I’d suggest a magazine article, where it won’t show up in search results for people who are looking for things that do exist. That would also be good to explain why it was removed, what the suggested alternative is, and how to migrate projects to the new lib.
You were looking for article ideas, right? What better way to record Pokitto’s history than to put it on paper?
Glad you’ve had a good experience with it so far! As for the output history getting cropped, a solution for this was implemented already and is on github. It will be included in the next release.
You actually don’t need to “jump back to it for building”. If your external editor supports running shell commands, you can send commands to an open FemtoIDE project in the background.
It’s been a while since I’ve used this feature, but off the top of my head it was something like this:
path/to/IDE projectname compileAndRun
It doesn’t, but simply because FemtoIDE does not include an x86 GCC. Instead of having an x86 and an ARM GCC, I’d like to switch to a single Clang.
People should be allowed to use whichever IDE they want, yes,
but we shouldn’t provide explicit/official support for more than a handful,
otherwise things could get out of hand.
We should pick only one or two IDEs as ‘officially recommended’ IDEs and provide support (tutorials, examples) for just those IDEs.
When I say ‘deprecate’ I mean not providing explicit/official support for said IDE.
If people want to go out of their way to make other IDEs/environments work then they’re free to do so,
but the ‘official’ support should be more focused towards a select few.
Including the EmBitz ones?
(Assuming they even need updating.)
Having legacy tutorials in a category specifically marked ‘legacy’/‘archive’ doesn’t seem that confusing to me.
Especially if said articles are locked so that they cannot be ‘bumped’.
As for the screen modes, part of the reason for keeping the information and marking it as ‘deprecated’ is to pre-empt people starting threads asking “what happened to screen mode X?”.
If it’s documented that the screen mode used to exist and was removed then that saves people the trouble of having to ask about it.
Me personally, only articles about C++.
Is this documented somewhere?
I’d certainly be more interested in using Femto as a command-line utility that just handles compiling.
(That’s more or less what I was aiming for with the Lua scripts a while back.)
Among other reasons, I’m rather attached to my current editor and trying to cut down on the number of code editors I have installed.
To think all it took was a little
That’s an awkwardly accurate representation of me at work 
Took “Merge PFFS and SDFS” off the to-do list, for now. Looks like the existing libs still work with C++17 so I’ll go back to fixing other things I broke in the last PR (Mode 64).
Edit: Fixed Mode64, it was just a missing #define. Back to work on MicroPython.
I just noticed that reviews were requested but weren’t actually filled in/completed.
I’ve noticed this tends to be one of the features of GitHub that few people know about,
so I’m going to leave some info here:
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews