Makaqu

[Sajt]

I should probably look up a faster way to "palettize" colours (without losing accuracy). It's (relatively) really slow in QWalk.

I once had it create a hash table based on the colours rounded to a lower bit depth, to palettize very quickly. It might be good for "preview" palettization, though it still takes a while to generate the hash table (it could be stored on disk, though).

@Sajt ... I really like the way you code. Ended up browsing through GoldQuake a bit too looking at the extensions you added, etc. And was curious about the tint thing.

QWalk is not unusual for my style: inconsistent, incomplete and riddled with FIXME comments. Also, because this is the Nth time I've implemented things like file loading and buffered writing (not to mention model and image loading) in my Nth project, I might have gotten bored or lazy at some point this time around and messed something up. Well, I wouldn't have thought that when I released it, but now it's been so long since I've looked at it that I'm pretty sure it's rotted a fair bit.

My current project (since Feb 2010) is a cross-platform "backend" which takes care of the memory wrappers, file system, buffered i/o streams, resource manager, parser of whitespace-delimited text (like a better more generic COM_Parse), string functions, as well as full game networking layer... and a whole new UnrealScript-like scripting language. All stuff that could be used to power a 3D game, a 2D game, or just an application, or anything in between. (There are also optional modules, like image loaders/savers/processing, a sound system, and in the future a scripted GUI thing.) I still don't know if/when I'll open source it. But this is why I haven't touched QWalk recently. I finally issued myself an ultimatum: I would code certain fundamental things once more, then never again. I've always planned on doing a second version of QWalk, on top of this backend layer, which will make it a lot nicer.

(By the way, they are all things I've done before, even the scripting language, but none of it has ever been polished. Anyway, it's all been rewritten for this. My current progress is that everything is basically done except the script interpreter, which is quite trivial. Then come at least some months of fixing FIXMEs and general polishing. Then convincing myself that I should open source it right away.)

Oops.. sorry. This is a Makaqu thread. Carry on.

[Team Xlink]

When you release Makaqu V2, are you going to release the source code with it? Or is it already available, and I just can't find it?

[Baker]

The source is with the .zip

http://www.quaddicted.com/engines/files/Makaqu1.2.zip

That's 1.2, I don't claim that I've read every post in this thread to know if there is a later version.

[mankrip]

I've always included the source for all releases in the released archives, and this won't change, so no problem.

The version 1.3 has savegame deletion implemented, but it has a bug in the menu code that makes the x-minus axis unbindable in the Dreamcast version. This has already been fixed in my current code.

There should be several releases before the full 2.0 release; this allows me to establish some definitive milestones while giving me enough flexibility to keep releasing new versions as soon as possible.

I'm currently working on the version 1.4. It's taking me longer than expected to complete it because I'm fixing several buggy and inconsistent features from the previous versions.

I've also had no time to update the blog for the last few days, but I've been getting some neat results with some custom color blending algorithms that may allow for some new effects.

[Team Xlink]

Is there an svn I could get updated code from?

And now all I have to do is learn to compile for the DreamCast, but to do that, I need to download and install everything manually into my current Cygwin (It is setup to compile for PSP), and I haven't found a guide, but I will keep searching


Thank you.

[mankrip]

Not yet. I still haven't uploaded the source, but will do it before the next release.

[Team Xlink]

Sweet, I came across your post about compiling Makaqu at:

http://makaqu.tumblr.com/post/719671180

But it is only for an R1 Dev Disc, not an R 2, thank you for the help, mk.

[Baker]

MK,

Can you tell me a list of software renderer things you are NOT working on?

I don't want to make attempts at reinventing the wheel especially when your knowledge level of the software renderer would blow me away.

I guess here are some things that I always wished the software renderer did ...

1) Alpha entity ... maps like Forwards Compatible.



This map crashes Makaque.

2) Some 2D graphic scale control. Maybe like OSX Fruitz of Dojo "WinQuake" where it isn't just any scale but like 1x1, 2x1, 2x2 or 1x2. I don't like the supertiny status bar in really high res modes. This seems straightforward enough someone who isn't software renderer elite like myself could still pull off.

3) Obviously the idea of using Sajt's palettization code to load 24-bit TGA files.

4) Resizing of the WinQuake window in real time in Windows. FTEQW already does this so I guess this is kind of irrelevant.

5) 24-bit renderer. I'll think I'll take a pass on this for a year or 2 Mostly because there are 206 changes in FTEQW to support it.

Anyway, I don't want to waste time reinventing the wheel but I have to say your work really gets me excited about the software renderer.

I recall trying Half-Life in software mode and being really impressed.

And on a side note, you may already know this ... but aguirRe's Enhanced WinQuake can play giant levels like Warpspasm and so on. I'm trying to decide on whether or not to do a test aguirRe protocol 10002 or FitzQuake protocol implementation and write up a tutorial.

[gnounc]

The RMQ team has an extension of fitzquakes 666 protocol(protocol 999)being developed and MH is working on a variant called protocol 777. So my votes for fitzquake, since you could upgrade it in the future when one or the other of these supersedes it.

[mankrip]

MK,

Can you tell me a list of software renderer things you are NOT working on?

For now, bilinear filtering of textures.

