next »

[ferreiradaselva]

Got my little SDK up on a repository, cloned it onto the Linux machine, fixed up bash scripts to compile the command line tools, used the command line tools to compile the engine library, and used the tools to generate, build and run a default project linking against the library—just had to fiddle a bit to get everything working. Will add in the SSH compile soon so that I can compile for Linux on that machine from the Mac. e:

Very nice!  What is the build automation tool? CMake?

Premake for everything except Android which uses CMake because it was hell getting even that to work to begin with and I'm not doing it all over again with Premake.

Haha, yeah, premake is a less nightmare-ish than cmake, imo. My wish is that Unix systems make Lua some sort of standard language, but not a total replacement of bash. I still come across some situations where Bash does some tasks easier than Lua, but both are great for their simplicity.

[oahda]

Bash is... weird, yeah. But it's workable with the help of Google.

Building and running over SSH is working! Gonna get cross-compile for Windows on the Linux machine back in there now and then all I've got left is to integrate my Android build stuff with the tools!

[Garthy]

Uh... I think I got semaphores working on the first try.

I was using a set of booleans to manage the synchronization of the threaded main loop (render on the main thread, update on the second), and was working just fine. The problem is that I had to use a 'while' loop to check one of the booleans to wait the an update to finish... and it would use 20-30% of CPU. Not good. Semaphores solved the problem.

Magic.

Congrats.

Also check out condition variables, they solve the exact problem you describe:

http://en.cppreference.com/w/cpp/thread/condition_variable
http://www.boost.org/doc/libs/1_62_0/libs/fiber/doc/html/fiber/synchronization/conditions.html
https://en.wikipedia.org/wiki/Monitor_%28synchronization%29

[InfiniteStateMachine]

premake eh? I've been looking to start using one of the systems that takes you a level away from directly authoring project files and the main problem is there are so many! I'll maybe give it a look.

I was considering Cmake mainly because it has 2017 support. I'm not sure what that means exactly. I would HOPE it means that it functions like KDevelop where the cmake file IS the project file but I suspect that might not be easy to do with Visual studio.

Maybe I should start a topic but does anyone else have any suggestions for a project definition system? Preferably one that's relatively easy to use and at the same time fairly agnostic. I would like to be able to run arbitrary processes at the very least.

[Garthy]

Bash is... weird, yeah. But it's workable with the help of Google.

Have you considered Ruby or Python to handle any heavy lifting that is difficult in bash/sh? Both are included most Linux distributions and have Windows ports.

[JWki]

premake eh? I've been looking to start using one of the systems that takes you a level away from directly authoring project files and the main problem is there are so many! I'll maybe give it a look.

I was considering Cmake mainly because it has 2017 support. I'm not sure what that means exactly. I would HOPE it means that it functions like KDevelop where the cmake file IS the project file but I suspect that might not be easy to do with Visual studio.

Maybe I should start a topic but does anyone else have any suggestions for a project definition system? Preferably one that's relatively easy to use and at the same time fairly agnostic. I would like to be able to run arbitrary processes at the very least.

So, vs 2017 has native cmake support where the cmake file is the project - but seriously, no need to consider cmake, premake is light years ahead in every other regard. It also works well as a building stone for custom build systems. It is a bit biased towards vs however.

[oahda]

Bash is... weird, yeah. But it's workable with the help of Google.

Have you considered Ruby or Python to handle any heavy lifting that is difficult in bash/sh? Both are included most Linux distributions and have Windows ports.

Oh, I don't really use Bash beyond calling other shell commands and reporting back how they went. Most of the stuff is still in my command line tools written in C++. I feel Bash is the best option for what I'm doing with it.

[Garthy]

Bash is... weird, yeah. But it's workable with the help of Google.

Have you considered Ruby or Python to handle any heavy lifting that is difficult in bash/sh? Both are included most Linux distributions and have Windows ports.

Oh, I don't really use Bash beyond calling other shell commands and reporting back how they went. Most of the stuff is still in my command line tools written in C++. I feel Bash is the best option for what I'm doing with it.

It sounded like you might be at the point where you were running up against some of the limitations of the sh family, and that is usually a good time to pick up one of the stronger scripting languages. It sounds like this is not the case in your situation though, so perhaps my suggestion is not yet pertinent. That's cool.

