From ProjectWiki
Jump to: navigation, search




Poor Kaguya buried under a pile of Marisas.

Have been mostly busy struggling to deal with MSVC++ past few days. Last time i tried gave up programming for a year or so afterwards cause i just felt so helpless. That was about 10 years ago, nowdays realize MFC is just stupid. :P Have used other gui widget sets and they're much less W T F?! GRR GRRR *HEADDESK* *HEADDESK* than this stuff is. But the company i've contracted to for this project needs my classes to integrate into msvc++ so here i am again... ~_~

Did sneak away and do a quick bit of coding on the game. Instead of using VBI to wake up the cpu, have put a wait for VCOUNT delay at start of bulletUpdate() function. VCOUNT is then set to immediately after the last subscreen update at VCOUNT of 144.. and yay! sprites are no longer cut in half at random resulting in a much more pleasing display. \\(^_^)// There is still an occasional random flickering caused by mp3s, and it gets worse when a 44.1khz mp3 plays but is very tolorable. Still i have some tricks to get rid of this, as mentioned below, just no time to try them yet.

Also NEED MOAR SPRITES!!! ;; Thinking of doubling the number of subscreens to try and get more. Worked out that pattern seen in the video is using 192 sprites per iteration and if that burst happens all on one subscreen (as it can sometimes) u get missing sprites since each subscreen can only produce 128 sprites (remember each physical display is divided into 4 subscreens 48 scanlines high), they will appear as soon as there is a free hw sprite but still it looks odd. doubling the number of subscreens from 4 to 8 would prolly fix that (and use up another 4K of ram >_>). Also i could just make the initial position of each sprite a little further away from the character, or position the character to be on a subscreen boundry to distribute the load, but it looks totally ossum as it is, and we cannot start compromising.. :P

I'll be getting back to full time working on thds soon as contract work is done, which will be this weekend, at least thats when i need to turn it in and get paid. :DD In the mean time enjoy the screenshot, was not unloading player bullet sprites after each level start and eventually if you played over and over it started using marisas as bullets. thought it funny hehe

ohhh yah, started on yet another song, its comming along nicely. Someone on the talk page asked about the music. Kinda put me on the spot asking if its gonna have an epic soundtrack.. ;; ;; ;; am doing my best... u_u;; Zun really set quite a high standard...

Eventfull day here yesterday, we had remains of Hurricaine Ike blow thru here with winds up to 75Mph. Was without power most of the day :\ Played TGM on nds and listened to music from psp to pass time made it tolorable :D Also over the weekend picked up some coding work involving processing images from a video camera, only have a few days to complete my portions so will probably be busy mostly with this week.

Okais, oh yeah blog is supposed to be about the game, have not done much coding on it, did fix the annoying purple square around my marisa sprites. Both modified my gfx converter to take a bgcolor argument if necessary and also figured out why GIMP was saving the image with a randomized color palette (it had transparency channel on the layer adding an additional color to palette). Either one of these things would have fixed the problem but having both fixed is nice. :D

Am concerned a bit now about the sprite multiplexing scheme. There are two issues, firstly the bullet updating function sometimes runs in between subscreens meaning you'll get 'broken' sprites where the top and bottom half's dont line up along one of the 4 subscreen boundries within each screen, only for a frame or so, but still its visable and bothers me. Also sometimes the bullet update function takes so long after being started in VBLANK that it updates during line 0 being drawn, this causes corrupted sprites to appear, only for one frame but grrr hisss.... This can be fixed or worked around in a few ways, best way atm seems to use the last subframe write to wake up the arm9 and do bullet updates, or double buffer...

Second sprite issue is the arm7 uses alot of memory bandwidth during certain mp3 decoding operations, if these happen to occur during a subscreen update there is possibility of 'flicker' from tops of subscreen boundries, its very intermittent and not very noticable but i can see it and also bothers me. Possible way around this is to occupy the arm7 with operations not involving memory access for duration of vhblank.. Might just put vblank interrupts on the arm7 coinciding with the arm9's updates.. Another maybe even better solution would be to double the number of subframes from 4 to 8, and reduce the number of sprites updated during HBLANK. For smaller sprites that may actually increase the maximum number of sprites possible for dense danmaku clouds, it would also simplify fixed priority sprites a bit.. :D

