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 > NintenCats help needed

#89250 - iainprice - Fri Jun 23, 2006 7:54 pm

Hi,

Yes I'm playing with some MD2 files and the touch screen.

Any ideas of nice algorithms to detect which polygon I am touching with the touch screen?

Cheers

#89271 - tepples - Fri Jun 23, 2006 11:25 pm

You shoot a ray out from the camera origin in the direction of the touch, and then you find objects on that touch position. But why specifically do you need to detect which exact polygon of the model was touched? Why isn't it enough to cast the ray to a bounding sphere?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#89282 - josath - Sat Jun 24, 2006 12:09 am

maybe he wants to detect which part of the cat you are touching.

#89338 - iainprice - Sat Jun 24, 2006 10:24 am

Yep, that's the one. If you are touching its back I want to switch to an animated section for arching back... etc.

#89351 - HtheB - Sat Jun 24, 2006 2:11 pm

NintenCats? O_o

#89382 - silent_code - Sat Jun 24, 2006 5:27 pm

meowe! :)

sweet idea :) hope you get it done :)

well, nearly everything has been said. you need to look for unprojecting from screen to worldspace (for the "touch ray") and then determine the closest model (not necessarily the first you find - depends on your implementation) the ray hits. after that you transform the ray segment that is inside the boundig volume and test each tri against the ray segment. you can also have a sub bounding volume hierarchy to minimize ray/tri tests. if that test fails repeat for the second closest model...

happy copding!

#89390 - iainprice - Sat Jun 24, 2006 5:54 pm

Surely there's a much easier way.

You only draw visible polys to the screen. You know which poly is drawn to which part of the screen and you know where your stylus is on the screen...

#89392 - silent_code - Sat Jun 24, 2006 6:00 pm

how would you do that?
and especially with hardware drawing?

poly indexing (the opengl thing)... is that available in either hw or libnds? i doubt it...

#89403 - MaHe - Sat Jun 24, 2006 6:51 pm

Huh ... I love cats, but let's face it: what could you do? Feed the cat, pet the cat, clean the litterbox and let it out. That's it. Sure you don't mean to implement a function to take a cat for a walk ... Do you?
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]

#89407 - tepples - Sat Jun 24, 2006 7:12 pm

MaHe wrote:
Huh ... I love cats, but let's face it: what could you do? Feed the cat, pet the cat, clean the litterbox and let it out. That's it.

That's why the homebrewers simulate cats and leave the dogs to the paid professionals :-)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#89415 - Zed0 - Sat Jun 24, 2006 8:33 pm

If it were me I would just do a bounding sphere or hemisphere for say, the nose, the top of the head, bottom of head, each foot, belly, back and tail
_________________
__Zed0__
FlasheMe'd Silver DS - GBAMP-CF - 512MB CF Card - R4DS - 2GB Micro SD Card

#89519 - iainprice - Sun Jun 25, 2006 9:30 am

I know there are threads on 3d on both screen but I can't get 3d on the bottom screen in hardware but it works in ideas emu...

I don't want 3d on both screens, just the bottom. What am I doing wrong?

#89530 - Dark Knight ez - Sun Jun 25, 2006 11:07 am

I'd suggest posting your code in which you setup the environments.
Meaning your vramSetBank(..)s, and your setVideoMode(..)s and such.

#89632 - iainprice - Sun Jun 25, 2006 9:55 pm

[code]
videoSetMode(MODE_0_2D | DISPLAY_BG0_ACTIVE);
videoSetModeSub(MODE_0_3D);
vramSetMainBanks(VRAM_A_MAIN_BG, VRAM_B_TEXTURE, VRAM_C_SUB_BG, VRAM_D_TEXTURE);
[/code]

#89678 - HyperHacker - Mon Jun 26, 2006 5:03 am

Maybe videoSetModeSub(MODE_0_3D | DISPLAY_BG0_ACTIVE);? I remember hearing that the 3D image replaces BG0.
_________________
I'm a PSP hacker now, but I still <3 DS.

#89699 - Dark Knight ez - Mon Jun 26, 2006 9:36 am

Try BG3 instead of BG0.

