cncfan

Hello, first of all: Great work Nyerguds, I love your C&C Updates! But 2 suggestions: First: I think, there are 7 video files missing in the video download pack that Nyerguds announced here: http://download.digiex.net/Games/C&C%2...movies_full.rar The files can be found on the (german) Covert Ops CD or in the TFD covertops in the movies.mix banr_nod.vqa blackout.vqa bodybags.vqa (foreskl.vqa) inferno.vqa iontest.vqa refinery.vqa I'm not quite sure if every file is used by the game, BUT IONTEST is definetely used by the last CovertOps NOD mission entry. When using the movies pack "as it is" you won't see the introduction movie when selecting this mission. Probably anyone might add them to the moviespack (I could do it by myself if there would be any interest) But if I do it, I would like to upload it to Nyerguds because his site is some kind of centre in the CNC TD world. Any interest Nyerguds? Second: It would be a GREAT IMPROVEMENT if the videos in the Windows version would be displayed as non-interlaced (as they are in the DOS-Version) I already tried to modify the headers in the vqa files (hight,weidth and/or block sizes) but without success. I think the only way would be to modify the game executable itself. Is anybody able to do that? If not, then the only way would be freecnc, an open source reimplementation of the CNC executable http://www.freecnc.org Unfortunately the development seems stuck since end of 2004. Maybe Nyerguds work can be fused with that project? That would also give an option to circumvent the 1024x768 display problems in the first maps. Best regards

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 }

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).....

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

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.

This thing gives me no rest. This Thread is about the graphical glitches in the first 3 missions when playing at 1024x768 caused by the maps being actually smaller than the screen resolution. Hi Nyer ;-) As you might remember I made a proposal to change the colour of the pink area http://nyerguds.arsaneus-design.com/junk/ingame_col0.png from palette #0 (transparent) to black Your concern was that the game might not be able to draw anything above that black anymore. I don't think that this is true because it IS able to draw the tooltips from the build queue above actual map colours too which of course are not transparent.... Won't you give it a try?

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.

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

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....

Regarding that Level 1-3 thing: 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.

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...)

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)

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)

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???

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...)...

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?

Ok I will rework the covertopsboxhack then. Great! Can you do this please? (Maybe even independent for different resolutions, so that 640x400 is still focused lower right when starting the game)

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. Of course it is. Nice if one is able to change C&C95 AND ddraw.dll behaviour, not just one of them^^. Nice work 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. 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....

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?

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. 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! 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. 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). I completely agree. 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.

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. 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* 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. 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....

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? 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? 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....

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.

Sorry I missed that... I will give you the release candidate today...

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. 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....