181 replies to this topic

[LinktheMaster]

Any information about the problem Nick talked about? I had to break apart another FFC script because of it.

[LinktheMaster]

I have some bugs that I've been meaning to post for a while.

• FastCombo does not preserve flips set for the combo in ZQuest.
• When playing older quests, swimming onto land doesn't work properly in all directions. I had problems swimming up in Power of Geduina.
• The Favorite Combos thing in the bottom right doesn't actually save the combos. It's an amazing idea, but... it just... doesn't work. I would love to use it, though.
• Switching to relational drawing doesn't work until I select relational drawing and go off the screen and back to it. Otherwise it just draws a 3x3 chunk of the combo I have selected.

Also, could we please get screen location markers for when we're placing warps?

[blue_knight]

I have some bugs that I've been meaning to post for a while.

• FastCombo does not preserve flips set for the combo in ZQuest.
• When playing older quests, swimming onto land doesn't work properly in all directions. I had problems swimming up in Power of Geduina.
• The Favorite Combos thing in the bottom right doesn't actually save the combos. It's an amazing idea, but... it just... doesn't work. I would love to use it, though.
• Switching to relational drawing doesn't work until I select relational drawing and go off the screen and back to it. Otherwise it just draws a 3x3 chunk of the combo I have selected.

Also, could we please get screen location markers for when we're placing warps?

I've been meaning to mention the first item in your list but I kept forgetting. Thank you.

[Saffith]

It would really be nice to know if there is anything else we might potentially encounter. What is the actual limit to stuff that can be put into an ffc script before it just gives up? Is there a maximum amount of scripting that can go into a quest besides the number of script slots? Does the global script have a limit? Does the pool that I assume holds things such as global variables have a limit?

Not too familiar with the relevant code, but it looks like you can have 65536 ZASM instructions per script, 256 global variables, 4096 arrays at once, and 1000 drawing commands per frame.
The instruction limit might be easy to increase; the only limiting factor I see is the program counter. I'll try upping it to 32 bits and see what happens.

[Kite]

Not too familiar with the relevant code, but it looks like you can have 65536 ZASM instructions per script, 256 global variables, 4096 arrays at once, and 1000 drawing commands per frame.
The instruction limit might be easy to increase; the only limiting factor I see is the program counter. I'll try upping it to 32 bits and see what happens.

Thank you. This is the exact information we needed to know.

We would love it if more instructions were allowed, but we would understand if that's not possible. Knowing the instruction limit and the total amount of global variables alone are enough to make it possible for us to work around it since we have some tangible limits now.

[SpacemanDan]

I assume it'll spit an error at you if you have too many global variables/arrays/whatever else? I'm a little worried I may hit the cap for global variables if I'm not careful. @_@

Also, I may sound stupid asking this one but I want to be sure but do constants count as global variables or do they have their own limit?

[LinktheMaster]

Constants don't apply. I was worried about that too, but std.zh has more than 256 constants.

[SpacemanDan]

...Ha. Didn't think of that one. Thanks for that. Is there a limit to the number of constants though? I'm not as worried about those as I don't use too many but it'd still be handy information to have.

[Saffith]

No limit on constants that I can find.
If you go past 256 global variables, the script will fail to compile, but I don't think it'll detect any of the other limits.

[blue_knight]

So I have an RC2.5 question for you guys. Is it possible for the bitmap data to persist across multiple frames? Basically is there anyway I render some stuff into a bitmap and then reuse that bitmap until I need to update it?

[Gleeok]

FastCombo does not preserve flips set for the combo in ZQuest.

Should be fixed now.

So I have an RC2.5 question for you guys. Is it possible for the bitmap data to persist across multiple frames? Basically is there anyway I render some stuff into a bitmap and then reuse that bitmap until I need to update it?

Yep. That's the point.
The data of any created off-screen bitmaps is never cleared, so you can cache multiple drawing calls into a single call (or more). In fact, there is no way to clear a bitmap of what you already drew on it directly so you have to set it as the current render target and then use Screen->Rect() to clear it to color (erase it). Right now the size is set to 320x240 (ZCs resolution) , though there's no reason why it can't be increased to something larger - the memory required is not very substantial at all. (If anyone wants to request a larger size that is.)

Should be useful for parallax layer stuff I'd imagine.



If anyone had problems with 2.5 crashing from before there is an easy fix - Set win32_proc = 0 in the config file. ..I had totally forgot about this. ..heh.

[LinktheMaster]

Hmm... would bitmap drawing be a way to get around the 1000 draws per frame limit? Also, would drawing to a bitmap, then drawing that bitmap to the screen be faster than drawing directly to the screen?

Also, I remembered another bug. From my understanding, drawing to layer 7 is supposed to draw over everything, right? I was thinking at one point this was allowed. But it no longer seems to work.

Another bug I've found is that apparently setting ST_TEMPNORETURN to true doesn't seem to trigger the timer to disable ST_TEMPNORETURN after going to several other rooms.

[blue_knight]

That's weird, I swear that I had to render to bitmap 0 every frame. I'll check it again, maybe I just did something silly.

Edit: I found the problem, I was drawing to the buffer on the first frame and then using it. In reality I have to wait a couple of frames first. So that is pretty awesome.

Edited by blue_knight, 21 January 2012 - 02:19 PM.

[Gleeok]

There could be a hitch with the flip argument. Right now flip 0 draws the combo with the default flip. However, flip 1 draws the combos current TILE horizontally flipped. ..so depending on what the combos set to in Zquest, flip = 0 and flip = 1 might be the exact same thing.. hmm.. Anybody want to come up with a method where this works as one would expect. ie; What is the expected behavior of this?

That's weird, I swear that I had to render to bitmap 0 every frame. I'll check it again, maybe I just did something silly.

Edit: I found the problem, I was drawing to the buffer on the first frame and then using it. In reality I have to wait a couple of frames first. So that is pretty awesome.

You can use it in the same frame. Keep in mind that drawing is deferred to preserve ordering of layers. This was unavoidable with the way zc draws the screen. Also, setting the drawing target is a global state, and is active immediately after it is called - and persistent across screens. Example:

CODE

Screen->SetRenderTarget(RT_BITMAP0)
Screen->DrawCombo(layer0);
Screen->DrawTile(layer4);
Screen->SetRenderTarget(RT_SCREEN)
Screen->DrawBitmap(layer2); // Here the combo is drawn to the bitmap but the tile is not until the next frame
Screen->DrawBitmap(layer6); // Here both have been drawn correctly

Usually what you want to do is simply draw to bitmaps at layer 0 unless you can spare a Waitframe();

[Saffith]

Also, I remembered another bug. From my understanding, drawing to layer 7 is supposed to draw over everything, right? I was thinking at one point this was allowed. But it no longer seems to work.

It only works if the "subscreen appears above sprites" rule is enabled. Otherwise, layer 7 drawing is ignored.
I have no idea if there's a good reason for that.