A plus for Ruby and Python versus *sh is that they allow far more practical cross-platform scripting. I believe there have been a few mentions of cross-platform work in your posts? Myself, I use Ruby scripts that run on both Windows and Linux to handle parts of the build process. Some of these were originally Linux-specific *sh scripts, and they couldn't practically be made to work on the Windows side when I tried to port them. Most were rewritten as Ruby scripts. Your situation sounded like it might have been similar to mine, hence the suggestion.

If you do find yourself struggling with it in the future, I'd suggest not spending too much time fighting before experimenting with other scripting languages.

In case you're wondering why I keep mentioning *sh, meaning sh but kind-of meaning bash, well, if you're ever bored:

https://stackoverflow.com/questions/5725296/difference-between-sh-and-bash
https://www.google.com/search?q=sh+vs+bash

Enjoy.

[oahda]

Thanks for the tips. c: I've considered this, but I concluded that at least for now I'm going to be focusing on making the engine/tools just for myself, and I don't work in Windows so I don't need it to work there for now. My tools are set up so that they can be run on Windows too, only they'll just say "operation not available" for now, so there's room for adding it in the future without restructuring everything if I want to. But for now it's nice to just hitch a ride on existing shell programs like ssh instead of interfacing some library.

(this only concerns the tools of course; the actual games are supposed to be very cross-platform which is the whole point of this setup :p)

[Garthy]

Thanks for the tips. c: I've considered this, but I concluded that at least for now I'm going to be focusing on making the engine/tools just for myself, and I don't work in Windows so I don't need it to work there for now. My tools are set up so that they can be run on Windows too, only they'll just say "operation not available" for now, so there's room for adding it in the future without restructuring everything if I want to. But for now it's nice to just hitch a ride on existing shell programs like ssh instead of interfacing some library.

Not a problem, I hope it helps in the future.

I had assumed Windows would be one of the build environments, possibly the primary one. Whoops, bad assumption there. :} I tend to use Linux as my primary build environment for personal projects, so Windows isn't really my primary development environment either. For Windows builds of those projects, I've both built on Windows (MSVC in a VM), and Linux (mingw cross-compiling), depending on the project.

[oahda]

Yeah, I do actually have Windows build on Windows with VS console tools working with Batch scripts in a separate project that I'm copying from into the tools, so it wouldn't be too much work getting it back in there if I really wanted to, but I just don't feel like I need it right now since MinGW works well. So Linux machine for Linux and Windows builds, Mac for everything else (macOS, iOS, Android and web so far).

[Garthy]

I couldn't *quite* figure out what your primary development environment was. My guess after Windows was macOS, which it turned out to be. It also looked like you might have been setting up some sort of Linux build slave environment.

Good to hear that your build environment is working well. No need to change for the sake of change.

[oahda]

And now Windows cross-compile is working too, over SSH as well. \ø/

Kinda a build slave, but it's not some server somewhere, it's just a second laptop right next to me, so I do some of the work on there as well.

[InfiniteStateMachine]

premake eh? I've been looking to start using one of the systems that takes you a level away from directly authoring project files and the main problem is there are so many! I'll maybe give it a look.

I was considering Cmake mainly because it has 2017 support. I'm not sure what that means exactly. I would HOPE it means that it functions like KDevelop where the cmake file IS the project file but I suspect that might not be easy to do with Visual studio.

Maybe I should start a topic but does anyone else have any suggestions for a project definition system? Preferably one that's relatively easy to use and at the same time fairly agnostic. I would like to be able to run arbitrary processes at the very least.

So, vs 2017 has native cmake support where the cmake file is the project - but seriously, no need to consider cmake, premake is light years ahead in every other regard. It also works well as a building stone for custom build systems. It is a bit biased towards vs however.

The mere fact that someone is praising a build system is reason enough for me to give it a look :D

That's pretty cool that visual studio has cmake support at that level though. That means you can now work in kdevelop in linux and visual studio without having to run any process to generate project files.

Thanks for the info on premake. I'm looking forward to giving it a try

[Garthy]

