gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Too many objects to use sprites (on both screen)

#83622 - Lagoon - Wed May 17, 2006 12:31 pm

I'm starting a project for a ds puzzle game
I'm new at ds programming and I'd really appreciate if anyone can help me move in the right direction with this game
The main problem I have is understanding which would be the best way to display my game. I've read libnds and PALib tutorials, so I already have some idea about the limitations of the various video modes.
Let me describe what I'm aiming at... both screen of the ds should have a game area: lower screen for the player, upper screen for the opponent.
The main problem is that I cannot, afaik, use ds hardware sprites because I need too many object on both screens. In fat che game area is made of at least 144 colored blocks (you can see it like a colomns clone with a 12x12 grid, but always full of blocks).
So it should be impossible for me to use hardware sprites and to use frame buffer too (because it can be used only on one screen and I need both screens with the game area). Maybe the solution is to use mode 5 with one extended rotational background for each screen? So I'd have to code a software sprite system myself and use it to create the two images to plot on the two screens... Any hint is welcome :)

#83630 - SeanMon - Wed May 17, 2006 2:32 pm

I'm not sure how Meteos handled its blocks (or even if the game you are planning to make is anything like it), but I'd guess that they used sprites for the falling blocks and then composited them onto the background when they had hit the existing stack.

#83632 - Mighty Max - Wed May 17, 2006 2:49 pm

In Mode6 you got some framebuffer-alike BG. (on both screens)

But i'd suggest a tiled-mode one grid-based games.
_________________
GBAMP Multiboot

#83633 - knight0fdragon - Wed May 17, 2006 3:02 pm

jusy do what they did in the old days

remember the background tile, apply the new tile,then when u move replace the tile


with ds and multiple BG its easier

use 1 BG for BG

and another fot its forground with transpareency

as long as ur not animating the tile u should be ok

(if u are, then edit the tile stored in bggfx, not each and every map spot)
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

#83673 - tepples - Wed May 17, 2006 8:04 pm

On the GBA (haven't tried on DS), you can do more than 128 sprites in a scene by rewriting OAM in horizontal blank. On the DS, you can conceivably do 1,500 sprites on one screen by drawing them as textured quads.

And Mighty Max is right: framebuffer is nearly useless when both screens can be set to extended rotation modes.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#83707 - Dark Knight ez - Wed May 17, 2006 11:28 pm

Haven't looked into it, but this might do the trick then:
http://forum.gbadev.org/viewtopic.php?t=9601
It supposedly draws 2D stuff using the "OpenGL" 3D hardware of the DS.

#83765 - Lagoon - Thu May 18, 2006 11:35 am

Thank you very much for your precious help guys, I really appreciate it, it's nice to have someone helping me start with the right foot :)
I'm not sure I've understood everything you sayd, but I'll study more, I promise :D
I've drawn a picture of the final result I want to achieve, here it is...
[Images not permitted - Click here to view it]
Let me explain it a bit...
Lower screen is the player, upper screen is the opponent (cpu or other ds player)
I'll talk about the lower screen, but most things are the same for the upper one
- the background is a static image, no animation is needed
- the character with the green dress is animated and changes animation according to what happens in the game
- the 144 blocks (those red, blue and yellow rectangles) are 10x10 pixel images, not animated.
- when the stylus hits one of the blocks, it makes a short animation to let you understand you clicked it
- when the stylus hits a second block, the two blocks are swtiched with an animation
- when the big red block or the big yellow block (which should be drawn as a central part plus 4 corners and 4 edges becase it can be a rectangle of any size) is hit by the styles, it pops with an animation and all the blocks above it fall down with an animation

this is basically what I need... which video mode would you use?

#83773 - Dark Knight ez - Thu May 18, 2006 12:58 pm

Nice concept screen.
Maybe using touch screen to select such a square can be difficult though, since they're pretty small and touch screen code tends (tended?) to be more inprecise at the edges of the screen. Might be a good idea to also let the user be able to select a square by using the D-Pad.

Anyway, one of tepples' suggestions was to use 3D on the DS to draw things. Basicly saying "draw a square here, and put this graphics on that square", and such. That could be done in the already available Open-Glide (3D) calls which are available in libnds. Using 3D, you can get way more "sprites" displayed at the same time on your screen.
Or you could probably use the library to which I just linked, in which you pretend it is all 2D in your own code, but the library executes it in 3D instructions, which basicly comes down to the same thing.
If one of the above options suits you, just choose the one which you feel most comfortable in: programming in 3D, or programming in 2D (which is executed by the library in 3D). Do note however, that the GL2D-library which I linked to is still in development. Ask the author about any details in the link I gave you.

#83784 - Extreme Coder - Thu May 18, 2006 3:56 pm

Nice to see my lib being advertised so early:P
Lagoon, if the number of puzzle pieces is THAT far, then you might think doing a similar setup to what my library does, or even use my library.I'd be willing to help you in both cases.

Or, another solution might be to use framebuffer(or mode5,they're really similar) for the static background, and use sprites for the character and also for the tiles that are being swapped.
Then you can use a tiled background for the rest of the tiles(although I'm not sure a tiled bg might be usable because of the space between the tiles).

And, nice concept:)

#83799 - josath - Thu May 18, 2006 5:03 pm

this can easily be done in 2d, with only 2 backgrounds, and 2 sprites

1. all blocks are normally on BG1
2. when you swap two blocks
A) create a sprite for both blocks
B) hide the tiles in the BG
C) animate the sprites swapping position
D) put the tiles back into the BG
E) remove the sprites
3. when the big block is 'popped', you could do something like:
A) copy all blocks above it that need to shift into BG2
B) remove them from BG1
C) slide BG2 downwards until they are in place
D) copy the tiles onto BG1, and remove BG2

