treated as arrays

They're not just "treated as" arrays, they are arrays.

Slader do you mean indexes in general or just that you could apply them to strings in c/++ due to strings being char pointers? If you mean indexes in general you really need to like, look into basic data structures and algorithms. I would not call anyone oblivious to arrays a decent programmer.

Surely the difference in syntax is reasonably important to note as well?

Soldat is also written in (some mish-mash of) Pascal (dialects) - I think Delphi moving over to Lazarus/FreePascal.

The current main developer also has feelings against C++, and I hear you on the compile times... That said, you can design things so that compile times are kept low (separate structure and implementation, for example) while still getting the best performance possible.

Either way, Pascal is one of the choices that I generally wont argue with, since you still get acceptable native code out (if not quite as optimised) and it's generally quite memory efficient, so at the end of the day I feel that one comes down to developer preference.

Every time I've tried to do something serious using Pascal though, I've found myself missing C/++ libraries. I'm not interested in wrapping that stuff myself if I just want to write games

That error is because CMake's missing libraries that were meant to be added at link time, but weren't, and so fail upon runtime linking.
It's happened to people before here, which might have your solution.

Negative, the lines 2 and 3 were swapped in the array, now works fine... trust the stackexchange code my a**... Figured it out when I read the comments on the lines and went: "Wait aminute... one does not make quads in that orientation..."

The copypaste-code demons strike again

That sucks, I'm sure you're seeing doctors and stuff where necessary (hence the diagnosis) and I don't have kids of my own to brag about so nothing to offer other that sympathies and internet hugs. Hope it eases up over time.

Working on Desert tiles wip.... Palm perspective is meh I know it... 

Good to see something new from you!
You're right that the perspective on the trees is a bit skew (too much like it's from the front) - have a look at this reference for measuring (via facet from pixelation)

Kinda janky but gets the point across on how to measure that stuff easily enough.

Seen some really good things done with MMF (FarmerGnome's games come to mind) so definitely have a look if you're not so strong on the programming front (or want to try something different).

We've certainly received hardly any attention just for supporting linux, but we haven't handled marketing as well as some others. Building tech on portable middleware made getting it running under linux and osx _reasonably_ painless (with OSX being the major pain there due to packaging requirements), but there have been numerous times where compiler differences have come back to bite us, and the occasional feature in some libraries which (despite documentation) crashes under several possible configurations of the 'nix systems - which we of course only find out on releasing a patch using those features.

I'd definitely suggest considering the increased testing cost if you're using anything open source - while they tend to be more friendly to linux it's common to find something has become unmaintained right when you need support with something (or at least realise that development isn't as quick as it was when you first picked up the library). There's also more potential breakage with every update for anything cross-platform, since there are inherently more dependencies in there.

Slightly better than if discontinuation happens with something proprietary, since you can technically fix it yourself, but paid solutions have some obligation to provide service as well, where free software is a labour of love, and a little easier to ignore for the developer

(this is getting quite detached from the subject of course)

fwiw until SteamOS is a household thing linux support is still a minor profit stream. Being so surprised about it not being available is kinda misinformed - even though we've supported linux with KAG since pretty early days, the combined revenue from Linux and OSX is still less than 10%. Windows is still where the majority of the money is on desktop, and developing for it first and foremost (or solely) is sane practice imo.

@ellian I saw a thing like that with a dog on twitter. Funny concept

Good man, as I said ask for help if you get stuck, but with this kind of complicated problem there's not going to be a 5-line solution, you're going to have to get your hands dirty.

You'd just need standardised names for your premake configurations (eg win32_debug) and to ensure each had their own object path and target path standardised to those names (then just trigger all your builds); at least for installs where the only thing to be installed is the binary -  for more complicated installs you could have scripts parametised on the configuration name to complete the install, but you'd need some way for those to be cross platform to avoid wasting time rewriting them for each OS.

 If you want to build in parallel, for some build environments you might need to make unique copies of the solution generated (eg I don't think vs likes you opening a solution in 2 places, though maybe you can tell the cli tools you don't care).

fwiw it's normal and expected to set an object directory in premake and not just build your objects in the same directory as source, I don't know anyone that prefers to do that outside of tiny projects with one or two source files

Learn to use them then; algorithm and data structure experience is fundamental as a programmer. If you don't understand fundamental structures like trees and lists then you should brush up on that, not look for a magic solution.

Taking a "simpler" approach often leads you to inefficient, slow, and potentially hard to debug solutions; often because this happens in tandem with a lack of experience. Jump in the deep end, try to wrap your head around it and when you get stuck, ask on forums and irc for a hand (or take a few classes and learn it formally).

Fair enough; I tend not to build libraries from source to multiple locations if I can help it but you're right that it would be more convenient there. Is there any other use case for building to a non-predefined location or would it just be for building local copies of libraries?

But my point is that, as I understand it, that needs doing in the premake scripts themselves. It's one of those little things that make perhaps no difference for executables, but it makes installing a library someone else wrote more complicated.

Do you mean that you need to tell premake that you want the objects generated elsewhere (objdir) and where to put the binaries (targetdir), or what? I don't see how you could get around that without the default option being somewhat telepathic.

If you're just talking about linking against another library, the pattern is the same as I've always encountered it - point it at a file and provide a linker option.

If you're talking about something else, please say so.



Either way CMake has always just seemed bloated and unfriendly to me, almost every time I've crossed paths with it in the context of portability it's cost me half an hour or more of me telling it what to do until it eventually spits out binaries without complaint - especially when it's been used as part of some sub-step of an installation task of some big software "thing".

(it's not like the default is a safe value this time).

Sure, but VS is more or less universally accepted as what you compile applications for on windows. It's as close as you could get to a sane default in that case, though it should probably check if it exists first :^)

Oh, you just set the build directory to do that; we have source in trunk (svn legacy reasons), build stuff goes into build and it builds binaries into bin, with objects generated under build/obj. Works fine.

Your materials always smash it out of the park man, love it!

Not 3d art but I just realised new blender versions finally have an "are you sure you want to quit" dialogue if there are unsaved changes. Wooo/about time.

No idea what you mean by out of source builds

Unless there's some new functionality of vs 2012 solutions you need you'll be able to upgrade the solution on open just fine and get all the c++11 niceness you want.

There's no build option, that's true, but it takes all of a minute to write a script to invoke premake and follow it up with msbuild or make invocations for each platform that you want automatic builds on. We use premake as part of our toolchain on our build server, so it certainly fits into automation pipelines just fine, if not quite as easily as appending --build I think you'd need to provide more info than just build though, as you may have multiple solutions and configurations present.

One great thing if you're working in a team is that you can provide the binaries and required glue scripts for each platform via your repo and noone has to "figure out" how cmake works every time they clone the source again. Helps get new developers up and running quickly too. The binaries are only a hundred kb or so.

You're right that the docs are crap though, haha, and if you need custom build steps you'll need to wait for premake5 or write them into build automation scripts yourself, but for what it does (cross platform solution/makefile generation, nothing else) it's my go-to software.