Jump to content

Photo

ZC 2.5 RC 2.5 (Windows)


  • Please log in to reply
181 replies to this topic

#31 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 23 December 2011 - 09:19 PM

I got my Windows build setup working again, so I'm gonna try and figure out why it's crashing.
Here's the same build of zelda-w.exe, but built on my system. See if it does any better.

http://www.mediafire...em67remqzoaepog

#32 XMSB

XMSB

    Furry Friends Furever

  • Members
  • Real Name:Joseph Watson
  • Location:San Antonio, Texas

Posted 23 December 2011 - 09:23 PM

Nope! No dice! It still crashes in windowed mode whenever the keyboard or mouse is used, and when you try to exit the program! icon_thumbsdown.gif

BTW, I'm thinking that whatever happened when the build was compiled, might be causing a memory leak of some sort. There have been other crashes in ZC and ZQuest that were caused by memory leaks.

Edited by XMuppetSB, 23 December 2011 - 09:31 PM.


#33 Rambly

Rambly

    Hero of Time

  • Members

Posted 23 December 2011 - 09:30 PM

The last build crashed immediately upon running for me, but Saffith's new one seems to work fine. I had to run it once in fullscreen mode and generate a zc.sav file, though, but that's no huge issue. Actually, I'm thinking that was a fluke (since I can't get it to reoccur even with a completely fresh install)... so.. disregard this line. It works fine for me.

Edited by Rambly, 23 December 2011 - 10:17 PM.


#34 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 23 December 2011 - 09:53 PM

So, maybe better, but not good enough. Try build 1417: http://www.mediafire...kmev4enyoe6g3vo

#35 XMSB

XMSB

    Furry Friends Furever

  • Members
  • Real Name:Joseph Watson
  • Location:San Antonio, Texas

Posted 23 December 2011 - 10:06 PM

The thing is, that build is outdated. So it'll nullify and features added in the newest build. Sorry, but I'm gonna have to stick with playing the latest build in full screen mode, and wait for the window crashes to be fixed. icon_sigh.gif
BTW, in your modified version of RC2.5, I found a little glitch with picking up bomb ammo. Click here for details.

Edited by XMuppetSB, 23 December 2011 - 10:08 PM.


#36 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 23 December 2011 - 10:10 PM

That's what I'm trying to do. If we can find the build where the problem first occurs, it'll be much easier to find the cause. You don't have to use it for more than a few seconds; just try it and see if it crashes the same way.

#37 XMSB

XMSB

    Furry Friends Furever

  • Members
  • Real Name:Joseph Watson
  • Location:San Antonio, Texas

Posted 23 December 2011 - 10:13 PM

Yup, even that outdated build still crashes in windowed mode the same way the latest build does. Could it be the original source of the crash?
(I used a separate folder by the way)

Edited by XMuppetSB, 23 December 2011 - 10:29 PM.


#38 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 23 December 2011 - 10:50 PM

Well, we'll see. Could you try a few more?
http://www.mediafire...029169tqn25sclf
There are four in there. What's the earliest one that crashes, or do they all work?

Sorry, I know it's a bit of a hassle, but there isn't really an easier way to do this. Might be one more set of two or three after this one, depending on which of these work.

#39 XMSB

XMSB

    Furry Friends Furever

  • Members
  • Real Name:Joseph Watson
  • Location:San Antonio, Texas

Posted 23 December 2011 - 11:00 PM

I tried all four of these (1402, 1406, 1410, and 1414), and the only one that crashed was 1414.

#40 Saffith

Saffith

    IPv7 user

  • ZC Developers

Posted 23 December 2011 - 11:24 PM

Excellent. That narrows it down enough to start trying stuff.

Here's a modified RC2.5. Any improvement?
http://www.mediafire...9cksa4gx78e7i4c

#41 XMSB

XMSB

    Furry Friends Furever

  • Members
  • Real Name:Joseph Watson
  • Location:San Antonio, Texas

Posted 23 December 2011 - 11:55 PM

Yes! That RC2.5 mod fixes the windowed mode crashes! Thank you so much! icon_biggrin.gif

#42 Gleeok

Gleeok

    It's dangerous to dough alone, bake this.

  • Members
  • Real Name:Pillsbury
  • Location:Magical Land of Dough

Posted 24 December 2011 - 03:44 AM

Eh, Sorry. I just haven't had any time to look at this stuff lately. icon_frown.gif I'm likely to simply comment out most of the superfluous and unfinished windows specific stuff for RC3 anyway (That's why I wasn't really worried about it too much), and why I wanted this beta out months ago. Everything else seems to be working fine though. I'll commit the final changes for 2.5 as soon as I get some time - Should also fix any crash issues with those builds on some platforms also.

