Makaqu

Had a quick hack session adding 666 to FTE clients a few days ago.
I disapprove of svc_clientdata tbh. Not particuarly fitzquake's additions to it, but that it added to it rather than killed most of it. Ideally imho stats should be sent via deltaed svc_updatestat/svc_updatestatbyte rather than resending shells in every single packet even when you don't have the shotgun selected (DP6+ and QW do it this way instead, just seems cleaner to me).
But that's my only real critisism.

I understand this, but my goal was to do the simplest modifcation to protocol 15 that makes the features work (and didn't bloat packet sizes too much), rather than create the ultimate protocol. Delta compression would be nice but that's magnitudes more complicated than what I did.

Tumblr has been offline for the last eleven hours or so, so I'll post this here:

Makaqu 1.4 alpha released

Translucent BSP rendering still has bugs. It flicks a lot when there are different kinds of liquid surfaces on the screen, and the clipping bugs weren't solved yet.

There are also several small bugs in some of the new features, and several of the new features are still incomplete. Plus, there's a lot of experimental junk code throughout the source.

I usually run a diff tool through the whole source against the source of the previous public release to make sure it has been properly commented everywhere and to make sure I haven't forgot to check anything, but this time this hasn't been done.

Also, since this is an alpha release I haven't included the PAK10.PAK file in it, as well as some other miscellaneous files that used to be included into the Quake folder and its subfolders. However, Windows and Dreamcast binaries are provided, along with a test map and a slightly modified progs.dat. All Dreamcast binaries are untested.

And to make things simpler, the Dreamcast version has been renamed to Makaqu.

A stable release is still planned.

Makaque is like a breath of fresh air. At times, I feel like I am evil learning from (and ripping) from your source codes ... but yet I have a strong feeling [ok, it isn't really a feeling, hehe] I will have a cool feature or 2 that you will wish to absorb.

Such is the beauty of open source.

Closed source = being an asshole. Open source = adding to the pile of knowledge. Although I am guilty of being an asshole, I earn it for reasons never related to sharing ideas or source codes. And I hope that history views me as being an "asshole" for the cause of the greater good.

1.4 is like an early Christmas present. I hope to have time to play with it tonight.

This is a superb engine. I've just run through some e1 with it, and it really feels good in general gameplay. The only (minor) niggle I have is that the particles are a little too large when up close for my tastes, but that's a personal opinion thing and not a criticism.

Well done.

Hmm. It's pretty nice, feels very smooth to play. Except...
- menutint ran at < 1fps for me (at 1280x1024). This could partly because of readback from hardware video memory? Anyway, that and all slowdown could be avoided by using colormap hacks for menutint like GoldQuake does...
- something in the hard difficulty hallway on startbsp also crippled the framerate now and then. Not sure what... lavabomb dlight?
- teleports (startmap) flickered sometimes at mid-distance.
- I played to e1m2 but halfway through it crashed when I picked up some shells

Thanks to all.

Open source = adding to the pile of knowledge.

This is why I've released it now. The last straw that led me to release it like this is that I've got a new job which is consuming all of my time, so I should be unable to work on this engine for several months.

Keeping the source closed while working on it is good for having no interruptions to our train of thought while developing our ideas, but since my train of thought has already been interrupted and will remain like this for a substantial amount of time, there's no reason to not release this code... while releasing it may still be useful to others.

the particles are a little too large when up close

Yeah, it took me a while to get used to it too, but it's actually more accurate and now the particles seems much more enjoyable to me, since their size is always proportional to the rest of the 3D renderer's space now. Bringing down the console and looking around an explosion with the chase camera turned on is awesome.

I don't know how GLQuake scales them, but the vanilla software renderer clamps the size of the particles at an arbitrary size (which reduces their scale in the 3D space, making them innacurate) without taking the screen resolution in consideration, so particles in it look a lot bigger at 320x200 than they look at the highest resolutions.

Reimplementing the translucent fading should make things better, but the particle emitters' code must be adjusted a bit first, since in some cases it replaces the particles for others of different colors instead of just changing the colors, which makes it impossible to use the particle's time to calculate the intensity of the alpha blending.

By the way, I have no idea why the offset and the width values of the particles' lines must be changed so much just to get memset to replace the inner drawing loop. I've #if'd all the necessary changes in the code to research about this when possible.

- menutint ran at < 1fps for me (at 1280x1024). This could partly because of readback from hardware video memory?

Most likely. The best way to check for this in any software-rendered engine is to activate the menus when underwater, because then the engine will read the pixel data from the system RAM instead of reading it from the video RAM.

- something in the hard difficulty hallway on startbsp also crippled the framerate now and then. Not sure what... lavabomb dlight?

I'm not sure either. In Quake's software renderer all surfaces lit by dynamic lights are re-cached every frame, and I've added a few things at the beginning of the caching process to implement one of the new features (I can't remember which feature at the moment).

Much of the new code in the BSP renderer is completely unoptimized.

[scar3crow]

The particles do appear a little "too large" for me as well, but if they were clamped before and this is just more accurate, I think I can make the adjustment - though their low detail does show through more at those close of ranges... Nice work nonetheless.

I believe it is the dlight on the lava bomb, I get a 7-10 fps drop at its zenith, which I don't experience elsewhere. I experience similar with exploboxes and firing rockets. I also experience massively reduced framerates while in the menu - but I love the organization of the menu.

All in all, rather nifty mk, thanks for the peek at it =)

