historic_bruno
-
Posts
2.755 -
Joined
-
Last visited
-
Days Won
47
Posts posted by historic_bruno
-
-
Usually, your ISP will give you a router as well as your modem, sometimes they are combined. The instructions to forward a port differ from one model to the next. Most of the time it involves you opening a web browser, typing in an address like "192.168.0.1", then logging into your router, and changing the appropriate setting.
-
How about some way to see which players won and lost? It doesn't need to be text, AoK had some icons next to the player names (for winning players). Even though right now only one player can win, they can be on teams and have diplomacy. Also I've worked on a change to EndGameManager to allow team victories.
So for the summary screen, it would require looping through player entities and checking if their state is "won" or not, and if so do something special. Not a big priority though.
-
Who's hosting the game? That person needs their firewall to have the rule added (as Feneur mentioned), but also if there's a router you'll need to port forward there as well.
Some people like myself have firewall software and a router, so both need to allow this.
-
im using visual studios 2008, i get 13 errors
i get this error 12 times: fatal error C1083: Cannot open include file: 'boost/filesystem.hpp': No such file or directory and this error once
fatal error C1083: Cannot open include file: 'FCollada.h': No such file or directory
Make sure you've completely checked out the latest revision from SVN, and that you ran build/workspaces/update-workspaces.bat first, and then opened build/workspaces/vc2008/pyrogenesis.sln in VS.
-
Thanks for working on the Atlas editor historic_bruno!
Is it now possible to select more than one object?
Not sure, I'm not working on that
-
Some cool things there Bruno. How about when choosing the default terrain for the new map it's actually a panel of terrain previews, similar to the bottom of Atlas when painting terrain.
I can try that and see how it works, but that control seems buggy - if you switch pages enough or scroll around for a while it will lock up Atlas. Also the previews will need to be shrunk to fit in a decent size dialog box. On the other hand I can reuse the code that builds the preview bitmaps, so that's handy.
-
A couple of new things for Atlas. The new map generation has been integrated (roughly) into the UI. I'm trying to keep in mind various comments I've gotten on the layout of the random map controls. It's simple right now, a drop down to choose your map script (this may get replaced by a file chooser dialog or something), then a "Run" button to run the script, and then some seed value controls. Later there could be controls to override things like the base terrain and height of the script. Also it was suggested to allow arbitrary text as seed value, and then hash it somehow into a numeric seed - to make things more interesting.
So the "generate empty map" button is gone now, replaced by a new menu item "New...", which brings up a new map dialog as follows:
It has a very basic layout so far. Maybe the texture selector could be a list, allowing multiple texture selections, in case you wanted a map to start with several blended textures (randomly). The texture preview box isn't working yet, but eventually it will show the selected texture, so you're not picking blindly. It would be nice to have some shortcuts for handling maps like CTRL+N for new, CTRL+O for open, CTR+S for save. I've not looked into how that would be implemented.
-
New ticket for troubleshooting Spidermonkey JIT:
-
Tickets relevant to random map system:
#460: Random maps don't work since the new simulation system
The RMS Interface document details an interesting API for RMSs. Maybe worth looking into.
I think there should be a higher-level interface (compared to, for example, how the Cantabrian Highlands and Latium scripts work). It could use the concept of Biomes, to avoid needing to specify every texture or object that might appear in a given map.
Potentially useful functions:
createRiver() - create a river, perhaps from a starting point to an ending point, or following a certain function(s). I think the way water is implemented now, it is all at sea level. Thus the river would have to be level (i.e. not flowing down from a mountain). Maybe in the future, this is something that could change, to allow for waterfalls and more realistic environments.
createMountain() - create a mountain range, maybe following two functions, one for position and one for height.
createPathways() - Useful for guaranteeing there is a way to get from each player to the other. Could be an actual open path on a land map, or water connections on a water map.
createForest() - create biome-specific forest of roughly a given size
createLake() - create biome-specific small body of water, like it could be a swamp in some areas
createBase() - create a player base, which uses starting structures and units for the given civ (can be specified in /civs/*.json)
-
3. As far as how the UI layout and usability, this is a mockup I did some time ago for the editor. I planned to make mockups for all the sections and panels, but realized just how much work that would have been, when whoever works on the editor is just going to do it their way anyway. But this might give you some ideas.
Nice mockup! I especially like the "collapsible" option boxes, allowing a larger number of controls in the same amount of space. It reminds me of how some 3D modeling and image editing apps work. That would require a custom control though since it's not a standard part of wxWidgets.
One of the things that annoyed me about AoK's scenario editor was that it was a pain to change settings for all the players, because you had to select each one individually. There could be an "All" tab on the player panel that allowed changes for all players at once, e.g. if you wanted to give large stockpiles of resources.
Setting diplomacy is another tricky task, as clicking a lot of controls gets tiring, so it may be easiest to use the concept of teams. A game I used to play called Neverwinter Nights, though it was an RPG, had a concept called "factions" for the various NPCs in the game: basically how friendly or mean every group was to all the others. 100 might be a group you'd never attack, 0 you would always attack, and the interactions of the game altered the value. It might not map perfectly to a RTS game like 0 A.D. but it does add some granularity to the concept of diplomacy.
-
I've been playing around with the Atlas UI, adding controls for some of the settings we use when creating and editing maps. So I added a few to the "Map panel" and then there's a whole new "Player panel" now, which lets you pick settings per player.
I guess mostly I'm just trying to get something basic in place, so that we no longer need to edit the map XMLs by hand. But if anyone has suggestions on what could be improved to make the UI more usable, that would be an interesting discussion.
Map panel:
Players panel:
-
Ran the same test scripts in FF 4 beta 6 using typed arrays, and it's lightning fast... under 4 seconds start to finish, and I validated the output so it's working fine. That's faster than rmgen, although it doesn't have to write any data to disk at the end. Guess that helps put to bed the question of whether JS is fast enough to do random map generation... Now to harness that power in 0 A.D
-
Firebug disables the JIT, so its measurements are pretty meaningless (at least once the game's able to use the JIT properly). (The SpiderMonkey developers have some plans to make their debugger API compatible with JIT, but I don't think they've even started implementing that yet.)
Ah, I didn't notice that critical little detail. So running the optimized code takes more like 22 seconds in FF 3.6 with FireBug disabled (JIT enabled)
That does tell us that JIT is clearly not working for us in Spidermonkey... but it gives me hope that we can in fact write the whole map generator in JS 
About RangeOp: Hmm, looks like that's mostly used by TileClass::countInRadius. If the tile sets are usually very sparse, it could possibly be much more efficient if implemented as a quadtree; or it could test distance to clumps rather than to individual tiles, or maybe it could precompute some kind of influence map, or something. Probably lots of ways to optimise itI think this will be a necessary step, especially if we want to have some kind of integrated web-based editor. The more efficiently it can do this, the better, so it can scale to larger, more complex maps.
Other RMSs may use multidimensional noise maps to construct terrain, along with clump placement, I'll be curious to see how they perform.
-
It occurred to me that since all the scripts are in JavaScript, why not use a web browser to profile them?
Here's some profiling results using FireBug in FireFox 3.6.11 - so it's not identical to our Spidermonkey, but it's not far off performance-wise. I wanted to try Firefox 4.0, but FireBug won't install on it yet.
mapgen_profile_firefox3.6.11.pdf
The optimized version replaces some of the Math library functions with alternatives, instead of Math.floor() there's a hack which uses bitwise OR for typecasting a number to an integer. Judging by the fact that these optimizations cut the run time by about 40%, I'd say that's significant. It also looks like optimization is very poor because that's the sort of thing that should be in-lined (Imagine 25 million calls to a given library function, taking up almost 1/4 of the total time to generate the map!)
Note: Since Firefox 3.x doesn't support typed arrays, I had to write a wrapper function which basically creates an untyped Array, all values set to 0. This raises an interesting point. In JavaScript the for...in statement can be used to iterate an array, skipping undefined values. For sparse data, it may be more efficient to create an untyped Array than a typed array, if we only need to iterate over the assigned values. This would require some logic modification, but it's one aspect of the language that may be useful.
-
There's a binaries/system/rmgen.exe in SVN so you should be able to simply run that version, I think.
I get an "Application not configured properly" error when I try to run that one. Which may be some sort of VS redistributable library issue, but I've got all thee DLLs installed on my computer and copied into the binaries/systems directory.
I did finally get the one I built in VS2008 to work. Turns out it's a manifest problem, I guess it needs both VS 9.0 and 8.0 run time libraries to run the upgraded project, but the manifest only had 9.0 listed.
Performance is good, it takes 6 seconds to run the Cantabrian highlands script, which includes generating the binary data and XML. Compare that with about 2 minutes to run the JavaScript version... Now I'm curious as to why there's such a disparity
-
You could possibly see if JS execution speed is the issue by uncommenting JSOPTION_JIT in ScriptInterface.cpp (it was disabled since we haven't needed the speed yet, and there's less chance of hitting bugs when not using the JIT).
Didn't notice any difference with JIT enabled
For typed arrays, I guess we should do something like this (using the not-quite-public-but-not-really-private APIs from jstypedarray.h) in ScriptInterface::FromJSVal<std::vector<u32> > and similar overloads, to specialise them for the appropriate typed array type.I think that's worth looking in to, although for now the time it takes to return the data and for the engine to parse it is negligible compared to actually generating the map (using typed arrays or not, again seems to have little impact).
-
Jason forwarded me this link. I wrote the old rmgen (in source/tools/rmgen), so I'd be glad to answer any questions you have about it. I like the idea of integrating it with the main game engine. Right now there are some parts that are C++, but the system is intended to let you write scripts in JS. The parts that are in C++ are mostly that way for performance (e.g. Perlin noise is fairly computationally intensive). However, performance might be good enough with pure JS code, in which case it would certainly be nice to move everything to JS.
Hello, Matei
If you don't mind, I'll ask some questions, but anyone else is welcome to jump in if they have some ideas.Is rmgen fast enough to generate a map, like Cantabrian Highlands in a matter of seconds - reasonable for use in the engine? (I can't get it to run on my system, maybe due to building with VC++ 2008).
I'd like to know some details of "RangeOp" as it doesn't have any coments in the code, but I guess at least it has something to do with counting points within a certain distance of another point. The reason I ask about this is that I've used the "Cantabrian Highlands" script as a sort of baseline to see how JS can handle the random map generation. It's very slow, but especially parts that create areas, which rely most heavily on RangeOp (for tile class constraints).
As an example, to create 3 small lakes on a 2 player map w/ 208 tile size, the inner loop of RangeOp.get() is called over 1 million times! That's a big deal in a JS implementation, moreso because RangeOp uses integer division, which doesn't exist in JavaScript, so every step is floating point and then has to be rounded down. Does 1 million ops sound consistent with the original design, or maybe I implemented something incorrectly in JS?
Also, if I'm not mistaken, the tile class constraints are handled separately. So say we wanted to avoid player, hill, and water classes - to place a forest or something. That would mean 4 separate constraint checks (also avoiding forests) for every point in the area, and that for every forest we wanted to place. That gets complex in a hurry.
What do you think of the feasibility of maintaining the tile classes in one data structure, which gets checked once for a given subset of tile classes? I'm not an expert on spatial data structures, but the following seems logical:
1. Get a "map" with subset of tile classes necessary for our constraints (this gets maintained as new areas are added)
2. Find open areas (i.e. where all constraints pass) which are big enough to fit our new area. Maybe they can be sorted by size, making this part fast?
3. Choose an open area at random (maybe the smallest?) and create new area somewhere within it's bounds.
What I'm thinking is rather than these algorithms dealing with points, they should deal with "areas," which are arbitrary shapes, possibly approximated as rectangles or circles. We could adjust how "strict" to make the constraints, so maybe areas could overlap in some instances.
I'd very much appreciate any advice you can give
-
Where does the map format get involved? Do you actually generate XML/PMP files and then load them in? (It sounded more like everything was loaded from the JS data structures, not via an intermediate file format, in which case I'm not sure how the map format is part of it.)
Right, it's all passed to the engine as fairly simple JS data as described above. I thought this was more sensible than having to generate a PMP/XML first, because the MapReader already has all the logic for parsing maps anyway, so it's not too hard to get it to parse JS data too (I wrote a few FromJSVal overloads to handle things like an Entity struct and u16 vectors).
The nice thing is the game setup hardly needed to be modified at all, because functions like "LoadMapSettings" don't really care where their data comes from as long as it's in the correct form. Instead of parsing JSON from an XML, it can use an entry from the game attributes.
Progressive loading sounds like unpleasant complexity here - RMSs will often be written or modified by inexperienced users, so I'd probably be happier to keep the script control flow as simple as possible. If it takes a non-negligible amount of time, we could perhaps run it in a separate thread to avoid freezing the progress bar.That was my concern, the loading screen does lock up, but in my test so far it goes very slow (see below).
(Incidentally, if you're not doing this already, the RMS should probably be run it its own unique ScriptInterface (not the simulation's one), so it has independent RNG state etc and so there's no danger of unexpectedly influencing the simulation state. Then we could move it to a new thread without any chance of upsetting SpiderMonkey.)The MapGenerator class does use its own ScriptInterface, and it's the only part that evals the scripts
Yeah, SpiderMonkey nowadays is hugely faster than when we started, so I'd expect performance to be fine. If not, we could publish our slow code as a JS benchmark and let the SpiderMonkey developers optimise their engine for usWell so far, using the "Cantabrian Highlands" RMS as a baseline, it's really slow. Until we're certain of why, though, I wouldn't necessarily blame it on SpiderMonkey. Being able to do profiling would help.
Also, it turns out typed arrays do work. I was trying to make a 2D typed array which is silly - the "outer" array has to be a standard Array always, the "inner" array is not a primitive type
On the other hand, they don't test as valid arrays using the jsapi macros, so it doesn't work if I try to convert them to a vector 
As a temporary work-around I copy the typed arrays to standard Arrays before passing them back to the engine. -
I've had a go at getting the random map system into a more usable state, including porting it over to Javascript. Any ideas on the shortcomings, bugs, etc, of the old rmgen can go here, as I've not had much experience with it. I'm sure the basic algorithms need work though.
Right now I've modified the MapReader with some new methods for "Loading" a random map, which is basically like loading a scenario, except there's some extra data associated with it from game setup (map size, random seed, base terrain, etc) and of course a random map script (RMS).
For now a new MapGenerator class is used to handle the details of loading JS libraries for all the necessary classes in their own context, executing the random map script, which then returns some data. This is not progressively loaded yet, so it may be that the RMS will need to be split into multiple functions, registered with the engine and then called piece by piece.
The returned data is a list of entities, a list of textures, a heightmap, a list of tiles, an environment object, and a camera object (since it's not unforeseeable that an RMS may alter the environment and camera). The MapReader parses this data from JS into the respective C++ structures and inits everything just like it would for a scenario. The map format is the current version, not the older one used by rmgen. This much works perfectly.
So the part that needs the most work IMO is an analysis of the algorithmic complexity of the generator, and some decisions on how high or low-level to make the RMS interface.
Re: SpiderMonkey's typed arrays, I don't think the implementation is complete in our version because all I get is "undefined" when I access a typed array. Maybe the constructor API has changed or something.
-
Good job, can't wait to see something other than a large blank window when I leave the game
Re: getting the colors to match with the game setup: once the setup patch is committed, then the player colors will be set from a single defaults file or as specified by a scenario. So, for the summary screen, you could probably just read the colors from the player entities and they will be identical. (This also leaves open interesting possibilities, like cooperative players having the same color, teams with matching colors, etc.)
-
OK, I added player color boxes (with a new sprite type for solid colors). Also chatting shows the user's name in their player color, but if they're not assigned yet, it will be black. I'm thinking maybe the host should have a different font or something to stand out if there's a lot of chat, but right now players don't actually know who the host is (since even the host is a client treated like all the others).
-
another thing i would like is the camera to go along with the terrain, if we we're on a hill then the camera keeps its current height and at times passes through the hill. what it should ideally do is keep a fixed distance between itself and the ground.
I agree, as long as it moves smoothly when transitioning height.
-
Here's a crazy idea, create a border around the player box with the player's color. That way it combines multiple related concepts into one control.
-
Shouldn't non-hosting players be able to choose their own player assignment (slot #, civ, team # if applicable)? Right now the host has to set everything. Of course if it's a scenario with predefined civ and teams, then those dropdowns would be disabled.
At the risk of UI clutter, there could be an option like "lock settings" for the host, so only then can choose player assignments.
A "Computer" player assignment should be added for when AI will take the spot.
Edit: And while I'm on the subject of dropdowns being disabled, maybe the disabled state could be text with no dropdown visible. Would look less cluttered.
Build warnings in VS2008
in Game Development & Technical Discussion
Posted
Some warnings from a clean build in VS2008. They may be nothing to worry about but I'm going to post them here anyway because they: 1. annoy me, 2. may be useful in the future if bugs are found, or 3. may remind us of things that need to be done.
The last two can probably be fixed with a default case, which I think is a pretty good practice in general. Also I've fixed some warnings in other files that I haven't committed yet.