Suggestions for Nyerguds C&C TDawn 1.06c

[cncfan 0]

Dispite the cropping - just for the scaling:

 

I have a texture with dimensions

ddraw->render->width=ddraw.ini[width]

ddraw->render->height=ddraw.ini[height]

 

the values from ccsetup are stored here:

ddraw->width

ddraw->height

 

 

if i want to scale something, there are 2 scaling factors:

scale_h

scale_w

 

when set to 1, nothing is changed

when set to 0.5 the dimension is DOUBLED

when set to 2 the dimension is cut by half

 

for noninterlaced ingame content my formula is simple

scale_w=ddraw->width / ddraw->render->width

scale_h=ddraw->height / ddraw->render->height

 

Does this work the way you want it? Even if you play at conquer.ini HiresHeight?

 

 

for interlaced movie content with a resolution of 640x400 my formula looks like this (in fact it is more complex, but if the source would be 640x400, it looked like this)

 

scale_w = 640.0/ddraw->render.width;

 

if ddraw->width==1024

scale_h = 400.0/ddraw->render.height;

else scale_h=ddraw->height/ddraw->render.height;

 

 

Can you help me out? I'm not an idiot but things start to swirl in my head....

I know that I have to expand the texture dimensions in y for it to work correctly....

 

Edited January 20, 2011 by cncfan

[Nyerguds 102]

I still not fully understand, sorry, but this is very complex for me since I have to do this different for ingame, for videos, for videos with solid fonts and for videos having vqphack enabled. AND THAT FOR 3 DIFFERENT ingame RESOLUTIONS where everyone has its own aspect ratio. (And the 1024 version is able to change its vertical resolution to make it even more complex)

All that must be scaled TO every possible ddraw output resolution.

 

You don't get it... there aren't just 3 game resolutions. The 1024 resolution's height can be adjusted to anything the user wants, and the ddraw settings can stretch that to anything the user wants. The only solution is one single formula, which is what I gave you.

 

 

The behavior of beta3 is like this:

I do the scaling of the CUTSCENES not just scaling to FS, but in that way, that it matches the aspect ratio of the ingame scenes in all 3 resolutions:

Not every chosen ingame resolution (chosen in ccsetup) does match the correct AR requirements when playing back at a 4:3 display.

The difference in aspect ratio between the real game size and the window size is the only thing that matters. If there is no difference between the aspect ratio of the window and that of the game, the videos should just be stretched to exact multiples of the original video.

 

As a test I set the HiresHeight to 960 (that's possible in windowed mode) so I technically played on 1024x960, and then to 600 (so 1024x600). These resolutions were NOT scaled to anything else with the ddraw width and height settings.

The result was that the videos were stretched over the entire height in both cases, while they should have stayed the same, since there was no difference in aspect ratio between the real game size and the window size. In both cases, it should have stretched to either 1024x640 (on original 320x200 aspect ratio), or 1024x768 (correctly adjusted video aspect ratio).

 

Displaying for Command & Conquer on a 4:3 screen (Fullscreen,ddrawsettings=ccsetup settings)

 

ccsetup settings AR for cutscenes AR for ingame content

640x400 correct = correct (earth is round)

640x480 not correct = not correct (earh too wide)

1024x768 correct = correct (earth is round)

 

You can choose every 4:3 resolution in ddraw.ini and will always get the correct AR when playing back on a 4:3 display for movies and ingame

 

If you want to display C&C on a 16:10 or 16:9 display then you have 3 possibilities:

1.) Change resolution of ddraw to values other than 4:3, this will of course destroy your AR (stretching)

2.) crop pixels in y direction

3.) black boxes in x direction

I don't understand what you mean. My tests clearly showed that your stretching system made no difference between playing a 1024x640 game stretched to 1024x768, or a normal 1024x768 game. This means you ignore the original game resolution and only focus on the final window size. I just gave an algorithm for getting the video size correctly, on the full game width, in any resolution.

 

As for the game's native 640x480 resolution, don't mind it, it CAN'T be fixed. The resolution itself was a workaround that sacrificed any hope of getting a correct aspect ratio.

 

