CoM II: Graphics Enhancement

[htester]

This thread was made to collect any suggestions to improve Graphics on CoM II. I made a small research on pixel art and probably most filters will work better if screen is reduced (I know... common sense but...) and possibly keep the "dark edges" as we have in current dosbox version of CoM I. If someone knows a better way to enhance graphics and keep the full screen please share. My current suggestion is to reduce screen size and add one of the filters (hqx) used on current dosbox version of CoM I. Here a list of sites about the algorithm:

http://blog.pkh.me/p/19-butchering-hqx-s...lters.html
https://code.google.com/archive/p/2dimagefilter/
https://github.com/grom358/hqx/

[Seravy]

These seem to be all requiring the scale to be an integer number, but we have a freely resizable window that doesn't keep aspect ratios, which I consider a much more important feature. So these are useless but I have to add they are also seem insanely complex and there is no way I'm going to even attempt them. I can probably finish the entire spell system overhaul in less time than understand one of these.

If that helps any, this is the current code that puts the image on the screen :

Code:

begin
wi:=MainForm.ClientWidth;
he:=MainForm.ClientHeight;
Bitmap.Width:=wi;
Bitmap.Height:=he;
py2:=-1;
for y:=0 to he-1 do begin
 l:=Bitmap.Scanline[y];
y2:=(y*200) div he;
if y2<>py2 then begin
py2:=y2; px2:=-1;
for x:=0 to wi-1 do begin
x2:=(x*320) div wi;
if px2<>x2 then begin
px2:=x2;
pc:=Fastbitmap.Pixelcolors[x2,y2];
b:=c2[1];c2[1]:=c2[3];c2[3]:=b;
end;
lrgb[x]:=pc;
end;
end;
move(lrgb,l^,wi*4);
end;

Even something this simple seems to consume 9% CPU time and that was 20% before I added the feature to skip the lines and columns that are exactly identical to the lines and columns before and thus can simply be drawn by using the same data again.
Also these are numbers for my (relatively small by today's standards) 1280*1024 screen where I use a game window of a similar but smaller size of 960*720. People with wider screens will likely want a window size that's twice as big.

I wonder, would something as simple as averaging the two colors for any pixel that's an "extra" inserted between the original pixels work? Possibly weighted by "distance" from the two pixels, for example if a pixel is pixel 127.32 in the original image then it's the average of 0.32*pixel 127 and 0.68*pixel 128? I'm afraid even that would probably put us in the range of 30 FPs though...

[Cruel100]

This link brings a video that compares the filters used in DOSBOX:

https://www.youtube.com/watch?v=wuT7cF3VG2w

The only one that doesn't appear to have a scale is the "supereagle". But I don't know the technical details.

[roarmalf]

but we have a freely resizable window that doesn't keep aspect ratios

I actually prefer a resizable window that does keep aspect ratios if the window is just stretching. If the gameplay area were changing to match the new window (e.g. you can see more map tiles) then a freely sizable window would make a lot more sense, but since everything is just stretched maintaining the aspect ratio while resizing is IMO just better.
That said, I'm sure there are others that get just as frustrated with a locked aspect ratio, and I can always choose to keep mine the same (although an option to "lock aspect ratio" would be welcome). 
Likely not relevant to the discussion about filters, but more for the general graphics thread.

[Seravy]

Yeah the problem with the aspect ratio is that there are two correct ones.

It's 320x200 which is 16:10 BUT it was fullscreen on the old 4:3 screens so it's also correct at 4:3. Screens back then uses nonsquare pixels.

I've tried to find what's supereagle but it's basically just a generic term for all filters of that kind. I don't think one that works on any screen size exists and even if it does, it might be too slow.

https://en.wikipedia.org/wiki/Pixel-art_...algorithms

Maybe using a different approach could help, like scale up using the filter only when there is a new pixel inserted, and keep the original pixel otherwise. But that's undefined for the case when more than one pixel is inserted. I'll probably need to come up with a new algorhytm for this.

[roarmalf]

2 general suggestions:

1. Colors: trees, ground, etc. should use colors not already in unit sprites. I don't know what color limitations we're under, but giving myrror ground a slightly lighter and redder hue would help.Trees should avoid black as much as possible. Don't use draconian/giant lizard green or wild boars/war bears/earth elemental brown for any environmental tiles as those units are mostly those colors.

I can help provide specific color suggestions for certain things if it's helpful, but I don't know what our limitations are.

2. Shadows: currently shadows are big, like it's late afternoon. What happens if they get changed to something like it's 11:00? Short shadows, that don't infringe on adjacent tiles could help a lot with clarity.

[Slingers]

Everyone probably already knows this and it doesn't help here, but there are many programs on the Internet that convert any kind of image into pixel graphics, 
like this one for instance: http://pixelatorapp.com/

[Seravy]

I can help provide specific color suggestions for certain things if it's helpful, but I don't know what our limitations are.

No limitations, CoM II used 24 bit colors. I do want to keep the colors as close to the original as possible which makes me wonder why this wasn't a problem there.
Did the combat tiles for Myrror use different colors than the overland? I think mine uses the same for both.

These are the currently used colors for the two planes, 6 colors each

Code:

(($24754D,$415169),
($3C5D3C,$38455d),
($388E61,$3c4149),
($044524,$10345d),
($105D38,$303c51),
($247524,$450445));

(It's in the order of BGR, not RGB)

Everyone probably already knows this and it doesn't help here, but there are many programs on the Internet that convert any kind of image into pixel graphics,

No, I didn't know that. It could make creating global enchantment images trivial, possibly even the summoning sprite for the new creatures.

2. Shadows: currently shadows are big, like it's late afternoon. What happens if they get changed to something like it's 11:00? Short shadows, that don't infringe on adjacent tiles could help a lot with clarity.

If you can provide a formula for shorter shadows that still looks okay, let me know.
These are the two formulas for the two versions posted in the alpha thread :

Code:

x3:=-y2+(x2 div 2);
y3:=-y2-((x2+sgn(x2)) div 2);
---------------
x3:=-y2+x2;
y3:=-y2;

x2 and y2 are the pixels distance from the image's axis - basically the point where it's supposedly touches the ground.

Each result has to be unique (if two pixels put their shadow on the same spot, that area gets darker than the rest) and should keep the shape of the original object recognizable. The shadow has to go towards the bottom-right direction otherwise it would overlap with already drawn stuff. The formula should be simple otherwise it'll slow down the game too much.

[Cruel100]

Everyone probably already knows this and it doesn't help here, but there are many programs on the Internet that convert any kind of image into pixel graphics, 
like this one for instance: http://pixelatorapp.com/

Cool, also I didn't know.

[roarmalf]

Did the combat tiles for Myrror use different colors than the overland?

After reviewing



I think the major differences are:
1. Original tiles all had a definite saturation of green or red/orange
2. Your tiles have a much higher concentration of maroon/purple (old combat river color, which is different from overland) in them. Neither of those things should really impact the visibility of units all that much.

I think it's more likely that the high quantity of foliage and the fact that it's the highest layer (or at least it cover units, so I assume it's layered above the units) are a bigger cause than color.

That said, I think the tiles should remove that purple color (old rivers) altogether, and make green patches in higher numbers and up to twice as large (but keep the small ones too).

Re: shadow coding, I have no idea how that works, but I do understand some amount of coding (but not graphical) and shadows shouldn't be too complicated to shrink. I'll poke around online and see if I can figure out what that code does and how to tweak it.