To Do List & Bugs

[daniel.santos]

Glest/GAE language file incompatibility:
viewtopic.php?f=15&t=3552

[daniel.santos]

Better CPU Ultra

[Ayrin Greenflag]

what about an easy cpu for newbie?

[daniel.santos]

what about an easy cpu for newbie?

you must not have read the link

[Ayrin Greenflag]

u are right...blush! .. i didn't read that

[daniel.santos]

u are right...blush! .. i didn't read that

hehe
Yea, I'm thinking having 3 basic settings like easy, medium & hard and then a custom setting.  The basic settings would just map to predefined levels on each of the more fine-grained settings that you would specify with custom.  Maybe later on even add a mechanism to save their custom AI profiles.  But I'm glad you asked anyway, because you made me think of a few more settings we could add (I posted them in the "Better CPU Ultra" thread).

[daniel.santos]

Ok, I've moved everything from this thread into Bugzilla.  Give this query a try and see if you get a list of all of the bugs.  Fee free to create an account (it should work), log in and add more.

[wciow]

Parabolic arcs seem to be broken in 0.2.10.  Shots are acting as if they have the linear trajectory type not the parabolic one. Just look closely at the archer or catapult attacks!

[daniel.santos]

ah hah! This is only happening in the i686 build.  That took quite a while for me to figure out, I went though a lot of different builds.  In the future, PLEASe do post what version you're using as well as which build/OS, etc.  It can help me a great deal!

It doesn't seem that the attacks have lost their parabolic curve, it just seems that they are arriving at their destination almost instantly, so there's no chance for them to curve.  I'll see if I can figure this one out, a very funny one indeed as it's only happening on the windows i686 build as far as I can tell.

[wciow]

Yeah sorry for not posting which build it was. I assumed it was happening on all builds/systems and wondered why no-one had spotted this obvious bug  
Also the sse2 build is working correctly.

[daniel.santos]

Yea, I'm not sure what went wrong with the i686 windows build.  I should probably just rebuild it and make sure the problems are fixed, or maybe some other msvc setting. But you should always use the sse2 build if possible (Intel Pentium 4 and later or AMD Opteron and later) because it will (or should) have better performance.

I've been working on 0.2.11 lately. I've done extensive profiling & experimentation and have a lot of performance improvements in so far, the greatest of which, oddly enough, by limiting how often the "stop" skill (not command) is allowed to update -- it's now limited to 4 times per second (this is where the auto-attack/repair/flee calculations are made). Having 500-600 units in the game should NOT cause lag & unplayability.  I had some 450-ish units at one point in a test, but I'm an a phenom 9850, so it's not a good measurement (I mean 500-600 on an older processor with graphics settings appropriately tuned).  I did also fix the last two outstanding bugs, the meeting point button not working and units on the client of a network game not (appearing) to respond to commands that you give and then later "jump" to where you told them to go.

Having taken a bite out of CPU usage, I'm now revamping the keyboard input (completely) to enable a keymap via an .ini file.  I know this is the stable branch, but this is just something I really feel is needed and I'm making very drastic changes to the engine in the 0.3 branch, so I figured that this is probably the best place to put this in.  There are a lot of limitations to the current way that keystrokes are processed, which is the reason I'm revamping that layer.

Lastly, I'm still planning on implementing a change to the rendering system that will improve performance.  In the glestadv.ini file, there will be a setting for "low memory usage" that dictates how interpolation will be performed.  If set, there will be a single interpolation buffer (instead of one for each model) resulting in identical CPU utilization, but lower memory consumption.  If not set, each unit will have it's own interpolation buffer (usually using more memory) but the amount of CPU utilization will be greatly reduced -- I wont get into the details of that now.  I'm not sure if that will be in an 0.2.11 or 0.2.12, but I want this in the 0.2 branch because I want to get performance improved as much as possible for the stable branch while we (hopefully will have some contributions from others, otherwise "I" ) work on the 0.3 branch which will integrate lua and all other Glest 3.2 goodies, add new skills, add more flexible particle systems, LOD scaling for better rendering at far distances, integration of ODE (physics engine), improved animations & death sequences, (maybe even skeletal animation with bone weight support), etc.

[hailstone]

I'm now revamping the keyboard input (completely) to enable a keymap via an .ini file.

