DEV Community: Alexandru Ardelean

I decided to try some game engines on Linux this weekend

Alexandru Ardelean — Tue, 08 Dec 2020 07:13:45 +0000

I always wanted to try a few game engines to see what they're about. I don't know if I'll ever get a chance to become a game-developer; once you specialize into something, it becomes more difficult to escape it. It's both a blessing and a curse; everybody will come to you for your specialty, but they will treat you like a beginner if you even consider starting something else... ¯_(ツ)_/¯

And I do have some Windows machines around the home, but I rarely get to use them anymore.

Let's start with Source SDK

[Edit: 10th May 2021]
I just found out that you can run a lot of Steam tools with their Steam Play support for Linux. It's basically a Windows app being run on Linux via Proton (some Valve variant of Wine).

Since I love the Half-Life game series, I decided to start with their Source SDK engine (made by Valve Software).

If you want to start from scratch with Source SDK, you pretty much just go to their wiki page: https://developer.valvesoftware.com/wiki/Source_SDK_2013

After going through some tutorials, I quickly got the gist of it... and I became a bit bummed. The Source SDK is pretty centric to making Half-Life mods, not necessarily games from scratch; you can make something neat just checkout Golden Eye Source which is a good source of examples.
While the engine is not used only in the FPS genre, it seems to steer you in that direction.

That is Source 1.
And recently they have a Source 2 Engine. So, I thought: where is it? Where can I get it?
Turns out, you need to install DOTA 2, and do some bits.
See: https://www.extremetech.com/extreme/187723-valve-quietly-releases-source-2-engine-source-2-version-of-dota-2-and-new-hammer-map-editor

Oh, and the biggest bummer [for me] is: a lot of editing tools run under Windows (maybe Mac as well). Well, that's for Source 1 tools; maybe Source 2 tools will get a port to Linux or some way to get them on Linux.

Now let's look at Unreal Engine 4

I knew this engine was hyped. And I'm not one to care or be persuaded about hype.

I found this doc page about UE4:
https://docs.unrealengine.com/en-US/SharingAndReleasing/Linux/BeginnerLinuxDeveloper/SettingUpAnUnrealWorkflow/index.html

