PRACX v1.10 Release

[PlotinusRedux]

If I use the 1366x768 screen mode in PRACX, my terran.exe crashes when I press the left arrow key four times in a row to move the selected tile ('V', left, left, left, left, {crash}). This doesn't happen if I use 1024x768.

I've attached an Ollydbg capture of the access violation.

Just a cursory look at this, it has to do with 1366 not being divisible by 4.  That makes the pitch of each line 1368 (#bytes per line has to be divisible by 4 in a DIB)--somewhere it's not accounting for that difference between width and pitch.

Until I track down the exact place (and hopefully it's only 1 place), you can use 1360x768 instead of 1366x768 without encountering the problem and get almost the same visual experience, just a bit of delay switching in and out of full screen mode as it changes your screen resolution (I'm assuming 1366x768 is your native resolution).  Sucks to have that delay just to change your resolution by 6 pixels, though...

Any resolution whose width isn't divisible by 4 is probably going to have this same issue.  My worry is there may be more places with the same bug--for most resolutions, pitch == width since most resolutions have a divisible by 4 width--that was certainly true of their target resolutions of 800x600 and 1024x768, so any code where they mixed the two wouldn't have shown up as a problem before.

EDIT: So out of every recognized resolution between 1024 width and 2560 width--1024, 1152, 1280, 1360, 1366, 1440, 1600, 1680, 1776, 1792, 1800, 1856, 1920, and 2560, exactly one, 1366, isn't divisible by 4 and thus has a pitch != width.  If finding their mix up of width and pitch takes more than a few hours, I'll probably just remove 1366x768 as an option--1360x768 is close enough (though the game really looks bad in very wide screen resolutions anyway IMO), and anyone with a native 1366x768 display can curse the manufacturer for not giving them 2 more or 2 fewer pixels every time they have a wait an extra couple of seconds switching in and out of full screen mode.

(Of course that just applies to 8-bit color.  If I get the 32-bit color mod done, pitch will just equal width * BytesPerPixel for every resolution (since BytesPerPixel will be 4), and 1366 can be re-enabled.)

[TarMinyatur]

I prefer to use 1024 x 768 anyway. Thanks for checking it out.

[PlotinusRedux]

 1024x768=1.333... is a pleasant aspect ratio.  Oddly my native resolution of 2560/1440 = 1.77.... appears to have the same aspect ratio, though of course it doesn't.  Yet 1360x768=1.77083..., which lies between the two, gives an unpleasant stretched appearance, and has vertical letter bars--but that may be because it treats it as 1366x768 = 1.7786458333... aspect ratio.

In general on my box, anything <= 1.777... aspect ratio (with the exception of 1360x768, which isn't a real resolution, just a fake one to make 1366 divisible by 4) looks good, and anything every slightly above that, even 1.778, looks stretched and horrible and gets letter boxed.

1366x768 is a violation of nature that never should have existed, and when my son becomes emperor of the world, you can be sure the criminals responsible for such a crime against mathematics will be properly punished.

[Lord Avalon]

Gee, that's funny. I thought 1024x768=786,432. 

[PlotinusRedux]

Gee, that's funny. I thought 1024x768=786,432. 

Dividing to get the aspect ratio, not multiplying to get the number of pixels....  Which you knew.... 

v1.04 feature.  "if (0==strcmp("Lord Avalon", pszPlayerName) && fAboutToWin) MultiplyEnemyArmiesBy1000();"

Bad Spock.  You weren't even ever in this dimension.

[ete]

hmm, I'm getting a bug where while watching the AI play out long turns it jumps to windowed mode and displays a circle instead of mouse. If you click anywhere it gives an error about the program not responding, but you can see the turn going on in the background. My guess is windows thinks the program is unresponsive during the off-turn, and now has a way to un-fullscreen?

I've attached a save which demonstrates it for me, just hit end turn and wait. If your comp is so fast it does that one before unresponsive hit y for full vision, or I'll dig up a bigger save.

Were you able to reproduce this? I'm getting it moderately reliably at end of turn on larger games and it's definitely new with your patch. It triggers even without omniscient on if enough AI units are within your vision, as happens in mid-late game.

Screenshot of what happens:


Units continue to move in the background and it starts responding at start of your next turn, but sound is gone, it's harder to see what's going on, and you have to minimize/full screen again to get it back to fullscreen.


Also, the black areas bug seems to be back:

[Lord Avalon]

// if (0==strcmp("Lord Avalon", pszPlayerName) && fAboutToWin) MultiplyEnemyArmiesBy1000();

FTFY 

[PlotinusRedux]

Ete,

I haven't been able to reproduce it, even with "y", but I have a very fast system.

It happens when the message handler doesn't respond to a message for a few seconds.  It was actually probably happening before, but was just hidden behind the game window so you never saw it, and my changes are now allowing it to appear over the game window.  The window you're seeing there that appears to be the game window grayed out isn't actually the game window--it's a Windows generated copy of the game window called a "ghost window".

The proper fix would be to create a new thread devoted to handling the message queue so that even during long AI processing messages still get handled.  I might do something like that after Scient releases his IDA database--I'm kind of putting off any major changes until then, because it will be so much easier to do things afterwards.

However, there's a stop gap measure you can test for me--I don't know if it will work or not.

Save the attacked SMAX.sdb file to your Alien Xfire directory.

Start a command prompt and change directories to your Alien Xfire directory.

Run: "sdbinst SMAX.sdb -q"

If you don't know how to do the command prompt stuff, just let me know and I'll put it in a script you can just click to run.

Let me know if it works--if it does, I'll add it to my patch's install script.  All it is doing is adding an entry to the compatibility database setting the "noghost" property for terranx.exe.  What I don't know is if that prevents the "Not Responding" dialog altogether, or if it only turns off the ghost window part of it.

[ete]

Yes, that seems to solve it, thank you!

Edit: Wait, no, it apparently just did not trigger on the tests I ran. It's still happening, popup and all.

[Yitzi]

Question: Which files should I include in my patch in order to have it include yours?

[Yitzi]

Problem: I switched to a new computer, and transferred over all the files that looked like they were relevant to PRACX version 1.01 (which I'd had).  No PRACX.  I then installed version 1.03, still no PRACX.  I then uninstalled and reinstalled 1.03, still no PRACX.  Disabled is set to <Default>, so it shouldn't be that...

[PlotinusRedux]

Question: Which files should I include in my patch in order to have it include yours?

It depends on how much or how little of my patch you want to include.

To just be compatible (i.e., not overwrite the patch), you just need to have run pracxpatch.exe on the terranx.exe file you distribute.

To just include the Alien XFire part of the patch, you need the above, plus prax.dll, and the PracxChangeLog.txt file wouldn't hurt.

To include the full patch (i.e., for Alpha Centauri as well), you need the above, plus prac.dll and pracxpatch.exe, and run pracxpatch.exe on install to update the terran.exe file (or distribute a terran.exe file it's already been run on).

[PlotinusRedux]

Problem: I switched to a new computer, and transferred over all the files that looked like they were relevant to PRACX version 1.01 (which I'd had).  No PRACX.  I then installed version 1.03, still no PRACX.  I then uninstalled and reinstalled 1.03, still no PRACX.  Disabled is set to <Default>, so it shouldn't be that...

Hmm.  Check in Ollydbg to make sure terranx.exe has the patch code:

@0x00668160:
    call jmp_over
    _emit 'p'
    _emit 'r'
    _emit 'a'
    _emit 'x'
    _emit '\0'
jmp_over:
    call ds : _SMAXLoadLibraryA
    test eax, eax
    jnz  loaded
    ret
loaded:
    push eax
    push 1
    push eax
    call ds : _SMAXGetProcAddress
    test eax, eax
    jnz  callit
    pop  eax
    ret
callit:
    call eax
    ret

And
@0x00682000    dd 0x00668160

If that's there and prax.dll is in the same directory, you might try:

*http://www.microsoft.com/en-us/download/details.aspx?id=40784 and download and install vcredist_x86.exe

*run pracxpatch.exe at the command line and see if it gives an error message.

*put a break point 0x00668160 and make sure it gets to the "call eax"

*make sure the directory with prax.dll in it is the working directory when running terranx.exe

Let me know if you're able to resolve it with any of that or not.

[Yitzi]

Hmm...looks like it's not there.

I think what happened was I just ran the downloaded file, and not the pracxpatch.exe file it created.

Now I tried running pracxpatch.exe, and (after downloading the file to get rid of the missing dll message) it crashed...looks like for some reason it can't write to the image of terran/terranx on my computer...

And I just realized I forgot to re-install PRACX after downloading the file for the missing dll message...

[PlotinusRedux]

The install script runs it, but if you didn't have the VC files, it would have failed.

If you want, you can email me your latest terranx.exe and I'll run the patch on it and email it back.