Well I'm back. Been working on different projects and stuff. So I haven't had time to post any thing in a while. What this post is going to be about taking a really big nasty class and transform it into a set of smaller more manageable objects. Here is the the simple example class we are going to cross cut.
class Test {
public:
Test() {
r.init(100, 100, 32, 32);
}
void update() {
Uint8* cur = SDL_GetKeyState(0);
if(cur[SDLK_LEFT]) {
r.x -= 1;
} else if(cur[SDLK_RIGHT]) {
r.x += 1;
}
if(cur[SDLK_UP]) {
r.y -= 1;
} else if(cur[SDLK_DOWN]) {
r.y += 1;
}
glBegin(GL_QUADS);
glVertex2f(r.x, r.y);
glVertex2f(r.x+r.w, r.y);
glVertex2f(r.x+r.w, r.y+r.h);
glVertex2f(r.x, r.y+r.h);
glEnd();
}
private:
Rect r;
};
There are many problems with this class first off you have everything from input to graphic rendering in the same function. So if you a value of the rect object you could potentially screw up how you render it. And not just that its really ugly to look at too. I've written this type of code many times in the past ( and on recent occasions too :( ). So how do we fix this.
Enter Components. Component Programming allows us to take a bigger class and make smaller class from it. This means we can decouple features from a bigger object and reuse them. Looking at this c++ class example I can already figure out what 2 components. InputComponent and RenderComponent. Here is the implementation
class InputComp {
public:
void update(Rect& r) {
Uint8* cur = SDL_GetKeyState(0);
if(cur[SDLK_LEFT]) {
r.x -= 1;
} else if(cur[SDLK_RIGHT]) {
r.x += 1;
}
if(cur[SDLK_UP]) {
r.y -= 1;
} else if(cur[SDLK_DOWN]) {
r.y += 1;
}
cur = 0;
}
};
class RenderComp {
public:
void update(Rect& r) {
glBegin(GL_QUADS);
glVertex2f(r.x, r.y);
glVertex2f(r.x+r.w, r.y);
glVertex2f(r.x+r.w, r.y+r.h);
glVertex2f(r.x, r.y+r.h);
glEnd();
}
};
class Test {
public:
Test() {
r.init(100, 100, 32, 32);
}
void update() {
in.update(r);
rend.update(r);
}
private:
Rect r;
InputComp in;
RenderComp rend;
};
As you see I'm taking what was in the Test class and making smaller more manageable classes with them. This will make the Test class easier to read and to implement. Not just that I can reuse the functionality in other class such as an enemy class can reuse the RenderComp class in order to render it.
Now lets say if you want to make the RenderComp more efficient (trust me using intermediate mode isn't a good Idea). So lets use vertex arrays instead
class RenderComp {
public:
void update(Rect& r) {
PointBuf vbuf;
vbuf.push_back(Point(r.x, r.y));
vbuf.push_back(Point(r.x+r.w, r.y));
vbuf.push_back(Point(r.x+r.w, r.y+r.h));
vbuf.push_back(Point(r.x, r.y+r.h));
glVertexPointer(2, GL_FLOAT, 0, &vbuf[0]);
glEnableClientState(GL_VERTEX_ARRAY);
glDrawArrays(GL_QUADS, 0, vbuf.size());
glDisableClientState(GL_VERTEX_ARRAY);
}
};
This will make rendering a lot more effectent because you are sending more data to the video card all at once now lets see if we did any changes to the Test class
class Test {
public:
Test() {
r.init(100, 100, 32, 32);
}
void update() {
in.update(r);
rend.update(r);
}
private:
Rect r;
InputComp in;
RenderComp rend;
};
Noda. The classes that use this pattern won't need to change at all most of the time because I've change the internals the only change you'll notice is that its moving a lot faster.
Hopefully this helps any one who wants to use component architecture in there game engine. Its really ease to use once you get the whole concept of components. Like all designs there are problems with, components make it where you have tons of smaller objects which can give you some overhead. Allocation does become an issue so use components to because you are creating a whole bunch of objects. So use it where you need and don't over design stuff to that will make it to complex. But like wise do over simplify stuff either well later.
Here are the exmaple links
component.zip
(note: comment me if the file isn't available I'll do a re-post to re-upload the examples)
Tuesday, August 9, 2011
Tuesday, June 14, 2011
Lua, a hello world example
I'm still working on the smuf which now I'm simply calling it stardust... I'll give more detail about stardust later. But for now I'll going to show something quite useful for designing game play for your game. C++ is a very versatile and robust language... But for building a simple prototype for game play its to verbose, and the compile type would take forever just to test simple game play. And hell most game designers would give you hell if they would have to use c++ language...
So here comes lua, lua is a simple scripting langage that is designed to be embed into an c or c++ application. Being a scripting language its slower than c++ or c but for prototyping game play that doesn't really matter... Your objective is to try to get the game play going. And after you have an idea of how the game play works then you'll start writing a highly optimized version in c or c++ languages. And then move onto your next project.
Now there are some differences in how lua look and feel. Here a simple comparacent.
lua:
-- Simple Comment
--[[
Multi line comment
]]
print("Hello, World")
if true then
print("Statement is true")
else
print("Statement is false")
end
c++:
// Simple Comment
/*
Multi line comment
*/
#include <iostream>
using namespace std;
int main(int argc, char** argv) {
cout << "Hello World" << endl;
if(true) {
cout << "if statement is true" << endl;
} else {
cout << "if statement is false" << endl;
}
return 0
}
As you see lua syntax is simpler than c++ but I still prefer c++ syntax though. To a designer lua would be easier to read and another useful feature of lua over c++ is dynamic compilation... Unlike c++ which is a static compiled language, lua is a virtual machine language. This means it can be compiled down to the virtual machine instruction, or you can just read the script file its self which will then be compiled dynamically down to the vm instruction. I'm not really sure if there is a speed benefit of compiling it or not though.
Ok now how to get lua and c++ to play together. This is actually really simple though... Here is a example.
test.cpp:
#include <lua.hpp> // This simplifies the include stuff for c++
#include <iostream>
using namespace std;
int main(int argc, char** argv) {
// This creates a new lua state
lua_State* state = luaL_newstate();
// This open all lua system libraries which
luaL_openlibs(state);
// This will read a file. It returns 0 if no error some other value if there is a //error
int err = luaL_dofile(state, "test.lua");
if(err) {
// This prints the error message
cout << lua_tostring(state, -1) << endl;
}
//This de-allocates the
lua_close(state);
return 0;
}
test.lua:
-- This is a simple file
print("Hello, World") -- just a typical hello world print
To compile this example you'll ether need visual studios binaries or the lua source code. To get the source code go to
http://www.lua.org/ftp/
It contains all the archive versions of the source code. The version you'll want is 5.1 or higher to test this crappy example. For binaries you're on your own there. I'll post more on this subject later.
So here comes lua, lua is a simple scripting langage that is designed to be embed into an c or c++ application. Being a scripting language its slower than c++ or c but for prototyping game play that doesn't really matter... Your objective is to try to get the game play going. And after you have an idea of how the game play works then you'll start writing a highly optimized version in c or c++ languages. And then move onto your next project.
Now there are some differences in how lua look and feel. Here a simple comparacent.
lua:
-- Simple Comment
--[[
Multi line comment
]]
print("Hello, World")
if true then
print("Statement is true")
else
print("Statement is false")
end
c++:
// Simple Comment
/*
Multi line comment
*/
#include <iostream>
using namespace std;
int main(int argc, char** argv) {
cout << "Hello World" << endl;
if(true) {
cout << "if statement is true" << endl;
} else {
cout << "if statement is false" << endl;
}
return 0
}
As you see lua syntax is simpler than c++ but I still prefer c++ syntax though. To a designer lua would be easier to read and another useful feature of lua over c++ is dynamic compilation... Unlike c++ which is a static compiled language, lua is a virtual machine language. This means it can be compiled down to the virtual machine instruction, or you can just read the script file its self which will then be compiled dynamically down to the vm instruction. I'm not really sure if there is a speed benefit of compiling it or not though.
Ok now how to get lua and c++ to play together. This is actually really simple though... Here is a example.
test.cpp:
#include <lua.hpp> // This simplifies the include stuff for c++
#include <iostream>
using namespace std;
int main(int argc, char** argv) {
// This creates a new lua state
lua_State* state = luaL_newstate();
// This open all lua system libraries which
luaL_openlibs(state);
// This will read a file. It returns 0 if no error some other value if there is a //error
int err = luaL_dofile(state, "test.lua");
if(err) {
// This prints the error message
cout << lua_tostring(state, -1) << endl;
}
//This de-allocates the
lua_close(state);
return 0;
}
test.lua:
-- This is a simple file
print("Hello, World") -- just a typical hello world print
To compile this example you'll ether need visual studios binaries or the lua source code. To get the source code go to
http://www.lua.org/ftp/
It contains all the archive versions of the source code. The version you'll want is 5.1 or higher to test this crappy example. For binaries you're on your own there. I'll post more on this subject later.
Thursday, May 19, 2011
Simple SMUP (Shootem up)
Its been a few weeks since I've posted on this blog. Right now I'm working on a simple shoot'em up or smup for short. For now its only a simple demo. It has no collision dection or respose system yet so the player can't do any thing with the meteors.
As you can see its very basic. You can't move up or down, you are limited to move left or right. Once I implemented it you'll be about to shoot with the z key which is the action button. Also it won't be in windowed mode either because windowed mode is really slow.
One thing about it is that is that there are 2 background. One is a star background which move quite slow. And the other is a meteor background to make it feel like you are in an asteroid field and it gives the map a little depth too :D. Oh well I'll keep it posted. (btw the platformer project has be stalled for a while I'll start working on it after this project).
As you can see its very basic. You can't move up or down, you are limited to move left or right. Once I implemented it you'll be about to shoot with the z key which is the action button. Also it won't be in windowed mode either because windowed mode is really slow.
One thing about it is that is that there are 2 background. One is a star background which move quite slow. And the other is a meteor background to make it feel like you are in an asteroid field and it gives the map a little depth too :D. Oh well I'll keep it posted. (btw the platformer project has be stalled for a while I'll start working on it after this project).
Saturday, May 7, 2011
Toki Toki Syntax 8D!!! In C++.
This is some silly test I did when I was working on one of my projects... I started playing around with how c++ class work and came up with a way to make it look sort-of like query language. It looks something like this :D
/*
* Toki Toki Syntax is just a simple way to make c++ classes look
* like queries :D
*
* So MAHAHAHAHAHAHAHAHAHAAAAA!!!! Couph Couph Couph 8D
*/
#include <iostream>
using namespace std;
class Test {
public:
int num;
Test() : num(0) {}
Test* hello() {
cout << "Hello World" << endl;
num++;
return this;
}
Test* moon() {
cout << "Hello Moon" << endl;
num++;
return this;
}
Test* sun() {
cout << "Hello Sun" << endl;
num++;
return this;
}
Test* stars() {
cout << "Hello Stars" << endl;
num++;
return this;
}
int getNum() {
return num;
}
};
int main() {
cout << "Toki Toki Syntax: Simple way to make c++ look like a query language :D" << endl;
Test t;
// WTF Am I reading :D
cout << "Toki Toki: " << t.hello()->moon()->sun()->stars()->getNum() << " times!!!" << endl;
return 0;
}
This is just boredom on my part but I thought it was quite funny. Who knows this design might be useful if not have laugh it helps with blood pressure 8D. What even funnier is the output from this example it looks like this.
Hello World
Hello Moon
Hello Sun
Hello Stars
Toki Toki: 4 times!!!
I thought it would be something like this though.
Toki Toki:
Hello World
Hello Moon
Hello Sun
Hello Stars
4 times!!!
Oh well figured out some strange about the way methods are launched in c++. Peace!!!
/*
* Toki Toki Syntax is just a simple way to make c++ classes look
* like queries :D
*
* So MAHAHAHAHAHAHAHAHAHAAAAA!!!! Couph Couph Couph 8D
*/
#include <iostream>
using namespace std;
class Test {
public:
int num;
Test() : num(0) {}
Test* hello() {
cout << "Hello World" << endl;
num++;
return this;
}
Test* moon() {
cout << "Hello Moon" << endl;
num++;
return this;
}
Test* sun() {
cout << "Hello Sun" << endl;
num++;
return this;
}
Test* stars() {
cout << "Hello Stars" << endl;
num++;
return this;
}
int getNum() {
return num;
}
};
int main() {
cout << "Toki Toki Syntax: Simple way to make c++ look like a query language :D" << endl;
Test t;
// WTF Am I reading :D
cout << "Toki Toki: " << t.hello()->moon()->sun()->stars()->getNum() << " times!!!" << endl;
return 0;
}
This is just boredom on my part but I thought it was quite funny. Who knows this design might be useful if not have laugh it helps with blood pressure 8D. What even funnier is the output from this example it looks like this.
Hello World
Hello Moon
Hello Sun
Hello Stars
Toki Toki: 4 times!!!
I thought it would be something like this though.
Toki Toki:
Hello World
Hello Moon
Hello Sun
Hello Stars
4 times!!!
Oh well figured out some strange about the way methods are launched in c++. Peace!!!
Friday, April 22, 2011
Object Oriented C ( MACRO!!! Oh no )
Well I took a break from the platformer I'm working on and decided to play around with c language and try to do some macro hacking. :D I've done oop c stuff in the past using a method like this.
Example of oop c
#include <stdio.h>
#include <stdlib.h>
typedef struct {
int i;
} Test;
Test* test_newTest() {
Test* temp = malloc(sizeof(Test));
return temp;
}
void test_deleteTest(Test* t) {
free(t);
}
void test_setI(Test* this, int i) {
this->i = i;
}
int test_getI(Test* this) {
return this->i;
}
void test_print(Test* this) {
printf("%d\n", this->i);
}
int main() {
Test* t = test_newTest();
test_setI(t, 20);
test_print(t);
test_deleteTest(t);
return 0;
}
As you can see its a great way to modulize your c code. But there is a problem with this. And the problem is reusability of code and Most people come from a java, c# or some other scripting background that use traditional oop would go "um...what?" and be quite confused. Then would say this "Hey that isn't oop noob" or something like that. Meh, who care what any one else thinks to me this is quite modular.
So after thinking for a while (and I was really board ) I did a little test project last night to see if I can add a little syntax sugar to that design. And behold my simple hackish way to add oop sugar to the c lang.
// This is where the class sytax will be created
// This defines the class
#define CLASS(v) typedef struct { v }
// This is the definision of a method
#define METHOD(class, name) class##_##name(class* this
// These 2 will start and end parameter setting
#define START ,
#define END )
// This calls a method
#define CALL(inst, class, name) class##_##name(inst
// These are wrappers for the constructor and destructor
// These need to be implemented
#define CONSTRUCT(class) void METHOD(class, create)
#define DESTRUCT(class) void METHOD(class, release) END
#define NEW(class, inst) inst = (class*)malloc(sizeof(class)); CALL(inst, class, create)
#define DELETE(class, inst) CALL(inst, class, release) END; free(inst)
I wonder what you expression is at the moment. If you can interpret this code your mouth is probably dropped of your face because I'm using some really sick looking macro and post some like "Evil!!!" and I'll simple go "mhahahahahaha just as planned!!!". Oh well I better explain what going on.
CLASS(v) - This defines your class name, the sytax for it is really quite simple for class definision.
CLASS(int x; int y;) Vec2;
Thats pretty much it for defining your class, internal it simple typedef struct but that doesn't really matter now doesn't it. Inside the () this is where you define your attributes or fields. To decare methods you will need to use the METHOD macro
METHOD(class, name) - This defind your classes methods, these can be any thing. NOTE: Being to c isn't a full blow object oriented language you can't use all feature of oop like inheritance (just for now), polymorphism( I heard this is possible but haven't implemented yet), data hide level (public, protected, private). In this simple implementation everything is public.
Ok how to use this macro
void METHOD(Vec2, setX) START int x END; or {}
int METHOD(Vec2, getX) END; or {}
Quite simle and a lot more meaning full then then the first example. START and END are used for parameters. START is optional but END needs to be with it for internal reasons.
CALL(inst, class, name) - This call a method for our class. inst is the class instance, class is the name of the class and name is the method name. Like method it uses START and END for parameters like so.
CALL(t, Vec2, setX) START 20 END;
e = CALL(t, Vec2, getX) END;
Pretty simple so far. But there is more.
CONSTRUCT(class) - This is a special method declaration that is use when you are instanlizing a class. (more on that in a moment). This means when you create an object this will be the first method created. Just like METHOD you will use START and END for the parameter.
CONSTRUCT(Vec2) START int x, int y END;
And like wise there is also a destructor or in this test lib DESTRUCT(class) which is used when you are deallocating a class. There is one major difference between CONSTRUCT and DESTRUCT and that is destruct doesn't need parameters.
DESTRUCT(Vec2);
Ok time for memory stuff...
NEW(class, inst) - This creates an instance of a class it doesn't return any thing though because it sets the variable. Like everything else it take START and END parameters.
NEW(Vec2, v) START 10, 20 END;
and likewise DELETE will deallocate an object. It also doesn't use the START or END because it doesn't take parameters.
DELETE(Vec2, v);
This is simply a wrapper of the first examples method of doing oop in c lang. This isn't really complete because I have done more advance stuff with it yet like inheritance and polymorphism but will do it eventually oh well later.
Here is the example of c oop wrapping. NOTE: The example is for linux but it can compiled on any compiler because I'm not using any external library for this example. And the oop wrapper is header only too so just create your own example to see how it works.
http://www.filehosting.org/
Example of oop c
#include <stdio.h>
#include <stdlib.h>
typedef struct {
int i;
} Test;
Test* test_newTest() {
Test* temp = malloc(sizeof(Test));
return temp;
}
void test_deleteTest(Test* t) {
free(t);
}
void test_setI(Test* this, int i) {
this->i = i;
}
int test_getI(Test* this) {
return this->i;
}
void test_print(Test* this) {
printf("%d\n", this->i);
}
int main() {
Test* t = test_newTest();
test_setI(t, 20);
test_print(t);
test_deleteTest(t);
return 0;
}
As you can see its a great way to modulize your c code. But there is a problem with this. And the problem is reusability of code and Most people come from a java, c# or some other scripting background that use traditional oop would go "um...what?" and be quite confused. Then would say this "Hey that isn't oop noob" or something like that. Meh, who care what any one else thinks to me this is quite modular.
So after thinking for a while (and I was really board ) I did a little test project last night to see if I can add a little syntax sugar to that design. And behold my simple hackish way to add oop sugar to the c lang.
// This is where the class sytax will be created
// This defines the class
#define CLASS(v) typedef struct { v }
// This is the definision of a method
#define METHOD(class, name) class##_##name(class* this
// These 2 will start and end parameter setting
#define START ,
#define END )
// This calls a method
#define CALL(inst, class, name) class##_##name(inst
// These are wrappers for the constructor and destructor
// These need to be implemented
#define CONSTRUCT(class) void METHOD(class, create)
#define DESTRUCT(class) void METHOD(class, release) END
#define NEW(class, inst) inst = (class*)malloc(sizeof(class)); CALL(inst, class, create)
#define DELETE(class, inst) CALL(inst, class, release) END; free(inst)
I wonder what you expression is at the moment. If you can interpret this code your mouth is probably dropped of your face because I'm using some really sick looking macro and post some like "Evil!!!" and I'll simple go "mhahahahahaha just as planned!!!". Oh well I better explain what going on.
CLASS(v) - This defines your class name, the sytax for it is really quite simple for class definision.
CLASS(int x; int y;) Vec2;
Thats pretty much it for defining your class, internal it simple typedef struct but that doesn't really matter now doesn't it. Inside the () this is where you define your attributes or fields. To decare methods you will need to use the METHOD macro
METHOD(class, name) - This defind your classes methods, these can be any thing. NOTE: Being to c isn't a full blow object oriented language you can't use all feature of oop like inheritance (just for now), polymorphism( I heard this is possible but haven't implemented yet), data hide level (public, protected, private). In this simple implementation everything is public.
Ok how to use this macro
void METHOD(Vec2, setX) START int x END; or {}
int METHOD(Vec2, getX) END; or {}
Quite simle and a lot more meaning full then then the first example. START and END are used for parameters. START is optional but END needs to be with it for internal reasons.
CALL(inst, class, name) - This call a method for our class. inst is the class instance, class is the name of the class and name is the method name. Like method it uses START and END for parameters like so.
CALL(t, Vec2, setX) START 20 END;
e = CALL(t, Vec2, getX) END;
Pretty simple so far. But there is more.
CONSTRUCT(class) - This is a special method declaration that is use when you are instanlizing a class. (more on that in a moment). This means when you create an object this will be the first method created. Just like METHOD you will use START and END for the parameter.
CONSTRUCT(Vec2) START int x, int y END;
And like wise there is also a destructor or in this test lib DESTRUCT(class) which is used when you are deallocating a class. There is one major difference between CONSTRUCT and DESTRUCT and that is destruct doesn't need parameters.
DESTRUCT(Vec2);
Ok time for memory stuff...
NEW(class, inst) - This creates an instance of a class it doesn't return any thing though because it sets the variable. Like everything else it take START and END parameters.
NEW(Vec2, v) START 10, 20 END;
and likewise DELETE will deallocate an object. It also doesn't use the START or END because it doesn't take parameters.
DELETE(Vec2, v);
This is simply a wrapper of the first examples method of doing oop in c lang. This isn't really complete because I have done more advance stuff with it yet like inheritance and polymorphism but will do it eventually oh well later.
Here is the example of c oop wrapping. NOTE: The example is for linux but it can compiled on any compiler because I'm not using any external library for this example. And the oop wrapper is header only too so just create your own example to see how it works.
http://www.filehosting.org/
Monday, April 18, 2011
Platformer
I'm taking a break from the low-level gba game development and started working on a simple platformer using SDL, OpenGL and Lua for scripting. I'm not real sure what the story is going to be about but I'll think of something interesting later. For right now it all engine developing. And right now I'm working on the low-level and library wrapper stuff at the moment. It forms a simpler library called librbase which contains useful simpler functionality than lower level libraries like SDL and Opengl (still can't beat something like gba, ds or psp development for low-levelness). Here what I have so far for this simple libary.
- windowing api (this is pretty much done)
- input (this is done because there won't be any mouse stuff for this game only keyboard.)
- rendering (this isn't even close to being done)
- logging(useful for debugging)
This is all I have for right now which an't to bad for a single day of deving and working on a simple design doc. Here are some ideas for what I'm going to add to the library later one that I can think off the to of my head at the moment.
- sound (really important for setting the mood)
- state management (This is for screen changing, logo to start states ect)
- scripting interface ( Not everything need to be written in c++, here come lua)
- math (linear algebra, rects, matrixies)
- collision (simple function for checking for simple collision like aabb)
- gui (Yep needs some sort of gui to make it look pro, I'll just write a simple one though)
- resource manager ( Heh heh, extremely important and I do mean extreme )
Now not all these will be implemented right away and I might use librbase for something else and improve it. Oh well I don't have any screen shots for it right. Mabey later when I have something decent. Well actully I'll show you what it can do right now.
For right now it can render textures and render font to the screen. I'm using SDL_image to load image into an OpenGL texture and for font rendering I using SDL_ttf for loading *.ttf files and caching them into a c++ map, well that pretty much how it works. More later.
- windowing api (this is pretty much done)
- input (this is done because there won't be any mouse stuff for this game only keyboard.)
- rendering (this isn't even close to being done)
- logging(useful for debugging)
This is all I have for right now which an't to bad for a single day of deving and working on a simple design doc. Here are some ideas for what I'm going to add to the library later one that I can think off the to of my head at the moment.
- sound (really important for setting the mood)
- state management (This is for screen changing, logo to start states ect)
- scripting interface ( Not everything need to be written in c++, here come lua)
- math (linear algebra, rects, matrixies)
- collision (simple function for checking for simple collision like aabb)
- gui (Yep needs some sort of gui to make it look pro, I'll just write a simple one though)
- resource manager ( Heh heh, extremely important and I do mean extreme )
Now not all these will be implemented right away and I might use librbase for something else and improve it. Oh well I don't have any screen shots for it right. Mabey later when I have something decent. Well actully I'll show you what it can do right now.
For right now it can render textures and render font to the screen. I'm using SDL_image to load image into an OpenGL texture and for font rendering I using SDL_ttf for loading *.ttf files and caching them into a c++ map, well that pretty much how it works. More later.
Monday, April 11, 2011
Hello and welcome to the nightmare. (Sortof) part 3
Lets do something funner than just create pixels on the fly. How about loading an really crappy image.
Oh God thats crappy, oh who cares I'm no artist, just a bored programmer who has nothing better to (btw I drew this in about a minute :D). Here is what I'm going to demo today. How to load images on the lil old gba. Note there are some strange issues, like I said before gba programming or any console in general is very low level. Just as low-level as OS developing, so there isn't any file system you can use. Here come the tool grit.
Grit is a simple tool used trance forms your sexy artwork and my non-so-sexy artwork into an array that the gba can read. Instead of loading via file you compile it with your binary, cool huh. One suggestion though make sure you compile your gfx data to a separate library because it will make your *.gba files smaller. Just a suggestion that's all.
grit crappy.png -gb -gB32 -p! -ftc
The grit tool contains many and I do mean many option to get your artwork workable. -gb basically tells grit that it is a bitmap if you do -gt then it would be a tile instead (I'll get to that later). -gB32 Produces a Uint32 (unsigned int btw) array of image data. -p! this options is for pal memory more on that later. -ftc creates a c file that contains the array, if you don't specify this option then it will be in ARMS or THUMBS asm instruction instead ( I haven't done much asm stuff yet but I'll do it later data ). Grit come with devkitarm as one of it standard tool and m'yes it a great tool.
Ok more source code and less talking.
// Here is some simple type defs for the code
#include <string.h>
#include "crappy.h"
typedef unsigned short Uint16;
typedef unsigned int Uint32;
typedef Uint16 Color;
// Memory locations
#define MEM_IO 0x04000000 // IO Memory Location
#define MEM_VRAM 0X06000000 // VRam Memory Locations
// Video Modes
// These are tiled modes
#define VID_MODE0 0
#define VID_MODE1 0x0001
#define VID_MODE2 0x0002
// These are bitmap modes
#define VID_MODE3 0x0003 // 240x160 16 color no page flipping
#define VID_MODE4 0x0004 // 240x160 8 color page flipping
#define VID_MODE5 0x0005 // 160x128 16 color page flipping
// These are additional mode for background stuff
#define VID_BG0 0x0100 // Background 0
#define VID_BG1 0x0200 // Background 1
#define VID_BG2 0x0400 // Background 2
#define VID_BG3 0x0800 // Background 3
// More mode later
#define VRAM ((Color*)MEM_VRAM) // Video Ram accessor Macro
#define VID_CNT *(Uint32*)(MEM_IO+0x0000) // Video Controle
#define RGB15(r, g, b) (r | (g<<5) | (b<<10)) // Simple Color Macro
#define M3_WIDTH 240 // Mode 3 width
int main() {
VID_CNT = VID_MODE3 | VID_BG2;
memcpy(VRAM, crappyBitmap, crappyBitmapLen);
while(1);
return 0;
}
As you can see there are 3 changes to the source, first one is that I'm including string.h and if any one knows c this file contains functions for c string functionality and it contains a very useful function for copying memory or memcpy. Its not perfect for gba because of data alignment issues but it still gets the job done for simple examples. crappy.h perfect name isn't it, this is the header file that was generated from the tool grit. It contains the both crappyBitmap array and the crappyBitmapLen which is the size of the image data. The array data its self is being housed in the crappy.c file which is just a huge array and nothing else. As you can see in the main function I'm copying the crappy bitmap into the VRAM. And that is pretty much it.
If you are see this then congrats, you're gba need anger management. Well more laters.
Demo 4 files
http://www.filehosting.org/
Oh God thats crappy, oh who cares I'm no artist, just a bored programmer who has nothing better to (btw I drew this in about a minute :D). Here is what I'm going to demo today. How to load images on the lil old gba. Note there are some strange issues, like I said before gba programming or any console in general is very low level. Just as low-level as OS developing, so there isn't any file system you can use. Here come the tool grit.
Grit is a simple tool used trance forms your sexy artwork and my non-so-sexy artwork into an array that the gba can read. Instead of loading via file you compile it with your binary, cool huh. One suggestion though make sure you compile your gfx data to a separate library because it will make your *.gba files smaller. Just a suggestion that's all.
grit crappy.png -gb -gB32 -p! -ftc
The grit tool contains many and I do mean many option to get your artwork workable. -gb basically tells grit that it is a bitmap if you do -gt then it would be a tile instead (I'll get to that later). -gB32 Produces a Uint32 (unsigned int btw) array of image data. -p! this options is for pal memory more on that later. -ftc creates a c file that contains the array, if you don't specify this option then it will be in ARMS or THUMBS asm instruction instead ( I haven't done much asm stuff yet but I'll do it later data ). Grit come with devkitarm as one of it standard tool and m'yes it a great tool.
Ok more source code and less talking.
// Here is some simple type defs for the code
#include <string.h>
#include "crappy.h"
typedef unsigned short Uint16;
typedef unsigned int Uint32;
typedef Uint16 Color;
// Memory locations
#define MEM_IO 0x04000000 // IO Memory Location
#define MEM_VRAM 0X06000000 // VRam Memory Locations
// Video Modes
// These are tiled modes
#define VID_MODE0 0
#define VID_MODE1 0x0001
#define VID_MODE2 0x0002
// These are bitmap modes
#define VID_MODE3 0x0003 // 240x160 16 color no page flipping
#define VID_MODE4 0x0004 // 240x160 8 color page flipping
#define VID_MODE5 0x0005 // 160x128 16 color page flipping
// These are additional mode for background stuff
#define VID_BG0 0x0100 // Background 0
#define VID_BG1 0x0200 // Background 1
#define VID_BG2 0x0400 // Background 2
#define VID_BG3 0x0800 // Background 3
// More mode later
#define VRAM ((Color*)MEM_VRAM) // Video Ram accessor Macro
#define VID_CNT *(Uint32*)(MEM_IO+0x0000) // Video Controle
#define RGB15(r, g, b) (r | (g<<5) | (b<<10)) // Simple Color Macro
#define M3_WIDTH 240 // Mode 3 width
int main() {
VID_CNT = VID_MODE3 | VID_BG2;
memcpy(VRAM, crappyBitmap, crappyBitmapLen);
while(1);
return 0;
}
As you can see there are 3 changes to the source, first one is that I'm including string.h and if any one knows c this file contains functions for c string functionality and it contains a very useful function for copying memory or memcpy. Its not perfect for gba because of data alignment issues but it still gets the job done for simple examples. crappy.h perfect name isn't it, this is the header file that was generated from the tool grit. It contains the both crappyBitmap array and the crappyBitmapLen which is the size of the image data. The array data its self is being housed in the crappy.c file which is just a huge array and nothing else. As you can see in the main function I'm copying the crappy bitmap into the VRAM. And that is pretty much it.
Demo 4 files
http://www.filehosting.org/
Hello and welcome to the nightmare. (Sortof) part 2
Well here part 2 of my hello intro I suppose... Here I'm just going to revise the code I posted last night for the gba example that looked like crap. It was really not that readable at all. So this post I'm going to clean it up a bit and show you how nice you can make it. Here the rearranged demo.
// Here is some simple type defs for the code
typedef unsigned short Uint16;
typedef unsigned int Uint32;
typedef Uint16 Color;
#define MEM_IO 0x04000000
#define MEM_VRAM 0X06000000
// Video Modes
// These are tiled modes
#define VID_MODE0 0
#define VID_MODE1 0x0001
#define VID_MODE2 0x0002
// These are bitmap modes
#define VID_MODE3 0x0003 // 240x160 16 color no page flipping
#define VID_MODE4 0x0004 // 240x160 8 color page flipping
#define VID_MODE5 0x0005 // 160x128 16 color page flipping
// These are additional mode for background stuff
#define VID_BG0 0x0100
#define VID_BG1 0x0200
#define VID_BG2 0x0400
#define VID_BG3 0x0800
// More mode later
#define VRAM ((Color*)MEM_VRAM)
#define VID_CNT *(Uint32*)(MEM_IO+0x0000)
#define RGB15(r, g, b) (r | (g<<5) | (b<<10))
int main() {
//*(unsigned int*)0x04000000 = 0x403;
VID_CNT = VID_MODE3 | VID_BG2;
//((unsigned short*)0x06000000)[120+80*240] = 0x001F;
VRAM[120+80*240] = RGB15(31, 0, 0);
while(1);
return 0;
}
A lot more readable isn't it. Its still quite simple though. Like before it using video mode 3 on background 2. And it still colors a pixel red at 120x80. Still quite simple. But it looks nicer.
Now as you can see the gba has 6 different vid modes. The first 3 are tile mode. These mode do hardware accelerated tile-mapping. Most gba games use these 3 mode because they are extremely quick (NOTE: gba was built from the ground up for 2d games not 3d so the hardware was built specifically to speed up 2d apps. Its possible to do 3d on the gba if you don't mind software rendering which really suck. )
The mode I'll show here for now is bitmap mode which isn't really built for games unless you are doing a doom type game using ray casting. But its easier than the tile modes when starting out.
Enough chit chat more demo. This demo is still boring and not real fun at all. Its just a damn red dot in the middle of the screen. Lets try a simple yet kind of cool effect.
// Here is some simple type defs for the code
typedef unsigned short Uint16;
typedef unsigned int Uint32;
typedef Uint16 Color;
#define MEM_IO 0x04000000
#define MEM_VRAM 0X06000000
// Video Modes
// These are tiled modes
#define VID_MODE0 0
#define VID_MODE1 0x0001
#define VID_MODE2 0x0002
// These are bitmap modes
#define VID_MODE3 0x0003 // 240x160 16 color no page flipping
#define VID_MODE4 0x0004 // 240x160 8 color page flipping
#define VID_MODE5 0x0005 // 160x128 16 color page flipping
// These are additional mode for background stuff
#define VID_BG0 0x0100
#define VID_BG1 0x0200
#define VID_BG2 0x0400
#define VID_BG3 0x0800
// More mode later
#define VRAM ((Color*)MEM_VRAM)
#define VID_CNT *(Uint32*)(MEM_IO+0x0000)
#define RGB15(r, g, b) (r | (g<<5) | (b<<10))
#define M3_WIDTH 240
int main() {
int i, j, c = 0;
VID_CNT = VID_MODE3 | VID_BG2;
for(i = 0; i < 240; i++) {
for(j = 0; j < 160; j++) {
VRAM[i+j*M3_WIDTH] = RGB15(i, j, c);
}
c++;
}
while(1);
return 0;
}
This code produces something like this...
I did this because it looks cool :D. Try rearranging the simple source code and see what type of crap you can load on the VRAM. What the code is doing btw is it looping through the width and the height of the gba's screen then it changes the color of the pixel using the i, j and c variables. i sets red, j sets green and c sets blue during the loops life time. So it produces a really cool effect. Oh well I'm getting tired need sleep, night.
Links for the demos
Demo 1
http://www.filehosting.org/
Demo2
http://www.filehosting.org/
// Here is some simple type defs for the code
typedef unsigned short Uint16;
typedef unsigned int Uint32;
typedef Uint16 Color;
#define MEM_IO 0x04000000
#define MEM_VRAM 0X06000000
// Video Modes
// These are tiled modes
#define VID_MODE0 0
#define VID_MODE1 0x0001
#define VID_MODE2 0x0002
// These are bitmap modes
#define VID_MODE3 0x0003 // 240x160 16 color no page flipping
#define VID_MODE4 0x0004 // 240x160 8 color page flipping
#define VID_MODE5 0x0005 // 160x128 16 color page flipping
// These are additional mode for background stuff
#define VID_BG0 0x0100
#define VID_BG1 0x0200
#define VID_BG2 0x0400
#define VID_BG3 0x0800
// More mode later
#define VRAM ((Color*)MEM_VRAM)
#define VID_CNT *(Uint32*)(MEM_IO+0x0000)
#define RGB15(r, g, b) (r | (g<<5) | (b<<10))
int main() {
//*(unsigned int*)0x04000000 = 0x403;
VID_CNT = VID_MODE3 | VID_BG2;
//((unsigned short*)0x06000000)[120+80*240] = 0x001F;
VRAM[120+80*240] = RGB15(31, 0, 0);
while(1);
return 0;
}
A lot more readable isn't it. Its still quite simple though. Like before it using video mode 3 on background 2. And it still colors a pixel red at 120x80. Still quite simple. But it looks nicer.
Now as you can see the gba has 6 different vid modes. The first 3 are tile mode. These mode do hardware accelerated tile-mapping. Most gba games use these 3 mode because they are extremely quick (NOTE: gba was built from the ground up for 2d games not 3d so the hardware was built specifically to speed up 2d apps. Its possible to do 3d on the gba if you don't mind software rendering which really suck. )
The mode I'll show here for now is bitmap mode which isn't really built for games unless you are doing a doom type game using ray casting. But its easier than the tile modes when starting out.
Enough chit chat more demo. This demo is still boring and not real fun at all. Its just a damn red dot in the middle of the screen. Lets try a simple yet kind of cool effect.
// Here is some simple type defs for the code
typedef unsigned short Uint16;
typedef unsigned int Uint32;
typedef Uint16 Color;
#define MEM_IO 0x04000000
#define MEM_VRAM 0X06000000
// Video Modes
// These are tiled modes
#define VID_MODE0 0
#define VID_MODE1 0x0001
#define VID_MODE2 0x0002
// These are bitmap modes
#define VID_MODE3 0x0003 // 240x160 16 color no page flipping
#define VID_MODE4 0x0004 // 240x160 8 color page flipping
#define VID_MODE5 0x0005 // 160x128 16 color page flipping
// These are additional mode for background stuff
#define VID_BG0 0x0100
#define VID_BG1 0x0200
#define VID_BG2 0x0400
#define VID_BG3 0x0800
// More mode later
#define VRAM ((Color*)MEM_VRAM)
#define VID_CNT *(Uint32*)(MEM_IO+0x0000)
#define RGB15(r, g, b) (r | (g<<5) | (b<<10))
#define M3_WIDTH 240
int main() {
int i, j, c = 0;
VID_CNT = VID_MODE3 | VID_BG2;
for(i = 0; i < 240; i++) {
for(j = 0; j < 160; j++) {
VRAM[i+j*M3_WIDTH] = RGB15(i, j, c);
}
c++;
}
while(1);
return 0;
}
This code produces something like this...
I did this because it looks cool :D. Try rearranging the simple source code and see what type of crap you can load on the VRAM. What the code is doing btw is it looping through the width and the height of the gba's screen then it changes the color of the pixel using the i, j and c variables. i sets red, j sets green and c sets blue during the loops life time. So it produces a really cool effect. Oh well I'm getting tired need sleep, night.
Links for the demos
Demo 1
http://www.filehosting.org/
Demo2
http://www.filehosting.org/
Sunday, April 10, 2011
Hello and welcome to the nightmare. (Sortof)
Hello and welcome to at random blog about game deving (developing btw). Its blog where I'll post random Ideas and concepts that isn't really base on any particular game project just ideas on how the develop these monster-as apps know as games. I'm not going to candy coat any thing so if you are a beginner you might want to look else where for now. I'm thinking of adding a simple set of tutorials on SDL and opengl later on but just random thought on projects I'm working on for my self which right now I'm working on game boy advance programming which is based off tonc tutorials which is a good place to start doing gba game development. If you are a beginner than you might want to start with some a little more realistic like sdl or allegro. Or Microsoft XNA which uses C# while sdl and allegro use c or c++ ( they also have wrappers for these libraries too like python, ruby, lua, java or what not ). Game Boy Advance programming or any sort of console development is quite low level. Its just as low level as Operating System development (not as hard though ). So do some thing like this...
int main() {
*(unsigned int*)0x04000000 = 0x403;
((unsigned short*)0x06000000)[120+80*240] = 0x001F;
while(1);
return 0;
}
Is perfectly legal. If you don't understand this source code its fine. 0x04000000 is the IO MEM location. Its used to set info to the gba. 0x403 means display mode 3 which is bitmap mode 1 using background 2. 0x06000000 is the location of the video ram (VRAM) which alows you to display stuff the gba's display. This example display a red dot at [120x80] pixels. The code is quite unreadable if I say my self, usually you would write a library to make this more manageable (I'm working on my own right now). I"m just demonstrating how low-level console development is. There are libraries out there to hide this like devkitpro's libgba or tonc's (This example is a simplified version of toncs hello world program).
Kind of boring but hell this is my first blog post after all.
Also note to compile this you need a compiler that compiles to arm and thumb code. I'm using devkit pro's arm compile stack which is the default stack now a days here the link.
http://sourceforge.net/projects/devkitpro/files/devkitARM/
Here's the demo link if it disappears let me know I'll re-up it.
http://www.filehosting.org/
Oh well this was kind of long for a hello world post. Well later.
int main() {
*(unsigned int*)0x04000000 = 0x403;
((unsigned short*)0x06000000)[120+80*240] = 0x001F;
while(1);
return 0;
}
Is perfectly legal. If you don't understand this source code its fine. 0x04000000 is the IO MEM location. Its used to set info to the gba. 0x403 means display mode 3 which is bitmap mode 1 using background 2. 0x06000000 is the location of the video ram (VRAM) which alows you to display stuff the gba's display. This example display a red dot at [120x80] pixels. The code is quite unreadable if I say my self, usually you would write a library to make this more manageable (I'm working on my own right now). I"m just demonstrating how low-level console development is. There are libraries out there to hide this like devkitpro's libgba or tonc's (This example is a simplified version of toncs hello world program).
Also note to compile this you need a compiler that compiles to arm and thumb code. I'm using devkit pro's arm compile stack which is the default stack now a days here the link.
http://sourceforge.net/projects/devkitpro/files/devkitARM/
Here's the demo link if it disappears let me know I'll re-up it.
http://www.filehosting.org/
Oh well this was kind of long for a hello world post. Well later.
Subscribe to:
Posts (Atom)