I finally got back to the program where I used the animated text discussed above. For anyone who is curious it's called "Pong+" and shared with friend code SW-3411-8656-9702
The title-screen uses the clear() method that Dave suggested originally, and the select-score-to-win-screen uses my "black box" method (to avoid re-drawing the whole screen)

@Nisse5 Thanks I will raise an issue

I have just been moving them off screen when I don't need them. . Finding a way off screen to see all these happenings always intrigued me in th ed 80's was like escaping into the code

A known bug - i believe this has been fixed in the first patch.

@brillianceguy

I completely forgot about that option!

This is a documentation issue, and the reason for this being this way is because of the angle parameter, where you would normally want the image to rotate about the centre of the image.

There is an issue for this internally and it'll be updated in the help in the near future!

Please be aware that accessing arrays with this "colon notation" is not officially supported, please check the online help for the most up to date help (https://fuzearena.com/help).

@Nisse5 said in Strings using special characters:

@jacobmph said in Strings using special characters:

I kind of agree, but the whole of the internet is against us :-) Backward compatibility with ASCII wins out (even though I guess it’s no real advantage for FUZE).

7-bit ASCII (the printable range at least) is a subset of 32-bit fixed Unicode, so in that regard the compatibility would still be intact.

What they mean by "compatibility" is that ASCII and UTF-8 have the same exact representation for characters in the ASCII range. This isn't true for UTF-32, because each character will take up four bytes instead of one. In other words:

Text: Hello, world! ASCII: 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 UTF-8: 48 65 6C 6C 6F 2C 20 77 6F 72 6C 64 21 UTF-16LE: 48 00 65 00 6C 00 6C 00 6F 00 2C 00 20 00 77 00 6F 00 72 00 6C 00 64 00 21 00 UTF-32LE: 48 00 00 00 65 00 00 00 6C 00 00 00 6C 00 00 00 6F 00 00 00 2C 00 00 00 20 00 00 00 77 00 00 00 6F 00 00 00 72 00 00 00 6C 00 00 00 64 00 00 00 21 00 00 00

Thank you! We'll check this out.

Thank you. I'll add this to the issue tracker

@ITzTravelInTime Same here with consistency. For my MML player, I want to give users of it 2 options. One without timers, and one with. With timers, they not only benefit from higher resolution timing for more accurate playback, but by having it on a timer, it won't stop or glitch if they have to process a lot of stuff in the main loop in one go because, unless I'm mistaken, it would/should interrupt what's being processed to process that stuff from that timer. Of course without timers, they wouldn't need to use a timer at all, allowing them to use it for other purposes.

Just to say this thread isn't being ignored! Thanks for reporting.

Maybe the error is an either/or scenario, since the stack could be used for functions and variables (gotta save the position and whatnot of where code was before entering a function)

Sounds good, and thanks.

I tested with the following code, doing my best to force the values to be integers:

int x1 = 0 int y1 = 0 int x2 = 100 int y2 = 100 p1 = {int(0), int(0)} p2 = {int(100), int(100)} vector pt1 = {0, 0} vector pt2 = {100, 100} loop clear() line({x1, y1}, {x2, y2}, {1, 1, 1, 1}) line(p1, p2, {1, 1, 1, 1}) line(pt1, pt2, {1, 1, 1, 1}) update() repeat

It all runs successfully, so maybe this is a symptom of another bug? If you're able to reproduce it let me know!

@Nisse5 Thanks I will raise an issue

This is fixed in the latest patch. Just waiting on the approval process :)

@MikeDX
also, I crashed the game when using the 3d objects initially, I created too many 3d objects, something about exceeding memory limit...

If you could tell me what is the object limitation that would also be a good foundation...

Ive read on other posts the limitation is your disk space, but obviously the game crashed because it just wouldnt stop... So i can assume aswell that if you ran that line of code where it just prints the same thing over and over and over and over it would also crash...

but thats a difference in kb to mb... and the intial lines of code are so small that the program is saved small but its the creation of all that information that is crashing through memory... thats my logic of the situation..

Thank you for the report. I have seen this so many times myself and yet continue to forget it. Will create a bug report now.

[EDIT] Raised.

@glank9000 the website will usually be slightly ahead of the fuze app help and will have corrections and additions before patches land so it's usually best to check there first.

I was modifying a program to use an array of a struct instead of singular sprite to bounce around at random on a tile map. All progress on it was lost due to he bug, but I'll try to recreate it and will report back if/once I get the error again