Gamer125 / fofix

Automatically exported from code.google.com/p/fofix
0 stars 0 forks source link

Allow arbitrary extensions for compatible file types #941

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
The idea behind this is to open up support in themes to use any file type
supported by PIL (not just pngs or even jpegs)

For every image file we load, we first pass the filename (without
extension) through
a function which checks for the existence of a file with the name we give
it and a
list of known supported filetypes.
It then tacks on the extension we find and loads that file as normal.

Another possibility might be to search for a file named "whatever.*" and
try loading it. If it fails, find the next one and if it can't find any
then mark loading as failed (and fall back or error depending on the file)

Original issue reported on code.google.com by death.au on 21 Aug 2009 at 10:22

GoogleCodeExporter commented 9 years ago
PIL supports over 30 Image formats.

so there are 2 ways to implement Image loading:
1) restrict to allow a few important types (BMP, GIF, JPEG, PNG, TIFF) and 
check file
extension manually
2) just try to load every file, don't check type, and catch unsupported types 
via
exceptions

im for nr 2)

and i like the idea of loading filename.*
it would be easy to implement
--> self.loadImgDrawing(self, "star1",   
os.path.join("themes",themename,"star1"),
textureSize = (128, 128))
just use the filename without extension, and then the first found file gets 
loaded
-Problem: a filename has to be assigned to a Image
(eg: atm there is cassette.dae and cassette.png - the first one would be the dae
file, which is not a image)
so you would need another check - OR easier: just rename one of the files ;)

if you agree to that suggestions, i could change the necessary code

Original comment by max26...@gmail.com on 22 Aug 2009 at 12:36

GoogleCodeExporter commented 9 years ago
With the "cassette" example, I imagine it would find cassette.dae and then fail 
to
load it (as it's not a supported filetype in PIL I would think) but then 
perhaps go
back and load cassette.png.
Instead of trying to load just the first file it finds, it would load all the
matching files in some sort of queue, until it loads one or fails on them all.

Original comment by death.au on 23 Aug 2009 at 1:17

GoogleCodeExporter commented 9 years ago
ok, i have some code, which allows loading images without having to add the 
extension
(like suggested in comment 2)

btw:
Are SVG files still supported or deprecated?

Original comment by max26...@gmail.com on 23 Aug 2009 at 12:10

GoogleCodeExporter commented 9 years ago
TODO for myself: Review and apply the following patch from max26199.
It does most of the work required to fix this issue.

Original comment by evily...@gmail.com on 21 Sep 2009 at 3:39

GoogleCodeExporter commented 9 years ago
Oh, here's the patch from Max26199.

Original comment by evily...@gmail.com on 21 Sep 2009 at 3:39

Attachments:

GoogleCodeExporter commented 9 years ago
I just had a look at the patch (haven't tested it because I need to get to 
work).
I think I prefer the "if not load" to the "try loading catch exception" method. 
But
shouldn't then svg.py return false if the image fails to load, rather than 
raising an
exception? Or did I just fail to see how that works?

Original comment by death.au on 21 Sep 2009 at 10:05

GoogleCodeExporter commented 9 years ago
A few thoughts:
1) The image loading needs to break loops that are used to load images. If 
keytex_e
exists, the game will act as if key textures exist (even if, for whatever 
reason,
only keytex_e does) - this is a problem in Guitar and Drum with textures and 
tails
(though for tails it's more of a speedup than a necessity).
2) It may be worthwhile in the data loadImgDrawing to call
os.path.splitext(filename)[0] before doing the loop on extension checking. This 
lets
us declare a default filetype without attempting to load .dae before .png (while
still letting us load .jpg, should a theme-creator wish), for example.
3) I look forward to your committing this for yourself, max!

Original comment by aked...@gmail.com on 21 Sep 2009 at 10:31

GoogleCodeExporter commented 9 years ago
> I look forward to your committing this for yourself, max!

Perhaps he could, had you actually given commit access to "max26199" (as I'm 
sure you
intended) rather than "maxx.h2"...

Original comment by john.stumpo on 22 Sep 2009 at 1:26

GoogleCodeExporter commented 9 years ago
Nope, Max has two accounts. I asked Max which account i should use before 
adding him.

Original comment by evily...@gmail.com on 22 Sep 2009 at 1:31

GoogleCodeExporter commented 9 years ago
@akedrou: thx for hint #1
#2: i changed it so loadImgDrawing can be called like this:
loadImgDrawing(..."versiontag.png") - will try png extension, and if not found:
search extension
loadImgDrawing(..."versiontag") - will search directly for extension
is that what you ment? - i think its good to stay with calling loadImgDrawing 
with
ext, so the code calls can stay unchanged

@death.au: if PIL cant load the image, it will raise an IOException, which is 
cought
by loadImgDrawing which then returns False
(Data.loadImageDrawing - Svg.py:ImgDrawing.__init__ - Texture.loadFile)

code committed in r1893 - further testing required

Original comment by maxx...@gmail.com on 22 Sep 2009 at 10:16

GoogleCodeExporter commented 9 years ago
how should code like this be handled?:
    if not os.path.exists(os.path.join(themepath,themename,"notes.png")):
    (Data.py line 86)
    (code where no image is loaded, just checked if it exists)

a) force extension on some files - not the best way imo
b) try searching and opening the image with PIL, but not load it
(Data.getImgDrawing(fileName)) - PIL has to open the image 2 ore more times, 
less
performance
c) search file and extension but not check with PIL if it is actually an image, 
just
look if filename.* exists

Original comment by maxx...@gmail.com on 23 Sep 2009 at 6:13

GoogleCodeExporter commented 9 years ago
I'd say C.
The code in question basically just checks if it's a theme, so in this case if 
it
finds the file and all then it's recognised as a theme, then when it tires to 
load
the image later and it doesn't work, it's the same as trying to load any other 
image
in the theme.
I assume if similar code is used elsewhere, it would be for similar reasons as 
well.

Original comment by death.au on 23 Sep 2009 at 9:22

GoogleCodeExporter commented 9 years ago
i think r1904 should support almost[1] all images with various extensions

[1]: notes.png is fixed, as i am unable to call data.checkImgData() in
GameEngine.py-line381
i think that code (lines 375-396) should be moved to a proper location inside a
class? if yes, could somebody do that?

Original comment by maxx...@gmail.com on 24 Sep 2009 at 4:05