Suggestions for Nyerguds C&C TDawn 1.06c

[cncfan 0]

That's one small step for [a] man, one giant leap for mankind.

 

2011-01-25_BETA6

 

In fact, this hasn't been a small step for me, but.... ;-)

 

 

What has changed? Nearly everything, but I promise, this thing will blow you away....

-fixed AR issues in 1024 - AGAIN ;-)

what is possible in terms of AR?

-choosing cncddraw output in any 4:3 resolution and C&C95 1024x768 and correctar=true should give you correct movie ar and positioning, menu ar will be correct, ingame ar may be wrong (but not by much and still displayed in full res) - you can play fullscreen this way with a 4:3 display (without ingame content being scaled in any way if cncddraw 1024x768) - don't waste a single pixel with this setting

-choosing cncddraw output in any 4:3 resolution and C&C95 1024x640 and correctar=false should give you correct movie ar and positioning, ingame ar correct, (wrong ar for main menu will be adressed by nyerguds patch later), you can play this in fullscreen too, but have to accept the fact that every ingame frame needs to pass the resizer (use this setting if correct ar is everything to you or if you wish to scale up further anyways)

-removed any possible jiggle in x or y when switching between solidfonts and not solidfonts cutscenes

-movies with solid fonts are interpolated in y and not just doubled (this should reduce visibility of wrong pixels near solidfonts)

-have been able to remove most of the hardcoded values since every interlaced content is treated the same way now - first scaled up to 640x400 and then passed to the opengl resizer (this does NOT lead to reduced movie quality since doubling is always done with linear scaling)

-the code looks much better now

 

At this point beta6 for the first time should be able to give you everyting that HIFIs last official version 2011-01-10 did + nice extras.

Edited January 25, 2011 by cncfan

[Nyerguds 102]

Nice! This is exactly the functionality I wanted

[cncfan 0]

fixes that are already implemented for beta7 yet (but these bugs are still present in beta6 though):

-fixed mouse boundary in y for 1024xXXX interlaced frames, yes I know, i alread fixed this before, but at that time i had not known the HighresHeight option, though this should be a solution that will last forever

-fixed a bug where moving the mouse pointer in newgame solidfontvid (choose nod vs gdi) to bottom would lead to wrong deinterlacing mode

(no solid font version instead of correct solid font version)

 

Bugs can be found and fixed much better within the slimmed code structure... I will get them all!

 

P.S: To Nyerguds, this version should not be used by anybody else, it is just for Nyerguds to test a special feature...

using palette colors for preserving solid fonts

 

Okay I implemented the solid font preserving based on palette.

Palette=0 pixels are the only ones that are interpolated now.

I think the result is definetely better than the "black"-approach.

You can test for yourself....

Please make sure to test with resizevideofilter=nearest, and cncddraw output resolution of 1280x800.

This is a multiple of 640x400 so the scaling issues should not be a problem there.

Input resolution should not matter, but if you are playing in 1024xXXX set correctvideoar=false.

As you can see the result looks quite good (best check first score screen and first mission selection screen [after first score])

Look at the 0 for buildings lost GDI! (Remember how it looked)

But there is a problem: Look at Estonia in missionsel screen. Seems like somebody has set some pixels to black that should be transparent at all.

 

Can you please doublecheck that. This happens on all input resolutions.

Maybe you can make another screenshot to investigate which pixels have transparency. It would be wise to use HIFIs last build for that purpose.

 

If this should be no bug in my implementation and those pixels should indeed have the wrong transparency information, I would rather switch back to the current "black"-approach.

 

Can this be true at all, I mean could I see those pixels normally, when they actually are set as black by palette? Sounds strange to me.

[Edit:Yes because they must be odd lines that are transparent/black anyways]

 

Have I done something wrong?

 

You can do a comparison with the same settings to beta6.

 

As you will see, most of the distortion is introduced by scaling and not by the black-approach itself. The "boxes" look quite good too.

 

