News | Forum | People | FAQ | Links | Search | Register | Log in
Raising The Minimum Bar (engine-wise)?
Someone posted that aguirRe's engine has .ent file support, I did a cursory search through the 1.33 source and ... maybe I'm missing something ... but I don't see it.

Also, I was wondering if there is an objection to the "record demo at any time" feature in JoeQuake? Is there something about the feature that could somehow break mod capability?
I'd rather lower the maximum bar, engine-wise. 
I'm Sure It Has Ent File Support 
Stick it in the BSP and you should be good to go. :)

(sorry, I couldn't resist...) 
Email Him 
You Tried 
with the .ent in the same dir as the .bsp? 
I agree one million percent.

Convince all the inner city masses who buy their annual Madden update like diligent consumers that graphics don't matter and I'll start on a cheap easy-to-develop fun-to-play game right away. 
It's already being done, pretty much constantly. All the remakes and casual games - most recently prince of persia (original) in 3d and that commando, X? The one with the green guy and extending arm.

Then you've got lower end than that in the forms of Peggle, all of Wildtangent games etc.

It's pretty much what I do. And its not as fun as you might think because anything new is automatically a risk - they don't just downsize the engine but any creative thought as well.

There's less stress than a AAA title because the devtime is shorter, but not much less.

Low sale price high turnover is the business model.

More interesting are the potential homebrew access points in the evolving direct download systems. How about downloading a new map or mod for Quake from Steam? Or a map for <insert recent FPS here> from Xbox live? Just remains to be seen if the big console manufacturers want to open their frontends that much.

Can't see a problem with steam though . . .

Baker, I can't remember about .ent files for AguirRe's engines, but its bound to be in the documentation on his site. 
hey Lunaran, that sounds like DS gamedev :) so you have a chance

ijed oh right - great idea, wee need to embrace Steam for distributing quake maps to the masses 
I remember someone at valve saying they were integrating some sort of P2P system for 3rd party content in steam, didn't valve also hire the guy who created torrents?

Sorry for thread hijack please continue :) 
Why not use it? 
Because It Is Evil 
Alpha Support (Long Post Alert!) 
(Old thread I know, but the topic fits.)

So everytime someone asks about transparent glass in Quake, everybody says "yeah, it's too bad there's not widespread engine support for alpha". And then nothing happens.

Here's a little something I worked out that can easily add alpha support without relying on a modified progs.dat. The basic idea is when loading progs.dat, check if there's already a field named "alpha". If not, add one to the end of the fielddefs lists. This all happens in pr_edict.c

// add a global var for additional field:
ddef_t pr_alpha_def = {ev_float, 0, 0}; // ofs set later; s_name not used

In PR_LoadProgs:
qboolean has_alpha = false;

// existing loop for byte ordering:
for (i=0 ; i<progs->numfielddefs ; i++)
if (!has_alpha && !strcmp(pr_strings + pr_fielddefs[i].s_name, "alpha"))
has_alpha = true;

if (!has_alpha)
pr_alpha_def.ofs = progs->entityfields++;

// this line moved down from earlier in function:
pr_edict_size = progs->entityfields * 4 + sizeof (edict_t) - sizeof(entvars_t);

// then comes the FindEdictFieldOffsets call to set eval_alpha

Then in PR_FindField:
// after the loop through pr_fielddefs:
if (!strcmp (name, "alpha"))
return &pr_alpha_def;

If the engine already has Nehahra support, that's it! If not, you'll need to add the U_TRANS code to SV_WriteEntitiesToClient and CL_ParseUpdate, and of course update the model drawing code. And IMHO, engines should at least recognize the U_TRANS flag on the client side anyway, even if they just toss the values. That way they don't crap out on demos that happen to have it set.

I know it looks a bit hack-ish, but pr_edict already has special cases for angle, light, fog, and sky, so why not alpha?

The main problem is protocol incompatibility, for client/server and recording demos. One solution is to have a cvar on the server side which can force it to adhere to the original protocol 15 (eg. sv_oldprotocol=1). A similar thing could be done on the client side wrt demo recording, or the message could be hacked to remove the extra data before writing.

I guess this is mainly directed towards metlslime & aguirRe, although there might be some other engine guys around.

Nice tutorial 
It may be worth posting that (or at least linking to it) at Inside3D, where Q1 engine discussion has recently migrated to. 
Alpha Support (addendum/correction) 
I left out an important piece from my last post - the alpha field isn't written to file when a game is saved. So a couple of changes need to be made (still in pr_edict.c).

