Uhhhh...
#1 posted by
Shambler on 2008/04/16 10:35:20
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
#3 posted by gb on 2008/04/17 00:47:50
You Tried
#4 posted by
bambuz on 2008/04/17 02:19:41
with the .ent in the same dir as the .bsp?
Shambler
#5 posted by
Lunaran on 2008/04/17 03:13:23
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.
Lunaran
#6 posted by
ijed on 2008/04/17 04:17:51
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/
#7 posted by
gone on 2008/04/17 05:31:09
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
IIRC
#8 posted by
DaZ on 2008/04/17 06:42:35
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 :)
Alpha Support (Long Post Alert!)
#11 posted by jdhack on 2008/08/10 07:39:04
(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?