What do you think? Any other explanation for the estonia effect?

In the Africa map the same lines are affected through the whole image in x direction.

The quality of this approach is too good to not use it. What can be the cause of this?

Anyway, this was a nice idea!

 

I have another idea if we can't fix it with the transparency info:

 

The old "black approach" works this way:

If pixel=black linearinterpolate(top,down) else take pixel;

 

What do you think of this "extended black approach":

if pixel=black
  {
      if pixel.top=fontcolor & pixel.down=fontcolor pixel=fontcolor;
      if pixel.top=fontcolor & pixel.down<>fontcolor pixel=pixel.down;
      if pixel.top<>fontcolor & pixel.down=fontcolor pixel=pixel.top;
      if pixel.top<>fontcolor & pixel.down<>fontcolor linearinterpolate(top,down);
   }
else take pixel

 

Should fix those problems on solid fonts very well too, don't you think?

I would need the palette color of the fonts for this.

Can you give me that information? Or can you tell me any idea how to get it from a frame?

Please note that this would be definetly slower than palette=0 check!

Edited January 26, 2011 by cncfan

[Nyerguds 102]

-fixed mouse boundary in y for 1024xXXX interlaced frames, yes I know, i alread fixed this before, but at that time i had not known the HighresHeight option, though this should be a solution that will last forever

-fixed a bug where moving the mouse pointer in newgame solidfontvid (choose nod vs gdi) to bottom would lead to wrong deinterlacing mode

It seems the mouse on the new game screen reacts somewhat oddly. Towards the bottom, I can move all the way down until only the top pixel of the mouse is visible. This is correct. But in X direction, I can't move a single pixel of the mouse out of the screen, while it should logically also move until the left pixel row of the cursor is the only thing still in the screen. It's not a serious bug, but still kinda odd.

 

Can you please doublecheck that. This happens on all input resolutions.

Maybe you can make another screenshot to investigate which pixels have transparency. It would be wise to use HIFIs last build for that purpose.

Ohh bloody hell. I see what went wrong there.

 

The game draws black blocks on the screen to wipe away the text that it puts there. That black is real black, and not the palette #0 type.

 

(background black replaced by purple to reveal the problem with the true black)

 

I'll see if I can fix that internally in the game...

 

 

I have another idea if we can't fix it with the transparency info:

 

The old "black approach" works this way:

If pixel=black linearinterpolate(top,down) else take pixel;

 

What do you think of this "extended black approach":

if pixel=black
  {
      if pixel.top=fontcolor & pixel.down=fontcolor pixel=fontcolor;
      if pixel.top=fontcolor & pixel.down<>fontcolor pixel=pixel.down;
      if pixel.top<>fontcolor & pixel.down=fontcolor pixel=pixel.top;
      if pixel.top<>fontcolor & pixel.down<>fontcolor linearinterpolate(top,down);
   }
else take pixel

 

Should fix those problems on solid fonts very well too, don't you think?

I would need the palette color of the fonts for this.

Can you give me that information? Or can you tell me any idea how to get it from a frame?

Please note that this would be definetly slower than palette=0 check!

Hm, that would definitely be a good workaround.

 

Oh, by the way, talking about palettes... doing a palette colour #0 check instead of black to see if you have to switch will also fix the fade issue. Fade darkens the entire palette, but doesn't touch the colour indexes, after all

[Nyerguds 102]

After some research it turns out the black blocks are not the problem. Or rather, I can't replace them with background colour, as background colour is seen as transparent to the game, meaning the black box drawing will have no effect if done with colour #0.

 

The real problem is that the screen clearing between the scenes (in this case, between the zoom in on europe, and then the Europe mission map) only clears the lines of the WSAs themselves, and not the black lines in between. If it would do a correct clear, everything would work fine. I'll see if I can patch in some sort of solution.

 

[edit]

 

