vec2 -- integer, key-value, or both forms of indexing?


I am creating wrapper for Codea to run apps under Love2d, and I am trying to implement my vector module to match behaviors. By the way, I am trying to do this without a running instance of Codea, so I am only using the documentation as a guide.

Looking at applications provided by others, it appears that Codea uses both key-value and integer indexing for vec2. Is that correct? For example:

    local myVec = vec2(1,2)
    for i in ipairs(myVec) do

Thanks to all!

This is correct. The output of your program in Codea is





Thanks for the fast response! Now I just gotta figure out how to implement that dual behavior in Love2d and their version of Lua. :slight_smile:

My initial attempt for this project was to resurrect the old Love-Codea project in gitHub, but after I got that to work (lots of version catch-ups), I found it orders of magnitude slower than expected.

So I have re-started from scratch. The most fun parts thus far were dynamically loading all assets to replicate Codea’s built-in stuff and determining the module require order at run-time, which I believe Codea does with tab ordering.

Thanks again!

@CubicleBill - interesting, haven’t used it for a while but updated Love-Codea myself a few times. Still use it occasionally, even thought about including Groverburgers 3D engine but don’t really have the time (or the skill). Nice to know someone else tried, development on a PC/Mac is, in some ways, much easier.

Hello, again!

Just to confirm, do associative tables in Codea all have the property of having integer and key-value indexing…or is this just a feature of vectors?

The reason for my follow-up is to learn if Codea’s version of Lua supports sorting associative tables because of this indexing. Sorting associative tables is not a feature of native Lua (or Love2d). Instead those languages’ Lua require using a second table to simulate sorting using an integer-indexed table to store the sort key values.


generally tables do not behave like vec. t[1] and t[“x”] are different.

Thanks @RonJeffries

It does seem like Codea supports sorting of associative tables somehow, just haven’t figured out how to replicate that. It must be unrelated to the indexing ability.

I saw an example of this sorting in your Dungeon articles for the contentMap, which I am using to test my Love2d-Codea wrapper to run Codea apps under a Windows machine. I replaced the sort with the Lua work-around of creating a parallel table for the sort…I just don’t have a way to generalize that yet to put into the wrapper.

Thanks for your excellent articles!

thanks! that code isn’t as clear as it might be. note that the table ord is a small array, which is why it can be sorted. an associative table or hashed table can’t be sorted, though one could make a new array of the keys and sort that. the thing is, pairs guarantees no order, so one needs to get to an array and use ipairs.

this is rather on point:

Gotcha, and thanks.

I ended up replacing that sorting table anyway to solve two other issues related to Love2d not supporting z-order of drawing, and so the sort didn’t help as-is:

  • coupling of the player and her attribute sheet could draw over decor, spikes, etc. (because the attribute sheet wasn’t accounted for in the sort as it is really on another tile); and
  • monster attribute sheets were not drawn, top to bottom, by proximity to the player.

I still plan to ponder how I might implement z-order without greatly slowing drawing and needing to save all objects prior to draw.