If you read through it, you probably get hit by an awesome fact [which I wasn't hit by right away]: Unreal Engine 4 gives you their entire source-code for the engine, editor, everything.

You create an account on their page, you login with your Github, and you get added to a private group (of about ~300k people) with access to the UE4 source code.

Now, obviously this still means the engine and source and everything is theirs [i.e. belongs to Epic Games]. But I rarely [if ever] see companies willing to show you their complete internals like this.
Naturally, the reason they did this is to be a bit more competitive with Unity and other game engines, but still... you can start submitting Pull Requests to their engine right away.

If you follow their doc-page for Linux, you will spend about half your day building UE4 on Linux. There are no pre-built installers/stuff. But for me that's great, because I love building stuff from source. And like their page says, you will need at least 100 GB free on your HDD for this.

After that's done, starting UE4 also takes 5 minutes the first time. It compiles all sorts of shaders and initialization stuff, and then you can start using it.

Quick run through Unity

Unity is way easier to install on Linux. You download some binary installer for Linux, run it, download an SDK/editor for Linux, and you can start using it.

Unity runs smoother than UE4; it won't kill your laptop's fan (like UE4).

Some conclusions

I ran through some Youtubes and articles around the web comparing these game engines.

Turns out, there is Godot which is free, open-source and better for 2D games than 3D games. I may try that later; I mean a weekend has 2 days, and I also need to spend some time with my family, not just sit in front of the computer all day.

I haven't tried to build any games yet, with any of these engines.
I just ran some templates (for all 3 engines).

Naturally, the most fun I've had, was with UE4, but only because they don't have an installer for Linux, and I had to build it. Otherwise, it wouldn't have been as fun.

Yeah... that's it

Learning to promote oneself

Alexandru Ardelean — Wed, 25 Nov 2020 09:12:48 +0000

You know when you get to learn new things and sometimes you learn them from interns?

I mentored a few interns during my career (since ~2007) and most of them were pretty standard-scared-little interns.
I don't mean this in a bad way, or to demean anyone; as an intern is how I started, and looking back.... I am now wondering how I was as an intern ¯_(ツ)_/¯ [1]

Anyway, there was this one guy who taught me a few tricks, and looking back he is [at this point in time] the best intern I've had.
Sure, he was hasty [as some interns are], tried to finish things really fast, only to see it fail in a CI build. But I know that I was about the same in this respect.

So, what I learned from him are [in a random order]:

thegit worktree command; this will save you gigabytes of storage if you need to work the Linux kernel; I mean just the .git is ~5 GBs and just grows when adding remotes [2]
he tried to convince me to use tmux... maybe the next intern/person will actually succeed to convince me; there's various overlap between tmux, zsh and maybe something else, and I just didn't bother after a while
better promoting my CV/myself

Ok, so point 3 is what this article is about, because I never really gave this much importance.

So, on this, what I learned from the guy is:

Create a https://github/<user>/aboutme repo and upload your resume (in doc and pdf formats) there
Create a gist with your resume in PDF format and JPEG/GIF as the first file in that gist (you'll see why)
Pin the repos you're most proud of on your https://github/<user> profile page. Make sure to also pin your gist.
Optionally, a markdown can be added to the gist and the aboutme repo. I didn't yet, I might later.

An example of how it looks on my page now is:

Essentially what happens is that the image from the gist (when pinned) screams pretty loud on your profile page, which may be something that someone would want. I don't know... what do I know? :p ¯_(ツ)_/¯

You can also fork these gists, I also forked this one from someone else's and modified it.

Turns out gists are git repos as well. You can clone, modify and push back to Github. Who knew?

[1] Ya' know... that is actually that I will have to reflect upon for the next few hours.
[2]

linux # ➦ eccc87672492 # du -sh .git
5,7G    .git

OpenWrt & Python - a tale from a maintainer (part 2)

Alexandru Ardelean — Tue, 24 Nov 2020 07:47:21 +0000

Because I wrote a part1 here, I wanted to follow up with a part2 (this article).

In the first part, I touched on CPython's size (when packaging), but now I want to mention speed.
And I never considered speed being so critical with Python (especially CPython) but on some embedded it sure makes a difference.

If you've run Python more than a few times, you've noticed those .pyc files it generates. Those are byte-compiled cache files that are loaded into the Python interpreter.
Usually, Python will look if there's a .pyc file and if the timestamp (of that file) is newer than the .py file, it will run that **.pyc.
Otherwise, the file gets re-generated, and then run.

And I never cared about them, but when you're a package maintainer, and you need to save on space on things like OpenWrt (and other embedded things), you'll notice that the Python source file is about the same size as the .pyc file.
Debian (for example) seems to ship both these files.

Initially, I packaged just the source files, because deploying Python source files makes sense for humans. You can see the source and you know exactly what you're getting with CPython and the libraries.

Of course, to prevent people from running out of storage flash on their devices when running Python code, byte-compiled caches have been disabled.
That means, that starting a Python program would involve re-generating those cache files every time you'd run a Python script.

It seems that the generation of those .pyc is expensive.
There was a report saying that a "Hello World" script in Python would take 500 milliseconds to start (on some slow machines).
When compiling it to .pyc and running that, it would take 70 milliseconds.
So definitely an improvement.

Now, what happened was that we switched from shipping Python packages with source (.py) files, to shipping/packaging Python packages with byte-compiled (.pyc) files.
Also, each Python package would get it' own python-xxxx-src version. So users that want the Python sources can choose to install them separately.
It is the best compromise here, to:

keep the Python packages as small as possible
have some speed (well, not make it worse)

For reference, I did find some of the old discussions on Github about some of these.
They have some historical meaning for me.
One is dating from 2014, around when I started: https://github.com/openwrt/packages/issues/474

And one about Debian's reproduce-able builds, which relates to all these .pyc files: https://github.com/openwrt/packages/issues/5278

Maybe it's a good time to re-spin the old reproduce-able builds effort for OpenWrt :)

Something about reviews

Alexandru Ardelean — Wed, 11 Nov 2020 08:54:38 +0000

This one is another tale that I sometimes like to tell around a glass of beer/wine.

But since the COVID-19 lockdown has started, I have this problem right here:

Anyway, I started doing reviews [more properly] around 2014, and it was thanks to a German colleague that I learned how to do it.

He learned this while working for SUSE (OpenSUSE now), and it's him that I have to thank.
In 2014 it was the first job I ever had that actually allowed (and encouraged) me to upstream stuff back into open-source.

Now, I've been working way before 2014, and have done reviews before then, but after that year, I came to the conclusion that the reviews I was doing weren't that great.

A few things I have learned along the way is [and the list isn't complete]:

Open-source communities do the best reviews; not all of them, but a lot of them; the older the project, the tougher the reviews and the reviewers. It's like they have this newcomer-grooming-syndrome, which can be great for some, and disheartening for others. So far the toughest reviews I've seen are on the Linux kernel community, but that's another topic
Still today (and it's 2020), there are plenty of companies and plenty of people not doing proper reviews.
After doing reviews for a while, you will (for sure) offend people, or at least piss them off to the point that they will start dreaming about ways to bury your body so well that nobody can find it.

So, lets take a pause here and break down these 3 a bit, because they are interlinked.

Firstly, I [personally] am not interested in offending people, even though after a few reviews I am no longer 100% sure about this. There's a weird sense [I have] when I get into a conflict, where I start to wonder whether the truth [about what I know is correct], or whether I have been wrong all along [which isn't great after doing a few reviews, because I feel that now I have to go back and correct all my older wrongs].

As objective as I try to be, I feel that when trying to apply open-source-style reviews to someone who hasn't been exposed to them, they start to feel defensive, and when that starts to happen, is when the review is almost over. It's like I have no longer someone to discuss the code with, but someone who is afraid of me [or what I have to say] about the code.
And I understand this behavior... but I don't think I am always capable of not triggering it in some people.

I've noticed this with people who have a few years of experience and no exposure to open-source. For their entire career [up until a point]:

they were given a task
left alone for 1-3-6 months to work on that
they came back with a working code/prototype/whatever which was a few thousands of lines of code
the reviewing process came along
people didn't complain/dissect the code all that much (it's a lot of code, and that takes energy to understand)
this was merged in
repeat steps above

Now, assuming that they would do this for the first time in an open-source project (and as a new-comer), [I would assume] they would get shut down instantly. Because [most] open-source communities don't want their work to be handled quite in this manner. Many want to be able to understand the changes going into the project, so that they can support it.

So, I feel that it's these kind of people that I tend to offend. And, I hope I'm right about this.

And part of the reason is that text-based communication is emotionless.
And most review is done via comments on Github, Gitlab, Bitbucket, etc.
I'm [often] perfectly calm when writing my comments, but they can be interpreted [by the reader] as if I'm furious or pissed at what I'm seeing in front of my eyes.

Obviously, I can improve my phrasing, and I [think I] have [partially at least]. For new people I review, I try to write a context for my question/comment, so that they don't immediately think I'm an a^%^_e [ I may be one, but they don't need to know this right-off-the-bat ].
For people I'm reviewing periodically, one-liners are often sufficient.

But I guess I'll have a beer now

OpenWrt & Python - a tale from a maintainer (part 1)

Alexandru Ardelean — Mon, 09 Nov 2020 09:05:25 +0000

So, this is a sketch article I wrote for a blogger job I applied for. Thing is: I didn't try blogging all that much; no idea why... well I could probably identify a few ideas, but it would be too much work for this.

Anyway, I didn't get the job, nor do I know whether the job actually got filled, or whether it [probably] got lost/forgotten-about within that organization.

And now, the article itself:

So, you've probably heard of OpenWrt... or probably you haven't and now your googling for it.

If you haven't heard of OpenWrt, you should know that it runs Python, and if you have heard of it [or you've googled it], you're probably wondering: "really?".

You may also be one of those people thinking "pfff, of course it runs Python, Python runs everywhere".

Well, the short answer is "no, Python doesn't/can't [really] run everywhere", because, unfortunately it's too big for some systems.

OpenWrt can run on systems that run at about 200-400 Mhz and 32+ MB or RAM and 4-8 MB of flash storage. Admittedly, I haven't tried to validate all this recently; I do have an old router running OpenWrt from 2-4 years ago, and it's within these specs.

Like this one here, which I use on my desk [ TP-Link WR740N v4 ]:
You can read more about these on https://openwrt.org/toh/tp-link/tl-wr740n
This is running OpenWrt now, but it has 4 MB of flash, so CPython won't fit on this.
I used it to connect it to the ISP's WiFi in the living room, so that I have some ethernet cables around.

I'm actually planning to setup the Linksys WRT1200AC, which has 128 MB of flash and 512 MB of RAM (w00h00).
Link: https://openwrt.org/toh/linksys/linksys_wrt1200ac
Python is definitely going to run on this :D

Quite possibly, someone reading this will jump-up quickly and say: "but there's micropython, and you can run Python on slower/smaller systems with it". And I'll say: "yeah, but that's an open debate". MicroPython is a really neat project for such small systems (even for microcontrollers) to run the Python language, but you'll find that a language can be closely tied to the interpreter you're using.

And MicroPython is not CPython [which is the reference for the language], hence the open debate: what is Python? is it the language? is it the interpreter? how much do you correlate the language with the interpreter ?...... and so on; this article won't cover this part.

So then, you're wondering: "why [C]Python on OpenWrt?".
Well, I was also wondering the same thing at some point in time.
Now I don't wonder about this anymore, I just try to be a good maintainer [on OpenWrt].
I've accepted the fact that there are things in life which are difficult to explain, and many of them exist because someone wanted them to exist.
And: people like Python, and want to run it on these systems.

So now the question is more like: "how do you get CPython running on these system?".
Python [2 or 3] is around ~15 MB for the interpreter with all Python standard libraries. And [like I said before] a router has 8 MB of flash storage; you could also consider putting it on 4 MB, but that's an extreme experiment.
Also, let's remember, you still need the OS and some basic shell + commands to fit along side CPython.

Well, the answer is: "you just package what you need from CPython + you compress it to store it on the flash".
Firstly, OpenWrt's filesystems are a bit special: stuff is stored in a compressed format. And the filesystems are pretty flat, they don't offer much information as desktop/server filesystems do.
Even the kernel is compressed. A typical compressed Linux kernel [nowadays] ranges around 2-4 MB.
[ If you're an embedded guy reading this, and already know this stuff already, and are probably bored about this part, you're in luck: I'm also wondering why you are reading this stuff and being bored by it ].

Also, you don't need everything in CPython to run it. Out of 15 MB of interpreter + libraries, you only need 2 - 3.5 MB [depending on version] to actually start it, and be able to do some minor operations with lists, dictionaries, loops, some basic math, etc.
If you compress that, you get ~750 KB - 1.1 MB.

Doing the math a bit: on an 8 MB flash, you get ~5 MB of used flash.
[ I obviously did some rounding here, so don't take these numbers too accurately. The math I did won't cure cancer or anything, so I can squeeze in some number rounding. ]

Now, usually what happens when the system boots up [with 5 MB of stuff on flash], all this gets uncompressed into RAM, and lives in RAM.
As you can probably guess, 32 MB or RAM is a really tight limit to fit an OS (like Linux) and CPython, but you can do it.
But, if you want to run a Python app without many worries, I'd recommend routers with 64+ MB or RAM.
[ At this point, I'm a reminded of my first computer
that had 1.2 GB of HDD, and that seemed a lot compared to older computers that had 3 MB of HDD, and now I sound like I'm old: ¯_(ツ)_/¯ ]

But, size of CPython [or other Python interpreters] is not the only thing that matters here. Speed is also something to consider [in another article, if I get around to write it].