Opened 18 years ago

Closed 18 years ago

Last modified 12 months ago

#194 closed defect (fixed)

interpolated graphics modes

Reported by: SF/logicdeluxe Owned by: SF/ender
Priority: normal Component: Graphics: Scalers
Keywords: Cc:
Game:

Description

Built on Apr 26 2002 13:06:42 win
The rightmost column is interpolated with the leftmost
one, but should not. For example it is very conspicuos
while the Monkey2 intro credits are running.

Ticket imported from: #549167. Ticket imported from: bugs/194.

Change History (13)

comment:1 by SF/ender, 18 years ago

With which modes in particular? advmame2x, sai2x,
supereagle, supersai2x?

comment:2 by SF/ender, 18 years ago

Owner: set to SF/ender

comment:3 by SF/logicdeluxe, 18 years ago

It appears in modes sai2x, supereagle and supersai2x.

comment:4 by SF/ender, 18 years ago

I just played through the intro credits with supereagle.. I
didn't notice a thing?

comment:5 by SF/logicdeluxe, 18 years ago

Here is a screen shot with super2xsai:
http://www.gratissaugen.de/files/mi2.PNG
Look at the right most column! It is a half bright version
of the left most column.
Now as I made the screen shot, I also noticed that the
bottom line is completely black.

comment:6 by SF/richiefs, 18 years ago

If you don't know how to modify the algorithm, replace the
last column by a black column

comment:7 by SF/ender, 18 years ago

Feel free to submit a patch to do so :P

comment:8 by SF/richiefs, 18 years ago

I'm ok to take a look at it.
But is someone can explain me what are the input and
output parameters of the SuperEagle function of 2xsai.cpp?

comment:9 by fingolfin, 18 years ago

The obvious source of the problem is the lack of
clipping in the scalers (which one can argue is by
design to gain speed).

These scalers interpolate each pixel with the 8 pixels
surrounding it. But for the leftmost pixel, the place
where the "left" neighbor would be (if there was one), is
actually taken by the rightmost pixel in the line above.
And vice versa. Hence it interpolates the leftmost line
with the right most line.

I can see two immediate fixes:
1) Add bound checks to the scalers for this. That would
cause a slowdown, though, and would probably be icky
to handle

2) Make the internal sdl_tmpscreen one pixel bigger in
each direction (one at the top, bottom, left and right),
and fill those with black. This would not cause
slowdown in the scalers, and IMHO would be the nicer
approach. I may give it a try later/tomorrow.

comment:10 by fingolfin, 18 years ago

I put a change to sdl.cpp according to plan 2 into CVS.
However, you might still not be fully happy with this, as
it now interpolates the outermost pixels with some
black pixels, resulting in a "dark" border. I personally
don't have a problem with this, but again, if you like to fix
this:

1) Once more, you can add special cases to the
scalers to handle the outermost pixels; pixels that are
"not there" (i.e. out of the bounds) could be assumed to
have the same value as their direct neighbor. But
again, I think this could lead to some messy code; feel
free to do it anyway, I may well be wrong :-)

2) As you suggested earlier, we could simply not
display the outermost pixels, resulting in a slightly
reduced screen size

3) The outermost pixels are interpolated with black
because the additional lines I added around the
graphic data in the temp buffer is black. But we could fill
that data with copies of the neighboring data - the result
would be the same as in 1 (visually at least).

comment:11 by SF/ender, 18 years ago

Closing this as 'fixed', as nobody seems to have any
complaints :)

comment:12 by SF/ender, 18 years ago

Resolution: fixed
Status: newclosed

comment:13 by digitall, 12 months ago

Component: --Unset--Graphics: Scalers
Note: See TracTickets for help on using tickets.