Both of these solutions are hax hax haxy, and i do not like them, but to make this work best may need to.

Sorry to rambles do that when tire. Need to nap for a bit and resume work on for hire project.. u_u//


Screenshot of stage start, just thought it looks sorta purdy ^^ Didn't make the bg, its 3 layers from a pa_lib demo.

Made a video video to show a few friends ^^ sorry digicam wont record for much longer... ~_~

It's at a good point to take break for few days, got lots to do (like work to pay for this server, am a bit late >_>) tho mostly exhausted trying to get all the systems working together. :\ Still, <3 touhou and does most everything technically required now. XD

Its debugged as far as i know, gots stages, levels, bullets, patterns/spells systems, along with characters, hit detects, animations, made things more scripted instead of coded etc..

Found this site, likes the style of art... sorta touhou related hehe

gots a dentist appointment today and will be gone for a good while, is part of why feel should take break. bbiab i hope :D


Few issues to sort obviously...

Getting there, integrated my old spells system into the newer version of game. After doing so realized why i hated the old spell system so much. :P Just wanted to get it working again to see how much cpu it used, still at only around 12% XDD Can see from the image it has a few issues, for one thing gimp is not saving the palette in proper order on the Marisa image so ya get a purple square around her, thats not such a big deal because have a sprite converter just not using it yet for these tests. Here i am testing spell functionality so just not a concern, yet.

Spells need to be defined in the character scripts instead of how they are at the moment using const tables. The main thing thats going to change is moving as much as possible into textual scripts to ease changes. and also because stuff like:

