Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - will

Pages: 1 2 3 4 5 [6] 7 8 9 10 ... 32
126
Mods / Re: The Great Ming (Chinese) Faction (BETA Download)
« on: 19 January 2012, 07:16:53 »
Wyvern, if there's anyone more armchair military historian than you here on the board, it might be Mr War! :)

I too am curious about breach loading cannon in this setting.  Maybe you're onto something, Wyvern; maybe its artistic license.

I'll get some popcorn.

127
Feature requests / Re: Skill revealing distant area (Scanner Sweep)
« on: 18 January 2012, 07:59:46 »
In the Harry Potter books, a Patronus is a thing - silvery, glowing - that attracts enemies.

In glest, if a unit spawns another unit whose size is 0 (it cannot be attacked), without a move skill and with negative hp (so it eventually dies on its own) (you can even make it fade related to hp in mg), then it would be a very interesting dynamic.  A decoy.

It is not related to sight and scanners.

128
Feature requests / Re: Skill revealing distant area (Scanner Sweep)
« on: 17 January 2012, 20:57:12 »
So spawning a patronus, size 0 and negative hp that enemies spawn too is actually a great new spell or magic?

129
Off topic / Re: Ludum Dare
« on: 15 January 2012, 09:16:06 »
There's plenty of time t *learn* how to program!

The first step is to pick a basic game - pacman, for instance - a decompose it, work out how it would work...

For example, mist games have a 'game loop':

1. Handle all user input events
2. Note the current time, relative to game start time
3. Work out new positions for everything that moves, based on the current game time
4. Draw everything on screen
5. Exit conditions met? (Victory, quit etc)  If so, exit loop
6. Else go to (1) again
2. Move all objects that move

130
Off topic / Ludum Dare
« on: 12 January 2012, 20:39:10 »
This April, the Ludum Dare competition celebrates its 10th Anniversary!

I encourage you all to go look at the various games entered in the 22nd (its more than once-a-year) Ludum Dare that has just finished.

There is a solo mode, where you make your own game in a weekend from scratch.

And there is a team mode called "jam" - like musicians - that has three days.

Nearer April I'll remind the coders here to book some hobby time that weekend.

Now, more important is all of you who are not *yet* confident coders.

Ludum Dare is a really really great fun way towards becoming a confident coder, and taking part is a fun, self-rewarding challenge even if you aren't actually a coder.

If anyone wants to set themselves the target of entering Ludum Dare in April and wants to talk through and prepare and learn some basic programming, I'm sure they'll find a willing and helpful audience here on this forum.

Go for it!

131
MegaGlest / Re: Newbie feedback
« on: 12 January 2012, 10:01:48 »
Its not obvious to me that a negative attribute means produces.

Would it be cleaner ui to have sections like "consumes" and "produces" and such, and under each section have things like "4 food"?

132
MegaGlest / Re: something to share
« on: 9 January 2012, 10:37:16 »
Very nice.  Will be defeated by uneven terrain I think.

Is it possible to attach a particle like this to the placing of a unit, so you see it before you place the tower and such?

133
Mods / Re: The Great Ming (Chinese) Faction (BETA Download)
« on: 9 January 2012, 10:35:13 »
(Remind me; if a human player selects to attack, using a ranged unit, one of your units behind the wall, will the wall still absorb the damage because its in line of fire?)

134
Bug reports / Re: 3.6.0.2: G3DViewer creates incorrect images
« on: 5 January 2012, 11:53:20 »
I have often had the same problem, whereas the exact same model looks fine on someone else's PC.

Myself, I tried tracking the bug down - was it wrong winding, or cull face or something?  But no luck.

135
MegaGlest / Re: How hardware requirements could be reduced further
« on: 4 January 2012, 10:12:51 »
I reread my posts and its easy to misunderstand my motives.

I have a very bad integrated Intel card on one laptop, and some slightly-better integrated ATI thing on another laptop.  My prototyping of faster model drawing and terrain and such has always been motivated by trying to make glest/gae/mg run at a better and more playable framerate on my low-end graphics.

A few years back both OpenGL and Direct3D decided a break with the past was necessary to better gain mechanical sympathy.

Basically, the API that glest uses and the way it uses it is not the best way to get performance.

My own prototyping shows me that I can nearly double the framerate using attribute vbos and shaders on my Intel card.

However, this API break is really fundemental.  Having two codepaths, one for people without modern drivers (note, not necessarily meaning people with rubbish GPUs; most people with rubbish GPUs do have modern drivers, and would massively benefit from a graphics pipeline that better utilised it) is a serious undertaking.

Who is going to maintain the 'legacy' OpenGL codepath we inherit from Glest - back when that was the proper way of doing things, lets be clear about that - when we put in a completely new clean modern codepath for the 88%?

