118 replies to this topic

[Gleeok]

(Emphasis, mine)

I have to concur with this. If users have very old HW, they can run 2.50.2 if they cannpt run newer builds. This issue will be the same for 2.55, 2.60 and so forth, as I said before. I do not think that hacking Allegro is a good option, and the ASM mode was probably a major source of bugs. If we change libs for 2.60, who knows what our reqs will be in the end. You can ask on the Allegro boards if you want to know why ASM was disabled. The commit logs have no information, and the changelogs seem to indicate that these changes occurred around the same time as several major bugfixes, so the two are likely related; but only the Allegro devs would know--if they remember ten years later.

They will probably just yell at us for not moving to Allegro 5.

Right now, the major issue, is whether this loss of performance is crippling any extant quest for any of the present userbase. I sincerely doubt that it is.

I do not see a viable way to both correct this performance loss, and to boih maintain maximum compatibility and stability. If we had more staff, we could probably do something about it, but the result would be a hacked allegro version that we need to distribute. If any of you want to try rebuilding Allegro 4.4.3, to see if it makes a difference based on another toolchain, I won't stand in your way.

Likewise, if you want to try compiling the source with a hand-built makefile to try to get a new performance gain, then that is our time to spend. This thread is hardly the place for a CMake debate. We are stuck with that option for the present, and if someone wants to create a new cross-platform compiler base to use that is smarter, cleaner, and not archaic, then fine; but wishing for a better solution does not mean that one exists.

Whoa there. Way to just roll over and die... We're not talking about the entire lib, we're just talking about the color conversion procedure. Think about what you are saying: The cc code runs at the tail end of /every single pixel/ that goes to the screen. This one simple routine accounts for like half of where all the CPU time is spent in ZC. Now that it's not optimized, the time ZC spends on it has about doubled from what I can tell.

Nobody is arguing over cmake for ZC either. [DD did most of the work for it, I gave minimum requirements before I would even run it-we argued: he was like "sigh ok fine whatever"-, and then we all tested it and made sure it's working; I'm fine with it.] We're kind of debating whether it has any real value.

[Timelord]

Whoa there. Way to just roll over and die... We're not talking about the entire lib, we're just talking about the color conversion procedure. Think about what you are saying: The cc code runs at the tail end of /every single pixel/ that goes to the screen. This one simple routine accounts for like half of where all the CPU time is spent in ZC. Now that it's not optimized, the time ZC spends on it has about doubled from what I can tell.

Nobody is arguing over cmake for ZC either. [DD did most of the work for it, I gave minimum requirements before I would even run it-we argued: he was like "sigh ok fine whatever"-, and then we all tested it and made sure it's working; I'm fine with it.] We're kind of debating whether it has any real value.

 

Sure, but given that the entire drawing system was reworked for 4.4, I would expect dropping back to ASM routines for colour conversion would just be a way to (1) reintroduce bugs into Allegro that we can't predict, and (2) force anyone who want to compile this to use a modified Allegro library, that we would be required to distribute and support.

 

It also means that you need to do it in ASM on Linux, and OSX. Who is going to be testing that, and ensuring that it does not break?

 

If you are fine with this, and you want to try hacking the allegro library, I'm not going to stop you, but I am not comfortable with going down that road. A few posts ago, you said that you were done fighting with Allegro.

 

If you are worried about this now, then worry more that jman wants to run purely on OpenGL in the future, using no gfx helpers at all. All hardware rendered.

 

I still have yet to see any real numbers that even heavily scripted quests fall under 60fps for anyone, using this build. That is what we ultimately need to know. Who gives a flidd if the uncapped top speed drops to 500fps if it still runs at 60fps even with tons of drawing and unoptimised script stuff.

 

The flip-side, is that the script instructions that eat up the most CPU cycles usually have to do with array iteration. We can proof this with the 3D rendering quest, or if someone wants to pop out some new graphic intensive quest to use as a baseline.
 

