i think switch has HW FPU so doing integer maths or floating points does not show that big a off a difference as it would on systems using softfloat where fixed point math would help in that case (represent floats in integers and do calculation using the integer representations so that your not doing floating point maths but integer maths which is faster) and even if it does not it's got plenty of speed. It's not like your developping for some 200mhz device without floating point unit about 20 years ago i had such problems with gp2x but fixed point maths fixed that. But fuze will probably slow down more from doing lots of small (self written) function calls (depending on use case or when trying todo fixed point math) than doing floating point maths directly
edit: according to wikipedia switch uses tegra chip and ARM Cortex-A57 which has hw FPU
also you can easily time stuff using time() function and do little benchmarks, if you really want to investigate for example time 10000 or even 100000 time doing integer division and then do simiar using floating point division and compare times. Doing a single division will not give accurate results to compare as it completes way too fast to measure
T = Time()
Do Some things you want to benchmark
Printat(0,0, Time() - t)
I have something but it's brute force. I use a working copy of the items to shuffle. I use random to grab an index into the items then copy that to the first available position of the result array. The items in the working array are then shifted down to replace the used value and the number of indices given to random is reduce by 1. Once that value gets down to 1 you just copy it and you're done. I did a test one 10 number and it looked like the worst-case scenario would be a total of 30 shifts. Logically, the lower the random result (index) the more shifts have to occur in that iteration of the main loop. It's enough code that I couldn't bring myself to copy it here tonight. All the logic fits nicely into a function so it keeps all these extra variables out of the scope of the main processing, which I have done. I, too, knew that I might need this and had done it this way in another language, so decided to recreate it in Fuze tonight.
EDIT: Wouldn't it be nice to send a code file to yourself in an email from the Switch so you could just drop a snippet in here! : )
items = 
function shuffle(ref options )
itemCnt = len( options )
// Make the working copy...
for i = 0 to len( options ) loop
workItems[i] = options[i]
shufleLimit = itemCnt
for i = 0 to itemCnt loop
// If last item, just move it...
if shuffleLimit == 1 then
shuffle[i] = workItems
// Use random index to get working item
// into shuffled result array...
pickIdx = random( shuffleLimit )
shuffle[i] = workItems[pickIdx]
// Shift values down in workingItems
// the item was not the last...
if pickIdx != shuffleLimit-1 then
for j = pickIdx to shuffleLimit-1 loop
workItems[j] = workItems[j+1]
result = shuffle( items )
print( "Original: ", items, "\n" )
print( "Shuffled: ", result )
Reading through the posts, I feel like my SVG approach is not fitting the core of this challenge. I will move it to a separate WIP thread. So, this submission fits better: download code NQ6HVMNDN8
The dark/light green structure in the tree, was a typo, but I decided that it looks nice 😄 so I left it.
That's correct, this is being worked on for the next patch. The code below:
function toto(ref a)
a = a + 1
...Does not affect the value of a in version 2.15.0 but will work correctly in the next patch. In the meantime, consider returning a value from the function or using a structure or list (ref works correctly for these).
For the second answer, whene we coding, we can write the different function on different file. Is more easy to read and understande. We can make this on fuze ?
Finaly, can we write my document on my PC and put the file on my switch for execute the program ?
FUZE does not currently support multiple code files in one project. We're exploring options that can help organize code better, but for now the best option for organizing code is using code bookmarks (R3).
Unfortunately there is not currently a way to transfer code or other text from the PC to the Switch. If you have a USB keyboard, you can plug it into the Switch or the dock to write code easier on the Switch.
It definitely would not be good for me to remove the ability to share the save file. I feel like there’s workarounds for most of this stuff at the moment, and imagine that the savefile functionality may be tweaked or added to in the future. For now though, I’d encourage new users to check out pianofire’s ‘persistent data’ functions (search in the forum for it), and/or gothon’s file system stuff, and/or spikey’s persistent high score table.
The way to get my collision map working undocked and docked and making use of 1920x1080 on TV was by applying setMode(1920,1080). In my past projects, this decreased the performance when undocked, so I did not use setMode() but scaled the coordinates. And for my current project the performance does not seem to be an issue. But is there another way to achieve this? I mean @Willpowered already answered this clearly, just want to make sure, I understand the application of the info.
That's why I thought it would be interesting to have this discussion. Since there will be a variety of backgrounds and thus expectations to how things behave. But I also think it will help to improve acceptance to the new language feature.
The natural response when you are confronted with something that looks familiar by association, but does not behave as expected, is disgust. It's a defensive response for situations where something is off, but you're not sure what. Of course "disgust" is a strong word, and we don't normally value by one indicator. I just think it helps to have an open mind towards the update :)
++ operator discussion
I think this is an interesting discussion, especially since FUZE does not have this operator. I do feel that this discussion is off topic, but it seems most natural to respond in here anyway.
My argument regarding this operator was indeed within the context of FUZE, that is loosely typed. I absolutely agree that the ++ operator works perfectly well in C++. But FUZE is an entirely different animal.
A problem I see with throwing an error for incorrect types, is that the debugging capabilities in FUZE are not the best in the industry yet. One could also wonder similar questions about floats and even vectors I guess.
Also because FUZE is loosely typed, a mismatch in type could occur in very specific scenarios that might not occur during play testing. Since FUZE in general is used for entertainment, not business applications, it would be more fun if the game would continue with an unforeseen bug, rather than crash with an error. However, during development, you'd want to know that something is wrong.
So here the ++ operator would first cast value1 to a Number, before assigning it to value2. Then after assigning to value2, value1 is modified again for the increment. As I said, this feels dirty, but as an expectation by a developer, not invalid.
I guess the scenario value2 = ++value1 is more simple in any case. Because, after the fact, both value1 and value2 should be equal, both by type and by value.
For these reasons, I am, mildly, opposed to introducing the ++/-- operators at all. But if the operators would be introduced to FUZE, I'd probably use them. But I don't need them.
But at this point, I do feel like I'm rambling on and am off topic.
EDIT: I've edited this post a couple of times, but mostly to improve how the message comes across. The message itself generally stayed the same.
I would also like to add, that although I say I am opposed to introducing ++, I would be happy to use it at the same time :-)