Mmmm … its in a sub-directory called
src/utils but these are impossible to see in the Arduino IDE. I actually use VS Code to develop these games - the basic Arduino IDE doesn’t cut it for me. You can probably find the file using Windows Explorer and change it using Notepad.
Mmmm … its in a sub-directory called
I try to caution people (possibly including you) about using subdirectories with Arduino sketches, whenever I see it done, for this very reason. Now it’s returning to bite you.
Its not biting me!
Well, it wasted a bit of you time to reply, and it’s causing difficulties for others.
You probably have but alas I might have ignored you.
I develop for the fun @vampirics and I get out of building games we like. I distribute our games in a compiled format for everyone to enjoy.
I am not going to limit myself to a restriction imposed by a half-baked IDE like the Arduino one. If someone wants to compile it themselves, they are welcome to but at the same time they need to acknowledge that I developed it my way. If they cannot compile it first go then I am happy to educate them on why the game is structured the way it is (if they care) - I don’t see it as ‘biting’ me.
It would help if the link to the compiled game, in the first post, wasn’t broken.
Ha … time to get off my high horse. Anyhow, fixed now.
The flaw isn’t with using subdirectories, it’s with using the Arduino IDE.
The Arduino IDE is a substandard IDE that’s incapable of doing basic things one would expect from a text editor, let alone an IDE.
Expecting people to inconvinience themselves because of the software’s shortcomings is unreasonable.
Software exists to accomodate humans, not the other way around.
Using an alternative editor like VSCode or Notepad++ avoids the ridiculous limitation with ease.
Then I suggest that to avoid the possibility of repeatedly having to deal with queries by inexperienced people, using subdirectories be treated similar to, say, removing the USB code:
Make it apparent and clear in any announcement or documentation that not all of the sketch’s source files will be visible or editable using the Arduiono IDE and explain why. (Assuming that it’s open source.)
The two situations aren’t really comparable.
All users are affected by the removal of the USB stack,
whereas using a
src file only affects people who want to edit the game’s source code or (more rarely) people who need to edit the game’s source code.
This incident falls into the case where the code doesn’t work “out of the box”.
Such incidents are very rare - this is probably only the first time I’ve seen such a situation occur.
(Also it could have been avoided had the code on the
master branch not needed editing,
which is ultimately what the real issue is.)
If, on the other hand, someone were editing a game (either to use as a basis for their own game or to mod said game) then having them ask “why can’t I see the
src folder in the Arduino IDE” is an excellent opportunity to explain the pitfalls of the Arduino IDE to them (including why the file must be named
src) and recommend a better editor.
If someone is modding or writing their own game then this would be doing them a great favour.
I’ve seen it a few times in the past.
That’s assuming someone responds with an answer in a timely fashion. It can’t hurt to make the answer available in the sketch documentation in anticipation of this.
There’s no need for a folder or subfolder to be named
src for a sketch. This is only for libraries, where it is well documented.
Yes there is.
.cpp files only get compiled if they’re in the root folder or a folder named
.cpp files in any other folder are ignored.
I learnt this the hard way - by getting bitten by it.
I keep the PR that introduced this behaviour bookmarked:
If this weren’t the case I would use multiple folders in the root instead of stuffing them into a
I expect this would be true for many other programmers as well.
OK, I stand corrected. I was only thinking of
#includes. Automatic compiling of anything in a folder other than the root is probably a side effect of the mechanism for compiling libraries, since using subfolders is not expected for sketches, as witnessed by the IDE editor’s inability to handle them.
If the people in charge of Arduino are not expecting people to divide their code into subfolders,
I would seriously question how much experience they actually have with programming and perhaps even their competence.
At any rate I think we’ve probably disected the issue enough,
we should probably let sleeping dogs lie.
I’ll just end with what I’ve said in the past. The Arduino system wasn’t meant for serious programmers or even those with intents to become one. It was intended as a way for hardware beginners, “hackers” and artists, with minimal or no software experience, to relatively easily get a (usually simple) microprocessor controlled project up and running with a low amount of programming effort.
Such a project would generally consist of a single or a few .ino files in a single directory and no .h .cpp or .c files. The Arduino build process was designed to accomplish this by eliminating the need for much of the set up involved to compile a standard C or C++ program, such as a “make” file, header files and
#includes, and function prototypes. This, along with an extensive collection of libraries for easily interfacing with various types of hardware.
The popularity, ease of setup and use, and multi-OS compatibility of the Arduino environment made it a good match for the Arduboy’s initial goals.
What percentage of Arduboy sketches are using subdirectories and how much of a hindrance do you think not having support for them in the IDE has been for most developers?
I hate to break it to you @MLXXXp but I designed the Arduboy around Arduino… for heavens sake its half of the name. Arguing that we shouldn’t even be using Arduino or complaining about it’s shortcomings isn’t necessarily wrong but it’s just the way things are.
On the contrary, I just pointed out why it was used for the Arduboy and why the Arduino environment should be used as designed.
Welp anyway, I changed the source code and it worked. Great game!
Fair enough, I hate to break it to everyone then. I’m sorry. I didn’t know any better.
I really prefer mbed and other arm platforms that the device shows up as a mass media device and you can just drop in hex files so it really doesn’t matter at all what ide you are using.
Personally I believe C* was a poor choice for that.
It had the inevitable effect of attracting experienced software programmers to hardware.
Had they chosen something like BASIC or Pascal they might have had less attraction,
but using a fabled language like C or C++ inevitably attracts the ‘hardcore’ programmers who like to mess around with CPU details.
(* As far as I’m aware they started with C and moved to C++, but I could be misinformed.
It might just be that they have a large number of people with C programming habits on their team.)
Adafruit’s CircuitPython will probably run into the same circumstances eventually simply due to Python’s popularity.
To really dissuade software programmers you have to use a GUI-based language like Scratch.
In truth, not that many.
I can presently name 6 developers who have used the
src folder including myself.
That’s counting teams as 1 rather than including individual developers,
and that’s counting
src folders specifically,
not including non-
src subdirectories that consist solely of
Given time I could probably find between 8 and 12.
However, that’s a bit of a loaded question because it depends on many factors.
The most important factor being how many people didn’t use subdirectories because they had problems with getting
.cpp files to compile when using them?
Had I not got lucky and discovered that GitHub issue I would still be having to shoehorn all my
.cpp files into the root directory.
The code for my Minesweeper game (lacking a
src directory) is a testament to that.
“I’m sorry I created a really popular handheld console that attracted loads of people and sparked the creation of over 256 games.”
Apology not accepted.
As the song goes, it’s too late to apologise.
(Don’t ask me what the song is, I only vaguely remember the chorus.)
That has its own set of problems too though.
The Pokitto went through a long period of having competing IDEs.
Eventually FManga made a new one that most people have adopted,
but there’s still a number of people clinging desparately to alternatives like Embitz.
Also you can’t programmatically eject the device in an easy cross-platform way.
Every platform has a different solution and it’s a real pain on Windows especially.
AVR chips on the other hand are easy enough to programmatically upload to and disconnect once you have access to a serial API and some documentation (and enough energy to be bothered to write the code to do so).
(That said, the talk of trying to put an ARM chip in an Arduboy shell has piqued my interest, I’d like to see someone try that just to know if it’s possible.)