@MikeDX So just how much memory are we allowed for variables, arrays, strings, etc? Also as a side-question, how long can strings be?

An interesting idea I just had was that if we were able to access an image's data pixel-by-pixel in a future patch, we could technically use that for storing data. That's how some folks that used Petit Computer handled a large amount of data for their projects, including myself.

edit:

Just did a test. Guess we have at least 4MB available. Started a string with just the character "A", which had a length of 1. Then I threw the string into a for loop to add to itself, so at about 22 iterations, the string was roughly 4,194,304 characters long.

From what I can tell, certain characters are not possible to obtain in strings, due to chr outputting utf-8:

0-127 (0xxxxxxx) - direct from chr 128-191 (10xxxxxx) - 2nd/3rd/4th byte of multi-byte chr (>127) 192-223 (110xxxxx) - 1st byte of 11 bit chr 224-239 (1110xxxx) - 1st byte of 16 bit chr 240-247 (11110xxx) - 1st byte of 21 bit chr 248-255 (11111xxx) - unobtainable

And even if you can create these chars, you won't be able to read their values very easily, because chrVal will probably fail with invalid UTF-8 data.
You should probably just use an array.

Yes, exactly, that was my 2 cents on how to assign a value into structure, when needed. Not sure what happens if the whole structure is passed as an argument, if that is a reference or a value. Mu guess is by value ;-). I.e in this what would happen if only a is passed and the function would assign a.b=3

That is correct, variables in Fuze are loosely typed and so do not need a $ for strings among other things. The exception to this is when declaring a structure. But then you still don't use $, you use "string"

In all seriousness, can you buy a USB switcher that switches based on a key press or combination that would still work on the (Nintendo) switch because it doesn't need any kind of driver to do it? If that exists relatively cheaply then yeah, I'd be tempted. But a switch that involves me reaching away from the keyboard to switch would be just as much of a nuisance as having multiple keyboards.

Far too many "switches" in this conversation :)

iAM just having a hard time trying to break down the code, but, from what it looks like to me, your title and start will always be true because of the first line...
When you just want title to be true for title, and start to be true for start...

like, i grasp, kinda whats going on....
but at the same time im just like, no....

Like, the naming, when start, shouldnt game be true..
because, title and start are not your game, thats title and a function...

but that first line... is forcing title true....

so no matter what you do, its just gonna turn back on

//solutions ill add :
//remove the very first line
//change the second line to
while !game loop
//add a
while game loop
// or keep it opposite, either way it needs to know what to do after you are no longer running while game loop, because start kills that entirely

The more i look at this code the more of a headache i get, title is always active due to the very first line,
so by activating start, you are turning off title and start... except for the first title.... because that is independent of the game loop mechanic...

Ive rewritten this more than id like to admit... but you cant expect to run title twice, kill it once and not have it return... its line one thats making the title screen reappear its also the reason the program doesnt close when you "start" your game...

:I start making game = false I: I cant even at this illogical syntax...

When plug in laptop - power = false.... no... just... no

Thanks everybody !

Hi Walton

You're correct, the gothicVania demo was indeed made before the map functions were added. I will be looking to include a remade version of that demo which uses the sprite commands for a future update.

The good news is that you can absolutely manipulate the collision map coordinates and scale. The setSpriteCamera function is what you need here. I've linked to the help page just below:

https://fuzearena.com/help/view/setSpriteCamera
https://fuzearena.com/help/view/setSpriteCameraRotation

You can also use setSpriteCollisionShape to adjust the collision box around your sprite:

https://fuzearena.com/help/view/setSpriteCollisionShape

Hope this helps, let me know if I can help further!

That's correct, you can assign a user variable to the sprite to keep track of the name if you like.

getSpriteImage(sprite) will return the image handle only. The image name isn't stored anywhere unless you keep track of it yourself!

It's a 3d game

@Myddrak said in Screen coordinates:

sorry, my mistake, I missed where for loops don't include the boundary... all good :)

To be fair, I’d say it is a little on the quirky side but just one of those things. As long as you know, it’s easy enough to live with.

Okay good :)

Thanks for the quick reply!

Makes sense that they'd have that restriction now that you mention it.

Edited the Joycon test program to include lc and rc, this works, thanks again!

The forum code changes two slashes to one. try \\ (enclose with backticks)

after some mistakes on my part due to mixing languages, i managed to get it sorted, thanks a bunch!