Questions about code / design decisions

[karvanit]

Doing N iterations is a lot cheaper than N comparisons. But yes I clearly stated that this isn't a huge deal, since the N amount of elements in a savegame yaml map is in the dozens at most.

When we just use node[val] for each of our values we do values searchs, each search is O(nodes). So we do O(N) * O(N) == O(N^2) actions.
When we iterate we do 'nodes' iterations * value comparisons, so still O(N) * O(N) == O(N^2) actions.
So they are exactly the same, but iteration is still the same cost if/when yaml-cpp changes to maps.

Just increasing my post count! 

[Fenyő]

the load/save code might just be rewritten later,

How much later? Approximately.

[SupSuper]

How much later? Approximately.

By 1.0? Whenever the old yaml-cpp API is gone for good? I dunno I'm not exactly looking forward to it either but I wouldn't stress over it, just don't get too attached.

[Fenyő]

If you were about to rewrite, how would you rewrite it?
You mentioned libYAML, maybe we can change to that.
It's C - as you also mentioned - but i think the compilers can handle it.
Besides, github tells me we already have 3% C code.

[SupSuper]

If you were about to rewrite, how would you rewrite it?
You mentioned libYAML, maybe we can change to that.
It's C - as you also mentioned - but i think the compilers can handle it.
Besides, github tells me we already have 3% C code.

The problem isn't that it's C per-se (after all, SDL is C-based). It'll just be a lot uglier since you won't get all the niceties from C++, like STL (vectors etc.), operator overloading, classes, etc. This is why a lot of OpenXcom code is designed to just wrap SDL's ugly C-style calls, making them more OOP-friendly.

Look, I could be speculating and giving advice all day. If you really wanna experiment with it, nothing like getting your hands dirty. Try whatever you want, try the default-values, try different libraries, try different methods, etc. Only then will you actually get to experience what works and what doesn't, and even if it doesn't work out, you'll have learned something from it.

[Warboy1982]

i've messaged a few people about this, but i may as well post it here too.

i'm not sure engine-state-extensions was a good idea, it's introduced far more problems than it's solved (i don't think there WERE problems? if it wasn't broken, why did we fix this?)
a lot of the logic now needs to be processed in reverse order, and it breaks a lot of things.

ufo detection popups, for example, are missing a _pause = true; so when playing at speed = 1 day, when you click center on ufo, it may be on the other side of the planet, or have left it already.
this is an easy fix, but look at research now, it's a mess. it's all in the wrong order, and correcting it would be a major undertaking. i tried reversing the order in which the states are added, and although this fixes the ORDER, i can still see the screens behind it (newPossibleResearch) because it is larger. other things are happening in the wrong order/overlapping eachother as well, for example, at the end of the month, i got a report screen, but there was a terror site detected screen drawn on top of it.

and in the time5Seconds routine, the craft logic needs to happen BEFORE the ufo logic, i'm sure there's a lot more that needs to be re-ordered to accomodate this.

no offense to karvanit, but i think this was a bad pull, i'm sure it's not unfixable, but it seems more effort than necessary when we could simply revert the commit and fix it immediately and with no effort.

unless there's a good reason for the change, in which case, please disregard.

[Fenyő]

The problem isn't that it's C per-se (after all, SDL is C-based). It'll just be a lot uglier since you won't get all the niceties from C++, like STL (vectors etc.), operator overloading, classes, etc. This is why a lot of OpenXcom code is designed to just wrap SDL's ugly C-style calls, making them more OOP-friendly.

Well, we could do the same for libYAML, making 1 or 2 new files which makes libYAML OOP-friendly. That's part of introducing it.

Look, I could be speculating and giving advice all day. If you really wanna experiment with it, nothing like getting your hands dirty. Try whatever you want, try the default-values, try different libraries, try different methods, etc.

Yeah, i just want to avoid solutions which you may reject at the first place. (before making it)
This is a so much major thing about the project, i think.

Only then will you actually get to experience what works and what doesn't, and even if it doesn't work out, you'll have learned something from it.

Well, if something i learned in my time on the university, - which i'm just finishing just like you - is that planning is NEVER enough!
More planning -> less problems later. It's almost every time true.

