item data?

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.

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?

I can make one

Well I've made one.

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'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.

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.

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.

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.

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.

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?

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.

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