Suggestions for Nyerguds C&C TDawn 1.06c

[cncfan 0]

Regarding that Level 1-3 thing:

The only real way to fix this is to remake these missions and place them in the top left area of the 64x64 map.

When you tried that (you said it didn't work) did you also set TacticalPos= under [MAP] in scg01ea.ini to another value (don't know how to interpret the numbers), but this should be the point the screen is focused to.

Changing this value should have no effect even on lower resolutions since the map is so small that it fits nearly completely even on a 640x400 screen.

Could this fix the doubled gunboat or make it less visible?

I know this would not wipe out the fact that the game does no redrawing, but probably it could eleminate that scrolling-"jump"....

 

I actually tried to rebuild the map with pseudo terrain but this broke the gunboat-script (it does not came back after reaching left screen border)

 

Regarding the 1024xXXX correctvideoar=false thing:

I am glad that you like the results after all, but you did realize that the resulting video height now only depends from cncddraw height but not at all from C&C95 Highres Height anymore?

If that's ok for you - fine.

Edited February 3, 2011 by cncfan

[Nyerguds 100]

TacticalPos isn't used by the game in any way, as far as I know. I don't know what effect you think it has, but I'm pretty sure it doesn't do it. It's an unused leftover of Dune II. In Dune II it determined the start screen position. In C&C, that is waypoint 26. Which has no effect at all when the map is smaller than the resolution. It always simply shows the entire map. The only difference between pre-scrolling and post-scrolling is that it first shows it with the last passable cell on the lower right corner, while scrolling switches to showing the first passable cell in the upper left corner. In both cases, the entire map is on the screen though.

 

As for how the cell numbers work, it's pretty simple... each line of the map is 64 cells, so first line is 0-63, second line is 64-127, third row is 128-191, etc... It's simply one large array of 4096 (64*64) cells.

 

 

And yeah, I know the correctvideoar behaviour... the setup tool now only enables it if the resolution is 1024x and ddrawheight is the same as the hiresheight. So, only in non-deformed hi-res. It works great; resolutions like the laptop-fix 1024x600 get their videos centered & corrected that way

 

 

btw, I released some pics on the moddb profile of the patch

http://www.moddb.com/mods/command-conquer-...di-score-screen

[cncfan 0]

Ok then.

It's a pity that we can't fix this thing though....

 

At first I want to say thank you for your cooperation. This whole thing got a lot better with your help and support as it had been without you.

Keep up your good work, Nyer!

 

Best wishes from my side.

 

One last thing though ;-)

Since I'm playing the game right now, have you ever wondered about GDI level 9?

It's the thing where Carter says: Destroy the turrets and I will come with my ships and put the nodbase to dust.

However if you destroy these turrets the ships indeed come but get blasted away by the obelisk.

Even if you have destroyed the obelisk before (to save the ships) they won't fire to anything within that base...

Is that the way it's meant to be or is this a scripting bug in that level.

I've been asking this myself before, can't remember this had been different ever....

[Nyerguds 100]

Thanks

 

As for GDI mission 9.... the mission is just meant to show off the Obelisk. It's that simple. There's actually a code exception on the gunboat that prevents it from attacking anything on GDI mission 9. I haven't actually found this, but I tested it thoroughly.

So yes, that's entirely meant to be that way. Not too subtle, but still exactly how it's supposed to work.

 

Story-wise, it's also to kill off Carter

[cncfan 0]

This is the final release of my changes.

(Only code formatting and version string update done since last release, nothing else changed)

 

This is the version I give back into HIFI's hands.

 

cncddraw_2011-02-04

 

Changelog 2011-01-10 -> 2011-02-04

-new option resizevideo=true

distinguishes interlaced from noninterlaced content

removes scanlines and scales videos to fullscreen on High Resolutions

 

-new option resizevideofilter determines which scaling filter to choose for interlaced content (linear,nearest)

(no effect if resizevideo=false)

 

-new option correctvideoar=true does aspect ratio correction for all interlaced content

(if resizevideo=false correctingamear is used for interlaced scenes as well instead of correctvideoar)

 

-new option correctingamear (disabled by default)

does aspect ratio correction for all non interlaced ingame content

if true you should use at least 480 cncddraw height output for 640x400 C&C95 output to avoid downscaling

if true you should use at least XXX*240/200 cncddraw height output for 1024xXXX C&C95 output to avoid downscaling

 

Using correctvideoar and/or correctingamear you can play C&C95 at any display ar (4:3 , 16:10 , 16:9 , 5:4)

