misc: game-engine project...

well, I just happened to run across this project (Xonotic), and yes it seems cool (want to mess around with it).

I don't know if anyone here will care about what I will mention here though.
please ignore if you don't care...


basically, I have written my own engine, which is "sort of Quake-like" (as in, it is close enough to where it can run the map files), but differs in that it is not based on the Quake-source (hence, I am not bound by the GPL, I may either use it proprietary or have it under the MIT license or similar, these details are not fully decided, although many parts will likely be MIT licensed). (mostly the effort was to free myself of GPL restrictions on the code and similar, so I could do whatever I wanted with it...).

so, essentially, it is a "ground up" reimplementation (mostly plain C).
(however, I am unlikely to be able to do a full game, as my artistic and mapping skills suck). also, it still needs work (it is not nearly so "solid" as actual Quake-derived engines, but I am working on this).

currently, I am still using some data-files from elsewhere though:
the Quake-1 maps released as GPL;
textures from the Quake Retexture Project (for sake of the above maps);
some sound effects and similar from OpenQuartz (and a few maps and textures).

textures: typically I use PNG or JPG (TGA, BMP, PCX, ... also supported);
sounds: currently supported WAV, OGG, and FLAC.
music: MIDI (custom synth).
also has text-to-speech (custom TTS engine, but it is not very good).


