Makaqu

[mankrip]

I'm working on Makaqu, aiming for a 2.0 release.

Here's the to-do list so far, from the top of my head:

• General stability and mod compatibility improvements.
• Get the hardware renderer working.
• Finish improving the controller support in Windows.
• Proper implementation of Fightoon's features.
• Alpha blending for BSP models.
• Automatic generation of blendmaps.
• 16/32 bit color software rendering.
• 8-bit colored lighting in software.
• 16/32 bit colored lighting in software and hardware.
• Brown/custom colored tinting of the menu background.
• Better support for multiple resolutions (HUD/menu/console scaling, custom screen aspect, etc.).
• Port to flash.
• Port to Linux.
• Port to DOS.

And the wish list:

• Hardware rendering on the Dreamcast.
• Support for the Dreamcast lightgun.
• BSP texture dithering on the software renderer.
• WAV/MP3/OGG/FLAC/ADX streaming and CDDA replacement.
• QuakeWorld support.
• Port to Mac.
• Port to Wii.
• Port to Nintendo DS.
• Port to PSP.

Work in progress:

• Dreamcast controller's analog stick bugfix. (untested)
  • Stippled sky. (cvar & menu option left)
    • Test map.
    Current changelog:
    • reckless' depth sorting of entities (from http://forums.inside3d.com/viewtopic.php?p=22096#22096 ).
    • SV_TouchLinks fix ( from http://forums.inside3d.com/viewtopic.php?p=23999#23999 ).

I'll keep this post updated.

[leileilol]

Add "Port to DOS" in there

You'd have to then truncate the long filenames, cook up a make file, etc. but it's still very possible to get it into DOS no matter how advanced the engine is. Hexen II's best port had a DOS version (H2 never was a DOS game)

If you do make Dreamcast hardware support in there (SGL api) you could hack in PowerVR PCX-2 support as well even though no one uses that card but me! But if you get one of those crappy cards (Apocalypse 3Dx) and optimize for that, it'll benefit the Dreamcast as well since the chip in that is a direct successor with the same features, plus blending. Good luck turning leafs into infinite planes, though... also remember, vertex lighting will help a ****lot**** for this chipset, so you'll also have to come up with a good implementation to translate lightmap to vertex.

Forget about ADX and MP3 streaming, that's very very patented.

[mankrip]

The ADX support would be for the Dreamcast version, as iirc the DC hardware has some sort of decompression support for it.

Porting to DOS is a good idea, it would allow the game to run from bootable CDs or flash drives with FreeDOS installed.

If you do make Dreamcast hardware support in there (SGL api) you could hack in PowerVR PCX-2 support as well even though no one uses that card but me! But if you get one of those crappy cards (Apocalypse 3Dx) and optimize for that, it'll benefit the Dreamcast as well since the chip in that is a direct successor with the same features, plus blending. Good luck turning leafs into infinite planes, though... also remember, vertex lighting will help a ****lot**** for this chipset, so you'll also have to come up with a good implementation to translate lightmap to vertex.

I'll keep these in mind, thanks.

[frag.machine]

I always wanted to understand the software renderer with more depth, documenting the key portions (at least a "who-does-what" vision of the main renderer functions) would be an awesome contribution for more people work on it.

[mankrip]

BSP translucency is a pain.

Currently the BSP renderer scans and draws all opaque surfaces in one pass, and does the same for all translucent surfaces in a second pass. I've done it this way because the renderer doesn't allow BSP scanlines to overlap.

The problem with this is that since all translucent surfaces are rendered in a single second pass, they won't overlap each other, only the opaque ones. So, for example, if a portal is underwater it will be invisible when looked at from outside the water.

I've thought about using a single pass for each translucent texture's surfaces, because doing this would be faster than doing a single pass for each surface. But there would be depth problems, as surfaces with different turbulent textures could be between them.

IIRC the renderer already sorts all surfaces from back to front, so there shouldn't be any depth problems if I use a single pass for each translucent surface. However, the BSP renderer needs more optimization for this, otherwise it may suffer massive slowdowns.

[Spike]

if it helps, q3 sorts by texture before depth.

[Baker]

I'm working on Makaqu, aiming for a 2.0 release.

Here's the to-do list so far, from the top of my head:

• General stability and mod compatibility improvements.
• Get the hardware renderer working.
• Finish improving the controller support in Windows.
• Proper implementation of Fightoon's features.
• Alpha blending for BSP models.
• Automatic generation of blendmaps.
• 16/32 bit color software rendering.
• 8-bit colored lighting in software.
• 16/32 bit colored lighting in software and hardware.
• Brown/custom colored tinting of the menu background.
• Better support for multiple resolutions (HUD/menu/console scaling, custom screen aspect, etc.).
• Port to flash.
• Port to Linux.
• Port to DOS.

And the wish list:

• Hardware rendering on the Dreamcast.
• Support for the Dreamcast lightgun.
• BSP texture dithering on the software renderer.
• WAV/MP3/OGG/FLAC/ADX streaming and CDDA replacement.
• QuakeWorld support.
• Port to Mac.
• Port to Wii.
• Port to Nintendo DS.
• Port to PSP.

Work in progress:

• Dreamcast controller's analog stick bugfix (untested).

Current changelog:

• reckless' depth sorting of entities (from http://forums.inside3d.com/viewtopic.php?p=22096#22096 ).
• SV_TouchLinks fix ( from http://forums.inside3d.com/viewtopic.php?p=23999#23999 ).

I'll keep this post updated.

Awesome.

Many people would love to see a 16/32 bit software render that supports alpha transparency. It is kind of the holy grail of software renderers.

[mankrip]

Currently wading through all Fightoon's and Makaqu's files...

Now that I'm working alone on Fightoon it will be a lot easier to reorganize everything. There's a lot of useless content scattered all over the place, so I'll salvage what can still be used, organize it and work from there.

Yesterday I skinned a third character that uses some previously unused animation frames. The other two still needs some recoloring.

I'm also making a test map for normal Quake, for testing engine features and catching bugs, but I'll turn it in a whole mod solely for this, complete with a custom progs.dat and whatever else it needs.

[mh]

I'm also making a test map for normal Quake, for testing engine features and catching bugs, but I'll turn it in a whole mod solely for this, complete with a custom progs.dat and whatever else it needs.

That would be an absolutely awesome thing to have!

[leileilol]

I get nasty crashes with 1.3 when I use the old blocky particle function (for pentium speed)

Also for 8-bit colored lighting, you might want to look at the Vavoom engine. It's a quake-based doom port that uses quake's rendering as a base and has neat stuff implmenented in 8-bit color software, and even has new ASM code for drawing colored lighting surfaces in software.

[R4mb0]

Good see you back on this !
Dreamcast needs a good 3D open-source engine with hardware acelaration and colored liths
something like kurok is for the psp.
You will finish Fightoon too ?
For hardware acelaration you will use D3d, open-gl or kglx ?
I have a request:
Add wad3 suport and maybe hl map suport on Makaqu
Halo Solitude (quake mod) team commented that they increase the framerate and the textures color quality on psp with halflife bsp´s.
For the sound a lot of the last quake-mods use mp3 for music
For sfx you can use wav-adcpm too, instead adx sound.

Good luck!

[mankrip]

I've actually been thinking that one of the best things that could be done to this engine would be adding support for a skeletal model format.

Fightoon suffered too damn much for the lack of this, it's excessively hard to make animated models that interpolates well. A custom skeletal model format with support for some kind of in-game editing would be the best.

I get nasty crashes with 1.3 when I use the old blocky particle function (for pentium speed)

The old particles checks the Z-buffer depth for each pixel of the particle, so I guess they may actually be slower than the new particles, which only checks the Z-buffer depth of their center pixel.

Also for 8-bit colored lighting, you might want to look at the Vavoom engine. It's a quake-based doom port that uses quake's rendering as a base and has neat stuff implmenented in 8-bit color software, and even has new ASM code for drawing colored lighting surfaces in software.

Depending on how similar its rendering code is, it may be useful. But I already know more or less how to get the colored lighting to work:

You will finish Fightoon too ?

No, but I'll release a version with at least three characters and two stages.

In the last weeks I've been making some new content for it, and polishing what's already in there.

For hardware acelaration you will use D3d, open-gl or kglx ?

OpenGL on the PC, KGL-X or whatever else works better on the Dreamcast.

I have a request:
Add wad3 suport and maybe hl map suport on Makaqu
Halo Solitude (quake mod) team commented that they increase the framerate and the textures color quality on psp with halflife bsp´s.
For the sound a lot of the last quake-mods use mp3 for music
For sfx you can use wav-adcpm too, instead adx sound.

Good luck!

Thanks. I can't promise anything, but I'll remember that.

[frag.machine]

Also for 8-bit colored lighting, you might want to look at the Vavoom engine. It's a quake-based doom port that uses quake's rendering as a base and has neat stuff implmenented in 8-bit color software, and even has new ASM code for drawing colored lighting surfaces in software.

Depending on how similar its rendering code is, it may be useful. But I already know more or less how to get the colored lighting to work:

Colored lights in software Quake. This is something I never imagined I would see someday. Awesome work, mk!

[leileilol]

Depending on how similar its rendering code is, it may be useful.

It is similar. The rendering engine is practically Quake with only Doom file formats supported. The lighting is all lightmaps, even! It supports both static and dynamic colored lighting.

I don't like the strange additiveness of the lighting it's too Saturn Quakey (actually that is appropriate considering the intended audience is delusional DC fanboys), but I suspect you're just using addmap.lmp for that.. and that can be fixed with another lookup table blended differently.

[mankrip]

Exactly. As I said, I didn't figure out the full effect yet, mostly because it was just a quick experiment I did years ago.

Those screenshots are from this thread.

Right now I'm going to do some experiments with the sky renderer, there's something I want to change in it.

[edit] What I wanted was to:
- Make the lower part of the sky sphere scroll backwards.
- Flip the texture of the lower part of the sky sphere.

This should be enough to make the sky truly rotate, instead of splitting and merging into itself at the horizon.

However, I don't even know the name of the algorithm they used to draw the sky as an oval. This was the best info I could find about it, but I don't understand it yet; gotta do some more tests.

Ideally, the sky should scroll in a trajectory that reminds of the lines of a shell turned on its side (its current trajectory seems to be somewhat different to that, though I'm not sure why):



[edit 2] Opened a blog for this project: http://makaqu.tumblr.com/