enigma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] 320x240 support, need help


From: Clarence Risher
Subject: Re: [Enigma-devel] 320x240 support, need help
Date: Mon, 31 Dec 2007 12:24:59 -0600

On Dec 31, 2007 11:47 AM, Ronald Lamprecht <address@hidden> 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!)

Attachment: 320x240.tar.gz
Description: GNU Zip compressed data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]