Looks like the scenes DO clear correctly at first, but with the next text write, leftovers from the previous text clearing boxes come back in the black lines, for some bizarre reason. At the moment I have no idea how I can influence this though, especially since the text drawing seems to happen independently from the main animation; as if it runs on a different thread, quite like how the music works. This means I can't debug it, and thus, not establish the exact code which draws the black lines. I found references to an earlier-identified TimerClass, but I still got no clue how it all works

 

I just hope I can find that text drawing thing and reset it in between the animations or something like that.

 

An alternative approach would be to use a different black (or nearly black) colour index for drawing the text-clearing boxes, and make your dll overwrite that second colour too as if it were index #0. But it doesn't seem like I can easily do that without editing the WSA animation files. The colour index #2 works for the actual mission selection screens, but its colour is different and too visible on the map animations before it.

[cncfan 0]

It seems the mouse on the new game screen reacts somewhat oddly. Towards the bottom, I can move all the way down until only the top pixel of the mouse is visible. This is correct. But in X direction, I can't move a single pixel of the mouse out of the screen, while it should logically also move until the left pixel row of the cursor is the only thing still in the screen. It's not a serious bug, but still kinda odd.

It is intended by me to act this way because I need column 639 for proper interlace detection in 640xXXX mode to be free from mouse pointer. I check if every second pixel of this column is black and if yes, I assume the frame is interlaced. If mouse pointer moves in, things would get messed up. In 1024xXXX I can check if anything outside the 640x4x0 box is <>black and if yes, the frame is NOT interlaced.

I can't use column 0 for this scanning (this would lead to only one line being not accessible with the mouse pointer) because sometimes there are actually drawn things in column 0 odd lines while being interlaced with solid fonts.

