#46683 - rize - Wed Jun 29, 2005 2:30 am
I wrote an extended palette demo. It's extensively commented (a bit too extensively perhaps) so it's really noob friendly.
In addition to extended palettes, it also has hardware timers displaying the elapased time since you powered on the demo, 4 scrolling backgrounds, alpha blending, power down on lid closed and basic controls.
It uses the libnds and armkitr13 and only runs on real hardware at the moment (dualis doesn't support extended bg's in tiled modes).
http://www.geocities.com/zrizez/
If you want something that runs on dualis, grab the for mic__ version. It runs, but all the backgrounds show up as black.
#46685 - doublec - Wed Jun 29, 2005 3:15 am
This is great, thanks for making it available. One question on your wait for vblank code:
| Code: |
while(DISP_Y != 192); //loops until the last line of the current frame
while(DISP_Y == 192); //loops until the vblank starts
|
Why do you do this instead of using SWI 5 to wait for the vblank?
#46686 - rize - Wed Jun 29, 2005 3:18 am
Because I don't know what that is and this works :)
Feel free to educate me.
Btw, if anyone wants to spread this around and/or host it whatever, go ahead. Probably shouldn't link to the geocities thing as it has minimal bandwidth.
#46687 - doublec - Wed Jun 29, 2005 3:25 am
Have a look a the 'Vertical Blank Interrupt' part here:
http://www.double.co.nz/nintendo_ds/nds_develop2.html
Basically you set up an interrupt to occur when the VB happens. There is a Bios call, SWI 5, that will wait for this interrupt to occur then continue processing.
I don't know if there is an advantage doing it one way or the other. Just curious on your approach as I've seen others using it too.
#46690 - rize - Wed Jun 29, 2005 3:47 am
Essentially, the moment the vblank occurs you want to start doing anything that modified the screen contents. You'll want to finish making those modifications before the vblank is over. So when you're done you wait for the vblank.
And once graphical updates are done, you can do other things even during the normal frame writing as long as they're finished before the vblank arrives. In fact, I'll probably modify my code so that things that update the graphics get sort of queued in temporary holding variables and then written to the graphics hardware just after the vblank.
In this way of thinking, it seems that if a vblank interrupt occurs it would indicate an error (you didn't finish processing before the vblank arrived). Otherwise why not manually call a vblank method? I'm not sure what the good of being interrupted by a vblank is. Even if there is some generic processing you can do in the spare time a waitforvblank normally wastes (seti at home?) you could just put that in side your first vblank loop if you really want. I'm not sure why an interrupt would be needed.
edit:
I asked a bit in the chat and was told that interrupts are "nonblocking" and "save power". If there's some way to disable the arm9 and wait for the vblank interrupt to reenable it, then yeah that would save power and be better than looping with no code until the vblank.
#46698 - tepples - Wed Jun 29, 2005 6:02 am
At least on the GBA, using a vblank interrupt along with a wait-for-interrupt BIOS call saves power on real hardware and it speeds up emulation.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#46708 - LOst? - Wed Jun 29, 2005 7:15 am
| tepples wrote: |
| At least on the GBA, using a vblank interrupt along with a wait-for-interrupt BIOS call saves power on real hardware and it speeds up emulation. |
Thank you. That's good to know.
| Quote: |
| I wrote an extended palette demo. It's extensively commented (a bit too extensively perhaps) so it's really noob friendly. |
Thank you, this worked on the real hardware.It will be very useful for me thanks to the heavy commented code.
#46709 - rize - Wed Jun 29, 2005 7:27 am
You're welcome. Thanks to mic__ for explaining the details to me enough to get it running. desktopma also made one although I'm not sure if he made it public (I know mic was using it to help get extended palettes working on dualis). Hopefully Dualis will be able to run it very soon!
#46718 - LOst? - Wed Jun 29, 2005 1:52 pm
| rize wrote: |
| You're welcome. Thanks to mic__ for explaining the details to me enough to get it running. desktopma also made one although I'm not sure if he made it public (I know mic was using it to help get extended palettes working on dualis). Hopefully Dualis will be able to run it very soon! |
If you have the time, maybe you can make it ARM7 compatible with Vertical Interrupt support.
I think that is the only thing you missed.
#46725 - rize - Wed Jun 29, 2005 5:01 pm
Well, this is a bit more friendly. I think people should learn interrupts elsewhere and intergrate it themselves so that they fully understand them.
Speaking of which, I should also mention that (although it's relatively unrecognizable now) my entire program is based of of desktopma's template.
#46732 - LOst? - Wed Jun 29, 2005 6:51 pm
| rize wrote: |
| Well, this is a bit more friendly. |
You got a friendly version of your code, and it is great. I still think you should add the Vblank interrupt (ARM7 code) because it is the propper way to do games.
Of course you can do it the computer way, and hope you will finish drawing in time, but if you didn't finish the drawing, that while vcount (fake vblank) will be the devil.
I tried once to do games using a fake wait for vblank because I was a newbie and no one had made a tutorial that showed me the benefits of a vblank interrupt. I had a screen buffer and no way to tell if it was done before or after the vblank occured.
With the vblank interrupt, you can force to not draw anything the next frame because you can turn off the vblank interrupt. That's how you do to frameskip something that takes longer to draw, so it can be drawn in two frames (hidden) instead of showing garbage on the screen. So you keep the interrupt disabled until the screen buffer has been finished, and then turn it on. It will be displayed, and then turn the interrupt off again. The propper way.
Also other benefits are power saving and more game structure. Some people may disagree with me. I have spent the last two year learning how they made games such as Sonic The Hedgehog and Super Mario Bros. by disassemble them, and they use a vblank interrupt to manage game scenes and structure up sprites using DMA. I go by these games. Disagree if you want. I will still go by the old games which made me become a programmer in the first place :P
#46736 - TheMikaus - Wed Jun 29, 2005 7:39 pm
Well if it's alright with rize. You could probably just add it, comment it and repost it. you seem familiar with the territory and since rize put the source out in the first place, perhaps it's alright to change it a bit and rerelease it as long as you give credit. But then I should let rize let you know if it's ok or not.
#46742 - doublec - Wed Jun 29, 2005 11:14 pm
I looked at the disassembly of the ARM 9 BIOS for SWI 4 and 5 which does the interrupt wait. It does a coprocessor 15 instruction which I'm unfamiliar with. Does anyone know what this does:
| Quote: |
FFFF07E8 MOV LR, #0
FFFF07EC MCR p15, 0, LR,c7,c0, 4
|
Once it has done this it does a branch to some code which checks DTCM+0x3FF8 to see if the bit related to the interrupt that we're waiting for is set. If not it it goes back to FFFF07e8 which is the MOV before the MCR instruction. Is it the MCR that does the power saving?
DTCM+0x3FF8 is VBLANK_INTR_WAIT_FLAGS define in NDSLIB. This is why it needs to be set to the interrupt just processed as described my tutorial I mentioned earlier in this thread.
Last edited by doublec on Thu Jun 30, 2005 1:03 am; edited 2 times in total
#46743 - doublec - Wed Jun 29, 2005 11:34 pm
Saved by DarkainMX on IRC. The CP15 docs show it as a way of setting the ARM9 processor into a low power mode. See 2.24 of:
http://www.arm.com/pdfs/DDI0155A_946ES.pdf
| Quote: |
| This operation allows the ARM946E-s to enter a low power mode. When you invoke the operation, the CLKEN signal to the processor core is negated and the cache and tightly coupled memories are placed in a low-power state until either an interrupt or a debug request occurs. |
#46757 - rize - Thu Jun 30, 2005 5:55 am
yeah, I definitely agree that the interrupt is better. I just didn't think that all demos need it. But what the hell.
Thing is I need to know how to set up interrupt handlers and all first and how to call a bios function. Haven't learned that yet.
#46802 - doublec - Thu Jun 30, 2005 10:58 pm
I've just written a tutorial about it:
http://www.double.co.nz/nintendo_ds/nds_develop8.html
Hopefully it helps clarify things. It was your post that prompted me to look into why use interrupts over just looping so thanks for that. I didn't actually know about the power savings advantage beforehand.
#46807 - rize - Fri Jul 01, 2005 12:55 am
again, glad to contribute wherever I can, and thanks for the interrupt thing
i'll modify the extended palette demo shortly
#46819 - rize - Fri Jul 01, 2005 3:22 am
Ok, vblank interrupt is now used, thanks doublec
http://www.geocities.com/zrizez/index.html (first file)