Messages

51

Bug reports / Re: Large units with short ranges are having trouble attacking

« on: 25 September 2011, 20:07:10 »

Oops, this was part of the projectiles chasing teleporting units failed fix, reverted in 9927075e10aa5

52

Feature requests / Re: Option for Camera movement when mouse on window borders

« on: 3 September 2011, 00:48:11 »

What a simple change this would be, and how useful... that auto-scrolling at screen/window edge often annoys me.

Will do.

53

General discussion / Re: Possible performance improvements with glGetUniformLocation and state changes

« on: 3 September 2011, 00:45:42 »

If I recall silnarm has, a long time back, played with splatting the whole map into a single massive texture.  If on the other hand you are still using tile textures, you can get massive speedups from putting all those tiles into a texture atlas so you can draw the map without texture state changes and from a small number of mega-tri-strips using degenerate triangles to skip.  (Always assume that an atlas will spill onto additional 'pages' so you're dealing with a small number of textures, rather than strictly a single texture).

Does GAE do this in someway? I recall seeing some image before that seemed to have all the tiles in one image file. Can't seem to find it now though, and no clue if that's even really related or anything.

'tr2' (Terrain Renderer 2, very creative name...) puts all the splatted textures on a single big texture (if possible, two or more may be needed depending on max texture dimensions and map size).

The image you saw was probably called 'terrain_tex.png' and was an output of said texture for testing/debugging, this is no longer saved.

I could imagine a G3DHack that took all the frames and merged the meshes and stripified it, and then you used a vertex shader to interpolate them.

I can also imagine such a thing... one day someone might even do it

I've had a quick play with gDEBugger and found a possible performance improvement. Instead of a calling glGetUniformLocation each time a uniform is set for each time a unit is rendered I've set it to store the handles on loading a shader. Using gDEBugger it shows that glGetUniformLocation is called 767 times and 11.99% of calls in a single frame step. After the changes it's called a max of 13 times. I've only tried with basic shader so if something is messed up, let me know.

Nice one, don't be shy with further investigating... rendering with shaders is not even remotely optimal atm.

Now that the shaders are working correctly (and are mostly consistent with the fixed pipe code) it is probably time to split the Renderer up, many current state changes are completely useless with shaders, and are just wasting time, but are needed for the fixed pipe code and therefor also for the ability to switch between them easily.

The other big thing that immediately comes to mind is getting rid of all the conditionals in shaders.  A tricky job perhaps, but what we need is what the guy at http://www.3dkingdoms.com/ calls a template shader system. Basically we have no complete shader source files, just snippets that do different things and are spliced together to make a final shader (or many shaders), so there wouldn't be one shader supporting up to x lights, but rather one shader for one light, one for two lights, etc, etc, and one for x lights, with no if statements.

54

MegaGlest / Re: [TESTERS WANTED] Speeding up rendering

« on: 3 August 2011, 10:23:54 »

For GAE I just store the X extrema (min & max x value) for each Y ('row') for an arbitrary convex polygon, this can then be used to quickly iterate and for an isVisible() function (very handy.)

http://sourceforge.net/apps/trac/glestae/wiki/SceneCuller

55

General discussion / Re: alternative ways to show teamcolor

« on: 20 July 2011, 13:28:49 »

I was perusing my bookmarks earlier and discovered this entry,

flipcode - Object Outlining

Uses the stencil buffer (so no need to mess with the depth buffer), too easy,

56

General discussion / Re: Options Menu

« on: 20 July 2011, 03:31:36 »

Nice job, with this finished it finally fixed my resolution problem! 

Yeah, this was probably fixed a while ago, bug from original Glest code, Windows wasn't being informed that the resolution change was of a temporary nature.

Don't forget to fix the language file, at the controls tab there is: ???HotKeys???

Sorry, I get lazy... if it doesn't show up in the solution explorer, it doesn't exist! 
Added.

Also for the audio tab, do you think there could be a percentage or something like that? If not, it's ok.

Could do I guess... just have to fix those rounding problems so Omega doesn't complain about his 80 becoming 79.

Don't forget to fix the language file, at the controls tab there is: ???HotKeys???

Feel free to remind me in a couple days if any language keys are still missing.  I'm a bit occupied with getting myself out of the ghetto (finally! ).

We programmer types should really be adding new keys to the English lang file when we use them in code, and mostly do... except me, perhaps.

Good luck with your move, hope all goes smoothly.

57

General discussion / Re: effects and emanations affecting buildings

« on: 20 July 2011, 03:23:04 »

I assume this applies to both effects and emanations?

Yep, an Emanation is an Effect, anything that applies to Effects applies to Emanations.

The one tag limitation is for the most part fine, as you can give units multiple tags, so could give all the units you want affected a tag specifically unique for the effect. Of course, the ability to specify multiple tags in the effect/emanation is more versatile and could save you from having to give more tags to the units.

Yeah, could be worked around easily enough, but isn't very convenient.

58

General discussion / Re: Options Menu

« on: 19 July 2011, 02:03:07 »

I stuck the keymap widget on the controls tab, and I've removed the network tab for now, seeing as we have nothing to put on it for the time being.

59

General discussion / Re: 0.4 beta2 (windows installer)

« on: 19 July 2011, 02:01:36 »

@wciow: more problems with handling normal maps have been resolved, hopefully one of them fixes your burnt out hut textures The team coloured tileset models is definately fixed.  Will build a new beta shortly.

@wecl0me12: see other thread for the buildings tag thing, total frame count has been returned to the debug info.

60

General discussion / Re: effects and emanations affecting buildings

« on: 19 July 2011, 01:54:00 »

'buildings', 'no-normal-units' & 'non-living' have all been commented out, I'm not sure if I intended to re-implement them with hidden tags or not, but tags would be the preferred way to do it now.

In an Effect the way to restrict the effects to tagged unit types is,

Code: [Select]

<effect>
   <!-- . . . -->
   <affect value="my_tag" />
   <!-- . . . -->
</effect>

Seems it can only support one tag atm, will fix that.

61

General discussion / Re: Re: alternative ways to show teamcolor

« on: 14 July 2011, 03:32:45 »

Apologies MG ppl... someone with the power to do so may want to shift the last few posts to the GAE board, I initially posted here to show what I had done and provide a link to the changeset if it was of interest.

I'm assuming they will be toggleable, what hotkey will be used by default (keymap.ini will have an entry, I assume)? At either rate, they look fantastic.

There is currently a keymap entry (default is semi-colon) to toggle 'team colour mode' (but atm it cycles through the different effects), and there will be a config option to select which effect you want to use for it (there is a keymap widget now too, needs a little polish, but you'll be able to change hotkeys in-game soon).

Could the outline be just around the silhouette of the unit?  It looks a little cluttered being around all of its edges.

It's currently outlining edges that have one front facing and one back facing polygon, I agree that it does get a bit cluttered, but fixing it will require disabling writing depth values while drawing the outline, and that will cause other problems as things are done now. The way we draw things (or rather, the order in which we draw things) will need overhauling, which will be good to do for performance reasons, so it will happen, but its a reasonably big job, so we'll have to make do with this for now 

62

Feature requests / Re: Simple override for default levels

« on: 14 July 2011, 03:20:39 »

I just did a quick test and can confirm that the defaults are used automatically, upon investigation of the code I discovered your request has been filled already, the attribute is 'defaults' and should be false to turn off the default stats.

Code: [Select]

   <level name="test_level" kills="2" defaults="false">


63

General discussion / Re: alternative ways to show teamcolor

« on: 13 July 2011, 13:28:31 »

I personally thought the outline idea seemed best, how does that circle look with selection circles as well?

I did outlines (could use some tweaking yet),

(click to show/hide)

A 'tint' (suggested after a bug in a shader that was doing basically this to some people randomly),

(click to show/hide)

and will allow both as an option,

(click to show/hide)

Commit:a05e3904

64

Feature requests / Re: Simple override for default levels

« on: 13 July 2011, 13:13:03 »

Since you can specify that stats for leveling up (eg, you might want it to gain a 1.25x multiplier for attack after 8 kills), the old system (1.5x hp, 1.5x ep, 1.2x sight, 1.5x armor) is should generally not be used if you are specifying custom levels. Because of the large number of mods which may depend on this "faulty" combination of both the default and their specified custom leveling, we cannot just disable the old system when specifying which stats to raise and by how much when leveling.

The 'old system' stats aren't used if you use 'new style' enhancements. At least, they are not meant to be.

65

Feature requests / Re: Cooldown on Permanent Cloaking

« on: 13 July 2011, 13:05:47 »

Interesting idea.

The cooldown for decloaking on skills can just be an attribute in the de-cloak node,

Code: [Select]

    <de-cloak skill-class="attack" cooldown="10" />

The second part will be a bit tricky to implement, I'll think on it...

66

Bug reports / Re: BUG: .deb package fail

« on: 10 July 2011, 22:35:36 »

Those debs were prepared on an old version of Ubuntu, probably best to build from source (actually, on linux this is always best... but that's a different matter).

67

General discussion / Re: Animation bound to build HP

« on: 10 July 2011, 22:33:40 »

I think we should both rename it to <anim-progress-bound value="true"/> ?

Sounds good, will change in GAE, and with no release since it was added 'anim-stretch' will not be supported.

What should it be good for in a build skill?

Who am I to say? There is a progress it can be bound to... so...

And what is build-self? Something GAE special?

This is part of the "placed morph" implementation, units that are 'transformed' from other units need to build themselves.

68

Feature requests / Re: Changes to Projectiles and Splashes

« on: 7 July 2011, 00:30:22 »

Thanks Will, re: comments on tickets, I had to disable them yesterday because we were getting people spamming them, I thought at the time they were registered users which was actually incorrect, apparently even anonymous users could 'comment', will change it to authenticated users.

69

General discussion / Re: Animation bound to build HP

« on: 7 July 2011, 00:26:34 »

Code: [Select]

<anim-stretch value="true" />

Currently valid only on be-built and build-self skills, will also be valid on produce, upgrade & build skills soon.

70

Bug reports / Re: BUG - Scenario not end on death

« on: 30 June 2011, 12:31:53 »

using,

Code: [Select]

  <default-units value="false"/>
  <default-victory-conditions value="true"/>

I immediately get the 'you lose' message, as expected. Could you cull away other code leaving the bare minimum to reproduce this then post it up?

As well, the loading screen images for scenarios don't seem to be working. I just got the generic missing image screen. Is the loading screen the path relative from the scenario XML?

I assume it looks in the scenario directory, what does the error log say? While it would previously try to load any valid image file, this is no longer true, all textures must have power-of-two dimensions now.

71

Tools / Re: G3dHack - alpha9

« on: 29 June 2011, 00:44:06 »

Hey, tried it out and i find it very useful, I am currently using it to re link textures, and shrink animations, for Annex which is being developed on megaglest. Game loads just fine and i'm able to play a game normally. However when i closed out i saw the debugger window full of errors! all are "...Error v4 model is missing texture...." upon checking the files all meshes have appropriate textures linked, and even in game said units have their textures displayed normally, and no crashes. Are G3D edited by this somehow incompatible with megaglest?

My bad, there was a bug in alpha8 and any models saved by it will have all five texture slots marked as in use, but contain empty strings for paths (on those unused slots).  I actually fixed this a few weeks ago, and thought I had uploaded a new one... Must have got side tracked!

Fixed in alpha 9.

The models saved should all work fine in MG, the 'no select' flag is not supported by MG, and if you add textures to anything other than the diffuse slot you are just wasting texture memory (MG will load them, but not use them for anything).

NB: G3dHack monitors all loaded textures, if they are changed in another program, they are automagically reloaded, so if you are working on textures, this is probably a lot more convenient than using the G3dViewer

72

Feature requests / Re: Per Faction Widget.cfg?

« on: 27 June 2011, 11:38:27 »

Sorry for the ultra late reply, no this didn't get done, there were/are resource scope issues with the stuff loaded by widget.cfg, wont be hard to fix up, but needed to stop adding code and start tightening existing code up...

Has been ticketed for 0.5.

73

Feature requests / Re: Effect/Emanations: Tags and Protection/Removal/Interaction

« on: 27 June 2011, 11:34:15 »

ticketed.

Basically, an effect strength multiplier (or 'canceller') to apply to effects appropriately tagged?

74

Feature requests / Re: attack on death

« on: 27 June 2011, 11:23:47 »

ticket 343 [one time attack on die skill], do we need the die-on-attack version? or this hp-cost thingie instead/as well?

75

Feature requests / Re: Changes to Projectiles and Splashes

« on: 27 June 2011, 11:18:39 »

Tickets 341 & 342.