136
MegaGlest / Re: Masterserver fallback ( ideas? )
« on: 4 January 2012, 10:06:03 »
DHTs are an interesting subject but they don't offer redundancy

137
MegaGlest / Re: How hardware requirements could be reduced further
« on: 3 January 2012, 19:38:42 »
Philip` has said that 12% of 0ad users do not have the modern GPU features.  88% do have modern API hardware.

The newer platforms - android, chrome, iOS etc - and the newest OpenGL 4 do not support - as in won't compile - the old legacy APIs that that 12% need us to use.

We are going to end up with a modern OpenGL/GLES 2 codepath and, as a separate compilable unit, legacy code.

Our current engine is firmly in the 12% legacy territory, even though we have started to move over to VBOs and such.  We really need a fresh tidy new start on the modern OpenGL/GLES 2 codebase.

We have lots of features we want to add, such as moving over to bone animation e.g. MD5 and fancy water and bumpmaps and such.  Are we going to support these new features by adding them to the 12% codepath as well as a different implementation in the modern codepath?

This is a very strategic decision that should not be taken lightly.

My personal vote is to abandon those users who do not have the new OpenGL APIs available.  Sorry, but I think that's the pragmatic reality.

138
MegaGlest / Re: How hardware requirements could be reduced further
« on: 3 January 2012, 14:58:56 »
https://developers.google.com/native-client/beta-docs/3D-graphics#openGL is interesting, generic advice about how to get the best from hardware accelerators in general.  The classic draw loop we've inherited is pretty much anti-optimal these days.

139
MegaGlest / Re: Masterserver fallback ( ideas? )
« on: 2 January 2012, 16:35:52 »
Introducing redundant servers e.g. dns load balancing means communicating between the master-servers.

It is perhaps easier to put the logic into the client instead; if the client supported multiple masterservers at once, and logged into all of them, and broadcast games to all of them etc, and merged duplicate results it gets from all of them and so on, you can have redundancy that way without needing masterservers to know about each other.

140
General discussion / Re: GAE Website
« on: 2 January 2012, 07:20:27 »
The logo is nice.

It would be worth comparing a sans-serif font compared to that serif font and seeing if that looks better.

141
MegaGlest / Re: Developer's Wishlist for next release
« on: 30 December 2011, 11:33:29 »
I really look forward to you moving to git.  That's actually conditional for me submitting code ;)

I don't really like all the dependencies we have, and zapping a few would be nice; moving to use SOIL and GLM and an embedded simple XML parser and such would all be big wins from the management angle I think.  I would also like to replace cmake with a single normal big Makefile... ;)

Keeping the non-GLSL codepaths is going to be quite difficult to be honest.  I can help with the OpenGL 2+ port, which can also take us to other platforms (iOS, Android, NaCL) but trying to have equiv functionality in legacy GL 1 too is going to be a bind; once people start using MD5 etc, there's really not much point running such a game on hardware that is so unmodern as to not do VBOs and GLSL and such anyway?  Philip` put the number of 0ad users without GLSL at 12%.

Once we move into GLSL world, we ought to bump-map pretty much everything

142
Bug reports / Re: Selecting.
« on: 27 December 2011, 19:46:01 »
Here's some simple ports of the stuff you don't get in GLES 2 (or, eventually, an OpenGL 4.x world):

Code: [Select]
void graphics_t::set_projection_2D(int width,int height) {
matrix_t projection = {{ // transposed for OpenGL
2./width, 0, 0, 0,
0, 2./-height, 0, 0,
0, 0, -2, 0,
-1, 1, -1, 1
}};
set_projection_matrix(projection);
}

void graphics_t::set_projection_perspective(GLfloat fovy,GLfloat aspect,GLfloat zNear,GLfloat zFar) {
const GLfloat
radians = fovy / 2. * M_PI / 180.,
sine = sin(radians),
deltaZ = zNear - zFar;
graphics_assert((deltaZ!=0)&&(sine!=0)&&(aspect!=0));
const GLfloat cotangent = cos(radians) / sine;
const matrix_t perspective = {{
cotangent / aspect, 0, 0, 0,
0, cotangent, 0, 0,
0, 0, (zFar + zNear) / deltaZ, -1,
0, 0, (2. * zNear * zFar) / deltaZ, 0
}};
set_projection_matrix(perspective);
#if !defined(GLES2) && !defined(NDEBUG)
matrix_t check;
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(fovy,aspect,zNear,zFar);
glGetFloatv(GL_PROJECTION_MATRIX,check.f);
if(pimpl->projection != check)
graphics_error("Error setting perspective: " << std::endl << pimpl->projection << std::endl << " != " << std::endl << check);
#endif
}

