-
Notifications
You must be signed in to change notification settings - Fork 2
/
README
178 lines (138 loc) · 6.91 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
Baby Cthulu is an abstraction interface and management engine.
Throw the .cpp's in tests into a template devkit working project and you'll have
for one of them you'll need a copy of the data files to serve as test sprites.
The 3D tests show the currently limited functionality of the engine.
Sprite capabilities are pretty solid. Multiple sprites of varying sizes can be:
*Blitted anywhere on the screen
*Have Alpha channels and such
*Be animated
*Stopped
I will add more functionality as I think of it. Esepcially while adding BG
functionality and such. Trying to make the engine compact but useful for users
in the same way Game Maker was useful in making neat nethack like RPG's.
(Man I want to learn to play that game so bad now...)
Anywho. Enjoi what I've got so far. Try out what you can. Break it send in bugs.
*************************************************************
*
* CTHULU Basics
*
*
----------------------------
1.1 bcthulu Nodes.
Baby Cthulu is first and foremost an API. Thus you must have an access method.
The functions of the babyCthulu interface can be seen in the source.
To create a handle to babyCthulu use the call "bluCreate()" to return a
reference to the babycthulu interface. This is done as so:
bcthulu* blu = bluCreate();
After this call blu will have a reference to babyCthulu. And will be able to
make calls to the interface.
blu->GFX_Initiate() or Input will begin to initialize the graphics engines and
will
be ready to handle input and 2D.
1.2 Graphics
As of currently babyCthulu only handles sprite memory. One could theoretically
add lower level code to access bg's until this functionality is added.
Graphics memory can be initiated. It has not been implemented however.
1.2.1 Sprites
Lets first take a look at the sprite memory. Using previous knowledge from the
DS architecture we know that OMA memory has 128 active spaces to hold sprites
of any shape size or format. (Unlike it's predecessor the gba which did not
have enough memory to full implement OAM).
Lets look at some specs before diving into cthulu
*0680:0000 is the VRAM base of a total of 656KB. Libnds breaks this up
into 9 banks.
Bank A - B: 128KB
Bank E: 64KB
Bank F & G: 16KB
Bank H: 32KB
Bank I: 16KB
This spans all of VRAM @680:0000. One needs to map virtual VRAM pointer
addresses to the real VRAM for the 2D engine to operate. This is done
with setBank(parameters);
That is not in the scope of this manual and if you have not learned it
you should not be using cthulu.
Babycthulu will automatically set the memory banks dependning on what you're
going to craft in terms of it's the engines. The default initiate will
set the Bank A to the start of sprite memory, and Bank B to the BG.
So to get ready to make sprites go ahead and call blu->GFX_Inititate();
Onto the sprite structures. Baby Cthulu handles all sprite data in memory
using structures that represents a fully animated sprite. (This is an advanced
feature, the animation). Go take a look in the babyCthulu header file about
what data you can set into the sprite:
struct bluSprite{
int init;
int frame;
int framerate;
int counter;
int x;
int y;
int fps;
int id;
int priority;
unsigned short* gfx;
const unsigned int* tiles;
const unsigned short* pal;
unsigned int tlen;
unsigned int plen;
SpriteMapping sm;
SpriteSize sz;
SpriteColorFormat sfmt;
};
All of these should be self explanatory (save init, set init to 0 before
initializing a sprite and it will be set to 1. Do not mess with it after. Set
frame the framerate and counter to 0 as well).
Framerate is not a real FPS. The higher this number the slower the animation
will play the lower the faster it will play.
Everything else should be explanatory.
After you construct a struct, pass a reference to it to LDSprite(); this will
cause the sprite to go into memory. From here you may BltSpr() it.
So how to use this? First use the grit extensions in devkitpro to configure
your sprites for your program. See the sample gritfiles, the best learning is
through code.
Once you do this your tiles should be named after your image. I like to metatile
so one sheet will have all the tiles like SnakeTiles or SnakePal and the len's
respectively. This is the easiest way to manage 2D resources through the gfx
tools used by the Makefile.
So as said include the .h files to get the tiles and palette info. Afterwhich
pass these values into a babyCthulu sprite structure as described above.
After you have set all that up and then set init=0 you are read to begin with
your sprite.
Pass a call to GFX_LDSprite() your sprite object and memory will be assigned to
it and the system will declare it initialized. You can now build animations to
accesorize the sprite object with. And animation is created in much the same
fashion using a structure object. However it has two slots for large memory
(assigned to the 4MB heap for optimization reasons), which we assign to tiles.
So step one is describing the amount of frames the animation will be (usually
indicated by the size of the sprite sheet). Then the sizes of each frame which
is almost always the size of the base sprite. You then assign it frames the same
way you assign a sprite a tileset. From here you make a call to play animation
with a reference to the base sprite. This call will determine if enough time has
passed to change frames if so it pulls the current tiles out of the basesprite
then slides in the frame number as indicated by the animation table.
Release when done. Pretty simple system.
---
Under Construction:
Started experimenting with the stuff underneath the input queues, trying to
buff it up a bit so that events are resolved efficiently. Probably need TODO
some modifications to the whole iprintf() thing. -- On going part of the below.
Going to build queue resolver for when the thing is spinning the framefunc.
When a message is resolved we'll place time markers to see how fast the
engine is actually running. This will be done first probably due to it's
simplicity. In essence the queue needs to output the average time between
resolving consecutive events. - Still working on this built a sort of developers
console to start this one off.
Resource manager for the 2D engine. Given a table of sprites and associated
animations (and soon/eventually backgrounds), the resource manager should
determine how to load and unload a large amount en masse without disturbing
current program flow.
---
If this manual is out of your scope here are some things to get started before
developing with or for babyCthulu:
*GNU C/C++ - if you know Java, Basic, or any language, this will take at most a
day to get up to speed
*Pointers - this is a part of learning C/C++, but they are a fundamental
concept in computing that many people misinterperate and henceforth misuse.
If you understand those two things you should be fine, if not people will hate
you as you work on this project.
-Stevie
Project by: Stevie Frederick and Patrick Jennings