Messages

586

Programming / Re: Battlescape development

« on: January 22, 2011, 07:48:04 pm »

Daiky i think that is small bug in battlescape, in mission during night source of light under solder is too big. its made 4 squares bright not only one under solder.

It's fixed now.

587

Programming / Re: Battlescape development

« on: January 18, 2011, 12:28:03 pm »

Just an update on what is happening on battlescape development these days.
- First of all the battlescape savegame is on it's way. Yaml-cpp hasn't yet all the base64 encoded binary reading/writing functions in place, so currently I will work with my own base64 encoding functions.

Why binary? Well, the map file will be huge otherwise, so I try to make it as compact as possible.
It is made up by 3 bytes per object, 1 byte for the datafile the object is in, 2 bytes for the index in the datafile.
A tile has 4 object on it, so 12 bytes per tile.
- Empty tiles are saved as a 0xFF byte followed by a two byte number indicating how many empties.
- Fog of war is stored as a bitmap with 0 or 1 when a tile is discovered(1) or not(0). This bitmap is also base64 encoded.
- Lighting level per tile is not stored but calculated.
- Smoke and fire is not yet implemented. But these will probably be stored as a list.

- Secondly, I discovered a spot in my design that really needed refactoring. I don't know what I was thinking when I initially did it this way.
Currently we have the following classes:

Resource/TerrainObject
Resource/TerrainObjectSet
Ruleset/MapDataFile

But a terrainobjectset and mapdatafile are actually the same thing (both refer to the .MCD file).
So I decided to merge them both into MapDataFile, and remove TerrainObjectSet.
And TerrainObject will be moved from the Resource map to the Ruleset map and renamed to MapData.
The set of MapData is then MapDataSet, following the syntax of Surface/SurfaceSet
So after refactoring we have:

Ruleset/MapDataSet
Ruleset/MapData

- Thirdly, lighting implemented like in the original game (light not blocked by objects). With the option to switch back to the solution I made.

588

Open Feedback / Re: How is my code?

« on: January 11, 2011, 10:48:54 am »

I would make the setSpeed a private function... how would you handle the acceleration/deceleration logic (for example depending on the weight the plane is carrying: a fully loaded plane accelerates slower).

There is imho also no need in setting a relative speed, only an absolute speed.

You could set a target speed, for example "setTargetSpeed(PATROLLING_SPEED)", but what the current speed is, what actually the patrolling speed is for this craft or when it will reach that target speed is none of my business.

589

Programming / Re: Battlescape development

« on: January 10, 2011, 02:56:59 pm »

Daiky i think that is small bug in battlescape, in mission during night source of light under solder is too big. its made 4 squares bright not only one under solder.

Hi Yankes,
I have seen this problem too, it's some kind of rounding error. Problem is the tile coordinates have a very low resolution (if you see every tile as a pixel with it's own brightness) and this easely causes this kind of rounding errors.

590

Programming / Re: Battlescape development

« on: December 30, 2010, 02:44:13 pm »

You can play with lighting too now, if you update your SVN build. Or wait until v0.2.
SVN 227:
- Basic per-tile-lighting implemented. Lighting/shade is depending on the landing site.
- Basic fog-of-war implemented.
- Caching of tiles and units implemented. This was needed for faster shading, despite some increase of RAM usage.
- Added terror site map rules.

I'm going to party some, and then go on holiday, so it might be quiet for a few weeksdays.

591

Programming / Re: Battlescape development

« on: December 25, 2010, 05:18:21 pm »

I made a little christmas present for the fans:
Wiiiii another videoooo
https://www.youtube.com/watch?v=t2ME1IhWFLk

592

Programming / Re: Ocean colouring - Version 2

« on: December 23, 2010, 01:47:52 pm »

I have a little performance suggestion, but it probably will not be worth the effort :p

That would require very little effort to implement, and probably would be worth it.
However, it's worth considering memory overhead for having those variables. Okay, so two values won't take an awful lot, but it might be worth keeping them local to the draw proc, and just calc them at the top of the function. Kinda of a halfway house - Only using memory when needed, but reducing the calculations needed

Fair enough, having these as class member variables may also people making them wonder what they are for. Having them locally it is more clear, and less codechange needed.

By the way, the performance increase of the new ocean colouring is amazing. On my pc rotating/zooming the globe goes very smooth and the overall FPS is also increased. Great job guys.

593

Programming / Re: Ocean colouring - Version 2

« on: December 23, 2010, 11:26:22 am »

