100 replies to this topic

[Timelord]

True, however, you don;t need the combined class for subscreens, either. It;s just a convenience, as you can always assign the direct item class, for Letters, Potions, bows, and Arrows, as individual objects; either as a selection item, or as a non-selection (-1) object. The combination classes merely don't work in the Item Editor, although I suspect that the slots they occupy are still blocked out.

My guess, is that the item editor merely doesn;t show either of these now, which could be bad if someone intentionally designed items that use these classes, instead of zXXX, or Custom Class items. I doubt that would be a common problem, but it could exist; in which case, it ma be better to rename the classes, instead of making them invisible (Subscreen: bows, and Subscreen: Potions).

In fact, if they were originally named as such, I think there would never have been confusion on the matter. If not for the need to replicate the letters behaviour from the original game, and to support games that use them, I'd rather see them entirely tosses, to free up two more custom item classes; however, too many games need them for legacy support for that to happen.

A combined class simulates the original behaviour in 'Zelda no Densetsu', where for example, the letter would become the selected item, when you used all potions. You can separate a letter class item into an individual item, or make it a passive item, etc..

I don't use either combined classes in LoE, as I utilise multiple levels of most inventory items, that are simultaneously available, but if I was making a simpler game, they improve subscreen design; and you do need the letter class if you have locked out potion ladies, without scripting.

With scripting, you can use any game object to unlock item sales,so having multiple Letter levels, can be quite useful, and using the Letters class on the subscreen to display them, with, or without without needing to manually use them, would not use the combined class.

The 'Bows & Arrows' class though, is never needed, for anything, as you can position the bow as a -1 subscreen object, and use the arrows to select the weapon. I believe that the only thing that the combined class does here, is to show both items in the button selection frame on a passive subscreen; if even that much. You can never use a bow, without arrows, and placing a 'Bows' class item on an active subscreen is purely decorative:

The [ singular ] 'Bows' class is particularly problematic, on subscreens, as using a 'Bow' item does nothing. I still consider this to be a bug of sorts, as the 'Arrows' class is what generates an LWeapon, rather than the weapon directly.

I think it'd be nice if the bows class fired the current arrow type, as this would make the different bow types easier to implement simultaneously (longbow and shortbow, selected by the user). That may make for a good future quest rule, as it would change too much behaviour to be standard (by needing a current arrow defined, and tied to a game variable that you can write into with ZScript).

As-is, it's not possible to have both the longbow, and shortbow in inventory, without scripting (and dummy items).

@ Saffith: Regarding performance, how would you advise debugging this from the user-end? Is there a good monitor tool that you suggest (for XP), that ties into Allegro 4?

[Saffith]

I don't think there's much you can do other than try to identify things happening in the game that correspond to a drop in the frame rate.

[Evan20000]

A bit, but I'm surprised it would have a noticeable impact. The way they interact with the spawning of other enemies is kind of weird. Is it only obvious in rooms where other enemies have already died, or anything like that?

Hard to say. I've had it happen going into a room that was otherwise unexplored, so I don't think that's the only cause.

[Gleeok]

I'm not noticing any frame-rate problems on windows. Is there any way this can be narrowed down a bit (ie; layers, scripts, item use, enemies, etc.)? What is the CPU usage between the default 1st quest and whatever area in another quest with any performance problems? vsync enabled?

I'll be happy to look into this. I did some profiling, analysis, and minor optimizations for the 2.50 release, except now I have much better tools to work with.

[Evan20000]

I'm noticing it in custom quests I've been developing and others I tested for others (Hitodama). It's mainly the constant traps. I don't think the line of sight traps produce the issue. The other important thing I've noticed is that a lot of the screens have no scripts running and still have this problem. I've been unable to reproduce this in 1st.qst to this point which I'd assume means the problem is with specific quest rules or some other aspects of these other quests. I'll keep messing around with it if you'd like.

[Saffith]

If you can identify any specific screens, that'd probably be helpful.

[Evan20000]

In Hitodama this room in particular comes to mind. I'll post more as they come up in other things.

EDIT: ZC changing quest icons of existing save files to other ones appears to still be a thing. I wish I had any more information than that, but my experience with this bug has been extremely limited (and up until now just heresay).

[Saffith]

Strange, I'm not seeing any difference at all there, either on Windows or Linux. Nothing special about that room that I can see, either. It's consistently slower there for you? About how much so?

[Evan20000]

I drop to about 46/60 for about half a second after the screen transition. It's not even that bad, but it's noticable.

[Saffith]

Try this: https://www.dropbox....elda-w-1677.zip

I changed the way traps are loaded; it should be faster in this build. The same changes were made to zoras, rocks, and statues.

[DragonDePlatino]

Is anyone else having problems with lag? For me, if there are too many enemies or animated tiles onscreen the game will start lagging. And sometimes, the game will still keep lagging even if I kill all the enemies or move to a screen with less animated stuff. This hasn't been a problem for me in the past so I think it might be the current build. Oh, and I'm experiencing these issues playing Origin and Isle of Rebirth. I haven't tested other .qst files yet.

 

EDIT:

 

Oh, and as I wrote this zelda-w.exe spontaneously crashed on me while minimized and I lost a lot of progress. Maybe it has something to do with the matrix screen? Nothing else was happening.

Edited by DragonDePlatino, 01 September 2014 - 04:32 PM.

[Saffith]

Did it crash, or did it hang? Hanging we've seen before, though I was hoping it was fixed.

[Demonlink]

Is anyone else having problems with lag? For me, if there are too many enemies or animated tiles onscreen the game will start lagging. And sometimes, the game will still keep lagging even if I kill all the enemies or move to a screen with less animated stuff. This hasn't been a problem for me in the past so I think it might be the current build. Oh, and I'm experiencing these issues playing Origin and Isle of Rebirth. I haven't tested other .qst files yet.

 

EDIT:

 

Oh, and as I wrote this zelda-w.exe spontaneously crashed on me while minimized and I lost a lot of progress. Maybe it has something to do with the matrix screen? Nothing else was happening.

Well, I had some lag in IoR, but I think that's due to the huge amount of scripts the quest has. As for Origin, haven't experienced lag on mine. As for the Matrix Screen Saver, a "temporary" problem I resolved to that was disabling it (since I remember for ages that it hanged, but haven't seen that either). 

[Gleeok]

If anyone can find a good example of ZC lagging consistently and reproducibly, either with scripts, zc engine, or whatever, then set the Init-Data to start one screen over, make it so screen traversal is a non-issue (It's important that the recorded sample be minimal), ship the quest and I'll take a look at it with some $10,000 micro$oft profiling tools that I totally acquired legally, honest-to-god, no foolsies, cross my heart, really paid that much for.

[Saffith]

Trying out Origin in the latest build (unoptimized), I do see some pretty significant slowdown in the Death Mountain area - about 450 FPS, compared to 500 elsewhere. Every screen in that area has the entirety of layer 6 filled with animated combos; if I hide layer 6, the framerate rises to normal. I'll see if there's anything I can do about that.

That shouldn't be a new issue, though...

Edit: Oddly, in RCs 2 and 3, I see a significant framerate drop there in the Windows build, but almost nothing on Linux. I don't know why that might be.