Create a new project interactively
fxsdk new <name>
Create a project ready to build with an autogenerated tree structure in folder.
The Makefile is generic.
ressources ├── font.png ├── icon.png └── ... build.fx # and/or build.gc └── ... include └── ... src ├── main.c └── ... Makefile
% fxsdk new tetris-delux Creating a new project in folder 'tetris-delux'. Full project name ? > Tetris Delux Short project name (full uppercase, no-space and max 8 letters) ? > TETRISDX Build for ? -  fx-9860G II (Graph 35+E/Graph 75+E) -  fx-CG 50 (Graph 90+E) -  both > 0 Tetris Delux successfully created.
fxsdk build [-s]
-sto automatically send the g1a or g3a to a connected calculator (see below).
make all-(fx|cg) wrapper, for more standard command.
Avoid to precise FX or CG, according to the word used in the new project command.
Connect a calculator
Connect a calculator to debug. Using p7 ?
Send to a connected calculator
Send the g1a or g3a to a connected calculator.
p7 send -f# <name>.g(1|3)a wrapper.
Excellent! I've started working on this as a shell script (much more suited than C for this task).
The main thing I was not happy with until now was handling dual-platform projects (ie. build for both fx9860g and fxcg50). We discussed decent options, but this felt too rigid to me.
So I tried to refine this with a smarter behavior. Here's the idea:
fxsdk build-fxcreates the
build.fxfolder and compiles for fx9860g
fxsdk build-cgcreates the
build.cgfolder and compiles for fxcg50
fxsdk buildcompiles in all existing build directories
This way, you can change the platform whenever you want by just compiling in a new folder. If you start
fxsdk build but no build folder is present, you are interactively prompted for a platform.
When sending the file, you can use
fxsdk send-fx or
fxsdk send-cg to make explicit which method to use, but if only one build directory exists then you can type
fxsdk send and the associated method will be selected.
How does that sound ? 😀
We also need a configuration file somewhere to store details such as the name and internal name of the add-in, the icon, and the like. I think it will take the form of a list of assignments in the syntax of Bash, so that it can be loaded and edited easily.
So you want to remove this in the interactive command
Build for ? -  fx-9860G II (Graph 35+E/Graph 75+E) -  fx-CG 50 (Graph 90+E) -  both
Because the project can build nativelly for both (if we defined the draw functions for both in our program) ?
It's seems correct to me 👍 .
As I said in previous Issue on gitlab (I forgot to mention here), usually a configuration file is in YAML syntax (or JSON, but YAML is better human readable).
The file can look like this
name: full: "Tetris Delux" short: "TETRISDX" version: v1.1.0 ...
I think, because the images of fx and cg are always different, we can have 2 ressources folder :
At root directly or in sub folder of ressources folder.
And because the icon is unique, I think we can cut out from the configuration file.
I can either fully remove the platform selection, or offer to create initial empty build directories to avoid some interaction when
fxsdk build is invoked for the first time. Both are fine with me.
Having a configuration file in YAML is nice, but parsing it is a nightmare. I think this should be enough:
name="Tetris Delux" internal="@TETRISD" version="git"
And so on. (Note the
git versioning scheme, which would place a commit number or tag name in the version field.)
Yes, you need two resource folders, also
fxconv needs to be aware of the target platform to properly do its job. But I don't want to enforce specific file names for icons, especially since :
- There are two of them on fx-CG 50, and no "trivial" way to name them;
- The image format (thus the extension) is not fixed;
- You might not want to place them in the resource folders.
I think remove totally is better, because I imagine a case of someone create a fx project only, but latter, he want to extend to cg.
Okay for configuration in simple text file, KISS keep it simple, stupid 👍 .
I am sure you can build the generic Makefile to consider all icon extension format 😛 If there is only
And if gint only allow
.png, why someone create an icon with other extension ? So we can maybe force png format ?
With 2 ressources folder, I had imagined 1
icon.png on each => fix name problem.
To me it's not weird to have icon in ressources folder (in androidstudio it's like this).
But the idea of "in ressources folder there should only has images used in program" is interesting... So icon should be in root folder, with name
Ah well, I was a bit fast,
fxg1a only supports png. But
fxconv is written in Python, so it supports pretty much every format here.
You may not know it, but two icons must be provided for a fx-CG 50 add-in: selected and unselected. On fx-9860G, the icon is just inverted when it is selected, but this is no longer the case on color screens.
I'd prefer having
resources-cg/icon-sel.png as default locations, and leave a parameter in the config file. It has no complexity cost, no setup cost for beginners, and it won't get in the way of people who put icons outside the resource folder.
By the way, the resource folder is also likely to include every font used by the add-in, as well as binary data files such as maps or whatever static data the application uses. This way of managing resources is much cleaner than having weird constant arrays in the code.
Oooh okay, I didn't noticed now we can use other format than
.png for images in ressources folder 😊 .
Okay 2 icons for one app, it complicates things...
So it's seems fair to include icon(s) path in configuration file.
I agree with the idea of putting default location in ressources folder 👍 .
Sure ressources isn't only images. The structure of this folder is up to the developper like
ressources-fx ├── icon.png | ├── font | ├── font_large.png | └── font_small.png | ├── sprites | ├── overworld | | ├── house.png | | └── sea.png | | | └── weapons | | ├── sword.png | | └── shield.png | | | └── ... | ├── maps | ├── road_101.map | └── road_102.map | └── ...
I'm definitely posting a beta version of this before the end of the week. This has waited long enough.
The commit above introduce the very basics. You can interactively create a project (no command-line arguments supported yet):
% fxsdk new fxsdk-empty Creating a new project in folder 'fxsdk-empty'. Full project name ? (at most 8 characters) > Empty Internal name ? ('@' followed by at most 7 uppercase letters) > @EMPTY Your project 'Empty' has been created. Type 'fxsdk build-fx' or 'fxsdk build-cg' to compile the program.
You get a tree like this, with the fxSDK's default icons. Images are located in
assets-*/img/ and fonts in
assets-*/fonts. Note that there are Makefile rules to build fonts but they won't work yet as you need to specify some metadata. I'll think about how to do it properly;
. ├── assets-cg │ ├── icon-cg-sel.png │ └── icon-cg-uns.png ├── assets-fx │ └── icon-fx.png ├── Makefile ├── project.cfg └── src └── main.c
The project configuration file can be edited at will once it is created (the fxSDK will not try to modify it ever again):
#--- # fxSDK project configuration file for Empty #--- # Project name, should be at most 8 bytes long. NAME = Empty # Internal name, should be '@' followed by at most 7 uppercase letters. INTERNAL = @EMPTY # fx-9860G icon location ICON_FX = assets-fx/icon-fx.png # fx-CG 50 icon locations ICON_CG_UNS = assets-cg/icon-cg-uns.png ICON_CG_SEL = assets-cg/icon-cg-sel.png # Additional compile flags CFLAGS = -std=c11 -Os
You can then
make the example program which prints a string on-screen. fx-CG 50 can run into trouble because the display API is not totally complete yet. gint has to keep up for that, or you can build with libfxcg.
I will add trivial commands such as
install-fx soon. Installing on fx-CG 50 and the Graph 35+E II is tricky because we have to mount the machine. Probably some user configuration is required.
This should start looking good. There's still work to do on asset conversion, in particular where to put the metadata. fxconv is build so that we can do this from Python. The question and when and where...
Let me know if this looks good to you. ^^
Since the CLI has been rolling for quite a while now, and decent success, I'm closing this issue. Feel free to reopen or open a new issue if something's amiss.
Deleting a branch is permanent. It CANNOT be undone. Continue?