Zorba the Hutt (zorbathut) wrote,
Zorba the Hutt
zorbathut

  • Mood:

So, What's Zorba Doing At Work?

<swolejoe> the size of your computer.... damn..... So how hard is it developing games for the ps2? Is it much more compilcated than developing for the computer?
* cchen (cchen22584@pool-151-200-239-180.res.east.verizon.net) Quit
<ZorbaTHut> well, yes and no.
<ZorbaTHut> you could definitely do it as easily as developing for the computer if you had some good libraries.
<ZorbaTHut> would you take full advantage of the PS2 hardware? absolutely not.
<ZorbaTHut> if you want to push the system as far as it can go, you end up mucking about in some very messy areas, and it gets a *lot* more complicated. :P
<ZorbaTHut> On the other hand, if you have good programming techniques it's still not really much more complicated in that the truly icky bits you only have to get right once, and then you just call them and forget about it. ;)
<ZorbaTHut> The only other real problem is a severe lack of RAM, and very very severe penalties for trying to use too much, e.g. "system crash"
<ZorbaTHut> we're not using any dynamic allocation at all except in one place, and we think that place might be causing a bug. :P
<swolejoe> LOL...
<ZorbaTHut> but, yeah - if you leak memory, even a *tiny* amount, it *will* catch up with you and your game *will* crash.
<MachinShi> no dynamic allocation? how can you code liek that?!?! :)
<ZorbaTHut> I can't imagine why people are using dynamic allocation on the GBA. I mean, I see people doing stuff with C++ and class hierarchies and Proper OO Techniques and I just shudder. :P
<ZorbaTHut> machin, you get used to it. :)
<ZorbaTHut> you make your buffers big enough to begin with. *shrugs*
<ZorbaTHut> I've got one or two places where I'm using C's dynamic-sized stack arrays, but that's basically to save RAM.
<MachinShi> on a gba? ugh.. *NO* .. dynamic allocation on that bad .. (but who uses C++ on a gba? :P )
<ZorbaTHut> machin, a lot of amateur developers who don't understand this thing called "efficiency" :P
<ZorbaTHut> on a GBA I might even drop to ASM ;)
<MachinShi> ZorbaTHut: agreed :)
<ZorbaTHut> mostly so I can page *code* in and out if I find it necessary. :P
<ZorbaTHut> but, yeah. example of what I'm going through on the PS2
<ZorbaTHut> when you want to use a texture, you have to get it into the memory on the graphics subsystem
<ZorbaTHut> you do this by DMAing (Direct Memory Address) a series of instructions to the GS processor
<ZorbaTHut> er, Access
<ZorbaTHut> so a texture ends up being a large amount of data that's sent to the GS
<ZorbaTHut> well, I don't know exactly how large it will be. so I generate it and we've got a bunch of functions which (thank god) I don't have to modify to take the datastream, break it into 4k chunks, and add the links so the DMA processor can just do it in one pass
<ZorbaTHut> meanwhile, I'm setting up rectangular blit areas to send the texture to the appropriate areas in GS memory
<ZorbaTHut> now, note that I don't actually know where those areas are when I'm generating this chain, so I provide a few pointers to where future code can fill in an empty area for the texture to be written to
<ZorbaTHut> Of course, the less data you send across the bus, the faster it is. Not all our textures are completely full. It turns out the PS2 hardware handles blocks of 16x16 pixels quite efficiently, so we mark (well, don't even store) every block of 16x16 pixels that doesn't have any data we care about in it
<ZorbaTHut> But we still want to do rectangular transfers, so I've precomputed, in the level-build step, all the rectangles of data - the spaces we don't care about just don't get written to. (Luckily, sending a 16x16 block is more expensive than the maximum 3 extra rectangles *not* sending it gives us, so there's never any value judgements in *that* algorithm.)
<ZorbaTHut> It's even worse than *this* though
<ZorbaTHut> the PS2 hardware likes 32bit colors, and so it's designed for that. We're using 8bit palettized textures - less bandwidth - and unfortunately, blitting 8bit palettized textures is slower than 32bit, because of some processing it has to do to move the data around.
<Tamyrlin> o sweet jeezus
<ZorbaTHut> However, we *can* claim it's 32bit, then change our mind once the data's on the other side. But in this case, we don't get the hardware moving the texture bits around for us. So we have to do it *ourselves*.
<ZorbaTHut> Keep in mind that I'm using a semi-obscure decompression algorithm at the same time, and you realize why this gets so incredibly evil. :)
<ZorbaTHut> On the other hand, I think I just tracked down the last bug. ;)
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments