historic_bruno
-
Posts
2.755 -
Joined
-
Last visited
-
Days Won
47
Posts posted by historic_bruno
-
-
I think the advantage of My Documents is that it's a.) accessible for Windows users who are used to thinking in these terms (many don't so much know or care what a folder even is), and b.) it's portable, so it should be possible to copy it all over to a USB flash drive and onto another computer or back again, and not be broken, even if 0 A.D. needs (re-)installing. App data by comparison is very obscure, even if we could spoon-feed instructions on how to access it, why should we have to?
I don't agree that that's agreeing
. "My Documents is where users store their files" is not saying it's where applications store files that users want to see. I think My Documents is appropriate when the user has taken an explicit action to create a file (and so they won't be surprised when a file appears in My Documents), and that doesn't include log files since the user has never chosen to save a log file.To use the example of another free open source multiplatform game, OpenTTD, they install the game in Program Files (minding whether it's the 32- or 64-bit build), and then My Documents\OpenTTD is used for all content downloaded in the game, crash dumps, logs, saved games, scenarios/maps, and config files - anything created while the user plays the game. Not that we have to copy what others do, but it's a least some precedent.
People might want to share them with other people online, or back them up, I guess. Probably not very often, but they seem to match the desired semantics of being files that the user actively chose to store. (I forgot about recorded games; those should go in My Documents too.)
This is a very good point, and I back up My Documents every week
I'm assuming a hypothetical future in which we have a working config system and users will never edit them by hand. Don't have much of an opinion on what we should do before then, since that's only temporarySo shouldn't we make it easy to back up config too? Nothing worse than having to change all your settings after losing everything...
-
Thanks for the report
One is that the variation selector for an object seems broken at the moment. It does nothing.I don't know what the story behind this is, maybe it's left there as a reminder that it needs fixing
The colour selector really should show the colour that is currently selected for a player by painting the colour on the button.Are you referring to Alpha 6 by chance? This problem should be fixed in SVN (r10064 was the relevant change).
-
I am happy to change our "appdata" directory to any standard Windows location.
Please see the documentation for SHGetFolderPath:
http://msdn.microsoft.com/en-us/library/bb762181(v=vs.85).aspx
We are currently asking for CSIDL_APPDATA - see wutil.cpp:294.
Which one would be preferable?
(Although this function is "deprecated", note that the
newer known-folder functionality is only available
starting with Vista, which is unacceptable for us.)
How about CSIDL_PERSONAL aka My Documents? I think that's the best location for games to store data because it's easily accessible from several locations (start menu, any explorer window, etc.)
-
is this in git so that I could test it by any chance?
I don't know anything about git, but no - it needs one patch to be fixed first
-
And now the much improved Atlas on OS X...
-
Ok... That's nice and all... Prob is that for many win7 users that C:\Users\...\AppData\... dir is hidden and unreachable in the normal user mode... The right place to put ANY program is in the Program Files dir, and user files such as config's can be auto writen by the prog in the /appdata/. User data as mod's etc. should be written to the user's /My docs/ dir. As far as I know, that is how Win7 want's it.
I agree, the user data should be more accessible than it currently is
-
Is it possible to get XCode to switch the active target when changing build configuration? Like when I switch between Release and Debug, it doesn't seem to switch "pyrogenesis" and "pyrogenesis_dbg" (this doesn't seem to affect the build target, only the run and debug). I don't know if it's a premake4 problem or an XCode problem.
-
Just an FYI, I committed the latest patch to our new build system (r10154). So "--without-pch" should no longer be necessary for building with Xcode, please test if you can
-
Your link mentions the fix
(Alpha 6 didn't support building against Boost 1.47). So you'll want to either: downgrade your boost lib to 1.46, or probably better, try compiling from the latest SVN source. -
What version of the game are you using?
-
The game view is more broken, it's all pixelated as theShadow pointed out (wrong resolution?) and the coordinate system is different than we expect so mouse events behave differently.
The GL canvas isn't being updated properly when the size changes, it stays stuck at the initial resolution (which happens to be 320x240 - thus the ugliness). I've got a fix for this but it causes the game view to flicker when the window is resized or moved
-
The UI alignment is all broken, but I think that's because it's forcing a minimum size for wxButtons, maybe that can be set to (1,1) and expanded evenly. The toolbar is missing entirely, or maybe hidden under the title bar?
The game view is more broken, it's all pixelated as theShadow pointed out (wrong resolution?) and the coordinate system is different than we expect so mouse events behave differently.
-
but i thought the system folder was inside the binaries folder.
anyway, its working ok for me
To put it another way, the location where you run the binary becomes the working directory and the game only supports binaries/system (because all the game data paths are relative to that, not just the libraries)
-
Yeah, people get that on both Windows and Linux. If I understand correctly, it's not a serious error but gives us some additional debugging info for Jan to work with, and so it could be disabled if we can't solve the underlying issue by Alpha 7. Jan would know more about it though
-
Atlas on OS X, it's not pretty but it works.. somewhat
-
oh, and when i run the binary in the system folder, it does this:
./system/pyrogenesis
dyld: Library not loaded: libnvcore.dylib
Referenced from: /Users/skela/Desktop/0ad/git/0ad/binaries/./system/pyrogenesis
Reason: image not foundIt looks like you're running the binary from the binaries directory instead of system, where it expects to find all the libraries.
-
I can compile now, but I can't link because a 64bit version of wxwidgets is missing.
It looks like we'll have to add support for wxwidgets 2.9 for getting 64bit support. Simply setting arch=x86 in premake4.lua as a workaround doesn't work either because a lot of dependencies do their own architecture detection.
I think getting Atlas to compile on OS X with wxWidgets 2.8 is a lost cause, it appears the Mac Ports devs have also given up on this and are suggesting people migrate to 2.9 instead. There are other issues than this, namely the Carbon implementation (which doesn't support all 64-bit APIs) has different constructors for wxGLCanvas, so I thought maybe we could add macros for that, but this would only help older 32-bit Intel Macs building with wxWidgets 2.8, I think they could just as easily upgrade to 2.9 instead - in the very unlikely event that anyone tries. I uninstalled the wxWidgets stable (2.8.12) port and installed wxWidgets-devel (2.9.1) and it seems to build fine for me in OS X 10.6, with a few changes (r10095). Philip also made some earlier updates to get us 2.9-compatible, so I think we can focus on that.
-
My guess is that it was http://trac.wildfiregames.com/ticket/898, which has been fixed for Alpha 7.
-
It'd probably be useful to publish some analyses of this data and update them over time (maybe run it over each 3-month period), like the Steam or Unity ones. I don't know if I'll have time to do this soon, but just in case: what kind of reports (tables or graphs based on the hardware/profiling data) would be interesting or useful? (If they're mostly variations on a few themes then it should be easy and quick to do lots of them, so hopefully this shouldn't take much effort.)
Pie or bar charts, they can either be for all samples or averaged over fixed periods:
- OS (Windows/Linux/OS X)
- Windows version (2000, XP, ME, Vista, 7, ?)
- Linux distro, and maybe kernel if it matters?
- OS X release (10.5, 10.6, 10.7, etc.)
[*]Graphics card maker (ATI/AMD/nVidia/Intel: possibly subchart for each?)
[*]CPU vendor (AMD/Intel: possibly subchart for each vendor to show important distinctions, not just clockrate?)
[*]System architecture (32/64 bit and/or 32-bit userspace on 64-bit)
[*]RAM (under 512MB, 512-1GB, 1-2GB, 2-4GB, 4+ GB)
[*]Supported OpenGL version
- Windows version (2000, XP, ME, Vista, 7, ?)
Graphs:
- Release adoption (does anyone still play A3?)
- Avg. framerate by release
- Avg. framerate by graphics card (and maybe other criteria, like OS)
- Some moving averages (maybe 1 month window) of above data to show adoption of new technologies
- OS (Windows/Linux/OS X)
-
So How come 0 A.D. doesn't work and these would?
I just need some explanations.
Ask yourself: are those games tailored for Linux or Windows?
Also commercial games will obviously have many resources at their disposal, so they can optimize and tweak every little thing to gain another 1fps increase. Since we're open source, anybody with the knowledge and time required could join and help us optimize the game, but it's not feasible for us to focus on only Windows or Intel (by comparison we plan to support Windows XP+, Linux, OS X on Intel or AMD with Nvidia/ATI/AMD/Intel graphics, oh and 32 or 64-bit builds).
-
Unfortunately the Intel integrated graphics are just too weak to run the game properly.
Even the newest Intel HD 2000/3000 graphics are the equivalent of a low end discrete GPU, from what I've heard. Here's a snapshot of performance (it's a few months old).
For mouse lag, try setting the environment variable SDL_VIDEO_X11_DGAMOUSE=0 when running the game. (Next alpha release should do that automatically.)
Ah, I thought it was in A6 for some reason. Hopefully that will help to try
-
Mythos: You're mad as hell and not going to take it anymore?
Also there's a ticket: http://trac.wildfiregames.com/ticket/886
-
still haven't managed to get it running or building from Xcode :/ sorry
for example if i try to build and run pyrogenesis.xcodeproj,
it gives me 8 errors (about pch for network, simulation2, scriptinterface, engine,graphics,atlas,gui and lowlevel), the errors all complain about similar things:
i686-apple-darwin10-gcc-4.2.1: /Users/skela/Desktop/0ad/git/0ad/build/workspaces/xcode3/../../source/pch/network/precompiled.h: No such file or directory
i686-apple-darwin10-gcc-4.2.1: warning: '-x c++-header' after last input file has no effect
i686-apple-darwin10-gcc-4.2.1: no input files
Command /Developer-old/usr/bin/gcc-4.2 failed with exit code 1Oh right, I misinterpreted your comments
Think the PCH support is still broken for Xcode, we haven't applied the patch for it yet. Try adding the --without-pch flag when running update-workspaces-new. -
What's the call stack like when it crashes?
Atlas GUI minor bugs
in Bug reports
Posted
Interesting, I can boot into Ubuntu 11.04 x64, I thought that button worked a few days ago. What's the result of running "wx-config --version-full" from the terminal?