#147885 - thegamefreak0134 - Sat Dec 29, 2007 9:52 pm
I know this is probably an old question, so here goes.
I recently updated devkitPro from devkitARM r19 to r21. When I did so (including updating libnds) all of my touch code in all of my programs stopped working when I recompiled. I've looked at the values being returned by the code and it's particularly odd. Was the touch code modified severely between those revisions, or is there some newer function I should be using to get the stylus position now? What I get now looks like I'm getting raw reads where I should be getting pixel (screen position) reads, and garbage reads where I should be getting raw reads. The X value for raw instead of random garbage is instead constantly incrementing. The entire effect looks like the functions are now returning things in a different format than the header I am using expects them to be returning, which is odd since they were both updated at the same time. This scenario holds true with all of the examples in the devKitPro folders.
As a result of this, we (me and my friend) are using r19 for all of our coding, and simply updating the header files to the new version when we need some of the newer defines. This is going to make our source code highly non-portable, and it would make me happy if I could know what is going on with the touch code. I can post code examples if necessary, but the touch input test in the examples folder gives the best example of what is going on with our code. I think it may even be copied from there.
-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#147896 - tepples - Sun Dec 30, 2007 2:09 am
The format of the IPC struct changes with each version of libnds. Make sure that all of your project's .o files get deleted when you upgrade libnds. (Make won't automatically do this.) And if you're using a custom ARM7, try copying the VcountHandler() and main() functions from the template's ARM7 code (.../devkitPro/examples/nds/templates/combined/arm7/source/template.c) into your project's ARM7 code. It is my experience that the changes to the combined template's ARM7 code from version to version happen mostly in those two functions.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#147926 - wintermute - Sun Dec 30, 2007 6:03 pm
tepples wrote: |
The format of the IPC struct changes with each version of libnds.
|
And will eventually vanish. Avoid using the IPC struct at all.
You should be using touchReadXY to get touch screen co-ordinates.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#147930 - tepples - Sun Dec 30, 2007 6:28 pm
wintermute wrote: |
You should be using touchReadXY to get touch screen co-ordinates. |
I just looked it up; it's in .../libnds/include/nds/arm9/input.h. Thanks for pointing it out. So if the IPC struct will disappear, I take it the ARM7 will pass the info to the ARM9 through the FIFO, right?
Semi-related: Why is KEY_TOUCH defined this way? It doesn't appear to match the hardware.
Code: |
KEY_X = BIT(10), //!< Keypad X button.
KEY_Y = BIT(11), //!< Keypad Y button.
KEY_TOUCH = BIT(12), //!< Touchscreen pendown.
KEY_LID = BIT(13) //!< Lid state.
|
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#147933 - wintermute - Sun Dec 30, 2007 6:38 pm
tepples wrote: |
Semi-related: Why is KEY_TOUCH defined this way? It doesn't appear to match the hardware.
|
How would you suggest "matching the hardware"?
We combined the key bits from arm7 and arm9 into a single 16bit value rather than having a 32bit value or treating them separately. Makes as much sense as any other way to do it.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#147934 - wintermute - Sun Dec 30, 2007 6:42 pm
thegamefreak0134 wrote: |
I recently updated devkitPro from devkitARM r19 to r21.
|
Is there any chance people could stop doing this?
devkitPro is the toolchain vendor, you don't upgrade it.
Most of your problems will probably be solved by doing a clean rebuild of your project and the examples after upgrading devkitARM.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#147936 - tepples - Sun Dec 30, 2007 7:25 pm
wintermute wrote: |
We combined the key bits from arm7 and arm9 into a single 16bit value rather than having a 32bit value or treating them separately. Makes as much sense as any other way to do it. |
I would have suggested the obvious extension to 32-bit, but this makes sense too. I'll take the naming issue to another topic.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#148085 - nce - Wed Jan 02, 2008 1:30 am
I haven't read all the thread sorry if I say somthing stupid
It's probably something different but the result I had was quite the same when I switched from the R19 to the R20.
I had all the data in the touchscreen texture inverted. When I wanted to read from px py it was working on emulator but on real hardware I was forced to read x and y .... that was looking quite strange :)
I finally drop on a thread here speaking about a compiling problem and the prob was a conflict between visual studio 6 and devkitARM.... And yes there is a conflict !
If like me you have visual studio installed what I'm doing to compile nds code is to have a bat file that rename the VC98 folder from visual studio and launch the make comande so it will use the make from devkit and not from visual and the rename back my VC98 folder....
Hope it help to understand that sometimes errors can come from something realy hidden :)
_________________
-jerome-
#148090 - wintermute - Wed Jan 02, 2008 2:41 am
nce wrote: |
I finally drop on a thread here speaking about a compiling problem and the prob was a conflict between visual studio 6 and devkitARM.... And yes there is a conflict !
|
No there isn't.
Quote: |
If like me you have visual studio installed what I'm doing to compile nds code is to have a bat file that rename the VC98 folder from visual studio and launch the make comande so it will use the make from devkit and not from visual and the rename back my VC98 folder....
|
Visual Studio's "make" is actually called Nmake and isn't compatible with gnu make. If you have something called make in there then you've modified your installation or installed something else to the same location.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#148094 - thegamefreak0134 - Wed Jan 02, 2008 5:32 am
I do apologize, wintermute, for the incorrect comment. I do know the difference, call it a typo.
Code: |
touchXY = touchReadXY(); |
That's the line we use, and that's the exact line that has issues.
tepples, from what I can tell, doing a clean (which delete's the .o files) and then a make still produces the errors. I'll try copying the code though, but I need to get my hands on a fresh copy of r21 again, which I can't do until the 3rd. (I'm stuck on dial-up here.) I'll get back to you if I find a solution, but all that you suggest sounds very reasonable.
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#148151 - nce - Thu Jan 03, 2008 1:05 am
wintermute wrote: |
Visual Studio's "make" is actually called Nmake |
Yes indeed, I'm not a pro in all compilation and link stuff, when it's working I'm happy when not I become crazy that's all LOL.
is maybe not the make but the link. What I do know ( and you are not forced to beleive me :) ) on 2 differents computers ( clean xp sp2 ) when I installed a fresh visual studio 6.0 and R20, that bug appears....
I know one day I should try visual studio 2005 and stop using this old 6.0 ....
_________________
-jerome-
#148158 - M3d10n - Thu Jan 03, 2008 3:27 am
VC++ 6.0? Good lord!
I use VC++ Express 2005 for DS dev (using a makefile project which just calls "make") and had no problems with it.
Actually, when you add the path to the libnds header files into the project's include paths you get magical intellisense auto-complete for all the libnds stuff.