Problem is, most people nowadays have widescreen TFTs, which display 640x400 as actual 640x400 8:5, and not stretched to 640x480 as it should be. That is why I made the ddraw settings stretch it from 640x400 to 640x480. The monitor will accept the 640x480 as 4:3 resolution and display it correctly. All of that is irrelevant though, since your video stretching ignores the ddraw stretching settings.

 

If I get you right, you don't want any AR change from the way it is now in beta 3, but you want me to "crop" pixels in y direction instead, when selecting the "stretch" option and then display the resulting picture at the chosen ddraw.ini output resolution.

 

Is that correct?

Cropping pixels is something different than changing AR!

No. I complained about the fact it didn't change the aspect ratio at all. That's quite the opposite. The only thing I said about cropping was in the case the window resolution is smaller than the correct video resolution... as part of the centering mechanism.

 

 

If this should be true I suggest something different:

I introduce a new setting "AspectRatio" instead of your suggested "videostretching"

 

 

People should then only be able to choose between 640x400 and 1024x768 mode in your ccsetup for gameoutput (since AR is correct there)

Nobody would need the 640x480 setting anymore (this should reduce complexity of the setup)

 

New "AspectRatio" setting in ddraw.ini:

It can be set to values "4:3", "16:9" and "16:10"

when selecting 4:3 everything stays as it is (ddraw 1024x768, 1280x960,... give correct AR on monitors that have 4:3)

when selecting 16:10 I will crop pixels in y (ddraw 1024x600, 1280x800,.. give correct AR on monitor that have 16:10)

when selecting 16:9 I will crop even more pixels in y (ddraw 1024x576, 1280x720,.. give correct AR on monitor that have 16:10)

 

 

And finally we never use this freaky HiresHeight setting in conquer.ini anymore...

 

Is this the way it should be?

No, no, no, my point is, the aspect ratio should NOT be a part of the video settings; it should be 100% controlled by the Width and Height in ddraw.ini. But you ignore that in your calculations, and just look at the real window size.

 

If you just use the calculation I gave to get your final video dimensions, and put that in the game window, there should never be a problem.

[cncfan 0]

****, I realized that I was writing bull**** shortly after the post, but deleting the post came too late...

 

Again:

 

Dispite the cropping - just for the scaling:

 

I have a texture with dimensions

ddraw->render->width=ddraw.ini[width]

ddraw->render->height=ddraw.ini[height]

 

the values from ccsetup are stored here:

ddraw->width

ddraw->height

 

 

if i want to scale something, there are 2 scaling factors:

scale_h

scale_w

 

when set to 1, nothing is changed

when set to 0.5 the dimension is DOUBLED

when set to 2 the dimension is cut by half

 

for noninterlaced ingame content my formula is simple

scale_w=ddraw->width / ddraw->render->width

scale_h=ddraw->height / ddraw->render->height

 

Does this work the way you want it? Even if you play at conquer.ini HiresHeight?

 

 

for interlaced movie content with a resolution of 640x400 my formula looks like this (in fact it is more complex, but if the source would be 640x400, it looked like this)

 

scale_w = 640.0/ddraw->render.width;

 

if ddraw->width==1024

scale_h = 400.0/ddraw->render.height;

else scale_h=ddraw->height/ddraw->render.height;

 

 

Can you PLEASE help me out how to set scale_h and scale_w for your stretching mode?

I know that I have to expand the texture dimensions in y for it to work correctly....

[Nyerguds 102]

Huh, scaling is done with factors, not with target width and height? That's plain bizarre...

 

I'll figure it out one of the next days; don't really have time at the moment.

[cncfan 0]

Yes it is, but the reason for this is, that the data stays in the opengl texture and afterwards the texture is displayed by setting up the edges of the triangles that will display the texture. That's how HIFI coded it. Seems strange but probably the scaling is actually done by the graphics card in this way which may be very fast....

[cncfan 0]

I don't need your help anymore

 

I slept over it (I should do this more often ;-) ) and finally I got it.

 

