I just took a look at this. I checked out the
double_size branch, fast-forwarded to the latest master and added the data files that David attached to the first post. I also removed the .DAT extensions from the data folder names.
I noticed that only the top left quadrant was being rendered. I managed to fix this by multiplying the surface dimensions by SCALE in make_offscreen_buffer().
Some observations:
Images that are not there in the DOS version:
PRINCE.DAT: res174-183 are added (potion bubbles for green and poison potions, apparently)
PV.DAT:
* res931 is added (princess standing)
* res963-965 are added (alternate torch frames, just for the princess cutscene?)
VDUNGEON.DAT: res220-229 are added (are these rough tile edges?)
VPALACE.DAT:
* res220-229 are added (rough tile edges?)
* res244 and res245 (blue stripes) have part of the tile below them (as opposed to res324-325)
* res348 added (don't know what this is)
Other differences:
* Level door (res233) is in one piece.
* The font does not seem to distinguish between small and capital letters.
Bugs:
* Naturally, SDLPoP isn't aware of the extra resource images that exist in the Mac graphics.
* Lots of objects are drawn slightly in the wrong place.
* Guard palette changes do not seem to be working correctly.
* The leveldoor is buggy: can see a slur of the image above the door (doesn't get redrawn properly).
* Transparency isn't always working. This seems to happen because the non-transparent blitter is used for some images, whereas the Mac version apparently uses transparency for that same image.
* Potion bubbles do not get drawn properly.
* Health flasks and text at the bottom of the screen are drawn slightly too low, causing them to partly fall off the screen.
* The health flasks are drawn too close together.
* The shadow is a bit weird.
Another thing I noticed:
Animations are sometimes a bit 'wobbly', e.g: look at the kid's feet during the turning animation, or the kid's y-position during standing jump animation. (If I remember correctly, the original Mac version has this as well)
Norbert wrote: ↑November 25th, 2016, 10:35 pm
David wrote:Or just start with the DOS graphics scaled to 2x, and let modders change them as they will.
This sounds like the easiest solution. If all PNG images are scaled 2x without interpolation - ImageMagick can do this in bulk - then even scaling it back to 1x with SDLPoP ("nearest" SDL_HINT_RENDER_SCALE_QUALITY) should give the program an unchanged appearance. After that, mods that use DAT files can be assumed to use 1x and for mods that use PNG files SDL_QueryTexture() could be used to check the height of a PNG image to determine the scaling factor.
Upscaling the DOS graphics to 2x would of course work (whether by preprocessing the images beforehand, or by upscaling while loading the 1x image), but it may cause some other inconveniences. For the 4:3 aspect ratio and integer scaling features, I expect that we would need twice the monitor resolution to get the same effect. Another disadvantage is that we would pay the CPU cost for double-resolution rendering, even though this is really not necessary for DOS graphics.
Also, modifying the Mac data files will not really help much to get the Mac graphics working properly, because the differences between the Mac and DOS files still need to be accounted for: extra images that are not in the DOS version, transparency differences, potion bubbles, possibly negative image drawing offsets, all that. It is looking like the best thing to do is to simply account for the remaining DOS/Mac differences in the source code.
Maybe in the end there should be a setting that specifies whether DOS-style or Mac-style graphics are used? (Maybe distribute the Mac data files in a separate folder?) Then modded images could be assumed to be 2x when Mac graphics are specified.
