Tutorial 7 online

[Phantom]

Folks,<br><br>Tutorial 7 is now online. This time I talk a bit about c-buffers, and optimizations, some specific for c-buffers, others are more generally applicable. C-Buffers can be used for other things than sprites too, check out the tutorial for some ideas. <br><br>url: http://www.pocketmatrix.com/phantom/tech.htm<br><br>Oh yeah, I added the sources for the bouncer demo, of course.<br><br>And another thing: If I click on 'developer' on the top bar, I do see a link to a certain game that is called 'Argentum', and some ancient 'Quake' thing, but nothing about the wealth of information on my tech pages. <br><br>(boy am I starting a burst of off-topic posts)<br><br>Well anyway, spread the word.<br><br>- Jacco.

[Digby]

That's a good article.  I enjoyed reading it.  I think it's a good thing that you're taking time to do this for the dev community, with all the other stuff you've got going on.<br><br>I didn't see anything about changing how the sprite is stored.  Do you think it would help to store the sprite as a list of spans instead of a rectangular bitmap where you need to traverse the pixels one at a time?  Even some sort of crude RLE might help here.  I haven't looked at your code so maybe you do this already.<br><br>Something that isn't mentioned in your article, but most think of sprites as being drawn in the order of submission.  That is, if you draw a red sprite first, then draw a green one in the same position, the green sprite will normally show up.  With this technique, that won't happen since the spans are already taken by the underlying red sprite.  I suppose the technical term for this is that you are drawing them in a front-to-back order.<br><br>I'm curious to know just how bad operator new and delete would do if you didn't use your span pool.  I know it's probably going to be hideous compared to setting a few pointers, but you might want to do it as a test just to bolster your argument for in-game memory management.  <br><br>In fact, in-game memory management might be a good topic for a future tutorial.  I can tell you from first hand experience that the heap manager in CE is pretty abysmal - much worse than anything on the PC.<br><br>p.s. I had trouble finding your tutorial pages too.  I meant to say something to Chris about it last week but I forgot.  Chris, get with it buddy!<br><br>

[MirekCz]

am I the only one, that can't find it?<br>I see tutorials 1..6, then a shot from tut6, a demo to download and then a list of source code downloads and info about nutcracker/easyce at the bottom... where is the 7th tutorial?!?<br>/me is blind at the age of 20... gosh

[RICoder]

Man...I just wrote a ton of stuff and erased it by accident.<br><br>Anyway, nice job Phantom it's a great article.<br><br>I also think Dan is on to something about a memory management article.  I am curious about heap management on the PPC, having not dealt with it directly yet.  So, Phantom, if you can throw an article about that together for, say, Friday, that'd be great.~~~~

[Digby]

Mirek,<br>Now I can't seem to find the seventh tutorial listed either!  This site is going through some funky voodoo lately.  On one of my machines, I try to click on a forum thread and it takes me back to the forum home page.  On another machine it works just fine. Kooky.<br><br>Jacco,<br>I'm wondering how much slower it would be to use a stencil buffer instead of spans?  It's incredibly easy to implement and could give you some cool transition effects by animating the contents of the stencil buffer instead of clearing it at the beginning of each frame.  Just a thought.<br><br>RI,<br>I think it was me who mentioned memory management in my earlier post in this thread, not Dan. <br><br>

[MirekCz]

Digby:using stencil buffer would be much slower, because with c-buffer you can write one value for n-pixels, while with stencil you need to write one value per pixel... you're quite much missing the whole idea then... (what's the difference between drawing a pixel and checking stencil if the pixel should be drawn and then drawing it or not?) The c-buffer takes a totally different approax cause it allows you to check if you should write or not a whole line of pixels with a few reads... and btw, what do you need the stencil buffer for? or maybe you're looking for something like s-buffering? (s-buffering is equal to z-buffering but you also save data as spans (and the difference between s-buffer and c-buffer is, that you save the z values in s-buffer))<br><br>and yeah... the pocketmatrix server seems to have some problems...

[MirekCz]

and ohh.. digby.. would you mind emailing me the tutorial/source code/exec(for PC)? I would like to read it and waiting till they repair the whole thing isn't the best idea I guess cause it might take few days...

[MirekCz]

ohh and maybe one more question.. is zlib free? Can I use it in a commercial product without any payment?(credits are ok)<br>Thanks for info...

[Dan East]

Pocket Matrix just switched servers. Jacco must have uploaded his files to the old pocketmatrix.com, so it's not available on the new host.<br><br>Dan East

[Dan East]

From zlib.h:<br><br>Permission is granted to anyone to use this software for any purpose,<br>including commercial applications, and to alter it and redistribute it<br>freely, subject to the following restrictions:<br><br>1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.<br><br>2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.<br><br>3. This notice may not be removed or altered from any source distribution.<br><br><br>Dan East

[MirekCz]

ohhh, thnx a lot Dan:)))))

[Phantom]

Hey guys, I can finally get to the forums again. I'm glad you liked the tutorial, apparently I can get away with quite complex stuff here. I was worried a bit that just Dan would appreciate tutorial 7. You guys answered all questions already, so I will now just go and get up-to-date on the other forums.

[cryo]

Hey,<br><br>first of all, i really liked the 7th tutorial. It is very well written and explains the stuff in a very clear and understandable way. Keep up the good work!<br><br>Now i dont know what most of you guys have been doing in the last years, but i have been an active member of the demo scene ever since. During the last years i have seen *tons* of optimization rutines, new algorithms and coding tutorials. So if you are really interested in coding examples/tutorials, there is a 99,99% chance you will find what you need in some demo-scene archives somewhere.<br><br>For this reason i think that talented ppl like Phantom should keep doing tutorials and sample code and stuff, but not necessarily reinvent the wheel. What i would like to see are pocketpc specific things. One more ultra-fast sprite blitting algo. is nice to see, but thats really nothing new (except if it is done in ARM asm). And yes, please get away with more complex stuff Phantom <br><br>M.E.<br><br><br><br><br>

[Phantom]

Marcelo,<br><br>You're right about reinventing the wheel, but I found that many tutorials are not that well written, and when you're experimenting with new stuff (most of the time a reason for looking up a tutorial) it's always nice that the examples are ready to be compiled on your platform. That's why I usually supply a sample source.<br><br>- Jacco.

[Dan East]

A great deal of the demos written for x86 are in (or contain) assembly. Especially if it is more than a couple years old when the average home PC wasn't 1 gigahertz. Believe me, I've looked through a huge number of demos, and very few were of use to me for that reason.<br><br>Dan East