PRACX v1.10 Release

[ete]

Yup, that's the answer.

I feel silly now.

Problem solved! Yay for scrolling!

[PlotinusRedux]

Lol, Mart, you're better at giving support for my patch than I am.

[Buster's Uncle]

Mart has many uses.

[PlotinusRedux]

This is really great!

I would be very interested in modifying the source to try to add sensible upscaling. Is that something you want to do yourself or do you want to let others try?

I'd be glad for you to try that, Draz, but understand this will just be the source code for my DLL's, not the full game.  I haven't pulled over enough functionality in that area from the .exe into the .dll to really do upscaling yet, but if you read assembly and want to pull that functionality in yourself, that'd be great.  If not, I plan to pull over more functionality over time.

I'm curious, though, upscaling could mean a couple of things in this context--do you mean upscaling in terms of the UI elements (larger font sizes and windows and such), or upscaling in terms of adding bilinear or better scaling routines to the map itself?

[PlotinusRedux]

I just updated the install program at the top to v1.01 to fix a few of the issues people have reported here.  It's great to get so much feed back--I've had to beg for defect feedback on other projects.

Change log:

v1.01 (12/10/2014)
=================
Minor fixes to the v1.0 release:

*Fixed "WindowsFileBox=1" .ini setting causing full screen to switch to windowed mode on load/save;
*Fixed <V>iew mode not displaying tile info on mouse-over in SMAX;
*Fixed scaling issue with resource icons in Resource Mode for wide aspect ratios;
*Fixed "Please don't leave" dialog showing up after switching between windowed and full screen mode;
*Improved Zoom Increment calculation so that 0 zoom always lies exactly in the middle.  A side effect is the number of
Zoom Increments must now always be odd.  Even values will be rounded up to the nearest odd number;
*Added this note that <ESC> is the key to use to skip movies now;
*Window close box now acts as though the <ESC> key was pressed instead of minimizing the window.

I think that's everything that has been reported--if I missed something, please remind me.

[DrazharLn]

This is really great!

I would be very interested in modifying the source to try to add sensible upscaling. Is that something you want to do yourself or do you want to let others try?

I'd be glad for you to try that, Draz, but understand this will just be the source code for my DLL's, not the full game.  I haven't pulled over enough functionality in that area from the .exe into the .dll to really do upscaling yet, but if you read assembly and want to pull that functionality in yourself, that'd be great.  If not, I plan to pull over more functionality over time.

I'm curious, though, upscaling could mean a couple of things in this context--do you mean upscaling in terms of the UI elements (larger font sizes and windows and such), or upscaling in terms of adding bilinear or better scaling routines to the map itself?

I'm looking for ways to apply suitable image scaling algorithms to the map and UI elements (or maybe just a whole framebuffer) dynamically. I previously tried to do this with a replacement directdraw library, but I don't think AC2 actually used the library a whole lot, and, as I mentioned before, videos completely broke it.

I understand that the source code would be just for your dll.

You seem to be messing with at least the map rendering calls quite a lot, so your code may well already contain the kind of thing I want to access.

[PlotinusRedux]

That's correct, most of the scaling and all of the shading was done directly in code--direct draw (apart from the videos) was really just used as a way to vsync the final update to the screen.  I just removed the last calls to it--they're pointless on today's hardware.

I was thinking of a few options in that regard. 

(1) A big part of the problem isn't the scaling or rendering code per se, but the fact that the source textures are limited to 256 colors.  Just getting rid of that limit alone would do wonders.  The source textures are actually pretty decent resolution in terms of width and height.  I really think this would do more than anything to improve the game's appearance.  Unfortunately, all the shading and rendering code is hard coded to 8 bit color, and reworking it all will take some work;

(2) Some of the scaling is done with calls to StretchBlt and StrechDIBBits, which are horrible.  I was thinking of maybe just replacing those with DirectX 9 calls to take advantage of bilinear or better scaling routines;

(3) The best result would come from doing a full DirectX 9 conversion, converting the Cavier 3d models to a standard format and replacing all the custom rendering and shading code with letting DirectX do it which would have the added benefit of breaking the 8 bit color limit without have to refactor all that custom code.

That's just where my thoughts were headed on it.  I'll be posting the source code sometime in the next week, take a look at it and then we can talk again.  If you come back with "I could do X if only the source code exposed Y from the .exe", maybe I can add Y to it and let you run with it from there.

[DrazharLn]

My original aim was just to try and get a frame buffer for SMAC's screen, rendering at SMAC's intended resolution of 1280x768 (or whatever) and then scale it up appropriately for modern screens (with black bars at the sides).

With the zoom in your patch, it's more clear that the underlying problem is the textures themselves, and I concur that upgrading the texture rendering and providing better textures is probably the best way to improve the appearance of the game.

As a quick fix, though, I think it would be sensible to render the game at a smaller resolution (so that UI elements and so on are appropriately sized), then scale this and render it for modern monitors. This would have the effect of hiding some of the bad textures with blurring, hopefully removing some aliasing, while also making the game playable at very large resolutions (like mine (2560x1440)).

(My current best solution is to reduce my desktop resolution to 1440x900 and then play the game, but that's not so great and definitely draws attention to aliasing on textures and the map grid.)

This seems easier than working out how to resize all the UI elements and interactions, but I don't know what you have access to.

As for replacing with DirectX calls, would it be worth using openGL instead? OpenGL is obviously available for more platforms and might make it easier to port your improvements.

Unrelated, GOG decided to prevent alt-tab with sdbinst. The GoGwiki has instructions on how to restore it. I think just using that is a better solution than mapping tab to toggle window.

[PlotinusRedux]

Draz,

Yeah, I've definitely exposed enough to do that, as it's basically what I have to do to run it in windowed mode:

(1) Hooked GetSystemMetrics to report to the game we're running at whatever resolution we want it to scale to itself;
(2) Hooked GetCursorPos and the mouse messages in WinProc to scale them from screen to client coords before passing them on to the game;
(3) Hooked the final BitBlt the game uses to copy the backbuffer to the screen.  In my case I replace it with a StretchBlt in windowed mode.

That should be enough to accomplish what you propose, just replacing that StretchBlt with your scaling code and use the Windowed mode coordinate conversions even when running full screen.

BTW, on "My current best solution is to reduce my desktop resolution to 1440x900 and then play the game"--you can change the full screen resolution in the PRACX prefs and it will at least automatically switch your desktop in and out of 1440x900 as you switch in out of windows mode, or start and exit the game.

I'll be interested to see your results.

[DrazharLn]

That sounds great, Plotinus. I'll have a crack at it once you're ready to release the source.

I really appreciate you explaining here what your code does: it'll make my work a lot easier.

Ultimately, it would probably be sensible to split rendering for the map and UI up: the map should probably be rendered with scaling appropriate to zoom level and UI should be scaled appropriate to resolution (probably should be configurable too). (And then the two buffers should be composited together).

Does your code receive the map and UI calls independently?

Thanks for the advice about PRACX preferences.

[PlotinusRedux]

Does your code receive the map and UI calls independently?

Not currently, as I didn't have all the classes and functions identified at the time.  Once Scient releases his IDA database, I plan to go back and add all the classes and functions the to C++ header file so any of them can be called and/or overridden.

[Lord Avalon]

While I appreciate the work you put into this, I have to say I prefer the old way the scroll wheel worked in the city build screen, where it moved everything up or down.

Also I'm wondering if you might know how to keep the cursor within the game window when in fullscreen mode? Right now I'm using Primary Lock to keep it on my main monitor (rather than having it go offscreen to the side of my second monitor).

[PlotinusRedux]

Lord,

I hadn't noticed what the mouse scroll did on the city screen.  I can change it to pass the wheel through when that screen is up.

There is a windows call to set a bounding rectangle for the cursor.  I only have one monitor hooked up, though, I'd be leery of messing with that without being able to test it.

[Yitzi]

Your patch appears to cause a stretching of the menu screen and of the map on my laptop screen dimensions.

[PlotinusRedux]

That should depend on the screen resolution you pick on the preferences window, Yitzhak.