spellMoves_t moarstarsmoves[] = {
	{0,0,0,0,MOVES_REPEAT}			//last one must be zero 
Spells_t mgrimoire[]= {
	{"Moar stars",		moarstars,		0	,0	,moarstarsmoves  ,0	,0}, 
	{"Radiant",		radiant			,0	,0	,radiantmoves 	,00	,0},
	{"Border of Insanity",	radialstars		,0	,0	,topuppercenter	,00	,0}

is insanely cryptic and hard to deal with... <_<

Still hope to have a working demo soon, am sorry for delays... ^^

Regret still do not have a demo. But progress++ :D Have been working so intently lately think my friends seem a bit annoyed at my lack of concern for anything else, sorry2u guys. Srsly doubt they ever read meh wiki but its the thought that counts eh? Right well onto what all I've done...

Last post said, "My objective for the day is to implement a player entity, provided no other bugs are found." which turned out to be a curse cause gawds did i has bug. Though after a bit found it, and in the process found out quite a bit about how the ds along with libnds works. One of the biggest wtf i had would realizing that ITCM is located by default starting at location 0x0000. Most systems I've worked with (btw, bit of personal infos, have worked as embedded systems developer on and off since late 90s) leave the first mb or so of ram unused. Among other things this allows you to protect the region and enable an exception handler so that any access to this area can call a debug routine (stack trace for instance). Since a lot of problems come about from NULL pointers being used when they should not this srsly helps with the debug process. But since memory is not configured like this from default on the NDS, errant writes to this region will result in bizzare and confusing behavior. @_@

In my game there was a loop, here much simplified as:

do {
} while(blah);

The printf (which was added to help debug this mess) was displaying that blah==0, however the while loop continued! After quite a bit of researching and experimentation realized that the function calling the function containing the loop had a null pointer being referenced as like: NULL->foo->bar which was screwing up the ITCM resulting in the nutty observations.

Something else I found out recently while i'm thinking about it, stddef.h contains a useful macro:

//say u gotta structure like:
typedef struct _blah {
 int x;
 int y;
 char *cptr;
 unsigned short mychar;
} blah;
//and want to know how many bytes from the beginning of the
//structure the element 'cptr' is offset you can use:
offsetof(blah.cptr) // :D :D

This is useful if you wish to manipulate structure elements directly. Similar is concept to sizeof(). Was gonna use it for my script parsing scheme where a const table defined variable names within a structure and where to put the results. Decided not to for now but still thought offsetof() was really neat. :D

OHH,sry am totally off topic really >_> Okais on the game now have both player and scenario script parsing functional, can load and unload character data required for the level as needed, player character responds to user input, other entities (enemys) can be manipulated by the scenario script. For now am just loading various characters and moving them to various places on the screen. Now need to work one reimplementing the spell casting system that will in addition do player firing patterns and bombs, detecting collisions, and then move on to more specific things such as level design. yay!! \\\^_^///

Also made a quickie Marisa enemy and Kaguya player sprites. Not animated yet, someone saw my kaguya posted earlier and made lot nicer one hehe, i should post it here, after asking permission. ^^

Have lot of notes and rough drawings of levels, music, characters, am encouraged getting this close.... will work more in a bit, am still laying in bed on lappy, needs sleep.. u_u

Installed a subversion server today to keep track of changes in my various project's code and as a way to keep backups off-site in case of catastrophe. :D Implemented stage scripts, an example follows:

#firstly start a bg
bg: 1
wait: 0

#nextly start some musics
bgm: 3
wait: 5

#display stage title
showstage: A tumbly world
text: Wut am i supposed to do here?
gfxpng: nitro:/stage1gfx.png
duration: 360
x: 2
y: 30

Nothing too fancy, just wanted an easier way to tweak the scenarios without recompiles. Recreating the entity (player/enemy) systems, spell systems will follow. Had all this done before but redoing to take advantage of NitroFS usage and to solve a few problems with original code. Lot of decisions to make, which always slow me down as I'm very indecisive. u_u Getting there tho! My objective for the day is to implement a player entity, provided no other bugs are found. Created a Kaguya player sprite and Marisa enemy sprite. Neither are animated (yet! :P) but will work for testing.

Oh, intended to mention something i figured out about DS WiFi... Was trying to get a homebrew game to connect to internet, it would not. Same settings had worked before, then tried the offical Opera web browser, it also did not work. After doing a bit of testing with DSOrganize.IRC figured out it was not resolving the

Lastly, friend asked who this Zun guy is, did google search, found wiki article, and realized from an old interview he owns and seems to like the NDS. ^5 hehe, wonder if he every looks at fan games. *ponder* *ponder*

Just thought i'd post to indicate progress is being made. Have reimplemented the main menu system which includes Game Start, Music Room, and Options. Also is a "please watch warmly" splash screen while the systems (such as dldi/fat/nitrofs, etc) are being warmed up. At this time Game Start simply takes you to sprite/bgm/background tests. Would post a screen shot but do not with to spoil, just trust me its sooooooooooooooooooo cute!!! :P

Since there are no more bugs presenting themselves in the bg and sprite portions, am now returning to the Entity, Spells, and Stage Scenario systems. Previous version of THDS used tables to store scenario and spell data like so:

struct StageSteps ezStage1[] = {
//	{EVENT TYPE, 	wait,   index, char,		entity,	x,	y) 
	{STAGE_BG,	0,	0,	NOCHR,	  	0,	0, 	0},	//background (bg 1 from list)
	{STAGE_BGM,	75,	2,	NOCHR,		0,	0,	0},	//stages bgm (song 2 from playlist)
	{STAGE_SHOWLVL,	320,	0,	NOCHR,		0,	0,	0},
	{STAGE_SUMMON,	0,	0,	&fam1chr,	1,	-32,	0},	//create two entities (enemy characters)
	{STAGE_SUMMON,	0,	0,	&fam1chr,	2,	288,	20},	
	{STAGE_SPELLCAST,268,	5,	&fam1chr,	1,	0,	0},     //Start noodley looking spells on each
	{STAGE_SPELLCAST,280,	6,	&fam1chr,	2,	0,	0},

and for spells:

struct Spells fam2grimoire[]= {
//	{spell name,		spell			,health	,dur	,Moves		,delay	,flags
	{"right atcha 8x8 L",	allatcha8x8		,0	,0	,downandtoleft 	,0	,0},
	{"right atcha 8x8 R",	allatcha8x8		,0	,0	,downandtoright ,0	,0},
	{"8x8 L2R",		allatcha8x8		,0	,0	,left2right 	,0	,0},
	{"8x8 R2L",		allatcha8x8		,0	,0	,right2left 	,0	,0},
	{(const char*)NULL,(void*)NULL,0,0,noMove,0}	//EndOflist

Since the creation of these tables have developed the NitroFS driver which would easily allow for scripting to simplify some of these tasks. Thinks should be a hybrid of spells coded in C and scripts to control them rather than going for a total scripted solution such as danmaku fu seems to use.

There is still some unwanted sprite flickering at certain moments caused by interaction of arm7 ram access during critical horizontal blanking periods when the OAM tables are being updated for multiplexing. It actually looks kinda neat but still am occasionally attempting stop it. A few idea's I've tried are having the arm7 go into halt mode during the critical hblanks (every 48 lines), this is so far a failure because it requires halting during interupts which is well just weird. Another idea was to just idle in a loop for the critical period where the arm7 would only need register access to VCOUNT but this for some reason did not have desiered effect.. @_@??? Still working on it off and on...

Lastly wanted to mention a really neat site I found a while back. This page describes the development of a WIP game called Tetris the Grand Master - Terror Instinct. It is really what encouraged me to start a development blog of my own, and has been an interesting read. Other pages on the site have tutorials for things such as laser effects and also is a insanely nice MML player library for nds called BGM DRIVER. Oh btw, its entirely in japanese, however or's translation page have helped alot. (considering i know only about a dozen words in Japanese and the characters are less comprehensible to me than Egyptian heiroglyphs ;_;;)


Sorry for delays between posts but when working am not writing. hehe Last night (over the past few days really) made lot of progress with background system, am now able to do thBgLoad(screen,bg0thru4, "fileprefix") and it loads the map, tiles, palette, and a bgtype definition file automagically. Can also load from memory with another function so that the font and startup screens may be loaded before filesystem is initalized (as well as be able to display error messages :)

Also automatic vram allocations finding the smallest 'hole' that the data will fit, similar to what i have done with sprite's vram. Made these macro defines to allow screen (s), and bg (b) parameters.

//macro to find proper bg control reg
#define BGCR(s,b) (*(vuint16*)(0x04000008+((s)<<12)+((b)<<1)))
#define DISPLAYCR(s)       (*(vuint32*)(0x04000000+((s)<<12)))
#define BGX0(s,b) (*(vuint16*)(0x04000010+((s)<<12)+((b)<<2)))
#define BGY0(s,b) (*(vuint16*)(0x04000012+((s)<<12)+((b)<<2)))
#define BGBMPRAM(s,b)  (((b)<<14) + 0x06000000+((s)<<21))
#define BGTILERAM(s,b) (((b)<<14) + 0x06000000+((s)<<21))
#define BGMAPRAM(s,b)  (((b)<<11) +  0x06000000+((s)<<21))

Background loading went from:

	dmaCopyWords(3,BG1_Map, (u16*)BG_MAP_RAM(12), sizeof(BG1_Map));
	dmaCopyWords(3,BG1_Tiles, (u16*)BG_TILE_RAM(1), sizeof(BG1_Tiles));
	dmaCopyWords(3,BG1_Map, (u16*)BG_MAP_RAM_SUB(12), sizeof(BG1_Map));
	dmaCopyWords(3,BG1_Tiles, (u16*)BG_TILE_RAM_SUB(1), sizeof(BG1_Tiles));
	thUpdateBgPalette((u16*)BG1_Pal, 1, sizeof(BG1_Pal));
	thUpdateBgSubPalette((u16*)BG1_Pal, 1, sizeof(BG1_Pal));

To this:

thBgLoad(0, 1, "nitro:/BG1");
	thBgLoad(1, 1, "nitro:/BG1");

Much simpler!! \^_^/ Can also load from ram so that font data and startup screens may be loaded before the filesystems are initalized (and ofc display errors)

So now am working on bringing the menu systems back using the new systems and have ran into a small bug last night, was quite tired so went to sleep. Now im awake, so here we go.. bbiab ^^/

It has been an eventful few days. Some hackers got onto the server, creating a bit of havoc but politely leaving it otherwise intact. Fixing that required backing up the data, reinstalling, updating everything, fixing the inevitable problems but normalcy is finally being restored. Friend also came to visit from out of town, and have some financial difficulties that are still being sorted. All this delayed work on game much more than i would have liked.. But...

Last night managed to find a troublesome bug in the sprite code. A sprite system funtion that tries to allocate a hardware sprite on the given screen division (there are 8 divisions, 4 per physical screen because of the multiplexing scheme) and if it fails returns -1 that should never return -1, at least with the limited number of sprites im using so far, (so i wasnt checking the return value >_>) WAS returning -1. Hmmz easier to explain in code:

inline int thGetNextSprite(u8 screen); //Return the next available hardware sprite on the given screen (0 thru 7)

The reason it was failing however was because the screen argument being passed was -1 from this funtion

//create a sprite on each screen sprite would be visable.. screen0 = first screen, screen1 = last visable screen
inline int thSubCreateSprite(thSprite_t *thsp, int screen0, int screen1); 

Sprites may span up to 4 'screens' (each screen is 48 pixels high, rly better terminology for this would be 'subscreen'). If the sprite is not visible on any screen screen0 argument would == -1. And THIS too wasnt being checked before calling thSubCreateSprite, causing the entire problem.

The bug appeared as an occasional missing bullet, and was occasionally corrupting other parts of ram as well. Originally thought it was in the bullet engine code, where i looked and looked often trying to find it before finally examining a disassembly and noticing the sprite tables were immediately above the bullet tables in memory and wondering if a corrupted array index may be to blame.

Confused? @_@??? Yes, kinda pointless to even try to explain, simple of it is.. ITS FIXED!!!! XDDDDDDDD Hopefully i will keep my schedule of completing a mostly working demo by the end of month tho it may be a few days longer due to the expected delays.

Also considering moving this dev blog to eris's user talk page instead, since it covers more than just THDS, and is getting quite long. Anyways back to work.. ^^

Heyas! Been insanely busy past few days working on the game, well notrly the game but the libraries to support the game. ^^ Now have soundfx, and a very nice FIFO/IPC system among other things.

First animation attempt

While making the sound lib created a simple synth, which sounds a lot neater that i'd thought it would Here a very very short mp3 demonstrating it. Had originally wanted to make mp3/midi playback of the soundtrack as Zun does but abandoned the idea early on... For now my objective is still to get a demo out by end of month, but may come back to the synth and midi idea afterward. ^^

Really need to work on my sprite animation techniques.. am pretty terrible (see pic :p) however this .gif was done quickly just to gimme something for testing the animation code rather than a very serious attempt at animation. Still am concerned a bit. Her skirt needs to flutter and hair needs blowing in breeze, prolly need to find better software than GIMP for the task, any suggestions? @_@

Gotta get back to work, leave with this nice sprite tutorial. a nice tutorial on sprite making


Here we are, happy 08/08/08!! ^^ Found out last night game was mentioned on MotK along with another thds by anoNL in the works. :D Good we needz moar touhou!!

Just laying here in bed after getting my new audio library working about to nap and thought to write a bit. Am very excited as it is very efficient and feature packed, even includes basic PSG functions mostly because i was wanting to use the noise generators on a level to simulate environmental noises. Still a few little features to add but its working gr8 so far!! :D

Have decided to attempt releasing a demo by the end of the month, probably just a single level but am doing alot of hardware trickery and trying new things, need to test will work with all homebrew cards and such. Will do my best! ^^

Otherwise lot has happend personally. My poor kitteh, who is best friend, and familiar died 2 days ago. She never recovered from whatever happened to her when she disappeared. but at least got to say goodbye and be with her to the end, was very difficult time. ;__;

protip: after hours and hours of wondering why something isn't working, give up and try doing it a different way.

Earlier today finally got back to working a bit, ran into some unexpected behaviour on the ds itself that i couldnt replicate on no$gba. after a few frustrating hours going in circles, realized there was an even nicer more simple way to do it and did that instead. Still had the memory sharing problems, this:

Shared Work     027FF000h 4KB    -     -    -    R/W

is only explained as:

Region 2 and 7 are not understood?

sighs, so nor do i still do not fully understand them. but now know, if u want something to be always available at either cpu without caching issues, use this region.. it rly needs a malloc. and a semaphore mechanism. Along those lines have made some simple 8,16, and 32 bit ring buffer code. ^^

a thought: if had flushed the cache after writes on the arm9 side this might not have been a problem :D

otherwise, over the past week or so my kitty dissappeared, she returned 4 days later very worn and weak. Was very very worry. ;;

Also made new song for start menu.


Finally went to dentist last tuesday, was there for 5 hours... not very pleasant, but after a few days of recovery feel much better and have resumed working. \(^_^)/

Have a working FIFO library now. days of resting allowed a bit of ponderings, and decided to go extremely simple with the FIFO code channelizing transmissions and providing facilities for locating particular channels on either side. Additionally will create messaging and ring buffer libraries for dealing with higher level tasks. This makes things more flexible and should improve handling speed for some situations.

Have already a ring buffer library coded for another project. Will attempt to reuse that and save some time.. :D


Image from spritelib demo showing

found a bug in the bulletlib, very odd it didnt like that i preset a global to 0. Normally set globals in init functions, and had set this one the same, but for some reason when declaring it had int nextbullet=0; which caused things to go screwy whenever nextbullet equaled 0... @_@ still confused about that..

Made a simple stand alone example/demo for spritelib. Image on the right shows the result. :D

  • animated 64x64 kaguya.thg movable by the touchscreen on the left
  • grit converted 8x8 white dot on the top
  • spinning red star on middle left
  • 16 color 16x16 kaguya on the right
  • a 8x16 2 frame gfx on two sprites (frame 0 blue+yellow and frame 1 pink+green circles)
  • and a buncha 16x16 bullets to demonstrate the multiplexing ^^

Few things remaining to create, need a better sound fx system, and to do that need a decent fifo which would also improve the mp3 playback *sighs* really want to get back to the fun of pretty pattern making, but need these backend stuffs need doing first.. ~~

Also finally released a very rough example application for the thmp3 lib. Added some features so that it may used in a friend's rhythm game.

toof again a bit better than before, still worrying me at time. -_- Today and yesterday made good bit of progress on spritelib, cleaned it up, fixed some bugs, only one weird thing remains but it may be in the bullets system instead. Not sure..

Also since there was some interest in the arm7 mp3 library (using helix ofc), went ahead and broke it off into a seperate project. Moar non-game work, but letting others use the code will help me find and correct bugs faster and result in better code for all. ^^ Over the next few days will most likely be documenting and correcting bugs in the sprite and mp3 libs.

Toof getting a bit better, but still an an annoyance. ;; After talking with dovoto who is creating a pretty decent nondanmaku library for newest libnds, decided it was important to support multiple object/tile boundry sizes in thsprite. What that means is your not limited to the 128K vram banks for sprite tile data thsprite allocates by default. You can instead use 32, 64, or even 256K of vram depending on application. Some users may desire to use limited sprites and allocate the rest of vram for 3d textures, or may desire more tile data and use 256K.

Work is nearly done here, just need to modify the raw gfx loading functions (for loading grit processed sprites) and clean up a bit. Then can again get back to the actual game code. :D

Tooth still hurts... >_< Otherwise some progress in the spritelib! can now load 16/256 color images instead of just 256 which saves on vram meaning moar animations! Hopefully tonight will start to re-integrate the entities and spells libraries which should give me players, enemys, familiars, and ofc spells again. That would leave only thmenu and thgoodness libs which are the start menu and other game functionality (such as levels, scoring, and other gamey related stuffs).

2008.07.04 Tooth hurts really bad, keeping me awake at night. still working on the spritelib one feature left to add, loading of 16color in addition to 256 color sprites to save memory when possible.

Made more music, now have 26 minutes 54 seconds total! XDD Definitly not Zun quality, but i am improving. u_u

have met recently SquidMan who has started working on a touhou game for wii. ^^ I had a wii but sold it to buy the ds and a flash card instead, had it for almost a year and never played it. :\


Have drawn a few characters and created about half dozen musics, but the graphics and audio used in these screenshots are from a version some months back and taken from various internet sources.

first half of level (Ignore replay debug infos on top ~_~)
final spell of level, verily hard
Peak at some of the game code, and Utter Lunacy spell

I'll update more soon, working on spritelib a bit still, and got distracted making yet moar musics :D

Personal tools
irssi scripts
eggdrop scripts