[V1.0a] Knytt Stories DS

No prob .

That's great. I'm doing DS knytt stories as soon as possible. 

Wow this looks pretty awesome Definitely gonna put this on my R4 once I get off work

Just finished trying it out, seems like it still has a long ways to go. One thing I noticed is that lasers are really broken. Whether it is on or off it always kills you.

Just finished trying it out, seems like it still has a long ways to go. One thing I noticed is that lasers are really broken. Whether it is on or off it always kills you.

I believe this is an already known problem and has been fixed in the version in development.
http://www.rodrigoroman.com/rrc2soft/nds_dsknytt.html

How goes the progress on this? We've not had an update in a while.
Just wanted you to know there's still people out there who care about this project.

...and there is still someone who seems to care about finishing it (weird guy...  )

I am now trying to design the custom objects, which is quite problematic - some of them are quite big, and I am always limited by the HW limitations of the DS and my (*cough*  ) lack of design for oddly-sized critters.

I have to fix some other stuff (Juni's movement, weird errors,...) and to implement all the critters that are not finished.

And after that, the remake will be finished  (although, as LPChip said, it will be finished between tomorrow and 55 years... OK, 1 year at most  )

almost done keep it up.
resistance hits hardest when the end is nearest.
but it sounds like you have it under control.

Don't worry. Support for your endeavors has not yet ceased. I, for one, am still very much looking forward to an eventual full release. A fully functional (or at least close enough to it) Knytt Stories would be most welcome on my DS.

Thanks, all your encouragement is deeply appreciated  . I can say that, as of today, the design of the logic behind the CO has been finished, and I am 99% sure that all types of CO (even those who are too much for the DS to handle, such as the CO that can be found on levels like "The deserted rustyard") will be supported, although with some limitations (big CO won't be animated, sorry).

Sounds good!
can you define what "big" is?

I'll skip the technical explanation  , and say that every CO whose area is bigger than 64x64 (or bigger than 128x128, need to make some tests) won't be animated. Besides, any CO whose area is bigger than 128x128 won't be considered as an sprite, and there will be some small glitches. 

I'll skip the technical explanation  , and say that every CO whose area is bigger than 64x64 (or bigger than 128x128, need to make some tests) won't be animated. Besides, any CO whose area is bigger than 128x128 won't be considered as an sprite, and there will be some small glitches. 

That must be from the limit: 16x32x64x128?
i didnt know that there was a 128?
i only know a bit of palib so there might be a workaround

Quote from: rrc2soft on December 14, 2009, 13:59:09

I'll skip the technical explanation  , [...]

That must be from the limit: 16x32x64x128?
i didnt know that there was a 128?
i only know a bit of palib so there might be a workaround

I'll give the technical explanation 
I use the Sprites3D of palib, in order to have more sprites on the screen. The amount of memory available for the textures (i.e. the graphics of the sprites) is 256x256 pixels, although one part of 128x128 pixels is used for Juni and the dialog window.

Why COs whose area* is bigger than 128x128 won't be considered as sprites? Because I need to store the image of the sprite on the VRAM of the DS, and I only have those 256x256 pixels free. Note that I already use two VRAM banks for the textures, but one bank contains the background.

Why COs whose area* is bigger than 64x64 (128x128) won't be animated? Because I need to update the image every certain frames, and I have limited CPU time to do that (although I am sure I can do some optimizations somewhere...). Besides, some CO animations are pretty big, and the DS have 4MB who are shared by the data, the music, the sprite animations...

(Nevertheless, I am sure there are plenty of optimizations to do somewhere, but I want to finish the game and to provide a good user experience... OK, I am a bit lazy )

*Actually, I have implemented a system that allows rectangular sprites, so sprites with strange sizes such as 16x640 are allowed 

Woah.
k
so yourr using the 3d functions to create the 2d screen so you can have more of them?
you wont have larger ones because of the limit of vram?
and not animated because of cpu
 
maybe a ram pack could help fix some of these problems (gives me an excuse to get one  )

btw with the 16x640 Thats awesome!! if i could do that then my games wouldnt have to be so grid based!
Good Work!!