cncfan

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?