Josh
-
Posts
23,145 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Blog Comments posted by Josh
-
-
Navmeshes can have multiple levels and overhangs, so you only need one for a small or medium sized scene. It's not a per-model thing, it can handle all geometry, and the engine will take care of that automatically.
Dynamically recalculating sections can be done by running it on a separate thread and getting the results a few frames later. Again, the engine just does it automatically for you. I don't know if mobile devices will have enough power for this, but when was the last time you worried about waypoint AI not being dynamic?
For very large scenes, I think you will need to create multiple navmeshes in the editor, because otherwise the navmesh data might exceed system memory. If you have ten miles of terrain and three towns, you would probably create navmeshes for each town, and then link them together with conventional waypoints that just follow the roads between them.
-
1
-
-
Also, it seems like this is already covered but is the device smart enough to know if a finger left the screen? In other words, say you're zooming with two fingers and you put a third on the screen and you remove the second. What happens? I guess this depends on the user's code. You'd have to make sure the third finger stays the third, even when the second leaves. You'd have to reset the zoom distance to start from between the first and third finger, I guess.
You'd get a TOUCH_UP event with index 1 (it starts with 0) and know the second finger left. The next finger down would become the second, because that would be the first empty slot.
-
I had a little fun with iMovie with this one. Don't be a hater.
-
It's probably possible to set up CodeBlocks to work with Android, but we always do things the official/most common way that Google recommends.
Yes, the PC market is so bad that cell phones often have better graphics performance. At least with an iPhone you've got a minimum graphical capability that is decent. I'm afraid the Android market has a lot of low-quality garbage, just like the PC market. Manufacturers want to cut costs, and so they put a cheap graphics chip in the phone, and think no one will notice. Meanwhile, Apple puts a good GPU in every phone, regardless of whether the user will actually need it.
It's just like the low-end PC market. "Why would you want a GPU? Not everyone plays games. A work computer doesn't need one."
My HTC Evo, for example, gets 30 FPS max (it's a known hardware design issue) and it gets 7-16 FPS drawing a single 15,000 poly model. Meanwhile, my iPhone and iPad render the same thing with no performance cost, running at the max framerate of 60 FPS. The Evo was marketed as "the iPhone killer" (for a month, anyways) and I had no way at the time to know how its graphics performance would be. If you buy an iPhone, you don't have to worry about making the right choice; everything will be reasonably good, even if there's an Android phone out there that is better in one area or another.
This is why I think HP had the right idea when they acquired WebOS, but I guess all those plans went out the window with Mark Hurd's departure.
I don't know what it is about PC and cell phone hardware, but it seems like pure competition destroys customer choice and quality. Maybe it's just the inability of the market to know what they're really buying. It doesn't help when hardware manufacturers obsfucate the performance of their products, like how CPU makers no longer advertise their clock speeds and GPU makers don't specify the number of stream processors their cards have. Now Intel just rebrands the same stuff over and over (yes, I know the architecture changes, but is that really that big a deal?), and they act surprised when no one is motivated to buy their processors. Even nerds have a hard time getting excited over a Clarksdale, Sandy Bridge, etc. Clock speeds aren't perfect, but at least it's an arbitrary indicator of performance.
-
For Android, you also have to create makefiles.
But once everything is set up, it's simple to compile. The emulator doesn't support OpenGLES2, so you will want to run the app directly on your device. You can do this from Eclipse.
I recommend developing your game on Windows, and then just build it on Android. Don't try debugging C++ code with Eclipse.
-
In fact it seems to turn in something like Unity3 and it's scripting system
I hope not.
caus the build can be made with CyGWin for example !Android compiling of C++ is pretty difficult. You have to install the Java SDK, Eclipse, the Android plugin for Eclipse, Android SDK, the NDK, and CygWin. Lua is a much simpler path since you don't have to install any third party compilers or SDKs.
-
It's not a problem. You can even program Lua on the iPad.
-
The NDK C++ tools are pretty awful. No debugger, so I don't recommend developing your app on Android. Just develop it on Windows, Mac, or even iOS, and compile for Android for distribution.
It's obvious to me that whoever supports pure C++ the best will be a winner. I have a lot of C++ criticisms, but the way I see it, Java and Objective-C are just as poorly designed, and have the additional disadvantage of not being widely supported. You also get the benefit of weeding out the more amateurish programmers. We all end up using C++ anyways to bypass these "wrapper" languages. So if Android eventually moves to pure C++, preferably with integration in MS Visual Studio, that will be a good move for them.
If Nintendo wanted to make a big comeback, they would make a C++ SDK for free or cheap and have an online store like the App Store. I mean, for years all the console devs did the exact same thing with a highly restricted SDK, and the first thing that comes along and does the opposite blows them out of the water (iPhone).
-
It would be hard to set up a game without having the new API to code with, but I think you will be able to port Lua games with Leadwerks Engine very quickly to the first beta of Leadwerks3D.
-
I got word back from our Android programmer about the likely cause. It's great to have someone around who is a counterbalance to my strengths and weaknesses as a programmer.
-
i also hope that system will be fully available in fashion as current LE is
Yes, don't let my positioning of it as a "visual game design tool" scare you. You've still got an API-oriented engine under the design layer. I'm just adding a layer of control designed for people who don't want to program. Who knows, you might even find it useful for some tasks.
i hope that under 'programmers' expression, you primarly thinking on people whos using raw C++, C# and Bmax, rather than scripting languageI think C++ is the best language to document things in, because it is a standard everyone can follow along. I can't really write syntax descriptions in Lua since all variables have no type. It's easier to convert a C++ examples into C# or Blitz or Lua than it is to go from another language to C++.
-
That makes sense to me. It's kind of silly to have a full page of code just to demonstrate Entity::SetMaterial or something like that. If you look at the Vec3 operators, I made small examples that aren't entire self-contained programs. Sometimes I need to stop being so pedantic about everything.
-
Instead of chm files, why not just plain html files that open in any browser on any platform? You don't need to have them on HTTP servers if the contents don't change.It counted as a "manual" as far as Quake 3 was concerned, and that was the first time I really saw it done.
Wikis are much easier to edit. The table of contents is handled automatically, and internal links can be added just by surrounding a work with [[brackets]]. It probably would take three times longer to edit all that HTML, and every change would be painful. Plus, people want to be able to search them and not everyone will think to use Windows search (I think they messed it up in recent versions, too...one more reason I prefer XP.
).Is there any way that members only could add to a wiki?I would have to create all accounts manually. Apparently there was at one time a bridge for IPB and MediaWiki, but I am not sure if it works. Then there is the issue that I have to be able to answer all questions about these docs, and if it's something a user added, I might not be up to date on that knowledge.
-
I know enough about how it will work, it's just a matter of hard work.
-
Right, a lot of people can do that, but the problem is we then branch the code, and each programmer becomes an island. This causes the rate of collaboration to be pretty low.
With a built-in navigation system, we can share AI scripts and they will all work together. We can even write different AI scripts and make them battle.
In the past, I figured that my job is to provide the graphics and physics foundation on which gameplay is built, and then let the user take over. I don't think that approach has worked out very well, except for a few people who already know how to write games.
-
I'm focusing on the gameplay features first and foremost. Pathfinding and flowgraphs are more important than having another post-processing effect.
-
Okay, I have a large amount of navmesh generation code compiling. It's nowhere near working, but I have learned some things.
The most important thing to understand is that recast is NOT a library; It's an open-source program. The code doing the heavy lifting is very impressive, but this thing was not designed as a general library with commands to be called from an external program. You've got to extract the parts of the program you want, and try to comment out all the calls to things you don't want, like OpenGL rendering, the GUI, etc.
-
I found some recast code that actually makes some sense. Fingers crossed...
-
P.S. I *think* recast works by voxelizing the poly mesh then generating a navmesh that fits that. But that's just the impression I got from reading something somewhere and may be totally incorrect.
Yeah, but 2D voxels are just a fancy way of saying a grid.
-
Yes, but those are all node or grid based, are they not?
-
That's not a bad idea.
Yes, you can link from one actor on one entity to another actor on another entity.
-
Instead of having to import the flowgraphs for each map, can't you just have one or more logic maps loaded first, and then the real maps on top of them?
Can you rephrase that?
I think we'll be able to save flowgraphs as part of a prefab, so you can set logic up once for a set of entities and then save it as one prefab of interconnected objects.
-
Mike, the entities are referenced by a unique ID, so the name does not matter. What scares me is what happens when the user resaves a script and the outputs and inputs change.
It's very hard to write an editor that dynamically reloads everything.The whole purpose is to have a standard way of making things interact, so that all our scripted objects can talk to one another.
-
I believe you can do stuff like this so all actors can access a per-entity value:
function actor:Update() self.entity.myvalue="Hello" end
Normally you would want to keep them in their own separate spaces, within the actor table.
Programming the editor to handle the multi-script attachments and properties, when scripts or objects may be reloaded at any time, is really incredibly gnarly, which is why I have never done anything like this before.
).
Artificial Stupidity
in Development Blog
A blog by Josh in General
Posted
Yep, that's what it looked like when I went back and watched it. Some polys in segmented tiles seem to be invalid.