I could redo the check to accept black and white pixels (this would include all mouse cursor pixels, but this would need additional checks - it's faster the way it is and you will never have to move the mouse at those points in interlaced mode)

 

 

Do you have any idea how to get the fontcolor (if it should change in palette values, i could use the rgb value as well, but i don't know how to get it, i would implement the extended-black approach until you might find a fix for the drawing thing, just for checking, how it performs)

 

Question: The black lines are not in the "texture"-files for europe and africa, they are drawn by the game internally, do i get you right? Otherwise we could just edit those texture files and make them look as they should.

 

An alternative approach would be to use a different black (or nearly black) colour index for drawing the text-clearing boxes, and make your dll overwrite that second colour too as if it were index #0. But it doesn't seem like I can easily do that without editing the WSA animation files. The colour index #2 works for the actual mission selection screens, but its colour is different and too visible on the map animations before it.

(If palette index #2 is never used anywhere else in ALL interlaced=2 movies (=solid fonts) we could try that.) Easy to change on my side.

(But this should be tested very carefully.)

Maybe this in fact isn't such a big problem after all.... Wouldn't it be sufficient if palettecolor#2 would never be shown in ODD lines? Since they are the only ones I do interpolate with that approach anyways... That should be true because despite solid fonts they are actually black or transparent most of the time in those scenes....

 

Visibility of #2 should not be a problem at all, because once it's drawn in this colour, I will "interpolate it away" before it will ever be shown on the screen... ;-)

 

The only drawback of this idea would be, that you could not disable deinterlacing and scaling anymore since you would see this #2crap instead.

 

Maybe we should check how the alternative black approach performs before we actually do any changes to the game logics. This way users of original C&C95 could use ddraw.dll as well...

Edited January 26, 2011 by cncfan

[Nyerguds 102]

Actually, visibility of colour #2 IS a problem... if it's used to draw boxes to remove text, it will also be drawn on the non-interpolated lines, at the actual time it removes the text. It's only afterwards that only the in-between lines remain. Also, it would be visible if the stretching isn't used

 

Anyway, I edited the WSA animations of the game to free up colour #2, and changed the ingame behaviour to clear certain text boxes with that colour instead of real black. The result is 100% unnoticeable ingame, and the colour #2 logic should work on it now.

 

 

Here's a test where I set the game to use white instead of the final duplicate black.

(note that it triggered the vqphack... obviously that won't be a problem in the real version where the colour is set to black)

 

The only small negative (but it's the best we can get) is that the text drawn over these areas will suffer from the font bleed again... but that can't really be helped because the whole problem is caused by text drawn over the map graphics.

GDI:

Nod:

 

(don't mind the fact the right-side pics don't have the interlacing done; the bars touch the side, so the fact I made them white messes up your detection. As black, it all works though)

 

 

I'm also looking into fixing the game's algorithm to determine the text length, since it's really ridiculously wrong right now. The lowest bar in the second pic shows how far the area is cleared. The first pic shows how far that text ("FOR VISUAL REFERENCE") actually comes.

 

It is intended by me to act this way because I need column 639 for proper interlace detection in 640xXXX mode to be free from mouse pointer.

Okay, no problem. It's just something odd I noticed; it's not a real problem

[cncfan 0]

Ok, what is to do for me then?

just interpolating #2 pixels then.....?!?

Or #2 and #0?

 

I will start an implementation for #2 and #0 now.

 

In fact I will make an ini option to change between #2 and black approach so that users of official cnc95 can use ddraw.dll as well.

[Edit: DON'T DO THIS]

The default setting will be black approach, you should overwrite this setting via your ccsetup.exe

 

solidfontrecoveryscan=black

will be default setting

solidfontrecoveryscan=2

is the thing you should change....

Edited January 26, 2011 by cncfan

[Nyerguds 102]

All you need to do is make sure both colours (#0 and #2) are interpolated.

 

As for the font colour detection, I think I found those in the exe (fonts are technically 16-colour images, and I found ranges of 16 palette indexes to map on them), but looking at the green map edges there is never a guarantee that the colours used by the font aren't ALSO used by the actual interlaced content.

[cncfan 0]

okay, i will start then

i will not implement the extended black approach (with fontcolours)

 

Ah it doesn't matter, i will change the behaviour fix to the new system, who cares.

Users without the patch will have to live with the estonia effect

Otherwise they would suffer from ugly fonts.

Less checks=more speed.

Ignore the ini suggestion please.

 

can you send me a new version of the exe then? or whatever file you did modify?

Edited January 26, 2011 by cncfan

[cncfan 0]

beta7

 

This is beta 7 that will be the last one you can play without the estonia effect on old c&c95 versions.

All newer versions (beta8 and above) will rely on a newer version of C&C95 than 1.06c r1f1

 

adressed bugs with this release:

-fixed mouse boundary in y for 1024xXXX interlaced frames

-fixed a bug where moving the mouse pointer in newgame solidfontvid (choose nod vs gdi) to bottom would lead to wrong deinterlacing mode

(no solid font version instead of correct solid font version)

[cncfan 0]

beta8

 

Changelog:

-new way for preserving solid fonts with very good quality (needs new C&C95.exe)

[Nyerguds 102]

I tested the effect of your beta 8 combined with my game edits. The effect is pretty much flawless, besides some stray pixels the game doesn't clear away correctly (but you won't find them unless you know where they are ). And without video stretching enabled, the effects are completely invisible

 

I'm compiling an installer right now, I'll upload it right away.

 

There's only one drawback; the original stretch palettes of the WSA animations can't be used anymore, since I reconverted the WSA anims with modified colours. Unfortunately, the tool I have for making WSA animations doesn't have real support for generating these palette files either; it just generates one that does nothing but doubling all pixels. This causes the image to "shift" a little whenever there is a switch from non-text to text filter if vqphack is enabled, since vqphack shows it smoothly, with the colours centered on the original image, while the game doubles them, moving the entire image half a pixel to the right side. I personally have no idea of the format of these palette files, so I really don't know how I could generate better ones.

 

 

By the way, I did notice an odd bug in the last version: if you disable correctvideoar in normal 1024x768 mode, the "Start New Game" side choice screen background wasn't cleared correctly before the video was centered on it. It kept showing pieces of the title screen above and below the animation and the videos that followed it.

 

This only happens on Start New Game though, since all other game functions do a fade to black before playing interlaced content.

[cncfan 0]

By the way, I did notice an odd bug in the last version: if you disable correctvideoar in normal 1024x768 mode, the "Start New Game" side choice screen background wasn't cleared correctly before the video was centered on it. It kept showing pieces of the title screen above and below the animation and the videos that followed it.

This is correct, I don't copy all information from ddrawsurface to opengl buffer to save time. I copy just the ones the user will need. If the user chooses wrong aspect ratio, things from the past will get visible. The only way to completely avoid this would be clearing the whole texbuffer that has full ddraw->render.height*ddraw->render.width dimensions.

I thought about doing it but haven't done it yet since you seem to have so much trouble in playing the movies fluidly. Maybe I will implement a fix that does the clearing everytime an interlaced picture is following an uninterlaced one.

 

Shall I do this?

This is no problem for me but might be for users of slower computers....

 

[EDIT]

I found a solution for this and the way I do is so cool, oh well it is perfect in every way...

I love it!

 

Currently I am adding support for letterboxing and proper centering of everything, this will get so perfect!

It is much easier for me to do this way than the old way to do those things - and its faaaaaast!

Edited January 27, 2011 by cncfan

[Nyerguds 102]

Sounds nice

 

Did you test out the beta patch I sent you as private message?

 

Oh, by the way, I just realized how the WSAs .pal files work - they're a series of indexes defining all possible in-between pixels. It's an array of 256 blocks of 256 bytes, each byte being the best colour index to put in between pixels FROM [the colour on the palette at that index in the block] TO [the colour on the palette at that block number] (so if you got 2 pixels with palette indexes 24 and 120, the colour index for the in-between pixel will be in the .pal file at block 120, index 24).

So once I figure out some good colour comparison and nearest-match algorithms, it will be quite easy to make a generator for them based on a single colour palette or paletted image.

 

(the current dummy .pals are just 256 blocks counting up from 0 to 255, hence just duplicating all pixels to the right side. To compare, If it had been 0 0 0 0 0 ... for the first block, 1 1 1 1 1... for the second, etc, the effect would have a same-colour pixel to the left side of every pixel)

[Nyerguds 102]

Well, my stretch table generation tool is finished... takes a WSA, reads its palette, and generates the file with all best in-between values. All that's left is testing it

 

[edit]

 

The system worked flawlessly from the first test. However, C&C still somehow insisted on using colours to "fade from" the palette #2 colour (despite it being black), so I added a logic to my program to completely ignore fades to certain colours (by always using index #0 as fade colour).

 

[edit]

 

lol, problem was me using a WSA where I edited the background colour to purple as source. Not a surprise all fades to "black" looked so bad

 

Here's the updated updata.mix:

updata.rar

(anyone else following this, don't bother downloading that, the effects on 1.06c r1 are completely unnoticeable)

 

 

In case anyone's interested in the actual stretch table generating tool, I uploaded it here, in the same folder that has Ultraq's Red Horizon utilities pack (with his working WSA converter).

http://nyerguds.arsaneus-design.com/tools/redhorizon/

The stretch table generator is written in C#, and requires the .net framework v2.0.

Ultraq's utilities are all written in Java.

[cncfan 0]

Ok here it is, beta9

 

cncddraw 2011-01-28 (beta9) by HIFI,J.Henze.rar

 

Changelog:

-Completely rewritten correctvideoar=1 algo which always centers and stretches correctly

it should support preserving video ar for any c&c95 output to any cncddraw resolutions,

2 exceptions:

C&C95 output 640x400 cncddraw y-res needs to be >480

C&C95 output 640x480 cncddraw y-res needs to be >576

In those 2 cases automatic fallback to correctvideoar=0 is done

so you can leave the option to true forever, because this WORKS VERY STABLE NOW

-including resizing with letterboxing support, without this this has not been possible at all

yes you can play in fullscreen on any type of display, including 16:9 now and ar being preserved

-new feature: correct ingame ar, the name says it all,

this is still very beta though, you might expierence lots of crap at the sides, that is not cleaned out,yet, however better than nothing, if you don't like it, turn it off or choose fitting resolutions

-nice speedups again, for all movies and solidfontscreens

-VQPhack disabled by default now, I have to rework it, at the moment it does mess up lots of things, but this is no step back, because in nearly all releases since beta4 it has been broken anyway (cause i didn't realize)

-I think I fixed "menu was still shown" on GDIvsNOD selection screen, please test many different combinations...

 

Have a nice weekend

Edited January 28, 2011 by cncfan

[Nyerguds 102]

The video aspect preserving for ingame content is a mess... please remove it. Besides basic 1024x768 and 640x400 stretched to 640x480, none of the videos still match the title screen image, it acts completely different from before.

 

-Basic 640x400: the game actually loses pixels because of horizontal narrowing

-640x480: is automatically stretched from the centered 640x400 to full 640x480, and the bottom is blocked because of the game's added 40-pixel black strips.

-1024x640 stretched to 1024x768: Videos are OK, but the ingame stretching is completely ignored; it gives the old 640x480 effect of the unstretched game content centered with black strips at the top and bottom. This is especially odd since it's the exact opposite of the 640x400 effect.

 

 

Basically, all 640x resolutions seem to stretch to 'corrected' aspect ratio, while all 1024x resolutions only stretch to original aspect ratio. None of them can be stretched to adjust the aspect ratio manually.

 

 

This system should really be removed, or at least made optional in the ini... it gives me a lot less freedom for adding resolutions. A lot of people WANT the (incorrect) original ingame aspect ratio since

A. they're used to playing C&C95 as 640x480 centered in 640x400 their entire life

B. they might want clearer image ingame without any stretching effects.

For the videos, aspect ratio correction is nice, but for the ingame content, I really wouldn't force it in such a way.

[cncfan 0]

As already said, I know that this feature does not yet work as expected, though I actually made it an option in the ini file so that people who don't want it, can disable it. I didn't changed the logic fpr ingamecorrected=0 at all so if you don't want it, please disable it. It should work as before then.

 

What I HAVE changed for correctVIDEOaspect=0 is the behaviour in 1024xXXX mode since the old formula didn't work very well. But I am not sure, if the new behaviuor is a step ahead or back. If you would test that would be help. If you don't like the new one, I can change that back of course. Both formulas aren't what I really would like to see.

(The old one is very complex and does not center correctly although scaling should be correct)

Didn't test the new thing if scaling is done correct yet!!! If not I will change back of course.

 

But ingame ar correction can be turned off in the ini file. Delete your old one. Start C&C95, it should create a new one where you can find the option.....

 

I totally agree that the user should not be forced to use ANY automatics that might not work as he expects.

 

Edited January 28, 2011 by cncfan

[Nyerguds 102]

Actually, the game crashed when I removed the ini to let the dll regenerate it, and the ini it generated had none of your new keys (and windowed mode disabled, for some odd reason). So I had no way of knowing what the key was.

 

I just tried ingamecorrected=0 and it had no effect. It still acted exactly the same way.

 

 

Note that in beta 9 I found that the Europe and Africa map scenes no longer used the video stretching logic for some reason, so you clearly changed something there. If you're using the palette index #0 method for that "is interlaced" check too now, please make sure to include colour #2 in that check as well. As I showed in the pic, the leftover bars I made into colour #2 reach the side of the 640x400 screen. So the right-side edge was never 100% pure #0 black in the first place.

 

[edit]

 

nevermind, looks like I deleted the old ini while my setup tool was running; that incomplete ini was generated by my setup tool. Whoops

 

Found the key now; it's "correctingamear", and as you said, it works

[cncfan 0]

Skip the testing for beta9, it was still corrupt, I did the third complete rewrite of the scaler and will contribute the result until this evening. It totally fulfills my needs and expectations now. Nothing is hardcoded, all is stretched and centered as one might expect without any exceptions, no dirt visible anywhere any longer. I would like to see this version getting the final release.

 

Note that in beta 9 I found that the Europe and Africa map scenes no longer used the video stretching logic for some reason, so you clearly changed something there. If you're using the palette index #0 method for that "is interlaced" check too now, please make sure to include colour #2 in that check as well. As I showed in the pic, the leftover bars I made into colour #2 reach the side of the 640x400 screen. So the right-side edge was never 100% pure #0 black in the first place.

I would be pleased if you could provide me with your new C&C95.exe that does use the palette 2 thing.

I can't find it on your webpage...

I am still using the old one and can't verify and fix the bug you described since.

 

If I get the new version from you I will check the compatibility and give you my release candidate of cncddraw....

Edited January 31, 2011 by cncfan

[Nyerguds 102]

Uhh, I sent you a private message with the link to an entire beta patch. I even asked you after sending it if you had tested it out yet, and you never responded to that.

 

I'm compiling an installer right now, I'll upload it right away.

 

Did you test out the beta patch I sent you as private message?

[cncfan 0]

Sorry I missed that...

 

I will give you the release candidate today...

[cncfan 0]

The map scenes do work with my RC version without doing any changes. So here it is:

cncddraw_2011-01-31_RC1

 

Changelog:

-VQPhack working again

 

-correctvideoar, correctingamear work for ANY C&C95 output to ANY cncddraw resolution now, no exceptions, no fallback.

use them for ar correct fullscreen playing on non 4:3 monitors (like 16:10 , 16:9 , 5:4 , .... , X:Y) without losing visible content

 

Though it's still recommended if you use correctingamear=true to set cncddraw height to at least 1,2*C&C95 height (for 640x400 and 1024xXXX C&C95) to avoid ingame content being scaled down

eg: if you want to play fullscreen with correct ingame ar on a 16:9 display with C&C95 640x400 and correctingamear=true

set 1024x576 cncddraw but you SHOULD not set 800x450

ar would be correct in both cases, but the second will cause downscaled ingame content.

 

-removal of pixel dirt, everywhere...

 

-changed some default settings in ddraw.ini for best compatibility

windowed=true (since if selected resolution is not suitable for fullscreen, game will still start)

correctvideoar=true (since it just works, and downscaling is not such a problem here (vids are 320x200 max)

correctingamear=false (since if people choose C&C95res=ddrawres ingame would be scaled down)

vqphack=false (since it consumes more cpu and not everybody needs it)

 

I hope this one will be the final. It is feature-complete. I will wait another 3 days from the time of this post and if you don't find any bugs in the meantime I will claim it final and send the code to HIFI.

 

Please test this version very carefully since, if things won't get fixed now, they won't be for a long time since I have other things to do then.

 

 

Please note the following:

As stated before, your new ccsetup.exe in r2beta does NOT run on my computer. It starts without window, creates conquer.ini and closes. Does it need .NET or something like that? This is most probable a bug on your side.

Edited February 1, 2011 by cncfan

[Nyerguds 102]

Yeah, I already found the problem with the ccsetup... it's a null pointer error when checking the exe info in thipx32.dll (since certain versions of the dll don't contain exe info). It's fixed now, but I didn't reupload the patch for it. I can send you the updated tool though.

 

The map scenes do work with my RC version without doing any changes.

It's in the low resolution. Please don't test only in high res.

Here's a pack of lo-res end of mission savegames (GDI1, Nod 1, GDI before the Bosnia mission, Nod before the South Africa mission). Could you please test with those?

http://nyerguds.arsaneus-design.com/cnc95u...ta/endsaves.rar

 

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.

And as you see in the image I posted above, the lines I changed to colour #2 reach the edge of the 640x400 frame.

 

The 640x400 area in 1024x768:

 

 

 

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