It works the way you want (I'm absolutely sure this time) and in fact, i don't know why i didn't realize it before.

 

I thought everytime: The AR of the videos is the same as the AR of the ingame (what could I have done wrong) in the old version.

 

But the thing is, if you set cncddraw height to higher values than the height output of C&C95, you will change the AR of the ingamescenes (which is absolutely correct) but in the old version you didn't do the same thing for scaled video output. (what was wrong of course)

 

I realized that now. It didn't come into my mind earlier because I was always playing at C&Cheight=cncddrawheight so I never saw the effect.

 

I would never make the old behaviour accessible by the user via videostretching="fullscreen" since it is not a feature - it was definetely a bug!!!

(you could see this easy by setting cncddraw->height>>>>>>>c&C95height)

You would see things in computer memory that were never meant to be shown ;-)

Edited January 21, 2011 by cncfan

[Nyerguds 102]

Ahh, glad you figured that out. Yes, I was counting on cnc-ddraw changing the aspect ratio so the 640x400 was correctly stretched to 640x480.

 

Can't wait for your next release

[Chimas 7]

Another suggestion, although might not be simple:

 

Would be interesting if the game speed control could be placed somewhere in the sidebar menu.

[Nyerguds 102]

That's really not a good idea. Speed control also contains the saving to conquer.ini mechanism... which is only activated at the moment you confirm the change by closing the game controls. It'd be a mess to remake that on the sidebar and save it on every change. Not to mention, there's not really space to put it on the sidebar, unless I put it under the icons in hi-res, and since I'm eventually planning to somehow expand that, it'd be really poor planning to put something in the way there.

 

Also, since this has kinda turned into the Cnc-DDraw development thread, I'd rather that any other suggestions for the patch are posted in the sticky dev thread.

[cncfan 0]

cncddraw 2011-01-24 videoresize,deinterlace,vqphack beta4 by J.Henze (based on official 2011-01-10 by HIFI)

 

Changelog:

-fixed AR of videos for 1024xXXX (C&C95 HiresHeight<ddraw.ini[Height]) including centering in y

-vqphack working again

-some speedups

-removing of crap that might had shown before on borders bottom and right when playing cutscenes without solid fonts

-improved interlace detection for 1024 width input (removed ugly heuristic that is still in use for 640 width though)

 

What does not work:

-C&C95 HiresHeight>ddraw.ini[Height] (never did in 2011-01-10 by HIFI too)

 

2DO:

-minor improvement of solidfont displaying (linear scaling 200->400 instead of doubling)

-static linking of libpng

-codecleanups

-see below

 

Please note: When configuring C&C95 to display HiresHeight=600 and ddraw.ini[Height]=768 videos are scaled to fullscreen. But solidfontscreens are higher than display size in this mode. So I might add a new option "Letterboxed" that will add black bars left and right (preserving AR of videos) exactly the size, that these screens are fully visible again.

Good idea?

 

Note: In beta4 I forgot to remove a debug output, since everytime you start it, there will be created a file called ziel.txt in game folder, sorry, but this is not the last release....

Edited January 24, 2011 by cncfan

[Nyerguds 102]

The window height and width are always at least what the original game height and width were... downscaling was never supported, and shouldn't be, either

 

 

Preserving the video aspect ratio in less-than-640x400-ratio (like 1024x600) might indeed be a good idea... it's been bothering me for a bit, and as you say, simply adding black at the sides indeed fixes this problem.

 

 

[edit]

 

It's still wrong... now you correct the video aspect ratio anyway, which makes the "original aspect ratio" (1024x640->1024x768) have wrongly stretched videos with the top and bottom cut off. Just try setting hiresheight to 640 and the ddraw width and height to 1024x768, you'll see.

 

 

Just to repeat this... following the normal stretching rules I'd like, the video aspect ratio should NOT be correct in normal 1024x768. You should just stretch it normally like the rest of the game content is stretched.

 

If you want to put in aspect ratio correction for the videos, please make it an option in the ini file so I can disable it when using my 1024x640->1024x768 mode.

[cncfan 0]

