Opened 11 years ago

Last modified 12 months ago

#7645 new enhancement

Hi res vector graphics mixed with scaled bitmaps?

Reported by: SF/zorbid Owned by:
Priority: low Component: Graphics
Keywords: Cc:
Game:

Description

This is a bit far fetched, but with the SCI engine on it's way to be ported, and Cruise for a Corpse also sporting vector graphics, this (O)systemic suggestion seems timely...

The idea would be to
1) pass the various bitmap planes through a scaler,
2) render vector graphics at the scaled up resolution,
3) blit everything together.

I assume it would be resource consuming too, but big screen devices usually come with fast processors anyway...

Since implementing this most probably requires to put the current rendering pipeline on it's head I'm not even sure it's possible to do in Cruise), I don't expect to see it anytime soon... It would be nice to have nevertheless...

Edge anti-aliasing would even be better, although obviously more difficult and even more ressource intensive.

Ticket imported from: #2013269. Ticket imported from: feature-requests/461.

Change History (7)

comment:1 by SF/zorbid, 11 years ago

A opening parenthesis slipped before "I'm not even sure"...

comment:2 by sev-, 11 years ago

AGI had problems with it, so was Another World. The problem is that quite often rendered lines are used for collision detection, path finding etc. So the only option would be to keep screen rendering separate from internal representation, but this is a BIG task. Lowering priority, as perhaps some student on some GSoC could look into that :)

comment:3 by sev-, 11 years ago

Priority: normallow

comment:4 by fingolfin, 11 years ago

Yeah, the basic idea is of course sound and has been implemented before; but there are pitfalls to watch out (nothing unsolvable, mind you, but it is fairly complicated).

comment:5 by SF/zorbid, 11 years ago

Still building castles in the air, this scaler stuff mad me think that, assuming you separate rendering from internal representation you could apply scalers individually to backgrounds+depth masks, and to sprites/costumes, cache the scaled graphics, and blit them in high res only.

This would save a lot of scaler passes, hence allow to use heavier/smarter filters, and it should look better, since characters and background edges would be computed independently.

This is only about edge guessing filters, this wouldn't work/be of much use with other types.

comment:6 by SF/zorbid, 11 years ago

While I'm at it (then I guess I'll be done with aerial building design, this is even further fetched...), here is a scaling strategy that may have some potential but requires a ton of work:

1) Determine edges by weighting thresholded 2D derivative of the HSL layers (or more elaborate strategies, as described here : http://www.andrew.cmu.edu/course/16-720/lectures/filters.pdf).

2) Create a mask to separate pixels touching an edge from the rest. Apply a bilinear filter to non edge areas.

3) Use an heuristic similar to potrace (http://potrace.sourceforge.net/) on the blocky edges extracted in 1 to turn them into bezier curves. Potrace as is couldn't be used as is since it creates closed, black and white paths, but the curve fitting routines could be borrowed, they're quite fast.

4) Paint the edges zones according to the beziers from 3 and the colors of the edge touching pixels from 2. This may be very tricky. I can already imagine some of corner cases (how do you deal with close parallel edges? this may already prove problematic at step 3), and I can't think of a simple algorithm to do it fast and reliably... This is the "2) ..." part of the idea, just before you can "3) profit!".

The whole thing could be enhanced by dealing appropriately with high and middle spatial frequency edges...

BTW, I just realised that palette cycling animations and fade in/out effects would be hardly compatible with the idea in my last post :-(...

comment:7 by digitall, 12 months ago

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