26
Off topic / model soldiers
« on: 7 March 2011, 13:45:49 »
in plasticine: http://ottenki-serogo.livejournal.com/208662.html
Unbelievably good!
Unbelievably good!
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.
Pages: 1 [2]
27
Feature requests / better clicking on resources to harvest
« on: 8 February 2011, 12:33:52 »
I have about a 50% hit rate for getting my units to harvest with a right-click.
Two things can be done to make it much easier:
1) polygon ray intersection for the clicking so we know you click on the visual representation of gold or a tree and not the tile that is some distance behind it but on that ray...
1b) or if you use colour-based picking, draw the resources onto the buffer too!
2) It would be very useful if, when right clicking a worker near a resource they can harvest, they harvest it even if you miss. The miss factor might be half-a-tile or one-tile - so very close, but not exact.
If the user wants to move their worker to that spot rather than harvest they can always use the actual 'move' command with the left-click destination.
Obviously (1b) and then (2) are perhaps much simpler to implement than (1). Anything to make it easier to command things.
Two things can be done to make it much easier:
1) polygon ray intersection for the clicking so we know you click on the visual representation of gold or a tree and not the tile that is some distance behind it but on that ray...
1b) or if you use colour-based picking, draw the resources onto the buffer too!
2) It would be very useful if, when right clicking a worker near a resource they can harvest, they harvest it even if you miss. The miss factor might be half-a-tile or one-tile - so very close, but not exact.
If the user wants to move their worker to that spot rather than harvest they can always use the actual 'move' command with the left-click destination.
Obviously (1b) and then (2) are perhaps much simpler to implement than (1). Anything to make it easier to command things.
28
General discussion / GlestNG: ambition is my middle name
« on: 6 February 2011, 10:29:31 »
https://github.com/williame/GlestNG/wiki/Engine
of course nobody will be surprised if this project is like most projects I start - unfinished
of course nobody will be surprised if this project is like most projects I start - unfinished
29
Mods / Bump maps et al., split from Aztecs
« on: 30 January 2011, 08:58:29 »
I think the buildings looking aztec would be very cool
Perhaps bump maps can be used to add the detail
[Split, due to derailing. Feel free to carry on in this new thread.
-- ♥ John]
Perhaps bump maps can be used to add the detail
[Split, due to derailing. Feel free to carry on in this new thread.
-- ♥ John]
30
Tools / a 3D model format (turrets and more)
« on: 27 January 2011, 10:39:12 »
The current G3D format is a morph-target (http://en.wikipedia.org/wiki/Morph_target_animation) animation format.
To be honest, whilst skeletal animation is 'better' and it might lead to slightly less artefacts in things like rolling wheels, there isn't a pressing need to migrate the existing models to anything else.
But if you want to do things like turrets, it seems the straightforward approach is to adopt skeletal animation (http://gamedev.stackexchange.com/questions/7754/how-to-export-3d-models-that-consist-of-several-parts-eg-turret-on-a-tank/7760#7760)
I would propose that the MD5 format is adopted. It seems ubiquitous and easy to export and easy to load.
For turrets, the information about what meshes align with could be encoded in the mesh names. However, the information about their maximum traversal etc would not fit so easily there, so I'd therefore suggest the information about which mesh points at the target etc should be encoded in the model's xml file instead, e.g.
There could be multiple targets supported by using
And the 'at' might not just be targets, but also 'upwards' - so rider bodies point upwards when going up and down slopes - and 'wind' as shown in the example, e.g. for sails on ships and flags and washing-lines and such.
To be honest, whilst skeletal animation is 'better' and it might lead to slightly less artefacts in things like rolling wheels, there isn't a pressing need to migrate the existing models to anything else.
But if you want to do things like turrets, it seems the straightforward approach is to adopt skeletal animation (http://gamedev.stackexchange.com/questions/7754/how-to-export-3d-models-that-consist-of-several-parts-eg-turret-on-a-tank/7760#7760)
I would propose that the MD5 format is adopted. It seems ubiquitous and easy to export and easy to load.
For turrets, the information about what meshes align with could be encoded in the mesh names. However, the information about their maximum traversal etc would not fit so easily there, so I'd therefore suggest the information about which mesh points at the target etc should be encoded in the model's xml file instead, e.g.
Code: [Select]
<animation path="models/dragon.md5anim">
<align mesh="turret" at="target0" miny="0" maxy="0" /> <!-- not constrained in the xz so it can spin -->
<align mesh="barrel" at="target0" miny="-15" maxy="+25" minx="0" maxx="0" minz="0" maxz="0" /> <!-- only limited movement on y supported -->
<align mesh="flag" at="wind" /> <!-- follow the wind, perhaps the engine factors in speed and direction of unit too -->
</animation>There could be multiple targets supported by using
Code: [Select]
at="targetN" notation etc how might that best fit Glest? If only one target can be engaged by one unit at a time, then the 'at' should still be labelled 0 so as to make it obvious we might extend it in the future?And the 'at' might not just be targets, but also 'upwards' - so rider bodies point upwards when going up and down slopes - and 'wind' as shown in the example, e.g. for sails on ships and flags and washing-lines and such.
31
Off topic / mixed games programming links
« on: 24 January 2011, 06:28:10 »
this http://gamedev.stackexchange.com/questions/3223/game-development-blogs caught my eye - especially http://gafferongames.com/ and what it has to say about networking, timesteps and everything else that I see applicable to Glest engine development
32
Closed bug reports / [(p) fixed] micro-bugs
« on: 22 January 2011, 20:10:47 »
two tiny things I noticed when playing MG; apologies if already fixed
- the trees in autumn tileset are too high and the airships fly through them
- in keyboard settings, resetting the camera is shown as 32 - perhaps [space] instead?
33
Maps, tilesets and scenarios / Glest Engine with arbitrary placement
« on: 4 January 2011, 14:02:56 »
It is my ambition to make a Glest-compatible engine that uses arbitrary maps rather than tile-based ones, e.g. play on a virtual planet or such.
I am busy coding prototypes, e.g. https://forum.megaglest.org/index.php?topic=6354.0 , yet I have not yet thought of a good project name!
Suggestions please.
I am busy coding prototypes, e.g. https://forum.megaglest.org/index.php?topic=6354.0 , yet I have not yet thought of a good project name!
Suggestions please.
34
General discussion / how are distances worked out?
« on: 28 December 2010, 21:01:35 »
The map and tilesets are essentially 2D.
But is the actual logic underneath that works out placement and such based on alignment on this grid? And is unit movement based on this grid? Can more than one unit occupy a tile and such?
(Sorry that it is so much easier to just ask than to try and read the code for such a high-level strategic question)
But is the actual logic underneath that works out placement and such based on alignment on this grid? And is unit movement based on this grid? Can more than one unit occupy a tile and such?
(Sorry that it is so much easier to just ask than to try and read the code for such a high-level strategic question)
35
General discussion / advice about artwork
« on: 22 December 2010, 19:00:24 »
Is it a professional trick to add fake shadows or brown feet to models?
http://gamedev.stackexchange.com/questions/6695/game-models-that-stand-in-grass/6743#6743
http://gamedev.stackexchange.com/questions/6695/game-models-that-stand-in-grass/6743#6743
36
General discussion / wicker behemoth animation
« on: 13 December 2010, 23:21:20 »
Interesting trivia: wicker_behemoth_morph.g3d contains 10 sets of texture coordinates, and if each frame is rendered with the appropriate coordinates then the body glows with an inner fire effect.
The game engines don't seem to show this though.
Presumably it worked at some point once when the model was originally made?
(There are no other models that use this 'feature' that I have found; anybody know anything about it?)
If anyone has anywhere to host a 100KB video, I have what the effect looks like as an AVI.
The game engines don't seem to show this though.
Presumably it worked at some point once when the model was originally made?
(There are no other models that use this 'feature' that I have found; anybody know anything about it?)
If anyone has anywhere to host a 100KB video, I have what the effect looks like as an AVI.
37
Bug report / does the hand of the swordsmen pass through his shield when he's charging?
« on: 13 December 2010, 12:32:27 »
in the tech faction, does the hand of the swordsmen pass through his shield when he runs? Has anyone noticed this before?
38
General discussion / Rendering G3D using OpenGL
« on: 9 December 2010, 07:38:58 »
If I interpret the code correctly, G3D models are rendered in the following way:
Each model is number of meshes.
Each mesh has a number of frames.
Each frame describes the coordinates of each vertex. Each frame must contain the same number of vertices - if a wagon has a wheel that turns, then the wheel might have 10 frames, and each describes the wheel at a different point of rotation. The position of the vertices for any given rotation are computed by the model making tools and not by glest.
When loaded in the glest engine, it is stored in a vertex array.
Each screen update, the appropriate frame is selected for each mesh, and the appropriate vertex array is drawn.
My immediate thought is this:
In modern OpenGL (which I am unfamiliar with; I did OpenGL in the old days) the vertex buffer would be a VBO and you'd have only one VBO for each mesh, and each frame of animation would be a transform described in a 'uniform'.
In classic OpenGL, as each frame of animation is immutable you'd place it in a Display List. You would have only one Display List for the mesh, and describe each frame of animation as a matrix or, better, a series of transforms (rotate/translate/scale) to make the matrix.
In both the VBO/uniform and Display List/matrix approach, you can have tweening of frames very easily.
Now the classic Display List / Model Matrix transform is 'deprecated', but my understanding is it still goes like a rocket.
Am I retreading old ground that others have thought about and discarded? Or does it make sense to move from vertex buffers to Display Lists, and to compute matrix transforms for the 'unrolled' frames in the G3D models?
(Background: http://www.gamedev.net/community/forums/topic.asp?topic_id=558817 Display Lists are 10x faster than the vertex arrays glest seems to currently be using...? My expectation is that Display Lists are likely a bigger gain for typical users than those numbers given in that gamedev thread suggest.)
Each model is number of meshes.
Each mesh has a number of frames.
Each frame describes the coordinates of each vertex. Each frame must contain the same number of vertices - if a wagon has a wheel that turns, then the wheel might have 10 frames, and each describes the wheel at a different point of rotation. The position of the vertices for any given rotation are computed by the model making tools and not by glest.
When loaded in the glest engine, it is stored in a vertex array.
Each screen update, the appropriate frame is selected for each mesh, and the appropriate vertex array is drawn.
My immediate thought is this:
In modern OpenGL (which I am unfamiliar with; I did OpenGL in the old days) the vertex buffer would be a VBO and you'd have only one VBO for each mesh, and each frame of animation would be a transform described in a 'uniform'.
In classic OpenGL, as each frame of animation is immutable you'd place it in a Display List. You would have only one Display List for the mesh, and describe each frame of animation as a matrix or, better, a series of transforms (rotate/translate/scale) to make the matrix.
In both the VBO/uniform and Display List/matrix approach, you can have tweening of frames very easily.
Now the classic Display List / Model Matrix transform is 'deprecated', but my understanding is it still goes like a rocket.
Am I retreading old ground that others have thought about and discarded? Or does it make sense to move from vertex buffers to Display Lists, and to compute matrix transforms for the 'unrolled' frames in the G3D models?
(Background: http://www.gamedev.net/community/forums/topic.asp?topic_id=558817 Display Lists are 10x faster than the vertex arrays glest seems to currently be using...? My expectation is that Display Lists are likely a bigger gain for typical users than those numbers given in that gamedev thread suggest.)
39
Tools / glest_mod_pack.py
« on: 26 November 2010, 13:15:15 »
https://github.com/williame/GlestTools
You need python - and only python - to run it. If you want to compress best, you can also install the 'xz' command-line compressor and ensure that is in your path (or, on windows, in the same directory as you run the script from I think)
It is Glest / MG / GAE agnostic, and useful for packaging mods of all those formats.
It enforces a version numbering system in the naming convention of mods.
To use it, simply put your mod in a nice directory, ensure the name of the directory follows the convention (if it doesn't, you get told the naming convention!), and then use the tool instead of a normal zip program.
The idea is that there will soon be a website for hosting these mods, or at least meta-data for them, and that there will be a friendly installer for players to use to get new mods and do updates.
But in the meantime, right now, hopefully this packager is useful in making classic mod zipfiles!
You need python - and only python - to run it. If you want to compress best, you can also install the 'xz' command-line compressor and ensure that is in your path (or, on windows, in the same directory as you run the script from I think)
It is Glest / MG / GAE agnostic, and useful for packaging mods of all those formats.
It enforces a version numbering system in the naming convention of mods.
To use it, simply put your mod in a nice directory, ensure the name of the directory follows the convention (if it doesn't, you get told the naming convention!), and then use the tool instead of a normal zip program.
The idea is that there will soon be a website for hosting these mods, or at least meta-data for them, and that there will be a friendly installer for players to use to get new mods and do updates.
But in the meantime, right now, hopefully this packager is useful in making classic mod zipfiles!
40
Feature requests / integrated mod installer
« on: 17 November 2010, 06:43:57 »
https://forum.megaglest.org/index.php?topic=6002.msg62656#msg62656
Apologies if this has previously been discussed to death (although I couldn't find a thread on it in this forum), but I'm volunteering to try and implement it. I have plenty of experience programming this downloading kind of thing, but it will be a fun and gentle introduction to coding glest...
The first step is get a good idea of the requirements so please reply with your assumptions and desires.
Oh, and explain how we manage mods that add fractions vs mods that use the engine for alternative games...
Apologies if this has previously been discussed to death (although I couldn't find a thread on it in this forum), but I'm volunteering to try and implement it. I have plenty of experience programming this downloading kind of thing, but it will be a fun and gentle introduction to coding glest...
The first step is get a good idea of the requirements so please reply with your assumptions and desires.
Oh, and explain how we manage mods that add fractions vs mods that use the engine for alternative games...
Pages: 1 [2]