Best way to make a weapon selection system tied to mouse wheel

[SoftWarewolf]

to jarred, late reply: i thought you already had the available weapons stored somewhere, flags on an object would make sense, just put on flag 1,2,3,4,5 when you get a weapon, and use the event internal flag currentweapon is on/off.

i would use two different values for currentweapon to be safe, one to fire the events i mentioned and one to actually give you the selected weapon (when you know the flag is on) or use Chrille's version which is probably the best one

i am skeptical of lists since it's a big string of text, but maybe it's faster than i think it is.

[nivram]

Hi. You shouldn't be skeptical of List Objects because you think they are slow. Easier to use in this case than Arrays.

Marv

[mobichan]

Since the original post asked that the weapons be in a predefined order, how are you manipulating the List object so that as you pick up new weapons they are added to the list in the proper order? Sorry, I haven't checked out the sample file yet, but are you keeping a set of events that is hardcoded to insert the weapon into the right spot in the List?

[schrodinger]

Interesting thread,
add some thoughts about latest clever observations:

1) to properly decide you should clarify whether:
a) you need to store your weapons in predetermined order or not
b) you need this system to support multiple players
c) you need to store (and save?) other values/infos about those weapons or just their availability (ex. ammo count, powerup level...)
d) you need to store/save additional data about your game (...that could all be packed in a differently setup array)

2) as for list speed, some time ago I tested list objects + fastloops for a random map generation,
and that was hugely slower than same setup based on array + fastloops (about 2 seconds vs 0).
But that was a large project building up hundreds of cells,
so I'd say for small scale and few steps at a time it's surely fast enough.

[Jarred]

For my purposes, the array is awesome. I know I'm going to use them a lot and this was a really good exercise to reintroduce them to me. The only thing I'm dreading is creating referential diagrams on paper to keep track of what means what at each dimension...but still incredibly useful.

[schrodinger]

I admittedly have never tested the "internal list object" that by definition is a "faster list object"
so I have no actual speed comparisons to report on that
(side note: I see it's windows only, don't know if viable for Jarred?)

As for my tests I would clarify that I was talking about standard "list object",
as the one used in the examples posted,
and I agree that it would better (cleaner & easier to setup) suit these singular weapon scrolling needs in comparison to an array,
even if slower (I guess because, differently from the "internal list", it is sort of a "GUI" object and has to show the highlight moving etc.)

(.....although I have a love affair with arrays so I can't question anyone choosing that way )

Given this warm endorsing by Snail, I will for sure test internal list on future plans, seems a really interesting thing


EDIT: knowing about internal list speed before I would have never tested a simple "list object" against an array for my purposes... well, next time!

[Jarred]

(side note: I see it's windows only, don't know if viable for Jarred?)

Eh, I'm developing on Windows but hope to do ports to the other platforms (of course no mouse movement there). Arrays just always seemed to be the most logical way to set up info to me. Plus I want to control 'upgrade' type additions so the array let's me keep that nice and tidy I'm already on a 5x5 grid and reworking my code to poll the info from the array (which will make future updates and changes a breeze )

Good to know about the lists tho. If I notice sluggishness it's good to know there are options to make things speedier.

[schrodinger]

Now that this thread has taken this direction, I HAVE to ask you, Snail,
if you have ever tested to such extent the speed of "Named Variable Object"?
(even if the answer could doom me to endless hours of re-coding )

Since you state, if I comprehend correctly, that on average usage (that is, 3 array cells vs. 1 internal list row)
the internal list beats the array,
I have tested the Named Variable Object against the standard Array, and the latter was the winner,
but I had anyway to stick to NVO for some additional needs (and + great features like builtin encryption)

BUT now I'm thinking...
if array > NVO
and list > array (in average usage)
...how an average NVO usage would score against an internal list???
(that, given its different structure from standard array, is pretty similar to an internal list, I'd say, so 1 row against 1 row?)

I'm curious if you ever had the chance for testing.

Additional question: does the internal list still performs great on growing index dimension? (let's say... > 50.000 indices)

So far NVO proved really useful for me, although sometimes I recognize that little glitching I didn't get with array.
Next question would be: that little sprint in speed could be worth the insomniac week recoding?
Ok, I'll try to answer that on my own...


EDIT: I just realized that I'd have to additionally parse the string,
because in my project I have to store a single value, but in a specific "composite" and traceable index,
and if internal list works as standard list, its "index" would be the row number,
so I'd have to use some string solution to store an additional ID, like "ID|value"
and then tokenizing/searching that would easily make it slower than NVO... (?)

[schrodinger]

That's a really interesting insight,
and a great point one usually don't think of:
work you have to do "around" the object may actually overcame the performance advantages you get from the object in itself.

As for the speed test... gosh.
It's so sad seeing those values ineluctably written on that pitiless white background

Fact is, I need something that can store an integer value in a three-index reference,
and that could handle negative positions. NVO seemed the only solution.

Using a 3D array was not viable due to the fact that negative numbers could not exist in index (I needed those for theoretical infinite map directions from any point)
the only solution with arrays was a four-array setup (a four quadrant solution suggested by Simon and Tompa, if I recall correctly),
great solution, but in my situation that performed bad due to the overprocessing needed to fastly switch/chose the right index in the right "quadrant", multiple times for any given moment.
This resulted in slower performance than NVO.

However, now I see what I "felt" in actual gameplay change: Nvo is 13 times slower than array.
Urgh.
But I posted this while ago and I had my way since then, so, yes, better stop going off topic

Thank you for all the useful infos and smart thinking.

[schrodinger]

Don't want to flood this thread with my issues, but since it's a crucial part of my engine I'll give just another quick line ()

The system underlying the reading/assigning value is quite complex, there lies the bottleneckin my situation, I think.

I substantially do the following about 2-3 times per second,
to generate an average of 12-16 new cells:
-the "choosing" engine loops through all pre-generated square-adjacent cells to these new 12-16 positions
(this means=looping through adjacent XYZindices of each cell and storing their content to a string. This is where four quadrants setup was weak: 12-16 times x 4, on an already "bulky" process, I had to add an additional control to decide from which of the four quadrants to choose)
-basing on above string + further calculations, the new value is assigned to the cell

This done on runtime with NVO works decently.
With single array was perfect... but incomplete for lacking of negative indices.


I could have split the process to make the quadrant jump only in needed cases (that is 0 indices).
That would have slowed down only in few cases, but required a good amount of weighting/crowding the code...

Well, since I'm full immersed in rethinking the basis,
I'm now going to masochistically speed-test the associative array...


UPDATE: oh... man... I knew I shouldn't have... Associative Array performs on par with internal list... hell awaits me