118 replies to this topic

[Saffith]

No, it was deliberately disabled, and before the switch to CMake. I don't see anything explaining why they did it, though.
It looks like all they did was remove the files from the list and forcibly define a couple of constants, so maybe that's all that would need undone.

[Gleeok]

It looked to me like they did it while switching to CMAKE and trying to make everything work. The allegro team is notorious for not running windows so my guess is they just don't care.

[DarkDragon]

I knew a guy that refused to use any web browser. Pine was "good enough" for him and so was Lynx and wget. I wasn't ever able to get him to articulate any rational reason he refused to use Chrome, FIrefox, or anything else. He was just set in his ways and distrustful of anything "new" (15+ years old).

 

Yeah... you kinda sound like that guy "Your website doesn't look right on Firefox! Nya nya nya, I told you Firefox sucks. I bet you could read the raw HTML just fine if you used Lynx."

 

CMake has its problems and a solid case can be made for using a different build system such as SCons. There are very few reasons a modern, cross-platform software project would use Autotools these days and no rational reason at all for using every-dev-for himself handcrafted Makefiles with no build system at all. Madness.

 

I think I've posted it before, but this rant while entertaining also makes a lot of good points. Also this thread has a good explanation of the advantages of using CMake vs using nothing.

No, it was deliberately disabled, and before the switch to CMake. I don't see anything explaining why they did it, though.
It looks like all they did was remove the files from the list and forcibly define a couple of constants, so maybe that's all that would need undone.

 

I guess my question is, does it matter? It was probably removed because it isn't cross-platform (perhaps even onto newer versions of Windows) and if it's causing framerates to drop from 60 to 30, that's a much more serious issue than if users are noticing a "drop" from 900 to 600, say.

Edited by DarkDragon, 13 July 2017 - 10:08 PM.

[Anthus]

This is totally off-topic, and pointless, but I love reading your guy's banter. It's just entertaining to hear about the inner-workings of ZC, and the platform it is based on.

[DarkDragon]

2. http://prntscr.com/fvahaw I am not sure problem with 2.53 or quest itself.   There is bug on this.   After I kill all enemies and got key, I don't want go around on third floor.  So I went back to black hole, but somehow, I am standing on hole that shouldn't do that.   So I use leaf to fly over and see what happen to land on hole, it disappear.  I though it froze, but it not.  I use leaf to show you where you are at.  There is way back to normal.   You need fall down to hole.   But not texture hole make you fall down to second floor.   Even I went outside, it still disappear.   I went back inside. Still disappear until I fall down hole, it back to normal.   But I have to go third floor to get boss key.  

 

3. http://prntscr.com/fvanoy  Is this normal way even you get staff, it still effect to talk rock block?

 

2 & 3

 

As best as I can tell these sound like bugs in the .qst, and not in ZC? Unless there is behavior that is different in the quest than how it used to work in 2.50.2.

[Gleeok]

My argument is that overly complicated build systems for trivial tasks (i.e., compiling a single library) are stupid, period, not that one is better than the other. There was probably a long road of questionable design decisions that lead to the idea that a universal build system could be a panacea for the ever growing compiler flags and platform specific configurations. Maybe this 'works', although you can make a case that monocultures and round-up 'works' in the real world - everyone might jump on that bandwagon except for a few. Some of those few might be completely crazy, but maybe some of them have some understanding and can do it better.


Also,
https://github.com/l...fc754101342b8ef

It looks like they switched to include a gen_asmdefs.inc file here instead... which is generated?

[DarkDragon]

It looks like they switched to include a gen_asmdefs.inc file here instead... which is generated?

 

It looks like you linked to the Allegro 5 repository? Trawling through the old Allegro 4 repository on SourceForce is painful, but it looks like this is the commit that removed support for assembly. No explanation is given: https://sourceforge....code/9746/tree/

 

I couldn't find any in-depth discussion on the Allegro forums either, though apparently it was removed because "The assembler stuff has not been maintained in so long ... and can be broken occasionally" and "the C code is faster" (not true I guess?). In any case I'm not thrilled about trying to turn on unsupported platform-specific ASM routines unless there is evidence that the performance difference actually matters when playing ZC (i.e., the framerate drops from above 60 to below 60 on a non-paleolithic machine).

 

Maybe this 'works', although you can make a case that monocultures and round-up 'works' in the real world - everyone might jump on that bandwagon except for a few. Some of those few might be completely crazy, but maybe some of them have some understanding and can do it better.

 

I'm not sure what monocultures have to do with programming. There is no Monsanto behind CMake profiting each time an open-source projects buys CMake seeds. Projects are switching in droves because it's the best solution so far to the cross-platform portability problem. Raw Makefiles make sense when you only care about compiling the code on one specific machine (i.e., you are working on a one-man one-platform private project) and don't mind making it as as hard as possible for other people to build the code.

[Gleeok]

Well shit. I'm officially done with allegro I think. Have fun guys.

