Slashdot Mirror

← Back to Domains

Domain: codemaestro.com

Stories and comments across the archive that link to codemaestro.com.

Comments · 7

  1. Re:I don't comment my code anymore by UnknownSoldier · · Score: 5, Interesting · on Institutional Memory and Reverse Smuggling

    > that's quite a different thing than the arrogant coders who feel that their colleagues are incompetent if they cannot follow uncommented code. if someone cannot follow my code then I feel I have done something wrong, not them.

    IMO, _proper__ commentting discusses WHY you did something. If someone wants to understand HOW it was done, read the code, as you correctly reason. Any half-decent coder should be able to figure out what the code is doing.

    EXCEPTION: If you are doing something tricky, then document that. i.e. http://www.codemaestro.com/reviews/9

  2. Re:Does anyone actually listen to him by MattSausage · · Score: 1 · on Carmack On 'Infinite Detail,' Integrated GPUs, and Future Gaming Tech

    Have you not read this?

    That's a pretty good reason to take him seriously.

  3. Re:I don't know about this whole "quality" thing by Clsid · · Score: 1 · on Game Devs Weigh In On Windows Phone 7

    They were simpler compared to today's standard but back then doing stuff like that was kind of like rocket science. First of all, there was very little documentation on how to do things. Most professional were self-taught individuals and it was hard for a company to hire talent. They pretty much had to be on the lookout for good shareware developers so they could enlist their talent to their product line. That was the case with Ken Silverman and even John Carmack and Tim Sweeney to some extent.

    So let me put this in perspective, the challenges you face today is coordinating a team of developers to do things right but the code per se is not a big issue. The 3D APIs is straightforward, most companies license a game engine, the music gets produced by composers with full orchestras. Everything is standard and documented. I don't know if you have seen the kind of hacks that those aforementioned three had to put in their code sometimes but here is a sample: http://www.codemaestro.com/reviews/9. Also stuff you had to do before since you had very low memory and crappy graphics device is totally irrelevant today. Things like color palette rotation, inline assembly optimization, using bitwise operators as much as you can instead of regular operators even if nobody could understand the code afterwards, etc. Today with true color there is no need for color palette rotation, compiler optimizations are pretty good so that you don't need to do most of the assembly or bitwise stuff since the compiler does it for you, plus as I said, there is version control, no need to program against different graphics cards and no awful DOS4GW with their int10h crap.

  4. Re:"elegant code" overhead coefficient by svtdragon · · Score: 1 · on Defining Useful Coding Practices?

    I don't know where things like this fit into the discussion... it's really quite a mathematical hack, and hard as hell to understand, but once you realize what it's doing, you realize it's saving a lot of time in a function that's called reasonably often.

  5. Re:Videogames in 1982? by Anonymous Coward · · Score: 0 · on Tron Legacy Exposed

    Carmack also gave us his magic number.

  6. Re:Commander Keen by Cheesey · · Score: 4, Interesting · on Historians Recreate Source Code of First 4004 Application
    Carmack's code is always interesting. Most famously, there's the infamous square root approximation from Quake. But I'm still impressed by the original Doom render loop, with it's self-modifying code.

    The loop is drawing columns (vertical slivers of wall). It needs to interpolate between two things: the input wall texture, and the output part of the screen. Carmack uses something like Bresenham's line drawing algorithm to do this, but because the 386 has such a limited register set, he stores the fractional increment in an immediate attached to the "addl" instruction:

    doubleloop:
        movl ecx,ebp // begin calculating third pixel
    patch1:
        addl ebp,12345678h // advance frac pointer
        movb [edi],al // write first pixel
        shrl ecx,25 // finish calculation for third pixel
        movl edx,ebp // begin calculating fourth pixel
    patch2:
        addl ebp,12345678h // advance frac pointer
        movl [edi+SCREENWIDTH],bl // write second pixel
        shrl edx,25 // finish calculation for fourth pixel
        movb al,[esi+ecx] // get third pixel
        addl edi,SCREENWIDTH*2 // advance to third pixel destination
        movb bl,[esi+edx] // get fourth pixel
        decl [loopcount] // done with loop?
        movb al,[eax] // color translate third pixel
        movb bl,[ebx] // color translate fourth pixel
        jnz doubleloop
    and elsewhere... :)

    movl ebx,[_dc_iscale]
        shll ebx,9
        movl eax,OFFSET patch1+2 // convice tasm to modify code...
        movl [eax],ebx
    A similarly impressive trick is used to draw floors, where 3D interpolation is required because each texture needs to be crossed diagonally, not vertically. I never understood how Doom drew floors until I looked at the code, and I still think it's deep magic. And that's without even mentioning the BSP code!
  7. Article copied from Code Maestro? by TomerM · · Score: 1 · on Origin of Quake3's Fast InvSqrt()

    The original article that came out more than a year and a half ago, right after Quake's source code has been revealed, has been published at Code Maestro: http://www.codemaestro.com/reviews/review00000105. html
    If someone doesn't have any good ideas of his own for writing articles, perhaps he should have picked another profession...