Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by MoJo, posted on September 06, 2001

Image Description, by MoJo

Here are some screen shots of a small game that I've pretty much completed. First off, I know: the screens are too dark, the radiosity seems rushed, and I haven't fixed the popping problems for the LOD. BUUUUT, I made it to test the functionality of the engine that I've been working on. The game itself is 2D, but it uses orthographic projection in 3D (which means hardware acceleration is needed). The engine itself uses a modular rendering design, currently supporting Direct3D v7.0 & v8.0, OpenGL, and a SLOOOOOOW SoftWare module. The game is my approach at an old game, I'm not sure the origional name of it. I know it's floated around on the TI calculators, and Yahoo Games has a version of it. (The tiles are actually taken from Yahoo because I am deeeefinitely not an artist).

The game itself is very simple. There are 5 different tile types spread out on a 10x15 board. Clicking tiles that have like tiles adjacent to them earns points. You can only click a tile if there are two or more, and the more you click at once, the more points you get. Once tiles are clicked, they disappear and the tiles above and to the left fall in to fill up the gaps. The white tiles (rotating through the 5 pics on the other tiles) are randomizers. Clicking them randomizes the tile and all the surrounding tiles. To complete a level, you have to get above a certain amount of points. The pictures just show the basic idea of the game. The top left show the basic board, the top right shows fading from clicking one set to clicking another set, the bottom left shows better the fading between the white tiles, and the bottom right shows the main menu for the game.

The game itself is pretty much done (yay). Everything seems to work smoothely, looks nice, main menu, about screen, game over/completed screens, etc. I want to test the game of different platforms, and get any constructive criticizm on how I can make it better, but don't have a web site at the moment for download. If anyone wants to test/play the game or see the source code, e-mail me at I'm just on a 56k modem though, so if a lot of people want to try it, it might take a little time to send it out.

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

September 06, 2001, 03:46 PM

cool - I love to see completed games on here - keep it up!


September 06, 2001, 04:12 PM

Popping problems for LOD? This IS a 2D game right? Why would you need LOD for a 2d game?

Other than that, it is a very interesting sounding game. Nice work. Besides the above question, I only have one question, what is the name of this game?


September 06, 2001, 04:12 PM

Currently I'm working on a similar game too! (A Tetris Clone)
But here is my problem: How can I use multiple APIs ?!
Such as DX and OpenGl?!
I thought in this way:
Create a Super Video Class and a class for every API.
For Picture Loading I wrote a Pic Loader that loads Pictures in my
own format:

typedef struct tColorComponent
char r;
char g;
char b;
char Alpha;
} ColorComponent;

typedef struct tApiContext
DWORD dwSize;
void *FrameBuffer; // for example this is a direct draw
} ApiContext; // surface in DX mode

typedef struct tPicture
int SizeX, SizeY;
ColorComponent *Data; // real Image
ApiContext RenderData; // API Image
} Picture;

But there must be a lack in design because
it doesn't work ;-(
So how to support multiple api in the right manner?!

And then where to go on?!


September 06, 2001, 04:13 PM

nice. and grats for completing a game!


September 06, 2001, 04:17 PM

What you do is abstact the calls to the api, and set some kind of variable to figure out which api your are using. So, like

Engine.Initialize(USE_OPENGL, 640, 480, 16, other variables);



Engine.Initialize(USE_DIRECT3D, 640, 480, 17, other variables);

And graphic calls are also abstracted within your classes and stuff. Basically, you keep any api specific calls and code within your class. Does that make sense?


September 06, 2001, 04:23 PM

What you do is abstact the calls to the api, and set some kind of variable to figure out which api your are using. So, like

Engine.Initialize(USE_OPENGL, 640, 480, 16, other variables);



Engine.Initialize(USE_DIRECT3D, 640, 480, 17, other variables);

And graphic calls are also abstracted within your classes and stuff. Basically, you keep any api specific calls and code within your class. Does that make sense?


