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: Ronald Lamprecht
Subject: Re: [Enigma-devel] 320x240 support, need help
Date: Sun, 06 Jan 2008 21:47:37 +0100
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)

Hi Clarence,

I commited your diff together with the necessary fixes with r972 to the trunk.

Clarence Risher wrote:
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.

Of course I meant 'pixel'.

A few lines of code are necessary for the detection of missing images and scaling of 32 pixel images. But I did the same trick to get the 64 pixel running.

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).

You can put arbitrary scaled version of the data/gfx images and icons into the data/gfx16 folder. Copies found there are preceed the default ones.

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.

If graphic artists optimize some images for 16 pixel we will of course add them to the distribution. Other images will rely on autoscaling. A pure 16 pixel platform may distribute prescaled 16 pixel images.

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)

You did a really good job in digging through this code. Please be invited if you like to cleanup some menus like the quite dynamic level inspector.

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.

You copied the entries of a switched off resolution :-). You just need to add your new resolution as a valid part of the fallback string ("-10-0-"). I just notice that I did add it only to the window mode as I cannot easily test the fullscreen mode on my two headed Linux.

Greets,

Ronald




reply via email to

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