Originally Posted by
Saffith
One thing - some of the constants for blank characters have mismatched names and values. CHAR_BLANK142, CHAR_BLANK144, CHAR_BLANK145, and CHAR_BLANK158 should each be named one less.
Fixed. I forgot to change the identifiers, when I offset their values.
It is used. It's passed to the base class constructor to initialize clk, which in turn is used to initialize clk2. What it ultimately controls is how long it takes for each head past the first to start moving. Why that's something you'd want to change, I have no idea.
Hmm... If I was going to choose a gleeok value to expose, it would be the shot timer (for 'breath' weapons, this would be useful), not the head movement timer. How utterly random. I'll make a note of it in the next update. I'm not even sure how to name that constant.
NPCA_GLEEOK_HEAD_CLOCK ? I hate identifiers that can;t explain enough about what they represent, and require a paragraph of comments to clarify what they do. :/
That works, sure.
The thing is, it's not. "Extended ASCII" refers to any standard that fills in 128-255, but ANSI never extended ASCII beyond 7 bits. A lot of confusion seems to stem from the fact that Windows called its encodings "ANSI code pages." That was because they were supersets of ASCII, but a lot of people took it to mean that the encodings themselves were ANSI standards.
I was referencing IBM's Code Page 437, which is usually regarded (once upon a time) as 'upper-ASCII' (not upper-ANSI, although these days, both are seemingly tossed about interchangeably), and I was bleating that it would have been nice if one of these was standardised. There were other things around at the time on every platform, such as Apple's MouseText, and most home PCs had upper chars that were graphical in nature. The MSX and the C64 both immediately spring to mind, in this regard.
I should prefix the present set with CP1252_* though, instead of CHAR_*, as that would [help to] prevent platform-based confusion.
Here is a re-up of the ZIP, with the amended files:
http://timelord.insomnia247.nl/zc/zc...ixwaterjig.zip
I would also like an opinion on something...
Which do you prefer of these two functions:
Code:
//Functions to converty angular behaviour to directional, based on the angle.
//Call when setting bool Angular for an object, as Angular = DoAngular(ptr)
//This ensures that the lack of decimal precision in conversion to Allegro radians
//does not prevent setting certain angles; causing 'drift'.
bool Angular(npc n, int deg){
if ( deg % 45 != 0 ) { n->Angle = deg; return true; }
else {
//u,d,l,r,lu,ru,ld,rd
int dgs[8]={ 270, 90, 180, 0, 225, 315, 135, 45 };
for ( int q = 0; q < 8; q++ ) {
if ( deg == gds[q] ){
n->Dir = q;
return false;
}
}
}
}
...OR...
Code:
//Variation on Angular() that has a void type. Use when declaring a pointer, to st the angle and direction.
void SetAngular(npc n, int deg){
if ( deg % 45 != 0 ) { n->Angle = deg; n->Angular = true; }
else {
//u,d,l,r,lu,ru,ld,rd
int dgs[8]={ 270, 90, 180, 0, 225, 315, 135, 45 };
for ( int q = 0; q < 8; q++ ) {
if ( deg == gds[q] ){
n->Dir = q;
n->Angular = false;
}
}
}
}
These are part of the std.zh 2/0 spec, and I'm not sure which users would prefer.
I prefer the boolean return to bool Angular, as you can do this (in 2.60):
Code:
if ( n->Angular = Angular(n, degrees) ) { //Note, this is not quality, it is *assign*; assign in a statement is now legal
///Adjust attached npc segments for angular movement;
}
else { adjust attach npc segments for directional movement; }
This to me, is better than separately setting, then checking it.
I have both in there at present. If you want to see the WIP files, thy are here: std.zh v2.0--alpha, for ZC 2.60
P.S.
@War Lord
, or whoever is responsible: I can again access the forum without workarounds. Thank you.