corona2222

now you got the resources rip. task complete, well done .mdl models are likely a custom format just for this iphone game.

I know that hence my previous post I believe in you doing this task trust me its easy and I want you to learn. Just a side question, how are you intending to port the game? you mention from scratch, are you coding a game from scratch? have a game engine? using someone elses game engine? (optional to say which) So you've never done this before... that's ok, what would be your first step acquiring the resources? The first thing I do is grab the .ipa app file of the game and get it on my PC (iphone apps are a file with extension .ipa, it is a basically an archive file format similar to zip *hint*) Post back when you have done this.

I'm not sure why you need someone else to do it for you, tell me how far you got and problem you get stuck at and I'll guide you as needed.

nice work! What tutorial did you follow? (or are you writing a tut as you go we can follow?) So far I've got the extra 64MB of chips ( which match the chip numbers on my xbox) Is it just a case of solder each ram individually, load xblast on my OpenXenium and test? Any other settings or hardware changes?

Cool. What did you use for the GUI harness / front end?

if the result looks great then its worth paying for and not worrying, plus saves a ton of time trying to do it yourself.

how much was it?

I'm unsure how it works and no diagrams. Can you clarify for me does it plug into the Xbox console, emulates a duke/S, and pair it with a wireless controller from Xbox 360 / Playstation? Or is it an inline adapter that plugs between the cable from console to controller?

fixed_grid_test_data1.txt my test data, in case it helps. (100x100 nodes) Let me know if you upload your test code to Gitlab (or similar) might be easier than posting code in this thread. happy to diagnose a little bit (when I have time).

I've run the code and tried to keep the code to the same as yours as much as possible. For data I used a fixed node grid (upper range 100 x 100, e.g from 0.0,0.0,0.0 to 99.0, 99.0, 0.0) I notice this line is an issue: currentNode->neighbours[i].hCost = Distance(currentNode->position, endNode->position); It causes all neighbours to have the same fCost (on a fixed grid), and no 'best' next step forward on the path. In the tutorial: "H - cost of movement from the current square to the goal...usually an estimate" This is likely where the misinterpretation was. The tutorial means "current square" as in the neighbouring square being currently calculated, not the currentNode. Anyway with the above issue the code results in the final path looking like this: (Note: the last two columns are not processed by A* because it finds the end node and stops searching) Visual 1: incorrect path costing colour key: light blue = final path (finalPath.corners nodes) grey = nodes that didn't get examined (never went on the open list or closed list) green = start node (x = 1.0, y = 1.0, z = 0.0) Red = end node (x = 98.0, y = 98.0, z = 0.0) So I changed the neighbouring hCost calc to use the neighbouring square position instead, as follows: currentNode->neighbours[i].hCost = Distance(currentNode->neighbours[i].position, endNode->position); Visual 2: corrected path costing That looks better. basically: gCost is the cost for the entity to travel from its current position to the neighbouring node position. hCost is then the cost for the entity to travel from the neighbouring node to the end. when those two are combined you get fCost which is the result of the entity walking from its current position through the neighbouring node and to the end. If we think about what was happening in your code (before that hCost line alteration), the entity walks to the neighbouring node then as if at no cost teleports back to the previous node and walks the rest of the journey from the original node. As all neighbouring nodes cost the same then the code selects the first node as default preference, the first node is whatever node exists first in the neighbour list, this results in all nodes examined until the end node is found (see Visual 1) It really helps to visualize this stuff

I'll try find time over the next month

maybe, (when i find a moment) wheres the latest code?

something that helped me understand what was happening to debug and optimize my pathfinding (not A* in my games case) was to render the path points being explored / found in different colours so I could visually see the path, and changed my 'GetPath()' code to be re-entrant so the path is built over a period of time so that I could see the path gradually getting built and the choices it was making and where the (complicated set of rules )code was going wrong. this may help.

from a quick glance looks good. see how it tests

I would need to know more about the type of game you're making but a lot of 3D games get away with 2D A*.