#89855 - crossraleigh - Tue Jun 27, 2006 12:23 am

Engine A (which normally draws on the top screen) does 3D, while Engine B (which normally draws on the bottom) does not. Toggle the swap bit in POWER_CR to make Engine A draw to the bottom screen.

#89942 - iainprice - Tue Jun 27, 2006 3:57 pm

system.h has several defines. Which bit do I need to change?

#90465 - xtoc - Fri Jun 30, 2006 9:42 am

- nintendoZoo will be a great idea with wifi support :p

#90467 - crossraleigh - Fri Jun 30, 2006 10:26 am

Bit 15. Look for POWER_SWAP_LCDS in libnds.

#93402 - iainprice - Tue Jul 18, 2006 11:47 pm

I'm still after a little help for sensing which part of an MD2 you are touching when displayed. I have a lot of the 3D and 2D work done. A few sprite problems but optherwise looking good. I still need to be able to change from one animation to another depending on user input.

Any ideas?

#93458 - dovoto - Wed Jul 19, 2006 6:57 am

I recently (a relative term) added the ability to read the number of vertecies rendered to the screen using a glGet(). THis should allow you to do 3D picking.

Some psudo code
Code:

capture 3D to vram and display as 2D

(x,y) = touchPossition;

viewport(x-1,y-1,y+1,y+1, z...)

for(i = 0 to polycount)

count = glGetInt(GL_GET_VERTEX_RAM_COUNT)

renderPoly(i)

countnew = glGetInt(GL_GET_VERTEX_RAM_COUNT)

if(countnew > count) hit(i);

end for

restore viewport

restore video mode



This requires a free vram bank to capture the output of your scene and hold it while you render a small screen centered about your stylus. Because the vertex counter only increments if the poly is rendered on the screen you will get a hit if any polys render to near the stylus location.

This is roughly the way openGL implements picking.

A raycast is an alternative method that does not require a free vram bank and probably is faster (it takes an entire frame to do the picking as described above). The raycast is just much more complex.
_________________
www.drunkencoders.com

#93508 - iainprice - Wed Jul 19, 2006 4:38 pm

Is there a ray cast tutorial or explanation on the web you can recommend as vram banks are scarse!

#93573 - tepples - Wed Jul 19, 2006 10:54 pm

dovoto wrote:
(it takes an entire frame to do the picking as described above)

It didn't stop NES games that used the Zapper for picking.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#93617 - crossraleigh - Thu Jul 20, 2006 2:14 am

I don't think dovoto's method of picking will work. Writing to GFX_VIEWPORT scales the view instead of cropping it. Any poly that was visible before changing the viewport should still be visible afterwards; it will just be squished.

#94692 - Payk - Tue Jul 25, 2006 8:44 pm

HMhmh whats up guys??? Camerasettings ....compute a vector...damn
like u would do in mathmatics with x,y and searching for a crosspoint of to lines...just in 3d....but damn it will cost much calulations...i would recommand fixed point of course...maybe i right a code for you...

#94806 - HyperHacker - Wed Jul 26, 2006 6:19 am

I have some raycasting code here that was working somewhat, but no longer does for some reason. Maybe you can use it; maybe someone can even tell me what the heck is wrong with it.
_________________
I'm a PSP hacker now, but I still <3 DS.

#94865 - Valmond - Wed Jul 26, 2006 3:17 pm

You can also make a matrice that translate the world so that the ray
casted starts at 0,0,0 and goes to 1,0,0 (for example).

Checking intersections should then be a piece of cake (2 crossproducts, right ?) even if tou have to make a matrix mul / vertex.

Well, that's a way anyway.

/Valmond
_________________
N?fer & LudLib

#94921 - iainprice - Wed Jul 26, 2006 9:54 pm

Payk if you are offering.....

any psudeo code, examples, suggestions....

I need to calcuate which poly/area of the md2 model you are touching...

#95143 - Payk - Fri Jul 28, 2006 12:41 am

hmh i have to sleep now but will do it tomorrow...
promissed...i also use md2 so i will be able to test..

#95145 - Payk - Fri Jul 28, 2006 12:52 am

