Pages: 1 2 [3]
  Print  
Author Topic: General engine wish list  (Read 35893 times)
Gig
In the year 3000
***

Cakes 45
Posts: 4386


WWW
« Reply #50 on: April 05, 2014, 04:16:24 AM »

About the way to distinguish whether it's fog, water, water+fog, lava, etc.... If the shader itself is missing, you cannot just read it surfaceparms from the shader file... I suppose in that case you will somehow read the properties that q3map/q3map2 stored into the .bsp file, right?
A few surfaceparms are however considered during game run-time instead of during map compile time[1]... how to manage them? For surfaceparm nomarks, I can guess your tweak may presume if the surface is water, lava or slime, that it should have "surfaceparm nomarks"... but for other parameters, I don't know.

[1] I remember I noticed this with "surfaceparm nomarks": you can add or remove it without having to recompile the map to see the change.
Side note: water shaders only show marks where water depth is smaller than X units. I can guess for future OA versions, we should fix existing water shaders to add "surfaceparm nomarks" to those which currently don't have it.

PS: Don't forget to make a cvar to enable or disable this (smart) feature.  Wink

PPS: Maybe, for "standard" missing textures (which are not models, sky, water, etc.), one may read if the filename contains "red" or "blue" character sequence, and then use slightly red-toned or blue-toned variants of the "generic rock" texture? Uhm... maybe that may become too random...
However you may do tests with DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Map_compatibility]maps which lack many textures and look at the results...
« Last Edit: April 05, 2014, 04:28:52 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #51 on: April 05, 2014, 04:20:33 PM »

Also, some textures just can't be avoided, such as the CTF-specific textures, for base recognition. We already have the replacements for the base arrows, which became pretty common post-TA (especially thanks to the Threewave packs) but some base-specific deco must still be made by hand.
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #52 on: April 05, 2014, 04:58:37 PM »

OK Gig, i'll take this feature out too. You convinced me how important it is to leave glowing white squares in every map OA isn't compatible with.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #53 on: June 07, 2014, 06:33:58 PM »

I'm porting Quake3MME's FX system over now (the fx_ files placed after huffman.o in the makefile).  It is in the github engine, it's not linked in the makefile yet and I'm getting a crapload of errors with the header that i'm lost on what is causing it.


Unlike MME I do plan to have the FX scripts triggered just by sounds and models rather than cgame hooks so the compatibility can still remain.
« Last Edit: June 07, 2014, 06:36:05 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
SharpestTool
Lesser Nub


Cakes -27
Posts: 143


« Reply #54 on: June 08, 2014, 10:46:01 PM »

This of course brings up two other discussions...one I'd like not address GPL v3  versus V2, but RTCW introduced a trap-call "trap_getTag" into the game logic.  What this allowed for was easy implementation of location based damage.   

If a feature such as this was introduced into the engine it would open up a whole new dimension of game play...."BOOM Headshot!"

It would also mean many models would have to be reworked as their tag-head/tag-torso locations are in weird spots visually.  I think fromhell (fromhell) mentioned this about Angelyss a long time ago.

