LÖVE

ingsoc451 wrote: ↑Sun Mar 03, 2019 5:31 pm Prior to running your game, you can export the bin files to a format that is easier/faster to parse by your game (like a (compressed) lua table). This is a one time processing. But if you are not able to do it for reasons, then using a compressed lua table would be of no use.
Then you can write a c/c++ module to the parsing of legacy format

gradualgames wrote: ↑Mon Mar 04, 2019 8:17 pm For instance, this file format contains strings which have a uShort header (2 bytes) followed by the characters of the strings. I couldn't infer from the unpack or moonblob documentation if the header for a string was a ushort or a normal 32 bit integer.

local reader = BlobReader(data)
local len = reader:u16()
local string = reader:raw(len)

grump wrote: ↑Mon Mar 04, 2019 8:50 pm

gradualgames wrote: ↑Mon Mar 04, 2019 8:17 pm For instance, this file format contains strings which have a uShort header (2 bytes) followed by the characters of the strings. I couldn't infer from the unpack or moonblob documentation if the header for a string was a ushort or a normal 32 bit integer.

Code: Select all

local reader = BlobReader(data)
local len = reader:u16()
local string = reader:raw(len)

gradualgames wrote: ↑Mon Mar 04, 2019 8:56 pm I actually almost just dug into the moonblob code to learn how to parse floating point numbers because I think I'm almost through all the types I need to parse in my own mini binary parser.

grump wrote: ↑Mon Mar 04, 2019 9:02 pm

gradualgames wrote: ↑Mon Mar 04, 2019 8:56 pm I actually almost just dug into the moonblob code to learn how to parse floating point numbers because I think I'm almost through all the types I need to parse in my own mini binary parser.

BlobReader:f32 reads 32 bits floating point numbers. BlobReader:f64 reads 64 bits floating point numbers.
Here is the documentation for BlobReader.

moonblob makes heavy use of ffi cdata types, so there is no actual "parsing" involved. It reads 4 or 8 bytes and interprets those bits as a floating point number by using "type punning".

love.data.unpack provides identifiers for floating point numbers, but you can't be sure their size matches the actual size of your data. It depends on the platform.

grump wrote: ↑Wed Mar 06, 2019 5:09 amYou have to do lots of string slicing and formatting/concatenation for that, and it results in slow code that's hard to read.

pgimeno wrote: ↑Wed Mar 06, 2019 12:51 pm unpack accepts an offset parameter. Wouldn't that obviate the need of slicing?

Where would you need the slicing/formatting/concatenation with unpack which you don't with other methods? Could you give an example?

{
	uint16_t len
	uint16_t data[len]
}

local data = "\x10\x0000112233445566778899aabbccddeeff"
local result = {}
for i = 1, 1e6 do
	local len = love.data.unpack('<H', data)
	result = { love.data.unpack('<' .. ('H'):rep(len), data, 3) }
	result[#result] = nil -- unpack returns an additional value
end

local data = "\x10\x0000112233445566778899aabbccddeeff"
local result = {}
for i = 1, 1e6 do
	local len = love.data.unpack('<H', data)
	for i = 1, len do
		result[i] = love.data.unpack('<H', data, i * 2 + 1)
	end
end

local data = "\x10\x0000112233445566778899aabbccddeeff"
local r = BlobReader(data, '<')
local result = {}
for i = 1, 1e6 do
	r:rewind():array('u16', r:u16(), result)
end