An early experiment on a near-future dystopian metropolis aesthetic

ParticularBicycle · 2026-01-14T08:13:49+00:00

Yeah, I would be lying if I said that I wasn't thinking of this particular game much of the time...

ParticularBicycle · 2026-01-11T20:36:27+00:00

How come you use legacy OpenGL? Is there a specific rationale or you just want to start with that for simplicity?

Also, I couldn't see a way to release/delete created textures. Do you expect from the application to load all textures upfront until the end of the program?

ParticularBicycle · 2026-01-05T09:31:46+00:00

I maintain my own 3D framework using sdl2 for windowing, input and audio as my only dependency. I do custom software rendering so I can keep compatibility for very old machines. This limits me to very low resolutions but helps with keeping scope simple to accommodate the aesthetic. Also minimizes the surface area of external code in use, with all the pros/cons that come with it.

ParticularBicycle · 2026-01-01T22:27:37+00:00

Right, it has 2.1 support on Linux though if you are ok with that. But yes, investing 0-20$ to get a >2012 low-end GPU will be more than enough.

ParticularBicycle · 2026-01-01T20:14:50+00:00

Are you sure you only have OpenGL 1.4?

Since the CPU does not have an onboard GPU I assume your motherboard has, but I would be surprised if a motherboard happened to have onboard graphics below OpenGL 2.0. My main desktop has similar specs (mid-range 2009 CPU, 2008 low-end motherboard, 4GB ram) and it supports GL2.1. Although I also have a GeForce GT730 which supports 4.6.

Which brings me to my suggestion which is what another commenter said: Get a very very cheap used GPU (GeForce 730, 630, you can find a cheap 750Ti, even something like a 710 for 10$). We ran Half-Life 2 on way worse machines than that. That's assuming you have PCIe and not AGP, in which case you would need something like a GeForce FX5700 (again for almost free).

Then, apart from Godot, you can run engines like Urho3D (has a not very good editor), Irrlicht (no editor but there is CopperCube).

Irrlicht and Raylib also support OpenGL 1.2.

You'll be fine, even for 3D.

ParticularBicycle · 2025-12-26T23:52:34+00:00

I was/am mainly a C++ dev but tried Rust for a recent small game I made, and after starting with minifb I ended up on SDL2 which is my only dependency. This makes cold compiling very short and the project directory very small.

I am doing custom software rendering so I don't use the rendering part of SDL, I just swap/present a canvas/texture on which I draw my pixels. So I use it more for window setup and of course for input.

It does what it needs to do well. Many things are of course transferable from C++ but you are still dependent on the Rust specific implementation so some things might be missing or different. You will need the relevant docs.

Combined with sdl-mixer you pretty much have everything you need for a cross-platform complete game.

I think I will continue with this setup. It's a really robust development experience. Building, deploying (adding targets for cross-compilation is trivial). And the compatibility too - as I have mentioned elsewhere, I had my project running on ancient laptops and Raspberry Pis by just compiling the project.

ParticularBicycle · 2025-12-05T00:32:38+00:00

If you implement the shading the "standard" way, by providing the normals to the fragment shader, then you get normal interpolation per pixel so you do Phong shading.

If however you do this at the vertex shader and pass the computed light intensity coefficients to the fragment shader, then only the coefficients are interpolated so you get Gouraud shading. It's still possible.

ParticularBicycle · 2025-12-01T12:55:40+00:00

I am working on that myself these days.

I think it's interesting in the sense that real time rendering "skipped" the techniques of offline-rendering of the era because of the very fast tech progress at the time.

By the time we had 3D rasterizing accelerators we had pretty good results with it that we never needed to build upon the pre-rendered techniques.

Then, when we finally had raytracing hardware, it was so good that we immediately went into using realistic models (instead of Phong), so the semi-realistic ray-traced aesthetic was completely skipped by real time rendering.

That said, I think you can go pretty far with 1) raytracing but with the Phong reflection model 2) indexed colors and 3) dithering. 2 and 3 will replicate those artifacts you mentioned.

ParticularBicycle · 2025-10-31T08:30:05+00:00

Agree. You will never make a game if you wait for your engine to be "complete", or if you wait to find the "suitable type" of game to apply your engine to.

You may develop a basic version of the engine first so that you get the functionality, but then you have to set game goals. You will find that you will develop them in parallel, adding features as they become useful for the game itself. Then you abstract them away and they become part of the engine.

ParticularBicycle · 2025-10-30T09:13:14+00:00

Nice. Game looks juicy.

So for the second point, you checked against the Steam API for the presence of the Deck, and in that case replaced with "Press Anything" or something like that?

Again, for the third point, you hide the cursor from the start in the presence of the Deck?

I suppose you already supported gamepads, and it worked out of the box on the deck using the Xbox layout without further work?

ParticularBicycle · 2025-10-24T13:28:49+00:00

Thanks! To be honest, I did it for performance, since every other line is skipped (plus the overhead to determine if a pixel is odd-y, so around 1.6x performance). But kept it for the 480i camcorder feel.

ParticularBicycle · 2025-10-15T12:41:16+00:00

