Kartones Blog

Be the change you wanna see in this world

Book Review: Game Engine Black Book: Wolfenstein 3D

Review

Game Engine Black Book: Wolfenstein 3D

Title: Game Engine Black Book: Wolfenstein 3D

Author: Fabien Sanglard

I've been following Fabien's blog for many years, with his excellent videogame source code reviews and in general great articles, so when he announced he was finishing a book about Wolfenstein 3D I got so excited and actually preordered it (on Google Play/Android, read from a 9" tablet).

You can actually grasp the contents of the book not only by reading the whole author's blog, but with certain examples, like how the fizzlefade effect was built or how to understand floating point. But to give a general overview, it is a quite specific technical book: You get history about 90s hardware (the 80386, VGA graphic cards, sound systems and the dreaded MS-DOS RAM handling), some background about the team and who did what regarding Wolf3D, but then it is a dive into the source code, analyzing, explaining and commenting the most relevant parts of the game internals, from how the raycaster works to how the sprites were stored, the different subsystems (sound, input, memory, cache, ...). It feels short but is +300 pages long, and also contains appendices and sequels & ports chapters to learn miscellaneous things related with the game.

I loved reading it, mostly because Wolf3D was one of the first PC games that actually made me start enjoying my father's 386DX instead of only my beloved AMIGA 500, and while it wouldn't be until 1994 that I started learning to code and grasped VGA graphics programming and assembly, I love the amount of tiny but interesting details that I've learned, from how a digital joystick worked and would be read its inputs, to why there were different sound formats or how clever were the guys at id storing the sprites to speed up even their reading and writing with VGA planar modes.

A great technical and nostalgic walkthrough the source code of a game that changed everything, but also a reading about how at the early 90s and the old MS-DOS days everything was harder, from playing videogames (with the conventional memory limitations) to developing them (way harder than being able to play them :)

Notes

As I was reading a book about generating computer mazes I read the book announcement and couldn't resist to try to adapt the maze generators to export Wolfenstein 3D maps. The result can be seen here, as Wolf3D doesn't supports mods or external maps easily, I decided to reverse-engineer NMap's (an unnofficial mapping tool) .LEV file format and generate those files with simple data.

After reading the book now I want to do a raycaster (probably using PyGame for drawing :_)


Regarding Technical Code Tests

Quick post with some personal thoughts regarding the last Code on the rocks podcast, which was about recruiting and human resources, but it mentioned the topic of technical code tests for candidates.

First, a confession: I am quite terrible at doing code tests, due to two main reasons:

  • I tend to get nervous, so I try to complete them in one sit even if given more time (like "the weekend")
  • I always time-box them if they aren't limited in time

When I start a code test, I get into a state I can only think about it, so my normal life gets disrupted until I'm done. I'm unable to take long breaks, or sleep and then continue. I also know it can be harmful for me to time-box when I could instead take advantage, because I could for example do multiple iterations using the extra time to improve something, but my reasoning here is:

  • This is a test, so for me the rule "is take it as such, a test": not strive for perfection but "what you'd do in a few hours most"
  • My time is precious. I'm not going to spend a whole weekend with an unpaid code test, I'm sorry

I've only done 4 code tests in my life (out of 10 companies I've worked/work at):

  • one I nailed it
  • other I did well enough to get hired
  • one I failed (there were external factors but I still had mistakes)
  • the 4th wasn't evaluated as I got hired elsewere and they stopped the process. I'd like to think was going to be ok

Asking for a code test it's a standard practice, and in some scenarios it is one of the few alternatives (e.g. remote work), but I dislike them as it is hard to be trully fair/objective evaluating them. It is also quite hard to come up with unbiased coding challenges, too easy to fall into either algorithmic ones, or too specific/narrow problems that while you might actually be working at if hired, you might as well not have faced before (so is not fair to ask about them). And most times there's a subjectivity factor upon the reviewers: They might not like your style of code, they might have their biases and/or preferences, and sometimes happens that they might be reviewing the code for the first time and think there is only one "correct approach".

I instead prefer other alternatives:

  • do an actual job task (or bugfix): getting paid for it as will take some time, but is a nice way to get the feeling. The main problem of this approach is it's really hard to do while working
  • "work with us for a week": Similar to previous one, but becoming a member for a certain time. Best way to see (both sides) if there's a match, you're part of meetings, etc. and not just of a specific task
  • doing a real task while pairing with an actual engineer from the company, so you don't get overwhelmed by doing something without knowledge of the scenario/context
  • if not the previous one, at least doing a code test but live with a peer from the company, in a constructive way. Probably will make you nervous but at least you're able to explain your reasonings and the other side can also ask you why you take some decisions

Also, one thing I think it is critical is to give feedback to the candidate. I'm not saying you should reply with the failure points, but at least give some general feedback so they can improve. After all, they gave you time and effort by doing it.

And finally, coding tests are a cheap way to filter candidates for the recruiting deparment, but they do take effort both from candidates and from the technical side of the company (preparing and reviewing them). Effort that sometimes the recruiters could also spend filtering their targets instead of blind-shooting everywhere. This is a complaint because I've seen and still see so many bad examples.

For me code tests just work as a filter but act like a double-edged sword. I know of a few good engineers who have failed code tests, and I've met other people who probably were good "coding" but were not somebody I'd be happy to work with. As usual, there is no silver bullet.


Recommended Articles - 2017/09/05

Vacations delayed this post a lot, but on the other hand lots of interesting articles gathered during this weeks.


Book Review: Writing Idiomatic Python

Review

Writing Idiomatic Python

Title: Writing Idiomatic Python

Author: Jeff Knupp

A small yet very useful book to teach you how to do things in a proper "Python way". It assumes you already know the language, and uses a very simple yet effective system of 1) describing the topic, 2) showing the harmful/wrong/typical way of doing it and 3) showing the idiomatic/best way to do it.

Comprehension lists, generators, choices of function arguments, default value caveats, even when to discard using objects in favor of simpler structures like named touples or just modules with functions.

Some of the examples were very revealing for me, as I come tainted from other object oriented languages and things are different in Python. You can read it in one or two afternoons so there's really no reason not to do it if you work with this programming language.

Notes

I updated my Python Gist with some notes from the book.


Recommended Articles - 2017/07/25

My latest bag of interesting articles and talks I've recently read, watched or listened too (you can check which podcasts I listen to here).


Previous entries