OpenXcom Forum
OpenXcom => Suggestions => Topic started by: Conti-k on February 01, 2012, 10:23:22 am
-
Hello,
First of all, thank you for keeping original X-Com alive.
Anyway, some few ideas/suggestions/whatever...
- Add support for "look" of soldiers to sprites to make them consistent with inventory art (female F0/F1/F2/F3 and male M0/M1/M2/M3). It can be done by inserting additional "torso" frames into XCOM_0.PCK and XCOM_1.PCK (just like in original game it's done with female/male gender). So we would have 4 variations of female (blond/redhead/black ponytail and black woman with short hair), and 4 variations of male (blond/redhead/black hair and black male).
- Add support for excellent Power/Flying Suit inventory images (BB's Mod Pack) (https://www.strategycore.co.uk/files/index.php?dlid=681). Example:
(https://desmond.imageshack.us/Himg214/scaled.php?server=214&filename=inven.gif&res=medium)
For example, if these files exist in UFOGRAPH directory:
MAN_2F0.SPK - MAN_2F3.SPK
MAN_2M0.SPK - MAN_2M3.SPK
MAN_3F0.SPK - MAN_3F3.SPK
MAN_3M0.SPK - MAN_3M3.SPK
engine will use them, instead of MAN_2.SPK and MAN_3.SPK. Default ones could be used in UFOPaedia.
- Fix "ghosts" problem. Because of that Lightning and Avenger doors are broken for non flying units. It has something to do with level 1 => level 2 doors passage. There must be a tile on both side of the doors (on the same level), otherwise unit will go through them like a ghost. Here's an image:
(https://desmond.imageshack.us/Himg21/scaled.php?server=21&filename=ghostb.gif&res=medium)
green path (downward) is working (there's a tile thus doors can be opened), and red path (upward) isn't working (there's no tile thus doors can't be opened).
- Add support for different ammo types for HWP Cannon, and HWP Rocket Launcher (AP/HE/I).
PS. sorry for my not-so-good English.
-
Hey Mate, welcome to the site.
Yanks has some code that can do what you wish with the skin/hair of agents to add more variety . Im not sure How far he got with this code but i thought it looked pretty good ;D
https://openxcom.org/forum/index.php?action=dlattach;topic=267.0;attach=475;image https://openxcom.org/forum/index.php/topic,267.15.html
As for the flying suit inventory screens they look pretty cool , i have never seen them before as i have only played the original version of x-com but i would love to have them in openX.
-
Hi Conti-K, welcome.
I think all your suggestions are good ones. I'm certainly going to have a look at that Lightning door/ramp problem, to see if it's a problem with our pathfinding too and fix it if it is.
-
Yanks has some code that can do what you wish with the skin/hair of agents to add more variety
That's nice. Does it use mask to recolor the sprites?
As for the flying suit inventory screens they look pretty cool
Yep, they do. Files from BB's Mod Pack don't use naming convention I mentioned in my previous post, so you would need to grab the mod and simply rename files to keep original one (MAN_0XX.SPK, MAN_1XX.SPK, MAN_2XX.SPK, and MAN_3XX.SPK). I already did that... This way you can keep this feature optional - if you want it, then drop files into UFOGRAPH directory, and that it is. I think, some check in the code should do the trick (I'm not a coder though :P).
I'm certainly going to have a look at that Lightning door/ramp problem, to see if it's a problem with our pathfinding too and fix it if it is.
I've been checking this problem with latest git build (I've replaced PLANE.XXX stuff), and it doesn't work. We've tried to solve this problem in original engine, but it's not possible to do without altering crafts/maps/whatever (you can read more here (https://www.strategycore.co.uk/forums/Few-questions-t9437.html)).
Anyway, grab this (https://www.mediafire.com/?ozykcodfsaz2c3p) file. It contains fixed Lightning (original one is broken - you can't open doors at all, and you can shoot/move through the "holes" in walls), and Avenger. No doors for Avenger at the moment, but when "ghost" problem is solved I'll implement them (original frames need to be re-aligned to make doors work properly).
On a side note: I'm glad you've fixed overlapping issue...
(https://img818.imageshack.us/img818/9746/clipboard01vyr.gif)
(top - original engine, bottom - OpenXCom)
Keep up the good work, guys.
-
It was done per pixel. I tested first what color is in that pixel and if is correct I switch it to another one.
-
Personally, I'd love to use original design, and be able to edit/modify/whatever such file (but keep it away from the .exe! :P):
- define gender: F, or M
- define race/look/whatever: 0, or 1, or 7, etc. (pointer to MAN_XXX.SPK file)
- define torso frames: 167-174, etc. (eight frames in XCOM_XX.PCK - default, or custom ones)
- define death frames: 200-202, etc. (right now the same are used for each XCOM_XX.PCK)
This way you can keep sprite customization on really high (and flexible) level, and make bald, long hair, short hair, etc. variations of soldiers, and different variations of armors as well, see here:
(https://img706.imageshack.us/img706/3032/clipboard01uh.jpg)
You could go even further and define legs, and arms too. I know it's only few pixels, but such customization would add a lot of more variety than re-colors only (because you can alter "shape" as well).
Anyway, some more stuff:
- allow to define new weapons look in HANDOB/FLOOROB.PCK (insert new frames and use them).
- allow to define what terrain (and civilians sprites) will be used in terror missions. For example, would be great to play TFTD's port terror maps in coastal cities.
- remove 256 colors limit. Useful when porting TFTD assets - you'll avoid breaking the colors when switching to EU palette.
- add civilians to the farm missions (emptiness is pretty boring over there).
- crazy, but really cool stuff: armed civilians (farm), or police (city), controlled by AI fighting against aliens.
-
How about dividing crafts armament into two categories: Cannons, and Rockets (without any launchers)? Each craft will have "hardpoints" with specified amount, and types of rockets you can mount, for example, Interceptor:
a) 1 x Cannon hardpoint:
- you can't mount any missiles over there.
b) 5 x Missile hardpoint:
- you can't mount any cannons,
- each hardpoint is capable of holding two short range Stingray missiles (up to ten), or one medium Avalanche missile (up to five).
This way you could give unique payload to each craft. For example, Firestorm can't carry medium range missile thus Interceptor wouldn't become obsolete due to medium missile payload (striking targets at long distances - hit and run tactics). Also, player would have more fun with managing crafts - at least me ;)
Sounds great, does it? :P
-
Petition for Extender features:
- reorder soldiers in craft:
(https://www.ufopaedia.org/images/7/75/SoldiersPosition.png)
very nice feature. It allows deploy newbies at first line, while veterans are on back. It worked in Roman Legions well (at least wikipedia says so) :P Player should have an impact of soldiers deployment in craft, I think.
- info that craft has READY status after being rearmed/refueled/repaired:
(https://www.ufopaedia.org/images/7/7d/CraftReady.png)
there's a "launch craft at anytime" option already, but would be really nice to get a message when craft has READY status. This is especially useful when a lot of UFOs is spawning in the same time. Constant clicking on base to get status may be sometimes annoying.
- Range Based Accuracy: already in. But would really nice to specify your own settings. Petition to include Aimed mode (not present in Extender), and visual feedback (this is must have thing for situations, where factor, like distance, have impact on hit chance percentage) too. Also, I do hope Aliens are affected by this as well. Personally I think that cheating AI isn't challenging, but my be frustrating (see night missions).
*signed*
By the way, I've made from scratch helmet-less Power/Flying Suit artworks.
-
Is there a chance to disable ground highlight when units are inside of craft? Seems like items not taken during equip phase cause highlight too :o It doesn't make any sense, and looks really weird. This (https://openxcom.org/forum/index.php?action=dlattach;topic=87.0;attach=138;image) is looking correct.
-
Conti-k, why do you refer to screenshot of early beta of openxcom? Why not original?
-
Conti-K, I had a feature of objects blocking light at a very early beta. At that time the "options" system was not yet in place, so I just abandoned it, I could make it an option again, if there are people that prefere it that way.
(floors blocks light too, so the ground under the skyranger will not be lit by personal lights)
There were actually two things: units turning their personal lighting off during daytime and objects blocking light. (there are values in the object data that can be used for this)
Check this to see how creepy a terror site becomes with objects blocking light: https://www.youtube.com/watch?v=t2ME1IhWFLk
-
Well your Video link sold me :D Better keep it as a option though ::)
-
Conti-k, why do you refer to screenshot of early beta of openxcom? Why not original?
Because this is looking correct :) Right now OpenXcom acts like original in this aspect. Dunno about other floors than crafts floor in OpenXcom, but seems like in original engine it happens as well. It's hard to spot inside of buildings though. But it's easily visible on landing zone example.
Conti-K, I had a feature of objects blocking light at a very early beta. At that time the "options" system was not yet in place, so I just abandoned it, I could make it an option again, if there are people that prefere it that way.
(floors blocks light too, so the ground under the skyranger will not be lit by personal lights)
*petition signed*
units turning their personal lighting off during daytime
Turning personal lighting off would fix breaking ground shadow of the craft by units when walking on the ground during daylight missions, I think.
objects blocking light. (there are values in the object data that can be used for this)
Yep, there's such feature, but original engine seems to ignoring it.
Check this to see how creepy a terror site becomes with objects blocking light
Indeed, looks creepy. Will this break landing zone being revealed to the player? I think that landing zone should stay revealed (including crafts frames), because this part of the map "belongs" to the player, everything else is a big mystery.
-
I remember the "realistic lighting" feature early on, it had its pros but it also had its cons, namely original X-Com's "object blocks light" data isn't fully correct, and it led to a bunch of odd stuff like this:
(https://i6.photobucket.com/albums/y237/supsuper/OpenXcom/openxcom_night.png)
If Daiky wants to bring it back and make it an extra feature that's fine by me, though I'd make it an option off by default.
-
but this look great :D give smoke and rain and we are in Lovecraft movie :D
-
When looking at SupSuper's screenshot I was lil' uncertain this feature, but after some thinking: bring it back! To highlight landing zone in night I'll add small-ish "landing" lights to crafts. Effect should be great. Besides, it's possible to tweak values here, and there - there's a wide range to play with (0-10).
Also, I've been watching that video with turned sound on, and I really liked the music :)
----------------EDIT
I've made a quick test with lights attached to Skyranger's landing gear because this kind of highlight of landing zone does make a perfect sense (of course, light is spreading through all levels because nothing is blocking it right now). This is going to be great feature 8)
-
Yeah, if you enable it, you would need a mod where landing gear emits light - good idea.
Also, I've been watching that video with turned sound on, and I really liked the music
Thanks, it will be part of my sound FX & music pack, to be released somewhere end of this year :p
-
Why ground tile (with non standard "height") overlaps scenery from one side while other is working normally? What's going on? Is there some logic behind it? If not, how about fixing it, because it's looking really ugly :o
-------------EDIT
Of course, I could "fix" the tile, but non standard height tiles that are completely rendered under the scenery (under the walls to be more specific) would be nice to have.
Speaking of that map: I've made a quick visualization of roof that fits with the rest of the building, instead of showing front walls. It's looking much better, much more naturally, I'd say :)
-
There is logic behind it. It's the way how the engine works. Each tile is drawn first floor, then walls, then object. And then to the next tile, drawing the floor, if the floor is not flat, it will draw over the previous tile, then the westwall which will overlap the floortile (it's why you see half of it overlapping by the west walls)
I took over the way of drawing of the original xcom (this glitch is exactly the same as in the original- can show you screenshot if you want) because it was easier as sprites and maps are based on how the engine draws things.
It's probably possible to fix these kind of glitches.... but I don't know a nice way to do it right now.
-
Thanks for explanation, Daiky.
(this glitch is exactly the same as in the original- can show you screenshot if you want)
I know, and that's why I've posted it in suggestions forum :P
I just want to finally enjoy original UFO without any overlapping (only this, and HWP on crafts ramp left), or any lights that highlight through solid floors/walls/whatever because this burns my poor eyes :P
-
It's related to how engine(s) draw things discussion thus I'll attach my post here.
Anyway, today I've noticed another proof that seems to confirm my (newest) theory that OpenXcom draws things like MapView does (except negative "tile y offset" value), which is in two cases different than original engine.
a) Step backward (perhaps it should go to bugs forum? :P ):
Pieces that are raised to 24 voxels (they're sitting in wall slots) are overlapped by tiles level above. Details: there's no tile at the same grid, or "before" it level above. And they should overlap next tile to it, which means tile "after" level above (but it's opposite). I've been testing super-cool-looking cut-off pilot's compartment <==> cargo bay (advanced usage of engine's features ;) ). See attachment (top - OpenXcom/MapView, bottom - original engine). Of course, this should happen with "tile y offset: 24" only, because 24 is another level, but is displayed on level is placed as well, but when switched to level above, visually acts like object placed there (without "shadow casting", only proper drawing order - see original engine). Would be really great to make engine display stuff this way.
b) Step forward:
On a side (brighter) note: I've tried to move ground tiles one pixel down, and since it's not possible via frame editing - 32x40 limit - and that means one pixel less of height thus four pixels(!) would be lost, so I've tried to use "Print Level Adjust" (Tile Y offset) feature... Unfortunately it's possible to move frame down only with MapView (255 value is treated as -1). Both engines treat it as 255 up thus tile isn't visible at all. I thought it's working in similar way as "Terrain Level" (Unit Y offset): 256 - 8 (going up), and 0 + 8 (going down), but it looks like not... So I figured out I'll move walls one pixel up... and shit happened (https://img837.imageshack.us/img837/8345/48704134.gif) (you can see where walls are that are under it) so, I've tested it with OpenXCom (https://img692.imageshack.us/img692/8194/screen004.gif)... Awesome!
Of course, we shouldn't forget about this (step forward):
On a side note: I'm glad you've fixed overlapping issue...
(https://img818.imageshack.us/img818/9746/clipboard01vyr.gif)
(top - original engine, bottom - OpenXCom)
Dunno, to what it's related. Maybe it's Daiky's fix?
----------------------EDIT
By the way, funny side effect of odd HWP's behavior on hilly stuff :o
-
- Add support for excellent Power/Flying Suit inventory images (BB's Mod Pack) (https://www.strategycore.co.uk/files/index.php?dlid=681). Example:
(https://desmond.imageshack.us/Himg214/scaled.php?server=214&filename=inven.gif&res=medium)
For example, if these files exist in UFOGRAPH directory:
MAN_2F0.SPK - MAN_2F3.SPK
MAN_2M0.SPK - MAN_2M3.SPK
MAN_3F0.SPK - MAN_3F3.SPK
MAN_3M0.SPK - MAN_3M3.SPK
engine will use them, instead of MAN_2.SPK and MAN_3.SPK. Default ones could be used in UFOPaedia.
I have one question related to my request... I've noticed this in rulesets:
spriteInv: MAN_0
spriteInv: MAN_1
spriteInv: MAN_2
spriteInv: MAN_3
so I've made such trick to test the stuff:
type: STR_NONE_UC
spriteSheet: XCOM_0.PCK
spriteInv: MAN_0 ==> MAN_2
Then I've added MAN_2F0.SPK, etc. to UFOGRAPH directory, but game crashes... the same happens with MAN_3. But changing MAN_0 ==> MAN_1 works... removing both MAN_2.SPK, and MAN_3.SPK gives an error about missing files... is there somewhere hardcoded the way how inventory artworks work in original engine? Or maybe I'm doing something wrong?
-
You did nothing wrong, just ran into an unimplemented feature. ;) I've added support for the inventory suit sprites now and it should also work with custom ones.
-
Working like a charm, both with default, and helmetless version (if it's present, of course). Thanks for implementing this feature, SS.
-
Will this feature with helmets be implemented? I finds it really cool because in the late game all your operatives look the same.
-
the inventory images are just that: images. for now, openxcom uses the original images, but if you simply replace them with the other ones, it works just as well. so basically there is no need for openxcom to be changed :P
-
It's too pity openxcom still doesn't have moddable easy-editable image resource format, like bmp maps (similar to used in ufotts, including "converter").
-
It's too pity openxcom still doesn't have moddable easy-editable image resource format, like bmp maps (similar to used in ufotts, including "converter").
Whats so hard about modding the original formats?
-
luke83, ugly format, ugly tools, ugly palette. I don't see any problem to go into 320x200x24bit. There are no real commitments to stick to 256 color. It's possible even now.
-
Sooo , how would that affect the whole "Original Game Data" issue. If it used different format , you would then need to supply converted data, wouldn't that be a copyright issue?
-
Original formats for original data.
New format for replacement / new data.
-
if there's no converted sprites/images, it will run converter and create them from original data. if there is converted data already - it will skip converting (exactly for those images which are present), so you will be able to edit them easily without paying much attention on palette limits. Original data still be needed for first conversion and probably some other info like maps/paths.
Which exactly copyright law will be violated if game will be launched without some of original graphics, with "advanced" ones? If it will _require_ for original data (but not really using)?
-
there is no need for an external convertor like ufotts. Just have two different loading routines, depending on extension of the file, like it's already the case with SCR files and SPK files. Just need a BMP loader then. You only need to take care the colors you use in your BMP somewhat match colors that are in the xcom palette, otherwise it will take nearest color. And obviously resolution/size needs to fit too.
-
Daiky, actually I think it will be better to start with getting rid of palette. Internally game should use 24bit sprites (convert 8bit graphics in realtime while loading), and then make alternative loaders for bmp images with no palette things.
-
If its possible to mix and match, would it be possible to borrow UFO2000 custom art?
-
ufo2000 art.. yes sure. why not. though personally i dislike their custom art. it looks like ugly pixel graphics with outlines
-
wow your one hard man to please :P
-
the speech about pics in .LBM type?
LBM - Deluxe Paint Image
I prompt the example editor: Pro Motion v6.5 [trial]
for save to *.LBM pic's https://www.cosmigo.com/promotion/index.php
for modified and save to *.FLI animations or .gif etc. https://www.aseprite.org/
-
oh come on why BMP. Thats no improvement over the original format. Can we use PNG? It's small, widespread, it has a nice losless compression and it supports both transparency and translucency (if we wanted to use it in future). You can also choose how to save the png (what pallete to use), etc.
Also... Someone already mentioned it - there's no reason for converting the original data. I think that it would be best to have folder "original" in the data directory where would be all the original resources. Idea is that any other folders would be displayed in a menu ingame and you could chose if you want to have them active (and presumably the order of loading) so that you could have like more "texture packs" or "sound packs". And if some file isn't in these custom-made folders, it would fall back to the original. What do you think? It might be pesky to implement it, but it would add great and simple extensibility to the game.
-
just to add another discordant voice 8) : I actually like the paletted original approach.
why?
because it keeps the style consistent. the same reason why I like the low resolution graphics. right now, because of the limited palette, you are so limited in what you are able to do that almost anything you do will end up looking similar to the original, whether you want it or not. that's not a bad thing.
I fear that as soon as graphics can be 24bit, they will be, with the highly possible result of turning the game into angry fruit salad.
what I'm trying to say is: I'm not claiming to know any general truths, but it might be that people aren't playing the game despite the retro look, but because of it.
that much being said, I'd say that using .png graphics is probably the best idea :) but I'd still stick with a limited palette (or heavily enforced graphical style guidelines, which is infinitely harder to do :P )
-
radius75, it's not about flis or lbms.
amunak, bmp/tga just because it's easy to write loader even in asm. png requires extra libraries. though it doesn't really matter until it will have alpha channel (there is 32bit tga with alpha).
moriarty, keeping style consistent by cost of limiting art is quite ugly approach. It would be infinitely better to keep style consistent without limiting artists with palette, when you just cannot get colors mixed or toned. Can't you remember luke83's experiments with inventory images, when he had some trouble with gillman toning/shading?
(https://openxcom.org/forum/index.php?action=dlattach;topic=425.0;attach=1745)
I cannot accept point of view such as "limited and slightly ugly is sweet"
-
I agree partly with moriarty that the cartoon look of artwork is a result of using palettes. Artists who draw concept art for a game and need a certain look, use colors from a certain palette.
But they use a limited set of base colors (pencils), not a limited set of shades (how hard or soft you press on a pencil)
So moriarty, you don't need to increase the number of base colors in the xcom palette if you want, but increase the number of shades. This would already give a much better look for gradients on larger surfaces: like the sides of the skyranger.
-
using more shades is probably unneccessary unless we also increase resolution (limited pixels available severly limit the gradient necessity :) ).
and I'd rather not increase resolution, because that makes life for modders a whole lot harder, graphics-wise. right now, because the resolution is so limited, you can leave a whole lot to imagination. as soon as you increase resolution, things will look ugly. it's the uncanny valley in its purest form.
Well, I would like to see xcom in beautiful high resolution, but for that we'd better go and recruit an army of really good artists... :( all examples of high resolution graphics I've seen so far were ugly. I think I'd rather avoid that, stay limited, small and blurry. like super mario. :P
-
True, for that you need an increase in resolution, but it was just saying, that increasing colors doesn't mean the arist HAS to use non-xcom colors.
Look at this xcom palette, where I increased the number of shades from 16 to 256 for the two first colors.
It's up to the artist whether he wants to create fruit salad, or high-res cartoony artwork that still fits the xcom palette, but in 256 shades instead of 16...
I think there is a technique called "cel shading" which is used in modern games and animated movies to create this cartoon look, and one of the things it does, is just reducing the colors to a certain palette :)
-
oh, and if you think you NEED a lot of colors, then play this recent amazing platform game LIMBO ;D
https://darkzero.co.uk/asset/2010/07/Screenshot-9.jpg
-
because it keeps the style consistent. the same reason why I like the low resolution graphics. right now, because of the limited palette, you are so limited in what you are able to do that almost anything you do will end up looking similar to the original, whether you want it or not. that's not a bad thing.
It's neither a good thing. If you want, you can make a mess of the game even with a 4-bit palette. Or you can improve it with smoother gradients with a full (32-bit) or at least 24-bit palette. Since openxcom will probably always (due to the copyright it has to I think?) come without graphics (actually using the "bought original" graphics), this won't be an issue. And then... let the modders do whatever they can.
Well... I see that I'm actually repeating others. NVM.
And speaking of LIMBO.. It might use only shades of white, but I'm pretty sure that they use both alpha and also whole scale (probably 255 colors) as a palette :)
Daiky, nice work on the palette. Maybe we could choose some "basic colors" xcom uses and advise the use of those only? I mean making something like this (https://developer.android.com/design/style/color.html).
-
I honestly think this discussion would be better after TFTD has been fully supported ( Are we going to call that V2.0 ? ).
-
Boy these modding discussions sure keep coming and going. :P Let me clarify the technical hurdles we have to overcome to implement this stuff:
- Support new image formats: Technically this isn't too hard. We just need to add image loaders for different formats and have them properly converted to 8bpp, which SDL can mostly handle on its own. It's just there is currently no easy way to specify those different files to load, the resource manager is pretty hardcoded (just loads some set files at the start) and would need some rewriting.
- Support 24bit: Ok now you have to get rid of palettes too. This sounds simple, just convert old graphics to 24bit right? Except... there's a lot of stuff set up around palettes. Screen background colorization, geoscape/battlescape shading, lots of drawing tricks based around 8bpp and lots of stuff drawn on-the-fly like windows, buttons, etc. Lots of stuff that would need to be either pre-generated or need new drawing solutions in 24bpp while preserving the original look.
- Support higher resolutions: This is probably the hardest. First of all, the engine gets away with a lot because it's all actually drawn at 320x200 and scaled up to whatever resolution, but once you actually need native high resolution, it all starts to chug with the increased workload, due to a messy mix of SDL software rendering, dirty rendering tricks, unoptimized resource management, etc. Second, you then have to figure out how everything is gonna fit on the new resolution, given it's all designed for 320x200. Does the UI just stay at its size centered on the screen? Make it flexible with the resolution and increase the viewport? What about elements that aren't flexible like original sprites (background images), do they just get resized? How does this all mix with new graphics? What about preserving the original look? Etc etc etc. This would pretty much require an overhaul everywhere and is very v1.0+.
So none of this stuff is impossible, it'll just take a long while, but it is planned. Be patient. :)
P.S.
Also... Someone already mentioned it - there's no reason for converting the original data. I think that it would be best to have folder "original" in the data directory where would be all the original resources. Idea is that any other folders would be displayed in a menu ingame and you could chose if you want to have them active (and presumably the order of loading) so that you could have like more "texture packs" or "sound packs". And if some file isn't in these custom-made folders, it would fall back to the original. What do you think? It might be pesky to implement it, but it would add great and simple extensibility to the game.
"Data packs" are the plan for moddability in the future. ;)
-
My comment on "Support 24bit":
Screen background colorization is a palette trick, taken from original xcom. Issue is there are number of screens which have same background, but with slightly different palette. So this will require either number of differently colorized screens, or simple colorizing them while loading (those loading functions anyways will get palette variables, just to get them converted into 24bit). Second is much easier and more "natural".
Geoscape/battlescape shading can be redone, though shading might become different (if there will be simple 24bit lightness control over depalettized 24bit sprites). While geoscape shading probably become more "smooth" and nice, battlescape lighting may become too altered, and probably will require additional tweaking (to keep shaded parts "in-palette") or just depalettizing-on-the-fly.
Interception window probably will require for little tweaking.
Windows/buttons and other "lots of stuff" is not a problem of any kind at all.
-
Windows/buttons and other "lots of stuff" is not a problem of any kind at all.
Well UI also uses lots of tricks like text colorization, inverted buttons, etc. And drawing on-the-fly is a bad approach in the long term since people will wanna replace those elements with their own graphics too, plus pixel manipulation isn't hardware-accelerated.
-
SupSuper, what "long-term" are you talking about, when everything made with SDL and "pixel" approach is not anyhow "long" at all! If we getting everything working like in original, but with some kind of modding, and paying attention mainly on gameplay replication, planning using pixel-SDL in "long term" is quite a silly idea.:) As much as hardware-accelerated SDL :)
-
For what is it worth, i like keeping all the same map formats, graphic types as the original, i dont really want anything Fancy until both xcom games are supported. Just my 2 cents
-
For what is it worth, i like keeping all the same map formats, graphic types as the original, i dont really want anything Fancy until both xcom games are supported. Just my 2 cents
Yes, running the two X-Com games without trouble is the first priority. Others major improvement is welcome but after 1.0
-
Yeah running xcom1 game without any modification. Without new maps or new units or new weapon. The only things allowed - is UI improvements, which make management easier.
-
Volutar , you can already add new maps without any trouble and have RANDOM ufo of a given type, this is why i am mostly focusing my efforts on these points right now. It would be good to sneak in new units OR weapons to increase game variety but no its not a must have before version 1.0 , Mostly we want to know What is planned ( and achievible without coding skills) and is there anyway we can test it?
However it is important to find some sort of balance with the Modders, I can think of nothing worse than writing a program like this and have no-one interested in using it as they can simply play the original in DOSBOX. You still need to provide people with something here that they cant easily do using UFO EXTENDER or any off the alternatives and so far i think Suspuper and Daiky have done a great job giving us things to keep us modders going whilst still keeping the project on the moving towards the main objective.
-
"You can simply play the original in DOSBOX" ... not :p Well, I can't anymore. If you are used to unlimited savegames, better pathfinding, possibility to abort a unit walking, etc... It's hard to go back :) Those for me are the main strengths of openxcom actually. Those things can't be done with UFO Extender.
Modding is nice, but it totally depends on the content that is created. It was possible to do modding for the original game too, but it's never been that popular... People have been able to create xcom maps and sprites already for more than 10 years, you would expect a giant repository of new aliens, maps, objects, but I don't think I can't find more than a handful.
-
Modding for the original game is a Pain because of the MCD limits per map. Also it not easy to have Large sets of maps because it ha set numbers of mapblock sets per type, in Openxcom i can have 10 version of the same "Road" all with slight variations and the result are interesting map variety. Other than those 2 points i am not sure why there is not giant repository of people work and besides the stuff from HOBBES ( which is usually very good quality) , most of the work from others is rather second rate :(
I can tell you so far i have HELPED answer 5 peoples questions directly for how to mod openxcom but so far only one has shown any work, maybe other people cant commit the amount of time required to do these mods, i can easily spend 3 hours on 1 UFO so you can imagine how long a Set takes. My Hope is my websites How To section will create a few more modders as there is very little help files on most of the software available. https://openxcommods.weebly.com/how-to.html
I want to create a completely New version of Xcom one day for the OpenXcom community, new story, new aliens, new UFOs,new weapons, set after Apocalypse...First things first, i need to create a reasonable story ontop of the Xcom universe, learn all the software required to make the art assets ( mostly done), workout what each alien race should look like, work out what human soilders i can recruit ( Human, Sectoid hybrids & Mutants) the biggest problem to my planned mod will be the changes i want to make in Geoscape which will require programs skills ???
Because this "New game" idea is such a big task, i will just work towards it piece by piece, so if i never reach the ultimate goal i still have new items for anyone wanting to add to there normal game ;)
-
luke83: We can still hope for some very nice modding API or something. If LUA/Python are at least considered (https://openxcom.org/forum/index.php/topic,11.msg55.html#msg55), it could mean very easy but complex modding opportunities.
-
gchevallereau already was experimentiong with python scripting:
https://openxcom.org/forum/index.php/topic,360.0.html