26 replies to this topic

[Shosci]

A script for changing the DMap from Day to Night.
 
The simplest thing I would think of in terms of making the script would be so every said minute would change the DMap's Cset. Maybe having 4 different Csets for one loop.

OR

Having the DMap change its Cset based on the computer's real-time clock. Seems more complex, but man that just blows my mind.
6 AM - 12 PM: Sunrise
12 PM - 6 PM: Daytime
6 PM - 12 AM: Sunset
12 AM - 6 AM: Nighttime

 

If anyone is able to do either of these or if there's already a script for this, let me know along with the setup.

 

~ Epad 

[Moosh]

ZScript can't read from the real time clock and can't write to palettes. This means that the only way we could do this would be with warps which would cause problems with the screen resetting enemies and everything every few minutes. You could check sprites carry over in warps on every screen, but then you couldn't use any tile warps in the quest and I don't think anybody wants that.

[CaRmAgE]

A better solution is to draw a transparent rectangle over the entire screen to simulate the different times of day.  You can find a discussion on this type of script here.

 

Direct link to zim's quest, which has the day/night script: Download

 

I would love to link to just the script, but I don't think it exists as a separate entity.

[Shosci]

So how does the script affect the transparent layer according to the code?

[Lejes]

I took a look at it, and it seems like he's simulating night by just stacking multiple transparent black layers on top of each other. He has a nice lantern effect going too, by drawing arcs instead of just filling the entire screen with a rectangle.

void Lantern(int r)
	{
	//Screen->Rectangle(7,0,0,240,0,0,160,240,160,10,true,128);
	if(Link->Dir==0)
		{Screen->Arc(7,Link->X+7,Link->Y+7,r,290,70,15,1,Link->X+7,Link->Y+7,270,true,true,OP_TRANS);}
	if(Link->Dir==1)
		{Screen->Arc(7,Link->X+7,Link->Y+7,r,290,70,15,1,Link->X+7,Link->Y+7,90,true,true,OP_TRANS);}
	if(Link->Dir==2)
		{Screen->Arc(7,Link->X+7,Link->Y+7,r,290,70,15,1,Link->X+7,Link->Y+7,180,true,true,OP_TRANS);}
	if(Link->Dir==3)
		{Screen->Arc(7,Link->X+7,Link->Y+7,r,290,70,15,1,Link->X+7,Link->Y+7,0,true,true,OP_TRANS);}
	}

Here's the relevant section of the code. He just calls this function for multiple values of r, to stack the layers for a darker night and make it look like your lantern light fades as it gets further away from you.

[Shosci]

@Moosh What if the Cset changes every given minute on the ZC clock?

[Moosh]

@Moosh What if the Cset changes every given minute on the ZC clock?

Are you making a Classic quest? In a case like that you might be able to compress all the colors you need for a screen into a single CSet. Otherwise, using CSets wouldn't work. You could read from the ZC clock, but I believe that caps after a certain point, so a global variable that wraps back to 0 when it reaches they end of a cycle would be preferable.

 

Zim's method can work, but mass transparent layering in ZC has a tendency to produce very ugly results, especially if you double the number of layers.

[kurt91]

What about using multiple DMaps, with carryover secrets to keep everything consistant, and a simpler script that increments a counter every screen transition. After the counter hits a certain point, the next screen transition transfers you to the next DMap in line.

 

Also, if you plan on taking the transparency route, I've found that a good way of faking a paler transparency would be to use a 50/50 dithering effect with a maximum speed two-frame animation that alternates the clear and filled pixels. I used that method for a tranparent fog effect that looks very good when layered with a canopy shadow transparency over it, and it may help you if you decide on layering additional transparencies for your intended effect. (I don't know how well it would work since you're doing a full-screen transparency, but with my fog animation trick, the effect was made even smoother by making the layer scroll diagonally as well.)

[Shosci]