#43 Omega

Omega

    Yes

  • Members

Posted 24 December 2011 - 02:27 PM

Can you guys make it so MP3's don't restart every time you warp to a map using the same MP3? I use mostly MP3's because I don't like the crap quality on most Midis.

#44 Kite

Kite

  • Members

Posted 04 January 2012 - 09:42 AM

To be honest, this post probably won't apply to 95% of the people reading it. Nonetheless, this is something that LinktheMaster and I have to legitimately worry about with a project we have been working on for about 3 years now. I also feel it's going to apply to anyone that does heavy scripting. I'm not talking about adding a few scripts from the site or making a few random weapons. I'm talking about coding entire engines out of scripting, being extremely thorough on cutscenes, and other code intensive concepts.

But I guess I should stop rambling and get to the point.

Last night, LinktheMaster and I had a near panic attack when we ended up encountering a mysterious problem with a cutscene ffc script we have been adding on to over time. It stopped working without any sort of error. Normally, one might think we just screwed up somewhere and code wasn't executing due to our own error... but that's not the case. We found that the problem would fix itself if we deleted random lines of code or took out various functions. We tried this in both RC2 and RC2.5 and got the same result.

We initially freaked out since we thought we had hit the end of the line regarding how much scripting a quest could contain total. We have actually already encountered compiler errors due to having individual functions that were too long and had too many if statements and loops (during that time, ZQuest was putting out memory exhaustion errors caused by a function that was 2,000 lines), so we didn't rule that out. However, we eventually narrowed it down to being a problem with FFCs having too much crap.

Our theory is that the cutscene ffc script we used simply contained too much code when it was converted to ZASM, so ZC's memory simply didn't want to handle it. The actual ffc script isn't that large, but it refers to enormous individual cutscene functions outside of it with various if/else statements that I assume are compiled into the ZASM. It did not help that the particular screen we noticed this cropping up on initially had two instances of the script running due to there being two different cutscenes on the same screen at different points in the quest.

For reference of just how large we are talking, here are some stats generated by cloc (Count Lines of Code) using its C++ interpretation for our overall project as of last night.

Note that this does not include std.zh and strings.zh, which are also in the project.

CODE

http://cloc.sourceforge.net v 1.55  T=1.0 s (11.0 files/s, 17707.0 lines/s)
--------------------------------------------------------------------------------------
File                                               blank        comment           code
--------------------------------------------------------------------------------------
fairy-gb\fairy_cutscenes.zh                         1127           1011           4161
fairy-gb\fairy_enemies.zh                            640            805           2890
fairy-gb\fairy_functions.zh                          328            623           1992
fairy-gb\fairy_ffcscripts.zh                         210            332           1112
fairy-gb\fairy_menus.zh                              112            149            540
fairy-gb\fairy_debug.zh                               26             53            341
fairy-gb\fairy_strings.zh                             49            107            326
fairy-gb\fairy_items.zh                               36             47            202
fairy-gb\fairy_scripts.zh                             37             36            138
fairy-gb\fairy_global.zh                              26             29            129
fairy-gb\fairy_library_ffcscript.zh                   18              8             67
--------------------------------------------------------------------------------------
SUM:                                                2609           3200          11898
--------------------------------------------------------------------------------------

The total number of lines generated by a ZASM dump is 170,810. This number includes std.zh and strings.zh.

As you may notice, fairy_cutscenes.zh is the largest file in the quest. Up until last night, it was also the largest ffc script since every single line was either part of the ffc script or referenced by it. It also referenced tons of crap from fairy_functions.zh and some enemies from fairy_enemies.zh. And then there are items from std.zh and strings.zh.

So yeah. It contained a lot of stuff. icon_confused.gif

We managed to fix this particular problem by splitting the cutscene ffc up and using Saffith's ffcscript library to load them as we needed them. But seeing as this is the second time we've almost had a complete panic meltdown (the first time being the compiler error with the too large function), it is natural that we are bit worried about hitting other limits that might present themselves with scripting.

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?

This is really worrying us since we really don't want 3 years of effort to just die without warning like it has almost done twice within the past month.

#45 Orithan

Orithan

    Studying Scientist - Commission from Silvixen

  • Members
  • Location:Australia

Posted 04 January 2012 - 10:15 PM

One thing I would like to see is that the position of the Gameover text colours become editable via Misc. colours, partly because the Gameover text in EZGBZ 2.0 is all whited-out and we would like to be able to fix it without changing some of the colours in the pallet around.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users