void graphics_t::set_modelview_look_at(const vec_t& eye,const vec_t& centre,const vec_t& up) {
#if !defined(GLES2) && !defined(NDEBUG)
matrix_t check;
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt(eye.x,eye.y,eye.z,centre.x,centre.y,centre.z,up.x,up.y,up.z);
glGetFloatv(GL_MODELVIEW_MATRIX,check.f);
#endif
const vec_t f((centre-eye).normalised()),
s(f.cross(up).normalised()),
u(s.cross(f).normalised());
const matrix_t m = {{
s.x,u.x,-f.x,0,
s.y,u.y,-f.y,0,
s.z,u.z,-f.z,0,
0,0,0,1
}};
set_modelview_matrix(matrix_t::translation(-eye).transposition() * m);
#if !defined(GLES2) && !defined(NDEBUG)
graphics_assert(pimpl->modelview == check);
#endif
}

vec_t graphics_t::unproject(const vec_t& win,GLint viewport[4]) {
#if !defined(GLES2) && !defined(NDEBUG)
double p[16], mv[16], c[3];
for(int i=0; i<16; i++) {
p[i] = pimpl->projection.f[i];
mv[i] = pimpl->modelview.f[i];
}
gluUnProject(win.x,win.y,win.z,mv,p,viewport,c,c+1,c+2);
const vec_t check(c[0],c[1],c[2]);
#endif
const vec4_t in(
(win.x - viewport[0]) / viewport[2] * 2. - 1.,
(win.y - viewport[1]) / viewport[3] * 2. - 1.,
2. * win.z - 1.,
1.),
inv = in*pimpl->modelviewprojection.inverse().transposition(); // from OpenGL to normal order
const vec_t out(inv.x/inv.w,inv.y/inv.w,inv.z/inv.w);
#if !defined(GLES2) && !defined(NDEBUG)
if(fabs(out.x-check.x)>0.0001 || // fuzzy to account for using floats not doubles
fabs(out.y-check.y)>0.0001 ||
fabs(out.z-check.z)>0.0001)
std::cout << "WARNING! unproject failed: " << out << " != " << check << std::endl;
#endif
return out;
}

As you can see, the functions check their results against the classic functions they are replacing so I've got good confidence in them nowadays.

For selection, for example, you can unproject the near z (win.z == 0) and the far z (win.z == 1) and this gives you a ray through the scene on the mouse-click.

Because Glest is using a grid, you can then use a Bresenham's to march across the map, foreground to background order, checking to see if there's an object on the intersecting tile to be tested.

Even without bothering to cache the inverse projection matrix there really isn't any performance impact in doing this every frame; this is infinitesimal effort compared to doing any rendering at all.

Which reminds me; it would be so cool if a debug-mode showed models that spilled out over the boundaries of their tiles.

143
Bug reports / Re: v3.6.0.2 frozen server
« on: 27 December 2011, 02:54:13 »
[small]My guess is that it was waiting for the timeout on the socket and then it got EINTR from however you got the stacktrace so you see it on the line where its going to print that it did timeout?[/small]

144
Bug reports / Re: Selecting.
« on: 26 December 2011, 10:10:37 »
I'll donate geometry picking code so it can all be done quickly on CPU

145
MegaGlest / Re: Options for reducing hardware requirements
« on: 25 December 2011, 21:42:53 »
What are the intentions regarding preaerving aspect ratio on hud and loading screens?

(My laptop is widescreen)

146
MegaGlest / Re: Options for reducing hardware requirements
« on: 24 December 2011, 13:33:13 »
If you want low-poly, there are standard algorithms for simplifying meshes and the engines could do it at load-time

147
Tools / Re: "Different" mods sharing development through Git
« on: 23 December 2011, 08:17:56 »
At the moment, megaglest bundles 7z.exe and GAE has the 7z lib.

If it bundled git or libgit2 then it could all be transparent.

There's no need for all this talk of zipping stuff up and finding download servers for it all.  Still, I think its a hard sell.

148
Tools / Re: "Different" mods sharing development through Git
« on: 22 December 2011, 21:15:39 »
You do not need to "package" your mod on github; people can easily download a zip of the mod directly from github using the 'download' button, and you can easily pass around the URL of the downloads there too.

To decide what's in a release and what isn't is just to make a 'branch' in git and put what you want there in it.

To clarify, when I was doing this for the sci-fi pack, I had a release branch that, periodically, I'd pull the develop branch into and then run megaglest --validate-techtrees=x=purgeunused=purgeduplicates=svndelete=hideduplicates or whatever the exact commandline is

149
Tools / Re: "Different" mods sharing development through Git
« on: 22 December 2011, 11:11:20 »
You do not need to "package" your mod on github; people can easily download a zip of the mod directly from github using the 'download' button, and you can easily pass around the URL of the downloads there too.

To decide what's in a release and what isn't is just to make a 'branch' in git and put what you want there in it.

150
I will install from debs on xubuntu and see what happens after my xmas break

Pages: 1 2 3 4 5 [6] 7 8 9 10 ... 32
anything