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*.

Just to clarify what you need help with "Then when close enough the NPC moves straight to the point (Instead of the end node's own position)." Is this a problem? "but I need to convert it to use D3DXVECTOR3 coordinates instead." Is this what you need help with? As a general comment on the tutorial, the tutorial author correctly states the issue with dynamic lists / STL and solution of fixed arrays, and also about not needing 3D A* if your 3D game can get away with only using 2D A*, smart.

good idea. how are you building the fault tree?

Not HL2 but when I developed xbox games there was a push from high for games with explorable large worlds and seamless ( no loading screens ), we streamed (loaded) assets (mostly textures & models) into ram in the background while the game ran, it causes slow down of frame rate, mostly unnoticeable but sometimes too much was changing - artists push (forgot) the limits ( set by wise programmers ). There are different ways to allocate the 64mb ram that i can think of Allocate on-the-fly. As long as your game never exceeds the ram available you're ok, oh and as long as the ram is not so fragmented you can't allocate memory. (XB Arcade games got away with it because they didn't change much once loaded) To improve on that, developers of AAA games allocated known amounts of ram divided into GFX, Audio, data etc and wrote memory managers to reduce/eliminate fragmentation problems. Most developers programmed code to identify when their game was executing in DebugKit 128mb or testing retail 64mb, so today you're stuck with the game running in 64mb even if the ram is upgraded to 128mb. The smart way for developers to use ram was ignore whether the game is running on debug or retail kit and just grab the total ram available, account for OS memory, and sub divide remaining ram, increase % GFX ram. (pretty obvious?) So if the game was coded smart it will make use of the upgraded 128MB, thereby reducing swapping assets in the background (reduce interrupts on resources e.g. CPU and affecting GPU frame rate). Another reason for low frame rates not improving with extra ram is just too much going on in the game scene with non-optimized shaders (GPU bottleneck) if the game was a quick port from the PC platform - which had better hardware and developers may not be skilled on limited hardware or given enough time if management and MS pushed the game out and overlooked frame rate issues. I had the experience of working with producers who never even looked at the game, just their schedule and tight budget, while the execs looked at the profit margin. Just looking up HL2 was released on PC 2004 and ported 2005 i'd expect it was some combination of the above as well as Valve focusing on newer consoles Xbox 360, released 2005. HL2 on OGX could have been a bit of a cash grab catching OGX at the tail end of life.

two bits of equal stickly back plastic tape on opposite sides under the DVD disk (for balance ) see what particles stick to the tape after spinning the drive up and down a few times alternatively some stick back tape inside the drive see if it collects dust/dirt

loose filaments/dirt/dust/objects in the DVD drive thrown up when it spins may explain scratches in different directions confirm by taking off the DVD drive cover, look inside, use a swab and Isopropyl swab a bit and see

Where did you find the 2/few? I assume xbsp, xrad and xvis are file extensions, xbsp is mesh? xvis is visability map? and xrad I couldn't guess I wont be able to take on another project for a while, it can take up a lot of unpaid time ( I literally only get 5 minutes some nights to write one line of code or one task, but get there eventually )

Correct. DXT5 programming is in, it is same image colour compression as DXT1 but DXT5 adds a compressed Alpha channel too. Life is busy at the moment but I will test soon (weekend)

this script indicates 4 different image formats are contained in the .XTF format (DXT1, DXT5, RGB Palette, RGBA True colour with 8bit Alpha channel) the test tool has proven concept using DXT1. others to be added....

proof of concept.

I got a little time on weekend, I tried getting my converted xtf test into game to check it. has anyone successfully added new files to .xzp? DM me thanks