That looks pretty ebin 

Is source included? What is the license? Can we modify it? 

Source is in there, GPL v2. 

Congratulations on the release. I was following the development of this and I know that it took a lot of work to get to this point. Good stuff. 

Major congratulations on the first public release!

It's extremely impressive for an 8-bit software renderer, that's for sure. Being able to use external textures with filtering, custom models, etc in a software renderer is a novelty, and the dithering effect that the renderer produces is actually quite attractive for a game like Quake.

I really like the little touches of style e.g. the altered loading text ("Arriving at E1M1") and the HUD is nice, though it'll take some getting used to.

Performance is highly variable but I suppose that's to be expected. The main detractor for me is the wild variability in framerate and especially frame TIMES, regardless of resolution. There's no way to measure the actual frame times, as far as I can see, but simply from perception they seem extremely variable.

If multicore rendering was implemented and allowed it to scale efficiently in performance, this would be a really attractive engine. As it stands, not being able to peg it at 60fps even at 640x480 means this won't be my day-to-day engine.

I realise the entire philosophy of this engine is that it is a _software renderer_, but I do wonder whether or not the same 8-bit rendering system could be achieved in Vulkan to leverage the power of modern graphics cards and achieve massive performance gains.

With all this said, this is a great first release and I'm really looking forward to seeing how Retroquad develops. 

Thanks for the review. As stated in the readme, part of the performance issues in this demo is that half of the vanilla Quake maps were recompiled without VIS data, so all of their polygons will be processed at all times. So, performance will vary significantly between maps with VIS data and maps without.

That aside, scenery complexity also causes poor performance. With r_drawflat 1, Retroquad performs much slower than other software renderers, so it's mostly not an issue with the rasterizer portion of the renderer.

Also, there's no x86 Assembly code at all. This may be one of the reasons why its polygon processing is slower than in other software-rendered Quake engines. I haven't compared it against software-rendered engines with pure C code yet.

The pre-rasterization stages were not optimized as much as they could be yet, because every time a new effect such as multi-layered transparencies and depth textures is implemented, the pre-rasterization pipeline must be modified to accomodate that. After the last planned effects such as colored lighting are implemented and the pre-rasterization pipeline is fully set in stone, it can be optimized.

Animated lightstyles also causes significant drops in framerate. Again, this is not an issue with the rasterizer, because lightstyle animations are fully processed prior to the rasterization.

With optimized lightmapping, optimized polygon processing and multicore rendering, I'm certain it could achieve a solid 60fps. Also, its rasterizer was developed from the ground up with scalability in mind - 8-bit addressing scales linearly accross resolutions, while 24-bit per-pixel processing would get exponentially slower.

Future features such as colored lighting, fog and shorelines will certainly have a very small impact on performance. Colored lighting will definitely have the same performance impact as glowmaps already have, which is negligible. 

I'm curious to know MH's opinion now.

This release properly shows the visual quality I wanted to achieve, so it can be judged without any misunderstandings. Even if he still dislikes the look of some effects, I'll respect that because it'll be an opinion grounded on the actually intended look. 

I don't actually recall previously having an opinion, never mind what it might have been.

I'll just say congrats on the release. I have a sense of the huge effort you've put into this, and any payoff you get is well-deserved. 

Thanks for the comments, Mankrip. I admit I didn't read the readme. I have now :P

Why did you have to recompile the id maps? Does RQ require the maps to be modified in some way? 

The maps had to be recompiled with qbsp -splitturb to have lightmaps enabled on liquids. 

Impressive!
Nice job, and I can't wait to see newer versions with some optimisations.

However, I've tried to compile it in 64 bits just for fun, but it seems some files are missing (console.c, dirent.h, etc...) 

Use the CodeBlocks project file. The Visual Studio project file is outdated. 

you could use cmake or genie to alleviate that 

The main issue is that the Visual Studio compiler produces bad results. TDM-GCC compiles it properly. 

bad results, but kind of awesome too.