It's still wrong... now you correct the video aspect ratio anyway, which makes the "original aspect ratio" (1024x640->1024x768) have wrongly stretched videos with the top and bottom cut off. Just try setting hiresheight to 640 and the ddraw width and height to 1024x768, you'll see.

 

Okay, we need to discuss things out, then, because I don't think that there should be any change on that behaviour....

 

setting:C&C95 output to 1024 and HiresHeight 768 and ddraw output to 1024x768: (playing at 4:3 screen)

look at the menu screen (ingame mode): The C&CLogo is round, thus AR is correct (same result as HIFI 2011-01-20) -> AR of movies has to be the same since

now look at the cutscenes (movie mode): Look the intro video, you see that scene where globe transforms to tiberium harvesting pie charts?

You'll see the globe is round = correct AR, same AR as menu screen (ingame mode). It has to be this way. The movie AR HAS TO BE FIXED in 1024x768 to achieve the same AR as ingame mode (menu). If I would change ANYTHING in this behaviour ingame and movie scenes would NOT be in the same Aspect Ratio anymore. I don't want that.

 

Now try stretching: C&C Output = 1024, Hiresheight=640, ddraw output 1024x768 (i can only play on my 4:3 screen too)

If you look at menu and globe again, you should see both having the same AR again!!! If this should NOT be true, I will change something again.

But if both AR are equal there is no reason to change anything in this behaviour.

If you disagree with that, please rationalize!

 

Just to repeat this... following the normal stretching rules I'd like, the video aspect ratio should NOT be correct in normal 1024x768. You should just stretch it normally like the rest of the game content is stretched.

This would lead to different AR for movie and ingame as stated above. This can't be a good idea since....

Do you agree with me that this would lead to different AR for movies and ingame?

 

If you want to put in aspect ratio correction for the videos, please make it an option in the ini file so I can disable it when using my 1024x640->1024x768 mode.

I COULD do that, but I can't understand why you want it this way....

Give me a least 1 rational reason!

 

Note: In beta4 I forgot to remove a debug output, since everytime you start it, there will be created a file called ziel.txt in game folder, sorry, but this is not the last release....

Edited January 24, 2011 by cncfan

[pichorra 4]

Just for you guys know: I don't know if the version you are editing are with the Wchat fix, if not, the peaple who will try to play trough it will have freezes-crashes...

[cncfan 0]

Just for you guys know: I don't know if the version you are editing are with the Wchat fix, if not, the peaple who will try to play trough it will have freezes-crashes...

This bug has already been fixed in my version since I'm working with the last available version of HIFIs 2011-01-10 (at the time of this writing).

You can visit his website and view the changelog to convince yourself.

 

I am planning on fusing my work into his version tree when I'm done with this.

 

If you are willing to beta test my versions and find ANY bugs, please doublecheck if these bugs are present in HIFIs 2011-01-10 version too.

If yes, report them to him.

If no, report them to me.

 

Please be sure to use always the latest of my beta versions since this is currently work in progress and I don't give any support to old ones that have known bugs.

Edited January 24, 2011 by cncfan

[Nyerguds 102]

I showed you the result... right now, it's impossible to get BOTH the videos and the gameplay in the correct old aspect ratio together.

 

 

Basically, what I would want, ideally, is to have the videos stretch with the same aspect ratio as the game, without any correction, so the stretching of everything can be controlled in the same way.

Then, you could add an extra ini option to fix the aspect ratio of the videos (like you do now), which can be used for correcting the videos if the ddraw width and height are the same as the game dimensions.

 

 

And if you want my "one reason": It's the only way the videos can be made to look correct in all video modes that can be set.

 

 

Screenshots from the current dll in the aspect-fixed resolution (1024x640 stretched to 1024x768):

 

Are you seriously telling me those look round to you? And not cut off at the top and bottom?

[cncfan 0]

 

beta5a

 

 

 

Changelog to beta4:

-Okay I added the option in the ini that you requested for keeping AR wrong

-removed debug output to ziel.txt

 

But I need your help for y centering for 1024 width setting:

 

current formulas for correctvideoar=true: (best for 4:3 displays)

scale_h = (float)(ddraw->height)/768.0 * (200.0/(float)(ddraw->render.height));

