Recently I wrote a simplistic RISC-V interpreter for educational purposes mostly, and a friend was benchmarking it against several scripting system in the context of game-character control routines. Well, it's quite fast for what it is, though Lua is still somewhat faster, heh.

Some benchmarking code is here: https://github.com/glebnovodran/roam_bench

Very cool! One tip: Take the execute segment and produce fast bytecodes instead of interpreting each instruction as a bit pattern. Producing faster bytecodes is something that even WASM emulators do, despite it being a bytecode format.

Thanks! Yeah, this one is supposed to be a very simple implementation for a kind of "how to write a machine code interpreter" tutorial, but I was looking to experiment with some optimizations if time permits. Patching with pre-baked alt-bytecode was one of the ideas indeed.

What’s the difference between a bit pattern and a bytecode?

The fast bytecode is reduced to a simple operation that excludes certain knowns. For example if you have an instruction that stores A0 = A1 + 0, then knowing the immediate is zero, this can be reduced from reading a complex bit pattern to a bytecode that moves from one register to another, basically MV dst=A0, src=A1.

So what would a bit pattern be in this case? I ask because I’m probably being too simple, but from a certain point of view, it’s all bits.

Couple years ago was experimenting with portable OpenGL rendering, and, interestingly of all platforms I had to deal with the Web was the easiest target :) - thanks to the excellent emscripten largely.

If interested, you can find the code/demo here: https://github.com/schaban/crosscore_dev (the link to the online demo is there in the README)

> I'm going to start learning graphics for the first time

Vulkan is a quagmire of very low-level concepts, the danger of getting stuck in them and give up without learning anything is just too high.

At the same time making something with OpenGL that is more interesting than a simple rotating cube is not that difficult and you will get a lot of mid-level understanding - how rendering pipeline implemented and organized, what kind of task it is. "Porting" this knowledge to Vk is straightforward.

> No I mean do full software rendering, no shaders, no graphics card.

But why?

There doesn't seems to be a lot to learn about applied linear algebra (in the sense discussed here) by implementing a rasterizer.

But there is plenty of LA above and below that (in the scene management, in the shaders).

Eh, it's basically a project consisting entirely of the parts of LA that the article is talking about.

> terrain generation in OpenGL

Well, sounds like pretty interesting thing to do, so rewarding in itself maybe. Is it published on github or elsewhere?

Also, as someone doing graphics programming mostly as a hobby, I think a good thing to do is to learn the artistic side of things (to some extent), might give you some advantage.

Thanks, yea I originally did it just because I thought it would be a nice change of pace from my day to day, and a fun way to learn C++. The code isn't really good so I avoided pushing it to github.

Yea the artistic side of things might be good to try, I do like the idea of exploring toon shading more.

Please let me recommend SideFX Houdini as an artistic (yet technical) tool to learn: https://www.sidefx.com (perhaps would be a kind of therapy in itself - it was for me long ago)

> exploring toon shading

Sounds excellent! And don't hesitate to publish your work.

Curious, is SideFX Houdini similar to Blender? Why use one versus the other, if you don't mind answering.

Well, to make an (imperfect) analogy with programming tools - Houdini is like Emacs, while Blender is more like Visual Studio.

That is not to say that one is intrinsically better than the other, but for a technically-minded person (== any programmer in this case), the way Houdini works will make much more sense.

Learning either of these tools is not an easy task, but I think that starting with Houdini will feel more natural in cases like yours (SE background, interest in interactive graphics).

You can email me (see my profile here) for some more Houdini-talk!

He explains the carpet in the top comment under the video.

He says it's very thin and has not noticed static buildup. Understood but it doesn't have to be noticeable to cause damage.

I wouldn't do this either:)

Old components are more resistant against ESD though due to the relatively huge processing nodes. On the other hand, the boards lack conformal coating and the through-hole pins are an ideal entry point...

I still wouldn't risk it.

I came across a russian translation of Shahnamah several years ago, that was published in 1950-60s, and it's in rhyming verses unlike most other Western translations that mostly resort to prose approximations.

Amazing experience, I even remember cross-referencing certain passages in Tajik edition to try to get some idea of original rhyming and rhythmic techniques mentioned by the translators (I don't know the language, but since it was written in Cyrillic I could get at least a general idea how it sounds).

For whatever reason I stopped right before the Iskandar (Alexander the G.) parts, have to get back to it someday.

Frank L. Holt's books on the subject are really interesting, "Into the land of bones" in particular.

Neat.. of course it seems obvious now, but that's funny - I'm Ukrainian and I think that without explicit explanation it would have never occurred to me to read, let alone pronounce it this way - the dot before the extension somehow puts an insurmountable boundary after "olive".

As a long-time beginner student of several Slavic languages, I like that word play too, with ".c" being "ts". It makes me wonder what missed opportunities there are for C library names with a funny pun.

> at least tens of thousands of simulated AI agents

Are you planning on displaying all/most of them every frame, or just to control that many of them, then draw those nearby/visible?

If it's the former (but how exactly?) then perhaps Vk is the way to go, if the latter, then it's hard to see how Vulkan vs OpenGL is all that relevant here.

Many of the enemy entities (which I’m expecting to be around the ten-thousands in the late portions of the game) are going to be visible on-screen, since most of them are going to be flying above the ground and only the terrain is going to hide them (no big architectural structures on the map obstructing them). And I would like to create lighting effects when they explode, which would require huge lighting counts.

The AI for the flying enemies isn’t going to be too complex, it will probably going to be some variation of boid simulation. However I still expect this to be computationally intensive, particularly when it comes to querying nearby entities and terrain. I am expecting some of the expensive geometric querying can be moved to the GPU via compute shaders.

The reason for using Vulkan instead of OpenGL was more of a pragmatic one: I’ve heard that OpenGL drivers can be hilariously bad on Windows, when it comes to both conformance and performance. Vulkan seems to be better in that respect, since both Nvidia and Amd has incentive to develop decent enough Vulkan drivers since some high-profile AAA games use it. Also, it is a pain in the ass to debug issues in OpenGL, and Vulkan is at least better than that.

Right, there's no reason to discard a game engine just because its most common usage patterns are inappropriate to your needs. Even if you do need to draw a zillion objects on screen, any engine will let you create your own mesh and feed that to the renderer.

IIRC the game From the Depths does this, being a game where you create ships using thousands of voxels. Using gameobjects for everything just would not have worked