Jump to content
  • Advertisement
  • entries
  • comments
  • views


Sign in to follow this  


One of these days I'll get back to regular postings lol. I've been kind of...stalled I guess. I've been trying to get a project up and running and it just wasn't working for me. One of the problems I always have is that I hate writing the starting code (not that I really hate it, it's just menotenous to write the same exact code everytime I want to start a project. Even encapsulating it gets old because I still have to write the same code, just less. A while back I had come up with an idea, but the design required DLLs and a few parts were giving me issues and I gave up on it. However, I came back to the idea, but threw out DLLs for static libs. And thus, Beelz RGDK is born.

The idea is pretty much exactly the same, just without the pros and cons of DLLs. At the moment its still very "bare-minimum", but I've got a list of stuff that I'm going to add. Once I get the stuff I need in it, I'm picking back up a project that everyone seemed to love in the beginning, but I totally mutilated lol. I've finished the design already and it's quite different from before, but still the same (yea, doesn't really make sense, but that's the best way to describe it.) Anyway, as soon as I have something to show, it'll be up here.

[ Beelz RGDK ]
First off, in case anyone is wondering, RGDK stands for rapid game development kit.
Beelz will have pretty much everything I need to make any general game, but I'm making it module based so that I can implement different genre-specific modules to make different kinds of games. I'm designing it specifically for 2D, but with plans on implementing 3D after a couple projects (specifically, after the project I mentioned above and Project AWiR.) I think 2 projects will give me sufficient time to get the kinks worked out of the 2D functionality as well as the UI. I'll probably have another 2D project or two in the works while I add the 3D functionality, that way there's not a huge gap between releases (seeing as how I have a LOT to learn before I can make a decent, functional 3D game.)

At the moment, the smallest code-sample for making a game is:


bool Beelz::CreateGame(Beelz::BaseGame **Game)
return ((*Game) = new Beelz::BaseGame()) != 0;
// I've made a macro for now (not sure whether I'm going to keep it.) It's pretty much the above function with a couple conditionals.
// Beelz_CreateGame(GameClassType)

That starts the system, sets up a window, the graphics system, and the audio system. There are currently 15 functions that can be overriden in BaseGame (7 of which are input handlers.) It's really just a bare "BaseApplication" type class.

My test bed code looks like so ATM:

#include "../Beelz/Beelz.h"
#include "../Beelz/Window.h"
#include "../Beelz/Graphics.h"

class MyGame : public Beelz::BaseGame
Beelz::Graphics::Texture CursorTexture;
float CursorX, CursorY;
bool OnLoad()
Beelz::SetWindowCaption("Beelz Test Bed");

if(!CursorTexture.LoadFromFile("Cursor.png", 1))
return false;
return true;

void OnShutdown()

void OnFrame()
Beelz::Graphics::DrawImage(CursorX, CursorY, 0xffffffff, &CursorTexture);

void OnMouseMove(long CursorX, long CursorY)
this->CursorX = float(CursorX);
this->CursorY = float(CursorY);

void OnFocusGained()

void OnFocusLost()


The graphics system currently has functions and structs for drawing images, enumerating hardware, taking a screenshot (and optionally adding a caption), color manipulation, and changing the device settings with plans for adding camera systems, effects, and animation.
The window system only has some basic stuff at the moment (get/set the caption, get/set the window style, and get/set the window's client size (based on the window's style).) I can't really think of anything else to add really.
The input system hasn't been started yet, but it'll have stuff for clipping the cursor, getting/setting the cursor's position, etc. I'm still trying to decide whether or not I want to add XInput support.
As always, a network system would be awesome, but I still don't have any experience there and I don't really care to make any MMOs for quite some time. However, I would really like to at least add some functionality for peer-to-peer for gaming like Baldur's Gate/Icewind Dale had or something.
Again, as always, the GUI environment is probably where I'll spend the most of my time (I just love GUI design and development for some reason.) I have plans for all of your basic controls as well as some other stuff.

BaseGame class
uint, uchar, ulong, and ushort typedefs

DepthStencilFormats enum
AdapterInformation struct
DeviceSettings struct
Texture class
ColoredVertex class
ColoredTexturedVertex class
DisplayMode class

