In celebration of the end of exams... (armagetron3d)

[Z-Man]

Yeah, winlibs hasn't been updated yet, and even if it was, the Windows project files would be missing components. It will be in fixed in the next couple of days. Same for mac, probably (the project files should be up to date, but I don't know about the libraries).

Bottom line: don't expect experimental branches to work on anything but Unix.

[Infa(mous)]

Ah. That would explain it.

[Al's Used Cars]

yeah... i tried opening the pbxproj file with xcode already, after installing MacOSXlib framework... got nothing. Nothing happens. So, thought maybe Im too noob to do this correctly, but after a lot of variant attempts, still nada.

can i compile directly?

[madmax]

yeah... i tried opening the pbxproj file with xcode already, after installing MacOSXlib framework... got nothing. Nothing happens. So, thought maybe Im too noob to do this correctly, but after a lot of variant attempts, still nada.

can i compile directly?

Hmm, not sure what you mean by "nothing happens". Try this: http://forums.armagetronad.net/viewtopi ... 462#197462
A minor detail, if you run intro problems about bison not being the correct version, you have to go to Project > Edit Project Settings and add one named BISON with its value being the path to the correct (newer) binary, for example /opt/local/bin/bison.

[Al's Used Cars]

Literally, nothing happens with Xcode. If I choose open file, nothing happens. If I choose "import project", nothing happens. If I choose new project, and then add files... um, have no idea what to do with that.

No error msg, just zilch. I don't see a crashlog in Lib for Xcode. (Btw, I'm on ppc, not intel, running 10.4.11.)
'

I've installed gcc, Macports, bison, rb-rake... can I do this a different way?

[madmax]

Literally, nothing happens with Xcode. If I choose open file, nothing happens. If I choose "import project", nothing happens. If I choose new project, and then add files... um, have no idea what to do with that.

Hmm, perhaps you have an older Xcode? Get Xcode 2.5
Anyway, I have no idea if you need to add extra files to the Xcode project, since it probably wasn't updated for this particular branch, and I haven't tried building it myself.

[dlh]

The Mac OS X project for this branch works—I merged it with protobuf so it is up-to-date. The osxlibs package was updated with the libraries needed to build.

Al, it would be better for you to start off building the main trunk source, and not a hack-branch. Maybe start a new support thread if you have issues, but make sure you read the relevant docs first, such as on the wiki and the readme files included with the source code.

[Z-Man]

(takes some time to come up with actual reasons )

That's just my instinct on how I'd implement it, I'm ready to go with whatever you come up with, those things usually turn out to be quite well thought out

Well, yeah, the 'teleport and let the rest of the systems work around that' sounds simple, but I don't think it is. With it, all systems need to be painfully aware of the teleport lines. How would you implement smooth camera movement? How would you make it so that zones can span over teleport lines? How do you get cylce wall rendering right? How do you mix sounds? All those problems are a lot easier if you have just one coordinate system.

Of course, we still should have teleport lines But they should be that: teleports. Not seams holding our world together.

[wrtlprnft]

Hmm, camera movement and sound should just be done after the transformation (they really need 3D coordinates). I haven't thought about zones spanning multiple grids, it just seemed to be too chaotic for me.

For wall rendering you'd first have to figure out what a vertcially bent wall should look like. Maybe there should be a distinction between close-proximity teleports and “real” ones, the former being rendered by some sort of algorithm that makes a straight path between two separated wall segments (in the simplest case just a single quad which would look acceptable in many circumstances).

The problems I see with a full 3D engine:

• What about floating-point precision? With 3D coordinates the base lines of a pair of walls will almost always be skew lines, you'd have to have tolerances, possibly taking into account the height of the walls and their “up” direction
• With three floats for most coordinates you'll use about 1.5 times the CPU power of a non-3d engine (probably more considering that some 3D operations tend to be quite a lot more complex than 2D ops)
• two floats + dynamically sized grid ID < three floats on the network
• the teleport approach makes it quite straigtforward to create a map format: just define grids in their own <Grid> tags and specify the transformation matrix that is to be applied and the teleport lines. Probably a PITA if you want to build larger maps by hand, but nothing prevents us to add shortcuts later that get transformed into the internal format.
  I wouldn't know how to make a real 3D map format without it being very complex or restricting the possible maps (what about grids with holes in them and all that)

[Z-Man]

Hmm, camera movement and sound should just be done after the transformation (they really need 3D coordinates).

Certainly possible, but there is no good way to convert a flat map with teleports to 3d globally, considering there are ways to create impossible shapes like the simple torus where you take a square and connect opposing sides.

For wall rendering you'd first have to figure out what a vertcially bent wall should look like. Maybe there should be a distinction between close-proximity teleports and “real” ones, the former being rendered by some sort of algorithm that makes a straight path between two separated wall segments (in the simplest case just a single quad which would look acceptable in many circumstances).

True, and of course you have the same problems in a 3d approach. Bad example by me

The problems I see with a full 3D engine:

• What about floating-point precision?

Same as now. This is not a new problem.

[*]With three floats for most coordinates you'll use about 1.5 times the CPU power of a non-3d engine (probably more considering that some 3D operations tend to be quite a lot more complex than 2D ops)[*]two floats + dynamically sized grid ID < three floats on the network

Yes. Raw performance is definitely better with 2d IF we're dealing with only a few relatively large flat stretches connected with each other. But on the other hand, you'll have added cost for each teleport, and that will add up for more complicated maps.

[*]the teleport approach makes it quite straigtforward to create a map format: just define grids in their own <Grid> tags and specify the transformation matrix that is to be applied and the teleport lines. Probably a PITA if you want to build larger maps by hand, but nothing prevents us to add shortcuts later that get transformed into the internal format.

I don't think full 3D maps will be complicated. For a full 3d map (shortcuts are probably possible), you need
* vertices in 3d
* faces linking vertices (edges can then be added automatically from that)
For a 2d map, you need the same, but you need each vertex several times for each face it appears in,and you need to define which faces are linked over which edges.