[quake3] Greetings

Chris Bunting cbunting99 at gmail.com
Thu Apr 10 01:37:37 EDT 2008


Hello,

There are many options available for a custom Quake 3 Engine. Last year, I 
first started posting screenshots of the first version of my rendering mods 
based originally on Evolution Engine.

The main problem I see with trying to advance Q3 engine is this..

Most 3rd party software used in games today is windows only. This really 
isn't a problem if all of the developers use windows. But still, many of 
these 3rd party programs may need some sort of engine incorportation to 
access the dll's and such.. Hence, this was the very first change I ever 
made which caused my engine to need an external .dll for the new renderer.

If you are not so worried about having a Linux / Mac version and you don't 
mind a windows only game or mod using Q3, you can basicly start out the same 
way that I did. All that is required 2 two main issues covered.

Firstly, You need to convert ioQuake3 to C++.

Second, you can use the very same Open Source 3D (rendering only) engine 
that I use. Horde3D. http://www.nextgen-engine.net/features.html

Horde 3D is basicly a GLSL 2.0+ Shader only OpenGL engine. So it can render 
scenes just as good as many of todays high tech 3d engines. The outdoor 
scenes that I show, use a custom gnome exporter and load the data into the 
engine using xml for the world and models. But you could also use Leadwerk's 
Studio, FreeWorld 3D or many others. Horde3D isn't an engine which is why 
you can replace the renderering engine in almost any opensource game while 
still leaving the networking and other features in tact. I guess now, I just 
like C++ better.

The main reason I choose a different route because games are becoming all 
about wide open outdoor terrain. And unless you implement some simular 
system, you just will not be able to achieve the desired results. I am also 
not a matter by nature. I can not get used to gtkradient, World Craft, Quark 
ect. But these new editors make it easy for almost anyone to create worlds, 
levels and terrain.

There is also tons of editors out there for this. Most are not free but they 
are fairly cheap if they aren't.

3D Editors that I know about.
http://freeworld3d.org/
http://www.leadwerks.com/
http://www.quadsoftware.com (Gnome)

Terrain Creation. (specific for terrain mostly)
http://www.pnp-terraincreator.com/  (Also has a vegitation generator)
http://www.dyvision.co.uk/ale.htm
http://www.dreamlands.to/

Charecter Animation.
http://www.insanesoftware.de
http://www.polyboost.com/

Shader Design
http://www.opengl.org/sdk/tools/ShaderDesigner/

In-Game Ui Editors
http://www.age3d.org/uieditor/index.asp?page0=/uieditor/container&page1=/uieditor/uieditor

In-Game Scripting
http://squirrel-lang.org/default.aspx

Model creation and Editing.
http://www.softimage.com/products/modtool/  (Free)

And there are many more. Those are just some of my bookmarks from the past 
year.

My biggest reason for wanting to learn about these newer advancements with 
OpenGL and rendering are all because of Crytek.
Thier engine simply amazes me, http://farcry.uk.ubi.com/videos.php

Chris


----- Original Message ----- 
From: <monk at rq3.com>
To: <quake3 at icculus.org>
Sent: Wednesday, April 09, 2008 7:57 PM
Subject: Re: [quake3] Greetings


>> So just to be clear, by 'just extend the base', do you mean to just work
>> on ioq3 itself, not fork it or anything but work on it directly?
>
> That's what I mean, yes.  I am used to referring to vanilla Q2 and Q3 as
> "baseq2" and "baseq3" instead of, say, VQ2 and VQ3.  Just a habit I can't
> break.  So in reference to ioq3, I view the original fork/tree to be the
> "base" in my strange mental realm of obtuse terminology.
>
>
>> Or we could always just do something like this: get to a point in the 
>> ioq3
>> engine where we can agree we've worked on it enough, and feature freeze
>> it.
>> Then fork it and focus everything on the new engine, while occasionally
>> even
>> patching the original ioq3 engine if need be. If we develop optimizations
>> and other things on the new engine which can benefit and are compatible
>> with
>> the original ioq3 engine, we can patch it. Just an idea.
>
> I think that idea makes the most sense, now that I think of it a bit more.
> There's only so far that some of the older hardware platforms can go.
> Get to a certain featureset for ioq3 and then freeze it as a legacy
> release, then try to take it further.
>
> Backport any important security fixes, but beyond that, leave the legacy
> release alone?  I guess it's forking, but in the opposite direction.
>
> In the end, if Tony, Tim, Thilo, Ludwig, Zak, Jorge, etc. don't really
> like the idea, then it won't work.  I'm not thinking anyone really wants
> to turn ioq3 into the type of engine that Chris or Tr3b described where
> pretty much everything has been ripped out and it's a whole new custom
> engine.  I think everyone here is vested in having ioq3 work, more or
> less, with all the q3 stuff that's already out there.
>
> If that can be done AND support for some new media or graphic effects is
> possible, at the possible expense of performance or support on some older
> hardware platforms, I think that's the win-win situation.
>
> Not everything is about the graphics, too.  Cameron from Hermitworks will
> hopefully submit some patches for UTF support and a supporting tool,
> deluxe mapping which is something one of the RQ3 mappers is hot-to-trot on
> even though I keep forgetting wtf it is, and skeletal models with
> supporting toolchain.  Hey, that stuff will probably work just fine on the
> ol' 420 MHz SGI Octane I keep referring back to.  And that helps extend
> the engine with modern features.
>
> I'm assuming it won't break support for existing media, too.
>
> Someone added a resolution-detection bit that uses the new SDL base in
> ioq3 to auto-detect available resolutions rather than have coders just
> hard-code in some common ones and hope for the best.  Would it be possible
> to auto-detect certain hardware characteristics and expose functionality
> based on that?  Have the engine scale the abilities based on what is
> available?
>
> Remember Tenebrae?  http://tenebrae.sourceforge.net is a bit dead now
> (screenshots still work), but it added D3-class graphics without losing
> support for legacy Q1 media.  Back in, what, 2003, 2004?  So it might be
> possible.  Maybe we won't get 500 fps, but most games now seem to be
> locking in to either 30 fps (games developed to be ported to/from consoles
> and TVs) or 60 fps (games assuming LCD refresh rates for either computers
> or game consoles/HDTVs).  So while things might be slow and inefficient
> from a conceptual standpoint, it might not be too much of an issue
> overall.
>
> I don't write long emails to try and push my agenda on y'all.  Well, ok,
> not primarily.  ;)  I am just trying to convince people of what I think
> would be a path that would benefit both the ioq3 project and the people
> who use ioq3, be they coders or mappers or players.  And it's just my
> opinion.
>
> However, I think maybe a year or two ago, most of the major coders on this
> mailing list wouldn't even entertain the idea.  So the fact that there's
> some discussion is heartening.
>
> We're all on this list because we like Q3.  The code, the mods, the
> gameplay the engine provides.  If the only way to add graphical goodies
> that are 3 generations past Doom 3 is to rip everything asunder and be
> left with only 20% of Q3, I don't think anyone will want to do that.
>
> But certainly, ioq3 should be able to be extended to a certain degree
> before it no longer becomes practical to work within the quake 3 codebase.
> If ioq3 reaches that point, then so be it.  But getting up to there, I
> bet the engine can be polished up quite a bit.  We won't know until it's
> tried, though.
>
> Monk.
>
> ---
> To unsubscribe, send a blank email to quake3-unsubscribe at icculus.org
> Mailing list archives: http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50
>
> 




More information about the quake3 mailing list