#42057 - astu - Thu May 05, 2005 7:04 am
i'm sorry to ask, this may be waste of your time,
but i still haven't found any _good_ information about video handling.
i'd be pleased to know how can i put my sprites to touchable screen.
currenty i'm copying those sprites to OAM_SUB, which seems to be at 0x07000400.
it seems to have no effect if i changed those parameters for that sprite.
should i tell [what?] to use [what?] bank or something?
currently i'm running out of ideas what to try next and i'd be very thankful
if you'd point me some source of information where to look at.
i really like this machine and want to develope something for it.
and yeah, this ain't my first platform. i've been coding for several years.
this is first one for a long time when i'm feeling newbie :)
thank you for your help
#42058 - josath - Thu May 05, 2005 7:37 am
sprites are exactly the same as for GBA, except there are two screens (which are completely separate, generally). Look at a gba technical document for the details (like gbatek or cowbite spec - google for them, i'm too lazy to look up a link). Or find a gba sprite tutorial if you need a quick walkthrough of the basics.
#42061 - astu - Thu May 05, 2005 8:02 am
i have sprites on top screen, but i'd like to have some sprites at another screen too.
i've never coded anything for gba or any other nintendo device, so this is
quite a new stuff for me.
i'm familiar with many concepts of that device since i've programmed for
couple of other specific machines.
i know those screens are separate, main problem for me is that how to
tell sprites where i'd like them to be drawn.
i've tried to copy those to another bank and use that with touch screen,
but i seem to miss something inportant since i didn't succeed :)
it's easy to grab screen address and draw them manually, but that isn't what i want.
sprites give me "free" scaling etc
#42064 - DekuTree64 - Thu May 05, 2005 8:22 am
Let's see, steps should be:
1. Turn on power to bottom screen (probably done).
2. Turn on screen and sprites in sub disp control (bits 16 and 12, I think).
3. Allocate some VRAM for sub OBJ.
4. Put some image data in sub OBJ VRAM (0x6600000).
5. Put some colors in sub OBJ palette (0x5000600).
6. Set up sprites in sub OAM (0x7000400).
Unless I forgot something, that should do it.
Actually not incredibly more complicated than GBA. Just the VRAM allocating causes the most trouble. And having to turn the screen on in two places. I still haven't found what motivation the hardware designers had in that one.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#42082 - dafer - Thu May 05, 2005 3:40 pm
But you really do not turning on the screens twice?
Ain't bit 16-17 in DISPLAY_CR just telling what extended screenmode to use?
_________________
/As meningful to you as words written in water.
#42083 - tepples - Thu May 05, 2005 3:48 pm
| DekuTree64 wrote: |
| Just the VRAM allocating causes the most trouble. And having to turn the screen on in two places. I still haven't found what motivation the hardware designers had in that one. |
If you turn on only one of those bits and view the screen under a light that's bright enough to make the original GBA Castlevania playable, do you get a faint image? Perhaps one turns on the screen and the other turns on the backlight.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#42088 - josath - Thu May 05, 2005 6:56 pm
when the screens are 'off', the backlight is still on, but the screen is white. turning off the backlight is handled somewhere else i believe