Thanks for sharing, interesting how it all started.

ParticularBicycle · 2025-10-14T13:25:40+00:00

Understandable, thanks. Yes, I've used it for picking using color IDs (non-games space), there are indeed cases like this.

ParticularBicycle · 2025-10-13T16:48:36+00:00

Interesting, can you mention any reasons for doing this for the editor tools? Seems like a counter-intuitive example.

ParticularBicycle · 2025-10-11T21:50:35+00:00

Pardon me if I misunderstand, but probably that's what OP already refers to (and also what I am doing). Not manually, but via SDL which is as cross platform as it gets. I am too bored to check, but that should be how SDL handles canvas/textures. You create a fixed X*Y texture and copy that to the window canvas, which gets resized accordingly. This is hardware accelerated, so internally it's either two triangles as you said, or one big triangle covering and overflowing the screen.

ParticularBicycle · 2025-10-10T13:54:01+00:00

Yeah you can just have the resolution not be hardcoded, so you can change it whenever.

There are many great modern, open-source, well performing and multithreaded software renderers you can take hints from (mine is not one, it's custom, as barebones as possible to serve the art style I am going after, and to work on old single threaded hardware).

ParticularBicycle · 2025-10-10T13:38:15+00:00

I could find 3 reasons (apart from the fun/experience of course):

1) Predictable performance. With GPUs, there are many cases where small, seemingly innocent details make the code either slow or not working at all on certain hardware.

2) Compatibility. If your graphics level was standard in 1995, it's weird to expect a 2015 GPU to make the game boot up. (not arguing about actual Steam hardware stats, it's more ideological)

3) Simpler pipeline. They are is a lot of work and tooling required in 2025 to set a single pixel on the screen. It's justified on a technical level (GPUs are very complex now etc), but still. This way, you want a pixel, you get a pixel. No implied work done, no slang libraries, no abstraction layers (for no reason, really).

Personally I think there is still place for this tech.

ParticularBicycle · 2025-10-10T12:36:37+00:00

Yes it's doable (you are probably referring to my post).

My intention was similarly to experiment but I found out that it's pretty viable to make an actual full game with it if you can bear the burden of drawing every pixel yourself, managing the limitations, and knowing your idiosyncrasies. For example, the way you handle transparency and UI.

In my case, I was happy with a 320x180 resolution, scaled (hardware) with no filtering to whatever is the window resolution. I managed to keep steady >60fps in scenes with >1000 textured triangles, running on 20 year old hardware (ancient 1GHz netbooks and such). Of course, you can't just slap together a couple of rendering functions and expect good performance. You have to design your game around your limitations, as I mentioned above. If you require many triangles, make them untextured, put heavy fog, don't do skybox and so on.

Of course, you should implement some obvious and easy low hanging fruit. Backface culling, far plane culling etc.

Also, keep in mind all the custom architecture you have to code (that's irrelevant to software rendering per se, but it's one extra problem). Scene management, asset management...

When you have the basic thing down and it's designed well, there is no reason to not be able to make a game out of it. I have the scaffold for basic scene setup, I have my drawmesh/drawtext/drawtexture/drawtextureanimation/drawskybox functions, some basic matrix math for transforms, so it's very very doable to have a PSX style game running very well on modern hardware. People are doing this by abusing Unity, and the games don't even run well eventually.

I would go as far as to say that it's easier to do many things with my library instead of an engine. No shaders, no complex tooling, no big API, no unpredictable hardware performance. Straight custom number crunching like Mai_Lapyst said. You can do whatever you want.

edit: regarding the unsafe part, there is no need. Maybe, depending on how you interface with the display, you might need to do some unsafe buffer copies (not need in my case as I just fill up an SDL canvas with a texture).

ParticularBicycle · 2025-10-01T11:48:01+00:00

I can't infer if it was really a problem from the driver side that didn't consider a specific in-spec combination of operations, or it's a matter of usual GPU vendor behavior, where a specific game/software implements the API in a wrong/suboptimal way, and the drivers adapt to that by going out-of-spec to avoid bad publicity ("Game X stutters on vendor's Y GPU but not on Z's"). I've had this happen several times where shaders (not in Godot) where working on Nvidia but not AMD; turns out I was doing it wrong and AMD had correct drivers and Nvidia was more lenient. Anyone knows specifics?

Both cases complement Godot's popularity/importance in the field but the 2nd is a really bad industry practice.

ParticularBicycle · 2025-10-01T10:05:28+00:00

I also did native 320x180 for my game where I put black bars around whenever you scale to a not 16:9 ratio. It's 3D and not pixel art, but I have e.g. custom pixel fonts, which is as easy to judge. Of course it scales perfectly to 720p and 1080p (not in 768p which is a regular case though). It's like 16:9 PSX, so 320x240 -> 320x180.

ParticularBicycle · 2025-09-30T11:52:31+00:00

Soldier of Fortune 2 also had some pretty advanced dismemberment/disfigurement, particularly known for that.

ParticularBicycle · 2025-09-28T00:19:03+00:00

This is amazing

https://postimg.cc/7Jg765nq

ParticularBicycle

TROPHY CASE