Currently the only other way to do the locational damage is really code heavy in the logic like Smoking Guns, ET:NoQuarter (which borrows the code from Bani's ETPro). Whereby the models are all essentially reparsed/reloaded in the game logic so their coordinates are accessible for hit detection.  this means a lot of hacking up the header files, ballooning the memory the server would use and at the end of the day the models would still have to be reworked to be visually correct.

but just a thought...iortcw did get qvms working again, fixing one of Hacktivisions major bastardizations of the multiplayer component.  Among other things they screwed up shader parsing in an effort to cache them to speed level loads.   Its why the same maps on essentially the same engine never looked the same.    BUT...think of the AI for single player missions that would be accessible...
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #55 on: June 09, 2014, 02:12:28 AM »

if I'm ever integrating 'headshots', it would be purely a clientside cosmetic with no effect to balance,    and I do not think scavenging RTCW sources would be necessary for it.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #56 on: June 09, 2014, 05:18:37 AM »

Playermodel bounds should not matter for hit detection, as the rest of the game uses uniform hitboxes for all playermodels.
Some Quake 3 mods implemented headshots by splitting the hitboxes into e.g. upper third and claiming a shot into it would be a headshot, no matter whether the playermodel actually has its head right there.
Logged

This space is for rent.
Gig
In the year 3000
***

Cakes 45
Posts: 4386


WWW
« Reply #57 on: June 10, 2014, 12:21:48 AM »

I don't remember which license is q3mme under...
However, a couple of links about oamme by biox1dE:
http://openarena.ws/board/index.php?topic=4117.0
http://oa-chs.warsforum.com/t75-oamme-openarena-movie-maker-s-edition
(Was it done by reverse engineering q3mme? I don't remember...)

About damage location, I think it's DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/NOTTODO]NOTTODO area (sounds more adapt for a mod). Maybe one may decide to implement it like a few Q3 mods did, but it should remain an optional feature disabled by default in baseoa.
Also, as Unlagged mod documentation shows in these screenshots (thanks to its cg_drawbbox command), Q3 models placement inside their hitboxes was quite variable (during some animations, the player model appeared almost completely outside from its hitbox!)... I have no idea if OA models do suffer of this problem to the same degree or less.
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #58 on: June 10, 2014, 01:33:53 AM »

I don't remember which license is q3mme under...
GPLv2 engine source is available on sourceforge.
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4386


WWW
« Reply #59 on: June 10, 2014, 02:20:18 AM »

Thank you. It looks like someone already posted it before, and I just forgot about it (I just noticed that link is already mentioned DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Manual/Demos]here in the wiki, I added it last September).
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
SharpestTool
Lesser Nub


Cakes -27
Posts: 143


« Reply #60 on: July 02, 2014, 12:24:30 AM »


About damage location, I think it's DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/NOTTODO]NOTTODO area (sounds more adapt for a mod). Maybe one may decide to implement it like a few Q3 mods did, but it should remain an optional feature disabled by default in baseoa.

That's why I contributed to OAX in the first place, so servers wouldn't have to run all their crazy 10 year old, not updated anymore or closed source quake 3 mods.

And because I'm on a phone so I can't quote the post...to fromhell/fromhell's comment about rtcw sources....I noted that it wouldn't be necessary either, just more efficient from a code perspective    Smokin Guns has the game module reparse all the player models again to create the hit boxes (they are already parsed by the renderer/client subsystem in the engine).  The thing RTCW does is just add a trap call from the game module to the engine so the engine with a return value of which model tag the shot intersected with.

Again, in both cases it would require models to be reworked so tag_head is actually at the head as displayed---and it is a lot of work.

Adding trap calls or messing with any of the structs in q_shared typically breaks the compatibility with all the other old mods anyhow--Although it would be nice to have playerState_t and entityState_t to be 32-bit instead of 16.  Does anyone know if this would break old mod compatibility if we changed the engine to use Msg_WriteLong for these instead? I'm not sure it would/would not.  Nor do I have two hours recompiling the source on Windows to do so...or the 6+ hours to repartition and dual boot 'Nix.   Any indicators whether or,not this would work?
Logged
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #61 on: July 02, 2014, 03:16:59 PM »

Although it would be nice to have playerState_t and entityState_t to be 32-bit instead of 16.  Does anyone know if this would break old mod compatibility if we changed the engine to use Msg_WriteLong for these instead?
playerState_t and entityState_t are structs, both larger than 16 bits (pointers to them are not transmitted). Any surrounding struct will change size if you adjust any of the two and thus most likely cause desync or crashes.
Logged

This space is for rent.
SharpestTool
Lesser Nub


Cakes -27
Posts: 143


« Reply #62 on: July 07, 2014, 03:20:38 AM »

Although it would be nice to have playerState_t and entityState_t to be 32-bit instead of 16.  Does anyone know if this would break old mod compatibility if we changed the engine to use Msg_WriteLong for these instead?
playerState_t and entityState_t are structs, both larger than 16 bits (pointers to them are not transmitted). Any surrounding struct will change size if you adjust any of the two and thus most likely cause desync or crashes.

I should have rephrased...
playerState_t->persistant[]
playerState_t->stats[]
playerState_t->powerups[]
playerState_t->ammo[]

Now you are correct, it does crash.  When you modify msg.c to use MSG_WriteLong and to write the above integer arrays as 32 bits, you have to modify the corresponding read calls as well to use MSG_ReadLong. 

I suspect we could dual code this...
Use a cvar like sv_legacyMod.
When set to one, it codes these as 16-bits.
When set to 0, it codes them as 32-bits.

Old mods we can't update would work just fine.  New mods, wouldn't be limited by just 16 stupid bits.

The server would send this cvar to the client during the initial connection phases. 

Logged
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #63 on: July 07, 2014, 04:05:15 PM »

Whenever I need some additional bits, I just stuff them into (the high bits of/unused) fields. This is not a very clean (could use macros for access to make it somewhat readable) or nice solution, but it works if you do not need space for that many values Smiley
Most of the time you can get away with restricting yourself to a char instead of a full int as well.
Logged

This space is for rent.
special
EXTREMELY SUSPICIOUS TROLL
Nub


Cakes -64556
Posts: 12



« Reply #64 on: September 03, 2014, 07:49:33 PM »

heres a wish. delete your engine.
Logged
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #65 on: September 04, 2014, 12:29:52 PM »

I know it's a no-no in the general forum netiquette of the Internet to answer to a troll, but...
heres a wish. delete your engine.
Do us a favor and get a goddamn life. =)
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #66 on: September 06, 2014, 07:36:23 PM »

Added lightingSpecularDiffuse and removed r_shadeMode because I couldn't reallly go far with different shading models. Not even my 'lame' diffuse shading was any faster on P2 300 and I never got multiple light sources to work from the lightgrid.

There's probably a change i'll return to that idea in the future though but anyway lightingSpecularDiffuse is intended to replace my 'second stage specular pass' method which takes a bit of fillrate and also works in vertexlight mode.  However it expects overbrights to work, and disables itself if there's no overbrights available or if r_shadeSpecular is set to 0 (falls back to normal lightingDiffuse). It's intended to make OA3's guns and players shiny with less overhead of also having alphaGen lightingSpecular, blending a stage, etc.


I also added tcgen environmentWater since it's a direct import of the environmentmapping code from JK2 (which may be directly inherited from Star Trek Voyager Elite Force) and has some coords set differently which is more than appropriate for use on water surfaces to make fake reflections.  The viewmodel reflection stuff is still left in there so the old 'gun gleam' can still be made from it.
« Last Edit: September 06, 2014, 08:44:43 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4386


WWW
« Reply #67 on: September 07, 2014, 05:57:44 AM »

New water effects, you mean? Interesting.  I'd like a screenshot or a video. :-)
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Pages: 1 2 [3]
  Print  
 
Jump to: