On Dec 31, 2007 11:47 AM, Ronald Lamprecht <[EMAIL PROTECTED]> wrote: > BTW you did not attach the compressed svn diff! Please email it directly > to me as the size may be too large for the mailing list.
Now I feel stupid... the file should work on the list (just 10k without images), but just in case I am CCing you. > There should be no need to scale the 32 bit images to external 16 bit > files. Enigma can scale down not existing 16 bit images from the 32 bit > ones. I did the same trick for the new 64 bit based resolutions. This > saves space on the svn and marks clearly which images have been > optimized for the new resolutions. I am confused when you say 'bit', you mean 'pixel'? If so, great. I am not sure how to set up the models-16.lua file to pull from both locations, but that shouldn't be hard for an experienced dev, and you'll have to do it if you don't duplicate my gfx16 folder. > You may still distribute scaled 16 bit images with a 320x240 Enigma > version. > > data/gfx16/thumbborder.png If you can make scaling work from the 32pixel images then thumbborder.png is the only one that really needs to be scaled down, because just cutting its size in half isn't quite right (it should be approx 68x48, not 64x43). I will probably distribute pre-scaled 16 pixel images with the gp2x port, to save size (and I won't include the larger ones), but they may not be required for other platforms. On that note, I do have some ideas for better automated prescaling. I want to put together a script that will take a 32x32 tile and scale down the middle 16x16 by 25%, and the outer 8-pixel border by 75%, illustrated below at half scale (as if scaling 16 to 8): AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAABBBBBBBBAAAA AAAABBBBBBBBAAAA AAAABBBBBBBBAAAA AAAABBBBBBBBAAAA AAAABBBBBBBBAAAA AAAABBBBBBBBAAAA AAAABBBBBBBBAAAA AAAABBBBBBBBAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA becomes AAAAAAAA ABBBBBBA ABBBBBBA ABBBBBBA ABBBBBBA ABBBBBBA ABBBBBBA AAAAAAAA this seems like it will better preserve the important parts of the majority of the tiles > Besides problems with menus not fitting on the 320x240 screen the > support of the new resolution should be limited to a few lines of code. > Please test your 320x240 support in the window mode. In full screen mode > SDL will refuse to switch to 320x240 if the graphic does not support > this resolution. In this case the base resolution is chosen. You are correct. Getting the resolution itself to work (mostly) was just a few lines of code. Getting the menus to work, where 90% of the element sizes have hard coded minimums designed for 640x480, was a few hundred more lines of code (with conditionals added) With my .enigmarc.xml set to use mode 10 in full screen and windowed mode then it works in both, and I can change to/from fullscreen at will (320x240 is a valid resolution for my X server). But if I try to change from any other resolution to 320x240 from the options menu, in full screen or windowd mode, I get 640x480. I hope someone can help with that problem. ... (really really attaching the file now, almost forgot again!)
320x240.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Enigma-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/enigma-devel