September 06, 2001, 04:38 PM


Engine.Initialize(USE_DIRECT3D, 640, 480, 18, other variables);


September 06, 2001, 05:14 PM

Lol, that is one way of pointing out my mistake. I guess I meant 16 (but I think you figured that out).

zed zeek

September 06, 2001, 05:54 PM

please tell me youre taking the piss
copy that virgil


September 06, 2001, 05:56 PM

Okay, sorry for not replying yet, I just found out my picture was posted (yay). Also, as for the popping and LOD, I was joking. Everyone always replies that the LOD and popping suck and the picture is too dark, so I said it before hand (even though, no, it doesn't have any of that stuff even). As for the modules, I actually have global functions in the header file. These are abstract functions with all my own enumerators and structs and stuff. (Ala SetMode, SetRenderState, CreateTexture, etc) all the image loading is abstracted from that even, I just have a general 32BPP RGBA class for loading images and storing the data, then a SetTextureImage function which converts (internally per API) the general RGBA image to the texture. In the engines CPP file, I just have function pointers that I import from the DLL that I want to use. So when you call the SetMode function, IT calls the modules SetMode function internally, so it doesn't know how or what to do, it just does it, and the module takes care of the rest. (I know I probably don't make any sense here though).

zed zeek

September 06, 2001, 06:01 PM

it looks very similar to maj-jong(sp)
though this looks pretty 2d, are there tiles under the visable tiles?
finishing something is the most difficult thing about making games, ive been working on mine for over 3 years :( + its still not finished.
in the meantime ive written at least 50 demos


September 06, 2001, 06:08 PM

Oh yeah, as for the name, it doesn't have an official one. The project is just titles GEK Blocks (GEK is the name of my engine).


September 06, 2001, 06:15 PM

Zed: No, it's just a flat layer actually. The goal is to click tiles that have similar adjacent tiles, the more that are connected with a single click, the more points you get, and you have to get a certain amount of points to move to the next level.

Evil Bill

September 06, 2001, 06:20 PM

You can do it the way that i do: using DLLs. Keep the class interface the same throught the header, but have the actual code different. You can LoadLibrary() the correct DLL (Direct3D.dll or OpenGL.dll, or even enumerate the DLLs in a directory to pick up e.g. Glide or software rendering), and recieve a pointer the the render class from a function in the DLL. Then you just use the class as normal.

Well, thats one way to do it i suppose - it means that you don't have to implement both OpenGL and Direct3D in you engine, so you could implement just D3D, and add OpenGL later if you wanted.



September 06, 2001, 06:23 PM

Also, maddoc: Try using a virtual class approach (from the code you posted, that might be easier than what I said earlier). eg:

class SurfaceBase
virtual Blahhh(blahh) = 0;
virtual Release() = 0

class RenderBase
virtual SetMode(blahhh) = 0
virtual Release() = 0
virtual SurfaceBase *CreateSurface(bleh) = 0;

And this would be in the main file, RenderBase get's passed around or whatever anytime you want to create/render stuff. Then in the seperate API file you'd have

class APISurface : public SurfaceBase

class APIRender : public RenderBase
SurfaceBase *CreateSurface(bleh)
return new APISurface;

Then, to create a new renderer, you'd say RenderBase *Render = new APIRender. Does this make any sense? There are quite a few threads about virtual classes and inheritance in the message center if you need better examples.


September 06, 2001, 06:29 PM

hehe, yupyup, Evil Bill, posted prolly as I was typing, it soundz like he's using the same virtual type method I posted, putting the inherited classes into a seperate DLL, and that RenderBase *Render = new APIRender is a function in the DLL, it just returns a constructed pointer to the inherited rendering API's class. That way you only have to retrieve that single function from the DLL, and then call that function, ala RenderBase *Render = CreateRender()


September 06, 2001, 06:43 PM

It should work...


September 06, 2001, 07:01 PM

If you #define then you only support different APIs at compile time, and not at runtime.



September 06, 2001, 10:07 PM

Its too dark and where is the source?


Actually, quite nice... what is it? Oh I should read the description, bah.

When will you finish it?



September 06, 2001, 10:36 PM



September 06, 2001, 10:37 PM

of wood, but I think u all are clever enough to understand me


September 06, 2001, 10:47 PM

Speaking of wood, isn't the crate texture from the NEHE tuts, you thief of textures you ;)

-good to see someone finishing something, looking good.


Alex Taylor

September 06, 2001, 11:13 PM

That texture certainly seems to do the rounds.


September 07, 2001, 12:20 AM

Mwahaha, yupyup, NeHe's crate texture (now lets just find out where NeHe got it from =) I actually am noooot a graphic designer, the water texture (behind the tiles) is actually from Romka Graphics site too.


September 07, 2001, 12:23 AM

And EGreg, sorry, I don't have a web page at the moment (my last site went belly up, even though the provider even says nothing is wrong with the site, hmmm). I can try to e-mail it, but I'd prefer to get it posted somewhere, since I'm only on a simple 56k dialup.

Peter Mackay

September 07, 2001, 03:26 AM

It's usually the deciphering that's the problem! :-p


September 07, 2001, 06:24 AM

I'd create a base renderer class and then derive different renderers from it. These derived renderers would then
be loaded by the engine itself from an DLL.

Kasper Fauerby

September 07, 2001, 06:42 AM

Just to clear up what's already been said about using multiple APIs with virtual classes:

What you can do is to create an abstract interface for a "GraphicsDriver" class. You declare its functions as "pure virtual" and make them so they operate on your own API-independant structures. For example, you'll probably need a function to render an indexed list of triangles:

class GraphicsDriver {
virtual RenderIndexedList(VECTOR *vertices, int num_vertices, WORD *indices, int num_indices)=0;

Then you create classes for each API that you wish to support. For example for d3d and openGL

class DxDriver : public GraphicsDriver {
RenderIndexedList(bla bla);

class GLDriver : public GraphicsDriver {
RenderIndexedList(bla bla);

It's important that you declare the functions in the BaseClass for PURE virtual (the =0 bit after each function). This will make the class to be "Late Binding" (I think it's called) meaning that the compiler will call the version of the function from the class a variable is instanced from (hard to explain)

For example you can declare a variable like this:

GraphicsDriver *gfxdriver = new DxDriver();
GraphicsDriver *gldriver = new GLDriver();

Because the interface is pure virtual the gfxdriver variable will call ONLY the functions in the DxDriver class and gldriver will call those in the GLDriver class. If you had just made the functions 'virtual' then the compiler would call the version of the functions found in the GraphicsDriver class because the variable is a pointer to that class even if it's instanced to a derivation of that class.

Anyway, now you can make your functions to use simply a 'GraphicsDriver' variable and forget about which API is in use. The engine will decide which API to use when it creates the GraphicsDriver variable and then never think about it again.

Hope this made some sense :)

- Kasper


September 07, 2001, 07:25 AM

ok but what you talked about I already know.
I thought more in the way whether the api-context idea
isn't too slow.
A example

i_Renderer = DIRECTX_RENDERER; //maybe later I will implent a console
// so it's done over variables

GraphicSystem.Init (ResX, ResY, Bpp);
So all Graphics that are loaded will be in the Picture struct.
Once in the "Colorcomponent Format"
-> Independet of a given file format
And second
-> In the ApiContext.FrameBuffer which is a DirectDraw Surface

Does anybody see any Problems in this method?!
Speed, Memory etc. ?!


September 07, 2001, 09:44 AM

I think this should be:

GraphicsDriver *gfxdriver = new DxDriver();
GraphicsDriver *gfxdriver = new GLDriver();

This thread contains 36 messages.
First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.