but have to say it would calculate much
there is one way which is very easy and absolutly fast & sure succes...but costs vram...
if u have that cat...displaycapture just the cat...no texture...glcolor it in green....backgroundcolor should be black...lets say i map that to vramc...
u have touchpos x,y...then u check the content of vram if color is green or if color is black...no crosspoduct is needed...the only problem is while doing that capture...u have a green cat on display...how to avoid that?
capture current scene first...make a bg over 3d scene ...display the capture....
now u render that green cat...display capture to vram now u can make next frame and free that bglayer which is over scene....that would be the dirty and fast way...but succes is sure...and if u make that just when touching...noboy will take notice that 2 frames are misssing..if u have a good framerate...i could help u to get a good one too..

My game runs at 60fps (since some hours)...
http://payk2005.pa.funpic.de/New.emu.nds
and it uses many light calculations and such a things...and the hole scene just needs one vram-texture bank (8bit textures are great)

but still i will make a code for u...the thing is ....more polys...more calculations....so it will be 2 functions...
one easy which just looks if that poly could be touched...very stupid one ...just to avoid the other function as much as possible..
the other function will calulate more...also both functions need the real position and rotation...when using matrix you could not easy know that...
dunno your code...i had to face same problems when coding my lights...
i never found out how to get back rot , scale and translate datas...so before each rot/trans/scale i gave data to another function to store...

#95284 - dovoto - Fri Jul 28, 2006 4:21 pm

Payk...very cool. Lets see a bigger level! :)
_________________
www.drunkencoders.com

#95409 - Payk - Sat Jul 29, 2006 7:19 am

yeah thanx....hmhm that displaycapture idea is cool...i just thought about...when touching make a capture to vram...each ground plate has r=10 g=x b=y as color (13x13 is viewfield) each char could use r=20 or obects beign with r=0....then i will make a controlment like zelda...should work...

#95822 - HyperHacker - Mon Jul 31, 2006 6:23 am

Yeah, colour picking is nice if framerate isn't an issue. What you can even do is render every polygon in a unique colour (doesn't matter if your eye can tell them apart) with no textures, so you can tell what polygon is being touched. You might make this even easier by setting the background colour to RGB 0,0,0 and using the R, G and B values of the polygon's colour as IDs of some sort. EG suppose you have your scene broken up into objects, which are made up of multiple shapes, which contain several polygons... you can use the red value as the object ID, green as shape ID, and blue as polygon ID.
_________________
I'm a PSP hacker now, but I still <3 DS.

#95901 - jester - Mon Jul 31, 2006 2:09 pm

Any progress on Nintencats???

#95933 - iainprice - Mon Jul 31, 2006 5:04 pm

I am getting there... there are so many animations to make for different movements and actions....

#95938 - jester - Mon Jul 31, 2006 5:28 pm

any screenshots yet??

#96108 - Payk - Tue Aug 01, 2006 12:02 pm

HyperHacker
Hmh i have 60fps in my game...so if u touch the screen u will lose 1-2 frames....just in that moment.
and that ID thing i will make.
R=0...nothing
R=1...ground
R=2...obj
R=3...npc
R=4...enemy
R=5...item

so G/B can then be used as index...for those grounds on screen G=X and B=Y for example...so a 32x32 tiled-field can be touched

But not the end HyperHacker...thing about a fence which is build of 2 polys..a texture with visualgaps is needed
[Images not permitted - Click here to view it]
so black here is invisible in game...so with a calculation solucion u never could touch whats behind fence. but if u use that color solucion u could precalc a blackwhite texture (16color of course) where black=invisible white=visible....and when rendering that colored scene u use that b/w-textures so u realy can hit trough the gaps of the fence...

#96110 - Payk - Tue Aug 01, 2006 12:28 pm

Dovoto?
http://www.lighthouse3d.com/opengl/picking/
^^Namestack? why not porting that? or u thing it uses raycasting?

#96190 - dovoto - Tue Aug 01, 2006 8:20 pm

Payk wrote:
Dovoto?
http://www.lighthouse3d.com/opengl/picking/
^^Namestack? why not porting that? or u thing it uses raycasting?


