Greetings & Planned Patching

[PlotinusRedux]

Yep, that was me, Blue.  This should work in the Other Games lobby, but it's giving me a "host version is newer than yours" error, which is odd since I'm the host--I'll have to track down the problem there.

Wait, you made WarZone?
I played TA on that a few times. Lots of fun
Would be great to see someone play SMAC on it, the only lobby that exists for it as far as I know is GameRanger, which has most games that have ever had multiplayer though.

[Buster's Uncle]

Should this thread be in Bug/Patch?

[Buster's Uncle]

Incidentally, I'd suggest a simple improvement to the graphics would be to switch from .pcx to .gif.  If the palette issues weren't too difficult to hurdle, that might make some simple animations possible - a pretty revolting development, most likely, for leaderheads and bases, so-so for logos and diplomacy landscapes, but fantastic potential for the still units in units.pcx.  It would tend to make individual flies necessary for animated elements, so it would take a number of available optional file calls added into the code, so I doubt the animation part is feasible, but just sayin'.

[Flux]

Incidentally, I'd suggest a simple improvement to the graphics would be to switch from .pcx to .gif.  If the palette issues weren't too difficult to hurdle, that might make some simple animations possible - a pretty revolting development, most likely, for leaderheads and bases, so-so for logos and diplomacy landscapes, but fantastic potential for the still units in units.pcx.  It would tend to make individual flies necessary for animated elements, so it would take a number of available optional file calls added into the code, so I doubt the animation part is feasible, but just sayin'.

You know, I would love to have Civ 3 type animations of the leaderheads slowly blinking.
Those were great.

[Buster's Uncle]

Tough to carry off subtly, but definitely possible, given the capacity.

[PlotinusRedux]

Incidentally, I'd suggest a simple improvement to the graphics would be to switch from .pcx to .gif.  If the palette issues weren't too difficult to hurdle, that might make some simple animations possible - a pretty revolting development, most likely, for leaderheads and bases, so-so for logos and diplomacy landscapes, but fantastic potential for the still units in units.pcx.  It would tend to make individual flies necessary for animated elements, so it would take a number of available optional file calls added into the code, so I doubt the animation part is feasible, but just sayin'.

The problem with GIF is (1) it's limited to 8 bit color like the current PCX files, and (2) it's still a proprietary format you have to pay if you use in your code.

I'm actually thinking of two separate phases graphics-wise:

(1) Continue using DirectDraw, but switch the graphics files to PNG in 32-bit RGBA format with the height and width of each file doubled.  That will enable simple conversion of current files (just convert to 32 bit color, double the size, and apply some filtering to de-pixelate), allow for much more detailed shading and improved scaling due to the increased color depth, and alpha blending for shadows and smoother borders.

This can be achieved fairly quickly just by rewriting the LoadPCX function to load PNG instead and to double the size of offset of the source rectangle, and rewriting the sprite class to use AlphaBlt(), and will provide the greatest improvements for the least effort.

(2) I can't promise I'll complete this one, but I'd like to convert the entire graphics engine to DX 9 or OpenGL 3D with at least a wire frame for the terrain tiles, and possibly basic wire frames for units, etc.  That will let the engines built to handle distorting the terrain images into their non-square tiles handle doing so, and permit effects such as terrain lighting and shadows.

Animation could really be done at either stage without GIF just by allowing multiple images to be supplied for each object and looping through them, but I'll probably put that off to phase 2, or maybe a phase 1.B if I decide I just don't have time for phase 2, just because I want to get phase 1 out fairly quickly.

BTW, you're probably right about where I should have posted this thread--I won't be offended if a moderator wants to move it.

[PlotinusRedux]

So what I've got so far is:

*Smooth scrolling and zooming;
*Mouse wheel zooming;
*Mouse-over terrain and unit info;
*Display all tile output mode;
*Native ALT-TAB to switch between windowed and full screen mode;
*.INI setting for full screen resolution;

The most important thing graphically, though, is changing the input files and image processing from 8 bit color to 32 bit color with an 8 bit alpha channel.  That was going to be fairly easy by intercepting the calls to DirectDraw.  But it turns out all the graphics primitives have 2 paths--one using DirectDraw, and another using GDI or custom code--and the DirectDraw paths never execute, except to display movies.  I don't know if they tested it before releasing AC and found DirectDraw wasn't faster than GDI for 8 bit graphics and turned it off, or if it later had compatibility problems with DirectDraw, or if that's something GOG did because DirectDraw has been depreciated under Windows for so long.  That is true regardless of the DirectDraw setting in the .ini file--if it's missing or is set to 1, all DDraw is used for in addition to movies is to change the screen resolution to 1024x768x8 bit color.

DirectDraw is such an old interface, if AC isn't using it now, I don't want to go back to it.  On the other hand, GDI has no AlphaBlt that would use hardware acceleration for alpha blending, and all that custom shading and blitting code that's running on the CPU is going to execute 4x slower after rewriting it all to handle 32 bit color--

So I'm trying to decide now--almost all of the graphics code needs to be rewritten to support 32 bit color and alpha blending.  So do I do that with my own CPU based blitting and blending code, or do I just bite the bullet and go straight to the DX9 or OpenGL conversion so the GPU can handle that?  I'm leaning towards the latter--but does that mean also going 3d meshes instead of 2d images for units, bases, etc., at the same time?

[ete]

Possibly you missed my post, it was the last on the previous page?

Another .exe modder, excellent .

I have one major graphics pet peeve. From my latest game:

It seems to be related to playing small maps on a large screen with directdraw=0. Scrolling away and back will cause the tiles to re-render correctly, but it occurs at the start of each turn.

That game has a load of custom factions so may run strangely for you without them, I can either send it to you or try and get a save with standard factions.

I also hope you and Yitzi can work together and handle version control nicely. Ideally in a way other developers could plausibly be added to without horrible edit conflict issues, perhaps github or something similar?

I'm looking forward to 2, 3, and 5 especially.

That thing happening is my biggest issue with AC graphics, it would be amazing to have it solved.


And I think you're probably a much better judge about which approach would be most effort efficient and have the best results than any of us here.

[PlotinusRedux]

I saw the post, I just haven't run into anything would explain the defect, so there's not much I can say about.  If it extended to the top and bottom of the screen, I'd know exactly what the problem is--there are calculations for when the 0 X coordinate of the map is in view, to show the high X coordinate to the the left of it, and they get modified by calculations comparing the map * zoom to the screen width which would particularly come into play in the scenario you describe of small map and high resolution.

But nothing about any of that could explain the differences on the Y axis--why the areas above and below the black area aren't also black.

I just don't even have a plausible hypothesis for what could cause that yet, so I have no idea if anything I'm working on will fix it or not.

[ete]

It does start off extending to top and bottom, but as the screen moves around during the upkeep different parts are refreshed, the original screenshot was after upkeep. Perhaps this is a more useful screenshot?



The save is also attached, hitting end turn will trigger the bug.

[PlotinusRedux]

Yeah, ok, that makes more sense.  Probably the coordinates if you do tile info on that bottom left tile are going to be 1,1, in which case the code that detects when the entire map will fit on the screen is getting confused.  If not, it's a simple case of the system running out of GDI resources, which wouldn't be surprising--with direct draw off it's creating well over 1000 GDI resources, where a typical large program will create at most tens.  It's not even using GDI+, and the GDI just wasn't designed to handle that many graphical elements.  Either way, the DX9/OpenGL conversion should take care of it.

[ete]

Okay, cool. I wish you the best with that conversion then!

[PlotinusRedux]

Ete,

I've been able to consistently reproduce the defect and I have it fixed one my system.  I'd like you to check something to see if the same thing will also fix it on yours.

To reproduce the defect,

(1) Use Z to zoom until until the exact point at which you can no longer scroll the screen horizontally by hold on mouse at the screen edges;
(2) Hit X to back up the zoom once, to the first point where you can move the screen horizontally with the mouse;
(3) As you scroll through with the mouse, you see the updating, black parts of the map.

Now try the exact same thing, but at step (3) instead of scrolling with the mouse, scroll left and right with SHIFT-LEFT ARROW and SHIFT-RIGHT ARROW.  This time, you should *not* see the defect.

Assuming that works for you as well, I know what's wrong and how to fix it.  It has to do with rounding issues with the scaling, where one part of the code rounds one way and decides the map is big enough to scroll with the mouse and another part rounds the other way and decides it's too small to scroll, when the zoom factor is very close to line between them.

It does start off extending to top and bottom, but as the screen moves around during the upkeep different parts are refreshed, the original screenshot was after upkeep. Perhaps this is a more useful screenshot?



The save is also attached, hitting end turn will trigger the bug.

[ete]

Ete,

I've been able to consistently reproduce the defect and I have it fixed one my system.  I'd like you to check something to see if the same thing will also fix it on yours.

To reproduce the defect,

(1) Use Z to zoom until until the exact point at which you can no longer scroll the screen horizontally by hold on mouse at the screen edges;
(2) Hit X to back up the zoom once, to the first point where you can move the screen horizontally with the mouse;
(3) As you scroll through with the mouse, you see the updating, black parts of the map.

Now try the exact same thing, but at step (3) instead of scrolling with the mouse, scroll left and right with SHIFT-LEFT ARROW and SHIFT-RIGHT ARROW.  This time, you should *not* see the defect.

Assuming that works for you as well, I know what's wrong and how to fix it.  It has to do with rounding issues with the scaling, where one part of the code rounds one way and decides the map is big enough to scroll with the mouse and another part rounds the other way and decides it's too small to scroll, when the zoom factor is very close to line between them.

When following your instructions:
1, fine
2, X zooms me out, so I am still unable to scroll by pushing the mouse against a side of the screen. Assuming you mean Z, which zooms in and allows me to scroll with the mouse at edges.
3, Moving the screen by clicking the mouse to recenter the screen at that zoom level massively triggers the bug, often nearly entirely blanking the screen. Clicking end turn (which recenters the screen) also triggers badly at this zoom level. Both scrolling to the side by moving the mouse against the edge and using shift+arrow does not trigger for me.

Additional observation: Recentering on a location near the corner of the current screen triggers it worse and more reliably.

I think you've found the problem! Very happy to hear you've got a solution too. Are you using Yitzi's latest patch as your base to work from?

[PlotinusRedux]

D'oh, yeah, Ete, I reversed zooming in and zooming out, it should read:

(1) Use X to zoom out until until the exact point at which you can no longer scroll the screen horizontally by hold on mouse at the screen edges;
(2) Hit Z to zoom in once, to the first point where you can move the screen horizontally with the mouse;
(3) As you scroll through with the mouse, you see the updating, black parts of the map.

Reworking the zoom code to adjust to screen resolution has fixed it for me--basically now it computes the zoom out level that will first show the entire map and sets that as max zoom out, computes the zoom in level that will show 6 tiles horizontally and sets that as the max zoom in, then adjusts the other zoom levels to fall evenly between the two.

I'm doing my changes a bit differently from Yitzi because I want my changes to work with both SMAC and SMAX, but I will make sure it is 100% compatible.  The only .exe changes are about 20 bytes to load the ac2.dll file that contains all my actual changes for both, the the .dll figures out which was it's been loaded by and hooks API's and modifies code in memory to work it's magic.  So Yitzi will just need to change those 20 bytes in his .exe once, and after that just downloading ac2.dll will get all my latest changes.  We'll just have to coordinate if we both want to modify the same function, but the nature of our different focuses--UI on my part and game logic on his part--that will probably be rare.