Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - grrussel

Pages: 1 2 [3] 4 5
31
Programming / Re: 0.9 Build fixes for OSX
« on: May 15, 2013, 06:59:25 pm »
A little more digging suggests its a language extension. https://msdn.microsoft.com/en-us/library/34h23df8(v=vs.80).aspx

Under the standard (/Za), you need to make an out-of-class definition for data members. For example,
class CMyClass  {
   static const int max = 5;
   int m_array[max];
}
...
const int CMyClass::max;   https:// out of class definition
Under /Ze, the out-of-class definition is optional for static, const integral, and const enum data members. Only integrals and enums that are static and const can have initializers inside a class; the initializing expression must be a const expression.

32
Programming / Re: 0.9 Build fixes for OSX
« on: May 15, 2013, 06:55:41 pm »
Mm. For whatever reason, that last change made it break.

It may be a bug in clang/LLVM, or a happy portability problem, or just laxity in other compilers?

At any rate, it is breaking the default C++ compiler on OSX 10.7 , and the fix is trivial to patch in.

33
Programming / Re: 0.9 Build fixes for OSX
« on: May 14, 2013, 09:48:05 pm »
Clean builds make no difference to the presence of the linker error.

It looks like an instance of the following: https://stackoverflow.com/questions/1312241/using-a-static-const-int-in-a-struct-class/1312267#1312267

34
Programming / Re: 0.9 Build fixes for OSX
« on: May 14, 2013, 01:42:56 am »
Hi, the OSX git build has broken again since
Commit 6024bedf3cca3855a5b00b315b5a24d8530964e9 by neo_nihilist
rewrite of unitOpensDoor() function.

Undefined symbols for architecture x86_64:
  "OpenXcom::MapData::O_WESTWALL", referenced from:
      OpenXcom::TileEngine::unitOpensDoor(OpenXcom::BattleUnit*, bool) in TileEngine.o
  "OpenXcom::MapData::O_NORTHWALL", referenced from:
      OpenXcom::TileEngine::unitOpensDoor(OpenXcom::BattleUnit*, bool) in TileEngine.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [../bin/openxcom] Error 1

The fix patch is attached,

35
These currently always have the default base layout.

Might be nice to be able to edit the base layout, too! ( XCOM tower defence, hmm)

36
Builds & Ports / Re: Request for OSX build
« on: May 09, 2013, 09:09:38 pm »
The .app OSX application build is a totally different build system, which builds its dependent libraries (SDL,YAML,etc) as OSX frameworks. I don't know how to do that :-|

If the .app build system is resurrected and described in sufficient detail, I can certainly add it to the auto-builder

In the future (1.0? 0.9.1? when OSX build fixes are committed into git) I can look into resurrecting the homebrew formula so that openxcom can be installed on OSX merely by

    brew install openxcom


37
Builds & Ports / Re: Request for OSX build
« on: May 08, 2013, 10:13:21 pm »
Git builds for OSX should now be appearing automatically at https://bitbucket.org/grrussel/openxcomosx/overview (fingers crossed)
This is a slightly patched version to get the build to work (see issue #465 on github)

38
Builds & Ports / Re: Build on Mac OS X 10.7.4
« on: May 08, 2013, 10:09:28 pm »
My (slightly different patch) is linked to from https://github.com/SupSuper/OpenXcom/issues/465

39
Programming / 0.9 Build fixes for OSX
« on: May 07, 2013, 11:36:38 pm »
Here is a diff to allow OpenXCOM 0.9 (or at least, todays current git source) to build on OSX 10.7 via Makefile.simple as was possible before in 0.5

Fixes are a) not including headers not present (malloc.h) and b) OpenGL includes, use of -framework, and not redefining glCreateProgram etc

Since now there is a linker command line difference e.g. OSX adds -framework OpenGL to link step, there is now a named OSX target in the makefile (As was there previously for Dingoo)

40
Programming / Re: Messing with yaml save games
« on: November 19, 2012, 07:51:38 pm »
Its probably not possible to convert arbitrary save games between versions. It is possible to add features with load/save code that can default in missing values - and thats good to reduce game save changes. It won't always be possible, or sensible, I expect.

I changed the save and load code to get my changed save games; let the game load + verify, and then omit unneeded in saving, or add new content in saving.

41
Programming / Re: Questions about code / design decisions
« on: November 19, 2012, 07:47:30 pm »
re the version number in the save file; its probably wise to bump it immediately after a release - as now we will have 0.4.5 tagged save files with various features ;-)

This looks currently set from Options.cpp
std::string _version = "0.4.5";

If you think the yaml-cpp is slow, you should see the load time of the save game files in python!

FWIW: the speed of save load/store is not noticeable so far for normal XCOM - only with my way larger battlescape sizes.

42
Work In Progress / Re: [Experimental] Modular rulesets
« on: November 18, 2012, 05:21:56 pm »
Thats an STL vector out of bounds access getting caught in a debug build by debug only error checks in the STL

some code is trying to access element N of a vector of less than N+1 elements in length.

43
Programming / Re: Messing with yaml save games
« on: November 18, 2012, 12:43:56 am »
This is a python script, indeed. It needs the pyaml and PIL libraries installed, too.

It loads a battlescape save game (change the path in the script, not elegant but meh) and makes a map of unit positions - showing red (xcom), white (dead), and blue (alien) as a png image.

44
Programming / Re: Questions about code / design decisions
« on: November 18, 2012, 12:37:07 am »
The YAML format for save games is very explicit about default values. Its quite inefficient, space wise, and slow to load on large saved games (e.g. enlarged battles)

The bulk of an enlarged battle state is tile state. Most of the tiles are not on fire. They have no smoke. They are (not yet) discovered. These facts are all explicitly stored in YAML.
They can be defaulted in the load code, and the save code can emit YAML only if the content is not an implicit default.

Omitting fire: 0 and smoke: 0 in tile saves, and then discovered[false,false,false] reduced file sizes (in KB) as shown. (It may reduce save/load times)

george-russells-imac:OpenXcom grrussel$ ls -sk boom3.sav
4624 boom3.sav
george-russells-imac:OpenXcom grrussel$ ls -sk test_sav_change.sav
3928 test_sav_change.sav
george-russells-imac:OpenXcom grrussel$ ls -sk test_sav_change2.sav
3164 test_sav_change2.sav


The tile positions are also explicitly given, and could likewise be implicit due to ordering in the sequence.

45
Programming / Messing with yaml save games
« on: November 16, 2012, 11:56:56 pm »
Given a save file on the battlescape, generates a PNG map showing live + dead units, colour coded.

Fun parsing YAML! (slow on big save files)


def load():
   f = open("/Users/grrussel/Library/Application Support/OpenXcom/boom3.sav")
   import yaml
   dd = []
   for data in yaml.load_all(f):
      dd.append(data)

   bg = dd[1]["battleGame"]
   return bg

b = load()

w = b["width"]
h = b["height"]
l = b["length"]

from PIL import Image
im = Image.new('RGB',(w,l))

tiles = b["tiles"]

units = b["units"]
for u in units:
   pos = u["position"]
   x,y = pos[0],pos[1]
   faction = u["faction"]
   health  = u["health"]
   col = (255,0,0) if faction == 0 else (0,0,255)
   col = (255,255,255) if health == 0 else col
   
   im.putpixel((x,y), col)

im.save("xxx.png")

Pages: 1 2 [3] 4 5