Wishlist
-
I think someone already mentioned insert and remove at index for arrays, but some more things that would be nice to have for arrays are
push()pop()shift()andunshift()For anyone curious
push()- Adds a new element to end of an array
pop()- Removes last element from an array
unshift()- Adds new element to beginning of an array
shift()- Removes first element from an array -
@pico8-jihem said in Wishlist:
Can you add a strSplit(<string>,<string separator>) function that returns an array of strings ?
result=strSplit("this+is+my+text","+")after execution, result = ["this","is","my","text"]
Here's my version of that. Takes a string and a separator string (length of 1)
function strSplit( strd, sep ) arr = [] if( len( sep ) == 1 ) then while(( loc = strFind( strd, sep )) >= 0 ) loop if( loc == 0 ) then strd = strd[ 1: ] else arr[ len( arr )] = strd[ :loc - 1 ] strd = strd[ loc: ] endIf repeat endIf return arr -
@Discostew Excellent, mine is very similar. Thank you for sharing :-)
Some of the requested functions can be done programmatically. The purpose of my request is to have a native function (faster than anything we can write). -
@Martin Regarding switch vs if-[elsif...]-else-endif the main difference in many languages is that switch supports ordinal values only (due to optimized jmp table) but if-elsif supports arbitrary expressions (resulting in boolean). So in case F4NS switch supports arbitrary expressions it's a clear vote from me but if not there still might be handy to have elsif keyword.
-
@pico8-jihem Haha, this is just a step away from adding classes ;-). Maybe something like golang implements for their "sort-of-OOP" might be here in F4NS as well. Golang basically ignores all the principles from OOP but left structures (F4NS has structures as well), added namespace definition and allows hook functions to structures. Nothing more. No constructors, no inheritance and no polymorpism - memory gc is solved via escape analysis. So possibly something like this might appear in the future version of F4NS?
-
It would be nice if the standard
result = input(prompt, multiline)function could include an optional 3rd parameter, with the default text in the edit field. That way it would be easier to edit existing data.
-
For the 3D:
- Something like :
https://www.khronos.org/opengl/wiki/GLAPI/glDrawArrays
Handy if you want to draw arbitrary objects from data.
- Parametric fog - fog makes the melancholic atmosphere in games ;-)
- Something like :
-
"...something like golang implements for their "sort-of-OOP" might be here in F4NS as well..."
@mixaal l think it's enougth and I would love it :-) -
@Jonboy I would really like to see Fuze have a 3D model creator and texture creator to used with the program’s 3D capabilities in a future update. A music and sfx creator would also be helpful when making games with your own original music or sounds.
-
@B_Studios I also think more advanced 2d drawing tools for the sprite creator and more themes for the menu would be cool to see in a future update. Keyboard themes would also be cool to have options for keyboard designs besides the two already existing red and black keyboard themes.
-
Hey Team, one for the website tutorials - Any chance of putting in links at the bottom of each page for the next/previous topic?
-
I've noticed that it would be convenient if the screen didn't scroll to the right when entering code so quickly. once you get to a certain amount of characters typed, the screen jumps far to the right and it can mess with my bearings. does that make sense? maybe just move with each character typed, but still show a majority of the left side of the screen rather than the right.
-
@Jonboy lambda expressions I can stick in variables and array slots, functional-style features for dealing with collections of things (so, closures.) Some way to break my code into multiple "files" (even if that's not what's going on under the hood; the whole thing could be a SQLite database or whatever else.) Regular expressions would be a huge win. ToyCon integration (particularly the piano and the VR goggles.)
-
I imagine the "File Handling" stuff is mainly for a project's "save" data (so it doesn't actually get shared), but maybe that could be expanded so we can store project relevant data that'll be shared, not limited to just one file, and maybe make them read-only when sharing (as they could be important and changing data in them could break the project). When I worked on my MM2 PTC project in Petit Computer, I utilized the program's use of graphic pages (GRP) to hold such both graphic and non-graphic data (like levels, music, etc) because I had no room within the program's line limit (9999 lines of code) to fit them there. As I understand it right now, if I were to use arrays and whatnot to hold levels, music, etc, that would actually take away from the memory allocated for variables. PTC provided the DATA and READ commands to hold the data as code like an array, but one had to read that data into variables and arrays to use them, thereby they didn't take up precious memory.
If having this expanded file handling is out of the question, then what about allowing us to read pixels in image buffers, and being able to save images from within our projects? That would allow us to utilize them like files that held project data like how I did it in Petit Computer.
-
This post is deleted! -
This post is deleted! -
What we need to get to OOP is mostly struct + lambda, and we're missing the lambda. Doing e.g. class-based message dispatch wouldn't be too hard with lambdas, and with multiple code files / IMPORT or whatever, we could write it once and use it whenever.
-
I would like to chime in and agree, as well as add an idea to hopefully implement write and open and both seq. and r.a. file operations perhaps ?
-
@MikeDX
Hi Mike,I want to be careful to avoid coming off as too negative on this, but respectfully, being forced to use one file is just painful. Code re-use is important: having to highlight a mountain of code and copy it into every program that uses it is not a good solution. Arguably it's even a bad habit.
I agree that the default workflow should expect that most users will be kids using just one file. But sometimes you get an ambitious kid who wants to do a bigger project; should we make that harder than it needs to be?
If this is about "Nintendo doesn't want us creating and deleting tons of files in the underlying Switch filesystem," there's a simple solution: use one (actual) file, and present it as though it were multiple files to the user. Let us have some kind of REQUIRE or INCLUDE command so we don't have to scroll through thousands of lines of copy-pasted "library" code.
Example underlying representation (actual file on Switch) for clarity:
<project name="foo"> <file name="scanner"> //big pile of code here </file> <file name="parser"> //metric ton of code here </file> <file name="fuzeInFuze"> require("scanner", "parser") // a ton more code, followed by an educational... metacircularityLesson() </file> </project> -
@Jonboy I almost forgot: when I get a syntax error, it helpfully tells me what column it happened in. Perhaps on the far right end of the bar at the bottom of the edit view there should be a column indicator?