technically, it directly loads the worlds from map files, and so does not use prebuilt BSP files (currently, BSP's are built on-the-fly).
rendering uses real-time lighting and stencil shadows, etc...

current engine map-file support includes Quake 1/2 maps and Valve 220 variants. potentially considered may be the Quake 3 and Valve 400 variants (may need a more expressive map format eventually, also want polygon-mesh geometry and a few other features, which would be a hack with entities).

most models currently use the AC3D file format (and a hack to apply skeletons/animations to it), but IQM is interesting (may look into adding support). it also has load-only support for SMD (just my modeling tools can't currently create/save SMD though...).


well, it doesn't use QuakeC though, rather a custom scripting language more closely related to ActionScript3 (with elements from several other languages). actually, a larger portion of the total codebase is related to the scripting VM (I only really started the "game-engine" part around Jan 2011, building on my prior VM and 3D modeling tools project).

most of the engine code is shared with my 3D modeling/animation/mapping tools. however, mapping is more done with QuArK as it has a more usable UI (full-3D mapping was not such a good idea...). eventually, I may go and rip off the UI design from Hammer Editor or something...


(I didn't really emulate Quake at the server/script level, but many things are still "similar").

currently, mostly scripts are direct-loaded from source files (binary bytecode serialization exists, but isn't really used at present). also, it is possible to interactively enter code in the console.

engine also has, but doesn't currently use, rigid body physics (custom physics engine, but using Bullet or ODE has come up as a thought a few times).


or such...

sorry for the bump...

but, yeah, after getting the Xonotic project downloaded and actually looking at its files some, it is likely the case that it would require a fair amount of work to get my engine to work with it (would have to implement a fair number of features, and I had approached a number of things in different ways), so never-mind. also, I have doubts that doing so would be worthwhile (neither partly would likely benefit).


however, I might borrow some of the data files for my own project if no one minds.

note: my project differs notably in that it focuses more on single-player gameplay (the plan is for a story-driven single-player FPS game, more like HL2 in these regards, but this is a long/difficult project for a lone developer). also, for now, it is also much more of an engine-project than a proper game project.


also, I give my regards to the people who made Xonotic, for actually doing a fairly impressive job.
the game looks fairly good.

hehe I suspect some people on this forum were waiting for you to realize that implementing your engine would not really benefit either party...

As for the borrowing of data files I assume it should be ok PROVIDED you release (if you release anything) the data you used including derivative works under GPLv2, as this game is entirely licensed under GPLv2. Any other usage would have to be expressly allowed (re-licensed) to you by the original author, if I am not mistaken.

well, I will use my own engine for my own project, mostly because I have more freedom this way, and prefer to use the MIT license (similar to the BSD license) for my own code.

MIT and GPL are compatible though (just, each has different definitions of "freedom").
for example, MIT also allows closed-source commercial use, which the GPL does not.
there are merits either way, just my view is that the GPL is a little heavy handed in this regard.

as for GPL with data, I already have a bunch of GPL'ed data files, so I am more or less stuck with it for now WRT data, unless I go and personally remake all of the files, which is a problem (my art skills are teh suck...). however, it is unclear how using GPL on data files exactly relates to the engine, since neither is "linked" with the other, it is possible that GPL'ed data, the "GPL stickiness", may not apply to the engine.


now, as for observed incompatibilities (between my engine and Xonotic):

my engine does not currently support the Quake3 map variant (used by Xonotic).
however, apart from supporting patches, this shouldn't be drastic (Quake3 map files are not otherwise notably different from Quake2 map files).

there are presently no 3D model formats in common (could be addressed).

each uses different shader systems, where I use per-texture shader files with a different format:
"<texturename>_info.txt" which is a line-oriented text file.

Xonotic makes non-trivial use of QuakeC (much expanded/changed since the stock Quake), which is not supported by my engine. unless I went and either wrote an interpreter for the "progs.dat" bytecode, or a hacked parser to feed QuakeC source into my existing scripting VM, nevermind likely architectural mismatches between the codes' assumptions and the underlying engine. (I would not ask people here to drop this code for such a trivial reason...).


internally, my engine is "not much like" the Quake-series engines, but had allowed map compatibility by faking it mostly at the level of the entities (thus far me mostly using the released Quake 1 maps for reference).

me having to basically re-implement the Quake engine's entity-mechanics from the ground up, still leading to edge case behavioral issues with some entities: func_door, func_train, func_plat, ... (lots of little edge cases in certain maps where things just don't exactly work correctly).

actually, the entity system is more a mix of the stock Quake 1 and 2 entities (more using Quake 1's spawnflags though), with a lot of other entities being more like those in the Source engine ("info_landmark", ...).

also, obvious things, like it is not network compatible with the other engines, ...

...

how does your engine compare to xonotic visually? (that is, if you used xonotic art)

I'm just curious.

I was trying this already, basically working on porting over some of the textures and maps, ... and making things work with my engine.

sadly, things look a good deal worse on my engine, especially due to lighting:
the Xonotic maps seem to be designed very much for radiant lighting, and the use of direct lighting and stencil shadows creates some big ugly pitch-black shadows.

the main issue is: my engine does its lighting in real-time, and there is no good way I am aware of (at this point in time) to do real-time radiant lighting for non-trivial scenes.


games like Doom 3 generally addressed this by having a number of "detail" lights placed around the scene, basically one places small light sources in/near the shadows to make them less dark (never-mind that Doom 3 was mostly pitch-black anyways, since at the time it was a strain making this sort of lighting strategy work in the first place).

the Unreal Engine and the Source Engine generally adopt a compromise, where static light-sources are handled using light-maps, and any dynamic lights/shadows are a "special effect".

this looks a little nicer, is higher performance, and avoids needing so many detail lights, but the problem is that this forces the scene to be largely static, as well as often introducing a lot of subtle visual glitches that have to be hacked around.

"Rage" / idTech5 is apparently using a different lighting strategy (based on Shadow Mapping and giant "streamed" texture-maps), which I may need to see how well this works and looks.


in my case, the lighting issues could be mostly addressed via the addition of detail lights (and either optimizing or getting rid of huge "sun" lights, which sadly do bad things to the framerate).

sadly, there are other plenty of other drawbacks as well at the moment.


as noted, I don't expect my engine to be usable as a drop-in replacement for DarkPlaces.

or such...

---

note: radiant lighting = radiosity, direct lighting = direct illumination, in case anyone was checking in a search engine...

a random idea I just had:
a "possible" idea could be to have an algorithm infer how much radiant light there would be in a given area from a given light source, and if it is above a certain amount, then the engine could insert a "proxy" light-source to compensate (essentially, having the engine automatically insert its own detail lights...). still thinking here of a good way to try to do this in real-time without risking introducing other artifacts.

one possibility:
if a sufficiently large amount of light hits a given surface, it will spawn a temporary "proxy" light source to "reflect" some of this (this may require some amount antiportal culling or similar).

granted, my prior status still stands, as a good deal more work would still be needed.

or such...

The darkplaces engine is similar to the Source engine in the lighting sector. A lightmap is generated in netRadiant, and then other light sources are calculated in realtime. Weapons and projectiles have automatic realtime light sources assigned to them and a mapper can place realtime lights on the map from inside the Darkplaces engine. As it is, any realtime light source in Darkplaces has a serious impact on performance, multiplied by the number of shaders being used on a single fragment.

yes, this is pretty much what I figured was going on, given what I could see in the engine.
DarkPlaces uses a premade lightmap, for both its benefits (high quality and good framerate), and its drawbacks: dynamic lighting is more expensive and the scene is less dynamic.


my engine, OTOH, doesn't use any lightmaps: everything is dynamic lighting.
this comes at a cost: one cost being framerate, and another being big ugly shadows unless maps use detail lighting (and, also, the positioning/intensity/... of lights may noticeably impact framerate).

as-is, all this is a bit problematic for the Xonotic maps.


granted, I didn't up-front decide "hell, I am going to write a 3D game engine using real-time lighting and stencil shadows", but originally I intended it just as a mapper (more as a pre-visualization feature, and because mappers need to be able to readily alter geometry), but computers got fast enough that using my mapper's renderer as a game-style renderer stopped seeming nearly so implausible (although in a quality/performance tradeoff sense, the technology is still a little weak).

another factor was me having previously discovered fast algos for BSP rebuilding.

actually, I have little idea what motivated id to use the technology in Doom 3.
any why do I use it?... hmm... I think because I am lazy (most other options seem like more effort).

it is more funny when my original opinion of Doom 3 was more like "I can't see crap, it is too dark, these monsters are annoying, and HL2 looks nicer...".


well, all is tradeoffs...

---

add: a few quick per-map performance stats.

dance: 15-35 fps (with asymmetric sun, depending on view angle, consistent ~ 25 fps if sun is placed directly overhead, and FWIW this avoids a huge black shadow on one side of the map, but smaller ugly black shadows remain).
g-23 and glowplant: unusable (< 10 fps), I suspect due to lots of huge-intensity light sources (light>1000 all over the place).
red-planet: ~ 50-60 fps, but much of the map is missing (engine ignores patches).
space-elevator: 30-60 fps (but looks strange, probably due to shader/texture issues).
stormkeep: crashes in BSP code (can't load, unsure of reason).
nexballarena: 50-60 fps.

currently, the texturing is fairly kludged (my engine uses a different texture/shader system).

another add:
was working on adding proper support for patches (rather than skipping them);
while I was at it, I also added support for Doom3 style brushes (brushDef3), which should potentially allow basic Doom3-style map compatibility (nevermind textures/shaders/entities/... issues);
did as a partial test go and make a modified version of dance.map with some detail lights added, and these help greatly WRT it not looking like crap;
also, trying to fix up other issues (using opaque and nodraw geometry on the same brush / ... also does not make my engine entirely happy), ...

or such...

misc: added a few screen shots here (using "dance.map"):
http://cr88192.dyndns.org/wiki/index.php/BGBTech_Shots

so, one can see just how much like crap this looks, and my attempts to add bezier patch support (beat on them for several days, still not succeeded in making them work correctly or look nice).

update: figured it out, got bezier patches to look less terrible... partly it was a misunderstanding as to how exactly they were supposed to work, combined with subtle mathematical issues (made drastic alterations to tessellation code).
another more subtle feature (added since the shots earlier): patches are now solid (added support for them in the "server" end). however, physics is done against the pre-tesselation geometry (may impact what is/is-not solid).