Jump to content

  • Log In with Google      Sign In   
  • Create Account


- - - - -

03.01 - Q&A

  • You cannot reply to this topic
120 replies to this topic

#21 ElCabong   Members   -  Reputation: 122

Like
Likes
Like

Posted 15 April 2001 - 03:11 PM

Hey submonkey -

I definitely agree with asylum101...instead of wasting your time coming up with that very difficult algorithm, just change the way you''re making your game. A cartesian numbering system would be much easier to implement than your spiral system, despite the slight kink that using hexes instead of squares throws in to the problem.

A note on programming in general (and submonkey, this is certainly not aimed at you, it''s just a bit of wisdom I''ve learned the hard way over the years): it has been my experience that almost every time I''ve run up against a problem I couldn''t solve, it turned out that someone else could figure it out easily. The reason was simply that I was being close-minded in my approach - instead of trying to figure out a new way to work at the problem, I would hammer away for hours trying to make my first idea work. Most problems just aren''t that hard unless you go out of your way to make them that way - these days I try very hard not to reinvent the wheel unless I absolutely have to.



Sponsor:

#22 submonkey   Members   -  Reputation: 122

Like
Likes
Like

Posted 16 April 2001 - 01:50 AM

Thanks asylum101 and elcabong, both. In a way, I''m relieved that it''s not a terribly simple solution, otherwise I''d have to wack myself in the forehead

quote:
Original post by ElCabong
Most problems just aren''t that hard unless you go out of your way to make them that way - these days I try very hard not to reinvent the wheel unless I absolutely have to.


I most certainly agree. Initially, it seemed it wouldn''t be difficult at the time, but the more I thought about it the more I couldn''t figure it out...

Time for a new direction...thanks again



#23 khal   Members   -  Reputation: 122

Like
Likes
Like

Posted 17 April 2001 - 02:18 AM

Alright, this forum is for questions in C/C++? Well, I''ve run across a little problem in some MUD coding I do on the side. There''s a variable...currently declared long...that controls the "status" of my character. For example, bit 0 might mean he''s invisible. bit 1 might mean he''s flying, etc, etc... There''s an instance of this variable for every character...and the damn thing is written in C (and compiled on a variety of OS & processors) so, I''m not sure what all is available for me to use or what not.

Anyway, the problem comes when I started needing more than 32 bits. You see, I really don''t care what the data type is, as long as it can be conviniently passed. I''ve given thoughts to how I should change this (and since this is used 500+ times in the code, I would like to change as little as possible).
The current macros that extract the bit data are:

#define IS_SET(flag,bit) ((flag) & (bit))
#define SET_BIT(var,bit) ((var) |= (bit))
#define REMOVE_BIT(var,bit) ((var) &= ~(bit))

If at all possible, I''d like to simply change its data type (and since its passed as a part of the CHAR_DATA object, I probably don''t need to redo function parameter lists), and perhaps these macros. I''ve given though to using data types such as long double (10 bytes, 80 bits), or string[10]. Or, perhaps...just alloc_perm() space in memory and set a pointer to it. Which is perhaps the best way to do things? How would these affect the macros? Will the compiler know how to do a logical and with a pointer to xyz number of bits (thats essentially what a string[10] is) and a number (that''s beyond the max int for long 2.14 billion, or something like that)? thanks for any help!!



---
~khal

#24 marcl   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 April 2001 - 08:08 AM

Ok, here is my silly question for the day.

I often see code loops that start like this: "when(true)". Well, when WHAT is true? This one has always had me stumped. I''m asuming its some kind of trick where the compiler understands an inplied variable to check but I don''t see how.


#25 WildWest   Members   -  Reputation: 184

Like
Likes
Like

Posted 23 April 2001 - 09:12 AM

marcl: the loops you mean are endless loops!
The loop only runs, if the statement in bracket is true. and true is true for ever. normally you have a loop like this:
while(x==1)
{
}
so this loops runs only, if x is equal to 1.
Hope, I could help you

#26 Halek   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 April 2001 - 11:35 AM

marcl : just to add a little bit on what WildWest told you. The while (true) loop is indeed endless and when you use it you must make sure you include an exit condition in the body of the loop with break.
For example :

int x = 0;
while(true)
{
x++;
if x == 10 then break;
}

Of course, in this example, the sam behavior could be reproduced a number of ways. Like :

int x = 0;
while (x < 10)
{
x++;
}


Or even:

For (int x = 0; x < 10; x++)
{

All these code snippets do the same thing (if i didn''t make any typos that is) but the point is:

If you use While(true) without a Break in the body of the loop, then the loop will be endless, because as WildWest said, True is always True.

#27 marcl   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 April 2001 - 01:54 PM

When I first saw this I figured it was an endless loop but then I saw more and more code examples like this and figured it must be something else.

Is this done for speed reasons? In other words, would checking a variables value (e.g. When(exit==false)) take more time than an endless look that you break out of when needed?

I just tossed the books out window… endless loops are good now?


#28 silicon_jesus   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 April 2001 - 11:46 PM

kahl: i know you''re not going to like this answer, but i would recommend adding another layer of abstraction between the functions that care about these flags and the flags themselves. right now, it sounds like functions are aware of particular bit positions and determine if the bits are set by calling macros.

i would recommend your functions call macros that determine which bits to care about and, in turn, call your macros to see if the bits are set. you might have a "CAN_FLY" macro that checks "IS_SET" with your "fly bit," for example.

this will allow you to change the way you store the data in the future (more variables, perhaps -- though a struct or class might work nicely) without having to modify each individual function that uses the data.

it''s a lot of work to change your existing code, but it''ll make your life a LOT easier -- especially if you have to change the way you store the data again.

of course, being the OOP fan that i am i would also recommend providing a class that internalizes all the detials of your character. your class could encapsulate the data, and you would access it through methods. you''d never have to care about individual bits again.

hope this helps!

#29 silicon_jesus   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 April 2001 - 11:55 PM

submonkey: a quick search on yahoo or google for "hexagonal grid programming" seems to bring up useful results. hexagonal grids are the bane of wargame developers . luckily there are all sorts of established techniques for dealing with them. i hope this helps you find some useful information!

#30 khal   Members   -  Reputation: 122

Like
Likes
Like

Posted 24 April 2001 - 07:25 PM

silent_jesus:

hhmm...perhaps some specific examples would help:

in code, each bit is defined, as:
#define A 1
#define B 2
#define C 3
...
#define aa (some grossly huge power of 2)
...

now, the bits are given names (so we dont have to memorize them), like:

#define PLR_CAN_FLY A
#define PLR_CAN_SWIM B
...etc...

the actual variable that holds the data is:

struct CHAR_DATA{
...
long act; // <-- this is the bitvector
}

again..the macros are:
#define IS_SET(flag, bit) ( (flag) & (bit) )
#define SET_BIT(flag, bit) ( (flag) |= (bit) )
#define REMOVE_BIT(flag, bit) ( (flag) &= ~(bit) )

now...checking if the player can fly or not, is simply:

void SomeFun(CHAR_DATA *ch) // passes in character
{
if(IS_SET(ch->act, PLR_CAN_FLY)
// so, player can fly
else
// player can''t fly
}


so...checking the bits are pretty simple, since each flag is defined as a certain bit. if we''d like to change which bit mean which flag, we simply reassign the #define PLR_CAN_FLY to a different alphabetical letter (which correspondes to a certain bit).

the problem arises, however, when i want to use more than 32 bits for flags. since long is only 32 bits long, i''m restricted to only 32 different flags. most fixes online just addes a second bit vector ch->act2 as another long. but this seems like a temporary fix to me, and i''m really wondering why we cannot just chance the long to something, for example, string[10]. since, in truth, we don''t care what the value of string[10] -- only the bits. any further input is most appreciated =)



---
~khal

#31 MtSMox   Members   -  Reputation: 122

Like
Likes
Like

Posted 24 April 2001 - 09:36 PM

Hi everybody!

I have a question about precompiled header files. I''m using VC++ 6 and when I create a new project it always uses stdafx.h (or something like that) as a precompiled header file. And if I add other files, I have to change their settings to: "not using precompiled header" to make them work or include stdafx.h.
So what exactly is a precompiled header file and why should I use it (or not)? And what sort of source files should use that precompiled header file?

Thanks,
Mox

#32 silicon_jesus   Members   -  Reputation: 122

Like
Likes
Like

Posted 28 April 2001 - 12:42 AM

kahl:

yeah, i see what you want to do... unfortunately i''m not sure of how you do that. one would assume there is a way, though. i''d guess it has something to do with manually allocating a block of memory the size you want and just setting/checking bits (if you find a good way of doing this please post it here). i''m not sure how you would do this with strings.

again, all i can suggest is to provide another layer of abstraction... not just between the code and the meaning of each bit, but between the bits and the code itself. or, though i agree it would be something of a pain, creating another long to store more bits with.

hope you find a solution!

#33 khal   Members   -  Reputation: 122

Like
Likes
Like

Posted 29 April 2001 - 09:44 PM

silicon jesus;

hey, i worked something out -- much similar to that "layer of abstraction." i don''t know if this is the best or the smartest solution -- but its A solution...

here''s the snippet:
#include
#include

#define aa 0x1
#define ab 0x2
#define ac 0x4
#define ad 0x8
#define ae 0x10
...
#define a1 0x4000000
#define a2 0x8000000
// so on and so foth. this is just to give values for all 32 bits

// convenient consts
#define MAX_BITVECTOR 2
#define MBV MAX_BITVECTOR

// lookup vector
const long bit_table [32] = { aa, ab, ac, ad, ae, af, ag, ah, ai, aj, ak, al, am, an, ao, ap, aq, ar, as, at, au, av, aw, ax, ay, az, a1, a2, a3, a4, a5, a6 };

// the old macros
#define IS_SET_SINGLE(flag, bit) ((flag) & (bit))
#define SET_BIT_SINGLE(var,bit) ((var) |= (bit))
#define REMOVE_BIT_SINGLE(var, bit) ((var) &= ~(bit))

bool IS_SET( long *b, long v, ... )
{
va_list args;
int i;
if (v!=0 && !IS_SET_SINGLE( b[0], v )) return false;
if(MBV>1)
{
long v2;
va_start(args, v);
for(i=0; i {
v2 = va_args(args, long)
if(!IS_SET_SINGLE(b, v2)) return false;
}
va_end(args);
}
return true;
}

void SET_BIT( long *b, long v, ... )
{
va_args args;
int i;
SET_BIT_SINGLE( b[0], v );
if(MBV>1)
{
long v2;
va_start(args, v);
for(i=1;i {
v2=va_start(args,long);
SET_BIT_SINGLE(b[i], v2);
}
va_end(args);
}
}

void REMOVE_BIT( long *b, long v, ... )
{
va_list args;
int i;

REMOVE_BIT_SINGLE( b[0], v ); // sets low

if(MBV>1)
{
long v2;
va_start( args, v );
for(i=1; i {
v2 = va_arg( args, long );
REMOVE_BIT_SINGLE( b[i], v2 );
}
va_end(args);
}
}

void CLR_BITVECTOR( long *b )
{
int i;
for(i=0;i b[i]=0;
}


...basically, i''ve used a long[] for my bitvector instead. then, when i check for certain bits using IS_SET, or whatever,
I use a variable argument list, ex:
#define A_CAN_FLY a2;
#define B_CAN_SWIM b3;
// bc would be the same as ac (the number 4)
if(!IS_SET(ch->bits, A_CAN_FLY, B_CAN_SWIM) return true;

...something along that line....

i haven''t fully tested the code yet...doin'' that right now.
i''ll post if there are bugs


---
~khal

#34 khal   Members   -  Reputation: 122

Like
Likes
Like

Posted 30 April 2001 - 01:44 AM

okay, that was the dumb way...
this is the smart way...

you still have all your #defines, such as..
#define aa 0x1
#define ab 0x2
...
#define a5 0x40000000
#define a6 0x80000000
#define ba 0x100000000
#define bb 0x200000000
...
#define b5 0x4000000000000000
#define b6 0x8000000000000000
/* tested up to 64 bits so far */

struct bitvector
{
long low; // a's
long high; // b's
};

//then, simply rewrite the macros:
#define IS_SET(flag, bit) ( ( (bit)>a6 ) ? ( ((flag).high) & ((unsigned long)((bit)>>32)) ) : ( ((flag).low ) & ((unsigned long) (bit) ) ) )

#define SET_BIT(var, bit) ( ( (bit)>a6 ) ? ( ((var ).high) |= ((unsigned long)((bit)>>32)) ) : ( ((var ).low ) |= ((unsigned long) (bit) ) ) )

#define REMOVE_BIT(var, bit) ( ( (bit)>a6 ) ? ( ((var ).high) &= ~((unsigned long)((bit)>>32)) ) : ( ((var ).high) &= ~((unsigned long) (bit) ) ) )

typedef bitvector BITVECTOR;
typedef bitvector128 BITVECTOR128;

void main()
{
cout<<"64-bit vector test"< BITVECTOR b;

SET_BIT(b, a6);
SET_BIT(b, b6);

if( IS_SET( b, a6 ) )
cout<<"true"< else cout<<"false"<
if( IS_SET( b, b6 ) )
cout<<"true"< else cout<<"false"<
REMOVE_BIT(b, a6);
REMOVE_BIT(b, b6);

if( IS_SET( b, a6 ) )
cout<<"true"< else cout<<"false"<
if( IS_SET( b, b6 ) )
cout<<"true"< else cout<<"false"<}

The highs check against the highs, lows against lows. I've looked through the code & we only set 1 bit at a time, but the macros can easily be altered to set/check/remove several at a time...

The problem was in the data types. If you pass it into a function, you're forced to pass it as a data-typed variable (at least, i don't know of another way). The problem was, there wasn't a integer type variable large enough, so it always gets truncated. The macros are easily changed for more bits as long as the compiler can handle larger constants. I've tested it as far 64 bits. I've also written macro definitions for up to 128 bits. If someone knows how to pass values into a function, w/o data-typing them, please let me know! (it would simply the code)
The advantage to macros is that they save a little cpu time. Due this being executed several hundred times every second (and the fact that i have to pay for my cpu usage), I really can't afford to waste cpu time doing bitvectors as strings & parsing. Also, since the damned thing is written in C, I don't have many of the C++ options available to me. If anyone can think of a better way, please let me know!


...ack, just tested it for 128 bit. get a const too large error. does anyone know if there is a a compiler directive that'll enable larger consts? (i'm using VC6.0, but its gotta compile for linux/unix's gcc as well) thx!



---
~khal

Edited by - khal on April 30, 2001 8:47:08 AM

#35 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 02 May 2001 - 08:42 AM

Every Time I compile my Direct X programs after I installed DirectX 8.0a, I get the following Error Messages in my Compiler:

--------------------Configuration: DirectX - Win32 Debug--------------------
Linking...
File_01.obj : error LNK2001: unresolved external symbol _IID_IDirectDraw7
Debug/DirectX.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

DirectX.exe - 2 error(s), 0 warning(s)

I am using Microsoft Visual C++ Studio Introductory Edition Compiler. When I looked at the DDraw.h file I noticed that to run against a different version of Direct X, I would have to #define the version. I tried that, but I did not work. Does anyone have an idea on what I should do?

#36 Weatherman   Members   -  Reputation: 122

Like
Likes
Like

Posted 03 May 2001 - 05:38 AM

Anonymous Poster:

Make sure that the following libraries are linked to your program (use "Project Settings" - "Link"):

dxguid.lib ddraw.lib dinput.lib dsound.lib winmm.lib

Also, in globals.h, make sure that you have the following line near the top of the file:

#define DIRECTDRAW_VERSION 0X0700

#37 Rictus   Members   -  Reputation: 122

Like
Likes
Like

Posted 03 May 2001 - 11:24 AM

Can anyone explain what functions are being used to map the bitmapped alphabet, so that you can type in words and they print from the bitmap? Just like Basecode1 does. I''m sorry, but I''m a little lost on this one.

#38 Piotyr   Members   -  Reputation: 122

Like
Likes
Like

Posted 03 May 2001 - 12:31 PM

Actually, it appears right now that basecode1 isn''t even using the font that''s in the resource.bmp file. However, the Utils_LoadBitmap function loads it into a DirectX surface, which is why it''s needed for the code. To print out the text, he uses the TextOut function, which is a Windows function, I believe.

#39 Rictus   Members   -  Reputation: 122

Like
Likes
Like

Posted 04 May 2001 - 10:34 AM

Thanks Piotyr, I thought it was a windows function but when it wouldn''t compile without the bitmap it threw me.

#40 leggyguy   Members   -  Reputation: 128

Like
Likes
Like

Posted 05 May 2001 - 02:12 AM

I have a question for anybody who, like me, has been forging ahead while Teej''s comp was down.

I have managed to get DirectMusic to play a wav file, (a cool tune that I converted from an mp3) during teej''s base program, and stop playing when you press "M"

Thing is, the mp3 was a reasonable 3.5megs and when converted became a stonking 40meg wav. This, apparently, is normal when you convert mp3 to wav.

Here''s the thing, I would like to make the program play this tune. 40 megs is too large, though. I would like it to be playable, but be no larger than 5 megs, so that if I send this little prog to someone it isn''t too large. Any ideas how it can be done?

Someone did mention that DirectShow can help, but I haven''t gotten that far yet, and would rather not have to while we are dealing with DX7 on the forum. BTW, I am using DX8 and the DX8 DXmusic stuff.





PARTNERS