@Moosh I am using DoR, so having multiple layers wouldn't really help the quest's design,. I have seen Zim's Quest, but I don't think it would work out well for me.

 

@kurt91 I never worked with carry-overs, so I'm not sure how it would work. Would it carry a sprite that already has been triggered (like opening a chest) to the next Dmap?

[Timelord]

The internal clock is stored as an int, rather than a float, (for whatever reason) in seconds. That should cap at 214,748 seconds, translating down to:

 

4,129 minutes, 8 seconds; or...

68 hours, 48 minutes, 8 seconds; or...

2 days, 20 hours, 48 minutes, 8 seconds.

 

If your game is large enough to exceed that, I'll give you a function, and matching array to store game time; that I'll be using as a basis for something similar to what you want to do here. I've experimented with a few methods to simulate day/night, and other cyclical changes, usually using global functions and draw commands. (If you don't expect to need 68+ hours for a player, then you can use the value of int Timer.)

 

An alternative, that hasn't been mentioned, but that would require extensive work, is to store every 'day' combo, and its matching 'night' combo a set number of spaces apart on every combo page, and during a transition, use draw commands to replace all combos on any given screen with the /- value of its matching combo. You could do that wish a basic for loop, but the work involved in making a day/night tileset would be extraordinary.

[Moosh]

Also, if you plan on taking the transparency route, I've found that a good way of faking a paler transparency would be to use a 50/50 dithering effect with a maximum speed two-frame animation that alternates the clear and filled pixels. I used that method for a tranparent fog effect that looks very good when layered with a canopy shadow transparency over it, and it may help you if you decide on layering additional transparencies for your intended effect. (I don't know how well it would work since you're doing a full-screen transparency, but with my fog animation trick, the effect was made even smoother by making the layer scroll diagonally as well.)

I just tried this and it created a scanline effect. Is it possible that the trick only works for some computers?

Anyways, EPad, here's an old quest of mine that never took off that illustrates the problems with a Day/Night script changing DMaps: https://www.dropbox....cQuest.qst?dl=0

You can hold down Ex1 to speed up the clock and observe what happens to the enemies as the palette changes.

[Shosci]

@Moosh I checked out the Epic.qst and it is very close to what I was looking for, minus the timer on the bottom and the long period of time itself. I was probably aiming to do 3 or 5 minutes for each transition. I only stopped after the Dmap changed so I wasn't sure if the timer stops if it reaches a certain point like Majora's Mask.

 

Now I am only having a timer for a large section of my overworld, two sub-overworlds uses a different Cset so I don't think it will look nice with the Night Cset. Can I try the script in my quest for a bit? If so, what do I need to change for the transition to work over time, how does the set up work, and does the timer continue if I go to another Dmap?

[Moosh]

I imagine I can rewrite the script to be more customizable, but a word of warning: Using this script may lead to your quest being engulfed by the darkness of ZScript for all eternity. By that I mean we may end up having to patch up bugs caused by scripts with even more scripts. Also it's a well established fact that once you go ZScript you never go back.

[Timelord]

Here's the basis for the time system that I'm constructing, however, you should note that I have a long list of  define events, well beyond mere day, and night:
 

int dayCycle = 0;
const int nightTime = 0;
const int dayTime = 1;
const int erevTime = 2;

float GameTimer[7]={0,0,0,0,0,0,0};

const int GT_SECONDS = 0;
const int GT_MINUTES = 1;
const int GT_HOURS = 2;
const int GT_DAYS = 3;
const int GT_WEEKS = 4;
const int GT_YEARS = 5;
const int GT_FRAMES = 6;

float InGameTime[12]={1,1,1,1,1,1,1,1,1,1,1,4};

