item data?

Whats the most efficient way to store an item. Or sprite and its data, such as its name, effect and worth? Examples appreciated.

I'm confused, are you asking how to store an item in an inventory or are you asking how to store a Sprite and its data? Because those are two very different things.

I'm confused, are you asking how to store an item in an inventory or are you asking how to store a Sprite and its data? Because those are two very different things.

The latter my friend.

Item data (though I've not dealt with it yet) seems simple. I would just use a binary integer string. Every time a 1 pops up, that item has been obtained. This assumes you have a system similar to TLoZ: ALttP. Otherwise, maybe have a data array (for a Terraria/Minecraft sort of system.) Sprite data storage: I have no idea what you mean. Sprite position: x/y coordinates using variables. Pretty simple, isn't it?

Item data (though I've not dealt with it yet) seems simple. I would just use a binary integer string. Every time a 1 pops up, that item has been obtained. This assumes you have a system similar to TLoZ: ALttP. Otherwise, maybe have a data array (for a Terraria/Minecraft sort of system.) Sprite data storage: I have no idea what you mean. Sprite position: x/y coordinates using variables. Pretty simple, isn't it?

theoretically sounds easy. appreciate your time. does anybody have a program resource i could study using an efficient item inventory system?

I can make one

I can make one

i would greatly appreciate it.

Well I've made one. It took me a little bit to figure out a system,

why

I started with a single string and integer, but figured out how complex that would be with more than 2 items. So I moved on to a string array and an integer (in the form of an array to save DAT files, but I don't know how efficient DAT files are compared to others like TXT and PRG.

but it worked out in the end. Beforehand, just know that this is only the first example I talked about (with the number string that's similar to binary.

why similar

If it were a binary string that added a value for every item you have, it would be impossible to figure out what items you do have, so don't make that mistake. And due to a bit of lazyness, I just used a decimal string. Most of the magic is in string functions, so number system doesn't really matter as long as it's 1s and 0s.

) If you want an example of the other type for Terraria/Minecraft like inventory system, let me know. Anyway, here's the key: KERXCEAV

Well I've made one.

Heyyy, i appreciate it! I think i understand how to deal with this. But i have another question. I have been trying to figure out an efficient and effective sprite menu select system...for example the same as a texts menu, but it uses a sprite cursor and sprite options. the problem is that its a huge mess of code to wright when you have multiple options made of sprites, because every move depends on the input+sprite collision.

Well, I can't help too much there, since I haven't really dealt with sprites too much due to the joys of graphic screen functions. I have found the graphic screens so much easier to use (to me) along with things like touch inputs, etc. So with sprites, all I can say is remember to use SPCOL.

Well, I can't help too much there, since I haven't really dealt with sprites too much due to the joys of graphic screen functions. I have found the graphic screens so much easier to use (to me) along with things like touch inputs, etc. So with sprites, all I can say is remember to use SPCOL.

Yeah 100% agree. i'm trying to innovate my game to work also on Switch, as that's my primary engine now. Yes, switch also has a touch screen. But i'm trying to make a more..."fancy", type of menu, using sprites over the console screen.

Well I've made one.

Heyyy, i appreciate it! I think i understand how to deal with this. But i have another question. I have been trying to figure out an efficient and effective sprite menu select system...for example the same as a texts menu, but it uses a sprite cursor and sprite options. the problem is that its a huge mess of code to wright when you have multiple options made of sprites, because every move depends on the input+sprite collision.

can anybody else help with this?

I have been trying to figure out an efficient and effective sprite menu select system...for example the same as a texts menu, but it uses a sprite cursor and sprite options. the problem is that its a huge mess of code to wright when you have multiple options made of sprites, because every move depends on the input+sprite collision.

What do you want exactly? give an example. If it's just scrolling options and a sprite pointer, the logic is the same as for text, except you draw and move sprites around instead of text.

I have been trying to figure out an efficient and effective sprite menu select system...for example the same as a texts menu, but it uses a sprite cursor and sprite options. the problem is that its a huge mess of code to wright when you have multiple options made of sprites, because every move depends on the input+sprite collision.

What do you want exactly? give an example. If it's just scrolling options and a sprite pointer, the logic is the same as for text, except you draw and move sprites around instead of text.

not scrolling. but more of a inventory system such as minecraft with a 3/8 hud or whatever. looking for something that i can put in a DEF END command that i can refer to anytime i need a new menu

thoughts on inventory management

what I would do is give each item a unique ID and then store the player inventory as a list of item IDs.

DATA "ID","Name","TYPE","Property1","Property2",...

and then copy them all into an information array and use VAL() when appropriate. Strings are really convenient for dynamic sizing, and in the case of a string I would maybe just write CHR$(QTY)+CHR$(ID) for every item. With clever ID assignment and a maximum quantity, you could even use INSTR to search for items by ID this way. But while convenient, pretty much every operation on this is O(n). Another option is to have contiguous item IDs, from 0 to LAST_ITEM, and statically allocate two arrays

DIM INVENTORY_QTY[LAST_ITEM+1]
DIM INVENTORY_LST[LAST_ITEM+1]
VAR INV_HEAD = 0

DEF INV_ADD ID
  QTY = INVENTORY_QTY[ID]
  IF !QTY THEN
    INVENTORY_LST[INV_HEAD] = ID
    INC INV_HEAD
    INC INVENTORY_QTY[ID]
  ELSE
    INC INVENTORY_QTY[ID]
  ENDIF
END
DEF INV_SUB(ID)
  QTY = INVENTORY_QTY[ID]
  IF QTY <= 0 THEN
    RETURN FALSE
  ELSEIF QTY == 1 THEN
    DEC INVENTORY_QTY[ID]
    VAR I% = INV_HEAD - 1
    WHILE INVENTORY_LST[I%] != ID && I% > 0
      DEC I%
    WEND
    INVENTORY_LST[I%] = INVENTORY_LST[INV_HEAD-1]
    DEC INV_HEAD
  ELSE
    DEC INVENTORY_QTY[ID]
  ENDIF
  RETURN TRUE
END

Then displaying inventory just involves enumerating INVENTORY_LST to INV_HEAD, remove is worst case O(n), but much lighter everything else is like O(1) or something. Completely untested.

How do you find the efficiency of algorithms?

thoughts on inventory management

what I would do is give each item a unique ID and then store the player inventory as a list of item IDs.

DATA "ID","Name","TYPE","Property1","Property2",...

and then copy them all into an information array and use VAL() when appropriate. Strings are really convenient for dynamic sizing, and in the case of a string I would maybe just write CHR$(QTY)+CHR$(ID) for every item. With clever ID assignment and a maximum quantity, you could even use INSTR to search for items by ID this way. But while convenient, pretty much every operation on this is O(n). Another option is to have contiguous item IDs, from 0 to LAST_ITEM, and statically allocate two arrays

DIM INVENTORY_QTY[LAST_ITEM+1]
DIM INVENTORY_LST[LAST_ITEM+1]
VAR INV_HEAD = 0

DEF INV_ADD ID
  QTY = INVENTORY_QTY[ID]
  IF !QTY THEN
    INVENTORY_LST[INV_HEAD] = ID
    INC INV_HEAD
    INC INVENTORY_QTY[ID]
  ELSE
    INC INVENTORY_QTY[ID]
  ENDIF
END
DEF INV_SUB(ID)
  QTY = INVENTORY_QTY[ID]
  IF QTY <= 0 THEN
    RETURN FALSE
  ELSEIF QTY == 1 THEN
    DEC INVENTORY_QTY[ID]
    VAR I% = INV_HEAD - 1
    WHILE INVENTORY_LST[I%] != ID && I% > 0
      DEC I%
    WEND
    INVENTORY_LST[I%] = INVENTORY_LST[INV_HEAD-1]
    DEC INV_HEAD
  ELSE
    DEC INVENTORY_QTY[ID]
  ENDIF
  RETURN TRUE
END

Then displaying inventory just involves enumerating INVENTORY_LST to INV_HEAD, remove is worst case O(n), but much lighter everything else is like O(1) or something. Completely untested.

though i will use this as reference for something i just thought of. appreciate it.

Big-O notation is how we usually measure worst-case time complexity for algorithms, and it's usually split in 5 categories: constant, logarithmic, linear, polynomial and exponential (sorted from most desirable to least desirable). Big-O notation describes how many "operations" your algorithm does in relation to your input size. In constant time [ O(1) ], means that no matter your input size, your algorithm will run in the same amount of time. An example could be:

DEF ACCESS A
  RETURN A[0]
END

In linear time [ O(n) ], means that the time that your algorithm takes to run is directly proportional to it's input size. An example would be your typical linear search:

DEF SEARCH(A,J)
  FOR I=0 TO LEN(A)-1
    IF A[I]==J THEN RETURN I
  NEXT
  RETURN -1
END

Logarithmic time [ O(log n) ], the best example for this is binary search:

a = [1,2,3,4,5,6]
a = [1,2,3]
a = [2]

Polynomial time is involved with nested stuff and exponential is like satan.

thoughts on inventory management

what I would do is give each item a unique ID and then store the player inventory as a list of item IDs.

DATA "ID","Name","TYPE","Property1","Property2",...

and then copy them all into an information array and use VAL() when appropriate. Strings are really convenient for dynamic sizing, and in the case of a string I would maybe just write CHR$(QTY)+CHR$(ID) for every item. With clever ID assignment and a maximum quantity, you could even use INSTR to search for items by ID this way. But while convenient, pretty much every operation on this is O(n). Another option is to have contiguous item IDs, from 0 to LAST_ITEM, and statically allocate two arrays

DIM INVENTORY_QTY[LAST_ITEM+1]
DIM INVENTORY_LST[LAST_ITEM+1]
VAR INV_HEAD = 0

DEF INV_ADD ID
  QTY = INVENTORY_QTY[ID]
  IF !QTY THEN
    INVENTORY_LST[INV_HEAD] = ID
    INC INV_HEAD
    INC INVENTORY_QTY[ID]
  ELSE
    INC INVENTORY_QTY[ID]
  ENDIF
END
DEF INV_SUB(ID)
  QTY = INVENTORY_QTY[ID]
  IF QTY <= 0 THEN
    RETURN FALSE
  ELSEIF QTY == 1 THEN
    DEC INVENTORY_QTY[ID]
    VAR I% = INV_HEAD - 1
    WHILE INVENTORY_LST[I%] != ID && I% > 0
      DEC I%
    WEND
    INVENTORY_LST[I%] = INVENTORY_LST[INV_HEAD-1]
    DEC INV_HEAD
  ELSE
    DEC INVENTORY_QTY[ID]
  ENDIF
  RETURN TRUE
END

Then displaying inventory just involves enumerating INVENTORY_LST to INV_HEAD, remove is worst case O(n), but much lighter everything else is like O(1) or something. Completely untested.

How do you find the efficiency of algorithms?

Time them

Big-O notation is how we usually measure worst-case time complexity for algorithms, and it's usually split in 5 categories: constant, logarithmic, linear, polynomial and exponential (sorted from most desirable to least desirable). Big-O notation describes how many "operations" your algorithm does in relation to your input size. In constant time [ O(1) ], means that no matter your input size, your algorithm will run in the same amount of time. An example could be:

DEF ACCESS A
  RETURN A[0]
END

In linear time [ O(n) ], means that the time that your algorithm takes to run is directly proportional to it's input size. An example would be your typical linear search:

DEF SEARCH(A,J)
  FOR I=0 TO LEN(A)-1
    IF A[I]==J THEN RETURN I
  NEXT
  RETURN -1
END

Logarithmic time [ O(log n) ], the best example for this is binary search:

a = [1,2,3,4,5,6]
a = [1,2,3]
a = [2]

Polynomial time is involved with nested stuff and exponential is like satan.

I know what Big-O notation is, but thanks anyway! (I'm assuming that was directed toward me, if I'm wrong then sorry)

thoughts on inventory management

what I would do is give each item a unique ID and then store the player inventory as a list of item IDs.

DATA "ID","Name","TYPE","Property1","Property2",...

and then copy them all into an information array and use VAL() when appropriate. Strings are really convenient for dynamic sizing, and in the case of a string I would maybe just write CHR$(QTY)+CHR$(ID) for every item. With clever ID assignment and a maximum quantity, you could even use INSTR to search for items by ID this way. But while convenient, pretty much every operation on this is O(n). Another option is to have contiguous item IDs, from 0 to LAST_ITEM, and statically allocate two arrays

DIM INVENTORY_QTY[LAST_ITEM+1]
DIM INVENTORY_LST[LAST_ITEM+1]
VAR INV_HEAD = 0

DEF INV_ADD ID
  QTY = INVENTORY_QTY[ID]
  IF !QTY THEN
    INVENTORY_LST[INV_HEAD] = ID
    INC INV_HEAD
    INC INVENTORY_QTY[ID]
  ELSE
    INC INVENTORY_QTY[ID]
  ENDIF
END
DEF INV_SUB(ID)
  QTY = INVENTORY_QTY[ID]
  IF QTY <= 0 THEN
    RETURN FALSE
  ELSEIF QTY == 1 THEN
    DEC INVENTORY_QTY[ID]
    VAR I% = INV_HEAD - 1
    WHILE INVENTORY_LST[I%] != ID && I% > 0
      DEC I%
    WEND
    INVENTORY_LST[I%] = INVENTORY_LST[INV_HEAD-1]
    DEC INV_HEAD
  ELSE
    DEC INVENTORY_QTY[ID]
  ENDIF
  RETURN TRUE
END

Then displaying inventory just involves enumerating INVENTORY_LST to INV_HEAD, remove is worst case O(n), but much lighter everything else is like O(1) or something. Completely untested.

How do you find the efficiency of algorithms?

Time them

Ok then