simple output setup for software rendering

category: code [glöplog]

I've got a small-ish problem. I'd like to do some software rendering but don't know how to output my images properly. Making a texture and rendering with OpenGL felt stupid and wasn't that fast, SDL didn't do the trick either and is way too big.

So I'd like just to have a buffer that gets directly drawn to the screen. How should I go about it?

added on the 2010-06-21 15:43:19 by msqrt

http://code.google.com/p/pixeltoaster/
all you need.

added on the 2010-06-21 15:44:32 by Gargaj

What OS(es)?

added on the 2010-06-21 15:44:47 by psonice

Windows. Wouldn't hurt to have more platforms, but I think this kind of stuff is quite OS dependant.

added on the 2010-06-21 15:46:36 by msqrt

Thanks Gargaj, I'll look into that o/

added on the 2010-06-21 15:49:07 by msqrt

Why didn't SDL do the trick? What is "way too big"?

added on the 2010-06-21 15:58:22 by xeron

I always use this:

Code:


#define XRES 800
#define YRES 600
#include <windows.h>
static BITMAPINFO bmi = { { sizeof(BITMAPINFOHEADER), XRES, -YRES, 1, 32, BI_RGB,
                            0, 0, 0, 0, 0 }, { 0, 0, 0, 0 } };
static DEVMODE screenSettings = { {0}, 0,0,156,0,0x001c0000, {0}, 0,0,0,0,0, {0},
                                  0,32,XRES,YRES, {0}, 0, 0,0,0,0,0,0, 0,0 };
static long buffer[XRES*YRES];

void intro_init( int xres, int yres );
void intro_render( long *buffer );

// viod main( void )
void entrypoint( void )
{
    // set fullscreen
    if( ChangeDisplaySettings(&screenSettings,CDS_FULLSCREEN) ) return;
    ShowCursor( 0 );

    // create window
    HDC hDC = GetDC( CreateWindowEx( WS_EX_TOPMOST, "static", 0,
                     WS_VISIBLE|WS_POPUP|WS_CLIPSIBLINGS|WS_CLIPCHILDREN, 0, 0, 
                     XRES, YRES, 0, 0, 0, 0 ) );
    // initialize demo
    intro_init( XRES, YRES );
    do
    {
        // render a frame
        intro_render( buffer );
        // copy to the screen
        StretchDIBits(hDC,0,0,XRES,YRES,0,0,XRES,YRES,buffer,&bmi,DIB_RGB_COLORS,SRCCOPY);
        // loop until ESC
    }while( !GetAsyncKeyState(VK_ESCAPE));
}

added on the 2010-06-21 19:41:21 by iq

before pixeltoaster that is several c++ classes and is made to support floating point framebuffers, gaffer wrote tinyPTC.
It's may be more old, but you might like it.
C, minimal api(init, close, blit. thats all).
Uses directdraw Some mmx conversion routines (need to setup nasm into visual studio if you need recompile).

Was intensively used by demos and intros quite a few years ago.

quote :

Quote:

You say it has a C++ API, are there C bindings as well? My architecture does not have a working C++ standard library, nor do I feel like porting one.

Gaffer
sorry, no c bindings at this time — it is a library written in c++
if you prefer c, then use TinyPTC instead. you can get it from sourceforge.

Entropia
Can PixelToaser be used to create tiny programs like TinyPTC? I really wouldn’t want to be using a 20k-DLL for a 64k intro…

Gaffer
nope. keep using TinyPTC for 64k intros – PixelToaster is not meant for that

added on the 2010-06-21 20:04:04 by HeLLoWorld

what iq said.
although you can make it look a bit nicer at the price of a few bytes, probably ;p

added on the 2010-06-21 20:07:17 by shuffle2

iq, seems very nice ; I like minimal stuff.

What, no message pump! :)

Also, I always wondered if gdi was slower than ddraw or dx8/9+blit to surface...

I always heard gdi was veeery slow to blit but maybe it depends on the version of windows and maybe new windows librairies are either mmx or sse or even somehow hardware accelerated, i dont know...some gdi blits seemed fast, that puzzled me.

In my experience when you blit into vram, windows memcpy is not optimal, i've read articles about how there are huge improvement (maybe 10 times, dont remember) by using simd, align, prefetch, etc.
But then again maybe newer windowses have all that modernized.

Btw again, i wonder if there can be a difference between the memcpy in static libs in visual studio(user32.lib maybe, dunno) and dynamic libs...
One can imagine that when you install windows, since it knows on which processor it runs, it chooses to use some dll with sse if available, etc, depending on the things available on the architecture, but then you wouldnt be able to boot with another processor (unless theres some boot check)...So does it mean everything in older windows is not optimal code...Oh well.

If anyone wants to share some thoughts/info :)

added on the 2010-06-21 20:18:14 by HeLLoWorld

oh, yes, its not my topic.

added on the 2010-06-21 20:18:50 by HeLLoWorld

Yeah, that minimal stuff is awesome. Specially when you end up with a black window that doesn't move out of the screen, and you have to reboot or suspend to get rid of it.

added on the 2010-06-21 20:33:40 by xernobyl