Getting up to date with AGS

Started by Snarky, Fri 27/09/2024 13:45:22

Previous topic - Next topic

Snarky

Moderator note: This topic was split from here: https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/i-started-a-devlog/

Good stuff! But this bit threw me:

Quote from: ThreeOhFoura few issues that were specifically related to the quirks of the AGS script language. For example, assigning an integer variable as the size of an array of floating point variables requires that you refer to the integer variable with the "float" type, despite the fact that you're calling an integer and that the array size cannot be a floating point variable, and yet AGS's rule for requiring an IntToFloat call to handle this conversion breaks the script. He pointed out that I could simply refer to the integer with the "float" type and that this would pass in this specific exception

It sounds like there must be some sort of misunderstanding. To use an integer variable to set the size of an array of floats, you would write something like:

Code: ags
  int arraySize = 15;
  float floatArrayDynamic[] = new float[arraySize];

This is not "referring to the integer variable with the 'float' type." The new float[arraySize] bit doesn't mean that arraySize is being used as a float; it's an instruction to "create an array of floats, with size arraySize." And the size of an array is always an int, of course.

It would be the same whatever we make an array of:

Code: ags
  bool boolArray[] = new bool[arraySize];
  AudioClip* clipArray[] = new AudioClip[arraySize];
  // ...

In each case, the bit in the brackets is giving the size of the array, and has nothing to do with the array type.

ThreeOhFour

That clears things up a bit, thanks! You can see I wasn't joking when I said I'm very rusty at doing this. I'll link to your explanation in my post!

Crimson Wizard

I might also mention that in AGS 4 there's a new compiler that provides more advanced syntax. There's "Use extended compiler" setting that enables it.
https://github.com/adventuregamestudio/ags/wiki/New-compiler%27s-end-user-cheat-sheet

We still call AGS 4 a "alpha" version, but it's generally usable, and I know that at least several people are actually making their games in it right now.

ThreeOhFour

These look like superb additions. I've absolutely been considering trying out AGS 4 (but I figured that I should relearn a little bit of programming so that I don't pester you about things that are problems with how I write scripts and not the latest version). But these and other new features have me very interested to try it out.

The cheat sheet is very useful, too! May I ask for an example of how to use the bitwise negation operator in syntax? Would it be something just like:

Code: ags
int FirstValue = 1101;
int SecondValue = ~FirstValue; //this sets SecondValue to 1011

Crimson Wizard

#4
Quote from: ThreeOhFour on Fri 27/09/2024 15:12:13May I ask for an example of how to use the bitwise negation operator in syntax? Would it be something just like:

Code: ags
int FirstValue = 1101;
int SecondValue = ~FirstValue; //this sets SecondValue to 1011


Almost, but that code would make sense if ags script supported writing binary numbers, which it does not.
(and ~1101 = 0010)

Common use case would be something like:
Code: ags
enum PlantTypes
{
    Grass   = 1,     // this is binary 1
    Bushes  = 2,     // this is binary 10
    Trees   = 4,     // this is binary 100
    Flowers = 8,     // this is binary 1000
    Everything = 255  // this is binary 11111111
}

int plants1 = Grass | Trees;
int plants2 = ~Trees; // everything except trees

ThreeOhFour

Quote from: Crimson Wizard on Fri 27/09/2024 15:38:55(and ~1101 = 0010)

No wonder I stayed away from writing code all these years  :=

Very useful example, thank you!!

Snarky

#6
Quote from: Crimson Wizard on Fri 27/09/2024 15:38:55(and ~1101 = 0010)

Though it's worth pointing out that the bitwise negation operation acts on 32-bit ints, so it would actually be (in binary representation):

~00000000 00000000 00000000 00001101
=11111111 11111111 11111111 11110010


Which in decimal works out to ~13 == -14
The perhaps surprising result is a consequence of how negative integers are stored as bits. (The largest bit is negative while all the others are positive, so that -1 is stored as all bits set to 1.) The upshot is that ~a == -a - 1

But since when you use bitwise negation you're usually only concerned with the individual bits, not what number they all represent together, and you can typically ignore any bits apart from the ones you're interested in, this doesn't really matter.

If you do need to limit the negation to certain bits, you can use a bitwise AND filter to zero out the others. For example, if you only want the last four bits:


 11111111 11111111 11111111 11110010
&00000000 00000000 00000000 00001111
=00000000 00000000 00000000 00000010


So that you get binary ~1101 == 0010 as expected. (In decimal: ~13 & 15 == 2)

ThreeOhFour

While this is definitely beyond my current goal of simply returning to some basic competency at making my ideas happen in AGS, it's very cool to see more detail on this side of programming!

SMF spam blocked by CleanTalk