Jump to content

historic_bruno

WFG Retired
  • Posts

    2.755
  • Joined

  • Last visited

  • Days Won

    47

Posts posted by historic_bruno

  1. My thinking was the router could be dying or otherwise broken. You could check if it has firmware updates available, or replace it if necessary (lots of people have routers now, even spares, so it's not hard to test a replacement). We still can't rule out your ISP as the problem, though, they may be filtering traffic or doing something else to interfere with the game.

  2. In-game terrain modification is all but ruled out for Part 1, due to design choices in pathfinding and complications in other things, e.g. terrain-based features like territories and water rendering. A lot of optimizations and caching can be used if the terrain doesn't change. Personally, I wouldn't mind having it with limited applications, but 0 A.D. isn't really about civil engineering/city building/etc. So part of me would like building roads, digging canals, building bridges, but it's not a focus :) Instead, RTSes tend to abstract such processes with technologies and stat changes.

    • Like 2
  3. On my system the game is playable in a Linux VM, in fact the framerate is higher than on Windows but it doesn't look as good. It all comes down to what drivers the VM provides (I have VMWare Workstation, VirtualBox is sadly far behind in most aspects that I've seen), what level of virtualization it has and the underlying host's hardware. I would check what graphics drivers it's using in the Linux guest, if it's software GL rendering, then it will be very slow indeed. Input lag is potentially going to be annoying too, as it's having to go through an extra layer.

  4. So, just so I understand: Is this going be to treated as a bug or as a change requiring a hardware update on the part of the user?

    As a workaround, try setting the "SDL_HINT_MAC_CTRL_CLICK_EMULATE_RIGHT_CLICK" environment variable from the terminal, like this:

    export SDL_HINT_MAC_CTRL_CLICK_EMULATE_RIGHT_CLICK=1open path/to/0ad.app
    changing the path to wherever 0ad.app is. Kind of yucky for OS X, I know, but it's only a workaround after all :P

    My thinking is to add an "emulatemacrightclick" option to the game's config, defaulting to true, Mac users can disable it if they have a two button mouse.

  5. Out of sync errors on rejoin are a known problem in A17. You may still be able to finish the game, but it's not reliable.

    When that happens, the best way to help us debug is to provide the oos_dump.txt files from each player (from the game's log directory) and a commands.txt from that game as well. By comparing the oos_dump.txt files, we can see what might have gone wrong. The OOS on rejoin has proven difficult to troubleshoot, however.

  6. I got an Iphone 4 working fine except the lock button is broken, How could I test that ?

    Well that's the tricky part... I think a 0 A.D. app would never be approved by Apple for relying on GPL code and plus it's a development version and violates all sorts of Apple's app design sensibilities even if they changed the GPL policy. So it can't be distributed through the app store or TestFlight (requires a review for beta apps). Then there are what Apple calls "ad hoc" and "enterprise developer" distribution, they don't require an app review, but only people registered as members of a dev team (for a yearly fee) can install the app and of course there are limits on that. As far as I know, all the official Apple channels require signing the app as a paid developer before it can be installed on a device, even for personal testing.

    That basically leaves jailbreaking the device and using a third-party distribution as the only way 0 A.D. could be distributed to non-developers. Cydia is one such service, I don't know anything more about it.

  7. Fixed the orientation problem, it was a bug in our code (incidentally it also affects desktop versions of the game, when the fullscreen resolution changes), and the model_common shader had failed to compile due to a type issue, that is now fixed. The next step will be building for real Apple hardware and ARM, not the i386 simulator.

    A slightly more realistic test on a simulated iPad 2, rotated to landscape view:

    LaWqvrtl.jpg

    • Like 1
  8. I'm a little curious as to how the game builds on the iPhone SDK.

    Decided to experiment with the iPhone simulator in Xcode, after a bit of work I was able to build an iOS app that runs in the simulator:

    v5wGj5Ul.jpg

    This is Xcode 6 on updated OS X 10.9.5, and the simulator is showing iPhone 4s / iOS 8.0. I tried other devices and they mostly work as well, except the Retina-based iPads have incorrect resolution and orientation changes (rotation) corrupt the screen. The Retina issue might be fixed by enabling HiDPI mode in SDL2. When touching a text input box, the onscreen keyboard pops up as shown below, which is nice. Most hotkeys don't work of course. There are some issues with touch input specific to iOS. But I'm quite happy that it works as well as it does :)

    In the coming days, I'll make an ios-support branch on Github, once I have a reasonably stable and cleaned up changeset.

    grmwYRal.jpg

    gjnLGqXl.png

  9. The mainlog.html is from a different instance of the game, but here's the call stack from the crashlog:

    > 	pyrogenesis.exe!CShaderTechnique::BeginPass(int pass=0)  Line 134 + 0x9 bytes	C++ 	pyrogenesis.exe!CLogger::Render()  Line 290	C++	pyrogenesis.exe!Render()  Line 258	C++ 	pyrogenesis.exe!Frame()  Line 369	C++ 	pyrogenesis.exe!RunGameOrAtlas(int argc=1, const char * * argv=0x00f27a30)  Line 511 + 0x5 bytes	C++ 	pyrogenesis.exe!SDL_main(int argc=1, char * * argv=0x00f27a30)  Line 555 + 0xd bytes	C++ 	pyrogenesis.exe!main(int argc=1, char * * argv=0x00f27a30)  Line 140 + 0xd bytes	C 	pyrogenesis.exe!wmain(int argc=1, wchar_t * * argv=0x01091d80)  Line 380 + 0xa bytes	C++ 	pyrogenesis.exe!__tmainCRTStartup()  Line 583 + 0x17 bytes	C 	pyrogenesis.exe!CallStartupWithinTryBlock()  Line 397	C++ 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes	
    The only time I see that error is when there's a problem with the game data, for whatever reason, maybe the game crashed and continued running in the background, or there were multiple instances of the game running, or something else was interfering with it. Please ensure that is not the case, and sometimes a reinstall helps.
  10. It looks like there's a problem opening the game's public.zip data archive. It's possible you have multiple instances of the game running (check task manager for pyrogenesis.exe), either that or the game's public.zip is missing, corrupted or being accessed by another application (antivirus scanner, etc?) I had that exact error when forcing the game to crash, but continue debugging in the background, while opening a new instance of the game.

×
×
  • Create New...