I'd rather lower the maximum bar, engine-wise. 

Stick it in the BSP and you should be good to go. :)

(sorry, I couldn't resist...) 

 

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.

http://user.tninet.se/~xir870k/ 

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? 

period. 

(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.

Thoughts? 

Nice tutorial 

It may be worth posting that (or at least linking to it) at Inside3D, where Q1 engine discussion has recently migrated to. 

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++;
else
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. 

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. 

to always use AguirRe's Nehahra since I map more than I play. 

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. 

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)