The link I posted on github was from the 4.4 branch - I had forgotten the original allegro4 repo moved to sourceforge before github >_> - which wasn't old enough I guess. You can see why I thought it was changed then and not earlier... Anyway, possibilities:

-if the asm still works then just enable it, or,
-modify the build settings to every possible optimization and try to vectorize the color conversion routines.
-screw it.

I'm not sure what monocultures have to do with programming. There is no Monsanto behind CMake profiting each time an open-source projects buys CMake seeds. Projects are switching in droves because it's the best solution so far to the cross-platform portability problem. Raw Makefiles make sense when you only care about compiling the code on one specific machine (i.e., you are working on a one-man one-platform private project) and don't mind making it as as hard as possible for other people to build the code.

You missed the point. The way of thinking about it is systemic. This is like the industrial age of computing. 50 years from now people will look back at these shitty tools and languages and wonder why we just didn't fix the /actual/ problems instead of Frankenstein-ing everything together. cmake will not exist 50 years from now because it's fundamentally a band-aid.

Like I said; I don't really have a problem with cmake per se, it's just that every single library that I've tried to compile in the past that used cmake, besides one, has failed miserably. Yes, even well kept and maintained libraries such as Box2D for example; and when it doesn't work then it actually makes it harder to figure out what the problem is. 'make' is simply outdated.

[Timelord]

I knew a guy that refused to use any web browser. Pine was "good enough" for him and so was Lynx and wget. I wasn't ever able to get him to articulate any rational reason he refused to use Chrome, FIrefox, or anything else. He was just set in his ways and distrustful of anything "new" (15+ years old).
 
Yeah... you kinda sound like that guy "Your website doesn't look right on Firefox! Nya nya nya, I told you Firefox sucks. I bet you could read the raw HTML just fine if you used Lynx."
 
CMake has its problems and a solid case can be made for using a different build system such as SCons. There are very few reasons a modern, cross-platform software project would use Autotools these days and no rational reason at all for using every-dev-for himself handcrafted Makefiles with no build system at all. Madness.
 
I think I've posted it before, but this rant while entertaining also makes a lot of good points. Also this thread has a good explanation of the advantages of using CMake vs using nothing.

 
I guess my question is, does it matter? It was probably removed because it isn't cross-platform (perhaps even onto newer versions of Windows) and if it's causing framerates to drop from 60 to 30, that's a much more serious issue than if users are noticing a "drop" from 900 to 600, say.

 

(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.

[Nightmare]

(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.

I know that this might suck for some people, but most gaming companies and people have a multi-core 4 GB of RAM computer these days and can afford it.

I see the poorsest kids running games on cell phones these days, and most have 4 GB
or more of RAM the past 2 yeats.

-James

[TheLegend_njf]

When this beta is completed, will this be the final version of Zelda Classic? Assuming that Zelda Classic 3.0 is probably discontinued. 

[Timelord]

When this beta is completed, will this be the final version of Zelda Classic? Assuming that Zelda Classic 3.0 is probably discontinued. 

 

No. Go back and read the thread.

 

We have not yet reached discussion on '3.0'. That is so far in the future, that I need to retune my crystal ball just to theorise on the subject.

 

The general plan is 2.53, possibly 2.54 and/or 2.55, and then 2.60, which is the current master branch on GH. All version IDs are raw speculation. We could just as easily call them ZC 3.0, ZC 4.0, and 5.0. The smaller numbers make more sense, as they reflect the amount of change; but with as many changes as we have going into 2.60 at this sage, it might well become 3.0 by the end.

Edited by ZoriaRPG, 14 July 2017 - 02:51 PM.

[TheLegend_njf]

No. Go back and read the thread.

 

We have not yet reached discussion on '3.0'. That is so far in the future, that I need to retune my crystal ball just to theorise on the subject.

 

Never had time to read the full discussion yet, but I will later tonight.

[Timelord]

Never had time to read the full discussion yet, but I will later tonight.

 

I figured that.

 

The bottom line, is that ZC is not going away any time soon. We have more developers actively working on it than we have had in almost a decade, and we are part-way into a refactoring that we are at present, calling 2.60 as it is a logical reference for us. I wanted to have a real update out by now, but delays happen.

 

I want to see 2.53 done by August or September, and 2.54/2.55 out some time around the new year, introducing new scripting features and some minor new ZQuest features. All major features are being held back for 2.60, because they require stuff that has been so dramatically changed, that the amount of work to make those new features work in the 2.50.x codebase is monumentally huge.

 

2.54/2.55 will have the full new itemdata set of instructions, new drawing commands, new lweapon and eweapon stuff, some enemy stuff and so forth, in ZScript. The Enemy Editor and Weapon Editor stuff is purely for 2.60+, because introducing it into 2.54 would lock it in a way that may make a headache for us later.

 

All of this is for canonical ZC. I still plan to work on some stuff for my own fork that will never be in the main branch, because ti does things that the other members of the team do not want to include.

[Timelord]

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.

Edited by ZoriaRPG, 14 July 2017 - 04:52 PM.