view release on metacpan or  search on metacpan

bin/qbix/QbixRube.cpp  view on Meta::CPAN

rube can be categorized (into directories?) according to piece locations
or some reasonable subspacing mechanism. ~8bytes is far less than 40.
Save files as the moves to get to solved from that state.
eg. R2YW-B-W-O2   If my compression approximation is anywhere close, I
could store almost 1million rubes in 8MB of memory or hard disk space.
1GB of disk space should store nearly 128million rubes.  If nicely
serchable, that would be quite an index depth to leverage for solutions!
Keep in mind that the first move has 18possibilities since 6 sides could
be terned any of 3 ways but a different side must be terned next
therefore every move of depth has 15 possibilities which fits nicely in
4bits.  As long as you know the first move (0-17), every following tern
can be succinctly described as a single hex digit (0-E).

Holy smokes!  At 8192 bytes per directory, using a FAT filesystem is NOT
the right way to subpartition the space!  ~190,000 possibilities would
munch 1.5GB in just directories alone!  Minimize directories!  Maximize
compressed flat files and lutlutluts!  How?  hmmm...

The above compression would be great if I wanted to always squish whole
rubes but for a nicely indexed solution space, I need a sequential space
of all possible rubes to look up a direct && optimal solution for any
current space.  I need a function that returns a unique identifier for
any rube.  So maybe that identifier can be the above compressed
representation of any rube.  It's gonna be a lot one way or another!

Let's say that the average compressed rube is 72bits (9bytes)... it
might be worthwhile to not silly compress so that all rubes are always
76bits (9.5bytes) and can be aligned on 10byte boundaries in phat files.
But the opportunity to shave around two bytes off each representation as
the number of stored rubes gets huge is also terribly important.  The
whole thing is worthless if it can't be serched quickly.  But a quick
serch is also useless without a substantial amount of data... ok...

I need a direct sequential index of all states.  A method for wasting no
intermediate states so that state 0 is solved and state n.  Any of the
24 possible positions for any corner or edge can be represented by
letters A..X  NiceNice.  Any uncompressed Rube can be 20 A-X chars.

What do I know about possible states?  Any piece can be anywhere and
parity holds.  Therefore, I should always be able to determine the
location AND pronation of c7 && e11.  I don't know of any other
governing rules by which to determine solvability.

The idea is to bruteforce depth-first from solved to populate a massive
data structure which can be indexed directly from mixed back to moves to
the optimal solution.

I'm thinqing directories for e0-3,c0-3,e8-11... compression problem!
The subdirs would subpartition the problem space at the cost of the
saved space the compression could accomplish... I must implement it so
flexibly that a whole spectrum of implementations can be evaluated.

From the serch, I can check e0 && look for dir: if found, cd e0 && look
for e1, else look for file beginning with e0(e1...etc.) er the file name
should reflect the compressed method.
*/

#include <windows.h>
#include <stdio.h>
#include <math.h>
#include <gl\gl.h>
#include <gl\glu.h>
#include <gl\glaux.h>
/*
#include <dinput.h>
//#include "dinput.h"

LPDIRECTINPUT7              g_DI;
LPDIRECTINPUTDEVICE7        g_KDIDev;
*/
HDC             hDC=NULL;
HGLRC           hRC=NULL;
HWND            hWnd=NULL;
HINSTANCE       hInstance;

GLuint  base;

bool    keys[256];
bool    active=TRUE;
bool    fullscreen=TRUE;
bool    rubemode=TRUE;
bool    bluemode=FALSE;
bool    dbugmode=FALSE;
bool    helpmode=FALSE;
bool    demomode=FALSE;
bool    inptmode=FALSE;
bool    invemode=FALSE;
bool    alinmode=FALSE;
bool    twrlmode=FALSE;
bool    flipmode=FALSE;
bool    solvwhol=FALSE;
bool    showtext=FALSE;
bool    light,lp,tp,fp,mp,sp,dp,up,qp,ip,jp,kp,ap;
bool    f1p,f2p,f3p,f4p,f5p,f6p,f7p,f8p,f9p,entp,bksp;

GLfloat gapp = 2.09f; //2.03 for newwdrawpiec
GLfloat crot = 1.0f;
GLfloat xrot = 0.0f;
GLfloat yrot = 0.0f;
GLfloat xspd = 0.0f;
GLfloat yspd = 0.0f;
GLfloat zdep = -16.7f;
GLfloat z    = -16.7f;

GLfloat LightAmbient[]=         { 0.7f, 0.7f, 0.7f, 1.0f };
GLfloat LightDiffuse[]=		{ 1.0f, 1.0f, 1.0f, 1.0f };
GLfloat LightPosition[]=	{ 0.0f, 0.0f, 2.0f, 1.0f };

//this is a lut for lefts... indexes are [front][up] ... 6 == !-e
GLuint leftable[6][6]=    { 6,2,4,6,5,1, 5,6,0,2,6,3, 1,3,6,4,0,6,
                            6,5,1,6,2,4, 2,6,3,5,6,0, 4,0,6,1,3,6 };
GLuint cornmapp[6][6][8]= { 15,15,15,15,15,15,15,15, 0,1,2,3,4,5,6,7, 3,0,1,2,7,4,5,6,
                            15,15,15,15,15,15,15,15, 2,3,0,1,6,7,4,5, 1,2,3,0,5,6,7,4,
                            1,0,6,7,5,4,2,3, 15,15,15,15,15,15,15,15, 0,6,7,1,4,2,3,5,
                            6,7,1,0,2,3,5,4, 15,15,15,15,15,15,15,15, 7,1,0,6,3,5,4,2,
                            0,3,5,6,4,7,1,2, 6,0,3,5,2,4,7,1, 15,15,15,15,15,15,15,15,
                            5,6,0,3,1,2,4,7, 3,5,6,0,7,1,2,4, 15,15,15,15,15,15,15,15,
                            15,15,15,15,15,15,15,15, 7,6,5,4,3,2,1,0, 6,5,4,7,2,1,0,3,
                            15,15,15,15,15,15,15,15, 5,4,7,6,1,0,3,2, 4,7,6,5,0,3,2,1,
                            3,2,4,5,7,6,4,1, 15,15,15,15,15,15,15,15, 5,3,2,4,1,7,6,0,
                            4,5,3,2,4,1,7,6, 15,15,15,15,15,15,15,15, 2,4,5,3,6,0,1,7,
                            2,1,7,4,6,5,3,0, 1,7,4,2,5,3,0,6, 15,15,15,15,15,15,15,15,
                            7,4,2,1,3,0,6,5, 4,2,1,7,0,6,5,3, 15,15,15,15,15,15,15,15 };