const int IGT_ACTIONS = 0;
const int IGT_SEGMENTS = 1;
const int IGT_MINUTES = 2;
const int IGT_TURNS = 3;
const int IGT_SPANS = 4;
const int IGT_SESP_CYCLES = 5;
const int IGT_MAGN_CYCLES = 6;
const int IGT_DAYS = 7;
const int IGT_WEEKS = 8;
const int IGT_MONTHS = 9;
const int IGT_ANNUA = 10;
const int IGT_ERA = 11;

const int SECONDS = 60;
const int SECONDS_DIVISOR = 6; // Ten minutes per span increase.

void clockUpdate(){
	gameTimeUpdate();
	inGameTimeUpdate();
}

void inGameTimeUpdate(){
	inGameTime();
	inGameTimeDayCycle();
}

void inGameTime(){
	if ( GameTimer[GT_SECONDS] == 10 ||
		GameTimer[GT_SECONDS] == 20 ||
		GameTimer[GT_SECONDS] == 30 ||
		GameTimer[GT_SECONDS] == 40 ||
		GameTimer[GT_SECONDS] == 50 ||
		GameTimer[GT_SECONDS] == 0 &&
		GameTimer[GT_SECONDS] ==  0 ){
			InGameTime[IGT_SPANS]++; 
	}

	if (InGameTime[IGT_SPANS] > 56){
		InGameTime[IGT_DAYS]++;
		InGameTime[IGT_SPANS] = 1;
	}

	if ( InGameTime[IGT_DAYS] > 7 ){
		InGameTime[IGT_WEEKS]++;
		InGameTime[IGT_DAYS] = 1;
	}

	if ( InGameTime[IGT_WEEKS] > 5 ){
		InGameTime[IGT_MONTHS]++;
		InGameTime[IGT_WEEKS] = 1;
	}

	if ( InGameTime[IGT_MONTHS] > 10 ){
		InGameTime[IGT_ANNUA]++;
		InGameTime[IGT_MONTHS] = 1;
	}
}

void inGameTimeDayCycle(){
	if (InGameTime[IGT_SPANS] > 28) {
		dayCycle = nightTime;
	}

	if (InGameTime[IGT_SPANS] < 28) {
		dayCycle = dayTime;
	}
	if (InGameTime[IGT_SPANS] == 28) {
		dayCycle = erevTime;
	}
}

void gameTimeUpdate(){
	for (i=60: i>0; i--){
	Waitframe();
        }
        GameTimer[GT_SECONDS]++;
	if (GameTimer[GT_SECONDS] >= 60){
		GameTimer[GT_MINUTES]++;
		GameTimer[GT_SECONDS]=0;
	}
	if (GameTimer[GT_MINUTES] >= 60){
		GameTimer[GT_HOURS]++;
		GameTimer[GT_MINUTES]=0;
	}
	if (GameTimer[GT_HOURS] >= 24){
		GameTimer[GT_DAYS]++;
		GameTimer[GT_HOURS]=0;
	}
	if (GameTimer[GT_DAYS] >= 7){
		GameTimer[GT_WEEKS]++;
		GameTimer[GT_DAYS]=0;
	}
	if (GameTimer[GT_WEEKS] >= 52){
		GameTimer[GT_YEARS]++;
		GameTimer[GT_WEEKS]=0;
	}
}

This is the best way of which I'm aware to translate rel-world time (in seconds, rotating other counters to negate caps) into in-game time. I 'm using cascading functions for modularity, and some of these tracking events are very-specific to my work (e.g. Sesperzium Cycle).

I'll likely include it in RPG.zh, in a more-refined manner, assuming that I find a better way to handle blocks of time conversions, using constants, division, and a % == 0. Suggestions in that regard, I'd appreciate, as my current plan is to use integer division, and use two constants for operands, and if the division result yields a modulus value of 0, then the operation is a success...

That seems the best way to allow user-defined time conversion.

Edited by ZoriaRPG, 25 August 2014 - 10:57 PM.

[Shosci]

Great! I don't know what else to say from your response @ZoriaRPG. Any more advanced coding talk will make my head spin