#83827 - Lagoon - Thu May 18, 2006 8:55 pm

Thank you, you gave me great suggestions... I gave a look at GL2D source, I like it, I'm seriously thinking about using it...
Indeed I have to consider the touch screen edges sensitivity problem, it's a good point... But I think I'll have to make a simple demo to see if the game area is ok like I designed it... Do you think testing it on one or two ds will be ok? I mean... is the sensitivity problem "standard" or may it vary consistently from ds to ds?

to Extreme Coder: when you say "another solution might be to use framebuffer(or mode5,they're really similar)"... isn't framebuffer limited, whatever video mode I select, to one screen at a time? I know video mode 5 lets me use extended rotational backgrounds on both screens with a result similar to a double screen framebuffer (but performances?)

to josath: yes, it could be a solution... but probably (honestly I didn't consider it in gameplay so far) when a big block is popped I'd be forced to create gropus of falling blocks per column since the player or other game events could modify the falling height of a column and not of another (think if while the blocks are falling the player pops another big block near the one just popped, creating a deeper gap for part of the blocks which were already falling...). So one background (BG2) for the falling blocks wouldn't be enought, unless I update it when such events occur

#83840 - Extreme Coder - Thu May 18, 2006 10:18 pm

Lagoon: If you need help with GL2D, you can contact me at anytime.

And, you can easily select the two screens to use mode5,without performance slowdowns(but i'm not really sure)

#84322 - Lagoon - Sun May 21, 2006 10:25 pm

Thank you very much, I'll do some tests both with video mode 5 and with GL2D in the next days and I'll contact you if I'll have problems... well... no doubt I'll have ^^''

#84329 - tepples - Sun May 21, 2006 11:13 pm

How large is the playfield? It may help to make the tiles 12 or 16 pixels wide, as those sizes let you draw things in tile mode.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#84332 - Lagoon - Sun May 21, 2006 11:38 pm

Well, when I designed the game, since I did not know DS hardware in depht (well... ok... I still don't know it in depht!), I decided to make the blocks 10 pixels wide with 6 pixels of gap between them. But the width can be changed indeed, as well as the number of blocks, having a grid of 12x12 blocks isn't mandatory. Tiled mode in practice lets me update only portions of the screen (tiles) of 8x8 pixels, is it right? So having blocks of 16 pixels would result in an update of 4 tiles to update 1 block. And having blocks with a size in pixels multiple of the size of tiles lets me update the tiles with "prefixed" graphics, right? I mean... if my blocks are 10 pixels wide then tiled mode could be used but with the problem of generating on the fly the tiles based on more than 1 block (a 8x8 tile with a corner of one block and its center and other tiles with the other edges and corners of the block plus parts of other blocks and so on...)... which makes the use of tiled mode useless I suppose...

#84342 - tepples - Mon May 22, 2006 12:27 am

Yes. To draw a block of 16 pixels on a map, you update four tiles. Games all the way back to Super Mario Bros. have done this.

The slightly more complicated case is a block of 12 pixels on a map. In this case, you alternate the blocks between two layers: blocks in even columns go in one layer and blocks in odd columns go in the other. Then you can shift the odd-column layer to the right by 12 pixels. Puyo Pop is a commercial GBA game that uses this technique; for demonstration in an open-source game, try Luminesweeper.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#84360 - HyperHacker - Mon May 22, 2006 2:41 am

If your blocks are 10 pixels, with 6 pixels between them, then there's not really a problem. You simply need to create tiles for each possible combination of blocks that can be touching eachother, which is probably not that many. Depending how you design your graphics you can probably use flipping to your advantage.
_________________
I'm a PSP hacker now, but I still <3 DS.

#84366 - tepples - Mon May 22, 2006 3:24 am

If the DS 2D is anything like the GBA 2D, then cutting off the bottom of a tile is also straightforward, using HDMA to the scroll registers.

Or you could just set everything up as a rotation background, scale the tiles up to 16x16 when you load them, and then have the DS scale them back down.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.