Getting rid of the dimming and lightening up

Renergy

Warlord
Joined
Nov 2, 2010
Messages
197
Location
Czech Republic
I have another suggestion/wish for a patch.

The goal: to get rid of the fade-out, fade-in dimming and lightening up that occurs many times in the game, most notably when looping through cities in the beginning of a turn, when the city screen comes up.

I mean: [animations turned off, of course] "Rome builds Mfg. plant" - select something - fade out, fade in - "Civil disorder in Caesarea" - fade out, fade in - "Tenochtitlan builds diplomat" - ... One "blink" and almost an extra second per city. Especially in later stages of the game, this blinking is rather annoying and slows things down.

The optimum behaviour when closing the city screen would be what happens now when it was opened by clicking on a city on the playfield = no extra blink on exit.

Perhaps, hopefully, there is a procedure for this dimming and lightening, so this might require just a small change on one place... then again, perhaps not.


Do you think darkpanda (or anybody) this could be easily attainable?


PS: darkpanda, your tutorial to IDA and civ.exe disassembling is - well - breathtaking is the word. :eek: :goodjob: To not just "ask for something and do nothing" ;) I actually began/tried to work on the problem myself. I searched for "3C8h" = c8 03 byte sequence [specific VGA port for changing palette] and managed to find a subroutine that seems to set the palette, and it is called from another one that waits for vsync and sets a timer, BUT that's about it, I'm kind of stuck now (there is a retf too early in the second func which puzzles me, I'm an ida-beginner).


Edit: Sorry for bad english, I should have written "fade out" and "fade in" instead of "dimming" and "lightening up". My mistake. To state my goal again clearly, I just want to eliminate all the fade-ins and fade-outs.
 
Congrats for having taken to the tutorial! If you went all the way down to VGA ports by yourself, you almost don't need anything else from me anymore... :)

Well just one thing maybe - which is supposed to be the topic of the next tutorial installment: overlays and "drivers". I suspect that the early 'retf' is either a null-sub in its own right (there are some), or you found it in a "driver proxy slot" location (for lack of a better definition). Those are locations where CIV will overwrite its own code with segment/offset to actual sub-routines for graphics, audio, or other peripherals (mouse and keyboard). Such sub-routines are not in CIV.EXE but rather in M/E/TGRAPHIC.EXE, A/T/R/NSOUND.CVL, and MISC.EXE, and are loaded dynamically after Civ startup, basically after selecting the desired graphics and sound. Note that this has nothing to do with IDA itself, it's Microprose proprietary code to handle driver loading (or maybe provided by a third party).

I have written some IDA scripts to simulate the driver loading and obtain a complete EXE unable in IDA, hopefully I can share it in my next tutorial (it's a bit convoluted).

Anyway, I see your point about fade-in/fade-out... Personally, what irritates me the most is the "random pixel fade-in" of the main title screen: I spend so much starting and starting and starting CIV over, that I am considering getting rid of it completely. If you think of it, this is what takes the longest time when starting CIV!

Also: for fade-in/fade-out, I noticed that it is usually related with PAL or PIC loadng: when you discover Invention for example, a fade occurs in order to replace your 'ancient' cabinet with the 'modern' cabinet (advisors graphics and background). I am suspecting that this also occurs when processing other Civs, that may be still ancient when you're modern (diplomacy screen preparation). For city exit I don't know...

Anyhow, I'll try and have a take on this :)
 
It's not what you asked for, yet, but I successfully sped up the CIV start-up "logo fade-in" - you know, the one that takes ages to show up the CIVILIZATION logo, randomly displaying pixel after pixel...

To do this, the patch below modifies one of the a parameter that is passed to a sub-routine dedicated to "random pixel fade-in" - this routine is also used to make new buildings appear in cities, new palace parts appear, as well as in the "hall of shame" when vanquished leader portraits are faded-in/out to the wall frames.

The modified parameters controls the speed at which the transition occurs, or more precisely, the delay between 2 pixels being displayed.

For the intro screen, this delays seems to be 20 somethings (20 milliseconds?), so the patch below changes it to 3 instead:

Code:
offsets:
	EN474.01: [b]0x2CD7C[/b]
	EN474.03: [b]0x2C583[/b]
	EN474.04: [b]0x2C583[/b]
	EN474.05: [b]0x2CD83[/b]
	EN475.01: [b]0x2CD7C[/b]
	FR474.05: [b]0x2E183[/b]

original bytes: [color=green]B8 14 0050B8010050[/color]
 patched bytes: [color=green]B8[/color] [color=red][b]03[/b][/color][color=green] 0050B8010050[/color]

Looking out for the "fade to black" now...
 
News from the front: there are actually 2 separate routines involved in the effect you're trying to kill.

One routine is used for palette fade-out (to black). This routine is called from 4 different places in the code (and I didn't check, but there may be additional code doing fade-to-black on the side... to be confirmed).

Another routine is in charge of the palette "fade-in", and this one is called from other places, with a different sequence of sub-routines, and different timing.

What's for sure is that there is also a parameter to control the speed of the fade-in/fade-out, so at the minimum it would be possible to make it faster.

For the rest, stay tuned...
 
Thanks for the update!

As for the speed-up of "pixel-in" of the initial CIV logo - neat touch!

The fade-in and out is indeed probably connected with .pal loading (after all, civ has to set the palette somewhere). I found that when you open the city screen by clicking on a city, then "view" the city picture, a fadeout does occur on close; if you don't "view" the city picture from within city screen - no fadeout, it returns immediately to playfield on close.


I doubt the following will be of any help, anyhow here is a (hardly complete) list when the fade-out occurs:

- starting menu fadeout
- customize menu fadeout
- fade-ins and outs in intro (those are ok btw, but don't care if they go away too)
- "Caesar, you have risen to become leader..." fadeout

- closing city-screen in initial loop through cities at the beginning of a turn (sic) OR if the city was just founded OR after you view the city picture

- after displaying civilization score [F9]
- after closing civilopedia
- closing palace screen
- closing spaceship screen
- closing victory screen (guess)
- after researching invention (advisors change)

Actually, just disabling the "blinking" when looping through cities that needs attention would be a major boon in late game. But I do realize/think it is all interconnected.
 
Finally, I could determine that the 2 sub-routines involved in the fade-in/fade-out are actually both calling the same sub-routine, which is in charge of cross-fading palette data:
  • the fade-out routine sets the "target" palette to "full black" (or more precisely to "full any-color-of-your-choice")
  • while the fade-in routine sets the "target" palette to the latest loaded palette

This cross-fading sub-routine takes one argument, which is passed through ax register rather than on the stack.
This argument is, just like before, some kind of "delay", which controls how fast the cross-fading occurs.

The 2 calling routines (fade-in and fade-out) have a "delay" argument themselves (passed on the stack form callers, this time), which they put into ax before calling the cross-fading sub-routine mentioned above.

Most of the time, the delay argument passed from higher level callers is set to 5, and sometimes to 8 or 10.

In the cross-fading sub-routine, the delay value passed through ax is first multiplied by 6, for no obvious reason (although I recall reading about 6 being the amount of CPU cycles necessary for the VGA device to process read and/or writes, but I may be mixing things up with AdLib sound device...).

So, I decided to patch directly the cross-fading sub-routine by hard-coding the smallest possible "delay" value instead of using "arg_delay * 6":
  • For hard-coded value 0, no cross-fading occurs and the screen transitions are instantaneous, however the palette colors get completely screwed up after one go
  • For hard-coded values 1 and 2, CIV crashes with a "divide by zero" error when trying to load a gamesave
  • For hard-coded values 3 and above, the cross-fading occurs without any problem, and the higher the value, the slower the cross-fading

The patch below does just this, hard-code this "delay" value to 3 instead of the minimum 5*6 = 30 in the original code: theoretically, the cross-fading transition should be 10x faster than before, but it's quite hard to judge with DOSBox's varying speeds at times...

Anyway, here is the patch:
Code:
offsets:
  EN474.01: [B]0x600[/B]
  EN474.03: [B]0x600[/B]
  EN474.04: [B]0x60E[/B]
  EN474.05: [B]0x60E[/B]
  EN475.01: [B]0x60E[/B]
  FR474.05: [B]0x600[/B]

original bytes: [COLOR="Green"]B406F6E4 8BE8A166000BC07506[/COLOR]
 patched bytes: [B][COLOR="Red"]B8030090 [/COLOR][/B][COLOR="Green"]8BE8A166000BC07506[/COLOR]

Renergy, tell me what you think of it, does this make your games more practical?
 
Hi I have a problem with the pixelated fade-in function (https://forums.civfanatics.com/threads/civ-1-dos-freezes-after-intro.625227/#post-15060620). Whenever it is called the game hangs in my P3 450 which runs dos 7.1 (win 98). I have tried the patches here but they did not help - with the intro patch applied the game just hangs straight away. Can I somehow get rid of the whole pixelated fade in and get things drawn straight away maybe? I have the same problem on the same machine with other Microprose games such as MoM.

Thank you.
 
Top Bottom