Opened 19 years ago

Closed 19 years ago

Last modified 2 years ago

#194 closed defect (fixed)

interpolated graphics modes

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


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, 19 years ago

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

comment:2 by SF/ender, 19 years ago

Owner: set to SF/ender

comment:3 by SF/logicdeluxe, 19 years ago

It appears in modes sai2x, supereagle and supersai2x.

comment:4 by SF/ender, 19 years ago

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

comment:5 by SF/logicdeluxe, 19 years ago

Here is a screen shot with super2xsai: 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, 19 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, 19 years ago

Feel free to submit a patch to do so :P

comment:8 by SF/richiefs, 19 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, 19 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, 19 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, 19 years ago

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

comment:12 by SF/ender, 19 years ago

Resolution: fixed
Status: newclosed

comment:13 by digitall, 2 years ago

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