PDA

View Full Version : I have a dream!



Tamamo
03-25-2016, 08:42 AM
Saffith Gleeok
I have a dream fellow programmers. That we drop this convulted angelscript mess. It's way too funky like that, and it's broken way too many things. We broke shops for crying out loud. Nobody ever does that. :(
I'm sorry to say this, but angelscript needs to be tossed in the trashcan. Which of course means back to square one. 1 step ahead, and 5 steps back. :<

ZoriaRPG
03-25-2016, 09:26 AM
I pretty much anticipated problems like that, and I made it a point months ago to make a stand to continuing the 2.x line, rather than halting its evolution towards 3.x, and blindly forging ahead to v3....Right now, as i understand the plan, we've rolled back (or are in the process of rolling back) to 2.6 flat. The three of us who were working on this, pretty much vocalised our desires, and now we're all on the same page.

May I suggest that you consider working on improving our present scripting language, moving as much as we can to variables, via setters/getters; and making 2.x as good as it can be for the present? The rest of us are on that page right now, and there is no reason that we can't add other scripting languages into ZC later on, using exactly the same basic internal vars and functions.

In fact, some of my parser modifications, and planned additional modifications, are for the strict purpose of allowing various forms of syntax.

I've already started adding things to ZScript that would, ultimately, make it as versatile as AngelScript, and more modernised. We need
people willing to collaborate on that, and there are three to five of us who are already doing that, albeit slowly. The pace will improve, the more that we accomplish, but it'd be nice to be able to delegate tasks to specific individuals, all based on their own personal goals, and expertise.
The basic idea is that any environmental factor can be modified by the scripting interface. I think that, bit by bit, we can accomplish that goal, without major paradigm shifts.

I know that you want ZC to move away from Allegro 4. I can even share that goal---to an extent--but that is an incremental process and we're simply not ready to jump into that at present.

I have also suggested working with the allegro 4 basecode directly, to make our own modified version that fixes some of the present flaws, as a stopgap. Migration to some custom engine really isn't viable right now; and migration to ag5 is a huge pain in the arse; but we do have a plan of sorts that pretty much everyone is on-board with, so perhaps you'll want to be a part.

All that said, you're a talented individual, and there's no reason that you can'twrite up whatever you want on (as a fork), and perhaps we can work with some of it, if you are adamant about your model. Hell, you can always release your own ZC version that is entirely custom, and if people like it, they'll use it.

Tamamo
03-25-2016, 03:15 PM
Either that or we come up with a Plan B for implementing it. Because replacing the most complex thing "enemies" has not been easy. ASUpdate returns false for some reason.
As for your question. I do both.

Tamamo
03-25-2016, 03:25 PM
ZoriaRPG
You might recognize this from weapons.cpp It's the mirror shield reflection code. Except I modified it to work for enemies. Darknuts with Mirror Shields need to become official.


if(special==3) // hit an enemies mirror shield!
{
switch(id)
{
case wRefFireball
{
id = wRefFireball;
ignoreLink=false;
goto reflect;
}
case wRefRock
{
id = wRefRock
ignoreLink=false;
goto reflect;
}
case wBeam
case wRefBeam:
{
id = wRefBeam
ignoreLink=false;
goto reflect;
}
case wMagic:
case wRefMagic:
{
id = wRefMagic
ignoreLink=false;
goto reflect;
}
case wScript1:
case wScript2:
case wScript3:
case wScript4:
case wScript5:
case wScript6:
case wScript7:
case wScript8:
case wScript9:
case wScript10:

ignoreLink=false;
reflect:
ignoreNPCs=true;
if(angular) switch(ReflectDir)
{
case up:
angle += (PI - angle) * 2.0;
break;

case down:
angle = -angle;
break;

case left:
angle += ((-PI/2) - angle) * 2.0;
break;

case right:
angle += ((PI/2) - angle) * 2.0;
break;

default:
angle += PI;
break;
}
else
{
dir ^= 1;
if(dir&2)
flip ^= 1;
else
flip ^= 2;
}

return;
}
}

Ain't I a bastard? Of course that's just the weapons side of things. Got to work on the npc part tomorrow.

Saffith
03-25-2016, 04:26 PM
I have a dream fellow programmers. That we drop this convulted angelscript mess. It's way too funky like that, and it's broken way too many things. We broke shops for crying out loud. Nobody ever does that. :(
What? They're fine. Maybe you're having the same issue Gleeok is, where return values aren't read correctly for some reason. That's a simple implementation issue, though, or maybe some compiler weirdness. It's not something that requires totally reworking everything.
There may well be changes in the plan, but not because of something like that.


May I suggest that you consider working on improving our present scripting language, moving as much as we can to variables, via setters/getters; and making 2.x as good as it can be for the present?
Variables already use setters and getters. Or do you mean binding each variable to C++ functions the way AngelScript does? That would be a fundamental change in how the script engine works. It's a lot of work, and it's not something that can be done gradually.
How much do you think can be changed without breaking a lot of scripts? And if you're willing to do that anyway, why bother with all the extra work?


I've already started adding things to ZScript that would, ultimately, make it as versatile as AngelScript, and more modernised.
What? Where? I haven't seen anything like that. I see that you've been working on allowing question marks in identifiers, which is great if we want to violate our own naming conventions further and never be able to implement the ternary operator. If you've added classes, or debugging capabilities, or even just short-circuiting conditionals, I haven't seen any sign of them.


Migration to some custom engine really isn't viable right now; and migration to ag5 is a huge pain in the arse; but we do have a plan of sorts that pretty much everyone is on-board with, so perhaps you'll want to be a part.
Who's "everyone"? And what subset of "everyone" has any idea what's involved in all of this? I'll give you Grayswandir, at least as far as coding ability, but even he doesn't have much experience working on ZC.

Tamamo
03-25-2016, 06:46 PM
My main issue is the way the enemies are being handled.

Tamamo
03-26-2016, 09:45 AM
Saffith
Do you have a list of unimplemented entities. I know most of the stuff are the npcs and enemies. But what else.

Gleeok
03-26-2016, 07:17 PM
I had a dream that nobody was confused and everybody knew what was going on and on the same page, and then lived happily ever after ...at least until the the alien invasion in 2021 wiped out all the people.

Lelouche Vi Britannia
03-26-2016, 11:45 PM
I for one welcome our alien overlords...

And no, I'm not on the same page either. After reading this thread, I'm still not sure what is going on. I wish I had the programming skills to help you guys out, but admittedly, even if I did I'd probably still be pretty lost...
Tamamo Broke shops? When and how did this happen?!

ZoriaRPG
03-27-2016, 02:41 AM
What? They're fine. Maybe you're having the same issue Gleeok is, where return values aren't read correctly for some reason. That's a simple implementation issue, though, or maybe some compiler weirdness. It's not something that requires totally reworking everything.
There may well be changes in the plan, but not because of something like that.


Variables already use setters and getters. Or do you mean binding each variable to C++ functions the way AngelScript does? That would be a fundamental change in how the script engine works. It's a lot of work, and it's not something that can be done gradually.


(Emphasis, mine).
What I mean, is that I plan to slowly convert the internal functions and variables (including those that are not yet usable, as well as expanding the way the engine works so that most of the present hardcoded values, become variables) into something that the setter/getter functions may read from, and write to, and I believe that I can do it in 'legs'.

I also started some very basic implementation of the npcdata class, but Dimentio wants to handle enemy code, and I shifted that load over to him for the present. If that proves fatal, than I'd end up doing it.

In theory, the npcdata class would be able to read from, and write to any of the npc entries (i.e. enemy editor, and npcs not in that table), to all of their attributes. It should be possible to set up user-defined movement types, and such, as well as user-defined weapons, using this system. I'm likewise planning to complete the itemclass (itemdata) class, and the list of what I have planned is floating on the board, if you want to examine it in detail.



How much do you think can be changed without breaking a lot of scripts? And if you're willing to do that anyway, why bother with all the extra work?


I should be able to add most of what is on the to-do list without breaking 95% to 99.x% of existing scripts. A goal of 100% would be ideal, but I don't particularly believe in a guaranteed outcome for anything. In reality, there's no way to predict this without experimentation.



What? Where? I haven't seen anything like that. I see that you've been working on allowing question marks in identifiers, which is great if we want to violate our own naming conventions further and never be able to implement the ternary operator. If you've added classes, or debugging capabilities, or even just short-circuiting conditionals, I haven't seen any sign of them.


That shouldn't break (adding) a ternary operator (?:). The way that the lexer works, I should be able to add all sorts of exceptions, and inclusions to handle it. In fact, the colon mark isn't included in the IDENTIFIER definition, so it should be pretty easy to add that as an operator symbol and retain it in the IDENTIFIER definition.

I'm having some fun adding * as a symbol to the the IDENTIFIER definition, which I can do, but I fear it would break things due to variations in user syntax. I want to add this at the head of a series of chars as a USERPOINTER, and at the end of a series of chars as an IDENTIFIER.

Ensuring that neither of these conflict with the MULTIPLY token is another barrel of fun.

I'll also have good practise making lexing exceptions like this, for the word-based tokens AND and OR. I'm not sure how those will turn out, and they'll take some debugging and magical trickery to permit.

You probably haven't seen any of the files that I've updated in the past few months. I'm having nothing but headaches updating the fork that I spawned, as when I try to do a GH update, I receive errors now; so I started dumping the files to a private server, and was going to update everything in a batch, as a new fork once I have more of it done.

My present revision of the ffscript.lpp file is r21. What is the latest that you have from me?



Who's "everyone"? And what subset of "everyone" has any idea what's involved in all of this? I'll give you Grayswandir, at least as far as coding ability, but even he doesn't have much experience working on ZC.

Well, aside from you, and Gleeok, those with 'experience working on ZC' have all long-since retired. The list of 'everyone', here, is as follows: Dimentio, Gleeok, Grayswandir, Samer, and ZoriaRPG.

Gleeok proposed this rollback to us, after all; as well as the incremental change process. It is pretty much either this, or the rest of us just fork it, do what we want to do, and release it as 2.x, while you work on 3.x; which was our original plan. We've been discussing all of our plans, and reviewing what we'd need to do, for months.

Granted, we may hit some stumbling points, but we're a pretty stubborn bunch of buggers, and we'll evaluate, and re-evaluate the feasibility of our plans as we progress.

Gleeok
03-27-2016, 03:17 AM
I like the rollback plan. Everyone involved only has to make a few minor concessions. Seems reasonable. (This of course is only if the bicker plan falls through, which, if you aren't paying attention, was 'plan A' :P )

ZoriaRPG: You may just change your mind about working on ZScript when you see the angelscript module do the same things, plus more, with only about 10% or less of the work ZScript would take. I'm also planning on plugging in a JIT compiler at some point in the future, which would allow scripts to be compiled to machine code and run closer to c/c++ speed.

Tamamo
03-27-2016, 09:10 AM
I can't make up my mind Gleeok do I want to toss AS or Keep it. Hmm....

Tamamo
03-27-2016, 09:28 AM
@Zoria RPG
Didn't see your post. You might want to be careful with some of the variables that are not yet usable. the clk, clk2,and clk3 variables in the enemy class for example. Don't touch those. Their type sensitive.

ZoriaRPG
03-27-2016, 04:29 PM
I like the rollback plan. Everyone involved only has to make a few minor concessions. Seems reasonable. (This of course is only if the bicker plan falls through, which, if you aren't paying attention, was 'plan A' :P )



No, just...no. This is entirely different to what you told us. We agreed to the rollback, based on your statements, which were never hypothetical. It's been 18 days since the deadline for any nay-saying, and we have been working under the premise that this was green-lit, as no-one has said anything to denote otherwise, until now. :disgust:

Everything that I stated in the message from 5th/6th March still stands:

-=SPOILER=-

Reiterating this now, and here, because it's only even clearer now that out goals clash. Saffith's responses in this thread only further my belief that what we want to do clashes with what he wants to do, which pretty much means we need to do our own thing.




ZoriaRPG: You may just change your mind about working on ZScript when you see the angelscript module do the same things, plus more, with only about 10% or less of the work ZScript would take. I'm also planning on plugging in a JIT compiler at some point in the future, which would allow scripts to be compiled to machine code and run closer to c/c++ speed.

Never going to happen, I'm afraid. I have far too much time committed to my work to even consider converting it, and I have no interest in doing it anyway. I'd rather just erase all of my work to date, than waste even more time converting it. I wouldn't touch it, even in the future, if it wasn't 100% capable of compiling the existing script library. Plus, I've already devoted enough time and effort into learning, and tinkering with the Flex parser.

I'll end up doing the ZScript changes, as will at least Dimentio, one way or another, just as we've said, repeatedly: If the rollback doesn't happen, please just jump to v3 and be done, so that we can get on with what we want to do without having version number conflicts.

Really, I'm getting tired of the back and forth on deciding what to do with this, to the point that if we can't resolve this very soon, either I'm just going to do my own thing and not care if there are conflicts, or toss the whole thing, along with all of what I've been doing for the last 3.5 years in a rubbish bin and move on with my life. I absolutely do not want to muck with JIT compilers. Been there, done that, never going to do it again.

We've been planning on how we want to expand ZC 2.5x for a long while now, and when the source release that we've been anticipating for so long was a wholly different beast to what we wanted to work on, it came as more of a slap in the face than some huge reward. it's been another two months, and it's still the same circular argument. We want to expand what we have, not convert it. That's all.

Short of that, you pretty much lose all the volunteers that you have at present.

I'll also note that we could already have a 2.53 release done, if everything in the repo wasn't so mangled. The Git repo for a 2.5 trunk should be no more than your last working path of 2.50.2/3 with all the support files, laid out exactly as they are on your system, so that all one need do is download the ZIP, unarchive it, open VS, and Build. Instead, we have to manually meddle with everything, grab external stuff, and then we still run into problems.

Now we're going back and forth between two completely different models, because of LOC?!

Please either work on ZC3, or 2.6. One or the other, pretty please. If you want to force AngelScript, then please just slap a ZC3 label on, it, send us a ZIP file of your 2.5x layout, and we'll make our own 2.5 repo as we planned from the onset. If we have to keep waiting just for a decision on this, then it's not open-source: It's shared closed source.

2.50.2 works, and is proven. It should have been the initial commit. We want to use that as a base, not something wholly new.

Dimentio Grayswandir Samer

Tamamo
03-27-2016, 05:15 PM
And this is what happens when you open source too early. People bicker back and forth. Sigh...
ZoriaRPG
I also agree that 2.5.2 should of been the initial commit. >_>

Dimentio
03-27-2016, 05:25 PM
I'd prefer to keep the 2.X line, and slowly move into 3.X. If we are truly adding Angelscript, I feel it should be a side thing, and not a forced upgrade. Remember back when people kept on using 2.10 and 1.90 because they found later versions buggy? I feel that forcing an upgrade could result in that, but more because of the removal of ZScript. People are attached to it, despite it's flaws.

A JIT compiler? Depends. If it means less lag and no overcomplications, then I'm for it.

Also, I vote that if we do decide to upgrade to Angelscript, that we call it ZScript, because Zelda Classic, ZQuest, ZLaunch, etc. Also, the amusing side effect of the confusion it'll cause. "Wait, so you mean the old timey ZScript, or that darn, new-fangled ZScript these kids be talking about these days?" :P

Tamamo
03-27-2016, 05:57 PM
Dimentio
Making Angelscript optional would be a pain in the ass.
Let me put it this way. The enemies currently are Angelscript Classes and so is Link. Weapons and Items haven't been converted yet.
In otherwords we would need two classes for each entity and that's just trouble waiting to happen

Dimentio
03-27-2016, 06:12 PM
Alright, if that's not possible, then ZScript. I haven't seen enough of Angelscript to eve n know it's going to be better than ZScript, so I'm going with what I know works, and just improve that.

Tamamo
03-27-2016, 08:12 PM
The best way to handle it is to create two branches of 3.x one for zscript and one for angelscript.

Dimentio
03-28-2016, 12:53 AM
That could be a solution... But then we have 2 separate groups working on 2 separate projects,which could either speed up or slow down development.

I'm all for whatever plan is the most efficient.

Gleeok
03-28-2016, 01:20 AM
I see we are going with the bicker plan after all. :/ [disclaimer: I am not a psychic, but I did stay at a Holiday Inn Express last night]

Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it.

ZoriaRPG: If I didn't have good reason to believe ZScript was staying around for a while and we're still 2.5 backwards compatible etc., then I wouldn't even bother updating some script functions.

Tamamo
03-28-2016, 09:11 AM
Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it. .

Then why the hell are we doing it. Thats settle it then. We're going to have to convert the enemies and link back to cpp and implement angelscript Differently if we still which to do that. This should be fun. >_>

ZoriaRPG
03-29-2016, 07:40 AM
I see we are going with the bicker plan after all. :/ [disclaimer: I am not a psychic, but I did stay at a Holiday Inn Express last night]

Part of the prob;em with moving c++ code to angelscript is that it's an extra layer of abstraction to work with. Debugging is harder, changes and bidings take longer, and runtime speed is slower. At the end of the day nobody really wants to deal with any of those aspects of it. That's why all new features happen in alpha stage, because hey, sometimes you don't know you don't like something until you try it.

ZoriaRPG: If I didn't have good reason to believe ZScript was staying around for a while and we're still 2.5 backwards compatible etc., then I wouldn't even bother updating some script functions.

(Emphasis mine.)

That's yet another of my problems, and it toes into my qualms about solving it with a JIT compiler. Suffice to say, that we'd be trading off either performance, or platform-independence in the process. I don't particularly want to do either, but the time itself, that it'd take to go from 3.0 alpha, to something viable, may solve the performance issue, by pushing the 'typical' HW base that runs the programme toward something newer.



Then why the hell are we doing it. Thats settle it then. We're going to have to convert the enemies and link back to cpp and implement angelscript Differently if we still which to do that. This should be fun. >_>

I frankly think that if we follow through on our 2.future plans, it'll become easier to implement an alternative scripting engine, as what we propose will eventually turn everything important, into a variable that can be set by the user. If we can add user-defined enemy movement patterns, and some of the other goodies on our list, it might be a good stopgap between 2.5 and whatever a full rewrite--which, let's admit, is what the AS proposal is--is when completed, if completed.

If you want to do any enemy rewrites as cpp, we'll probably use them one way or another. We absolutely need to add a few attributes to the npc class though, including a flag for 'IsCore()', and some other basic values that are missing at present. I'm thinking of adding IsPointer() to every class object, to return the pointer ID of anything as an int, and of course, the ability to reference any object by its numeric pointer; but now I'm straying off topic.
Dimentio is the member of our group that has interest in cleaning up the enemy code. I was going to work on the 'Talking NPC' ZC class, as requested, and I was thinking of doing some modifications to a few of the other enemy types, but it's really not part of the engine that draws my attention, or interest.

Gleeok
03-29-2016, 08:16 AM
This whole thing is just getting completely ridiculous.

First of all, any JIT compiler would not be setup unless it was running on the appropriate architecture and the user set "use_jit=1" in the config file, or was even compiled into ZC into the first place (Sorry, only x86 or x64 right now). See Also: https://github.com/BlindMindStudios/AngelScript-JIT-Compiler

Secondly, it's not like it's bad to put enemy code in scripts. A shitload of console games are written this way. I remember reading an article by John Carmack years ago about this (google it I guess) where he talked about the pros and cons of it. It's just that as-is it would be a nightmare for people to try and edit built-in enemy types, to say the least.

...That's all I feel like responding to right now.

Dimentio
03-30-2016, 03:57 PM
I agree, this whole thing is getting pretty ridiculous.

I do agree on the JIT compiler. Faster processing? An option to turn it on/off? Yes please!

Tamamo
03-31-2016, 11:27 AM
God damn linker. Seems the zcsound library is being a cockblocker.
If you tell me how to fix this Gleeok I'll see what I can do about those enemies dying, willing to give it another try.
Also appears save and load gif are't defined. I think I know why though. So I'll look into that.



||=== Build: Debug Win32 in zc (compiler: GNU GCC Compiler) ===|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_stop'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 658|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_unload_file'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 702|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_init'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 175|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_exit'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 263|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_load_file'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 300|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_play'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 457|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_change_track'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 796|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_get_tracks'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 767|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_pause'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 573|first defined here|
||Warning: corrupt .drectve at end of def file|
Debug\ZC\src\build_modules\zc_module.o||In function `main':|
C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|21 76|undefined reference to `save_gif'|
C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|21 76|undefined reference to `load_gif'|
..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
||error: ld returned 1 exit status|
||=== Build failed: 23 error(s), 1 warning(s) (0 minute(s), 2 second(s)) ===|

ZoriaRPG
04-01-2016, 01:38 AM
I agree, this whole thing is getting pretty ridiculous.

I do agree on the JIT compiler. Faster processing? An option to turn it on/off? Yes please!


You're forgetting that if we go that route, we'd need to ensure that whatever JITC we use, would be capable of converting to other architectures, like ARM, and to be prepared for needing to rewrite it repeatedly to keep up with changes. It's possible to make these very efficient, but it will never be as efficient as properly pre-compiling for the system architecture (and APIs) that you are using.

This will not increase performance of the current ZC model. In fact, it's guaranteed to be slower than whatever we use now, even with a JIT compiler, unless we did some seriously tedious performance adjustments. If you truly want it to be fast, you need to write your own graphics handler, instead of relying on Allegro, or any of its competitors. They all pretty much sacrifice performance for versatility.

If you want it to be insanely fast, go learn AMD64, or better yet, Power7, assembly. :p

I'm reminded here of that cross-engine game...'Shovel Knight'. Didn't its author rewrite it in 80386 assembly, so that it was capable of running at full speed on an 80836SX-16, or something insane like that?

For all its flaws, the popularity of Java started with the intention of having a 'fast, and efficient' cross-platform engine to run non-compiled code.

In any case, this thing isn't going to work for Android, or iOS, and that's a prime concern for future versions of ZC, especially in terms of system processing power, and efficiency; although I'll be the first to admit that by the time we're ready to address running it on a mobile device, the power of all such devices on the (first-sale) market will have doubled.

It also won't work on OSX, even on Intel architecture, nor so I expect support for that to come from the author. We'd need to provide it ourselves.

Tamamo
04-01-2016, 08:17 AM
You're forgetting that if we go that route, we'd need to ensure that whatever JITC we use, would be capable of converting to other architectures, like ARM, and to be prepared for needing to rewrite it repeatedly to keep up with changes. It's possible to make these very efficient, but it will never be as efficient as properly pre-compiling for the system architecture (and APIs) that you are using.

This will not increase performance of the current ZC model. In fact, it's guaranteed to be slower than whatever we use now, even with a JIT compiler, unless we did some seriously tedious performance adjustments. If you truly want it to be fast, you need to write your own graphics handler, instead of relying on Allegro, or any of its competitors. They all pretty much sacrifice performance for versatility.

If you want it to be insanely fast, go learn AMD64, or better yet, Power7, assembly. :p

I'm reminded here of that cross-engine game...'Shovel Knight'. Didn't its author rewrite it in 80386 assembly, so that it was capable of running at full speed on an 80836SX-16, or something insane like that?

For all its flaws, the popularity of Java started with the intention of having a 'fast, and efficient' cross-platform engine to run non-compiled code.

In any case, this thing isn't going to work for Android, or iOS, and that's a prime concern for future versions of ZC, especially in terms of system processing power, and efficiency; although I'll be the first to admit that by the time we're ready to address running it on a mobile device, the power of all such devices on the (first-sale) market will have doubled.

It also won't work on OSX, even on Intel architecture, nor so I expect support for that to come from the author. We'd need to provide it ourselves.

Wow... could you be any more wrong here. :-/
How did this thread turn out like this.

Have you even compiled ZC, ZoriaRPG? Don't lie to me here because it's missing a file.
So quit your bitchin and let Gleeok and Saffith do there jobs.

Gleeok
04-01-2016, 06:02 PM
God damn linker. Seems the zcsound library is being a cockblocker.
If you tell me how to fix this Gleeok I'll see what I can do about those enemies dying, willing to give it another try.
Also appears save and load gif are't defined. I think I know why though. So I'll look into that.



||=== Build: Debug Win32 in zc (compiler: GNU GCC Compiler) ===|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_stop'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 658|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_unload_file'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 702|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_init'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 175|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_exit'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 263|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_load_file'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 300|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_play'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 457|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_change_track'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 796|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_get_tracks'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 767|first defined here|
..\..\libs\win32dbg\zcsound.lib(zcsoundd.dll)|| multiple definition of `zcmusic_pause'|
Debug\ZC\src\build_modules\zc_subscreen_module.o:C :\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zcmusic.cpp| 573|first defined here|
||Warning: corrupt .drectve at end of def file|
Debug\ZC\src\build_modules\zc_module.o||In function `main':|
C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|21 76|undefined reference to `save_gif'|
C:\Users\BurnsAcer\Downloads\ZeldaClassic-master\projects\code_blocks\..\..\src\zelda.cpp|21 76|undefined reference to `load_gif'|
..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
..\..\libs\mingw\libgme.a(Spc_Emu.o):Spc_Emu.cpp|| undefined reference to `_Unwind_Resume'|
||error: ld returned 1 exit status|
||=== Build failed: 23 error(s), 1 warning(s) (0 minute(s), 2 second(s)) ===|


Did I just screw these up? There should be a define for that, unless you just compile zcmusic.cpp with everything else.

Tamamo
04-02-2016, 05:30 AM
ZCM_DLL_IMPORT is missing from the debug target I should put it back in then?
And yes zc music is being compiled by itself... Why, i have no idea.
I call shenanigans on the repository.