General engine wish list

[fromhell]

I don't know where else to put this, but there are things I wish for in general

Client:
- Build switch to allow Win95 compatibility again (no PSAPI, restored old network code and no document home path)
- Restore console startup window on Win32
- Fix SDL input sluggishness (see: Darkplaces-sdl for how to do SDL right)
- Allow sound playback to be interrupted (such as pre-1.27g)
- Switchable announcer voice via client so it'll work in other mods (also important for future localization support)
- MME fx particle system (moving cg_leiEnhancement to r_leiEnhancement for improved versatility and performance)

Renderer:
- Loading of DDS images (supporting the special dmmq3 maps) (DONE-ish.  Some textures do still fail to load but for the most part it's working. Hardware support only.) Not yet done in the Git tree.
- GLSL-based color control so overbrights work in a window, so we can finally kill all those "the game is too dark" excuses. I believe the opengl2 renderer does this already. (Done with a polygon blend, as well as by shader as an option)
- Default textures for map textures (defaultMapTexture) and models (defaultModelTexture) and everything else like 2d elements (defaultTexture). That white black square is a grating placeholder. done
- An option for simpler flare testing (for performance) (DONE - r_flareQuality 0 makes oa_pvomit perform in the three digits without losing flares)
- Gamma control in a window (DONE - fragment shaders required)
- Performance enhancements for MDR models, like using hardware transform & lighting (Geforce256/Radeon7x00), vertex shaders (GF3/R200), or something
- Dynamic lighting in vertex light mode


Renderer - new features for content:
- Parse the string in q3map_flare to actually load and use the said defined shader, pass that to tr_flares.c and use it (Done)
- proper world space tcGen environment (like Elite Force and Q3Revolution) (Done, thanks to the JO source release - implemented as 'tcGen environmentWater')
- tcMod Atlas
- tcMod atlasalpha, which will pick a frame based on the texture alpha instead of it being a looping sequence. This is to get around certain video cards' lack of alpha modulation (Rage Pro, S3 ViRGE)
- skipbias shader parameter, which just skips drawing the polys completely when at a distance from viewer, could be very useful for vegetation details

Renderer - legacy fallbacks:
- Software rendering via a touched up TinyGL that supports at the least vertex coloring and alpha test
- Reimplement 'alphahack' for PowerVR PCX2, Matrox MGA and S3 ViRGE - generate alpha channels for all additive and subtractive shader textures; remove alpha channels from textures of non-transparent map surfaces (like tinfx stuff)

UI (not q3_ui):
- 16:9/16:10 scale and alignment support (instead of stretching 640x480 to 1920x1080 it'd be centered, stretched with correct aspect, and allowing coords beyond the strict 640x480 space so the UI can 'fit' in HD, and this would also make the UI model drawing elements maintain perspective consistency better) (Done)
- Somehow allow the 'team heads' to be selectable (as in the heads defined for missionpack, and not a mix-match for every head ever) Not supported

[sago007]

- An optimistic culling algorithm instead of (or as an alternative to) the conservative culling algorithm. The vis-thing is putting limitations on map design.
- I find the FreeType in UI interresting although I doubt that it will look very good and translations has been added to NOTTODO (wasn't translations a goal for 3.0 at some point?)

- Loading of DDS images (supporting the special dmmq3 maps)

I don't know much about this. It this https://bugzilla.icculus.org/show_bug.cgi?id=5442 relevant?

UI:
- 16:9/16:10 scale and alignment support (instead of stretching 640x480 to 1920x1080 it'd be centered, stretched with correct aspect, and allowing coords beyond the strict 640x480 space so the UI can 'fit' in HD, and this would also make the UI model drawing elements maintain perspective consistency better)

I think this is controlled by the game code. There are multiple scaling functions. I think there are missing some drawing routines that can draw at relative locations (like from the left, center at).

[fromhell]

I don't know much about this. It this https://bugzilla.icculus.org/show_bug.cgi?id=5442 relevant?

Yep, though the decoding part should never be included - instead the Darkplaces software decoding should be used since it's patent free and does it differently
ideally since DDS textures are typically huge, the software decoding would probably be done in half resolution for mip consistency

[grey matter]

- Build switch to allow Win95 compatibility again (no PSAPI or enforced document homepath)

Heck, no! Those should never see the daylight again, let alone connect to the internet (via IPv6 ). KernelEx should be the maximum handstand.

- Fix SDL input sluggishness (see: Darkplaces-sdl for how to do SDL right)

I have no problems with SDL. On the contrary, my mouse is seriously broken in id Quake 3 1.32c (this being on a Linux system). Instead of spreading FUD, you should file proper bug reports.

- Somehow allow the 'team heads' to be selectable (as in the heads defined for missionpack, and not a mix-match for every head ever)

I don't know what's special about the missionpack heads, but this is most likely gamecode, not engine. Are we just talking about a GUI for the headmodel and team_headmodel cvars here?

UI:
- 16:9/16:10 scale and alignment support (instead of stretching 640x480 to 1920x1080 it'd be centered, stretched with correct aspect, and allowing coords beyond the strict 640x480 space so the UI can 'fit' in HD, and this would also make the UI model drawing elements maintain perspective consistency better)

I think this is controlled by the game code. There are multiple scaling functions. I think there are missing some drawing routines that can draw at relative locations (like from the left, center at).

This is indeed mostly gamecode (also see the multiple same questions in ioquake3 forum and bugtracker, rftm). While you're at it, don't forget to fix the crosshair being stretched.

[Neon_Knight]

- Fix SDL input sluggishness (see: Darkplaces-sdl for how to do SDL right)

I have no problems with SDL. On the contrary, my mouse is seriously broken in id Quake 3 1.32c (this being on a Linux system). Instead of spreading FUD, you should file proper bug reports.

You weren't around at the time of each and every single of the SDL complaints circa 0.76/0.7.7.

[hairball]

- Fix SDL input sluggishness (see: Darkplaces-sdl for how to do SDL right)

I have no problems with SDL. On the contrary, my mouse is seriously broken in id Quake 3 1.32c (this being on a Linux system). Instead of spreading FUD, you should file proper bug reports.

I have heard of this complaint too in other games like UrT.  I think the complaints are usually for Windows so you may not have experienced it if you use Linux.  I don't think I ever had a problem in Linux with ioquake3/SDL other than at one point the resolution selection was messed up.  That has long since been fixed for me.

I think it may be a problem on older SDL releases.  I have tried the openarena_engine in github on Windows and it feels fine to me.  It feels fine in Linux too.  It feels even better if you enable the QuakeLive sensitivity settings

Edit: Also, they are in the middle of upgrading to SDL 1.2.15.  zakk added mac support and changed all of the includes.  Hopefully they update all the other platforms. -_-

[Gig]

Seeing that crosshair has been mentioned..

When I asked for it, someone said it's engine, someone said it's gamecode... I don't know, anyway it would be nice to have the crosshair shown when using r_anaglyphMode (DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Stereoscopic_view]stereoscopic view).

By the way... wiki pages that may be related with this thread (and that may be updated with things from this thread, maybe):
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Wishlist
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Bugs

[fromhell]

By UI I was referring to the Missionpack UI. That has its own stretch functions and it's not related to cgame (cgame's where the traditional hud and crosshair stuff is at)

- Fix SDL input sluggishness (see: Darkplaces-sdl for how to do SDL right)

I have no problems with SDL. On the contrary, my mouse is seriously broken in id Quake 3 1.32c (this being on a Linux system). Instead of spreading FUD, you should file proper bug reports.

The trick is to issue a zero sleep.

[Gig]

Another thing (probably the solution would be a very small gamecode change, anyway I write it here because it's a rendered-related feature!):

Geometric detail: I've seen that it is possible to set r_subdivisions to 1 or to 0, other than its "classic" values (4=high -default-, 12=medium, 20=low). And curves actually look better than with "classic" high quality (e.g. wrackdm17 shotgun platforms, over the jump-pads).
This means that is easily possible to get better quality from the game (when looking at Bezier curves, I suppose), without the need to change anything in the engine. What do you think about adding a "very high" geometric detail option to the GUI (linked to r_subdivisions 0 or 1), to make this available to all users and do not cause anymore r_subdivisions to be reverted to a lower quality (higher number) the first time the user will apply any kind of change in the "graphics" menu?

See also: (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Geometric_detail

Question: is the "geometric detail" in the GUI related also to some other cvar, other than r_subdivisions?

[fromhell]

Question: is the "geometric detail" in the GUI related also to some other cvar, other than r_subdivisions?

yes, r_lodbias which controls the bias distance of LOD meshes

If I do missionpack UI i'll have all sorts of options exposed in the menus, like 16x anisotropy which is oddly omitted in the q3_ui...

now you're getting more into the trivial 'add menu options' wishlist rather...

[Gig]

Question: is the "geometric detail" in the GUI related also to some other cvar, other than r_subdivisions?

yes, r_lodbias which controls the bias distance of LOD meshes

Sorry for being a little "OT", if it is... I'm interested into understanding better what that r_lodbias is.
Searching the net for "lod bias", somewhere someone said it controls the distance at which a lower-quality model of an object is shown.
But in this page http://www.planetquake3.net/tweak/lod_benchmark.html (quite old, about 3dfx, but however q3-specific) it says "L.O.D. bias" changes texture quality (from sharper to smoother), and even suggests to set it to negative values. Maybe he was referring to something different? In that page he does not mention r_lodbias, but there is a place where he mentions r_picmip (texture detail); but in OpenArena negative r_picmip values are not allowed at all (I can't check in Q3 now).

Doing some quick tests in OA, I can see that setting geometric detail to "high" sets r_lodbias to 0, while setting it to "medium" or "low" sets it to 1. I don't notice differences in texture quality by changing r_lodbias, but I can notice that, with it set to 1, some weapons (it seems not all... however, an example is the shotgun) in my hand are drawn using less triangles (with lower quality); if I set it to 2 (or more), even less triangles are used and the weapon looks bad.
Looking at the "bubbles" of health bonuses in the arena, instead... I can notice that r_lodbias influences them, too. If I set it to 2, they look "low polys" even when I am next to them... if I set it to -1, they are still shown in "high polys" also at the distance where they usually switch to the low polygons mode at the default value, 0.
I suppose a future "very high" geometric detail quality may set it to -1 or similar, too... what do you think about it? Okay, maybe it's stuff for another thread...

Anyway, what do you think about that page I linked? That guy made some confusion with texture detail and lodbias, maybe? But where his negative values would come from, in that case?

PS: I tried to explain DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Geometric_detail]here what those settings do... would you like to fix it, if I did errors? Thank you!

[fromhell]

But in this page http://www.planetquake3.net/tweak/lod_benchmark.html (quite old, about 3dfx, but however q3-specific) it says "L.O.D. bias" changes texture quality (from sharper to smoother), and even suggests to set it to negative values. Maybe he was referring to something different? In that page he does not mention r_lodbias, but there is a place where he mentions r_picmip (texture detail); but in OpenArena negative r_picmip values are not allowed at all (I can't check in Q3 now).

That guy doesn't know what he's talking about.

I already explained what r_lodbias does. Also I have to produce the LOD meshes by hand btw so it's not automatic reduction

[Gig]

Consider that I'm not too much into how a renderer works.
I suppose "LOD" means "level of detail":
From Wikipedia: http://en.wikipedia.org/wiki/Level_of_detail

In computer graphics, accounting for level of detail involves decreasing the complexity of a 3D object representation as it moves away from the viewer or according other metrics such as object importance, eye-space speed or position

... thus the variable controls the distance at which the engine switches from using an low-detail model to a high-detail model (or vice versa), to save resources or to give better looking. And it affects some items only because you created low-detail models only for part of them. Summed up right?

[fromhell]

I did update the wish list.

[WaspKiller]

...What do you think about adding a "very high" geometric detail option to the GUI (linked to r_subdivisions 0 or 1), to make this available to all users and do not cause anymore r_subdivisions to be reverted to a lower quality (higher number) the first time the user will apply any kind of change in the "graphics" menu?

Gig, first time I am reading this thread and I have no issue with anything you wrote unless you are advocating that r_subdivisions be locked to 1 or 0.  I don't think that is what you implied but I want to make sure that if anyone has that thought that it be banished.

It may not matter to baseoa but having r_subdivisions set to 20 is advantageous (and one of the recommended settings) in Excessive Plus because surface imperfections are more visible and are the starting point of our BFG/Rocket/Nade and Rail slides.

Unlike other Mods, we use our weapons as much for locomotion as for fragging**.  Any crack, corner, bas relief, sunk relief, etc, is a point for planned or impromptu slides.


** That's why it's easy to spot the noobs in E+.  They are the ones always walking, running, bunnyhopping, and even multi-jumping.

[Gig]

Gig, first time I am reading this thread and I have no issue with anything you wrote unless you are advocating that r_subdivisions be locked to 1 or 0.  I don't think that is what you implied but I want to make sure that if anyone has that thought that it be banished.

Don't worry, Killer. I was absolutely not saying to place further limits to the option (by the way, the current DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Graphic_options#Geometric_detail]r_subdivisions 20 limit is from videoflags).

I was talking about allowing an additional value for the menu option in the GUI. At the moment, we have "low" (that uses the r_subdivisions you like, 20), "medium" and "high". I suggest to add a fourth value, "very high", that would set r_subdivisions and r_lodbias to achieve better quality than with "high". It would make the game look better without having to invent new ideas in the engine, but using something that is already there but is hidden. At the moment, the user can set that better quality only by using the console, and that setting will be lost the first time you will change anything from the "graphics" menu. I suppose a little change in the GUI should be good.
It would not prevent you from setting "low" value.

PS: "Nade and Rail slides"? What's this Excessive Plus' "Sliding"? A sort of enhanced plasma/bfg/etc climbing? Why don't you add sections DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Mods/Excessive_Plus]here explaining main E+ specific features (physics, weapons, etc)?

[fromhell]

r_subdivisions can do negatives, FYI, but it's not much difference. r_showtris 1 should reveal how messy it'll get.

[Gig]

Probably, when I did those test, noticed that r_subdivisions works with negative values, too. But I did not try to check with r_showtris 1. Anyway, I didn't notice further difference while setting it to negative values... while I noticed a visible difference (checked with curves in wrackdm17 platforms) while setting it to any value lower than the one set by "high" option (that sets it to 4), so I came up with the idea of a menu value "very high" that would set it to 0 (or to 1, if 0 is too messy) (and that should also affect r_lodbias to show the detailed version of a model at a longer distance).

[WaspKiller]

...Why don't you add sections DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Mods/Excessive_Plus]here explaining main E+ specific features (physics, weapons, etc)?

I am the one who edited most of that page, however, you have to know when to stop before you overwhelm a player who is simply looking for a wiki definition of "What is Excessive Plus?"

--------------------------------------------------------------------------

...PS: "Nade and Rail slides"? What's this Excessive Plus' "Sliding"? A sort of enhanced plasma/bfg/etc climbing?...

The best way to explain E+ slides is via demo.  The following 2 minute video breaks it down into its basic parts in a slow controlled manner.

http://oa.goquake.com/servers/basic_ep_movements.flv


This next 2 minute video shows it in real-time:

http://oa.goquake.com/servers/fast-flag-caps.flv


These videos can be viewing via your browser at http://oa.goquake.com if you prefer not to manually download and view these.


--------------------------------------------------------------------------


Fromhell, I was unable to embed an SWF into the post.  Either you have not enabled it (...Admin > Posts and Topics > Embed flash into posts) or you do not want it enabled in which case you can and probably should remove the icon.

[son_goku2]

- An optimistic culling algorithm instead of (or as an alternative to) the conservative culling algorithm. The vis-thing is putting limitations on map design.

Portal rendering. Portal rendering is what unreal 1 & 2, max payne, source engine, doom 3, and other games do. It's much less time consuming to place a portal on a window or doorway than to place a lot of hint brushes. Even Crysis had them.

Or drop PVS and use a buffer to determine visibility in realtime like http://www.umbrasoftware.com/ That's what unreal engine 3, cryengine, killzone, and other games are using now. But then, dynamic visility is much harder to do, who is gonna do it?

[fromhell]

During development Quake used to have portals for traversing but it was slower. Then again Quake was weird, software only, had surfacecaches, etc.  This was never approached in their GL version.

[Neon_Knight]

And their maps broke each and every single map development rule.
It's crazy how nowadays there're strict, non-flexible rules for mapping to follow, when the people who mapped for the company which did the engine itself violated them at many points.

[Suicizer]

And their maps broke each and every single map development rule.
It's crazy how nowadays there're strict, non-flexible rules for mapping to follow, when the people who mapped for the company which did the ngine itself violated them

Violated on what grounds?

Well, as most things, it has to be tested first so mistakes can be whipped out and  people actually learn how it should be done. Quake 1 is a good example of that.

[Neon_Knight]

I'm talking about the technical side.
Word from the era where the Q1DM maps were introduced in 0.7.0 said that it was a lot of pain to work with those maps as they had overlapping brushes (leading to glitches) and bad brushwork in general.

[fromhell]

- MME fx particle system (moving cg_leiEnhancement to r_leiEnhancement for improved versatility and performance)

I did attempt to port this but ran into errors on even things as simple as structs. Also, it's an engine client feature, not renderer.    The FX code can be found in here btw.