janwas
-
Posts
2.733 -
Joined
-
Last visited
Posts posted by janwas
-
-
> Bit expensive huh.
Yeah, that's out of the question :/
You say it's for Windows XP, well i'm on Vista, do the same chipset problems occur. If not couldn't the 0ad code be altered to detect the OS and thus not bother loading the driver on versions of windows over XP.Vista+ already have such a driver built into the OS, so there's hopefully no need for ours (barring any further screwups and bugs). I suppose it would be possible to disable the corresponding code on Vista - would you be interested in doing so?
You can also launch with -wNoMahaf on the command line for the same effect.
Of course, this error will only affect 64bit users I think.hm, why would the driver signing only be an issue on amd64?
-
I become now this compile error:
Thanks for reporting it, that problem has been mentioned (and hopefully fixed) in post #18. I still need to test the proposed workaround on Win32 though, after which we can commit.
I never used nor nasm neither yasm, all my projects are pure C/C++ ones, so I don't know about the quality of these assemblers. For now I just downgraded nasm to 2.05.01 and it works. And reported a bug upstream to nasm devs (no answer yet).Thumbs-up
for posting a bug report 
OK, I have no experience with YASM, and would propose sticking with (possibly older versions of) NASM until this issue is fixed unless someone comes up with a good reason to switch to YASM.
But how to solve remained unresolved dependencied when linking ActorEditor - I don't know. It could be a bug in gcc 4.4.0 or in binutils (something about C++ name mangling) but no solution yet. I'll try to build on a stable distribution with gcc 4.3.2 (currently I'm using development branch).Unfortunately I can't help here, am a Windows developer and have little experience with wxW and the GCC toolchain. Hopefully Philip will have an idea soon
-
Sorry, but that message gives more hope than it should. While people are welcome to try it out, the game just won't run adequately on gfx cards without S3TC compression, multitexturing and certain other extensions. I'd say at least GF3-class graphics cards are needed.
What version of OpenGL and other drivers do you have? I am just taking a stab in the dark.Good question in general (and the game will tell you via binaries\logs\system_info.txt), but in this case even newer drivers won't help because this chipset isn't really up to the task.
-
I too am using VC2005 Pro at home. The first raft of errors is due to dbghelp definitions not being found, but the cause is unclear. PSYMBOL_INFOW requires dbghelp 5.1. Unfortunately you apparently can't tell the installed version from the header. If it helps, my Microsoft Visual Studio 8\VC\PlatformSDK\Lib\DbgHelp.Lib is dated 2006-06-22.
Have you installed the Platform SDK and not inadvertently disabled/deleted anything? If so, additionally installing the Debugging Tools for Windows (of which dbghelp is a part) would probably solve this problem.
The many other missing headers make it sound like you're using VC2005 Express. Here's mention of the rpcerr/mac headers and a workaround: http://channel9.msdn.com/forums/TechOff/13...e-Platform-SDK/
If that works, it'd be appreciated if you could add these steps to the Build Instructions wiki page.
-
Aken and Mahaf are somewhat fitting (see http://www.touregypt.net/godsofegypt/mahaf.htm) names for a kernel-mode service and user-mode library that calls it to action. They are used for mapping physical memory and port I/O, which are required for ACPI table access and proper high-resolution timing due to various bugs in chipsets and Windows XP.
If disabled, the timer falls back to the usual Windows API routines, which are prone to problems (see http://www.gamedev.net/community/forums/to...opic_id=451305; the PDF referenced therein is now located at http://algo2.iti.uni-karlsruhe.de/wassenberg/timer_test.zip).
The driver isn't signed because I don't have the means of doing so; if you are able or know someone who can, help would be very much appreciated.
-
The build crashed when I tried to start the single player game.
My bad. A somewhat complicated memory allocation data structure's invariant is apparently being violated. This has also been reported in another thread. Are you running 64-bit Linux?
-
"warning: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’"
Oh yes, thanks, we'll fix those. Unfortunately I am really busy ATM (just got back from a business trip) but may manage during the next few days.
3) When I did "svn co" I've noticed a lot of windows exe, dll and pdb files. Is it possible to remove them from svn to not download them on non-windows OS?Further to what Philip has said, there is an (admittedly inconvienent) workaround, namely updating the individual top-level directories and skipping binaries\system.
what isn't good is that the game asks to attach a debugger when loading a game(I tried single player).Ooh, that is very bad indeed, it's a warning that a somewhat complicated memory-allocation data structure's invariant has been violated. I hope to be able to investigate this at work soon, too.
D'oh. Should be fixed now.Thanks
I have a fix for this locally, but as usual I don't really know if it will break Windowsheh, going by previous experience on such issues, it probably would on the first try
(unfortunately GCC and VC apparently differ in this area). I'd be happy to test the patch, but my home repo has more of those incorrect checksums throughout the tree, and it'll take a while to re-download the affected portions. Have sent it to my work address as well, maybe someone will beat me to it.I believe the other file exists because the 'lowlevel' directory is shared with some other projects and so it has a source/lowlevel/precompiled.cpp for use when the 'pch' directory isn't present. For 0 A.D. the easy fix is to just delete source/lowlevel/precompiled.cpp, but I think janwas still wants it there, so the less easy fix is to modify build/premake/premake.lua to somehow exclude that file from the list that will get built.Exactly. It'd be fairly simple for me to add a local precompiled.cpp to the other shared project that uses this code, after which it'd be OK to delete source/lib/precompiled (note lib vs lowlevel, the former is the directory name and the latter is the project name).
It's very strange, but I've managed to solve this problem only by replacing 'nasm' with 'yasm' in lowlevel.make. Seems like a bug in nasm (2.06).Ugh, that's bad news. Would you recommend switching to yasm entirely? I thought that YASM was newer and therefore prone to more bugs. Are there any other compelling reasons?
Thanks to the both of you for posting your issues and information, hopefully we'll get all of this fixed soonish
-
I have compiled the last svn version on my 64 bit sys and i become an segfault.
Here is my gdb output:
Thanks for reporting the problem, it appears to be the same as above.
The error statement is being found:Excellent, it looks like we've found the culprit, then. You can work around it for now by commenting out everything but the contents of the %ifdef OS_LINUX block in amd64_abi.inc (a proper fix follows).
@olsner: could you please add "-dOS_LINUX=1 "; to Premake's GCC command line? (amd64_abi.inc relies on that being set, else it uses Win64's calling convention, thus causing CAS to misinterpret its arguments and segfault).
-
I've added a hack in update-workspaces.sh that should forward the proper value to premake. I also added some code to send the proper elf64 format to nasm conditionally, so the assembly stuff should work out of the box on 64-bit linux now.
Great, thanks very much!
Just in case someone runs into the same problem: my TortoiseSVN reported a checksum mismatch in build/premake and build/workspaces. I'm not sure as to the cause (possibly corruption of my local disk), but it can be fixed by deleting those directories and restoring them via SVN update.
it's probably because of this error, which is the only one I can find left in the build log.hm, that looks fairly harmless (probably similar to the FCollada problem about int/long int being distinct types or not). Either way, the self-test is independent of the main executable.
Thanks for doing a backtrace! Since the same asm code works on Win64 with the exception of register renaming to match the platform's convention, I'd suspect that is where the problem is. It looks like our idea of the registers is correct (c.f. http://en.wikipedia.org/wiki/X86_calling_c...ABI_convention).
Could you please add an %error statement to the %else block in source\lib\sysdep\arch\amd64\amd64_abi.inc and rebuild? This will verify that we're using the right set of registers - if not, OS_LINUX isn't being defined on the NASM command line.
-
Have u released the files yet?
Yes, details are given in the Getting Started guide, which is referenced from the open-source page mentioned above.
This is amazing news! I will syndicate it for you.Thanks
-
Good to hear that the ia32 problem is gone after forcing arch=amd64.
My HOSTTYPE return "x86_64" like expected, which makes me wonder why it wouldn't see it.Yes indeed, that's strange.
Did you run the same update-workspaces script initially and after changing the premake script to force arch=amd64? It'd be great if you could add some error("text") statements to the various branches of the if/else statements in premake.lua:20 to understand if it's getting there at all and whether OS == "windows" or HOSTTYPE != x86_64 (hopefully your environment variable doesn't have it in quotes).
The only problem left is a new error that popped up.First of all, can you please ensure you have NASM >= 0.99.0? Running nasm -v will indicate the version, and nasm -hf indicates what formats are supported, which should hopefully include elf64.
We apparently need to pass -f elf64 instead of -f elf to NASM for 64-bit builds. This is done by premake in build/premake/src/Src/gnu_cpp.c:520 . As a quick fix, you could just change elf to elf64, but to properly support 32 and 64 bit builds we'd need to upgrade to premake 4.1 (see http://industriousone.com/platforms-0). Would you be interested in such an undertaking?
-
hm, the intent is to exclude ia32.cpp from 64-bit builds. Since it remains included, Philip is right about the root cause of the problem. Our premake script checks a HOSTTYPE environment variable - is that not set on your system or doesn't it equal x86_64?
Unfortunately I don't know about GCC compiler switches for 32 vs. 64-bit, but at least the ia32.cpp problem is something that we'll easily be able to fix or work around.
-
That kind spammer the other day reminded me of the existence of this game.
heh, this may be the first time I'm grateful to a spammer
Actually, I think the AI pathfinding does need more work.That's right. We have a basic A* pathfinder and a much more advanced TRA* (triangulated A*) system, but the latter is currently in limbo because it depends on a library for constrained Delaunay triangulation that's incompatible with our open-source license. Pathfinding being really important for RTS games, it sure could use some more work. One worthwhile undertaking would be a multilevel scheme that subdivides large maps into sectors (it doesn't make sense to perform long-distance searches at the full resolution).
Give me a pm if you still need help on this.PM sent!
-
The $700 Billion bailout, as is, will cause inflation as much of that money will be created out of thin air by The Fed.
I'm not sure about the inflation either, but what irks me is the attempt to hide the fact that the taxpayer is paying for all of this. Printing more money or the other Republican suggestion (tax breaks) - both are disingenuous, the latter hiding behind a higher deficit and long-term debt.
But the point I'm defending here is the plan is not fairAmen! Bailing out the greedy crooks that lied to their risk-management systems isn't fair, and worse, won't exactly discourage future shenanigans. For the "self-interest" prerequisite of capitalism to work, there has to be some disincentive for risk and failure like this.
As others have noted, this doesn't sound like (even regulated) capitalism anymore. Instead, FDR had it right:
The first truth is that the liberty of a democracy is not safe if the people tolerate the growth of private power to a point where it becomes stronger than their democratic state itself. That, in its essence, is fascism—ownership of government by an individual, by a group, or by any other controlling private power.(they will die anyway, just that it will be within a year).You may be right about them eventually going broke, but it's interesting that so much effort is going towards papering things over. Sounds to me like someone knows that the entire financial system is a house of cards and that they have to try to intervene.
-
Interesting, thanks for the pointer. It looks like there are some issues remaining - when I tried your search two hours ago, it returned zero results but looks good now.
Did you read about it on Motley Fool? They have an interesting conclusion:
I happen to like Cuil's chances, though. Its timing couldn't be better, at a time when Web users are gun-shy over how search engines are keeping and manipulating search history data. If Cuil becomes the new "do no evil" player, it could be a feel-good winner.
Yay for "do no evil" (ads, history, ..), but surely they have to earn money somehow. Anyway, I'll keep it in mind; it's always good to have competition.
-
"Multi-levelling" is not possible because the terrain is representated via heightmap. With exactly one height value per tile corner, the terrain is "2.5D". Something like Starcraft's Nydus canals / C&C's attack holes would still be possible but aren't planned for.
-
and will there be distribution independent packages of the alpha release available, beside the ones for ubuntu?
That's still an open question, our capability to do so is fairly limited (we only have a few developers using Linux). It's possible that the alpha release would be in source-code form and require compilation.
-
Good news: the game currently runs on 64-bit Linux, but the Win32 environment is our main development platform and sees more testing.
It is also possible to choose an arbitrary resolution via config file; we'll see whether the in-game options menu will be operational before going alpha.
-
Thanks for reporting this
Matei has contacted the video game trading site in question and they've removed it.I do wonder who would try to trade a (probably old and incomplete) 0ad build for a few bucks when the whole thing will be available for free - pretty soon, too. Oh well.
-
I'm getting an error...
This is just a warning - the VFS is indicating that it's being told to load a zero-length file, which is at least questionable. When did it happen? I bet that creating an output file failed, resulting in an empty file; the ensuing load generates this warning.
However it's definitely possible that zero-length files can happen, so I've changed the code to safely handle this without complaint.
(Just a small thing, I couldn't help but find it funny that the error message says that the operation completed successfully, as if that's the opposite of what was supposed to happen There is probably a very logical explanation for this, but still )heh. Yeah, that's rather silly and part of the reason Philip wanted it banished to the very end of the crashlog.
I've changed the message to "OSError = 0 (no error code was set)".
-
Seems to be fixed now, I can log in and see several other 0ad guys (e.g. Erik, Matt).
[am using Miranda 0.7.2.0 with msn.dll version 0.7.1.3]
-
In response to Michael's suggestion, Erik has posted a solution in the staff forum.
Here's the relevant steps to take:
http://tortoisesvn.net/docs/release/Tortoi...g-settings-main <-- there you can read about the general settings dialog. You can get to the General settings by right-clicking on a file/folder that's downloaded from SVN and there, in the Tortoise SVN submenu, left-click on Settings) The one we're interested in now is "Global ignore pattern", in that box please enter "Thumbs.db" (without the quotation marks, but with the capital t) and click confirm (or whatever it is in English).Cheers!
-
I am so glad that some publishers/developers have seen the light: Copy protection just annoys the honest guy and doesn't stop pirates in the long run.
It is good that these guys are doing well with their strategy
-
Welcome
Thanks for the warm words.And for my first query, it's something I've always wondered - are computer games more difficult to make/design than console games? Or vice-versa? I've always thought of consoles as just specialized computers, while not a powerful as their counterparts, much smoother/faster in game execution. Is that a product of the game or the machine it's played on?Hard question. Here's a developer's perspective:
When designing and coding a console game, you usually have much more limited resources (most of all: memory). There are also requirements from the platform owner prescribing all sorts of hard limits, e.g. maximum load time. Finally, the hardware is often a bit wacky (see PS1, or the decidedly non-SMP configuration of PS3). PCs have fewer such constraints and problems.
Then again, with a (single-platform) console title you do not need to worry about different graphics card capabilities and so on. Counterbalance that against the inconvenience of needing a Devkit to test the build.
As you can see, there's no clear answer - everything is tradeoff.
IA32? I thought I was x86_64?
in Game Development & Technical Discussion
Posted
It really pains me to see how often this bug is reported online :/ My bad.
I've had a quick look and that allocator has several 64-bit bugs (~0 vs ~size_t(0), it's also using 32-bit tags). Most of the time we were testing on 32-bit Windows, and it looks like most Linux users are on 64-bit. Have begun fixing those issues, but unfortunately I left the files at work (am now at home for 1 day of vacation). If a colleague is able to send me those files, then those issues will be fixed later today.
heh, yes - this problem with the deer mesh has existed for a while. The problem is that the error message isn't annoying enough to galvanize the artists into action
Thanks for the info, I see someone has already added that to BuildInstructions
hm, the docs say alDeleteBuffers can only fail with that error code if the buffer is still in use. However there is a mechanism in place for unqueuing buffers and stopping the source, which should happen before freeing buffers (even when shutting down). Unfortunately this problem doesn't occur on Windows (more forgiving OpenAL implementation?), so it's difficult to investigate. Would you be up to firing up the debugger and seeing what happens in vsrc_reclaim when shutting down?