ashdnazg

argv[0]

I thought it's like hopping onto a bus. Then it doesn't take a lot for "hop" to change into "jump".

A bit of a niche game: https://www.mobygames.com/game/63804/socher-hayam/

Although it has cult status in Israel for some reason.

Thank you!

It's similar with Turbo Pascal 3.0, but there's only one segment since it's a good old COM file. The compiler just copies its own first ~10000 bytes, comprising the standard library, and splices the compiled result to the end.

I can see how this makes transcompilation relatively straightforward, although the real mode 16-bit code is a bit unpleasant with all the segment stuff going on, so you might as well just decompile :D. It's very possible that similar instructions will be emitted in 3.0 and 4.0 for the same source input.

My program also has the stack checking calls everywhere before calling functions. I think that people using Pascal weren't worried about performance that much to begin with, so they didn't bother disabling it.

I'm writing a decompiler for Turbo Pascal 3.0, to reverse engineer an educational game from the 80s.

Since TP 3.0 does no optimisations, and looking at the progress so far (~25% decompiled), it seems like matching decompilation should be achievable.

If/when I get to 100%, I hope to make the process of annotating the result (Func13_var_2_2 is hardly an informative variable name) into a community project.

That's a good point, the matter of timing different fleets from different sources to arrive at the same time is definitely an operational challenge.

I think it's a bit difficult to describe a game as purely strategic/operational/tactical.

Games can contain strategic/operational/tactical elements or choices, and I would say that a game where the vast majority of choices are operational can be called an "operations game".

When I played Konquest/Galcon, I felt that the biggest challenge was figuring the correct timing and order of expansion, which to me feels like strategy. It's very possible that AIs would disagree with me.

I also thought about this type of game!

I have more experience with the discrete version - e.g., Konquest[0].

I think it's not very operational, as getting your ships to battle is as simple as saying go from A to B. Your operational choices boil down to whether you want to pass through planet C, to trade time for flexibility.

While it has perfect information over your own ships, I think the core idea can be easily adapted to have separate players controlling separate planets, with delayed communication, both for people playing this game and for an AI competition.

[0] https://apps.kde.org/en-gb/konquest/

With AVX512 (and to a lesser extent with AVX2) one can implement 256 bit addition pretty efficiently with the additional benefit of fitting more numbers in registers.

It looks more or less like this:

  __m256i s = _mm256_add_epi64(a, b);
  const __m256i all_ones = _mm256_set1_epi64x(~0);
  int g = _mm256_cmpgt_epu64_mask(a, s);
  int p = _mm256_cmpeq_epu64_mask(s, all_ones);
  int carries = ((g << 1) + p) ^ p;

  __m256i ret = _mm256_mask_sub_epi64(s, carries, s, all_ones);

The throughput even seems to be better: https://godbolt.org/z/e7zETe8xY

It's trivial to change this to do 512 bit addition where the improvement will be even more significant.

Competition works because the more successful a company is, the more resources it gets (money from the customers).

If a free Linux distribution is more successful, its resources don't scale accordingly.

I think he meant verbs, and specifically how you say things like "could have done" - the order of "hätte machen können".

I'm glad I walked Hadrian's Wall Path before this happened.

Close to the midpoint you're walking up and down a bunch of small but steep hills and valleys, when a huge tree appears in the next valley.

It was really a memorable view in the mostly monotonous English countryside.

I don't understand the higher performance either. What I know as the significant advantage is that you can have one object in multiple lists.

More like 10000 [1]

[1] https://en.m.wikipedia.org/wiki/Kawara,_Fukuoka

Pretty sure it's optimisations.

Even small things like converting multiplications followed by additions to FMA will reduce the operation count.

Add to that constant folding etc. and a speedup factor of ~3 is not so hard to imagine.

I think I only recently learned that there are two different Steve Jacksons.

The founder of Steve Jackson Games and creator of Munchkin and GURPS [0]

The writer of Fighting Fantasy and founder of Games Workshop and Lionhead Studios [1]

I find the fact that the two are in business quite satisfying.

[0] https://en.m.wikipedia.org/wiki/Steve_Jackson_(American_game...

[1] https://en.m.wikipedia.org/wiki/Steve_Jackson_(British_game_...

Ooh, I also did the compile-to-WASM side quest! There are some really fun optimizations one can do to make the emulation run faster.

It's orders of magnitude faster than my naive hand-written emulator.

Asymptotic analysis is only relevant if you have some series (or a function).