without losing actual display content since letterboxing is supported

 

- new option vqphack (disabled by default)

corrects colour display for (interlaced content without solid fonts) = cutscenes with corrupt VQP files

If you don't need it, keep it disabled (since it consumes more CPU)

you'll know if you need it, believe me

 

-added version string to ini file creation routine

 

-please note that deinterlacing on europe,africa mission selection screen will not work flawlessly with

Nyerguds C&C95 1.06c r1f1 and older, you need to upgrade to newer versions to get best experience on these screens

with old versions there will be some scanlines left on these screens

 

Best Regards J.Henze aka cncfan

Edited February 4, 2011 by cncfan

[pichorra 4]

I don't know what OS did use to compile it, but here it is saying there's a Missing DLL, the Zlib1.dll

 

OS: Windows XP Professional SP3 (32-bits)

Edited February 4, 2011 by pichorra

[cncfan 0]

This is caused by the need to link libpng dynamically. HIFI uses this for his screenshot function.

I did not get to work static linking.

It depends on some other dlls since, and the result is different on every computer (since every system has other dlls and some might be missing)

As far as I know only libpng3 and zlib1 are affected.

 

When HIFI does a new compile on the (unaltered) code you will be able to play without additional dlls.

Because the libraries he is using are all statically linked.

 

Until then, download the missing dll from here

http://www.dll-datei.de/zlib1.dll,4741

and put it into C&C95 directory.

 

[EDIT:] I included libz1.dll to the package.

 

Sorry for the inconvenience.

Edited February 4, 2011 by cncfan

[pichorra 4]

None problem.

 

This thing looks very Nice with the winDOwS mod! i really can feel now the DOS style on it!

[Nyerguds 100]

Ah, I've had someone else with the zlib problem too... glad that that'll be fixed when hifi merges it.

 

btw, Pichorra, I can get you a full beta of the new patch if you want... beta testers are always good to have

 

----

 

cncfan: I tested it in RA, and it seems to work perfectly

 

(RA95, windowed, 640x400 stretched to 640x480)

(ant missions briefing video )

[pichorra 4]

not entery for me:

 

But i think it is a problem with my videocard... it is Old (GeForce 6200 LE)

 

[Edit]

 

Forget it, it was did by a corrupt MIX file.

Edited February 4, 2011 by pichorra

[cncfan 0]

Hello Nyer,

 

after playing through the whole two campaigns in German Language (GDI was fine)

I noticed a bug in the NOD campaign.

 

South Africa map selection screen does make interlace detection fail.

English version is NOT affected but german is.

 

Tested with my latest release and your 1.06c r2 beta.

Screen Resolution 1024x768

 

It's the CovertOpsBoxCheck that triggers this misdetection.

For you to remember:

 

    int x=ddraw->width>>1; //center in x
    int y=(ddraw->height>>1)+1; //center in y, take next odd line
    if (
           (((unsigned char *)ddraw->primary->surface)[y*ddraw->primary->lPitch + (x-30)*ddraw->primary->lXPitch]!=0)
        && (((unsigned char *)ddraw->primary->surface)[y*ddraw->primary->lPitch + (x-10)*ddraw->primary->lXPitch]!=0)
        && (((unsigned char *)ddraw->primary->surface)[y*ddraw->primary->lPitch + (x+10)*ddraw->primary->lXPitch]!=0)
        && (((unsigned char *)ddraw->primary->surface)[y*ddraw->primary->lPitch + (x+30)*ddraw->primary->lXPitch]!=0)
       )
        return 0; //we found a briefing box

 

We check these four pixels to be <>palette #0

 

This is also true for this screen in the german version. It's caused by the solid fonts - not by the image.

 

Maybe this is a problem for other solidfonts scenes in other languages/resolution combinations too!

For german version however this is the only point that makes problems (in 1024x768).

 

This bug is resolution and language dependent.

 