The most wasteful draws are going to be 3D draws, outline draws for stuff like Quad() or Rectangle(), and the worst might be DrawLayer, DrawScreen, DrawCombo, DrawTile, and CopyTile. None of those are optimised in the slightest, and some of them are slated for reworking. DrawScreen/DrawLayer/DrawCombo are amongst these, as they do not factor in the CSet2 value.

Edited by ZoriaRPG, 14 July 2017 - 07:56 PM.

[Avaro]

Some of my projects are getting close to 100 FPS for me, so with this there's a good chance some people will have less than 60 FPS playing some of my quests. It's getting dangerously close is what I'm saying and that's why I at least find the fps drop concerning. (You wanted numbers. Please don't just tell me to improve my scripts, I'm trying my best xD)

[DarkDragon]

A quick point of order: we're *already* distributing a modified version of Allegro, since out-of-the-box allegro has a number of DirectDraw-related bugs on Windows that we had to fix.

 

That said, regarding the performance issue: I compiled Allegro 4.4 on Windows 10 using a Windows 8 version of the DIrectDraw .dll, since DirectDraw was completely removed from the Windows 10 SDKs. I also don't remember what compiler optimization flags I used. Has anyone actually verified that the assembly routines are the cause of the difference in performance (by compiling both versions of the library on identical computers with identical toolchains)? Or is this just speculation?

Here is Zelda Classic v2.53 Beta 2 for Windows.
 
This fixes the corruption of af.cfg in ZQuest, and the MIDI issues in ZC. It also resets std_functions.zh to the one from 2.50.3RC1, plus one function pair, SetLayerComboC() and GetLayerComboC().

 

I updated the download link, and the changelog in the top post of this topic.

 

Is this the latest version from the repository? Or your (non-merged) changes?

 

If the latter, please do not post binaries until after your changes are approved and pulled into the main repository, and you have 100% synched your local copy with the official repository. Dealing with bug reports is difficult enough without having to guess which version of which fork of the code is being discussed.

 

If the former, why are you sending pull requests for changes that are already in the repository, and that undo bugfixes already in the repository?

[FireSeraphim]

I have a couple of bugs to report regarding beta 2

