Suggestions for Nyerguds C&C TDawn 1.06c

[cncfan 0]

You mean with the beta patch, and with the updated updata.mix I put in one of my previous posts?

Yes with the new beta it works (kind of, maybe not...).

With old 1.06c r1f1 you'll see estonia effect, as expected.

 

With or without the new updata.mix has no effect on this - works both in 1.06c r2beta...

 

All tests are done with vqphack disabled in the ini (should make no problem, however, just to be precise)

 

TEST EUROPE:

I tested lowres 640x480 (this worked) used the old ccsetup.exe to set up.

1024x768 works too (used old ccsetup.exe to set up).

I tested 640x400 with old ccsetup (does work)

I DON'T HAVE ANY STRIPES THROUGH ESTONIA ANYMORE.

 

Although I have the feeling that the blue GPS cross that displays is not fully visible (there is missing a small part where the fonts were before (top left of the screen), has this been in this way ever or is this something "new" introduced by our palette #2 thing? True for all resolutions.

 

My algo does as you told me to though, can you maybe fix that in the exe?

 

TEST AFRICA:

640x400 (old ccsetup) black stripes get visible for a fraction of a second [not through the whole picture in x though, but only where the text has actually been] (text is still visible at this moment). Both text and black stripes disappear then forever. The moment i have the mouse cursor is fine. - this is definetely not as it is supposed to be) My fault? Your fault?

The text that is affected is "Definiere Aktionsgebiet" in the german version. It's just a fraction of a second, barely noticable at all...

Other text that crosses africa is displayed correctly. Did you simply forget something?

BTW: Maybe different selected languages will lead to different problems.... I play in german.

 

 

HOWEVER I HAVE NO CONSTANT STRIPES THROUGH AFRICA ANYMORE.

 

 

I tested this using my old savegames from 1.06r1f1 end of gdi 1. This shouldn't make any difference, should it?

 

 

 

 

I can only conclude from this that you check on palette colour #0 at the edge of the GAME content, instead of checking for #0 or #2, on the right-side edge of the 640x400 video frame.

 

 

EDIT:

INTERLACING CHECK FOR 640xXXX:

Sorry, I was wrong: In fact, I do check for palette, not for colour. If the palette values of neighboured odd lines differ, frame is detected as NOT being interlaced (ingame). This is strange. In fact, If you really would write palette #2 in this line, the palette values of odd lines WOULD differ... And therefore the whole picture in fact HAD TO BE DISPLAYED INTERLACED if you would do everything correct. This does not happen.

I agree with you that i should maybe change this check back to <>black-check, but this seems to prove that you DO NOT OVERWRITE X=639 Y=ODD with palette #2 at all (or you overwrite the whole COLUMN with it)!!!!

THIS CHECK IS ONLY DONE FOR 640xXXX. In 1024 mode i do detect "no interlaced frames" by searching outside the 640x4x0 box if something is there....

 

EDIT AGAIN:

I remember now, why i scan for palette change and not for colour change anymore. This should adress the fading bug in lowres modes.

 

Finally, to summarize things up: I don't think you actually write palette #2 into this column (other than suggested by your picture)

 

Code segment:

