OpenXcom Forum
Modding => Work In Progress => Topic started by: AndO3131 on June 15, 2013, 10:48:51 am
-
Hi. With recent @Warboy1982 activity - new sprites, sounds, etc. I thought it's time to talk about Terror support. I'm a big fan of hybrid game, so I made some efforts to get this started. My first though was that we need more complex folder support, so I' ve implemented this (https://openxcom.org/forum/index.php/topic,1236.15.html) @Daiky's idea. It's available on Github (https://github.com/AndO3131/OpenXcom/tree/Folder_support). This branch is quite complete, so it can be pulled to the main code, if developers want it.
Based on it, I tried to pull in some Terror images (ufopedia). It works, however colors are bad, since Terror used different palettes. My second thought was trying to add 32bit surface support - this would allow drawing all necesary colours as needed. What do you think about this? Is this something we want or not?
For now I managed to get both globes drawn, but shading doesn't work. I don't get these template shader functions. They don't work with 32bit globe surface, and I don't have a clue how to get it fixed. I'm hoping for some help, ideas, thoughts from you guys.
If someone wants to check out how this works, get the code from this branch (https://github.com/AndO3131/OpenXcom/tree/TFTD_Support) and compile it. Here's the settings.cfg entry I use (your folder structure might be different)
==========
games:
xcom1:
vanilla: UFO1/
openxcom: UFO1_openxcom/
rulesets:
- name: Pathfinding
folder: ""
- name: Xcom1Ruleset
folder: UFO1/
xcom2:
vanilla: Terror from the Deep/
openxcom: UFO2_openxcom/
rulesets:
- name: TFTD
folder: Terror from the Deep/
==========
And some screenshots of the globe.
-
For now I managed to get both globes drawn, but shading doesn't work. I don't get these template shader functions. They don't work with 32bit globe surface, and I don't have a clue how to get it fixed. I'm hoping for some help, ideas, thoughts from you guys.
This template functions work on palette graphics. They change one palette index to another using logic form class in template parameter. Right now its expect 8bit palette but this will still work if palette was 16bit aka both palettes merged together but this will not be supported by SDL (its only allow 8bit palette).
Another approach is that to allow this template functions to accept RGB colors but this will have some drawbacks like it will be slower than now and shading will have different hue than original. But this will have some positive sides too. Without 8bit limitations shades will be more smooth than now.
-
This template functions work on palette graphics. They change one palette index to another using logic form class in template parameter. Right now its expect 8bit palette but this will still work if palette was 16bit aka both palettes merged together but this will not be supported by SDL (its only allow 8bit palette).
Another approach is that to allow this template functions to accept RGB colors but this will have some drawbacks like it will be slower than now and shading will have different hue than original. But this will have some positive sides too. Without 8bit limitations shades will be more smooth than now.
Is it possible to have 16bit colours available but still be able to load, and shade/colour replace palletted images? That would be the ideal...
-
ups... I made small mistake, it only require 9bit (514 different colors) to have both palettes. 16bit is still require because its next possible storage size.
Is it possible to have 16bit colours available but still be able to load, and shade/colour replace palletted images? That would be the ideal...
you mean RGB colors? it will be tricky because conversion RGB <-> Palette lose information. If you want have some graphic that have both XC1 and XC2 it require to be RGB graphic and after that you cant use current shading method that use palette index. great example of that situation is if you want create unit from XC1 that using weapon form XC2, this require RGB to store it in one graphic. Next thing that engine do with that unit is applying correct shading when is drawing it on battlescape map, but we now lost data required to do it.
Because SDL dont support palettes bigger than 256 (8bit) maybe we should scrap `SDL_Surface` as data format? It can be replaces by plain `std::vector<Uint16>` with some additional fields. With 65535 different colors in palette, we could use couple palettes in one graphic (0-255 XC1 globe palette, 256-513 XC1 battlescape palette, 514-767 XC1 graph palette, 768-1023 XC2 globe palette etc.). Every pixel will have information form what palette he is from. `SDL_Surface` will be still used but only as main display surface.
-
It's not about SDL. SDL can support what hardware supports. There are no graphics modes and never been on planet Earth where more than 256 colored palette was used. There's no such technique. There is 15 bit RGB (5 bit per component), 16 bit (5-6-5),24 bit (8 bits per component , true color, and possibly aligned to 32 bit) and recently introduced 30 bit(10 bits per component +2 to align).
It is possible to use 8bit paletted sprites and convert them into truecolor during drawing pricedure, but (1) I dont know amount of performance drop it causes (maybe noticeable), (2) how to mak pixel processing methods work, if they are expecting for color index, not RGB value.
-
Hmmm. I know Diablo 2 used palleted images that it converted into higher depth, but I don't know what the performance hit on that was like.
Well, the simplest solution for TFTD support as a seperate game is to simply switch out the palletes through data, but you'll probably need to have a higher bit depth if you want to use UFO and TFTD sprites at the same time, which would probably mean your best option is interfacing palletted images with true colour, to preserve the ability to shade the sprites via pallette shift. (And also, if we want to recolour sprites, palletted images are ideal for that)
-
While using 32 bit surface, we could use alpha channel to get increasing opacity - wouldn't it be a good form of shading?
I would need help with that -> here's a Github branch (https://github.com/AndO3131/OpenXcom/commits/32bit_Surface_Support), it doesn't use any folder changes mentioned in earlier posts.
-
While using 32 bit surface, we could use alpha channel to get increasing opacity - wouldn't it be a good form of shading?
I would need help with that -> here's a Github branch (https://github.com/AndO3131/OpenXcom/commits/32bit_Surface_Support), it doesn't use any folder changes mentioned in earlier posts.
The issue with shading is that both UFO and TFTD change the colour as it darkens- UFO reddens it slighly, and TFTD makes it bluer. (to give a visual impression of being underwater) They achieve this by using custom palleted colours, which means some colours are more affected by this tint than others. You can't really preserve the shading technique while dumping palleted images entirely, and for that matter, opacity channels work best by allowing us to anti-alias the sprite's edges. You're thinking of post-processing sprites, which is a slightly different thing again.
-
Ok. After much struggle I've made the globe shading without/with/only water working here (https://github.com/AndO3131/OpenXcom/tree/TFTD_Support). It presented another problem - globe tends to 'dissapear' during rotation - any help on that would be appreciated.
I'll try to do something about battlescape, no promises though.
P.S. Overlook x-com base on yellow land :)
-
[OT]
you have probably bugged version of SDL, you should not see black dots between triangles. SupSuper spot this long ago and he find outs that was caused by bug in (IIRC) SDL_GFX
-
[OT]
you have probably bugged version of SDL, you should not see black dots between triangles. SupSuper spot this long ago and he find outs that was caused by bug in (IIRC) SDL_GFX
Actually, this was me. I even submitted the patch to SDL_gfx, but that's by-the-by :)
-
[note to myself]
check who did what exactly :>
-
Good news :)
I've managed to combine two palettes in battlescape. Will work on supporting terror maps now. Geoscape dissapear problem seems to be fixed, too.
-
Why this craft has underwater "bluish" tint for shades AT terrain level?
-
Good news :)
I've managed to combine two palettes in battlescape. Will work on supporting terror maps now. Geoscape dissapear problem seems to be fixed, too.
Nice work mate , keep it up and we will be playing TFTD in no time :P
-
Why this craft has underwater "bluish" tint for shades AT terrain level?
Good catch. I used wrong palette (one of those underwater).
-
I believe we could "recode" tftd sprites into ufo1 palette by closest color algorithm, and use it with xcom1 palette...
But jow did you make them together?
-
I believe we could "recode" tftd sprites into ufo1 palette by closest color algorithm, and use it with xcom1 palette...
Someone could try it, but I think it would require much more work (besides, I don't know, how to do it :-[).
Initially, whole battlescape is shaded to one big surface, then drawn to screen. Instead of one big surface, I used small tile to blit shade of small map parts to it and then blit this small tile on proper place in battlescape. This way every part of map can have different palette. Remember, It's not working perfectly yet.
-
How is your algorithm, performance-wise?
-
those look really nice
-
If you are just blitting surfaces onto other surfaces (remember the screen is still a surface), it is likely SDL is doing all the converting for you behind the scenes. If you try to blit 8bpp surfaces with different palettes, SDL will automatically do "nearest color" matching between the palettes. If you try to blit 8bpp with 24bpp, it will automatically convert between bit-depths as appropriate. If the screen is 24bpp, you would get an apparently "flawless" result. This all has performance costs, though they might not be noticable on modern systems.
-
I'm coding on Linux, and as @Supsuper said, I didn't notice any performance issues yet. I haven't tried to compile on Windows.
If you try to blit 8bpp surfaces with different palettes, SDL will automatically do "nearest color" matching between the palettes.
Result's of this are here (https://openxcom.org/forum/index.php/topic,668.msg6518.html#msg6518).
-
I'm coding on Linux, and as @Supsuper said, I didn't notice any performance issues yet. I haven't tried to compile on Windows.
I don't think you'll see much in the way of performance changes on Windows either. I think where you will probably see it (if anyway) are on the embedded devices, like Android devices, Cannoo, Pandora, GP32x, GCWZero etc.
-
SDL is making 8bpp->[palette]->RGB conversion for each pixel anyways. So at 24bit surface/display mode that wouldn't make any performance difference at all.
-
Result's of this are here (https://openxcom.org/forum/index.php/topic,668.msg6518.html#msg6518).
AndO3131 this dont look like "nearest color". It more probably this use my blit function (aka simple copying palette index without bothering with different palettes) not SDL ones.
-
There's some new progress. Looks like battle terrain is not a problem anymore (only thing left is putting them in ruleset). Next thing will be items.
-
Fantastic Work!
August 1999 - This just in, reports of the rumo(u)red organization called X-COM seen flying an unknown type of flying craft into the ocean! Ocean liner personnel who witnessed the incident say the craft didn't return out of the water during the few hours that they passed near. What could this mean? Bug your local representative and keep off the beaches!
-
Technology used for bubbles trail requires for "postprocess" pixel manipulation. If this "mixed palette" concept will be used, I'm not really sure this will work. Because for working it will require pick color index of pixel, modify, put pixel index. For every bubble trail pixel, and often even number of times.
I wouldn't take this mixed mode at all.
-
Bubbles coming from terrain do work - I think they are included in map files. This is an example ruleset entry for terrains, based on ufopaedia.org found here (https://www.ufopaedia.org/index.php?title=TERRAIN_%28TFTD%29) - bubbles are in UFOBITS section:
==========
- name: SEABED
mapDataSets:
- BLANKS
- SAND
- ROCKS
- WEEDS
- DEBRIS
- UFOBITS
largeBlockLimit: 3
textures: [13]
mapBlocks:
- name: SEABED00
width: 10
length: 10
type: 1
subType: 0
maxCount: 3
- name: SEABED01
width: 10
length: 10
maxCount: 3
- name: SEABED02
width: 10
length: 10
maxCount: 3
- name: SEABED03
width: 10
length: 10
maxCount: 3
- name: SEABED04
width: 10
length: 10
maxCount: 3
- name: SEABED05
width: 10
length: 10
maxCount: 3
- name: SEABED06
width: 10
length: 10
maxCount: 3
- name: SEABED07
width: 10
length: 10
maxCount: 3
- name: SEABED08
width: 10
length: 10
maxCount: 3
- name: SEABED09
width: 10
length: 10
maxCount: 3
- name: SEABED10
width: 20
length: 20
- name: SEABED11
width: 20
length: 20
- name: SEABED12
width: 20
length: 20
==========
Bubbles coming from operatives of course don't work, but I think they are hidden somewhere in terror files, just like other animation frames.
-
Some more info. @Volutar, you can see bubbles in first screenshot.
Weapons and grenades work, but I don't have projectiles. How did you guys get projectiles currently in use by the game (those in Resources/BulletSprites)?
-
I mean bubble trails after projectiles. They won't work in this "hybrid palette" mode.
-
the bullet sprites have been around on various forums for a while, we used to have them stored in byte arrays, as did the original.
tftd will have them hard-coded as well. it's just a matter of finding the appropriate data within the executable and interpreting it using a battlescape palette.
-
I mean bubble trails after projectiles.
We won't know until we try. Does anyone know where can we find them inside data files? Or maybe that's a hardcoded feature? If so, we would need some equivalent.
They won't work in this "hybrid palette" mode.
I'm not sure what do you mean. I already wrote that every surface in battlescape can have it's own palette. As you can see on screenshots around this thread, all soldiers use Ufo:Enemy Unknown palette, map uses Terror from the Deep palette, bubble trails can have it's own, that's not a problem. However, I'm not sure if current code has enough features to get trails working as expected. If so, someone would have to write apropriate code, but that's not colliding with "hybrid palette" concept.
-
We won't know until we try. Does anyone know where can we find them inside data files? Or maybe that's a hardcoded feature? If so, we would need some equivalent.
I'm not sure what do you mean. I already wrote that every surface in battlescape can have it's own palette. As you can see on screenshots around this thread, all soldiers use Ufo:Enemy Unknown palette, map uses Terror from the Deep palette, bubble trails can have it's own, that's not a problem. However, I'm not sure if current code has enough features to get trails working as expected. If so, someone would have to write apropriate code, but that's not colliding with "hybrid palette" concept.
What might cause difficulty is trying to palette shift things if you're running two palettes at once- even if you code it perfectly, XCOM sprites won't work if mixed with TFTD sprites using any of the underwater palettes, which (mostly) shift blue as they get darker, wheras XCOM sprites EITHER shift slightly red, or just take funky, uneven steps down in brightness that look pretty cool.
-
AndO3131 can you release your experimental branch? Its hard to say what is possible or not without seeing implementation.
Right now I dont see any shading in your screen shots, you didnt made it work?
-
AndO3131 can you release your experimental branch? Its hard to say what is possible or not without seeing implementation.
https://github.com/AndO3131/OpenXcom/tree/TFTD_Support
-
I tried to get these images work, but I've stumbled in two problems I need some help with.
1 problem: I couldn't get right colors to appear on screen. In Gimp I tried paletted image, gave one of Terror palettes and it looks good. When I load this image in game - colors are different. I've attached image in rgb palette (I think it will be enough for projectiles, contains one ground and one underwater set) and four battlescape palettes I got from 'lbm' files - they are in Gimp palette format (gpl), but i couldn't load that extension. There has to be somebody around here who can fix this projectile image ;).
2 problem: @Warboy1982, I tried loading additional projectiles file with extrasprites, but I seem to have acces only to first row of the file (first projectile). Can extrasprites combine larger files? I also have problem with 'bulletSprite' option in rulesets - how does it work?
-
load it with extraSprites, but make sure you define the height, width and subdivision x and y.
setting the subX and subY tells the loader to split the image into a set of x*y images.
the way the bulletSprite works in the ruleset is this:
number * 35 = index in projectile set. by default, all projectiles are 35 particles long, some of them are simply "blank"
-1 = no bullet sprite.
you may have to make an adjustment to RuleItem.cpp line 118 for modability's sake.
-
I was trying to get a second set of bulletSprites working this morning.
I did succeed eventually - I think I used something like (from memory):
extraSprites:
- Projectiles
sizeX: 105 (whatever the value is in Xcom1Ruleset)
sizeY: 18 (I had 6 new projectiles... 6 x 3 )
subX: 3
subY: 3
385: Resources/MOD/BulletSprites.png
That lined up with bulletSprite: 11 - 16 (as in bulletSprite: 11 was my first new bullet, bulletSprite: 16 was my last)
It took me a while to figure out it wanted a completely different number.
-
@Warboy1982 It turns out I did nothing wrong in making the projectile file, the problem is in 'modindex' variable. Weapons can access projectile, if I define it in the same ruleset file, but they won't shoot it, if it's defined in different ruleset. Is it correct behaviour, or did I mess something up while merging the code?
-
if you define it in xcom1Ruleset.rul, it won't get indexed
-
Ok. Projectile loading solved (no trails, tho). Turns out new surfaces also don't get indexed. Some progres has been made regardless.
-
TFTD. Yummy!
-
AndO3131 Im working on my ShaderDraw to allow bliting to 32bit surfaces. You will able revert most of changes in `Map` and TTFD will still working.
-
Ok. I'm waiting for it, but I think I got the hold of current shader. It works fine with multiple palettes - hasn't let me down yet. Learning new one scares me :o.
In the meantime, some new things.
-
I've managed to get bullets and explosions for terror-based weapons work with different images over and under the water. There are more screens in terror-like fashion in battlescape, but also some new issues I need help with.
1. I can't get image buttons on main menu to work properly - they don't display correct colors when pressed.
2. I would need help with drawing routines for aquanouts and those underwater monsters, especially humanoid ones (aquatoid, gillman, tasoth, etc.). These graphic sets are just too much for me to handle.
3. Since bullets work, I would like to take a look at infamous bubble trails after bullets. I need a piece of animation describing various stages of trail dissipating. If someone has it, please post it here.
Hoping for some help from dev team ;)
Here's the code: https://github.com/AndO3131/OpenXcom/commits/TFTD_Support (https://github.com/AndO3131/OpenXcom/commits/TFTD_Support)
-
i'll start giving you a hand with this when i get some free time, i have some ideas on how to do stuff, but i believe TFTD used a bunch of colour swapping (for the buttons and the "smoke" clouds) that may currently be somewhat beyond the reach of our engine.
-
Thanks, @Warboy1982.
I put up some files to run this terror-like environment. options.cfg goes in place of the old one (I suggest a backup ;)).
The rest is unzipped in Data folder. According to this particular options.cfg, you also need folder Data/UFO1 with Ufo:enemy Unknown copy and Data/Terror from the Deep with TFTD copy (I think mine was 2.1, but there's a good chance it will work with other version). Of course, folders are customizable, but Windows shortcuts don't work (symlinks in Linux work great).
P.S. TFTD ruleset is quite far from being complete ;D
-
New screenshots incoming - combined battlescape map.
-
if you jump on irc we can have a good, long chat about things.
-
Looks like Warboy's interest just spiked up ;)
-
back in the days when I said I was going to implement TFTD I made some notes about the bubble trails after bullets. I think it was just observations, I guess I share my notes, you never know if it's helpful.
- double animation speed, 8 frames long, particles gradually fade out each frame (transparency)
- 2x2px and 1x1px white/blueish particles emitted on the bullet trail at more or less random positions, but evenly spread out. (each voxel bullet travels through has 50% change to emit particle?)
- particles rise in voxel space, smaller particles move faster than bigger particles with a bit of randomness in the speed (not all particles of same size move at the same speed)
I don't know if it's correct or not or useful, so use it at own risk :p I was almost about to implement it, I'm sorry I never got that far... I think I got stuck in how to get transparency work. (and how to spell the word correctly :p)
-
what kind of transparency you want? Its not hard to replace color part in palette mode. In AndO3131 version it would be a bit more harder but if we cheat and use simple color blending it can be trivial.
-
TBH I would really like all the TFTD content but keep the UFO EU interface, I was never a big fan of the TFTD palette or UI
-
according to some research done by volutar, they had a big-ass lookup table for colour replacement values to simulate transparency.
-
@Bluedrake42, in this hybrid mode UI is selectable.
Final battlescape screens. Unfortunately, battle with only TFTD files loaded can't start yet - there has to be done some extra coding with aquanauts.
P.S. Some colors can be wrong (haven't played in TFTD for a long time).
-
oh awesome, as long as I can choose thats fine =D
-
i'm working on an xcom2ruleset.rul file. so far i've got the facilities, crafts, craft weapons, USOs, and armors converted, and i'm half done with the units. trouble is, i need save files to extract certain key pieces of information, like unit height.
so far i know gill men are 20 and deep ones are 21.
-
I've got a bunch of 100% saves if you need.
-
Thanks to @Warboy1982 advice, I've made aquanauts and aquatoids working.
Looking forward to new ruleset ;D
-
Awesome work. I like the tftd interface graphics, I imagine the yellow-greens...putting around in one of those tiny yellow mini subs at less than walking speed at the bottom of the ocean.
And the harpoon rifle is a sun bleached yellow-green super-soaker.
-
This is giving me chills... :)
-
units i have covered so far:
gill man, deep one, tasoth, aquatoid, hallucinoid, tentaculat, triscene, biodrone
units i still need saves for:
calcinites, lobstermen, xarquids.
-
Just go on any late-game mission and you'll have no problem finding Lobstermen. :P If you go to T'leth you should also find Xarquid.
Calcinites are tricky as they rarely show up, maybe with some modified game to get them to spawn?
-
I only saw Calcinites in terror on passanger ship on higher difficulty (one was always in the centre room on first stage). They happened in second-third month in higher difficulties. Unfortunately, I don't have any save :(
-
Thanks to @Warboy1982 help, there's a progress in combined geoscape - there are no holes in it.
And one combined arms screenshot :)
-
your sdl_gfx needs updating :P
-
It's amazing how many people never update their libraries :)
Regardless, it's great work.
-
Sometimes a distro is slow, so you have to force an update from source...
and then you find out that the distro library was compiled with (or without) a bunch of specific distro options, and now your gui is broken. So you have to go grab another machine and research the problem, only to find out the new version of the library you care about is going to require a new version of another library ... and the chain continues until you give up rather than attempting to recompile the entire gui, just to get an updated version of libinsignificant.
I'm not bitter.
P
-
This is definitely something that I'm looking forward to. As a developer, is there something I can help with here?
-
You could try to compile and run it, check colour of the screens in geoscape and battlescape. You could also make 'GUIstyle' an option in 'advanced' options menu.
https://github.com/AndO3131/OpenXcom/tree/TFTD_Support (https://github.com/AndO3131/OpenXcom/tree/TFTD_Support)
I've attached files I use. Currently I'm slowly doing geoscape.
P.S. Added better UFO2_openxcom.zip
-
I'm getting a number of merge conflicts pulling AndO3131/OpenXcom into my tree. Most are resolved easily, but what is the relationship between the BattlescapeState::_btnZeroTUs ImageButton in SupSuper/master and the BattlescapeState::_btnReserve0TU ImageButton in AndO3131/TFTD_Support? How are you and Warboy coordinating your efforts?
-
I haven't merged it yet. I'll look into it now. It's merged, but some problems remain.
-
How's progress?
-
RL issues stopped progress on this mod, but everything I've done is on github. Currently battlescape is somewhat complete; next is geoscape.
https://github.com/AndO3131/OpenXcom/tree/TFTD_Support (https://github.com/AndO3131/OpenXcom/tree/TFTD_Support)
Together with @Yankes we tried to introduce 32 bit surfaces to Openxcom, but I have problems getting this feature to work properly - I hope that sometime in the future engine could read unpaletted images.
https://github.com/AndO3131/OpenXcom/tree/32bit_and_TFTD_support (https://github.com/AndO3131/OpenXcom/tree/32bit_and_TFTD_support)
-
Uhh... any OpenXCom: TFTD Support for Dummies Manual around, guys?
Pretty please? ;)
-
TFTD support is in very early stage right now (more like en exercise in programming), not in the main branch. I'll get back to it at later date.
At this moment you would have to compile code found https://github.com/AndO3131/OpenXcom/tree/TFTD_Support (https://github.com/AndO3131/OpenXcom/tree/TFTD_Support) or https://github.com/AndO3131/OpenXcom/tree/32bit_and_TFTD_support (https://github.com/AndO3131/OpenXcom/tree/32bit_and_TFTD_support) and use it with files found under https://openxcom.org/forum/index.php/topic,1312.msg12791.html#msg12791 (https://openxcom.org/forum/index.php/topic,1312.msg12791.html#msg12791) post. You would also need TFTD files in apropriate folder (DATA/Terror from the Deep if using configuration files from https://openxcom.org/forum/index.php/topic,1312.msg12791.html#msg12791 (https://openxcom.org/forum/index.php/topic,1312.msg12791.html#msg12791) post).
These guidelines are for now the closest ones I can give. Godd luck :)
-
SupSuper, is it possible merge branch "TFTD support" into master branch?
Switch between TFTD and EU mode possible via "advanced options" menu or command line.
Advantages:
- branches will not diverge;
- will increasing interest to the project;
- possibility connection to the project more developers and testers;
- merging on the last stages will be painful.
-
I wanna get 1.0 out before starting to throw such experimental code into the mix. :P
-
I agree with SupSuper. A 1.0 release must come before TFTD support.
Now I know that I have said this several times before, but bear with me: SupSuper is a TFTD fan (and so am I) and this means that TFTD support WILL BE IMPLEMENTED in the engine. However, this should happen after 1.0 - the "we're all don here" release
-
Hows it coming? also how long after 1.0 do you think that support will be implemented?
-
I think the consensus is that TFTD support will be implemented with a similar deadline as the 1.0 release - "when it's done" :)
-
sorry should have been a little more clear, i know open source and free ware projects are almost always on "when its done" schedule, i was thinking more of where on the list of things to do after 1.0 is out
-
I think TFTD support will be merged into the main branch right after the 1.0 release. Depending on how much manual work is needed to actually merge it.
-
I hope that the TFTD support will not mean solutions in Frankenstein's style like I saw in this thread.
UFO Defense and TFTD don't mix well with each other.
TFTD as a separate game is much better.
-
I second that.
-
Cant wait to translate tftd into german :)
-
https://www.ufopaedia.org/index.php?title=ENGLISH.DAT_(TFTD) (https://www.ufopaedia.org/index.php?title=ENGLISH.DAT_(TFTD))
https://www.ufopaedia.org/index.php?title=ENGLISH2.DAT_(TFTD) (https://www.ufopaedia.org/index.php?title=ENGLISH2.DAT_(TFTD))
you can probably use this as a starting point.
-
Any progress? (sorry for bumping)
-
It's on hold for the moment. I think devs have more clever way of reading apropriate files (maybe YAML solution) - this will enable TFTD game. @Yankes has 32 bit shader ready https://github.com/Yankes/OpenXcom/commits/ShaderDraw32bit (https://github.com/Yankes/OpenXcom/commits/ShaderDraw32bit). With these two things it won't be too long to prepare a hybrid.
-
Hi, I'm new here :) I was wondering if anyone here can tell me how to import the SWS into OpenXcom. I got the sprites but the turret appears in the wrong place, any ideas? Has this problem been solved in your project?
-
I was wondering if anyone here can tell me how to import the SWS into OpenXcom. I got the sprites but the turret appears in the wrong place, any ideas? Has this problem been solved in your project?
True, sprites appear in different places. They require new drawing routines in UnitSprite.cpp file. After that routines can be used in rulesets.
-
Thanks..... err, can I get an example on how I'll go about this? :) I'm still new to the system....
-
Here are routine changes for underwater tanks https://github.com/AndO3131/OpenXcom/blob/32bit_and_TFTD_support/src/Battlescape/UnitSprite.cpp (https://github.com/AndO3131/OpenXcom/blob/32bit_and_TFTD_support/src/Battlescape/UnitSprite.cpp)
You can try to compile OpenXcom using this file instead of the standard one. If it succeeds, you would have to add ruleset for the tank, for example
items:
- type: STR_TANK_GAS_CANNON
size: 6
costBuy: 420000
costSell: 340000
transferTime: 96
weight: 1
bigSprite: 40
floorSprite: 0
handSprite: 0
bulletSprite: 4
fireSound: 2
compatibleAmmo:
- STR_SWS_GAS_CANNON_SHELLS
accuracySnap: 60
accuracyAimed: 90
tuSnap: 33
tuAimed: 80
battleType: 1
fixedWeapon: true
invWidth: 2
invHeight: 3
armor: 20
turretType: 0
- type: STR_SWS_GAS_CANNON_SHELLS
size: 0.1
costBuy: 200
costSell: 100
transferTime: 48
weight: 1
bigSprite: -1
floorSprite: 12
hitSound: 13
hitAnimation: 26
power: 60
damageType: 1
clipSize: 30
battleType: 2
invWidth: 2
invHeight: 1
armor: 20
- type: STR_COELACANTH_CORPSE
size: 1
costSell: 20000
battleType: 11
- type: COELACANTH_CORPSE_1
name: STR_COELACANTH_CORPSE
floorSprite: 68
invWidth: 0
invHeight: 0
battleType: 11
recoveryPoints: 3
armor: 20
- type: COELACANTH_CORPSE_2
floorSprite: 69
invWidth: 0
invHeight: 0
battleType: 11
armor: 20
recover: false
- type: COELACANTH_CORPSE_3
name: STR_COELACANTH_CORPSE
floorSprite: 70
invWidth: 0
invHeight: 0
battleType: 11
armor: 20
recover: false
- type: COELACANTH_CORPSE_4
name: STR_COELACANTH_CORPSE
floorSprite: 71
invWidth: 0
invHeight: 0
battleType: 11
armor: 20
recover: false
units:
- type: STR_TANK_GAS_CANNON
race: STR_TANK_GAS_CANNON
stats:
tu: 70
stamina: 100
health: 90
bravery: 110
reactions: 20
firing: 60
throwing: 0
strength: 60
psiStrength: 100
psiSkill: 0
melee: 70
armor: COELACANTH_ARMOR
standHeight: 16
kneelHeight: 16
value: 20
deathSound: 23
moveSound: 14
armors:
- type: COELACANTH_ARMOR
spriteSheet: TFTD_BATTLE_TANK01.PCK
corpseItem: COELACANTH_CORPSE_
frontArmor: 90
sideArmor: 75
rearArmor: 60
underArmor: 60
drawingRoutine: 11
size: 2
damageModifier:
- 1.0
- 1.0
- 0.4
- 0.75
- 1.0
- 1.0
- 0.0
- 0.9
- 0.4
- 0.0
loftempsSet: [ 92, 89, 90, 91 ]
(it requires apropriate sprite entries) and load it through config file.
-
Thanks for your help, I'll give it a try :)
-
Ugghh, it's beyond me >_< it took me a while to realize that I'm not even using the correct OpenXcom version for this >_< (I wasn't using the GitHub version...)
Thanks, for all your help but I think I might have to install fixed guns on my SWS sprites for now.... ;D
-
i used your sws mod and i think its pretty cool idea :D...but i have to question...anybody know how tho make theirs "tracks" animated?(its called that way right? i mean THE WHEELS stuff sorry my english >-<) if that could be implemented...its really posible to make the "wheels" of the normal hwp animated? if i remember the hovertanks has animated blue sprinkles when it moves o.o
-
the hovertank actually has blue sprinkles all the time. and that's the problem for animated wheels or tracks: they would turn even while the tank isn't moving. unless somebody introduces code to "only animate when moving"...
-
yeah i forget to say that in tftd it actually only animate the tracks when the sws move...so my question was if anyone know how that was possible?? xD...but i get your point :D
-
Thanks for your kind words BlackWolf ^_^
Also thank you for reminding me of the Tracks, I guess I'll have to add Tank Tread covers to my SWS/RWP unit. Still, any help to figure it out the turret and tracks will be great. Does anyone know how to make a hwp use the hovertank sprite section?
The hover Tank's turret is further back, maybe it can work with the SWS turret, but I don't know how to assign the hwp to use the hovertank sprites... >_<
-
the hovertank actually has blue sprinkles all the time. and that's the problem for animated wheels or tracks: they would turn even while the tank isn't moving. unless somebody introduces code to "only animate when moving"...
UnitSprite.cpp file I mentioned a few posts back implements "only animate when moving" for coelacanth. Displacer has green stuff moving all the time (like hovertank).
The hover Tank's turret is further back, maybe it can work with the SWS turret, but I don't know how to assign the hwp to use the hovertank sprites... >_<
That's one of the problems I had while drawing underwater units. It's solved in aforementioned UnitSprite.cpp file. As I recall, tanks in TFTD used a little different sprite structure, so they won't look as you would like them to with current code. Routine drawing those tanks doesn't exist yet in master branch, so either follow hints I gave earlier, or wait for OpenXcom version 1.0 and beyond.
-
any update?
-
The devs are on a feature freeze to get to 1.0 of OXC, so I doubt they are working on TFTD support at the moment.
-
Together with @Yankes we made some work on the code allowing 32bit images to load into Openxcom https://github.com/AndO3131/OpenXcom/commits/32bit_Surface_Support (https://github.com/AndO3131/OpenXcom/commits/32bit_Surface_Support). It's enough to resurrect this thread: a little off-topic, but the concept is inspired by palettes present everywhere in UFO and TFTD.
WARNING: This is experimental branch, so I make no statements if and/or when it could be included in main branch. It may also produce weird colour effects or crashes.
WARNING 2: Images you can (propably) recognize are just a proof of concept. They are NOT indicating Apocalypse remake or anything like that.