Thanks! I will look into it. By the way, if someone needs a code for quicksort : -- https://en.wikipedia.org/wiki/Quicksort local function swap(db, i, j) -- swap in all fields for f=1, #db do db[f][i], db[f][j] = db[f][j], db[f][i] end end local function partition(db, field, left, right) local pivot...

You pointed out very well. Test(row consisting of 4 ints, 1M+ number of rows) shows that my first method(table.sort) takes only half the time, even with including time for cloning db and creating temporary table for indexing. So in terms of speed, qsort through ffi is not a better option. Also, I no...

I learned that, for C array of structs, I can just use qsort in stdlib through ffi. local ffi = require "ffi" ffi.cdef[[ void qsort(void *base, size_t, size_t, int (*)(void *, void *)); typedef struct { unsigned int id; unsigned char age, height, weight; } row; ]] local n = 4 -- number of ...

Yes, db and DB sould be same. Sorry for messy code; I tried to show pseudo code that includes C data as DB as well, plus possible wrapper functions(set). Your code correction is right. For additional speed one could use table.new for each field when making clone, as size is known and many rehashings...

I completely agree with you that it isn't worth using such data structures for fairly small memory gain, if I have to manually code for each different cases or to clone database everytime when they are sorted. However, if there is any simple, effortless and universal way to sort field(column)-based ...

A simple example : ID | Age | Height(cm) | Weight(kg) 001 | 32 | 175 | 70 002 | 24 | 182 | 82 (...) 220 | 62 | 168 | 65 If each record is a lua table (e.g {1, 32, 175, 70}), we can just use table.sort. However, this is inefficient if number of records become huge. To reduce memory size : 1) Each fie...

Oops, should have searched for 'greyscale' as well.
Thanks!

It would be helpful as in many simple games we use grayscale graphics only. Also, there are many elements(textbox, mask, etc) that use only black and white. * Normal canvas needs 3 times more memory. * 'la8' pixel format might be a good option(grayscale+alpha), but it can not be used in canvas - one...

I finally solved this issue. You are right. TextBatch should be better choice. Also I did some tests after you mentioned GlyphData, and I found out advance of single glyph(GlyphData:getAdvance()) isn't always same as width of single glyph(font:getWidth("X")); sometimes they are same but so...

By the way, the code is : -- big = big font size -- small = small(main) font size function alt_print(s, x, y) love.graphics.setFont(font) for i=1, #s do -- Ascii only example(1glyph=1byte) x = math.round(x) love.graphics.print(s:sub(i, i), x, y) if i < #s then x = x + bigFont:getWidth(s(i))*small/bi...