SetAlpha(Color, Value)
SetRed(Color, Value)
SetGreen(Color, Value)
SetBlue(Color, Value)

SetPerspectiveToOrtho(Width, Height, NearZ, FarZ)

DrawQuad(X, Y, Width, Height, Color)
DrawSubImageStretched(X, Y, Width, Height, Color, Texture, SourceX, SourceY, SourceWidth, SourceHeight) // This is the main drawing function; the rest of them are inlines that call this function.
DrawSubImage(X, Y, Color, Texture, SourceX, SourceY, SourceWidth, SourceHeight)
DrawSubImageScaled(X, Y, ScaleX, ScaleY, Color, Texture, SourceX, SourceY, SourceWidth, SourceHeight)
DrawImage(X, Y, Color, Texture)
DrawImageStretched(X, Y, Width, Height, Color, Texture)
DrawImageScaled(X, Y, ScaleX, ScaleY, Color, Texture)

GetAdapterInformation(AdapterOrdinal, Information)
EnumerateDisplayModes(AdapterOrdinal, ModeCheckCallback, SupportedModes)
EnumerateDepthStencilFormats(AdapterOrdinal, FormatCheckCallback, SupportedFormats);


WindowStyles enum



ResizeWindow(Width, Height)

That's the entire RGDK at the moment lol. Not much, but hopefully after a little while it'll be more functional and whatnot.

Obviously, there are a few flaws with it, but I'm not quite sure how to handle them. The most apparent one right now is the fact that it assumes that I'm creating an instance off the stack and not setting it to a pointer (the system deletes it before finishing.) I could fix this by assuming the opposite, but that's as hazardous. However, I'll deal with that when it becomes a problem I guess.

Anyway, back to the code. Hopefully I can have something up in a couple days (even if it's just a lame screenshot XD.)

As an aside, I don't plan for this to be uber-powerful (thus "Rapid" Game Development Kit.) I'm going to use this to actually get some games finished. Coupled with this is the fact that all of the projects I've got planned, are "funny" games. I'm not going to try to make my serious projects; I'm going to make spoof RPGs, games that don't really make any sense, and in essence, are just funny (or 'stupid funny.') In a few years, after I've got some projects actually completely finished (instead of half-arsed, half-finished 'demos'), I'll make something to do some decent games. Hopefully by then I'll also have at least someone to help with graphics lol (i.e. a team, even if it is just two of us.)

Hm...I got the camera system implemented as well as a waypoint system for it. I'm kind of torn though. With the current system, lets say you made 3 cameras (hypothetically, each one represents a point of interest.) Before each rendering, you have to call "Beelz::Graphics::SetCamera2D()", supplying the camera, and it switches to that camera. Now, the part where I'm torn: should it smoothly "move" to the new camera, or just jump? Maybe make it optional?

And having typed all of that, I realize a little flaw. The camera has a speed setting, and it occurs to me that a time version would work better. Makes more sense really "Move to this location in X seconds" instead of "Move to this location X units/second." And then I could change SetCamera2D(Camera) to SetCamera2D(Camera, Time) and supplying 0 for the time would make it instant. Hooray for blogging and "thinking aloud." lol

That also seems to solve another problem I was having. At the moment (I was going to fix it), I get the next waypoint, do a bunch of calculations, and then move the camera. With this I could just store the waypoints as { X, Y, StepX, StepY } and do all of the calculations at the point when the waypoint is added.

Of course, I get that implemented and it sheds light on a problem with it: a 5 second commute over a {10px, 10px} distance is quite slow. So, I'm going back to the other system and I'm going to add some optional parameters to SetCamera2D(). Though, quite honestly, I'm not really sure this is best to be implemented directly into the Camera class anyway; seems more suited for an "attach to entity" setup. That way you would only create 1 camera, attach it to an entity and the entity itself would have a script to follow (this way you could do more fantastical stuff like follow the entity to a point, have some text output to the screen, follow it to the next point, etc, etc.)

However, that has issues too (design issues though; because Beelz doesn't have an Object class or anything, so I'd have to either implement that now or have the camera take a pointer to a vector or something (like I used to), but I'm not too fond of that.) I guess I'll think on it and try to decide while I'm at work tomorrow.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!