I remember doing this a while ago. It had a couple of issues like not having support for combination keys and I don't think it would work if you revamped the code.

[daniel.santos]

Ooh, you already wrote some key-mapping code?  I haven't actually gone too terribly far with that part yet so maybe I can use some of it if you still have it around.  I've removed all of the key and mouse processing functions from platform_util.h/cpp and window.h/cpp and created a new file called input.h that is under shared_lib/include/platform and an input.cpp that's under the sdl or win32 directory. I'm mostly finished with reworking this so I haven't actually worked much on the keymap yet, but now there's a new enum for "Glest key codes" and the functions (actually static functions of an an Input class) that translate back and forth between the native and glest/gae-specific code.  That way, we can have left and right for shift, control, alt, etc when it's supported.  I don't think that windows supports this distinction without using DirectInput8 and I'm not ready to make that leap yet so they just get mapped to the left shift/control/alt/meta.

The way I went about it is a little ugly from some aspects because I created a lot of code using an OpenOffice spreadsheet.  But the upside is that the translation tables should take very little room in the executables data segment, shouldn't be loaded in memory anywhere else except for the executable being loaded and it will make very fast translation calls.  I could have done it with less lines of code, but it would have either been slower or take more memory or both, so I sacrificed the code prettiness this time.  I added a huge ugly verifyTranslationTables() function to be called in debug builds that's just hundreds of asserts that makes sure the translation tables are correct.  I'm also restricting the range of native key codes to the first and last ones at the time of this writing, so that extensions on the end (most likely in SDL) will not later cause a GAE build that's corrupted.

Oh yea, and I found a buffer overrun flaw in the original Glest code (the SDL stuff) that I'm going to report so they can fix it there too (caused by rotating the mouse wheel or using the horizontal on a newer mouse).  It obviously hasn't had a drastic effect on others.  But back to the keymap, here's what I have of that so far (it doesn't do much yet and it's still on the ugly side)

Code: [Select]

enum UserCommand {
ucChatAudienceAll,
ucChatAudienceTeam,
ucChatAudienceToggle,
ucEnterChatMode,
ucMenuMain,
ucMenuQuit,
ucMenuSave,
ucMenuLoad,
ucQuitNow, // boss key
ucQuickSave,
ucQuickLoad,
ucPauseOn,
ucPauseOff,
ucPauseToggle,
ucSpeedInc,
ucSpeedDec,
ucSpeedReset,
ucNetworkStatusOn,
ucNetworkStatusOff,
ucNetworkStatusToggle,
ucSaveScreenshot,
ucCycleDisplayColor,
ucCameraZoomIn,
ucCameraZoomOut,
ucCameraZoomReset,
ucCameraPitchUp,
ucCameraPitchDown,
ucCameraRotateLeft,
ucCameraRotateRight,
ucCameraAngleReset,
ucCameraZoomAndAngleReset,
ucCameraPosLeft,
ucCameraPosRight,
ucCameraPosUp,
ucCameraPosDown,
ucCameraGotoSelection,
ucCameraGotoLastEvent,
ucSelectNextIdleWorker,
ucSelectNextProducer,
ucSelectNextIdleProducer,
ucSelectNextDamaged,
ucSelectNextBuiltBuilding,
ucSelectNextStore,
ucAttack,
ucStop,
ucMove,
ucReplenish,
ucGuard,
ucFollow,
ucPatrol,

ucCount
};

class Keymap {
private:
string fileName;

struct Entry {
KeyCode key;
UserCommand cmd;
const char * name;
const char * desc;
KeyCode defaultKey;
};

Keymap(const char* fileName);
Entry entries[ucCount];

public:
static Keymap &getInstance() {
static Keymap singleton("keymap.ini");
return singleton;
}
bool isMapped(KeyCode key, UserCommand cmd) {
assert(cmd >= 0 && cmd < ucCount);
return entries[cmd].key == key;
}

void save(const char *path = "keymap.ini");
};The basic idea is that there are "commands" and you can map those commands to some input (joystick should be added to this eventually).  I'm only planning on supporting it via a keymap.ini file, but a UI can be written later.  It is then the responsibility of the classes that accept keyboard input to ask the Keymap if a particular key code is mapped to a particular command.  Also, instead of sending key as an int, there's a new class for it now:

Code: [Select]

class Key {
private:
KeyCode key;
char ascii;
int modifiers;

public:
#ifdef USE_SDL
Key(SDL_keysym keysym) :
key(Input::getKeyCode(keysym.sym)),
ascii(keysym.sym < 0x80 ? keysym.sym : 0),
modifiers(keysym.mod) {
}
#elif defined(WIN32)  || defined(WIN64)
Key(DWORD wParam, DWORD lParam);
#endif

operator KeyCode() const {return key;}

KeyCode getCode() const {return key;}
char getAscii() const {return ascii;}
int getModifiers() const {return modifiers;}

bool isModifier() const {return key >= keyNumLock && key <= keyMode;}
bool isShiftDown() const {return modifiers & (kmLShift | kmRShift);}
bool isCtrlDown() const {return modifiers & (kmLCtrl | kmRCtrl);}
bool isAltDown() const {return modifiers & (kmLAlt | kmRAlt);}
bool isMetaDown() const {return modifiers & (kmLMeta | kmRMeta);}
bool isNumlock() const {return modifiers & kmNum;}
bool isCapslock() const {return modifiers & kmCaps;}
bool isMode() const {return modifiers & kmMode;}
};
Now that I look at it again, I should probably add separate "is[Left/Right][Shift/Ctr/Alt/Meta]Down" functions as well.

[verarticus]

is it know that the rally points cant be changed? (probly is but just making sure cause its annoying)

[daniel.santos]

is it know that the rally points cant be changed? (probly is but just making sure cause its annoying)

How about a little more verbiage? Because I don't understand a damn thing you are saying.

[verarticus]

is it know that the rally points cant be changed? (probly is but just making sure cause its annoying)

How about a little more verbiage? Because I don't understand a damn thing you are saying.

You can't change where the stinking ralley points on the buildings puts the new units that it producess! (IS THAT GOOD ENOUGH?!)

[daniel.santos]

ahh, I gotcha now, thanks!  Yea, the button was broken in 0.2.10 and 0.2.10a, I thought it was fixed in b.  Either way, you can still right click to set the rally point (in all versions).  Also, don't you think that the summoner should have a meeting/rally point as well?  I've often thought so.

[verarticus]

I dont know...maybe. and thanks didnt know about the right click for the rally point thing.

[modman]

NO!  How would that act when the Summoner moves?  Plus it would look stupid since the Summoner is not a building.

[verarticus]

well It could be progamed to only show when the summoner is summoning monsters and the such and I dont think it would look stupid...

[wciow]

NO!  How would that act when the Summoner moves?  Plus it would look stupid since the Summoner is not a building.

But the summoner can't move whilst summoning.

[daniel.santos]

Thanks for the feedback guys.  If I do it, I'll figure out a way for it to not be stupid, lol!

[Ayrin Greenflag]

don't know if someone has told before...would be nice to have bridges in maps  

[modman]

But the summoner can't move whilst summoning.

That's not what I meant.  I mean will the meeting-point stay in the same place globally or relationally to the summoner?  Plus, I just think it would be stupid.

[daniel.santos]

But the summoner can't move whilst summoning.

That's not what I meant.  I mean will the meeting-point stay in the same place globally or relationally to the summoner?  Plus, I just think it would be stupid.

I like stupid things!  Because stupid is the new smart!!!

If we do this, I'm thinking that it's temporary, that if the summoner moves, it clears it (no arrow displayed).  I've had situations where I was summoning stuff and I needed it on the battlefield ASAP and wished I could tell them to send them directly to battle.  Also, I'm starting to think that when new units are created, instead of issue commands for them to "move" to the rally point, they use the attack command if they have one.  If they do not have an attack command, but they have a repair command and auto-repair is enabled (now a config file option), then they should repair to the rally point.

don't know if someone has told before...would be nice to have bridges in maps  

Actually, can you please expound upon your bridge idea?  the first thought that comes to my mind is starcraft-style bridges, but only because I was talking about starcraft recently.  So like a bridge to travel across bodies of water, or gullies (the new cliff feature we're talking about for 0.3 & the new map format)?  There's a lot of possibilities.  I'm also thinking about "sky bridges" to join "walkable" units/structures (like defensive walls we've talked about before).  Lots to consider there, thanks for the idea and please elaborate.