Yes this is the picking I describe. The functionality is allready present in libnds. Simply capture the current frame to vram and display it as a 2D static image (this freezes the display), zoom in on the place you touched (and probably set an ortho render mode). then render your scene one object at a time. Comparet the vertex counter before and after each object and if they are different then you know that object was rendered. Fortunatly the DS hardware will not render anything that is completely off screen. Because your viewport was so small and centered on the touch then you can assume that any object rendered is in line with the touch.

I may do an example of this but I will not be implementing the actual method that GL employs to keep track of the "hits" as i dont much care for it.
_________________
www.drunkencoders.com

#96304 - Payk - Wed Aug 02, 2006 1:16 pm

There is just one problem...if u call capture reg u have to wait till next frame, right?
so when making a loop which goes trogh the mesh and capturing after each poly in order to get pixel...it will cost that much frames polys are tested...when i understand that right...if not..your method is better since it cost just one vram bank instead of 2

#96305 - Mighty Max - Wed Aug 02, 2006 1:30 pm

If you can abuse the capture, you can do a hidden render, where you replace any texture just with a color indexing the object it belongs to.

Reading the pixelcolor would then point you back to the object there.


For the most cases tho, i'd recomment to check if the line cast from the cam's root to the screen's pixel intersects either the polygons or bounding boxes for the objects (faster due to less calculations)
_________________
GBAMP Multiboot

#96457 - Payk - Thu Aug 03, 2006 2:18 pm

Last night dovoto and me talked about all these...he gaves me a working pc example and a source of a glu-function which is missing on libnds...
with that things it will be easy to code the method dovoto descriped here.
it will cost one vram-bank and one frame to detect which poly or polygroup was touched. Thanx for sources and a lot of infos.
I am pretty sure it will work...i just understood him wrong before...now its clear and understandable for me...i will code an example of this. I have a working PC example...so it will be easy...Thanx dovoto!

#97866 - Payk - Sat Aug 12, 2006 12:44 am

Hi there...Dovoto and me searched for other easy solucions.
He made gluPickMatrix and i did same independendly....
both causted blackscreens.

So i thought about how to make it just using 1 Main-Ram-Bank
(its very important for me)

My color picking method would generaly work. But it costs one BG to hide the 3d scene and one mainbank to catch 3d scene.

The Only solucion i see then is:
-First Capture 3D scene as 128x128 image to vram a,b,c or d
-Next frame read out the captured to vramE and display as main bg streched right in order to fit: [Images not permitted - Click here to view it] it doesnt look that bad i had tought...

So now 3D scene is hidden and main bank still can be used to capture...

-Render Cat for example in green
-Render toys of cats in different blue colors
-Clearcolor was hopefully setten before to black or its still that case.

Next frame:
-Render normal scene again and and switch of the 128x128 BG layer.
So now mainram is filled with touch infos vramE is usable again and u can code what u want.

There is just one thing:
I use vramE for texture pals....is there an easy way to store it to a different bank?
Thanx....

This color method should be easy to code.
Just that pal thing is a problem for me. If nintencats works with 16bit colors...u wont have any problems and 3 texture banks to use.
i will try to use vram E as bg and get pals working in my game...then i will code that color picking...

#97882 - omaremad - Sat Aug 12, 2006 2:56 am

wow you guys are going a bit far with per polygon collsion detection for the cat, it would mean:

1-huge memory used as each polygon needs group data
2-1500 polygon cat imagine cheking every polygon that would take ages.

my method is very fast and very easy:

when the player touch the centre of the touch screena value of 0 is added to the virtual cameras rotation matrix

when the player touch just above the centre the x rotation increases in the virtual camera matrix

etc..

the virtual camera looks theroretically in the direction of the touch ie sorta like a first person shooter camera, then we shoot a ray out of this virtual camera and then it hits a bounding box, the bounding box has the same translation as one of the cats bones. therefore we get the limb that is touched

line to bounding box collision is easy and cheap

#98899 - iainprice - Fri Aug 18, 2006 10:20 am

How do you draw to Vram, not the screen?

#105202 - MelGibson - Fri Oct 06, 2006 6:25 pm

Any updates on this project ?