OpenGL Small Framework

[xearokool]

Somebody posted a link to a 1k OpenGL framework. I cant find the post again, I looked and looked.

I had some trouble with the posted framework, as I am trying to get it to work in Code::Blocks. I made a slight change, and now it works a charm.

Code: [Select]


#include <windows.h>
#include <GL/gl.h>

int main()
{
   PIXELFORMATDESCRIPTOR pfd;
   pfd.cColorBits = pfd.cDepthBits = 32;
   pfd.dwFlags    = PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;


   PVOID hDC = GetDC ( CreateWindow("edit", 0,
                        WS_POPUP|WS_VISIBLE|WS_MAXIMIZE,
                        0, 0, 0 , 0, 0, 0, 0, 0) );
   SetPixelFormat ( hDC, ChoosePixelFormat ( hDC, &pfd) , &pfd );
   wglMakeCurrent ( hDC, wglCreateContext(hDC) );

   ShowCursor(FALSE);

   do {
       glClear ( GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT );
       // insert Breakpoint winning 4kdemo here
       SwapBuffers ( hDC );
   } while ( !GetAsyncKeyState(VK_ESCAPE) );
}


All I did was change void WINAPI WinMainCRTStartup() to int main(). I cant get it to compress down to 1k, more like 2.65k, wich is still good. Hopefully this is usefull to someone.

[benny!]

Somebody posted a link to a 1k OpenGL framework. I cant find the post again, I looked and looked.

You'll find some neat information about 4kb development here :

http://in4k.untergrund.net/index.php?title=Main_Page

The framework is stored here :

http://in4k.untergrund.net/index.php?title=Aulds_OGL_Framework

I cant get it to compress down to 1k, more like 2.65k, wich is still good.

Have you tried cap-dropping with a shrinker like Dropper :

http://gem.intro.hu/dropper.htm

[taj]

I know this framework quite well :-)

Get the framework from the link Benny posted and study the makefile and makesmall script in it. The three main tricks therefore are:

* use -nostdlib in the makefile
* Convert from an exe to a com file using dropper 2.0 (provided in the package)
* Compress the com file using apack with standard settings

I believe the framework should be 450-460 bytes. A bit over 500 without ordinal import (the /n flag to dropper).

I dont know code::blocks but make sure you are using C compilation, not C++. Once you exclude stdlib...you may find a link error with just int main ... its not clear to me how this would resolve to WinMainCRTStartup...and it needs to.


Oh one thing, the framework is aulds...so we really should credit him we use it, which I didnt in trinity - ooops!

[Jim]

There are so many violations of Windows' programming standards in that snippet I'm surprised it works at all!
But, anything to get the size down I suppose.

Jim

[Rbz]

I believe the framework should be 450-460 bytes. A bit over 500 without ordinal import (the /n flag to dropper).

I did it in Visual C 6.0 and the final packed file size was 437 bytes   

There are so many violations of Windows' programming standards in that snippet I'm surprised it works at all!
But, anything to get the size down I suppose.

Jim

Oh yeah, for those crazy 1k intro coders 

[taj]

Jim: it doesnt always work :-( and it leaves the stack corrupt.

Rbraz: wow! Maybe I'll have to shift to Visual C++! Could you get it below 400 in asm do you think? How many Karma to do it :-)

[Jim]

One reason it got bigger when you changed WinMainCRTStartup() to main() is that you are now bringing in chunks of the C runtime library startup code.  When your program runs normally (either a WinMain() program or a main() program) WinMain/main isn't the first function that's called.  Usually there's a stub tacked on the front, called crt0.o or something similar, which does all the initialisation for the stack, the heap, file handles, the clock, program arguments, and the rest of the C runtime, and the very last thing it does is call WinMain or main.  By having WinMainCRTStartup in a Windows program you avoid having the runtime startup in there because you've overridden it, but then if you try calling C functions or much other stuff it will barf.  Sometimes you can find out the name of the function before main() in a non-Windows program and override that too.
So that's the size problem.

It doesn't look to me like the stack would get messed up, but there's a problem with the PIXELFORMATDESCRIPTOR.  The code assumes the stack has all 0s in it at least, so that pfd is all blank. I think Windows might guarantee that, else it might let you look at the stack from some old program that just ran which could be a security issue, but I wouldn't know for sure.  Even then though, that's wrong.  I would think you'd have to add this to be totally sure, even if it was all 0s.

Code: [Select]

pfd.nSize = sizeof(PIXELFORMATDESCRIPTION);
pfd.nVersion = 1;

Then there's the CreateWindow.  It's being subclassed off an "edit" style window (like text boxes), which is probably OK, and means there'll be a basic message pump happening, but the Windows API doesn't say what happens when you pass a caption of NULL and width and height of 0,0.  I suspect that's OK, especially since WS_POPUP windows have no caption.  I also don't know whether "edit" style windows have CS_OWNDC class style, so the fact that ReleaseDC isn't called might be significant - if it doesn't let's hope Windows doesn't try drawing to our window.  That bit right there is a cute but nasty hack

There's also no clean up at the end, but I guess that's to be expected

Jim

[taj]

Jim,

I honestly dont know exactly why this fails sometimes. It fails as far as I can tell about 2-3% of the time. This tends to get masked by import by ordinal or shader issues or in at least one of my cases by just bad code :-). I have achieved better stability by moving the pfd declaration to global scope and making it static (forcing it under C99 standard to be all zeros). However I've even seen this fail and its a byte or two more. Maybe size and version matter but if so, I'd expect it to fail much more regulalry than it does.

The releaseDC is an interesting thought...

[Jim]

I'm just clutching at straws.  According to most Windows programming manuals, the smallest loadable segment size is supposed to be 4Kb, so it's all way out of spec anyway   I'll be honest and say that it's algorithmic beauty and correctness that keeps me interested in computing, not being able to write the smallest or fastest piece of code, though I have been known to participate in that kind of malarkey.

Jim

[Rbz]

Rbraz: wow! Maybe I'll have to shift to Visual C++! Could you get it below 400 in asm do you think?

@taj:  I forgot to reply here  , I have attached the Visual C++ 6.0 project that I did, take a look at it, maybe it could be useful for you or someone else, Gravity Theory was coded with this one

Btw, I did an ASM framework using FASM, and the final packed file size was 427 bytes ( 10 bytes smaller  ), maybe it could be smaller using MASM which I'll try to do at some stage...  Still, I like FASM and I'm coding my first attempt to 4kb entirely in ASM.

 

[taj]

cheers rbraz..once tried to get lower using masm than with this framework, came out as more bytes :-). Guess that means either we were very bad at asm or very good at C. Or both.

[taj]

I installed a newer veriosn of microsofts dev suite and now the framework breaks. However I discovered that using

Code: [Select]

void mainCRTStartup()
fixes the problems and still compresses down well. So there is the fix.

[Rbz]

Nice one, with vc6.0 I changed it to -->  int WINAPI WinMain

[taj]

I installed a newer veriosn of microsofts dev suite and now the framework breaks. However I discovered that using

Code: [Select]

void mainCRTStartup()
fixes the problems and still compresses down well. So there is the fix.

Excpet when using crinkler in which case

void WinMainCRTStartup()

seems to work under GCC.

OK Rbraz, we now have 3-4 entry points :-) depending on compiler and release of Microsoft devkit. I'm very confused but at least I have it working again!