EDIT:
I have an idea.
Do you remember the DLL-hell / Dependency nightmare?
What would happen if we integrate all the external libraries?
I mean we remove the deps folder, and take all the source files from the external libraries and put them to (eg.) src/ext_libs ? (they would be actually stored on github!)
I think we can avoid the dependecy nightmare, and we always have STATIC linking easily, without the need of any more configuring.
And of course noone needs to get the external libs when starting to coding. If a new version of an ext.lib. comes, then its just updated with a github-commit.

[karvanit]

Re: The engine-state-extension fiasco:  

Re: Pulling in all external libraries:
I am deeply opposed but that may be because working in Linux getting them is easy.

Re: libyaml
It appears to be extremely low level. One would essentially rewrite YAML-cpp if one tries to make it OOP, or at least that's what I can see from the API in the wiki.

[Fenyő]

Re: Pulling in all external libraries:
I am deeply opposed but that may be because working in Linux getting them is easy.

Would anything be harder for you? (after all you wouldn't have to get it at all)

[karvanit]

No, it just bloats the repository. 
The proper (tm) way to do this would be to have seperate repositories for each library and use git submodules. Which are not familiar to many people.

[Fenyő]

No, it just bloats the repository. 

And why is this a problem?

The proper (tm) way to do this would be to have seperate repositories for each library and use git submodules. Which are not familiar to many people.

Maybe, but it's easier to have a new folder with the files in it.

[smerch]

Speaking about linux and yaml.

Is yaml-cpp is better choice than libyaml?

Since libyaml is present in the repository of any decent linux distribution. So building and packaging the game will have less hassle.

[karvanit]

Speaking about linux and yaml.

Is yaml-cpp is better choice than libyaml?

Since libyaml is present in the repository of any decent linux distribution. So building and packaging the game will have less hassle.

In Ubuntu yaml-cpp IS in the distribution, and I think it's also in Debian. Don't know about the others.

But: Looking at libyaml again, it appears it provides a high-enough level that we could wrap it in a few classes and use it. Perhaps it'll be worth it just after we have all the functionality in the game.

Programming rule: Make it compile => Make it run => make it run correctly => make it run fast

[smerch]

In Ubuntu yaml-cpp IS in the distribution, and I think it's also in Debian. Don't know about the others.

Not quite.
In Ubuntu the yaml-cpp package first released '2012-06-08' and it's available ONLY to Quantal and forth. The last LTS Precise Pangolin lacks that package so I have to made one for myself.

In Debian libyaml-cpp0.3 package first released '2012-06-03' for Wheezy.

So (strictly speaking) yaml-cpp library was adopted by Linux distributions a couple of months ago and considered experimental.

IMO it's better to base on technology that distributed and supported better.

[SupSuper]

I have an idea.
Do you remember the DLL-hell / Dependency nightmare?
What would happen if we integrate all the external libraries?
I mean we remove the deps folder, and take all the source files from the external libraries and put them to (eg.) src/ext_libs ? (they would be actually stored on github!)
I think we can avoid the dependecy nightmare, and we always have STATIC linking easily, without the need of any more configuring.
And of course noone needs to get the external libs when starting to coding. If a new version of an ext.lib. comes, then its just updated with a github-commit.

You try that yourself and let me know how it goes. You can never get rid of dependency hell, it's a necessary evil. I've been in a lot of projects with a lot of different approaches to the problem, like pre-built files, custom own tools to automatically get dependencies, hooking them into the repository through externals/submodules, or just not giving a shit. In the end it's always a hassle.

The problem with static linking is it isn't a magic wand, or everyone would do it, you're just shifting the workload to the developers. Now the user doesn't need to worry about DLLs since it's packed into the EXE, but the developer needs to build every dependency themselves, including dependency's dependencies, and dependency's dependencies' dependencies, and... you're kinda undermining the advantage of using someone else's work. Also some libraries have licenses that restricts static/dynamic linking, or actually make use of dynamic linking at runtime (eg. SDL_mixer only loads smpeg if a format needs it).

As for "copying" them to your repository, again you have to maintain and build everything yourself, make sure it stays up to date, pollute your commits with third-party updates, check everything builds in the right order, etc. Also you usually can't just "copy" other people's work into your own, you need to get permission, give credit, check if the licenses are compatible, etc. Another solution is having your repository linked to other repositories (through externals/submodules), so you're always up-to-date, but then you're relying on everyone's bleeding-edge code from their repositories, and we already have enough bugs around here as it is.