Tutorial 4 online

[Phantom]

Hey guys,<br><br>The fourth tutorial is now online, covering pointers, buffers and sprites. Enjoy.<br>URL is: http://pizza.hvu.nl/~kouwenhs .<br><br>- Jacco.

[Moose or Chuck]

Ya, good to hear. Another tutorial. <br><br>Now i can write my next too ~

[Phantom]

Hey you should request a thousand e-mails first.

[Moose or Chuck]

Now that's a good idea! ~

[Digby]

More good stuff Jacco.  I've just read your Tutorial #4 and I have a few comments.<br><br>1) The article explains the use of the new[] operator but it doesn't mention delete[].<br><br>2) The article didn't cover one of the most important points of C/C++ pointers, and that is pointer arithmetic.  Novice programmers should understand that when using the pre/post  increment/decrement operators or any of the math operators (+/-*) that the value of the pointer variable is changed by the size of the data type to which it points - not by the value of the operation.  For example<br><br>BYTE *pbByte = (BYTE*)0x10000000;<br>WORD *pwWord = (WORD*)0x10000000;<br>DWORD *pdwDWord = (DWORD*)0x10000000;<br><br>    pbByte = pbByte + 1;<br>    pwWord = pwWord + 1;<br>    pdwDWord = pdwDWord + 1;<br><br>After the addition operation above, pbByte now contains 0x10000001, pwWord contains 0x10000002, and pdwDWord contains 0x10000004.  This can really confuse people who look at the code and see the value of 1 being added to pointer and the resulting variable will sometimes increases by more than 1.<br><br>3) There is the issue of alignment. Attempts to dereference a WORD or DWORD pointer at an odd-address will cause an exception with some CPUs.  This might be harder to explain than it's worth for newbies though.<br><br>4) In the paragraph explaining how to use a spin loop to update the frame every 30 msec, why do you need to call update() in the loop?  Incidentally, you've left off the () in the update call.<br><br>5) There's a typo in the code mentioned in the section titled "Pointer Magic".  The line should read: <br>PIXEL* source = secondarybuffer;<br><br>6) It might be worthwhile to add a section about NULL pointers and checking for NULL before dereferencing (and what happens if you don't do this).  A lot of APIs denote failure by returning a NULL pointer value, including the memory allocators.  Since Pocket PCs will fail memory allocation far more frequently (limited phys RAM, no paging to disk) than code running on PC, this might be worth mentioning.<br><br>7)  This is really trivial but in the line of code that tests for a transparent pixel there's no need to recalculate the source pixel value - you have that already in spritepixel.  This brings up another point, you started the article with a nice progression of pointer arithmetic, to post-increment operators, to using memcpy().  Did you consider doing the same for the sprite code?  You might want to add sample code that shows how to copy the sprite more efficiently than calculating the source and destination address within the inner loop.  I'm not saying remove the example you have because it is very readable and easy to understand, but you might add an optimized example and then the reader can compare the two.<br><br><br>Again, it's really cool that you're doing these series of tutorials for the people who want to dabble in game programming for their Pocket PC devices.  Keep up the good work!<br><br><br>

[Phantom]

Digby,<br><br>I fixed the things that you mentioned. I think this is quite important, since these are really the basics that people should understand. I appreciate your feedback greatly.<br><br>- Jacco.

[Dan East]

Yeah, #3 is a biggie. The Windows CE processors are much more picky about alignment than the x86 family. Thus an app may run great in the emulator, but crash on a real device. I also discovered that the MIPS processor was very picky about alignment performance-wise. In one app I dynamically allocated string buffers to fit their contents. The code ran very slow on MIPS devices until I changed my allocation routines to allocate memory in chunks of 8 bytes. That alignment got MIPS back up in performance relative to the ARM and SH3 processors.<br>This doesn't directly deal with your document, but I have found the ARM processor to be the most forgiving, versatile processor of the three. MIPS has the alignment-performance issue, and SH3 apps(probably because of the compiler) may crash in certain circumstances due to compiler optimizations. Unfortunately any non-trivial app must be tested and even debugged on all three types of devices.<br><br>Dan East

[Phantom]

Dan,<br><br>You said you aligned your strings to 8 byte boundaries. Does it matter, speed wise, whether you use 8 byte or, say, 4 byte boundaries? In that case I suppose I can get some more performance from the Nutcracker too (and maybe from MikMod, wich would also be nice).<br><br>- Jacco.

[Dan East]

I just looked at my code to see what it was I did. Based on experimentation, I had to allocate (with new) in multiples of 16 (my earlier post is incorrect) to prevent a huge performance degradation with MIPS. I also tried 2, 4 and 8 byte chunks with no positive results. We have the same medical software running on a host of devices, CE 2.0, 2.11, 2.11 Pro and 3.0, SH3, ARM and MIPS.  The MIPS devices (a Cassopeia E-105 PSPC and NEC MobilePro HPC/Pro) both ground to a halt (like 3-5 times slower) when repeatedly allocating data that was not on that boundary (we're talking about thousands of such allocations at a time).<br>Here's the type of code I used:<br>[fixed]<br>#if defined(_WIN32_WCE)&&defined(_MIPS_)<br>pNewData=new BYTE[16-(len%16)+len];<br>#else<br>pNewData=new BYTE[len];<br>#endif<br>[/fixed]<br><br>The memory is used primarily for strings (TCHARs).<br>I don't have a MIPS device handy to experiment with, but it should be easy to do some trials to see what happens. You would have to do thousands of iterations to make the effect most noticeable.<br><br>Dan East

[Phantom]

So the slowdown occurs only when performing the actual 'new', not when accessing the memory? I mean, a memcpy from or to a 2-byte aligned address is not slower than one to a 16 byte aligned address?<br>I don't do that many new's in The Nutcracker, so it's not really an issue for me in that case.

[Dan East]

No, it was in accessing the memory after it had been allocated. Actually, I never did a test to see if the allocation time was affected either way. The accessing of the memory down the road was the most critical part.<br><br>Dan East

[Phantom]

Well in that case I'll optimize my code. Thanks for the tip.

[Dan East]

Do you test on a MIPS device? I thought you had an iPaq. It's a shame a developer needs to own one of every Windows CE device they want to target, to work out its idiosyncrasies.<br><br>Dan East

[Phantom]

I have an iPaq, indeed, but this modification can be tested by my betatesters. It's certainly not an ideal situation however, I agree.

[Phantom]

Dan,<br><br>I am in the process of optimizing The Nutcracker a bit; I now store my screens (7*8 tiles) in a 8*8 buffer to be able to use <<3 instead of *7; I added a lookup-table for the tons of /40's I do (tiles are 40 pixels wide), and now I wanted to add this optimized memory allocation stuff for the Mips.<br><br>I just read over your post again, and first now I noticed that you allocate chunks of 16bytes. I thought you where allocating at 16byte boundaries, so I wondered how you were going to fix that when you free memory. But no, you just allocate 16byte chunks, at random addresses.<br><br>I don't understand that. I mean, I can imagine that allocating at a nice address matters, but the size of the chunks? Very odd.<br><br>Anyway, I'll just add it with a nice #ifdef around it for the Casio's. <br><br>- Jacco.