After getting used to it, the accurate particle scale enhances the sense of depth, especially for rocket trails and high-speed particles from explosions. Looks like particle shape could be customized for various effects? Or pre-stippled for an economical alpha effect.

I enjoyed trying out r_fullbright_range/gamma combos to get high-contrast. Like r_fullbright_range = 4 and gamma = 2.5.

Looks like particle shape could be customized for various effects? Or pre-stippled for an economical alpha effect.

The shape can be customized, but the possible shapes are extremely limited since the code doesn't support more than one line segment on each line. To put it simple, it's possible to shape the particles like a C, but not like a U. This is one of the reasons why they're so fast to render.

Stippling would look shallow since none of the particles would be drawn over each other, and with so many cases of particles being overlapped by other particles, using color blending would preserve the impression of thickness of the particle effects. Also, iirc stippling could overcomplicate the way the particles uses the depth buffer now, making the stippling algorithm on par or even slower than the color blending algorithm.

My final thought when I was coding this was "if the user really needs speed he won't mind opaque particles, and if speed isn't a issue he can enable particle translucency". Stuff like water surfaces may need stippling because they're more prone to loss of detail since their textures may contain several colors, but since particles only have a single color, they have no texture detail to lose.

the code doesn't support more than one line segment on each line.

I didn't know that. I wonder how bad a pattern like this would look for smoke:

  Code:

...######...
....#.......
.##########.
.......#....
############
...#........
############
........#...
.##########.
.....#......
...######...

cue early 90s flight sim particles

the code doesn't support more than one line segment on each line.

I didn't know that. I wonder how bad a pattern like this would look for smoke:

  Code:

...######...
....#.......
.##########.
.......#....
############
...#........
############
........#...
.##########.
.....#......
...######...

Yeah, skipping entire lines is simple and doesn't require any changes that could slow down the drawing code, since it can be done during metadata creation. However, at low resolutions it will stand out a lot more than stippling - which may or may not be a problem, since particles doesn't stay on the screen for long.

My final thought when I was coding this was "if the user really needs speed he won't mind opaque particles, and if speed isn't a issue he can enable particle translucency".

Just so you know you're not alone, I agree with you.

Does anyone know of a map that doesn't need extended coordinates or any other higher requirements, but that does feature multi-layered liquids (water/slime/lava/portal/etc.), translucent BSP entities and maybe some BSP entities with "fence textures"? Maybe a mini-mod.

Also, does anyone know of a good small mod to test SPR model lighting and framegroups? Preferably a mod that use as many SPR orientation modes as possible.

I'm looking for an actual test case for these features.