Page 10 of 10

Posted: Sat Mar 02, 2013 10:16 am
by Stef
peekpoke wrote:
TmEE co.(TM) wrote:So you cannot push the pixels closer together on Stef's code ?
Cant give u definitely answer right now :) As i understand, Stef's bitmaps routines are fast, because they treat pixels as bytes instead of nibble (8 bit, instead of 4 bit) - so because of this bitmap is "vertically interlaced" on screen. But to be true i didnt looked into his routines very closely... I may be completely wrong! But even if i right, probably, here is some way to switch it to 4bit mode... If Stef read this, and its not difficult for him, he may comment on this issue.
Actually the bitmap engine use 4 packed pixel as the MD does.
So you can easily double pixel by writing c | (c<<4) to the buffer.
I modified the drawSlice method this way :

Code: Select all

inline void drawSlice( u8 screenX, SLICE *slice )
{
        if( slice->sliceHeight == 0 ) return;

        u8 offsetY   = ( slice->sliceHeight >  64 ) ? ( 0 ) : ( 32 - ( slice->sliceHeight >> 1 ) );
        u8 overflowY = ( slice->sliceHeight <= 64 ) ? ( 0 ) : ( ( slice->sliceHeight - 64 ) >> 1 );

        register u8 heightY   = ( slice->sliceHeight >  64 ) ? ( 64 ) : ( slice->sliceHeight );
        register u16 textureInc = divlut[slice->sliceHeight];
        register u16 textureY =  ( overflowY * textureInc );
        register u16 *texturePtr = &textures[ slice->textureId ][ slice->textureOffset ];
        register u8 *screenBuffer = &bmp_buffer_write[screenX + ((offsetY + 16) * BMP_PITCH)];

        while( heightY )
        {
            register u16 c = texturePtr[ textureY & ~63 ];
            *screenBuffer = c | (c << 4);
            screenBuffer += BMP_PITCH;
            textureY += textureInc;
            heightY--;
        }
}
It's almost as fast and draw doubled pixel :)

Posted: Sat Mar 02, 2013 1:08 pm
by peekpoke
Stef wrote: It's almost as fast and draw doubled pixel :)
Thank you very much!

Posted: Sat Mar 02, 2013 6:06 pm
by Chilly Willy
Treating each pixel as a byte also allows you to do some pseudo-dithering for more colors... you could store (c | c<<4), or you could store c1c2, where that is two colors chosen to make a different color. On composite video, this works pretty well, and is a common affect in many MD games for more color.

Posted: Mon Feb 23, 2015 4:50 pm
by Nitro
How much performance it will costs to build the game around sectors like Build Engine does?

Seems like a good choice -- you just stick with portals one room with
another.

http://msx.gnu-linux.net/doomlike/doomlike.html And what can you say about this article? It's covers 8-bit computer, imagine what Genesis could pull off.