Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Changing underwater screen colours Goto page Previous 1, 2

| Inside3d Forums Forum Index -> QuakeC Programming

View previous topic :: View next topic
Author | Message
--- | ---
Nash Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia |

Posted: Mon Oct 29, 2007 4:57 am Post subject: |

I'm not whining. I already know the solution to my problems. I just thought it's a non-standard way of doing things here. I come from a school of thought that modifying the engine source to cater to a mods' specific details is messy. I guess I should just go ahead and do whatever I want without worrying if it's "valid" or not.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Mon Oct 29, 2007 7:49 am Post subject: |

Nash: I totally agree with you, you should avoid changing the engine source as far as possible, unless it's made as a patch provided to LH for modder-friendly underwater tint changing. _________________ Look out for Twigboy

Back to top |

Nash Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia |

Posted: Mon Oct 29, 2007 8:28 am Post subject: |

As far as tint changing for Quake's default liquids, it's easy enough to move those to a cvar. For my project's specific needs though, I would also have to modify hmap2.exe to produce the extra content types I need. It's such a big deal for me to implement this right now because, I am actually porting over my mod which used to be developed for an OpenGL Doom engine port - in that engine, it is very easy to create an unlimited amount of custom view tints because it's all done through scripting and I didn't have to touch the engine at all.

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Mon Oct 29, 2007 10:45 am Post subject: |

I guess Doom is technologically superior. _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Mon Oct 29, 2007 1:07 pm Post subject: |

I guess so. Nash: Doom didn't originally have any scripting, or modding capabilities for that matter, at all. Quake on the other hand, had a (pretty good at the time) gamecode logic system, and generic modding capabilities. Problem is that they (id Software) didn't imagine the engine was going to be used by modders to create entirely new games, or just generally changing the looks and feel of the game to radical extents. That is why today most Quake engines have a hard time "working around" the already existing systems when they're adding new features, to ensure that old features still work as before (compatibility), whereas Doom engine programmers can design their own scripting systems and modding architectures to suit all their needs without much hassle, cause there's no "old" scripting system which you have to keep in mind.
I'm obviously not saying it doesn't take a lot of standardization work/discussion to make something for an entire community, nor that it'd be easy to design a script system.
With that said, ignore what I said. I'm just rambling
Have fun!
_________________
Look out for Twigboy

Back to top |

Nash Joined: 19 Oct 2007 Posts: 95 Location: Kuala Lumpur, Malaysia |

Posted: Mon Oct 29, 2007 1:32 pm Post subject: |

Sajt, I hope you were being sarcastic. I was not implying that. I understand that the Doom and Quake engines are two totally different beasts by design and what works for one engine won't work for the other because they're both doing things differently at the core.
Most of the Doom engines today offer nice features for the casual mappers or light modders, but will never be able to be as flexible as what QuakeC can do.
I found QC to be more impressive, hence the engine switching. The little compromises I have to face to get my little details ported over aren't a big issue compared to the vast amount of power I readily have with QC and I think it's worth it.
Urre, yes, you're right. The main problem with a lot of Doom source coders is that, when the source came out, they all started adding a bunch of new features and what happened was that there are so many different ways of doing the same thing and no one can reach an agreement on what is "standard". In respect to that, I find the Quake community to be better because of the standards that have successfully been maintained throughout the years. Compatibility is maintained and everyone is happy.
Anyway! I think this discussion is pretty much over; since my mod will be single-player-only anyway, I guess I'll just go ahead and do what I have to do!

Back to top |

Preach Joined: 25 Nov 2004 Posts: 122 |

Posted: Mon Oct 29, 2007 3:59 pm Post subject: |

I suppose if you wanted to do it backwards compatible style, the easiest way forward would be to add an extension for toggling the waterwarp effect on a player. You'd essentially do things like the extras mod above - the z-fighting can be avoided by careful mapping, grouping the right brushes together as entities etc.
The extension could work as follows:
//NASH_WATERWARP
.float waterwarp
//supporting engines set this float to 1 on clients before playerprethink if the player has it's viewpoint in a water volume
//They then read it's value after playerpostthink to determine if the waterwarp effect should be applied to the viewpoint for that player entity
Then engines without the extension would lack the warping effect but otherwise work correctly, and engines with the extension would behave right. Anyone see a better way of handling it?

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Tue Oct 30, 2007 8:47 am Post subject: |

Preach: I think you misunderstood the whole waterwarp thing, I really doubt he means the awful glquake warping which pushed vertexes underwater around, but rather the software renderers waterwarp, which moved pixels on the view around. I think there ought to be better ways of handling it. It'd be cooler with a proper framework for these kinds of post-processing effects, which is easily expandable and with more control for modders.
_________________
Look out for Twigboy

Back to top |

Preach Joined: 25 Nov 2004 Posts: 122 |

Posted: Tue Oct 30, 2007 9:24 am Post subject: |

But it would have to be up to the engine how the waterwarp appears, otherwise you're gonna end up with one waterwarp effect for the original water brushes and one for the new water volumes you're creating in the mod. That would defeat the point of trying to make them look consistent. The GLquake warp is ugly and bugged, but no engines out there continue to use that, right?

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Tue Oct 30, 2007 3:02 pm Post subject: |

Preach: when it comes to that, I'd say it depends on wether the engine finds mod/map/entity specific info. If a mod wants their water to look a certain way, they can provide a file with info for that. It could also be map specific, entity specific, or much rather, shader specific. DarkPlaces already has a lot of shader stuff going on, which specify a lot of appearance info. It could just be expanded. Then, if the engine doesn't find any info, it should just use default values, some of which could perhaps be changed by cvars.
And yeah, I doubt any engines use the old glquake water warp. Unless ofcourse, you're running glquake.
_________________
Look out for Twigboy

Back to top |

Preach Joined: 25 Nov 2004 Posts: 122 |

Posted: Tue Oct 30, 2007 3:18 pm Post subject: |

We're still talking at cross purposes though, I was explaining how you could expand the extras mod into something that fully simulates water using entities - ie with that extension you could make a volume that is indistinguishable from a volume of water when you enter it, with the added bonus you could selectively control things like tint. What the waterwarp looks like is a totally separate issue.
Also, you'd need to change my suggested method slightly, as it stands the waterwarp wouldn't be applied on a frame when the player was above the waterline before physics, and below it after physics. You'd in fact want to set the value before playerpostthink/during physics, then wait until after playerpostthink to decide if you need to apply the effect. It would also cause some problems over the network, but there might be ways round that.

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> QuakeC Programming | All times are GMT Goto page Previous 1, 2
Page 2 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group