btuduri / palibds

Automatically exported from code.google.com/p/palibds
0 stars 0 forks source link

New (advanced) function: erase sprite w/o erasing gfx even if it has no attached sprite left. #19

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a Gfx
2. Crate a sprite attaching that new Gfx
3. If I delete de sprite and no other sprite uses this Gfx, the Gfx gets
erased.

What is the expected output? What do you see instead?
I'd like to have control on Gfx by myself. Example: A Pang clone, I have a
Gfx for each ball size, and many sprites attached to those 4 Gfx. When
player destroys all ball from one specific size, this Gfx dies too, so I
have to reload, and it's anoying. I'd like to have a
"DeleteSpriteEx(screen, sprite, deleteGfx)" function.

What version of PAlib are you using ?
060917 

Testing on DS or emulator ?
DS and emulator.

Link to PAlib topic ?

Please provide any additional information below.
If this funcion doesn't get accepted, I'll do my own version, it's quite
easy, but I'd like to mantain compatibility with full palib, since I
request before I do.

Original issue reported on code.google.com by egon....@gmail.com on 28 Sep 2006 at 8:33

GoogleCodeExporter commented 9 years ago
Actually, it shouldn't be deleted. If you create the Gfx first, it counts like 1
sprite using it... Creating a sprite from it therefor counts as 2 sprites, and 
thus
deleting the sprite should not delete the gfx...

All in all, you should actually NOT use DeleteSprite when using this gfx 
method, but
just moving the sprite out of the screen (x = 256). It works better and is 
completely
Gfx-safe :)

Original comment by Molo...@gmail.com on 29 Sep 2006 at 8:10

GoogleCodeExporter commented 9 years ago
I come from PC development, and I see strange that way of dealing with sprites. 
IIRC,
you have an array of video memory and an array of sprites. That sprites don't 
have
the image they represent themselves, but a pointer to an image on the video 
memory,
and all other needed data (position, rotset...). I see no point in having so 
tied up
the gfx and the sprite. It seems more logic to me having a pool of graphics on 
the
gfx memory, and reattach a graphic to a sprite when it has changed. I mean,  by 
now,
when you animate a sprite, you have a graphic on video memory that is being 
updated
every frame of the animation from main memory, and you don't touch at all the 
sprite.
Wouldn't be better to simply having the animation frames loaded into gfx memory 
and
change the sprite pointer to the corresponding gfx? Only in case of 
insufficient gfx
memory you'll need to overwrite a gfx...
All in all, if you are interested in this issue, I can help you even code it 
for you.
I'm new on NDS development, but quite experiencied in PC coding (games and 
non-games).

Original comment by egon....@gmail.com on 30 Sep 2006 at 10:26

GoogleCodeExporter commented 9 years ago
Any chance you could come on Msn ? (molousk@gmail.com). 

Indeed, you do seem quite experience in coding, nice to see that ! The main 
problem
with loading all the animation into memory is that in 'most' cases it won't 
work : if
you have a main character animation that has like 3 frames for walking, in 4
different directions, plus other actions (jumping, attacking, etc...), you'll 
VERY
rapidly get to the VRAM limit, which is only 128kb, after all... So if you have
complex animations, your best bet will be to update the image every frame, 
which is
why be default it works that way.

In my personnal projects, sometimes I preload all the gfx and have a custom 
animation
system to change the pointer, sometimes I use the PAlib system, it's a question 
of
number of sprites animated at once and memory usage...

As for the primary question, the Gfx and Sprite aren't too much tied : if you 
use
PA_CreateGfx, Sprite and Gfx are handled independantly, deleting the sprite 
will not
delete the gfx (unless the system has a bug !). If you don't preload the gfx 
and just
use PA_CreateSprite, then it ties both of them together and deleting the sprite
removes the Gfx... I actually find that simple relatively flexible, as it 
allows me
to use both animation possibilities in the same projects...

Original comment by Molo...@gmail.com on 30 Sep 2006 at 8:54

GoogleCodeExporter commented 9 years ago
You could also open a topic on palib.com to talk about that :)

Original comment by Molo...@gmail.com on 30 Sep 2006 at 8:55

GoogleCodeExporter commented 9 years ago
Thanks for your comments, I've added you to my msn contact list (my nickname is
Egon), and I've read that NDS has 656KB of video ram... You can only use 128kb 
for
sprites??? Hope we can talk by msn.

Original comment by egon....@gmail.com on 30 Sep 2006 at 11:42

GoogleCodeExporter commented 9 years ago
I saw your msn contact, I'll wait for you to come up :)

As for the 656kB of ram, it's set for different stuff... You can have up to 
256kB for
sprites, not more, but in that case you can't have the 128kB bank for 
backgrounds,
etc... It's kind of a pain to manage ^^ It's just not a big VRAM from which both
backgrounds and sprites pick stuff, it's actually fragmented into several 
smaller
banks, and each bank can only be used for 1 kinf of stuff (sprite, background,
palette, textures)

Original comment by Molo...@gmail.com on 1 Oct 2006 at 8:16

GoogleCodeExporter commented 9 years ago

Original comment by Molo...@gmail.com on 1 Oct 2006 at 11:11