small incbin issue
BlitzMax Forums/BlitzMax Programming/small incbin issue
| ||
| I can do this: Incbin "weapons.png" But not this: path$="weapons.png" Incbin path$ The compiler says it's expects a "string literal" but encountered a identifier. (Anyone explain what that means =) ) Also incbin does not use lower() on the path, so Incbin "Weapons.png" does not work.. Same goes when you Load: a = Loadimage("incbin::imagename"), where it fails if incbin is written with any capitals. Is this a bug/something to be fixed/ or am I useing the command in the wrong way? |
| ||
| Ah this answers a problem I had with incbin as well.. I think its goto be a bug cos nothing else is case specific. that I know of anyway. and I think by literal it means Constant, as Path$ is not a constant it wont compile. |
| ||
| The compiler says it's expects a "string literal" but encountered a identifier. (Anyone explain what that means =) ) A "String literal" is just that. Something that is literally a string. Not a variable or constant that contains a string, but an actual string. Is this a bug/something to be fixed/ or am I useing the command in the wrong way? Well the lower() bit seems to be a case of 'using it the wrong way'. Since you've supplied Incbin with a string literal, you already know the case of the filename. MacOS and Linux are potentially case-sensitive, thus it is adviseably to only use lowercase latin characters for filenames. |
| ||
| Since IncBin is done at compile time it only accepts actual string constants ( string itself ). There is no use for anything like a variable or similar for it as the incbin can't change at runtime ( -> after compilation ) |
| ||
| Yah, you can't incbin with path$ because path$ is a probably set up as a variable - it would imply that you had the ability to change path$ at runtime to change what is incbin'd, which doesn't make sense (or, if it makes sense, it isn't a supported functionality). I don't know if you could, however, do Const path$="weapons.png" incbin path$ If you were trying to use path$ as a variable so that you can load in several files in some kind of loop, you can't use incbin for that. Incbin is only to embed file data at compile-time which can later be extracted at runtime. And to extract it you need to give it a constant name. You might think well, why the heck can't I use a variable. My guess is, because the compiler has to keep track of the address within the executable that the file is stored and does it with a number but also internally stores the file's name/path as a complimentary thing (or throws it out at compile time) ... so the location is probably hardcoded in the compilation. I'm not sure how I feel about inbin'd files.. .great to make a single exe but having to refer to each file with a filename rather than like a numerical value. |
| ||
| That explains it. And I do think it should work with constants, cause I have a series of types which controls my media. Each instance/image have a path$. It is constant but it would feel better to not have to do IncBin manually, but it's not like it's important or anything. MacOS and Linux are potentially case-sensitive, thus it is adviseably to only use lowercase latin characters for filenames. That was good to know, I always write filenames with mixed Caps =) And latin, does that mean the entire ascii table or not included ~^'´ôà`? I guess this doesn't matter if I include my files in the binary? (Assuming I only code in win) |
| ||
| Good question. If we want files to be properly loaded on all three platforms, is there differences in naming conventions and forbidden characters etc that can't be allowed? For example, in osX you are allowed to have a file with a / in the name, but this isn't acceptable in msdos. ? |
| ||
| For example, in osX you are allowed to have a file with a / in the name, but this isn't acceptable in msdos. You are?!? But that's the directory seperator! There's no reason why IncBin shouldn't work with Const constvar$="whatever", if it doesn't then I dare say that's an oversight on Mark's part. I also agree with AngelDaniel, returnhandle=IncBin("whatever") would be a better implementation too... but then there's the question of how to handle the loader... currently it takes a string in the form of "incbin::whatever" how would a numerical equivalent be handled..? |
| ||
| the returnhandle would be totally useless ... the handles you get later are of a different type then this one so it would ( or could? difference is 0 ) create some quite "unnice" problems with numerical collisions. |
| ||
| As it is now it doesn't work with Const Path$, I was a little unclear above. returnhandle=IncBin("whatever") would be a better implementation too... Agree, and it shouldn't be to hard to implement. The only differenct when loading the image is "incbin::" incbin("file.*") Const Path$ = "file.*" IncBinPath$ = "incbin::"+Path$ Image = LoadImage(IncBinPath$) I think this would give more freedom: IncludeFile=incbin("file.*")'Probably returns the number of the include file. i.e the first file would return 1, all data is kept in a list. So the include adress and binary stuff could be "hidden" Image = LoadImage(IncludeFile)'Loads the included file at specified number in the includelist, if it is an image then success! This is how imagehandles works isn't it? Because you can drawImage(1) ' for first image or Midhandleimage(1) 'again for image 1 |
| ||
| Good question. If we want files to be properly loaded on all three platforms, is there differences in naming conventions and forbidden characters etc that can't be allowed? Yes, there is definately an issue with character encoding. In western countries, Win32 and Linux users will typically use Unicode or ISO 8859-1 (Latin-1). The Mac ofcourse uses something entirely different.Thus to be on the safe side only use the lowercase latin letters of the English alphabet, and numbers. Try to avoid spaces, underscores and hyphens too. |
| ||
| Underscores should not be a problem. A to Z a to z 1 to 9 and _ - is what I use. |
   |