Hi,
I have a little performance suggestion, but it probably will not be worth the effort :p
I see you recalculate sin(_cenLat) and cos(_cenLat) a lot of times over and over again.
You could however calculate and store the sin and cos in results in _sinCenLat and _cosCenLat only at times when _cenLat changes. And then use this precalculated value in the code. It eliminates a few hundred sin/cos calculations.
It may be of use on a Dingoo... because on a PC you probably not feel the difference, I don't know, I thought I'd just share my idea.

594

Programming / Re: Battlescape development

« on: December 22, 2010, 06:30:37 pm »

Interesting to see the Japanese gaming website seems to follow the progress, they even promoted the donation.
https://translate.google.be/translate?js=n&prev=_t&hl=nl&ie=UTF-8&layout=2&eotf=1&sl=ja&tl=en&u=http%3A%2F%2Fwww.game-damashi.com%2Fdatabase%2F%3Fp%3D7382&act=url

595

Programming / Re: Battlescape development

« on: December 21, 2010, 12:35:17 pm »

Well, it depends what you call fast The lighting code up until now is maybe just 40 lines, but it took me about 10 hours to write. I have implemented these features before already in my own project, some concepts are carried over from there.
BUT.... and here it comes... in my project the minimum requirement was hardware acceleration (OpenGL or DirectX driven).
It is unplayable without hardware acceleration, because of how I handled the tile drawing. I pumped all sprites into the GPU as textured polygons. The GPU can render tiles this way very fast, including applying shaders to the textures while drawing them.

But in OpenXcom there is no HW acceleration. (...yet. But not let us start the discussion here :p)
I did a first try implementing it like I was used to. But no go: less than 5fps... I had to rethink the whole concept.

The issue was in the fact I had to create a temporary copy of the original sprite, this means creating/allocating a new Surface object and then applying the shading to every one of it pixels, and then blit it. This whole process takes up to 2 milliseconds, which is forever in the world of graphics rendering. That's only 500 sprites per second. Before shading I could blit about 100.000 sprites per second. And as a reference: old/slow GPUs could already shade and blit 10 million sprites per second. FYI the current battlescape viewport contains 400 sprites on average.

So I had to take out the shading process out of the drawing loop. This is from gameplay standpoint no issue, because the shading only changes every now and then. At the start of the battlescape I copy every tile to a "cache". If the shading of a tile changes, I update the cache with the correct shading of the tile. The shading update is done asap for tiles within the viewport and a little later for tiles outside the viewport. In the drawing loop I just blit the cached/pre-shaded tiles.

596

Programming / Re: Battlescape development

« on: December 21, 2010, 01:22:53 am »

Very first try at soldier personal light. Still needs lots of work.

597

Programming / Re: Battlescape development

« on: December 19, 2010, 11:15:35 pm »

Not a very exciting feature that I implemented today, probably nobody ever notices it, but nevertheless: I call it "sun shading". This is the shade under the skyranger, inside buildings, inside ufo's,...

598

Programming / Re: Ufopaedia development

« on: December 19, 2010, 12:41:06 pm »

Have you talked to SupSuper yet, preferably over IRC?
As a contributor to openXcom, I can only give you the advice to start with a few babysteps.
Milestone 2 is very general.
I would have done something like this: "Milestone 2 - create a UfopaediaState class: a screen with a background image and an OK button. This state is launched when you press the ufopaedia button. When you press the OK button, you go back to the geoscape."
Done.
But I'm afraid you will bump into a lot of voids still in this very early stage of the game... new interface objects will need to be made, a structure to hold together all ufopaedia data.... RuleItems that read out of OBDATA.DAT, Rules for soldiers armour, Rules for HWPs, the whole Research structure... you'll need all that to build the ufopaedia on top.
I'm afraid SupSuper had a reason to put Ufopaedia on release 0.6 in the roadmap....

But I'm not the guy to discuss this with, just warning you upfront of possible obstacles

599

Programming / Re: Battlescape development

« on: December 17, 2010, 10:24:09 pm »

Since the Items section is undergoing a major overhaul in release 0.3, I wanted to wait to implement items/weapons in battlescape as well.
So I have put some less exciting stuff on my todo list for the coming weeks:
- battlescape lighting (night missions yay!)
- fog of war (the excitement of not knowing what to expect at every step...)
(not necessarily in that order)

600

Programming / Re: Battlescape development

« on: December 17, 2010, 04:34:36 pm »

First aliens sighted in openXcom !

I have done a commit. But for people who are not compiling themselves, I have uploaded a little video:
https://www.youtube.com/watch?v=Spn3DbrrEKE