Add to ED_Write:
// after the loop, but before the final fprintf:
if (pr_alpha_def.ofs)
v = (int *) &ed->v + pr_alpha_def.ofs;
if (*v)
fprintf (f, "\"alpha\" \"%f\"\n", *(float *) v);

You should probably make a similar addition to ED_Print.

And in PR_LoadProgs:
// Change this:
if (!has_alpha)
pr_alpha_def.ofs = progs->entityfields++;

// To this:
if (!has_alpha)
pr_alpha_def.ofs = progs->entityfields++;
pr_alpha_def.ofs = 0;

Sorry about that! 
I was hoping with all the mappers here, it might be easier to convince metl & aguirRe that it's a feature worth adding. Then maybe I'll take on the rest of the world ;)

Seriously though, I don't spend any time on Inside3D. But if anyone wants to post a link to this, feel free. 
thanks for the work, I've actually implemented this feature already, but rolling these snippets into a tutorial for inside3D could still be a useful project.

Also, doesn't aguirre already support alpha? 
what i whould love to see is aguirre engine with a easy menu like joequake for demos and all the easy commands :\ not the old stuff but i guess this will never happend :( so i will stick to joequake and in big maps i will continue to use glquake 
Don't say never. 
Thread ended at post #1, where Shambler claimed the instant win. 
AguirRe's engines have .alpha support. 
So What Are The Commonly Used Engines? 
Is it like fitzquake & darkplaces and then the stragglers or is it horribly fragmented?

People might be more willing to target certain non-vanilla features if they knew what percentage of the 'audience' played engines with support for what sparkly bits. 
I would use Fitzquake if it had some futures of joequake:
maps menu
demos menu with the ability to go into folders
map name and demo name completion
possibility to start recording demos during playing
an big time and moster/secret display for speedrunning (yeah you think it is silly I know)
no need to enter the ".cfg" when execing a config file

And I can't remember how to turn the of the flash which appears while shooting and picking up items in fitzquake. 
I Tend 
to always use AguirRe's Nehahra since I map more than I play. 
FitzQuake For Me 
but i use AGLQuake for leaks because either marksurfaces or whatever is broken when the map leaks, or there can be no lit file or the wrong lit file and fitzquake gives me a black map. i SHOULD use it for gameplay testing too, but most of the time I dont.

I wander what version of Darkplaces I'm using because I have a water bug. Water shows up as a system texture. Also darkplaces doesn't support realtime lights with "255 255 255" colour lights, it only works with "10 10 10" I guess but Ive never tried it... But I do like the bump mapping and hirez texture thing. Especially for base maps. 
Alpha In AguirRe's 
From what I can tell, alpha entities are supported only in aguirRe's Nehahra engine, and only if the progs.dat supports it.

The advantage of the above code is that mappers could then use the "alpha" field without using a custom progs.

(Of course, requiring engine support for alpha is no better than requiring a custom progs, unless it becomes something that the majority of engines support. Which is why I thought I would at least make a case for it) 
It is very fragmented. 
i agree, it's better (even though it's hacky) to not require progs.dat support, just as skyboxes and fog are supported in most engines via similar hacks. 
Thread ended at post #1, where Shambler claimed the instant win.

I ended up looking up your old PlanetQuake home page just to see if you had made any single player maps out of curiousity and I saw the gaming industry note.

Is there something about the gaming industry that tends to sap the positivity, imagination and free-spiritness from the bone marrow?

Please don't this personally, I am really big admirer of 2 of your DM maps in particular my favorite being EFDM12 which is an amazing masterpiece if only it were not so hard to fill it with enough players ;) I'm rather just trying to figure out a pattern of why some func_participants are uppers vs. downers. 
Is this a serious question?

Is there something about the gaming industry that tends to sap the positivity, imagination and free-spiritness from the bone marrow?

Absolutely, positively, emphatically yes.

Even I hate me for how bitter and cynical I've become... sigh. 
Yeah, it's because I'm working on a custom progs that I didn't mention it.

Is there something about the gaming industry that tends to sap the positivity, imagination and free-spiritness from the bone marrow?

Absolutely, positively, emphatically yes.

In fairness, I think it's partly the membership of func too. That whole free thinking thing we encourage doesn't mix well with an industry increasingly driven by corporate interests and focus groups.

But to sum up; Yes, yes there is. 
I like Quake. I really like Quake.

My comment is not at all incompatible with that. 
I Like 
Shooters. With creamy graphics and good gameplay. 
Is this a serious question?

I can't remember ;-) 
So The Question Is 
leave the industry or leave func? 
Lun (re: Commonly Used Engines) 
You forgot the speedrunners that tend to use JoeQuake and GLQuake. And the people who play netquake (as opposed to QW) multiplayer who use ProQuake. 
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.