That mention of kdevelop prompted me to check it out to see if it might be suitable for my own work.

Is there anyone here fairly comfortable with kdevelop (particularly on Linux) who might be able to point me in the right direction with a couple of questions? For each of these I haven't yet found a way to solve them and have only found posts suggesting it isn't possible. I'm wondering if someone with more kdevelop experience knows of a way to do it or of an acceptable workaround.

- Can you create a separate independently-movable window and edit text in it? I've tried splitting the existing window as a workaround, but there are problems. I'm on a setup that has three monitors side-by-side, meaning that the menubar and those side-tab things are on the far left of the left monitor, which makes them awkward to access. It also means that I can't place an individual window with one file in it alongside a different tool, since I've only got one gigantic window to work with.

- Can you launch external scripts on selected blocks of text, whose output replaces the selected text, and then attach keyboard shortcuts to launch them? I have a library of scripts that take input from stdin and send the processed results out to stdout that I regularly use to perform operations on blocks of text.

No probs if nobody knows, just thought I'd check.

[JWki]

Happy because I restructured some parts of the foundations of my new project so now all platform independent code can just be reloaded on the fly which is also now a fully automatic process for all modules so that's nifty. Essentially as long as neither the platform layer nor the interface between application code and platform code change, I don't have to quit the program - for changes to initialization code, I have built in app restart.

[oahda]

Sounds cool, JWKi! Excited to get there. I just got Android working with the tools as well with separate make, build and run steps like everything else, so now I'm finally done with every system (until I get a console devkit at least!).

[ferreiradaselva]

@JWki, that sounds really nice. Must have been a ton of work to get there

[JWki]

@JWki, that sounds really nice. Must have been a ton of work to get there

The least straightforward part of it is actually to make sure Visual Studio doesn't prevent you from rebuilding the .dlls at runtime while debugging because it locks the .pbd files - this is a problem only with Visual Studio and the best known workaround is building with /PBD and a random generated name for the file. Luckily, premake makes this pretty easy to do:

Code:

filter{"system:windows"}
    local rand = "$([System.DateTime]::Now.ToString(\"HH_mm_ss_fff\"))"
    linkoptions {"/PDB:\"" .. name .. "_" .. rand .. ".pdb\""}

Besides that it's not too complicated. You have to make sure that all memory is allocated from within the main executable tho if you want to preserve state without extra serialization bs - so no

Code:

 new 

and no global variables, statics, etc in the shared libraries. Not something I consider an issue though, when I need constructors to be called I use placement new (which also requires some workarounds if I don't want to include <new> which I don't because I have exceptions disabled and that'll lead to problems) and I tend to avoid globals anyways.

On a related note, I'm trying out https://github.com/mattconte/tlsf to replace malloc() as my general purpose allocator - primarily because it works within preallocated pools which is something I've wanted from my general purpose allocator for some time now.
It also has nice debugging facilities:

Code:

if (ImGui::Begin("Memory")) {
                    if (ImGui::TreeNode("ImGui")) {
                        tlsf_walk_pool(tlsf_get_pool(g_imgui_allocator),
                            [](void* ptr, size_t size, int used, void* user) -> void {
                            ImGui::Text("Block @ %lli (%lli bytes, used: %i)", (intptr_t)ptr, size, used);
                        }, nullptr);
                        
                        ImGui::TreePop();
                    }
                    if (ImGui::TreeNode("Global")) {
                        tlsf_walk_pool(tlsf_get_pool(g_tlsf_allocator),
                            [](void* ptr, size_t size, int used, void* user) -> void {
                            ImGui::Text("Block @ %lli (%lli bytes, used: %i)", (intptr_t)ptr, size, used);
                        }, nullptr);

                        ImGui::TreePop();
                    }
                } ImGui::End();

[oahda]

I'm there: it just works™.

• build and run on every system ✔
• rebuild the library alongside the project since I'll be working on both in tandem ✔
• build on a remote machine over SSH ✔
• push from local and pull from remote before building remotely ✔

Clean and rebuild both from scratch across all targets like this and see six little coloured SDL windows popping up one after the other without an error!

karhubuild apply --acts clean make build run --preacts pull push --kacts clean make build --kpreacts pull push --sys all