So we need to make the covertopsboxcheck more strict. (=check for more pixels within the box to be <> palette#0)

Can you propose other pixels to check too of the current used ones that WILL NEVER FAIL on any solidfontscreen for ANY language pack.

We would need a pixel that is ALWAYS transparent on South african map (never filled by fonts) but is never transparent at the covertopsboxes.

Are there places that are never filled by fonts? (maybe between neighboured letters, they are all displayed with exact inbetween spaces)

Read on before thinking!

 

Any proposal?

 

Here is a screenshot of the scene and a savegame at the end of the mission before:

southafrica.rar

 

Please note that game resolution (1024xXXX) treats covertopsboxes DIFFERENTLY to solidfontscreens.

covertops are displayed fullscreen, solidfontscreens are 640x400....

This will lead to pixel (xmiddle,ymiddle) be always the same for covertopsboxes but DIFFERENT pixels in solidfontscreens if C&C95 resolution changes.

Choosing specific pixels within the box should be hard to impossible therefore....

You see this thing is not resolution independent atm!!!

 

 

2 possible solutions without changing C&C95.exe

 

A extend boxcheck for the following checks (check if a transparent column is present in the frame): [not possible]

choose a single specific column (eg. column 0 or column 1)

check all pixels for y=0..399 (enough since we only mess around with solidfontscreens that have maxheight 400)

if pixel.palette!=0

and not (pixel.colour==black or pixel.colour==white) //mouse pointer

then {goto thisisnotabox}

return this is indeed a box

:thisisnotabox

return this is not a box

 

pro:

-makes boxcheck really resolution independent (atm it is not)

 

cons:

-would require covertopsboxes to have maxwidth to keep a column free (is this true?)

-up to 3 checks per pixel = 400-420 checks per column (one column should be enough)

still should not slow down vids and solidfontscreens since loop break should come in very fast (mostly after first pixel)

but 400-420 checks for covertopsboxscreens (is not THAT much)

-mouse pointer needs to stay how it is forever, if other colours in pointer, covertopsboxdetection will fail when moving mouse to left screen border

-EDIT: This proposal is not possible because it would break (non-german) coming attraction screens

 

If we would choose line 0 instead of column 0 this would break german coming attraction screen.

 

 

B extend boxcheck for the following checks:

Simply check the whole minbox instead of just four pixels to be <>palette 0

 

pro:

-only one check per pixel

-should keep all coming attraction screens intact as long as they have enough height to be within the box

 

cons:

-you said the boxes have minwidth of 178, but what's minheight?

-minwidth*minheight additional checks (but maybe more checks for movies,solidfontscreens than proposal A, since break might kick in later!!!!)

-still no guarantee that this will always work on any res/language (but would be much more probable)

(could potentially misdetect solidfontscreens again, since not resolution independent, i think 640x400 would be most critical)

 

 

C solution including C&C95.exe editing

 

If you could make pixel(x=0,y=1) be nontransparent for covertopsboxes there would be no need anymore for the heuristic covertopsboxcheck at all.

This would also require to force non-german coming attraction screens to have x=0,y=1 and x=10,y=1 to be not transparent via C&C95.exe.

If both can be achieved, I would wipe out covertopsboxcheck from the code.

 

pro:

-fastest solution

 

cons:

-more glitches with older C&C95 versions (german coming attraction screens will not be scaled up in 1024xXXX)

-more glitches with older C&C95 versions (covertopsbriefingboxes will be unreadable in 1024xXXX)

(since original C&C95 does not support Highres, these bugs will only affect older Nyerguds releases)

 

What do you think?

 

 

Update:We investigate version C atm, looks as if Nyerguds is able to do the needed changes.

Edited February 9, 2011 by cncfan

[pichorra 4]

in true, this bug afects all languages, but english. (French, German, Portuguese)

[Nyerguds 100]

Right... result of our testing and chatting sessions...

 

1. The briefing text screens now have their background cleared with real #12 black, so no more special exception code is needed for them. This solves the problem mentioned above.

2. To make sure the English and French Coming Attraction screens don't get stretched, the CPS files were edited so the black around the actual image is not in the palette colour #0.

3. There is a bug in the map selection screens that causes the targeting lines of the top missions not to display correctly. This bug has been in the game ever since the very first C&C95 version, and, as far as I can see, can't be fixed. It's caused by the black rectangles drawn over text to remove it. Most of these get removed (on image content lines anyway) when the image refreshes, but for this scene that hasn't happened yet, so they're still there.

[cncfan 0]

cncddraw_2011-02-09.rar

 

This release should fix some solid font screens being detected mistakenly as ingame (eg South Africa in german 1024x768)

Nyerguds C&C95 1.06c r2 beta 4 or newer recommended

 

cncddraw 2011-02-09 videoresize,deinterlace,vqphack,aspectrario by J.Henze (based on official 2011-01-10 by HIFI)

 

official changelog: 2011-01-10->2011-02-09

-new option resizevideo=true

distinguishes interlaced from noninterlaced content

removes scanlines and scales videos to fullscreen on High Resolutions

C&C95 1.06c r2 beta 4 or higher recommended (see restrictions section for details)

 

-new option resizevideofilter determines which scaling filter to choose for interlaced content (linear,nearest)

(no effect if resizevideo=false)

 

-new option correctvideoar=true does aspect ratio correction for all interlaced content

(if resizevideo=false correctingamear is used for interlaced scenes as well instead of correctvideoar)

 

-new option correctingamear (disabled by default)

does aspect ratio correction for all non interlaced ingame content

if true you should use at least 480 cncddraw height output for 640x400 C&C95 output to avoid downscaling

if true you should use at least XXX*240/200 cncddraw height output for 1024xXXX C&C95 output to avoid downscaling

 

Using correctvideoar and/or correctingamear you can play C&C95 at any display ar (4:3 , 16:10 , 16:9 , 5:4)

without losing actual display content since letterboxing is supported

 

- new option vqphack (disabled by default)

corrects colour display for (interlaced content without solid fonts) = cutscenes with corrupt VQP files

If you don't need it, keep it disabled (since it consumes more CPU)

you'll know if you need it, believe me

 

-added version string to ini file creation routine

 

Restrictions (only for old versions of C&C95, 1.06c r2 beta 4 and newer are NOT affected):

-deinterlacing on europe,africa mission selection screen will not work flawlessly with

Nyerguds C&C95 1.06c r1f1 and older (also original C&C95) will leave some scanlines on these screens

-covert ops briefing boxes will be scaled up mistakenly when playing in HiRes (1024xXXX)

this affects only old Nyerguds C&C95 versions, since original C&C95 from Westwood does not support HiRes

-GERMAN coming attraction screens won't be scaled up in HiRes (1024xXXX)

this affects only old Nyerguds C&C95 versions, since original C&C95 from Westwood does not support HiRes

 

 

If no new bugs should occur within 7 days I will post this version to HIFI again.

 

Hints for beta testers:

TDawn should work very well now.

Please test Red Alert very carefully.

Look for scenes that are not scaled correctly when C&C95 HiRes 1024xXXX is chosen.

Maybe there are Briefing Boxes for missions like the TDawn Covert Ops Briefing Boxes.

Is all content scaled correctly?

 

Best Regards cncfan

Edited February 9, 2011 by cncfan

[Nyerguds 100]

I just looked into your code a bit... and, well, seems to work nicely and all, but...

 

good gods man, you use GOTO in your code? that's just plain horrible! No programmer should EVER use that

 

If I knew a bit more of C syntax I'd clean that up a bit... really though, a bit of refactoring in that dodeinterlacing function could solve all of that. There's no reason for that giant 'if'; just make these 2 huge chunks in the "else" of (isinterlaced==0) into separate functions (processvqphack and processnovqphack), replace the "goto" by just returning False, and check on that return value to see if you still need to execute the "processnovqphack" function.

 

So kinda like this...

int dodeinterlacing(int* tex)
{
    int isinterlaced=choosedeinterlacingmode();
    if (isinterlaced==0)
    {
        int i,j;
        // ... normal uninterlaced content drawing code
    }
    else
    {
        bool executenovqphack=true;
        if (ddraw->render.vqphack==1)
           executenovqphack=!processvqphack(tex);
        if (executenovqphack)
           processnovqphack(tex);
    }
    return isinterlaced;
}

 

yes, you'd have to redefine your i and j and your pixel definitions in each of the two 'process' functions, but that doesn't seem like a huge problem. Overall this would make the code a lot cleaner.

[cncfan 0]

good gods man, you use GOTO in your code? that's just plain horrible! No programmer should EVER use that

Although I totally agree with you in that point, I just have to say:

 

LOOOOOOOOOOOOL - the assembler crack is bothered about gotos. This is indeed funny.

 

In fact I could clean up the function a lot by eleminating those gotos, I thought of that by myself before too.

They were not there from the beginning but were introduced by changing the code over and over again.

 

Altough I could change this thing, I would do it in another way than you proposed:

Instead of seperating vqphack from novqphack i would rather seperate 640x480 from non 640x480 code parts.

This would shrink down codesize considerably (even more than your proposal).

 

But note that the current solution is the fastest you can get, having two functions will force additional stack overhead.

Furthermore the only thing you would really get is replacing the goto by a break.

 

Although the code would be easier to read then, both will get a jmp in assembler later. So nothing is really gained beside better code readability at the expense of (really small) speed impact.

 

I will do it if you like, though (because I know using goto is really bad style).....

Edited February 9, 2011 by cncfan

[Nyerguds 100]

It's not because IF become a conditional jump in asm, that I don't still use clean jumping in my asm code

 

Also, a return statement doesn't become a jump in asm; it's just a RETN. Even in asm, actual function definitions are still a real thing.

 

And if you're talking about speed impact, I don't think one small boolean check beats redefining that pixel type definition on each run of code that is ran 15 times each second. I don't think type definitions belong inside functions, personally...

 

 

 

If you know a better way to fix it, by all means, go ahead, but really, this goto stuff is quite awful coding.

[cncfan 0]

At the moment I optimize the hell out of the code with great success.

But I have been asking myself a question...

Since you seem to know a lot about assembler, you maybe know which one of the following versions is the fastest:

pinterpol is a union of size int
pinterpol.value fills the whole union size, therefore it is an int
|| means logical OR (I know that C code will not perform the second check if the first one is found to be true)
But I am not sure if two array lookups are performed if the first one is false. (Maybe the result of array lookup is stored in a register for the second check???)
Do you understand the question?

first:
(how many array lookups are performed in sum for then and else branch, assuming ==0 check fails?
   2 for then and 3 for else?
or 1 for then and 2 for else?
or 1 for then and 1 for else?
if (   (surface[(i+1)*width + j]==0)
    || (surface[(i+1)*width + j]==2))
      pinterpol.value=foobar;
else pinterpol.value=palette[surface[(i+1)*width + j]];

second: (is this better or worse compared to the first?)
switch (surface[(i+1)*width + j])
{
case 0:
case 2:
  //true
    pinterpol.value=foobar;
  break;
default:
  //else
   pinterpol.value=palette[surface[(i+1)*width + j]]
}

third: (definetely only one array lookup, but explicit storage performed)
pinterpol.value=surface[(i+1)*width + j];
if (   (pinterpol.value==0)
    || (pinterpol.value==2))
      pinterpol.value=foobar;
else pinterpol.value=palette[pinterpol.value];

 

What is the fastest solution?

I tend to use the third. But this is just feeling...

 

Edit:After talking with Nyer I decided to use that

int palettevalue=surface[(i+1)*width + j]; //I hope palettevalue is only stored in a register but not in memory TRUE?
if (palettevalue==0 || palettevalue==2)
   {
      pinterpol.value=foobar; //foobar is more complex
                tex[(i+1)*width+j]=pinterpol.value;
   }
else
   {
      tex[(i+1)*width+j] = palette[palettevalue]; //only place where palettevalue is used after the check
   }

Edited February 9, 2011 by cncfan

[Nyerguds 100]

Yeah... third usually gets black, in which case nothing else will get checked.

 

Internally, explicit or implicit storage makes no difference at all anyway; if you got something that needs to be calculated it will be stored somewhere, be it in a register or a function variable. It just depends on the compiler, how long it needs to be stored and how many registers are needed by other actions that happen while the value is in use.

[Nyerguds 100]

I think I'm going to remove 640x480 as "compatibility resolution"; simply removing the black bars and making it use the full screen just like 1024x768. If that works, I could go on to simply allow the user to set any game dimensions, without being restricted to the resolution enum that's currently being used.

 

Not sure what that means for the dll though... since RA will still have 640x480 with the black bars :-\

[pichorra 4]

I think I'm going to remove 640x480 as "compatibility resolution"; simply removing the black bars and making it use the full screen just like 1024x768. If that works, I could go on to simply allow the user to set any game dimensions, without being restricted to the resolution enum that's currently being used.

 

Not sure what that means for the dll though... since RA will still have 640x480 with the black bars :-\

 

I was going to ask you that, but you already learned to read the others mind...

 

But remember! if it make the C&C95 incompatible with my ancient PC's i'm going to Blame you

[Nyerguds 100]

Psh, you just go find a better Kernel Extension then

[pichorra 4]

cncfan, could you make the ScrenShots able to be saved in somewhere else (like C&C95/SShots)?

[Nyerguds 100]

That's hifi's code though. Though I think it'd make a great ini option

[AlexB 8]

Even though you made it clear you can do it yourself in just a few minutes time in the other thread, I'd still ask: How about deinterlacing the background images before the font is drawn onto it? It would make all the special handling redundant and solve the subobtimal stretching of fonts.