Zelda Classic 2.50.1
#76
Posted 12 May 2015 - 08:56 PM
#77
Posted 18 May 2015 - 12:22 PM
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.
#78
Posted 23 May 2015 - 01:17 PM
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...)
#79
Posted 31 May 2015 - 03:59 PM
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.
#80
Posted 08 June 2015 - 12:46 PM
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.
- coolgamer012345 likes this
#81
Posted 08 June 2015 - 02:13 PM
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.
#82
Posted 10 June 2015 - 12:58 PM
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.
- Avaro likes this
#83
Posted 18 June 2015 - 02:28 AM
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.
#84
Posted 20 June 2015 - 02:56 PM
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.
#85
Posted 08 July 2015 - 10:34 AM
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:
Or do I need to select individual tracks?
#86
Posted 25 August 2015 - 07:10 PM
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.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users