IncFile() and IncArray() macros [Updated 22-1-2009]

[Merick]

Actually, I'm hoping to eventually do all my setup stuff with the lua api. The real reason for using this with FBlua is so that if someone makes a game they can use incfile to compile their script into the .exe. That way, if someone wanted to cheat they'd have to use a hex editor or something in order to change the game variables.

[porfirio]

And FBGfx really miss integrated png suport ( static linked ) ok i have been able to done it myself linking libz.a and libpng_load.a, but PNG loading for sure should be on the Core

Well, it'd be a nice feature, but the truth is, it's not needed..
png_load and PLoad can provide the same functionality without much of a hassle.

But if PNG support was to be integrated into Gfxlib, that would mean that ANY freebasic application will have to link to zlib1.dll, or provide a static implemention..

About the integrated memory BMP loading support, i'll look into it, i think it can be done.. :)

Not necessary, for example FBGFX is only linked if we do a Screen* comand

Maybe zlib and png load could be linked only if used
But you are right kinda, theres libraries that already do that, its not the same but its ok

For example PureBasic suport diferent encoders\decoders by including them on one comand
http://www.purearea.net/pb/english/manu ... image.html

theres other option, include the pngload with fb inc+lib
so we can do something like

Code: Select all

#include "fbgfx_png.bi"

FB.loadPng(...)

I just think bmp is a deprecated format, 1MB for a crappy sprite is too much ( worse if you are including it inexe ), png is great and should be IN fb

Just my 0.02 €

[voodooattack]

I just think bmp is a deprecated format, 1MB for a crappy sprite is too much ( worse if you are including it inexe )

I'll have to agree on this :)

Although I have an alternative idea for supporting formats other than BMP through standard interfaces, Since I'm totally against adding extra dependencies. (for portability/size/memory usage considerations obviously)

Perhaps FBGfx should supply a FB.RegisterDecoder(@Decoder) interface, that way external libraries such as yetifoot's png_load could effectively act as a part of FBGfx, while still transparent to the users, and still without increasing dependencies for Gfxlib, that way FB programmers could even write their own custom format decoders.

let's see here, BLOAD currently checks the file format this way:

Code: Select all

	id = fgetc(f);
	switch (id) {

		case 0xFD:
			/* QB BSAVEd block */
			fgetc(f); fgetc(f); fgetc(f); fgetc(f);
			size = fgetc(f) | (fgetc(f) << 8);
			break;

		case 0xFE:
			/* FB BSAVEd block */
			size = fgetc(f) | (fgetc(f) << 8) | (fgetc(f) << 16) | (fgetc(f) << 24);
			break;

		case 'B':
			/* Can be a BMP */
			rewind(f);
			result = load_bmp(context, f, dest, pal);
			fclose(f);
			fb_hStrDelTemp(filename);
			return result;

		default:
			result = FB_RTERROR_FILEIO;
			break;
	}

simply reading a single byte and checking it against well-known values, if it doesn't match any, a run-time error is returned.

changing this to support what i suggest is simple...
Read a ushort instead, compare the first 2 cases using shifts, and compare the third to 0x4D42 ("BM"), if none match, the fourth case would be:

Code: Select all

		default:
			result = fb_GfxFindDecoder(context, f, dest, pal, decoder_options)
			break;

naturally "fb_GfxFindDecoder" will traverse through a table of registered decoders, calling each in turn, until one of them succeeds decoding the stream, if none found, it returns the normal error flag (FB_RTERROR_FILEIO)... or even a "NO_DECODER" one, doesn't matter..

So instead of the way PB implements it, there will be no bloat in compiler code, nor any namespace pollution, perhaps only 1 extra optional BLOAD argument (to pass data/flags to decoders or explicitly specify the decoder), while everything else remains intact..

about the memory decoding feature, an overloaded version of the function that accepts a pointer instead of a file name could be added too.. (changing the normal bload to load the whole file then call it if it can find a working decoder for the format for example).

Although I'm starting to think that this thread is going out of context, I still think that such a feature would make a great addition to FB, now and in the future, just my thoughts though, feel free to accept this or reject it, it's still a mere and incomplete proposal :)

[Tigra]

voodooattack, the new .bi file has an attribute parameter

Code: Select all

		asm .section sectionName,attr

Can you describe a little of its use, or point me towards a resource.

[voodooattack]

the attributes parameter allows you to set attributes for the section..
for example "r" is readonly, "rw" is read and write (you can change the file in memory), and "s" is shared (you can share any modifications to the file throughout multiple instances of your application in memory (if one instance changes something, the others will be updated with that change)

here's a small demo to show how it works:

Code: Select all

	#include once "crt.bi"
	#include "incfile.bi"
	
	incfileex( t, "incfiletest.bas", .sharedFile, "rws", 1)
	
	if *cast(zstring ptr, t) = "" then  ' check if the buffer is empty
		print "Buffer is clear, a previous instance cleared the contents!"
		sleep
		end
	else
		print *cast(zstring ptr, t) 
	end if
	
	
	sleep
	
	
	memset(t, 0, t_len) ' clear the buffer
	print "buffer cleared, try launching a new instance."
	
	sleep

I've updated the first post, fixed a small glitch with the attr parameter :)

[Landeel]

This is very useful. Thanks a lot!
But how do I retrieve the size of the inc file(s)?
(This is required to use with PNG_Load_mem)

EDIT:
Uh, sorry! Found it!
blahblah_len

[TbbW]

Actually, I'm hoping to eventually do all my setup stuff with the lua api. The real reason for using this with FBlua is so that if someone makes a game they can use incfile to compile their script into the .exe. That way, if someone wanted to cheat they'd have to use a hex editor or something in order to change the game variables.

you can still encrypt the script file with a simple xor just to make life hell for ppl that use hex editors :P
all you need to think about is to unecrypt it b4 you pass it to lua at load time :)
also if you want to make it even more slim then i know that fb got a built in lzo or whas it lzh compression that you can use to make you'r incany's even smaller instead of encrypting em that is :)

[Merick]

Maybe you're thinking of luac? luac compiles a lua script from a text file into bytecode. I haven't tried using it yet so I can't really say about whether it uses compression, but the compiled scripts are supposed to run a little faster.

[TbbW]

nah i whas just thinking of making the readable script less readable :P

[voodooattack]

Added a new IncArray() macro, check first post :)

[anonymous1337]

Added a new IncArray() macro, check first post :)

nice.

[notthecheatr]

I don't quite understand what IncArray() does... is it just including a file, except that it can be used as an array instead of a pointer?

[cha0s]

I don't quite understand what IncArray() does... is it just including a file, except that it can be used as an array instead of a pointer?

Yes, appears that way.

[voodooattack]

I don't quite understand what IncArray() does... is it just including a file, except that it can be used as an array instead of a pointer?

exactly, but instead of adding a '*_len' variable, you get to know the file size using lbound/ubound just like normal :)

it's basically the same as loading an array from a file using Get in binary mode, but instead of doing it at run-time, it happens at compile-time..

[notthecheatr]

Ah, OK. Thanks :)