• The quest player in this version fails to detect the joypad part of my IBuffalo replica SNES controller, whereas there was no such detection problem in 2.50.2 (Basically I can configure the face buttons (A,B,X,Y, Start, Select, L and R) just fine but when I go to configure the joypad part it acts like it's not plugged in)
• Zquest refuses to load (the end of the allegro.log files keeps on bitching about "Overlays not supported" regardless of whether or not I'm using DXGL on Zquest)

I hope a beta 3 comes along to fix these damning issues

Edit: Before you ask, I'm running a Windows 7 64-bit PC

Edited by FireSeraphim, 15 July 2017 - 01:39 AM.

[Gleeok]

Has anyone actually verified that the assembly routines are the cause of the difference in performance (by compiling both versions of the library on identical computers with identical toolchains)? Or is this just speculation?

AFAIK I'm the only one that has profiled it and it points to allegro44 from what I'm seeing, specifically the 8-bit color conversion code (although it may turn out to be more than that-not sure). No side-by-side has been done yet, but as soon as I can find the magic DX libs I used to use to build allegro years ago I'll give it a go.

[edit] I added this to my todo list for 2.50.3 which funnily enough only consists of optimizing a couple of things.

[kurt91]

Just downloaded, and it turns out that the file name for ZQuest has a typo, so the launcher won't open it. Changing the file name to what the error message says it needs to be will fix it, so no big deal. Still should probably be fixed, though.

[Nightmare]

Confirmed:  The 1.92 B 182/3 version of James Quest is now 100% functional in its base form.  I think 1.92 183 stuff works picture perfect in 2.53.  Zoria, let me know if you want me to test out quest conversion stuff again with that

 

New Quest 2003 is partially working.  I'll get back to it when the other stuff is properly tested.

 

Next target:  The Revenge 1 and 2 and U3Q, see if 1.90 stuff works properly.

 

-James

Edited by Nightmare, 15 July 2017 - 04:09 AM.

[Timelord]

A quick point of order: we're *already* distributing a modified version of Allegro, since out-of-the-box allegro has a number of DirectDraw-related bugs on Windows that we had to fix.

 

That said, regarding the performance issue: I compiled Allegro 4.4 on Windows 10 using a Windows 8 version of the DIrectDraw .dll, since DirectDraw was completely removed from the Windows 10 SDKs. I also don't remember what compiler optimization flags I used. Has anyone actually verified that the assembly routines are the cause of the difference in performance (by compiling both versions of the library on identical computers with identical toolchains)? Or is this just speculation?

 

Is this the latest version from the repository? Or your (non-merged) changes?

 

If the latter, please do not post binaries until after your changes are approved and pulled into the main repository, and you have 100% synched your local copy with the official repository. Dealing with bug reports is difficult enough without having to guess which version of which fork of the code is being discussed.

 

If the former, why are you sending pull requests for changes that are already in the repository, and that undo bugfixes already in the repository?

 

My 'un-merged change' is redundant and immaterial as it turned out, for you made the same change, on your end without notifying me, which was why the files could not be merged. The only difference is that I put a line comment after packfile_password("") that reads //The is required to prevent corruption of ag.cfg. That is quite literally the only difference, and my 20.x branch in the GH/ZoriaRPG/ZeldaClassic.git -2.50.x path is identical to GH/ArmageddonGames/ZeldaClassic -2.50.x on my end of things.

 

That said, if you want another build, I will start a fresh local repo in a new path for it. I was going to do that for the next stage regardless of what happens here, so that I don't frack up the works. A binary built from the AGN 2.50.x branch should be wholly identical.

 

I do apologize if it seemed as if I was jumping the proverbial gun here, but Beta 1 was rubbish as it could not be used, and the code for Beta 2 is already up.

 

I still have n idea who is going to spend the time needed to rework allegro but we truly should be hosting a mirror of the entire blipping thing, modified to our specs. ( That is mandatory per the license  )

 

I'm horsing around with a dead beet, bt we need scrpt-heavy performance tests of this

[DarkDragon]

But of course; the modified Allegro files are in the repository and instructions for how to build them are in the README.

[Nightmare]

The Revenge - works in 2.50.3, also have a 0-game RTA to show up for it (unfortunately a bug stopped the No Up and A run part)

 

Revenge 2 and U3Q upcoming.

 

-James

[FireSeraphim]

Are you seriously going to disregard the bugs I reported on the #50th post of this thread?

[DarkDragon]

I don't know anything about SNES control pads, but for the ZQuest issue: does it open if you force it to start in Windowed mode?

[FireSeraphim]

Nope, it just flat out fails to launch.

[Timelord]

I have a couple of bugs to report regarding beta 2

• The quest player in this version fails to detect the joypad part of my IBuffalo replica SNES controller, whereas there was no such detection problem in 2.50.2 (Basically I can configure the face buttons (A,B,X,Y, Start, Select, L and R) just fine but when I go to configure the joypad part it acts like it's not plugged in)
• Zquest refuses to load (the end of the allegro.log files keeps on bitching about "Overlays not supported" regardless of whether or not I'm using DXGL on Zquest)

I hope a beta 3 comes along to fix these damning issues

Edit: Before you ask, I'm running a Windows 7 64-bit PC

 

Try deleting ag.cfg, and see if there is some setting in there that might be doing this to you. 

 

Did you have the same issue in Beta 1?

 

I'm also running Win 7 on a 64b system, and those are my ag.cfg settings, so that is utterly bizarre. I have no idea what could cause the issue that you are having with ZQuest. It might represent a problem with your drivers, and gfx hardware, but just about everything should support overlays.

 

I found a very old thread on this, on the allegro.cc forums:

 

https://www.allegro....s/thread/381282

 

I do, however, own iBuffalo controllers, so I'll test them. Please post all of the allegro.log output.

Edited by ZoriaRPG, 16 July 2017 - 04:05 PM.