PocketMatrix • View topic

by **Dan East** » Apr 5, 2001 @ 12:22pm

As randall stated, arrays are useful anytime you have a large number of elements to work with. They are really essential for most tasks (often their cousin, the Linked List, is used when the number of elements varies at runtime, or when chains of elements need to be moved around at once). In most cases the index itself is of some value. For example, PQ has a palette of 256 colors. This is represented by an array of 256 colors (I'll just use an int to represent a color value here): int palette[256]; Now, PQ's bitmap is just an array of those color values (indices to the palette array): int screen_buffer[320*240]; Note that the size of the array is simply the number of pixels needed by that particular resolution. So, now say we want to find the actual color value at coordinate x, y: int palette_value=screen_buffer[x*y]; int color_value=palette[palette_value]; Or we could just compound those statements: int color_value=palette[screen_buffer[x*y]]; Obviously this type of work requires arrays. Further, anytime you want to handle memory dynamically you are basically required to use arrays. For example, lets say at runtime I want 10,000 bytes of storage allocated (this is allocated off of the Heap, which is different than hardcoded variables, which are allocated off of the Stack). char *my_data_chunk=malloc(10000); A char is a signed byte. So, to use my data, I treat the char pointer as an array (arrays and pointers are basically synonymous as far as usage goes). So lets initialize the chunk to 0 (yeah, I know we could use memset, but this is for illustration). for (int i=0; i<10000; i++) my_data_chunk[ i ]=0; How about a more efficient alternative to do the same thing using pointers: char *ptr=my_data_chunk; //We precalculate the pointer to the 10000th element int *end=ptr+10000; while (ptr<end) *(ptr++)=0; I can break that down for you further if you want to know exactly what's happening. Even more efficient, because this ansi C function is coded in assembly for the various target devices: memset(my_data_chunk, 0, 10000); How about something tricky, where we can really achieve some optimization? A byte is only 8 bits, yet modern processors at at least 32 bit. Thus we are only using a fourth of the processors data size by setting each byte, or 8 bits, at a time. Instead let's work with 32 bits (an int) at a time. Note that this requires our array size to be a multiple of 4 since we are handling 4 bytes at a time: int *ptr=(int *)my_data_chunk; //precalculate ending pointer int *end=(int *)(my_data_chunk+10000); while (ptr<end) *(ptr++)=0; Now, that looks very similar to one of the previous examples. However, it requires 1/4th the amount of work on a 32 bit processor. If that code is compiled for a 64 bit processor then it will require 1/8th the work. Again, I'll go into as much detail as you care to hear regarding how that works. Just let me know... Dan East Last modification: Dan East - 04/05/01 at 09:22:17

by **randall** » Apr 6, 2001 @ 9:08am

Okay, my version was "Arrays for Idiots" and Dan's was "The Complete Reference for Dynamic Data Allocation".

As you can see, arrays are VERY important when dealing with homogenous data (similar information). For normal variable use, it doesn't make sense to use an array, especially if the types are different like this: unsigned short int v_age = 45; char v_fullname[] = "Jed Clampett"; char v_occupation[] = "hillbilly"; char v_financial[] = "millionaire"; Instead of using arrays for unlike-data, these could be implemented into a class. This is especially effective if we were organizing data for multiple people. class person { unsigned short int v_age; char v_fullname[]; char v_occupation[]; char v_financial[]; f_bio(); } Then different data could be stored for multiple people by defining a new "person". person Jed; Jed.v_age = 45; Jed.v_fullname = "Jed Clampett"; Jed.v_occupation = "hillbilly"; Jed.v_financial = "millionaire"; person Jethro; Jethro.v_age = 23; Jethro.v_fullname = "Jethro Bodine"; Jethro.v_occupation = "student/moron"; Jethro.v_financial = "dependent of Jed Clampett"; person Granny; Granny.v_age = 42; Granny.v_fullname = "Granny Moses"; Granny.v_occupation = "homemaker"; Granny.v_financial = "dependent of Jed Clampett"; Alot of games use classes in order to store and organize the player/enemy stats like HEALTH, FIREPOWER, POSITION, etc. I'm sure Dan can shed even more light on the usage of classes.

Last modification: randall - 04/06/01 at 06:08:19

by **Dan East** » Apr 6, 2001 @ 10:07am

The Class is the primary thing that makes C++ different than C. A class is basically like a C struct, except that it also can contain functions which manipulate the data contained in the class. It also adds in additional capabilities, such as protecting the data / functions from access by other classes. Classes can also be derived from one another, which is a much more elegant method of reusing code. For example, you could have a base class in a DLL, and in an application build off of the functionality of the base class. MFC (Microsoft Foundation Classes) does a great deal of this. For example, the basic window class is CWnd. Controls, such as buttons, trees, lists, edit boxes, etc., are built off of the CWnd class. Thus when you want to move a button (MoveWindow), you aren't calling code in the CButton class, but the code that is in the CWnd class it is derived from. So if you are familiar with the (huge number of) CWnd member functions, then you can apply them to any object derived from that class. CodeGuru has a huge amount of source code specific to the MFC. C++ and MFC are extremely well suited for creating / expanding windows controls. If you go with MFC, then you are commiting your code for use in Microsoft Windows only. Period. There was at one time a version of MFC for Macintosh, but to my knowledge that product died a long time ago. An advantage of using structs over classes is that the struct is just a chunk of memory, exactly large enough to store all the members it contains. Thus you can read directly in and out of a file into / out of a struct. This makes for extremely easy file IO. You can't do that with a class. There is also additional runtime overhead to using C++ over C. Especially when using the CString class. I have come to avoid that class more and more, where I relied on it heavily in the past. You really have to watch, because often easy, quick coding comes at a cost to runtime performance. You only write code once (ideally), but it is executed literally millions of times (in loops, etc). It is worth extra coding effort so that the optimizations are where they belong, in the execution of the app, as opposed to optimized code writing. That is one of the reasons I am fundamentally against Visual Basic (etc). The running application will require the device to work much harder to perform a given task, just so the programmer didn't have to when they were writing the software. That may be fine for a 1 ghz Pentium III machine, but not for a Pocket PC. Most games (Quake included) are written in C. My suggestion is to use MFC for more standard windows apps that do not take over the entire display (not using Game API). You should avoid MFC for games. Don't make the mistake of throwing in CString or similar MFC class because you don't feel like handling string manipulation yourself. This would come at a huge cost to portability (and performance), for the day you want to port your award-winning game to Playstation 2.

Don't ask me where this thread is going... Dan East

by **randall** » Apr 6, 2001 @ 10:56am

This thread is pretty much staying on the subject of C++. I haven't even come across any books that compile so much information into such a relatively small space. So I rather enjoy the "free information". Have you considered writing a book, Dan?

by **Moose or Chuck** » Apr 6, 2001 @ 11:38pm

Dan, randall. Thanks a lot, but I already bought a couple books on C++ ;D. But really, Dan's pallete and pixel examples were a perfect explanation.

Website · by **Paul** » Apr 12, 2001 @ 6:08am

I made this in eVB last week but its pretty rubbish using that so I wondered if anyone could help me make it in eVC? The PLAY button should load PocketQuake with command line parameters but as that doesnt seem to work at the moment it just pops up a message box. Everything else is in place and it makes some great config files for you! (There are more frames than the one I've shown) I also need to know the list of options for the engine (my 'video settings' frame doesnt do much yet) I kind of understand C but the whole thing with linking .c (or whatever) files to the forms is beyond me. If someone could point me in the right direction I could do this myself and release it by the end of the week... Oh yeah, you can see the desktop QuakeOn at Last modification: Paul - 04/12/01 at 03:08:47

by **Dan East** » Apr 12, 2001 @ 6:25am

Well, I don't know any way to get what you've done in eVB over to C++ without redoing everything in eVC. Visual C++ uses what are called Dialogs, which are pretty much equivalant to Froms in eVB. There is no way to copy a form into, or access a Visual Basic form, from eVC++. I think with Windows ME (etc), you could create a DLL with VB that you could then access from VC++, but you can't create DLLs or EXEs with eVB. To get you started redoing it in eVC: Create a new MFC Application in eVC. Hit Ctrl-R, then double click on Dialog. You now see something roughly like the forms editor in eVB. Layout all the controls as you normally would. You will have to assign a Control ID to each control, which should be in all capitals. Double click on the title bar of the dialog you created, and a box will pop up. Pick a name for the CDialog C++ Class that will be created to handle this Dialog box (MFC convention is to start all class names with a capital C, ie: CQuakeOnDlg). The Class Wizard will popup, which will allow you to add handlers for events, and variables for the controls. Click on the Member Variables tab, and double click each of the Control IDs representing the controls you added to the Dialog. Pick a variable name for each. C++ convention is to proceed each Class Member variable name with m_, so you can tell members of the class from local variables (ie: m_installed_patches). That will at least get you started.

I don't know what your programming background is, or how familiar you are with eVC++, so it's kinda hard to offer advice. Dan East

Website · by **Paul** » Apr 12, 2001 @ 6:45am

Yeah I knew I had to use dialogs - I've already started a project with the 'WIN32 Pocket PC Application' icon, not the MFC... I'll try again Dan, you're adding command line support, yeah? I had a registry problem a few days ago and now everything is reset - I've reinstalled the whole Visual Studio and the Embedded Tools loads of times and I'm still getting 'control not registered' (or something like that) in VB and "Error spawning shcl.exe" when i build in eVC... what's that about? Last modification: Paul - 04/12/01 at 03:45:33

by **Dan East** » Apr 12, 2001 @ 7:03am

The reason I recommend MFC is because the eVC++ gui will allow you to add and remove variables and handlers all point-and-click. Also, the MFC dialog classes are similar to Visual Basic when it comes to accessing the data contained in the controls. The mfc dll is in the ROM of all Pocket PC devices, so that's not an issue. As for your installation problems, have you tried uninstalling first? Make sure you scan your harddrive for errors before reinstalling too. I've never had any such problems in the 5 years I've been using the Windows CE toolkits. Dan East

by **Moose or Chuck** » Apr 12, 2001 @ 8:06am

this could be why the computer math class i'm taking at school doesn't seem to help. I need to learn MFC and they are teaching plain C++ crap thats usable in any compiler.

thanks for that tit bit of info i'm gonna work on this now. I figure i have enough of the basics to get a small program running.

by **Moose or Chuck** » Apr 12, 2001 @ 8:09am

where is a good place to find some help on MFC ???

by **Jaybot** » Apr 12, 2001 @ 8:22am

http://www.pocketprojects.com/site/ and http://msdn.microsoft.com/default.asp and http://www.devbuzz.com/ are a few...

by **myccroft** » Apr 12, 2001 @ 9:28am

So what you're saying is that you want to be me ;-)

by **Moose or Chuck** » Apr 12, 2001 @ 11:43am

no i don't want to be gay j/k

by **Moose or Chuck** » Apr 12, 2001 @ 11:44am

no i don't want to be gay j/k

C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Re: C++

Sort

Forum Description

Moderators:

Forum permissions