16-bit color video modes won't be featured unless I find out a good reason (like, let's say, support for some odd hardware that has no 8-bit or 24-bit color video modes). 24-bit color video modes will be implemented though, since in this case the colors can be directly translated. My reasoning is that if someone needs speed they'll run the engine at 8-bit color, and if they want quality they'll run it at 24-bit color; I really see no reason for 16-bit color support.

1) Alpha entity ... maps like Forwards Compatible.



This map crashes Makaque.

This will definitely be implemented soon. If not in version 1.4, right after it.

2) Some 2D graphic scale control. Maybe like OSX Fruitz of Dojo "WinQuake" where it isn't just any scale but like 1x1, 2x1, 2x2 or 1x2. I don't like the supertiny status bar in really high res modes. This seems straightforward enough someone who isn't software renderer elite like myself could still pull off.

This should be featured in Makaqu 1.4, it's very high on my list. However, it'll be dinamic, so there'll be no need to add a cvar or menu option for setting it.

3) Obviously the idea of using Sajt's palettization code to load 24-bit TGA files.

Support for 8-bit and 24-bit PNG, TGA, PCX and (maybe) other file formats should be implemented, but I'm not sure when.

4) Resizing of the WinQuake window in real time in Windows. FTEQW already does this so I guess this is kind of irrelevant.

This idea never occurred to me, actually. But I'll think about it.

5) 24-bit renderer. I'll think I'll take a pass on this for a year or 2 Mostly because there are 206 changes in FTEQW to support it.

24-bit color rendering shouldn't be hard to implement, so it shouldn't take too long for me to do it. It'll definitely come before any kind of hardware acceleration.

And on a side note, you may already know this ... but aguirRe's Enhanced WinQuake can play giant levels like Warpspasm and so on. I'm trying to decide on whether or not to do a test aguirRe protocol 10002 or FitzQuake protocol implementation and write up a tutorial.

Removing or extending the limits of the engine doesn't have a high priority for me, because first I want to make sure that this engine works well with normal Quake and with mods and maps that doesn't require a custom engine. Some limits may eventually be removed, but I can't predict when.

[mh]

The RMQ team has an extension of fitzquakes 666 protocol(protocol 999)being developed and MH is working on a variant called protocol 777. So my votes for fitzquake, since you could upgrade it in the future when one or the other of these supersedes it.

I definitely recommend the FitzQuake protocol instead of 10002. Aside from the fact that it's going to be broadly compatible with the RMQ protocol (just a search in the source code will be enough to identify the changes needed) it's better thought through and more oriented towards gameplay needs than 10002, which may have been built with convenience and functionality for mappers (rather than players) in mind.

I've implemented both 666 and 10002 in DirectQ, and 666 was genuinely a walk in the park whereas 10002 was nightmarish and I'm still not certain if I have it all done right. Good documentation (metl's Quake wiki page on the protocol), a working implementation, everything clearly commented, and being able to do direct comparisons between the before and after codebases all help.

10002 was great when there was no other option, but with 666 available and being so clearly superior there's no reason not to use it.

[Baker]

24-bit color rendering shouldn't be hard to implement, so it shouldn't take too long for me to do it. It'll definitely come before any kind of hardware acceleration.

And on a side note, you may already know this ... but aguirRe's Enhanced WinQuake can play giant levels like Warpspasm and so on. I'm trying to decide on whether or not to do a test aguirRe protocol 10002 or FitzQuake protocol implementation and write up a tutorial.

Removing or extending the limits of the engine doesn't have a high priority for me, because first I want to make sure that this engine works well with normal Quake and with mods and maps that doesn't require a custom engine. Some limits may eventually be removed, but I can't predict when.

Understandable.

Well, just for fun and mostly because I have momentum going for me at the moment after playing around with your code [and borrowing a couple of features, of course ] I will likely end up posting some WinQuake refinements just to make you aware of them.

Anyways, more experiments to do.

Forwards Compatible is my favorite mod and I'd love to see it in a software renderer.

I've implemented both 666 and 10002 in DirectQ, and 666 was genuinely a walk in the park whereas 10002 was nightmarish and I'm still not certain if I have it all done right. Good documentation (metl's Quake wiki page on the protocol), a working implementation, everything clearly commented, and being able to do direct comparisons between the before and after codebases all help.

The only thing that slightly bothers me about 666 is the lerping stuff, other than that metlslime's protocol is clean and straightforward as imaginable.

I may be overstating the lerping stuff and am possibly wrong, but most of Fitz 666 is raised limits and a few checks here and there.

[metlslime]

The only thing that slightly bothers me about 666 is the lerping stuff, other than that metlslime's protocol is clean and straightforward as imaginable.

The server-side part of this is pretty simple to implement. The client-side part of it is more involved, but can be ignored if the engine doesn't support interpolation or supports it differently.

[Spike]

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.

[mh]

The only thing that slightly bothers me about 666 is the lerping stuff, other than that metlslime's protocol is clean and straightforward as imaginable.

The server-side part of this is pretty simple to implement. The client-side part of it is more involved, but can be ignored if the engine doesn't support interpolation or supports it differently.

Absolutely, all you need to do is read the data so that you remain protocol compatible, but you can read it into a temp variable that's then discarded and handle lerping whatever way you want yourself after that. Ditto with just about any feature of any protocol in fact.

A great way for testing protocol implementations by the way is recording and playing back demos. Record in Fitz, play back in your engine, and vice versa.