posyoffset=0.00017*(768.0-ddraw->height); //correct 1024xXXX y-drift caused by different AR

 

 

 

current formulas for correctvideoar=false: (your wish, best for 16:10 displays)

scale_h = (200.0/(float)(ddraw->render.height));

posyoffset=0; //correct 1024xXXX y-drift caused by different AR //THIS IS NOT CORRECT YET

 

 

can you please tell me how to set posyoffset for correctvideoar=false

maybe even better: find a formula for posyoffset without hardcoded values like 0.00017 in correctvideoar=true for both versions

 

Maybe I will do add support for 16:9 and all other monitor aspect ratios by introducing letterboxing... (I would rename the correctvideoar then to videoar=16:10 , 4:3 , 16:9 , X:Y

But I would need a formula for posyoffset without hardcoded values to achieve that.

 

video of 200 pixels source height (for 400 source height the value for scale_h is multiplied by 2 [for solidfontscreens])

 

Both scale_h and posyoffset are RELATIVE values.

 

posyoffset>0 shifts movie up

posyoffset<0 shifts movie down

 

ddraw->width = C&C95 width

ddraw->height = C&C95 height

ddraw->render.width = cncddraw width

ddraw->render.height = cncddraw height

Edited January 24, 2011 by cncfan

[Nyerguds 102]

At this moment, the "correctvideoar" doesn't affect the normal 1024x768 resolution at all; switching it on or off gives the same result. This certainly isn't correct.

 

Anyway, I think the easiest way to help you with this is to have the the scale_h (and scale_w) as floating point numbers in the ini file, so I can test out everything myself, and give you the results.

[cncfan 0]

beta5b

 

 

At this moment, the "correctvideoar" doesn't affect the normal 1024x768 resolution at all; switching it on or off gives the same result. This certainly isn't correct.

This is not true as i will explain in detail later. Altough there is still a bug in beta 5a, BUT this one does only affect solid font videos in correctvideoar=false version. So here is beta 5b. But despite solid font screens beta5b does treat movie screens equally to beta5a.

 

PLEASE READ ON AND CAREFULLY.

 

I think I know what's the problem....

The problem is that your menu pic in 1024 mode has not the same ar as actual map ingame scenes and because I oriented on this menu screen when judging ingame ar i messed things up over and over.

 

Just for understanding, please do the following test: (this is how all things should look like)

set C&C95 settings to 640x400, set ddrawsettings to 640x480,windowed

this setting should give you:

correct movie ar (globe is round)

correct menu ar (c&c logo is round, pic does fit to screen)

correct ingame ar

 

If you use beta5a set C&C95 to 1024x768, set ddrawsettings to 1024x768,windowed,correctvideoar=true

you will get:

correct movie ar (globe is round)

correct menu ar (c&c logo is round, pic does fit to screen) ->this was the thing that got me wrong

WRONG INGAME AR (that is what i did not notice since i thought it has same ar as menu)

This is how I will play the game since fullscreen is more important than correct ingame AR to me.

Furthermore no ingame or menu scaling is needed what results in high visual quality.

 

If you use beta 5a and set C&C95 to 1024x640, set ddrawsettings to 1024x768,windowed,correctvideoar=false

I THINK THIS IS THE RESULT YOU WOULD LIKE TO HAVE, what is wrong with this???

you will get:

CORRECT MOVIE AR (globe is round) ->but not centered in y, since my help request

wrong menu ar (c&c logo is not round, looks like an egg, pic does not fit to screen)

correct ingame ar

 

IT IS IMPOSSIBLE TO GET MENU AR AND INGAME AR CORRECT BOTH WITH C&C95 1.06c IN 1024, because of YOUR pic for this mode. The game itself does display things differently at this moment. You have to choose between the two.

THAT IS A THING THAT YOU SHOULD HAVE TOLD ME BEFORE, BECAUSE IT DIFFERS TO 640 modes!!!

 

If you use beta 5a and set C&C95 to 1024x640, set ddrawsettings to 1024x768,windowed, correctvideoar=true

you will get:

WRONG MOVIE AR (globe is not round, looks like an egg)

wrong menu ar (c&c logo is not round, looks like an egg, pic does not fit to screen)

correct ingame ar

I CAN CHANGE THE VIDEO AR AS LONG AS I WANT, MENU AR WILL EVERYTIME BE CORRUPT IN THIS SETTING.

PLEASE NOTE THAT YOUR STATEMENT, THAT CORRECTVIDEOAR HAS NO EFFECT IN 1024 IS NOT TRUE

I think this is the setup you tested and this indeed is crap, it should never be used this way.

 

If you use 2011-01-10 by HIFI and set C&C95 to 1024x640, set ddrawsettings to 1024x768, windowed

you will get:

correct movie ar (although interlaced and not scaled)

wrong menu ar (c&c logo is not round, looks like an egg, pic does not fit to screen)

correct ingame ar

 

AS YOU CAN SEE HIFI HAD EXACTLY THE SAME AR BEHAVIOUR AS 5a WITH CORRECTVIDEOAR=FALSE

And you keep telling me that it's different...

I can't see any difference despite that interlacing is removed and that the videos are greater in 5a (what is what we all want) and that they are positioned differently in y.

AR is the same in all states

 

 

That is to do from my point of view:

-fix y positioning of videos in 1024 correctvideoar=false mode

-YOU SHOULD ADD AN OPTION IN CONQUER.INI TO REPLACE THE MENU PIC WITH AN AR CORRECTED VERSION THAT MATCHES INGAME AR IN HIGHRESHEIGHT 640 SETTING (this way users of 4:3 screens could play 1024 in fullscreen with correct movie,menu and ingame ar, furthermore users of 16:10 displays could play in 1024 windowed with correct movie,menu,ingame ar or maybe later fullscreen letterboxed left/right with all 3 ars being correct)

 

If you think that something else needs to be fixed, please let me know what the hell you mean. I can't understand you at all anymore. We have to be very precise when where under which settings ar is not correct.

please use my scheme from this post to make things as clear as possible.

Edited January 25, 2011 by cncfan

[Nyerguds 102]

Could you please make a beta which does NOTHING automatically, but just reads the scale_h and scale_w as floating point numbers in the ini file? It's the only way I can accurately test out everything and tell you what I think will work best.

 

 

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

 

My main menu background image in 1024x768 mode is indeed stretched. It was never made to match the video since I had never managed to expand the videos, but I just wanted to show the background correctly.

 

However, what you don't seem to realize is that the 1024x640 mode already has a separate main menu image, with the original aspect ratio. This change is done automatically, by detecting the 1024x640 resolution. I don't see why it would require any ini keys. It already works.

 

So the correct bahaviour with correctvideoar=false should be that in normal 1024x768 it does NOT match with the background image. The video needs to be less high, since it should keep the 640x400 aspect ratio. Your code shouldn't check for the 1024x### height, JUST for the correctvideoar ini key. Otherwise, you get conflicting automations.

 

If you use beta 5a and set C&C95 to 1024x640, set ddrawsettings to 1024x768,windowed,correctvideoar=false

I THINK THIS IS THE RESULT YOU WOULD LIKE TO HAVE, what is wrong with this???

you will get:

CORRECT MOVIE AR (globe is round) ->but not centered in y, since my help request

wrong menu ar (c&c logo is not round, looks like an egg, pic does not fit to screen)

correct ingame ar

I tested that out, and it was still wrong. The whole image was moved up about 65 pixels, meaning it got cut off at the top. It just didn't center correctly. I have no idea how something like that could happen if you just center in the available space...

 

 

Here you see both the end of the intro video, and the main menu, in 1024X640 stretched to 1024X768, with correctvideoar=false

 

The aspect ratio is correct, but the video image is moved up too much.

[cncfan 0]

If you use beta 5a and set C&C95 to 1024x640, set ddrawsettings to 1024x768,windowed,correctvideoar=false

I THINK THIS IS THE RESULT YOU WOULD LIKE TO HAVE, what is wrong with this???

you will get:

CORRECT MOVIE AR (globe is round) ->but not centered in y, since my help request

wrong menu ar (c&c logo is not round, looks like an egg, pic does not fit to screen)

correct ingame ar

I tested that out, and it was still wrong. The whole image was moved up about 65 pixels, meaning it got cut off at the top. It just didn't center correctly. I have no idea how something like that could happen if you just center in the available space...

I was talking about AR, AR is correct, but if you would read the bold letters, you would know that it still needs centering in y position. That was my help request. But you can't say AR is wrong when indeed only positioning is wrong. Please be precise!

 

However, what you don't seem to realize is that the 1024x640 mode already has a separate main menu image, with the original aspect ratio. This change is done automatically, by detecting the 1024x640 resolution. I don't see why it would require any ini keys. It already works.

This does NOT work on my PC setup. Not with 5a or 5b nor with HIFIs 2011-01-10....

 

ddrawsettings=1024x768 both:

If I play it in 1024x640 C&C95 the menu ar is wrong (stretched), picture cut off on bottom.

If I play it in 1024x768 C&C95 the menu ar is correct, picture does fit on the screen.

 

I will try without ddraw.dll at all, wait a few seconds please.... (Stupid, this is not possible of course, since I can't set this resolution in fullscreen on my 4:3 monitor)

 

I tested that out, and it was still wrong. The whole image was moved up about 65 pixels, meaning it got cut off at the top. It just didn't center correctly. I have no idea how something like that could happen if you just center in the available space...

Could you please test with 5b if solidfont videos are displayed with correct y offset and correct AR.

Both should be true...

Edited January 25, 2011 by cncfan

[Nyerguds 102]

The aspect ratio is indeed correct, yes. But the fact you HAVE a difference means you do something different for 1024x640 mode compared to 1024x768 mode. That shouldn't happen at all. The stretching in 1024x768 mode should always react the same way, no matter what's set as height. The only thing that should influence it is the correctvideoar key.

[cncfan 0]

The aspect ratio is indeed correct, yes. But the fact you HAVE a difference means you do something different for 1024x640 mode compared to 1024x768 mode. That shouldn't happen at all. The stretching in 1024x768 mode should always react the same way, no matter what's set as height. The only thing that should influence it is the correctvideoar key.

This is true, indeed, I will investigate.

 

Please reread my last post [i edited it] (test solidfont movies).....

 

Can you please investigate that main menu thing, it really doesn't work here. My version is 1.06c r1f1

 

Another thing: my intro video is that one where TV zapping occurs - yours seems to be the nuclear bomb.

Could that be the reason for your background image detection to fail on my sys?

 

How do you detect which menu pic to choose?

If you do this by checking the AR of operating system screen resolution this is wrong and would explain why it does not work as expected here on my system, you should decide which background pic to take just by using C&C95 output AR (1024x768 is 4:3, 1024x640 is 16:10)

 

Shall I upload my whole C&C95 folder to rapidshare? Size about 936 mb....

My OS: Win XP Pro SP3 screen resolution 1280x960 graphics card ATI 4350

Edited January 25, 2011 by cncfan

[Nyerguds 102]

Oh, I'm so sorry!

I've been testing this on my own version of 1.06c revision 2... I didn't realize the special 1024x640 title screen was one of the new things I added... I thought it was already in revision 1

 

 

I could give you a beta if you want... then you have the same things I have.

 

[cncfan 0]

I wouldn't mind getting your beta, because this is a nice extension, but this is not a must have. Since I know now, how my old version acts, I will be able to interpret things correctly.

 

Nevertheless I want you to look at a solidfont video with beta5B and c&c95 output 1024x640 and ddrawsettings 1024x768 and correctvideoar=false

 

If the SOLIDfontvideos there display in the correct AR and the correct y offset I will make the videos without solidfonts(=cutscenes) act the same way.

 

In my opinion videos with solidfonts should already be displayed the way you want it to be in beta5b.

Edited January 25, 2011 by cncfan

[Nyerguds 102]

In 1024x640, with correctvideoar=false, the scenes with fonts on them display 100% correctly, yes.

 

But in 1024x768 they're stretched as if correctvideoar would be enabled.