View previous topic :: View next topic |
Author |
Message |
Chip

Joined: 21 Jan 2009 Posts: 314 Location: Romania
|
Posted: Sun Jan 03, 2010 8:33 pm Post subject: |
|
|
Quote: | The real question I have is what does someone have to do in 2010 to have a smokey fire or a steam vent (Nehahra?) in a "good" engine like DarkPlaces or FTE? Shouldn't someone write a QuakeC tutorial to have a non-boring world? |
I have smokey fire but it's build using DarkPlaces effectinfo and implemented in a (way too) crippled Kleshik mod. So I guess code examples and tutorial would benefit no one. _________________ My Projects: Quake 1 Mods | OpenQuartz 2 | ChipQuake |
|
Back to top |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Sun Jan 03, 2010 8:35 pm Post subject: |
|
|
Heck, how do you make a regular alphatest fence? Alphatest grass? Trees? Ladders?
And I still think alphatest textures is something the engine has been missing for a very long time, it should be part of the standard too. It's not a feature request though it sounds like one. Software can use this feature without trouble as well, so there's no real excuses for not supporting it. Textures defined by { prefix would denote a 1-bit alpha index texture. It has to be 1-bit alphatest, there's no sorting issues with those. I've only seen support for 8-bit alpha or nothing, which is quite annoying.
The Doom scene has been having Boom standards for a minimum support in most engines (the only major one that doesn't is Doomsday). That Boom standard was established in 1998, and look how well it's done for Doom's thriving community. It's about time we've had the same done for Quake. _________________
 |
|
Back to top |
|
 |
LordHavoc
Joined: 05 Nov 2004 Posts: 243 Location: western Oregon, USA
|
Posted: Sun Jan 03, 2010 9:26 pm Post subject: |
|
|
leileilol wrote: | And I still think alphatest textures is something the engine has been missing for a very long time, it should be part of the standard too. It's not a feature request though it sounds like one. Software can use this feature without trouble as well, so there's no real excuses for not supporting it. Textures defined by { prefix would denote a 1-bit alpha index texture. It has to be 1-bit alphatest, there's no sorting issues with those. |
Actually if you ever worked on the software renderer you would find that it is designed solely for opaque world surfaces, there is no zbuffering in the actual world rendering, so a lot of things that sound simple (like alphatest) are not at all simple, because it is only rendering the frontmost surface on any given segment of a scanline - to do alpha test or stippled alpha (or blending) of any kind requires deferring these frontmost surfaces for a later rendering pass with zbuffering...
Now I should mention that software Quake contains exactly one rendering path for alpha tested, perspective correct (like the walls) texturing - sprites.
If the transparent surfaces were sorted as normal but emit sprite-like rendering data whenever they do rise to the frontmost position in the rendering stack in the Sorted Edge Rasterizer portion of the surface renderer, then not only would alphatest or stipple be relatively easy to implement, but so would alpha blend and additive blend.
I should also mention that I wrote 16bit and 32bit color versions of the software quake renderer in quakeforge many years ago (but without the assembly code path), and these rendering paths are still maintained, with an upgrade to 16bit or 32bit color the full alpha/additive blending features become easy, except for the sorted edge rasterizer which remains a source of pain.
But to get back to the point - there is nothing easy in the software Quake renderer, it has a large mess of assembly code that most people don't want to touch (and if the assembly is disabled it performs worse), only very talented programmers succeed in adding these kinds of features to it. |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Sun Jan 03, 2010 10:07 pm Post subject: |
|
|
So... Technical discussions aside, back to the topic: it's time to bring more opinions from the rest of community (mappers, more modders, and even players) so we can gather a reasonable list of features to work. We need more people from Func_MgsBoard, QuakeOne, ModDB and others not so regular at this forums coming with their own lists to add material to discuss. And Spirit, I think this thread deserves a front page note, and even become sticky. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Urre

Joined: 05 Nov 2004 Posts: 1073 Location: Sweden
|
Posted: Sun Jan 03, 2010 11:08 pm Post subject: |
|
|
frag.machine wrote: | So... Technical discussions aside, back to the topic: it's time to bring more opinions from the rest of community (mappers, more modders, and even players) so we can gather a reasonable list of features to work. We need more people from Func_MgsBoard, QuakeOne, ModDB and others not so regular at this forums coming with their own lists to add material to discuss. And Spirit, I think this thread deserves a front page note, and even become sticky. |
Yes! But I think you're mixing this site up with Quaddicted. _________________ Look out for Twigboy |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Sun Jan 03, 2010 11:37 pm Post subject: |
|
|
I posted a link at func_.
Oh and Baker, nice shot  _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Mon Jan 04, 2010 1:03 am Post subject: |
|
|
IF we want a FOG standard, why not a WEATHER key for worldspawn with bitwise values. So I can get, FOG + RAIN + NIGHTTIME + LIGHTNING etc.. |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Mon Jan 04, 2010 1:09 am Post subject: |
|
|
Slightly off-topic to some, but entirely on-topic to me if the idea is engine standards for modding:
I wish engines would use the same name for the same feature:
Case in point:
Gamedir switching
DarkPlaces: gamedir
Quakeworld (all engines): gamedir
JoeQuake: gamedir
Qrack/ProQuake: gamedir
FitzQuake: game
I don't care if FitzQuake uses "game" but it would nice if it also supported "gamedir". It would be nice for there to be a single way for a readme to indicate this.
Yes -hipnotic and any other special "game" (Nehahra, the big list that DP supports, etc.) parameters represent an issue.
Helps in a mod readme.txt to not have to list multiple ways to do something trivial and widely supported.
Memory
I think -heapsize xxxxx is universal, but it would be nice if all the engines supported -mem. Although it would be better if a good universally functional memory manager tutorial existed and maybe MH's one does the trick. Still, lower resource platforms may not be a good match for such a memory manager.
I won't drifting into the whole "no command line" discussion.
Easily "Dedicating" an engine to a mod
For total conversions or standalone mods, it would be nice to be able to:
1. Specify the engine name (I notice in Makaqu there is an ini file) so the Window doesn't say "GLQuake" but might say "Solitude" or "Kurok" or "X-Men: Ravages of Apocalypse" or <insert mod here>.
2. Customize the menu stuffs easily. XML like Urre or someone said? And the "help screens". And not having the engine precache demon/dland.wav or other Quake specific stuff (Where is source for Tomaz GLQuake clean source? I guess ArQLite (site) is based off that ...)
Then again the whole sbar issue and CSQC crops up.
I'm sure DarkPlaces has ways to deal with all of this and -- well -- a major problem that always resurfaces is that I bet it isn't documented anywhere, but likely there is a mod that is open source and uses it except no one knows the name of the mod or where the download is because the site of whatever mod is dead and only lives on leileilol's hard drive.
And then there is what Spike said about video mode switching and related features that really shouldn't be stored in a config.cfg because they have nothing to do with the mod. Video mode, directinput, etc ... those aren't gamedir.
Standard Places for Stuff
Where do external skyboxes go ideally? gfx/env or what?
DP captures video to gamedir\video whereas JoeQuake captures to quake/capture.
Where do screenshots go? gamedir\screenshots? Or "User Documents" folder on Windows like Quake 3 and whatever the Linux equivalent is? Or throw them all in gamedir?
Maybe this last part has drifted way off topic and that's not what I'm trying to do, but rather collect the list of "things" while I am thinking about them so as to not lose them.
AND PLEASE!
One single standard for naming external model textures! Use the DP way! It is insane to have to rename textures from engine to engine. And only TGA ... jpg and png are bad due to the reasons LH mentioned. JPG loses quality for trivial hard drive savings making future modifications of the texture "even crappier" and PNG is virtually requires external libraries to load and save, but TGA is optimally efficient to implement in engine code.
Button
Lardarse once told me the benefit of DarkPlace's support for button1, button2, button3 etc. I don't recall what this was exactly, but maybe simplifying binds and menus and more or less a standard controls implementation on the QuakeC side (since my playing around with QuakeC is somewhat limited, I plead ignorance on this, but know it is important.) |
|
Back to top |
|
 |
goldenboy

Joined: 05 Sep 2008 Posts: 310 Location: Kiel
|
Posted: Mon Jan 04, 2010 2:38 am Post subject: |
|
|
Baker, the yellow makes your posts hard to digest. _________________ ReMakeQuake
The Realm of Blog Magic |
|
Back to top |
|
 |
necros
Joined: 16 Dec 2004 Posts: 22
|
Posted: Mon Jan 04, 2010 3:38 am Post subject: |
|
|
hey there,
i was linked here from func_, so i haven't read any of the posts. i'm just responding to the OP.
vital:
-map limits: i won't bother listing them all, but essentially, if i'm able to compile the map in aguirRe's tools, then it should be loadable.
i consider fitzquake to be adequate (although i have already reached the limits in v085 and had to scale back a couple of maps).
if fitzquake double it's limits from 085, i would be very happy.
also: don't neglect the max_ambient_sound_channels (or whatever it's called). i'm talking about that error that shows up when you have a lot of ambient sounds in your map which stops further ambient sounds from playing. fitzquake still uses the old limit (or the increased limit is still too low)
-multiple mod loading. especially for quoth because it sucks that anyone who made a map back when it was new essentially had to dump their files into the quoth folder.
fitzquake has -quoth but dp does it best, i think, with a more general method of just specifying whatever mod folders you want in a row.
-the signon buffer and whatever else needed to load up maps with tons of entities.
-alpha transparency with the .alpha key for windows or whatever. it should work on everything; brush models, mesh models and sprites.
not vital, but Pretty Damn Important:
-skyboxes and fog: while not having any impact on gameplay, skyboxes contribute a lot to the atmosphere of a map and not having access to one or both sucks.
-i would also consider it pretty important that there be a qc manner to load fog and skyboxes. if you have a map that used multiple skyboxes or fog levels, it shouldn't be necessary to have to use fancy qc to get the settings to stick for map loading and saving.
-external file loading for map textures, sprites and skins. this opens up all new texture sets for use in maps. (but pretty much everyone does this already)
would be very nice to have:
-sound sources that move with entities they are played on. so my lifts and trains emit their sounds nomatter where they are after they started.
-going along with the previous point, doppler effect.
-stereo sounds
-ogg support
-real rotating brushes. i'm so damn tired of that hacky hipnotic shit. if this was a standard, it'd be beyond cool to have proper rotation.
-some way to have more control over particle temp entity effects in qc. it doesn't have to be complicated.
say for example, you take all the currently existing temp entity particle effects and give the ability to control what colours are used by specifying a start and end point on the palette.
and maybe a way to scale the size of the particle effect so you could have a TE_EXPLOSION at half size or something.
so.. yeah, that'd be my ideal quake engine standard. |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Mon Jan 04, 2010 4:01 am Post subject: |
|
|
Urre wrote: | frag.machine wrote: | So... Technical discussions aside, back to the topic: it's time to bring more opinions from the rest of community (mappers, more modders, and even players) so we can gather a reasonable list of features to work. We need more people from Func_MgsBoard, QuakeOne, ModDB and others not so regular at this forums coming with their own lists to add material to discuss. And Spirit, I think this thread deserves a front page note, and even become sticky. |
Yes! But I think you're mixing this site up with Quaddicted. |
yeah, sorry guys. I meant to say scar3crow... _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
scar3crow Inside3D Staff

Joined: 18 Jan 2005 Posts: 837 Location: Las Vegas, NV
|
Posted: Mon Jan 04, 2010 4:04 am Post subject: |
|
|
I've considered it, and think I shall make a news post shortly (I'm just quickly checking things at the moment). Once things have been solidified a lot more, I would be fine with stickying a thread detailing those things, and the future of the standard, to have as an "on-forum reference" for the sake of convenience. This thread itself has yielded plenty of good information, but there is a lot of reading to be done to reach those conclusions as they come, and thus isn't suitable for getting sticky with it.
Nah nah nah, nuh nah nah nah. Gettin sticky wit it. _________________ ...and all around me was the chaos of battle and the reek of running blood.... and for the first time in my life I knew true happiness. |
|
Back to top |
|
 |
Dr. Shadowborg Inside3D Staff

Joined: 16 Oct 2004 Posts: 726
|
Posted: Mon Jan 04, 2010 4:14 am Post subject: |
|
|
Another one that would be nice would be some easier way of doing screen tints for powerups, cutscenes (fade to white/black), Nuke Blasts, etc. (stuffcmd to v_cshift is a less than ideal way, and you can do things that would make it break leaving you with stuck with a screen tint, which is why I've abandoned even attempting such things and have resorted to just working around the builtin screen tint effects.) _________________ "Roboto suggests Plasma Bazooka." |
|
Back to top |
|
 |
leileilol

Joined: 15 Oct 2004 Posts: 1321
|
Posted: Mon Jan 04, 2010 5:23 am Post subject: |
|
|
That reminds me, the water/slime/lava tints should be less hardcoded somehow, maybe specified in worldspawn. It sucks diving into any water that drenches the screen in bright brown. _________________
 |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Mon Jan 04, 2010 7:59 am Post subject: |
|
|
standard defaults for density start end etc... for me my defaults look like this, you can barely see the doorways in the distance begging your interest...
 |
|
Back to top |
|
 |
|
|
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
|