85 replies to this topic

[Saffith]

You've only got one tile for each. They use two consecutive tiles.

[Nana]

I have a problem with 2.50.1, when I download and extract the files my Norton blocks Zelda-w.exe with an error message of WS.Reputation.1

Does anyone know what this means and is it safe to use 2.50.1

I have had no problem downloading and using 2.5 or any other version.

Any help or information would be appreciated.

[Deedee]

I would love to see the ability to copy entire maps without changing the enemies in a future update. Changing multiple clone maps with different enemies is annoying (Not that I use it myself...)

[Omega]

Unless you run ZC on windows 8 in window mode, you will have a problem every time you press the Start key on your keyboard and resume ZC in fullscreen. It's all sideways and glitchy. Only happens with fullscreen.

[Dark Entity]

Window Scaling (1x, 2x, 3x, 4x) works with the Classic interface on ZQuest, but not with the new one.  Could this be included in an update?  It would be a massive help for people using 1920x1080 resolution.

[Saffith]

The next size up would be 1600x1200, so it wouldn't fit on the screen at that resolution.
I don't think it can reasonably be added any time soon. It's not as bad as I would have thought, but it completely breaks mouse input, at least. I'll see what I can do, though.

Edit: Actually, that was really easy to fix. I'll have to test a bit and make sure nothing broke, but maybe it'll be doable after all.

[Unames]

There seem to be some issues with draw commands during screen transitions:

Blue square drawn before Waitdraw(), red square after. The red square is drawn before the blue square while scrolling, and disappears entirely for one frame. This occurs with other draw commands as well. Script was written to demonstrate this and is as follows:

import "std.zh"
global script slot2
{
	void run()
	{
		while(true)
		{
			Screen->Rectangle(6, 0, 16, 8, 8, 3, 1, 0, 0, 0, true, 128); //blue rectangle
			Waitdraw();
			Screen->Rectangle(6, 0, 8, 8, 0, 5, 1, 0, 0, 0, true, 128); //red rectangle
			Waitframe();
		}
	}
}

While this is not particularly noticeable with small draw commands such as these, something such as a full screen fill (e.g. a dark room script) will be much more noticeable.

 

Edit: After testing with a transparent red rectangle, I have also found that the second rectangle is drawn twice on the frame the scrolling ends.

 

My theory about what seems to be happening with this glitch is that instead of the commands running:

 

Frame1 code before waitdraw

Frame1 movement

Frame1 code after waitdraw

Draw Frame1

Frame2 code before waitdraw

Frame2 movement

Frame2 code after waitdraw

Draw Frame2

etc.

 

It instead runs:

 

Frame1 code before waitdraw

Frame1 movement

Draw Frame1

Frame2 code before waitdraw

Frame1 code after waitdraw

Frame2 movement

Draw Frame2

Frame2 code after waitdraw

etc.

 

Resulting in a missed draw command in the first frame and a double draw command in the last.

 

Edit #2

 

My theory for why this could happen is that the command that causes Waitdraw(); to return so the code after it is run is on the end of the link or enemy movement functions in the game code, which would not run while the screen was scrolling.

 

Edited by Unames, 11 June 2015 - 12:33 PM.

[Moosh]

This is similar to another bug I found, so it may be a somewhat known issue, but I got talking with ZoriaRPG about ZC's water mechanics and figured I'd bring it up again.

 

https://www.youtube....h?v=zp7suZxOR7Q

 

Walkable water combos allow for some rather strange sequence breaking with screen transitions. Yes Link has a lot of room to move about if he enters the screen on a water combo, the roc's feather is hilariously broken with this, but I think the real problem here is how you trigger it to begin with. It appears for one frame as the screen starts to scroll, Link is able to move and the game doesn't check what combo is under him. This allows for scrolling onto a water or scripted pit combo and either infinite falling adventure or screen transition riding adventure.

[Timelord]

There seem to be some issues with draw commands during screen transitions:

Blue square drawn before Waitdraw(), red square after. The red square is drawn before the blue square while scrolling, and disappears entirely for one frame. This occurs with other draw commands as well. Script was written to demonstrate this and is as follows:

import "std.zh"
global script slot2
{
	void run()
	{
		while(true)
		{
			Screen->Rectangle(6, 0, 16, 8, 8, 3, 1, 0, 0, 0, true, 128); //blue rectangle
			Waitdraw();
			Screen->Rectangle(6, 0, 8, 8, 0, 5, 1, 0, 0, 0, true, 128); //red rectangle
			Waitframe();
		}
	}
}

While this is not particularly noticeable with small draw commands such as these, something such as a full screen fill (e.g. a dark room script) will be much more noticeable.

 

Edit: After testing with a transparent red rectangle, I have also found that the second rectangle is drawn twice on the frame the scrolling ends.

 

My theory about what seems to be happening with this glitch is that instead of the commands running:

 

Frame1 code before waitdraw

Frame1 movement

Frame1 code after waitdraw

Draw Frame1

Frame2 code before waitdraw

Frame2 movement

Frame2 code after waitdraw

Draw Frame2

etc.

 

It instead runs:

 

Frame1 code before waitdraw

Frame1 movement

Draw Frame1

Frame2 code before waitdraw

Frame1 code after waitdraw

Frame2 movement

Draw Frame2

Frame2 code after waitdraw

etc.

 

Resulting in a missed draw command in the first frame and a double draw command in the last.

 

Edit #2

 

My theory for why this could happen is that the command that causes Waitdraw(); to return so the code after it is run is on the end of the link or enemy movement functions in the game code, which would not run while the screen was scrolling.

 

 

Wouldn't the code positioned between Waitdraw() and Waitframe() execute drawing at the start of the next frame, by design?Drawing can;t happen, after Waitdraw, so it needs to wait for the next Waitdraw(), to happen... Isn't the right? It doesn't seem to be a bug, as part of the purpose of placing things after Waitdraw() like this, is specifically to delay them (in my experience).

 

Anything after Waitdraw() occurs after screen drawing in any event: This is normal behaviour.

Edited by ZoriaRPG, 20 June 2015 - 02:57 PM.

[Demonlink]

Quick question: How do you actually use GB chiptune (.gbs) files? I want to select one specific track, but the menu that actually lets you do that doesn't appear as in .nsf files:

 

Image

 

Or do I need to select individual tracks?

[accela2me]

I don't know if this has been solved, but if Link has the shield and the spin attack item and walk up while the sword button is pressed, the shield changes side every step you take.