The series 0.9, 0.99, 0.999,... is asymptotically close to 1 and also asymptotically close to 0.9999... (with infinite 9s), since for any epsilon, I can find an index N after which all elements of the series are within epsilon of the target.

Since a single series can't have two limits, 1.0 should be equal to 0.999...

Note that real numbers are allowed to have infinite digits after the point, otherwise they wouldn't include things like 1/3.

I'm sometimes tuning accordions, which is rather similar, but if you want to lower the tone by a lot, you can plop some solder close to the tip of the reed.

It's pretty clear why that's the opposite of filing off material close to the tip, so obviously the tone goes lower.

In my mental image, filing close to the base of the reed gives the reed a similar shape as putting extra material next to the tip (thinner at the base, thicker next to the tip), and that's why it behaves the same.

In the Spring/Recoil RTS game engine[1] we adapted Lua to have deterministic execution allowing synchronous multiplayer simulation. In addition we relatively easily implemented a precise[2] serialization of the Lua VM, allowing us to support save/load for games with no code required from their side.

In other languages these would require much more effort.

[1] https://github.com/spring/spring or https://github.com/beyond-all-reason/spring (yay for forks!)

[2] Preserving the order of iteration on items in a hash table after deserialization and further manipulations.

I think you mean Coagulation[1]. I remember playing this map with a bunch of friends and two split screen TVs. Hearing somebody swear at you from the neighbouring room is a wonderful experience.

[1] https://halo.fandom.com/wiki/Coagulation

I used it in a few game jams and can thoroughly recommend it.

The interface might be intimidating at first, but with two wave generators and a couple of patterns you can already conjure a passable background track. A bit more complexity and it can sound pretty good.

In my case it definitely didn't (so far).

I'm not a prolific writer and the subjects are just what interested me at that point in time and I feel should be public. Unfortunately, there aren't many companies looking for experts in palindromes.

Looking at the websites shared here, it seems like web development tutorials and tips are the way to go if you want to get hired.

I, however, recommend writing about whatever gets you excited and you want to share with the world. Especially since you're happy in your current place.

The article's definition of not revealing information is a bit unclear, but if we understand it as Eve not knowing who holds any single card, your solution seems to work. At least assuming the following code is correct :)

import itertools import functools

for eve_card in range(7): cards_left = set(range(7)) cards_left.remove(eve_card)

    mod_to_cards = [[], [], [], [], [], [], []]

    for c in itertools.combinations(cards_left, 3):
        mod = sum(c) % 7
        mod_to_cards[mod].append(set(c))

    for combs in mod_to_cards:
        i = functools.reduce(lambda x, y: x.intersection(y), combs)
        if len(i) != 0:
           print("intersection", eve_card, combs, i)

        u = functools.reduce(lambda x, y: x.union(y), combs)
        if len(u) != 6:
           print("union", eve_card, combs, u)

Yes. For instance, if a player says the sum of their cards is 3, Eve immediately knows they have cards 0, 1 and 2.

Our CI posts a list of shame with the 10 worst offending expressions on every PR as part of the build and test results.

So far it's working quite nicely. Every now and then you take a look and notice that your modules are now at the top, so you quickly fix them, passing the honour to the next victim.

Note that it's not 100x faster than C, but than bend running on one CPU thread.

Running the equivalent C code takes ~2.3 seconds on my machine. Same order of magnitude as bend on the beefy GPU.

Each row has 3^3=27 options, which doesn't fit in 4 bits.

This code encodes a board into [0, 6045] which fits in 13 bits: https://gist.github.com/ashdnazg/5cca7de6bac0eef4532d0c635c6...

It follows the principle that one can represent a board by choosing k filled spots from 9 and then choosing k / 2 Os from k. These two combinations can be converted into an index, which can then be offset according to k to prevent collisions with indices from other ks. This offset is not pretty, but it works.

I haven't thoroughly tested my code, but the principle should work even if there's a bug or two :)

With some luck I'll find time to write a clearer explanation or a blog post.

Package name should have been Lattex.

Interesting article!

Regarding the low core-count, you might actually lose performance when having less CGUs, since your absolute estimation error is larger.

For example if a CGU can take 3 times as long to compile as another with the same estimate, we might end up with a 0.75:0.25 split if we have 2 CGUs, ending up with a 50% increase in compilation time, but with 16 CGUs the worst case (one CGU taking a 1/6 of the time and 15 CGUs taking 1/18 of the time) will only result in ~11% increase in compilation time, due to the automatic balancing that job scheduling gives us.