x=639;
for (y=3; y<(ddraw->height); y+=2)
  if (   ((unsigned char *)ddraw->primary->surface)[(y-2)*ddraw->primary->lPitch + x*ddraw->primary->lXPitch]!=
     ((unsigned char *)ddraw->primary->surface)[y*ddraw->primary->lPitch + x*ddraw->primary->lXPitch])
   {//this thing is ingame, not interlaced}

 

 

INTERPOLATION CHECK:

The interpolation does work as expected. I check for palette #0 or #2 in both cases the pixels gets interpolated (from top,bottom pixel) else it is stored as it is.

So the fact that some pixels are stored as they are must be, that the game does not send them as palette #2 or #0.

 

Code Segment:

if (   (((unsigned char *)ddraw->primary->surface)[(i+1)*ddraw->primary->lPitch + j*ddraw->primary->lXPitch]==0)
    || (((unsigned char *)ddraw->primary->surface)[(i+1)*ddraw->primary->lPitch + j*ddraw->primary->lXPitch]==2))
   {//interpolate pixel}
else {//take pixel as it is}

 

Maybe you should do a new screenshot to check the palette values of the pixels i get.

 

 

How did you test? Did you get the same results as I? Or do you have other problems?

Have you vqphack disabled or enabled?

 

btw, ingame 1024 goes incredibly slow when played fullscreen, compared to windowed. do you have any idea what could be causing that?

Hmm this should not be caused by me (directly) because there is absolute no difference in MY code sections between fs and windowed. I never have anything to do with this stuff. Probably FS is more resource hungry...? I don't know, you'll have to ask HIFI for that...

I think the problem is that your computer has only one core. Since C&C95 is running always at 100%, ddraw.dll won't get enough power I think.

Maybe Windows manages cpu time differently if an app is fullscreen, i don't know. All i can do is keeping my code quick (i have another idea for this but would like to ask hifi a question first, since i don't want to restrict extendability of ddraw.dll.

 

But let's talk about that palette #2 thing first....

Edited February 1, 2011 by cncfan

[Nyerguds 102]

I had VQPHack disabled, and the lines on that screenshot are unedited; the only edits were the palette, and my added notes. It's my latest beta patch installed on a clean C&C95, but I didn't change anything related to drawing those lines; It has always drawn these lines beyond the 640 width. I tried to change that, but it didn't work.

 

The screenshot was taken by pressing ctrl+s on the selection screen, and the colours were then made visible by editing the colour palette using Paint Shop Pro. I haven't found any settings on 640x400 or 640x480 on which the black lines don't appear on the mission selection screen. And it only happens after the game draws those long lines I indicated on the screenshot.

 

 

By the way, since I'm planning to eventually add 800x600 too, could you PLEASE not make different logics for different resolutions? If you only check the 640x400 box, everything should work the same way for any game resolution.

 

 

[edit]

 

Eh, and what exactly is the purpose of that first code segment?? It just checks if the palette index changes... why? If this code is ran BEFORE the second piece you show, then the screenshot I showed will never pass your "is ingame?" check. I think you should just check whether the "0,1" pixel is palette colour #0, that should be all the indication you ever need to confirm it's not ingame. None of the text stuff ever overwrites that, and ingame that's ALWAYS the real black (colour 0x0C) of the Options bar at the top.

(of course, AFTER passing that check you should do the 3-point covert ops briefing screen check, but that's irrelevant here)

[cncfan 0]

I haven't found any settings on 640x400 or 640x480 on which the black lines don't appear on the mission selection screen. And it only happens after the game draws those long lines I indicated on the screenshot.

I play the german version. You maybe not. Could that make a difference?

Did you test with my RC1 build on 2011-01-31 or with beta9?

I am talking about RC1.

I don't have constant black lines with RC1 and your r2beta anymore.

I had them when using 1.06cr1f1.

 

 

By the way, since I'm planning to eventually add 800x600 too, could you PLEASE not make different logics for different resolutions? If you only check the 640x400 box, everything should work the same way for any game resolution.

This is not possible, since the game display is very different.

For example compare 640x400 to 640x480. In 640x480 the first 40 lines are blanked out. The actual image is between lines 40-440.

In 640x400 the actual image is between line 0-400. I have to treat differently since.

 

Take another example:

In 640x4XX I can never look outside the movie area to detect if something differs (check if interlaced frame or not.

I have to use the scanning in column 639.

I don't like this scanning at all but there is no other way for this resolution.

 

If I would do it the same way for 1024 (check column 639) I could detect an ingame scene where the map is not discovered as being a movie since nothing differs (every second line is black)

I can't remember what went wrong when I choose column width-1 but there was a problem too. I had it this way before. Maybe this is not a problem anymore since solidfont screens are treated the same way as non solid fonts screens now if vqphack=disabled. But I don't want to change that again, since it is working right now.

 

Another example: 1024xXXX lets me detect Covertopsbriefingbox very quickly by just scanning a single column. In 640x4XX this is much more painful, I wrote a whole function for this purpose. But it won't work the same way as in 1024xXXX.

 

Basically 800x600 should work like 1024xXXX in terms of interlace detection and actual deinterlacing.

Scaling should be very similar to 1024xXXX too.

 

I could add support for it, of course. But it won't work out of the box with resizevideo=true (which is needed for all of my magic to work)

 

I dislike the fact that I have to do things differently just as you do, but i can't see an alternative.

The worst thing is the 640x480 resolution, since it is an exception in any way on every point. Code size would get down by almost 50% if I would not have to treat this differently. Besides this it doesn't even has any advantage compared to 640x400..... It's just ****ing different. *grrrrrrr*

 

first code segment

If this code is ran BEFORE the second piece you show, then the screenshot I showed will never pass your "is ingame?" check.

Yes it runs before segment 2. It is just executed when 640xXXX.

That's exactly what I tried to tell you. In fact, If column 639 should contain palette #2 and any other colour in any other line, the frame should indeed be detected as ingame (and being shown whith interlacing in EVERY line).

The fact that this does not happen lets me think that you don't write palette #2 at all into this column. Or it is getting overwritten.

Or the whole column is filled with #2.

 

I think you should just check whether the "0,1" pixel is palette colour #0, that should be all the indication you ever need to confirm it's not ingame. None of the text stuff ever overwrites that, and ingame that's ALWAYS the real black (colour 0x0C) of the Options bar at the top.

This would not work for 640x480 (remember the 40 lines.

If I would check 0,41 for 640x480, maybe. I have not tested this yet. (Welcome to the next exception^^)

What I have tested before was using column 0 instead of 639 (checking if odd <>black)

That was my first approach. I liked it, because every res could be treaten the same way.

But this did not work because europe map screen draws these green points into that column.

Yes it draws them to column 0 but not to column 639.

 

Regarding your one-pixel suggestion:

It would fail on covertopsbriefingbox the same way as my current solution.

If you would move the mouse to this point the detection would fail too.

Does it work for menu to be false? No it would fail - look at the menu pic very carefully....

Does it really work for all ingame content?

Nobody knows?

I know how crappy my solution looks, but it works - tell me something different that actually works and i might change...

Think about red alert. The more specific the solution to TDawn. The more problems might occur with red alert later....

 

Even if you might find a single pixel that is <>black for all ingame content and black for all movie content and is on an edge (which gives the ability to force mouse pointer out of its position) you will still have the problem that menu pic is stretched differently by different highresheight values. So I don't think that a one-pixel detection is possible at all....

The detection is harder than one might think for the first second, I had to learn that too....

 

 

But remember: The problems you experience are NOT CAUSED BY THE isinterlaced detection (code segment 1), since this would lead the whole image to be displayed as interlaced then.

 

Please try again using RC1 and german language.

 

We need an explanation for our different experiences before we should change anything.

 

Maybe you can try a faster dual core computer - can you remember you had that lost parts of the image thing before in scores screen. I have never seen anything like that on my sys....

Edited February 1, 2011 by cncfan

[Nyerguds 102]

I play the german version. You maybe not. Could that make a difference?

So, you never considered just testing in English for a moment to try it out? It's just an option in conquer.ini; it's REALLY not hard to change it and test on multiple languages. It's even in the new setup tool.

 

And yes, it draws the lines based on the text length, so the language makes a difference. I tested in German, and indeed, it doesn't have the black lines drawn to the end. But obviously the system SHOULD work for ALL languages.

 

So can you just test it in English too then? You'll see.

 

Did you test with my RC1 build on 2011-01-31 or with beta9?

I am talking about RC1.

I don't have constant black lines with RC1 and your r2beta anymore.

I had them when using 1.06cr1f1

I tested with both; no change.

 

This is not possible, since the game display is very different.

For example compare 640x400 to 640x480. In 640x480 the first 40 lines are blanked out. The actual image is between lines 40-440.

In 640x400 the actual image is between line 0-400. I have to treat differently since.

As far as I can see, 640x480 is the ONLY resolution that needs an exception...

 

I know how crappy my solution looks, but it works - tell me something different that actually works and i might change...

Think about red alert. The more specific the solution to TDawn. The more problems might occur with red alert later....

I doubt it. RA already fully stretches its WSA files, and uses hi-res PCX files for any fullscreen images, including full briefing backgrounds. The only thing RA needs to stretch are videos.

 

Even if you might find a single pixel that is <>black for all ingame content and black for all movie content and is on an edge (which gives the ability to force mouse pointer out of its position) you will still have the problem that menu pic is stretched differently by different highresheight values. So I don't think that a one-pixel detection is possible at all....

The detection is harder than one might think for the first second, I had to learn that too....

Don't you do the detection on the original game image before all stretching? Also, you keep talking about "black", while my suggestion wasn't black but "palette colour index 0". The main menu screen doesn't contain any colour #0.

 

But remember: The problems you experience are NOT CAUSED BY THE isinterlaced detection (code segment 1), since this would lead the whole image to be displayed as interlaced then.

Uhh... did I ever say it wasn't? I said the whole deinteracing system stopped working after the black bar shown in the screenshots was drawn.

 

See this screenshot. That's your latest DLL, on English language.

 

 

About the upper left (x0,y1) pixel though... I didn't think of the problem it had if you move your mouse on it, but you could get around simply by checking (x0,y1) and (x10,y1), since the mouse shape doesn't allow it to cover both these pixels.

 

The ingame, main menu and briefing screens would NOT have a problem with it if the mouse went over it, since then they'd immediately (correctly) be identified as "ingame content". The scenes you SHOULD be worried about are the interlaced ones with user interaction, like the Europe and Africa maps, the Start New Game screen and the final Nod ion cannon choice screen, but as I said, also checking pixel (x10,y1) fixes that. The map screens never draw over the top 4 lines, so it works perfectly there too.

 

Oh, and the main menu image doesn't contain any index #0 black, so no, the (0,1) detection should work perfectly there. And all ingame (mission playing) content has a 14-pixel high top bar drawn there, which is drawn in #12 black, with SHP buttons on it (which can't draw colour #0 since it's used for transparent in SHP files), so it would always work there.

[cncfan 0]

I said the whole deinteracing system stopped working after the black bar shown in the screenshots was drawn.

Okay, I got you wrong then. I initially thought, only the estonia effect did happen. Of course this is caused by me then (code segment 1) and will be fixed.

I will try that one pixel solution then.

I suggest we should call such effects (and also such things like covertopsbriefingbox bug) as "wrong deinterlacing mode is chosen" from now on, this will avoid confusion on my side.

 

See this screenshot. That's your latest DLL, on English language.

This screenshot (and also the first) did not make this obviuos to me, because in every screenshot the view is completely interlaced if it's a movie even if the screen output is deinterlaced correctly. That is because the screenshot function needs to get the palette colours that are only available on the ddraw surface. I do my things while copying the ddraw surface to a rgb-texture. Screenshot pics can differ from actual screen display since!

 

So, you never considered just testing in English for a moment to try it out?

No there are so much options to test that this did not came into my mind earlier. It's very hard to test every possible combination of all options.

 

Don't you do the detection on the original game image before all stretching?

Of course, I do. I was talking about the fact that menu picture is shown differently by C&C95 if menu pic does not fit into C&C95 Hiresheight. But you are right, this has no effect on the colour value of any specific pixel (x,y). So no stretching, just something missing (on bottom).

 

About the upper left (x0,y1) pixel though... I didn't think of the problem it had if you move your mouse on it, but you could get around simply by checking (x0,y1) and (x10,y1), since the mouse shape doesn't allow it to cover both these pixels. The ingame, main menu and briefing screens would NOT have a problem with it if the mouse went over it, since then they'd immediately (correctly) be identified as "ingame content". The scenes you SHOULD be worried about are the interlaced ones with user interaction, like the Europe and Africa maps, the Start New Game screen and the final Nod ion cannon choice screen, but as I said, also checking pixel (x10,y1) fixes that.

I completely agree.

 

Oh, and the main menu image doesn't contain any index #0 black, so no, the (0,1) detection should work perfectly there. And all ingame (mission playing) content has a 14-pixel high top bar drawn there, which is drawn in #12 black, with SHP buttons on it (which can't draw colour #0 since it's used for transparent in SHP files), so it would always work there.

These are very valuable information to me, that I did not have before. Keep in mind that before this project I only saw C&C through the eyes of a gamer. Whereas you have experience in modding and analysing this game for a very long time. Furthermore, when I first wrote this code, I had no idea of the transparent palette thing. I thought a black pixel is a black pixel then. Since it kept working the way it was for a long time, i did not change more than i thought was needed there. If I had the information once I have now, I would have made things different.

 

To make things short:

I will recode the interlace detection to check if pixel (x0,y1) or (x10,y1) is palette #0 and will assume interlaced then, ingame else+covertopsbriefingboxhack

For 640x480 I will check if (x0,y41) or (x10,y41) is palette #0 and will assume interlaced then, ingame else +covertopsbriefingboxhack

 

I will test if covertopsbriefingboxhack can be removed too. This would be true if those pixels would be real black there and not transparent (palette#0).

I will also check if fading is handled correctly (which should be true too, since fading does no change on palettes)

This would be great.

Edited February 2, 2011 by cncfan

[cncfan 0]

Regarding isinterlaced-check:

 

Europe and Africa are working the same way now in german and english on all resolutions (like german).

Fading is handled correctly too.

 

The change introduced a new problem:

The "Coming attraction" screens in the intro/sneakpeak option are mistakenly detected as being ingame now (only in the german version). Since the pixels on that places are not palette#0.

We need a new bypass for them too.

The simplest way to achieve that would be to set the corresponding pixel to transparent in the german picture.

All other language versions do work fine. The german one is the only one with full height.

I think we should simply crop the german pic.

Any better solution? Please include the next problem in your thinking.

 

 

CovertOpsBriefingBox does FAIL. (is recognized as interlaced, so these pixels seem to be transparent)

We still need to bypass this with a seperate function. At the moment this can be done for 640x400, 640x480 and 1024xXXX. It's still commented out in the beta included with this post.

This function is not generic and has to be adapted to work on 800x600 too...

Do you have an idea for a fast generic approach that works on all resolutions and languages?

Keep in mind that you could only check in the 640x400 box to be resolution generic.

Think about a theoretical resolution of 10000x6000 the whole picture would be transparent then in 640x400 box.

Either you can check only for transparent pixels for detection (being fully resolution independent)

or you can check for some parts of the boxes (losing full resolution independency)

 

My proposal would be to check if some other pixels in the (y-centered region) ON EVEN lines are transparent too and if yes,

assume we have covertopsbriefingbox.

y centered to be different from coming attraction screens.

If this should work there should never be a transparent pixel on these specific even line pixels in (cutscenes, scores, mission selection, nod fire ion cannon,COMING ATTRACTION)!

Is this true? Can I rely on that? I'm not sure regarding solidfontscreens. We would have to check at least two pixels again (because of mouse cursor)

Any better idea? Keep the (different) coming attraction screens in mind.

 

Offtopic:I like the new interlace detection since it's very simple, but as you see, we have to adress new problems now...

Very hard to find a one-fits-all-solution. Do you now understand why coding resolution independent is very hard?

If I had not told you that german coming attraction screen is broken, would you have noticed it by yourself?

Had you doublechecked THIS screen for every language independently? No, I doubt that. Testing is always kind of luck since you can't test everything everytime....

 

Regarding mission selection screens:

The problem that the blue GPS cross on mission selection screens is interrupted if it crosses the area where fonts HAVE BEEN does persist. Has this been present with 1.06r1f1(no palette#2logic) and HIFI 2011-01-10 too?

See Europe, Estonia (all languages)

 

The problem that Africa maps still flashes interlacing lines (only under one text block) for a fraction of a second does persist. (all languages)

 

Both problems should be something YOU can adress, not me.

 

If you want to see the problems with your own eyes: (just for nyerguds)

iisinterlacedeasy__nocovertopsboxes_nocoming_attraction.rar

 

 

Another note:

remember: CovertOpsBriefingBox does FAIL. (is recognized as interlaced, so these pixels seem to be transparent)

Why does the game use transparent instead of real black for these screens?

Is this the same colour as ingame undiscovered areas?

If yes, could we maybe fix the graphical glitches in 1024xXXX in the first three missions by changing this from transparent to black? This was just an idea. Could be totally wrong. What do you think?

Edited February 2, 2011 by cncfan

[Nyerguds 102]

The "Coming attraction" screens in the intro/sneakpeak option are mistakenly detected as being ingame now (only in the german version). Since the pixels on that places are not palette#0.

We need a new bypass for them too.

The simplest way to achieve that would be to set the corresponding pixel to transparent in the german picture.

All other language versions do work fine. The german one is the only one with full height.

I think we should simply crop the german pic.

Any better solution? Please include the next problem in your thinking.

I can probably fix that, actually. These images are stretched correctly ingame, without black lines. It's not hard for me to simply stretch them to fullscreen instead of 640x400.

 

CovertOpsBriefingBox does FAIL. (is recognized as interlaced, so these pixels seem to be transparent)

We still need to bypass this with a seperate function. At the moment this can be done for 640x400, 640x480 and 1024xXXX. It's still commented out in the beta included with this post.

This function is not generic and has to be adapted to work on 800x600 too...

Do you have an idea for a fast generic approach that works on all resolutions and languages?

Keep in mind that you could only check in the 640x400 box to be resolution generic.

Think about a theoretical resolution of 10000x6000 the whole picture would be transparent then in 640x400 box.

Either you can check only for transparent pixels for detection (being fully resolution independent)

or you can check for some parts of the boxes (losing full resolution independency)

 

My proposal would be to check if some other pixels in the (y-centered region) ON EVEN lines are transparent too and if yes,

assume we have covertopsbriefingbox.

I thought of that too, but it has to be both X and Y centered, on the normally-black in-between. That box is centered, and has a minimum width (178 pixels), and insie that width, none of the pixels can be #0 black. So testing out 3 or 4 pixels with about 20 or 30 pixels in between them, all on the center of that line, should work correctly, on all resolutions. Heck, by using the center, even 640x480 won't need any special logic.

So you take

W=X/2

H=Y/2+1

Check pixels (W-30,H), (W-10,H), (W+10,H), (W+30,H), and if none of them are #0, it's Covert Ops.

 

y centered to be different from coming attraction screens.

If this should work there should never be a transparent pixel on these specific even line pixels in (cutscenes, scores, mission selection, nod fire ion cannon,COMING ATTRACTION)!

Is this true? Can I rely on that? I'm not sure regarding solidfontscreens. We would have to check at least two pixels again (because of mouse cursor)

Any better idea? Keep the (different) coming attraction screens in mind.

As I said... Coming Attraction screens dont' HAVE any transparent lines between them. They just need stretching. This is really hard to detect though, since the way they are built is technically the same as the Covert Ops briefing screens (transparent 0,1 pixel, but solid in the middle). I think I'll just try to fix that ingame. These pictures really call a stretching function, so it should work.

[Nyerguds 102]

Offtopic:I like the new interlace detection since it's very simple, but as you see, we have to adress new problems now...

Very hard to find a one-fits-all-solution. Do you now understand why coding resolution independent is very hard?

If I had not told you that german coming attraction screen is broken, would you have noticed it by yourself?

Had you doublechecked THIS screen for every language independently? No, I doubt that. Testing is always kind of luck since you can't test everything everytime....

It's certainly faster... the previous method lagged a lot on the map scenes filling in the red and yellow areas. But yes, I understand it's not simple.

As for the "Attract" screens though, if I make the game stretch them, they'll fail the new Briefing screen check I showed above, and they will always be seen as ingame content. So then there is no problem. The only reason I hadn't done that yet was because the videos weren't stretched.

 

Regarding mission selection screens:

The problem that the blue GPS cross on mission selection screens is interrupted if it crosses the area where fonts HAVE BEEN does persist. Has this been present with 1.06r1f1(no palette#2logic) and HIFI 2011-01-10 too?

See Europe, Estonia (all languages)

Hmm... I can probably fix that by making ALL black boxes into colour #2. I'll look into it.

 

The problem that Africa maps still flashes interlacing lines (only under one text block) for a fraction of a second does persist. (all languages)

 

Both problems should be something YOU can adress, not me.

Right. I'll see what I can do.

 

 

If you want to see the problems with your own eyes: (just for nyerguds)

iisinterlacedeasy__nocovertopsboxes_nocoming_attraction.rar

Right, I'm testing with that now.

 

Another note:[/b]

remember: CovertOpsBriefingBox does FAIL. (is recognized as interlaced, so these pixels seem to be transparent)

Why does the game use transparent instead of real black for these screens?

Is this the same colour as ingame undiscovered areas?

If yes, could we maybe fix the graphical glitches in 1024xXXX in the first three missions by changing this from transparent to black? This was just an idea. Could be totally wrong. What do you think?

Undiscovered areas ingame are shown as real black. If a mission is smaller than the screen resolution, #0 black is shown outside it after scrolling and then opening & closing the main menu, but this is always too far at the edges to interfere with a center-based colour #0 check:

http://nyerguds.arsaneus-design.com/junk/ingame_col0.png (I indicated the center with a blue cross. It covers a 100x100 area. That should be plenty )

[Nyerguds 102]

The attract screens are now automatically stretched to fullscreen ingame, if the StretchAttract key is enabled in conquer.ini, so that's one issue fixed

[cncfan 0]

I thought of that too, but it has to be both X and Y centered, on the even line. That box is centered, and has a minimum width (178 pixels), and the only colours that can appear on that line are #12 and #159. So testing out 3 or 4 pixels with about 20 or 30 pixels in between them, all on that line, should work correctly, on all resolutions. Heck, if you use the center, even 640x480 won't need any special logic.

So you take

W=X/2

H=Y/2+1

Check pixels (W-30,H), (W-10,H), (W+10,H), (W+30,H), and if none of them are #0, it's Covert Ops.

The check is in fact on odd lines, then? not even lines as stated in your writings...?

If yes, I will code it that way.

 

The new isinterlaced check is faster.

Of course it is. Nice if one is able to change C&C95 AND ddraw.dll behaviour, not just one of them^^.

 

The attract screens are now automatically stretched to fullscreen ingame

Nice work

 

Regarding mission selection screens:

The problem that the blue GPS cross on mission selection screens is interrupted if it crosses the area where fonts HAVE BEEN does persist. Has this been present with 1.06r1f1(no palette#2logic) and HIFI 2011-01-10 too?

See Europe, Estonia (all languages)

You mean where it draws the arrow? Looks like that simply isn't stretched in X-direction, which is the game logic failing, not your stretching. It stretches correctly in the Y direction.

No I don't talk about the green arrow, I talk about the blue cross that is visible for maybe half a second directly after "NOD progression". It is interrupted in x where the fonts have been before.

 

Undiscovered areas ingame are shown as real black. If a mission is smaller than the screen resolution, #0 black is shown outside it after scrolling and then opening & closing the main menu, but this is always too far at the edges to interfere with a center-based colour #0 check:

This was not my point. My question was the following and has nothing to do with cncddraw at all.

If playing C&C95 at 1024x768 there are graphical glitches in the first 3 missions because the maps are smaller than the screenres. E.g: The gunboat gets visible a second time in the pink area. Could this bug be circumvented by filling the pink area (in fact transparent#0) with black instead? By C&C95.exe, not by ddraw.dll....

Edited February 2, 2011 by cncfan

[Nyerguds 102]

The check is in fact on odd lines, then? not even lines as stated in your writings...?

If yes, I will code it that way.

Yes, sorry, I said even because if you just count them it's lines "1,2,3,4", and in that case it's the even ones. But you're right, I obviously mean the black in-between ones. I edited the post, but you beat me to it

 

No I don't talk about the green arrow, I talk about the blue cross that is visible for maybe half a second directly after "NOD progression". It is interrupted in x where the fonts have been before.

I realized that just a little too late... I edited my post. It should be fixed by making all black boxes into colour #2. At the moment, only those that made black lines go into the map image were changed.

 

 

This was not my point. My question was the following and has nothing to do with cncddraw at all.

If playing C&C95 at 1024x768 there are graphical glitches in the first 3 missions because the maps are smaller than the screenres. E.g: The gunboat gets visible a second time in the pink area. Could this bug be circumvented by filling the pink area (in fact transparent#0) with black instead? By C&C95.exe, not by ddraw.dll....

Ah, no... the REAL issue there is the position of the playable area on the map itself. All C&C maps are 64x64, but the game positions mission #1 incorrectly from the start because the playable area is located in the lower right corner. When it starts, it tries to show area that is actually still in the map, which means it shows the lower right corner of the map as lower right corner of the screen.

 

But when you try to scroll, it tries to correct this, and shows the map's playable area drawn from the top left corner of the screen. The problem is that this leaves a large area of the screen looking REALLY OUTSIDE of the map data. That area isn't filled at all, it's simply left blank. And since blank is transparent, it doesn't remove the graphics that were already drawn there (until you open the options menu, which forces a full repaint).

 

I really shouldn't touch its default canvas colour; if that's not transparent (#0) it's possible the game can't draw ANYTHING on to of it, meaning it wouldn't show any terrain at all.

 

See http://nyerguds.arsaneus-design.com/cncstu...gdi/scg01ea.png

 

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

[cncfan 0]

Ok I will rework the covertopsboxhack then.

 

Blue cross:It should be fixed by making all black boxes into colour #2

Great!

 

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

Can you do this please? (Maybe even independent for different resolutions, so that 640x400 is still focused lower right when starting the game)

Edited February 2, 2011 by cncfan

[Nyerguds 102]

Oh, this problem only happens on high resolutions. changing the position of the mission will have no effect on lower resolutions.

 

Sure, I'll see if I can do it. I might be able to shift the terrain map itself with my hex editor

[cncfan 0]

CovertOpsBoxes do work again

 

61_isinterlaced_independent_from_gameres.rar

 

The actual deinterlacing process is already independent from gameres.

But I have to rework the scaler now.

 

Can I rely on the requirement that each resolution you will add in future can be treated exactly as 1024xXXX in terms of AR?

That means:

the ar is always like in 640x400.

Correctvideoar and Correctingamear use the assumption that 1,2*height (preserving width) will give you corrected ar?

Will it be like this in future, too?

 

I checked your new beta2 from yesterday and ccsetup still does not work on my sys.

Even deleting thipx32.dll (i don't actually know where i got my version from) has no effect.

Any ideas?

Edited February 2, 2011 by cncfan

[Nyerguds 102]

Strange.... it requires the .net framework 2.0, but everyone should have at least 3.5 these days. Windows 7 even comes standard with the newest one (4.0)

I'll make a test version with error dump for you, so I can see what goes wrong...

 

 

I edited the mission, but it has no effect... the bottom-right to top-left jump still happens, and no matter what colour the tiles outside the visible map are (I made #12 black filler tiles) the stuff outside the map doesn't refresh, so the image still copies. So the only effect this has is that it's not #0 black anymore.

[cncfan 0]

.net framework

wahhh, awkward, i hate this framework.

I have not installed it and this is the reason i can't use your setup, ok.

But i won't install that monster just to save some time on ini editing.

I will use the old ccsetup instead and will live with the fact that i have to adjust some settings via ini.

 

New beta can be downloaded, look above, reread the post (scaler questions...)...

Edited February 2, 2011 by cncfan

[cncfan 0]

I edited the mission, but it has no effect... the bottom-right to top-left jump still happens, and no matter what colour the tiles outside the visible map are (I made #12 black filler tiles) the stuff outside the map doesn't refresh, so the image still copies. So the only effect this has is that it's not #0 black anymore.

Hmm, maybe 3 options left then...

A expand the maps with actual pseudo terrain

B force a refresh (as if sidebar is opened)

C maybe even starting these maps with sidebar enabled would fix???

[Nyerguds 102]

Well, opening the sidebar fixes it, yes, but the only way to force that is by giving the player construction options; AKA, replacing the MCV by a construction yard. That kinda goes against the mission briefing test, so I won't do that.

 

As for expanding with pseudo-terain, that won't work in this case, since there are reinforcements coming from the bottom of the map. I'd have to pad it with water, and the reinforcements would all arrive a lot later because they'd have to travel further. I can't really pad the top either, since mission #2's big surprise is that there's a Nod base there.

 

By the way, I just sent you a link with a test version of the ccsetup tool... can you try it out and post the result of the crash thing here?

[cncfan 0]

Keep in mind that i don't have .net installed at all (and i won't install it, as stated above)

 

Also keep in mind that HIFI wrote cncdraw.dll for getting better Wine=Linux compatibility. Is a .net setup tool really the way to go then?

 

crashlog:

 

Die Datei oder Assembly System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

bei ccsetup.persistence.ini.IniSection.getKeyValuePairs(Boolean lowercasekeys)

bei ccsetup.persistence.ini.IniSection.getKeyValuePairs()

bei ccsetup.persistence.ini.IniFile.writeIni(String iniFilePath)

bei ccsetup.persistence.ini.IniFile.writeIni()

bei ccsetup.domain.DomainController.initDDraw(Boolean writeSettings)

bei ccsetup.domain.DomainController..ctor()

bei ccsetup.domain.DomainController.Instance()

bei ccsetup.Program.Main()

-------------------------------------------------------------------------------

 

I have to rework the scaler for resolution independency.

Can I rely on the requirement that each resolution you will add in future can be treated exactly as 1024xXXX in terms of AR?

That means:

the ar is always like in 640x400.

Correctvideoar and Correctingamear use the assumption that 1,2*height (preserving width) will give you corrected ar!

Will it be like this in future, too?

Also note, if you would introduce black lines as it is done in 640x480 to any resolution they won't be removed by correctvideo & correctingamear (unlike 640x480 where i do this)

 

Newest beta is "61", link can be found some posts ago...

 

can you tell me the mix file where the mission files are stored (bin and ini)

Edited February 2, 2011 by cncfan

[Nyerguds 102]

Keep in mind that i don't have .net installed at all (and i won't install it, as stated above)

That's a pretty silly attitude. It's a framework to run programs, just like java. Also, you clearly have SOME version of it installed, otherwise the program wouldn't run at all. It crashes on 3.5 specific calls (guess I was wrong there; it does need 3.5), so you probably DO have v2.0.

 

As for aspect ratio, well, there are 2 ways I can do this... either I ust give the user Width= and Height= keys in the ini, but restrict it to 1024x768 internally (since larger resolutions just cause too many problems), or I just add more to the internal resolutions "enum", meaning 0=640x400, 1=640x480, 2=800x600, 3=1024x768

[cncfan 0]

That's a pretty silly attitude. It's a framework to run programs, just like java. Also, you clearly have SOME version of it installed, otherwise the program wouldn't run at all. It crashes on 3.5 specific calls (guess I was wrong there; it does need 3.5), so you probably DO have v2.0.

That's my problem though. In fact I HAD 2.0 installed, I regret that fact, you see, how good removal works^^

All programs coded with .net are SLOW LIKE HELL. I don't use any of these. Having the framework not installed is a good way to check which apps depend on it Furthermore I don't have to keep up on security fixes for a framework I don't WANT to use.

 

However, ini access would be all I need for every option.

 

Can I rely on that 1,2*height ar fix assumption?

 

can you tell me the mix file where the mission files are stored (bin and ini)

Edited February 2, 2011 by cncfan

[Nyerguds 102]

Well all resolutions will normally be 4:3, if that's what you're asking. I'm not planning to add anything else than 800x600, really.

 

The mission files are all inside general.mix, as they've always been.

[cncfan 0]

Well all resolutions will normally be 4:3, if that's what you're asking. I'm not planning to add anything else than 800x600, really.

 

You can do whatever you want from now on, I fixed the scaler to being resolution independent.

 

All components - interlace detection, deinterlacing and scaling should now all be independent from resolutions. The only exception is 640x480 which is treated differently everywhere since the 40lines top and bottom.

 

63_newscaler_independent

 

Note that I also fixed the mouse boundaries to 639,399; 639,479 for interlaced content resulting in every pixel should be reachable again.

 

I also had to change the stretching logic (correctvideoar=false!!!!)for 1024xXXX to the one used for 640x400.

All other correctingamear,correctvideoar combinations should act the same way as before for all resolutions.

 

for correctvideoar=false 1024xXXX the logic changed from

this:

scale_h = 240.0/200*src_height/768.0 * 400.0/dest_height;

to that:

scale_h = 400.0/dest_height;

Please test if it suits your needs.

 

I'm not quite sure at the moment why it was different before, I just can't remember...

I just remember that I played around at this value multiple times before.

But at the moment the old formula just doesn't make sense in my head...

 

 

If everything works as expected or maybe even better than before, let me know and I will claim this version as RC2 and the 3 days period until sending the code to HIFI is started again. (I will upload it once again though, because the version string that is generated in the ini file is outdated now...)

Edited February 2, 2011 by cncfan

[Nyerguds 102]

Nice, I'll test that tomorrow.

 

I made sure all rectangles are now drawn in colour #2, which should fix all stretch problems.

 

As for the Nod text disappearing in 2 stages (on non-interlace lines, then fully), I don't really know what causes that... but I've fixed a couple of errors in my code. I had generally been replacing "0C" values by "02", and now I filtered out which of them are actually colours, and restored the rest. It's possible this already fixed the issue, but if not, I'm going to check if it's actually different in the original game.

 

It doesn't look THAT bad anyway... it just appears as if it's a 2-phase fade

[Nyerguds 102]

Well, looks like I found some time to test it now after all...

 

And it's bloody amazing, that's what it is. Congratulations man, everything works perfectly as it should now, and it runs smoothly even on my PC

 

I adapted the ccsetup tool to have the new "stretch videos" option on it, and the filter for the video stretching. And I fixed some bugs and made it .net 2.0 compatible, so even you should be able to run it now

(and no, I didn't do that for you, it just came naturally with the bug fix )

 

 

Oh, and I just found out that the correct term for the black lines is "scan lines":

http://en.wikipedia.org/wiki/Scan_line