OpenXcom Forum
OpenXcom => Fan-Stuff => Topic started by: Zyxpsilon on February 11, 2011, 06:40:03 pm
-
This thread will become a temporary placeholder for some HD graphics development subjects while trying to introduce anyone on concepts (in the reserved posts below) i believe might matter if such a project could ever be tackled or completed *WHEN* a solid final OX 1.0 version is finally released.
I intend to share and contribute as much stuff as possible over the next few months or even, until OpenX-Com has reached its predictable state of pre-release while considering it might provide us an engine where full HD assets can be properly integrated.
For those interested, here's a quick https://forums.galciv2.com/172808 (https://forums.galciv2.com/172808) to "show-off" some on my MOD work in GCII -- if anything, it proves quite well i've been a fan of Gollop's titles for years.
In the meantime... Want a Logo?
See below!
-
Let us begin - at the minimal introduction steps necessary.
I won't be bothering anyone with what most serious X-Com "developers" know already; the files structure & type, available toolset (much of it at either StrategyCore or the usual Wiki for quick inspection or dowload), the basic gameplay elements and a number of other important or completely irrelevant issues.
What i do know is this, though;
-- If someone wants to bother with a total revamping of the graphics by re-sizing, re-sampling, filtering, Alpha-Channeling, 24bits from a sweet low 256 colors in multiple runtime driven palettes and so on... they'll need the proper software and the skills.
-- A reasonable target for a rational attempt *MUST* include a 4x (that's four-fold, right there!) edit of everything - minimum, at least, no compromise, sealed from discussion -- you were warned. ;)
-- The OX-Engine would need to compensate for stack space, memory footprints, routines & functions for IT.
So, to get to the subject of this post.
THEORY #1...
The Blaster Launcher paradox. (Which happened to me... Years ago, btw)
Refer to the image below.
Left-side = Original ... Right-Side = 400%, Bi-Linear, very slight sharpening for temporary clarity ... Proportional samples shown in Red boxes just to realize how big such a change would be introduced to the entire set of files.
The only problem with that processing (as a choice) is the fact that the items are "Encased" into limited width-height ratios and for a vast majority of the work -- some important pixels information can get lost in tight edges as shown by the Red Arrow.
Solution, Alpha Channel and 4 pixels (around, not one, not 5 - FOUR, that's 2 on the LRTB) worth of extra area to re-size the items "framing" for every single images. Background remaining "Black" (at times) to prevent under-shadowing issues in cases. Final product? Keep the Alpha layers since there's HUGE implications for both design and gameplay reasons - more on this later.
Secondly, the map tiles -- they also need plenty of extra re-sampling effects since seemless is a must for such Hi-Res project.
Something to think about while i step further into details in the next post(s).
-
Try better.
-
Wow... superb SVG file. (You should reveal what you used & how you did it!)
I was going to "comment" about acceptable format(s) & quality rendering later on, but since someone seems to be interested into contributing already here's a quick RoadMap for development.
Such a project requires long term dedication and a whole lot of "knowledge" about tricky filtering applications;
1) BiCubic Smoother in Photoshop+ or with any free software alternatives such as Gimp! 2.6? Plugins, etc.
2) Size matters, 4X is a recommendation for most if not all items.
3) Alpha Channel, 24bits and the necessary use of an indirect system for specific palettes processing.
4) Pixelization feel of the original or blurring weirdness that could lead to some off-standard mess?
Just a few simple examples of important considerations before facts & duty by team.
Now, the RoadMap;
1) Hi-Res files.
2) See #1.
Contributions, suggestions, talent, commitments... accepted & encouraged!
;D
-
*Reserved for later use*
-
*Reserved
-
*Reserved
-
*Reserved
-
*Reserved
-
*Reserved
-
*Reserved
-
*Reserved
-
*Reserved
-
*Reserved
-
Reserved for final use too!
This whole first page is entirely dedicated to basic concept.
-
I like that blaster launcher image of volutar. If you can convert them all like that, that would be a great start.
Would be nice to share the method used...
-
If we all get to find out *HOW exactly* he was able to do such a splendid version... i believe there's some seriously good potential in any further results anyone (including me!) would achieve.
The simple but rational limit is to remain as much faithful to the original titles as possible, though.
I prefer SVG (or some tricky acrobatics with PNG_Alpha) re-scaling tricks as well... but, let's not rush out the gate too fast.
EDIT;
After an extensive inspection of his Blaster-Launcher image, i can only conclude it was manually re_edited in great details and in a few key areas. There's absolutely no programmable filters_plugins that can achieve such results -- automatically!
I'd say we could always "TRY BETTER *AND* HARDER" to obtain similar perfection but considering the huge amount of individual files to edit, we'd probably have to work at it for years not weeks or days. ;)
Oh well... there's no easy ways. Patience & dedication.
-
High quality is impossible without manual per-pixel control.
The recipe is - any vector-based zooming tool such as Photozoom or Alien Skin BlowUp or Fractal Zoom + not very much handwork (probably not very accurate or ideal) to add some logical details. Anyways who knows what it should look like when zoomed with more crisp details? It's just an artist work which just should look "neat", not "ideal".
I've spent about 30 minutes on that particular image considering it was my 1st time I ever done this.
There are not so much of them which require such attention.
Writing/translating 600 paged book is much harder.
All pictures could zoomed without any work on detail, so crispness and details could added some other day "on demand" when needed. There is no need to have "final" quality right now.
-
A sharp influx of fresh optimistic air -- indeed! I must admit that you *DO* have pure talent and certainly artistic instinct just by staring at your quicky Blaster work.
I agree that some degree(s) of perfection isn't necessary at this time and given the months of editing we yet have ahead of ourselves, the entire project is a step_by_step affair of reasonable results & optimal quality.
In a sense, i think we're still at the decision stages;
1-- What filtering processes are favorable for any specific categories of images?
2-- How are we to determine some rational re-sizing targets for each?
3-- Will the actual OX_Engine be flexible enough to integrate any work done, even if these would (or should) be "temporary" assets only?
4-- Where do we draw the lines of conceptual features?
I could go on and on, but it's pointless to insist on mythical reasons.
The objective is to work at it, start to finish, whatever comes next, and cross fingers.
In the meantime, i didn't realize some stuff like PhotoZoom and AlienSkin products could offer good alternatives to a whole array of regular plugins (Lanczos, Bi_Linear, Mitchell, B-Spline, ClearIQZ... plenty more) -- thanks for the reminder, Volutar.
We'll just have to see for ourselves. Maybe some magic will stir from collaboration and patience by teamwork.
I certainly hope for the best.
-
First of all I suggest you to look at UFO:TTS 2x images. They've done them pretty nice.
I think it should be possible to share this part of OpenXCom and UFO:TTS projects, since its results going to be the same. To get into mutual aid, so to speak.
Speaking of what you listed.
1 - Nearest neighbor is preferable for further editing, since any filtering will vanish hard borders which are must be in alot of places (my example of fotozoom+editing isn't any perfect). For temporary replacement any filtering is possible.
2 - No need to determine "for each". OpenXCom works with 2x resized graphics already (resized onscreen), and could flawlessly go to 1x but with 640x400 (when all graphics resized internally, like UFO:TTS - their approach is really nice). When all graphics for OpenXCom will be converted into 2x (just via nearest neighbor zooming) and screen mode goes to 640x400, you won't notice any difference.
3 - I don't know what OX_Engine you're talking about :)
4 - Hmm?
SVG (vector) graphics for xcom units isn't really good idea considering it has really crisp pixel-graphics which should stay the same (in sense of all graphics concept). UFO:TTS done this work very nice, BUT, (A) they've done graphics for 2x (that's not bad), (B) not for all (but really a lot of graphics were reworked), and (C) sometimes they've allowed themselves to change graphics of some tiles.
Attached - HEavy Plasma from UFO:TTS and original.
By default they just convert all sprites into BMP 2x scaled version (without any filtering), and when someone make crisp version of any of 2x image - it just applied for project. So game graphics is "crisp" only partly.
-
omg... They certainly did an excellent job for their project. It would simply be a matter of "Copy/Paste" to re-use most of these and call them "ours"... but we shouldn't. In fact, i prefer to resist such quick shortcut to *our* own alternate design(s). Plus, it would be either cheapshot or outright laziness and even if we'd get formal permission to have (limited or otherwise) access to their Art, the results would always simply remain an inspiration from others. Not that it's a bad thing which contradicts intent or liberty of expression.
I claim, we (or anyone else, btw) can do "Better" if we just "Try" - to mimic your earlier remark.
I tend to agree on the fact that the current code has the functions to splash a general (but still proportional) 2X graphic system already. Although, the technicality seem to predict a probable compatibility with new Hi-Res stuff. Thus why i offered you guys & gals the suggested development thread here. Daiky's eMail about his personal HD work (stopped for Battlescape tasks) triggered my reaction, so to speak.
So...
1-- Nearest Neighbor *IS* a filtering process, indirectly. Again, 4X requires up-scale editing of most diagonal gaps in much of the items. It could be 3, 2 - the need for re-drawing remains simply for accuracy reasons.
2-- The point with re_starting from scratch is that it's a HUGE opportunity for some hybrid designs in a number of areas. Examples; Free-camera perspective, Rotating the landscape, Zooms to the battlescape, 4X potential, 3D modeling (or not, btw), Hexagonal grid instead of Isometric "Diamonds" for moving, etc. Decisions will certainly be taken while considering *HOW* selected features can improve 1) Gameplay Fundamentals and 2) The overall experience with Interface & immersion gimmicks by means of specific Art concepts.
3-- Open X-Com procedural approach to the general gameplay model when applied to UI principles & optimal speed for functional assets.
4-- Re-sizing has its inherent limits within any given quality goals. Concept has to compensate for possible features and at the same time, provide for enhancement factors with as many things as possible. The line must be drawn with or at 4X but also for a number of other issues.
I'll delve much deeper into relevant details (for both my intentions & to recommend some tricks) in Reserved posts on Page 1. The next is about Isometric mapping and cursors. Some hints for alternative concepts for the bottom Panel(s), Side-Bars, Fonts, & Equipment screens, etc... within the post(s) immediately after.
Is 4X absolutely necessary -now- at this stage? Sure, it isn't. But i'm fast forwarding to include provisions while thinking about solutions for better results. Strict? Naaaaa. I'm all open & willing for subjective & abstract reasoning from anybody. Essentially - we'll do some Artwork, progressively. Within a plan of actions rather than "talks". While being entirely (team wise) focused on multi-tasking & explanations (If need be!) included.
PS; Perspective rendering (if kept under a tight grasp with some PNG Alphas & complex shadow tricks) opens up incredible control over Interface & Sprites. Even right now (battlescape, maps, etc) the OX code *can* tilt the environment in any 4 cardinal directions rather easily... the infra-structure is there, the images are already PCK'ed. Free-camera panning on the other hand (with 4X elements) would create an even greater scope.
-
Sprites can be draw in higher res pixel by pixel:
https://www.youtube.com/watch?v=wnxXF79ffKk
https://www.youtube.com/watch?v=p-mkQ4XK4qM
-
Oh, yeah... i've seen some projects similar to these "Tasking examples" with Sprites editing back in the late 90's. Nintendo's Animes were a real fag back then! :) Yoshi under Mario, Manga, Transformers. The consoles market scooped upwards in a turmoil.
Through deductive flow, any good artist_animator can obtain superb results when given relative amounts of skills & talent... sprinkle Patience & dedication and you got potential. I'm not claiming i'm the best either... gee, we may yet get lucky in finding a precious jewel of a developer willing to participate in our quest for Hi-Res (transitional or final, btw) files. TTS got some, so should we.
That's not a pure competition in my mind.
More like an end to the means and vice-versa.
There are still a few shaded areas about supsuper's intentions (after all, it's HIS baby code - he can decide whatever he must!) -- but if we (as outsiders) step back a little to observe, the huge opportunity (previously mentioned) for additional features is certainly within our grasp.
Examples...
-- External Modular algorithmic AIs such as what was achieved by Steffen Gerlach's https://c-evo.org/text.html (https://c-evo.org/text.html).
-- Perspective rendering... where do you want your Sun Rays at Zenith or nightly Moon misty glows? Eye sight, shadows, Reality, 3D, the works.
-- Seb's extender stuff.
-- Heck a whole array of supplemental assets by Modders (Bomb Bloke Uniforms!) that already showed up over the years.
The mechanics, infrastucture, dataset, ruleset already exist and are just waiting for a hell_of_a_ride by somebody.
I'm IN. You bet.
PS; Can anyone here contact Daishiva so that his MapView, PCKView & XCView tiny (but essential) editing programs are uploaded as working Win-7 executables at the usual SourceForge spot? Cuz, i still get the darn Green palette + the header bytes (PPI) flaws on saves and i don't own a 1500$+ MS_VB compiler to use what he has done since - it seems - forever!
PS2; Related... if i could do this for some GCII 160x160 query boxes back in '09 -- i can certainly try my hands at OX stuff too!
PS3; And finally... a reference (https://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms (https://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms)) about what good filtering tricks can do to any Sprites. Anybody has runtime versions for any of these? I could even try suffering through some bat command_line weirdness if i must.
-
Zyxpsilon,
first of all, do you talk this much in real life to, or just on forums ;D No offense, everyone their own style ;)
PS; Can anyone here contact Daishiva so that his MapView, PCKView & XCView tiny (but essential) editing programs are uploaded as working Win-7 executables at the usual SourceForge spot? Cuz, i still get the darn Green palette + the header bytes (PPI) flaws on saves and i don't own a 1500$+ MS_VB compiler to use what he has done since - it seems - forever!
During the little chat I had with Daishiva, he basically told me that he'd probably never touches these tools anymore. It's all uploaded on SF, but that's it. If you want changes/fixes you download it and compile it, which I did. You can do that with the Free MS Visual Studio, it's in C#. I have no issues with it in Win7 concerning the palettes.
PS3; And finally... a reference (https://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms (https://en.wikipedia.org/wiki/Pixel_art_scaling_algorithms)) about what good filtering tricks can do to any Sprites. Anybody has runtime versions for any of these? I could even try suffering through some bat command_line weirdness if i must.
Actually you find links to the runtime versions on that same wiki page. I've used that hq3x.exe before and works fine.
-
PS; Can anyone here contact Daishiva so that his MapView, PCKView & XCView tiny (but essential) editing programs are uploaded as working Win-7 executables at the usual SourceForge spot? Cuz, i still get the darn Green palette + the header bytes (PPI) flaws on saves and i don't own a 1500$+ MS_VB compiler to use what he has done since - it seems - forever!
I lurk here, so getting in contact is easy!
Yeah, I haven't done anything with that codebase for a long time. I also dont have windows7, but if you know what the problem is, we should be able to fix it, even if I have to send you executables to test out. Send me a PM or something
-
Zyxpsilon,
first of all,...
Yes to both!
2) MS-VB_C#... is all good an nice. IIRC, i used to fiddle a bit with VBX5 when trying to create a GCII tech-tree "app" for myself once but never got around much with the essentials. Too busy with everything else maybe. But as long as you *do* have some working (already) compiled versions, would it be too much to ask for a favor; zip it all up and join the resulting exes in an attachment below! Unless...
3) Well, since Daishiva himself just showed up -- there might be another way.
Thanks, i'm simply somehow curious at this stage and must re-immerse myself into some things & available toolsets i've "worked" on in the past.
-
I lurk here, so getting in contact is easy!
Yeah, I haven't done anything with that codebase for a long time. I also dont have windows7, but if you know what the problem is, we should be able to fix it, even if I have to send you executables to test out. Send me a PM or something
Didn't realize you were actually here often!
First, many thanks for those early rides i had with your great tiny tools.
Secondly...
Converting BASEBITS with your PCKView (which i had to run in a compatible Win98mode under W7_Aero to allow it to boot_run without crashing), i obtain the attached file when using the necessary ufo-battle palette. Any resizing attempts with PSPro-X3 locks the process into a "Parameter out of range" warning box. Once IrfanView is used to insert values (200, proper?) in the DPI fields and re-saved -- re-sizing (or filtering, edits, etc) is okay as expected. I can deal with the compatibility "mode" but i guess some palettes are either "wrong" when rendering the files or the internal game-engine itself actually requires the "green" indexes at runtime. The Skyranger & Hangar (etc) aren't green on the UI, though.
Mostly all others PCK, react the same way (DPI missing) after being "converted" with XCView. Example with the UP001 UfoPedia entry, below. Which also has some strange "Blue" artifacts in places and is being saved as 0x7 DPI figures.
(oooppps, A thought... maybe it's the original UFOD copy i'm using for such conversions (pure 3 floppy disks back in 94!) -- these files may differ than all other versions that crawled over the web.. Gold, CE, STEAM, etc. I even bought the extra "Complete" set from Impulse a few weeks ago.)
Thirdly, if you have (or will fix) these executables... eMail them to me - fire away, please. I must do some extensive test_edit_work on thousands of images and without such tools -- it won't be possible.
PS; The CoreBrain & AquaPlastics GCII queries (and plenty more!) inserted above were created with *your* MapView program and a *lot* of patience with alternate settings, btw. ;)
-
I filled in the dpi fields, hopefully that will fix the issues with your other programs
https://www.daishiva.com/other/bin.zip
the basebits does show up green on my computer. Looks exactly the same on my pckview as the bmp you put in the zip file.
The blue artifacts that you see may be a palette entry that I hardcoded wrong, it doesnt read the palettes from the ufo data folder (maybe it should!)
Let me know how it goes
-
Let me know how it goes
I'll do that and many thanks for the quick BIN re_compile.
The weird "greeny" flaw is strange but not so much of a priority, AFAIC.
EDIT (Back with some comments after a swift run);
-- PckView is now compatible with Win7Aero, smoothly operating as expected. The palettes are still acting weirdly with the usual Greens, but there's a very simple workaround once these files are extracted; Load any valid *.PAL(s) as necessary and re-save in PSPro-X3.
-- 76 DPI is working as well. I've seen 72's everywhere in other progs, but i think it doesn't matter that much for file EXIFs of BMP copies. Except for the proper saves formatting, of course.
-- I was pleasantly surprised by a few new options (Compare, Save to Directory, HQ2x..) which have potential for some later iterations, i'm guessing. Up to you, but might as well consider adding HQ3 & 4 (maybe Lanczos & Bi_Linear) while you're there, no?
-- Saw you've also included a newest copy of MapView. Note that someone at StrategyCore (Zombie) altered v1.1 to fix the extra AlienShips back in '08.
-- The only remaining fact would be that a more recent XCView is "missing" and could be fixed (DLL, pal references) if you want.
The complete package would become absolutely essential for anyone willing to tackle a complete graphics re-editing.
-
I am sorry to break the spirit.
This is going nowhere except one route is taken:
It is illegal to derive those high-res pictures from the original files and distribute them. End of the story. There is only black and white here, no gray areas. Instead of a long and boring talk about licenses and redistributing here the solution:
Whatever you do, it must result in a set of (automated) steps, instructions and commands so that open xcom can create the high-res version from the normal data. Or in other words: Like everything else in OpenXcom the graphics, in any form, must be interpreted.
This does not mean you have to rely purely on automated steps and filters. If this is the desired outcome, ok. But even if manual editing is needed you must find a way to create a diff and patch, in progammers-speak, and apply these to the original data.
Summary:
Every step that leads to the final version of the graphics must be done by a program or predefined instruction, based on the original data files.
-
Dunno if you've actually read the exact opinions of the main coder for this tiny little jewel of a completely fresh RE_compiling of equivalent gameplay that OpenX-Com is... but there is Legality & then, there is Justice itself.
-- The original X-Com:UFO Defense title that i bought fair&square with cold hard ca$h back in July 1994 from a)Microprose as its distributor and b)Gollop_Mythos_Gang has -like every binary driven products ever sold- an EULA licensing gimmick attached.
-- Reading through this complex but pretty straight forward Legal text allows for specific usage & undeniable Rights that nobody on Earth can enforce, limit (expressively or otherwise), provide in different manners or terms, or deny (by DRM, spywaring, Ping looping at Networking levels, etc) anywhere on Earth no matter how hard they'd try.
-- As consumers we have the RIGHT to use & enjoy the products we purchased. It's a one way deal. I buy the Hot-Dog, i eat the Food. Somebody cooked it and was paid for the edible device. Offer/Demand.. Capitalist economy. The equation is a loop.
-- Comes Judge Dread and Lawyer X whom claims they can get a cut throat part of the proverbial pie(s). Only problem, the transaction has already been resolved for the good of two sides; Code boxed & code now runs on a PC. There's nothing in-between. Ziltch, nada, the void.
-- Art is a process... kept or sold.
They can all come and sue me. I paid already. A whole bunch for *some* Rights.
In the meantime, let us enjoy our creativity trips and if you claim we're being criminals for it, call the Police and send them right here to my door steps. I've got some news for the Cops, too.
Cuz, Honesty is a two-way street.
-
EDIT (Back with some comments after a swift run);
-- PckView is now compatible with Win7Aero, smoothly operating as expected. The palettes are still acting weirdly with the usual Greens, but there's a very simple workaround once these files are extracted; Load any valid *.PAL(s) as necessary and re-save in PSPro-X3.
-- 76 DPI is working as well. I've seen 72's everywhere in other progs, but i think it doesn't matter that much for file EXIFs of BMP copies. Except for the proper saves formatting, of course.
-- I was pleasantly surprised by a few new options (Compare, Save to Directory, HQ2x..) which have potential for some later iterations, i'm guessing. Up to you, but might as well consider adding HQ3 & 4 (maybe Lanczos & Bi_Linear) while you're there, no?
-- Saw you've also included a newest copy of MapView. Note that someone at StrategyCore (Zombie) altered v1.1 to fix the extra AlienShips back in '08.
-- The only remaining fact would be that a more recent XCView is "missing" and could be fixed (DLL, pal references) if you want.
The complete package would become absolutely essential for anyone willing to tackle a complete graphics re-editing.
I suspect the binaries that are downloaded off of sourceforge are some old version that is not the latest. I will have to update those.
the dpi value I dont know what its supposed to be. If you want it to be 72 I can make it that way. I entered '3000' instead of '0' and it comes out to 76. As long as the file works i dont think it matters much more than that.
The options have been in the sources for years. I found my .net wrapper for the hq2x code thats something like five years old. adding more hqx options would be trivial.
Everything needs to be updated, sure, but at the same time there is no motivation to work on it if noone is using it =)
-
I suspect the binaries that are downloaded off of sourceforge are some old version that is not the latest. I will have to update those.
Everything needs to be updated, sure, but at the same time there is no motivation to work on it if noone is using it =)
It's alright... IIRC, the sourceforge files are only picked from the whole SLN folders (of XCSuite 1.0) but there's no executables (binaries) overthere. They might be old, you should know it's your code! :) (((Oooppps, found the BIN file too! Sorry.)))
Well... at least one (me!) instead of noone. ;)
I suspect a few more people might eventually require something to work with... up to you. If anything BombBloke's BB_tact command_line bats (outputs GIFs only) could serve as temporary alternative for anyone willing enough.
So far, the actual brand new stuff you gave above is perfectly fine. I'd enjoy having XCView too but again, you decide.
Thanks a bunch anyway 8) as i really appreciate the time you took to re-compile the latest versions.
EDIT; I forgot to attach this zip of palettes for anyone to examine... since, it essentially provides easy (or useful) ways to "inspect" Interface assets & code functions effects directly on the Battlescape/Geoscape (for both UFOD & TFTD, btw) screens at runtime.
-
Ok I'm usually pretty passive and approving around the forums, but I think I need to clear some things up here for Zyxpsilon and anyone else reading this thread:
- High-resolution graphics are a great endeavor and I always like seeing brand new takes on X-Com art. However to everyone involved, keep in mind that OpenXcom will not be supporting high-res graphics any time soon. It's not as simple as just "replacing the graphics" or "switching to 24-bit PNG" or whatever. It's not up for discussion. Once all the core gameplay is done and OpenXcom is fully functional and playable (v1.0), then we will look into such engine upgrades.
- Zyxpsilon, I get that you're full of enthusiasm and really excited about this, but keep in mind this is a "fan work", and OpenXcom developers are in no way directly involved and/or affiliated with this. So to avoid confusing people, please don't use words like "official" and the like in your posts (eg. "This thread will become the Official placeholder for all HD graphics development subjects." in your first post). I'll let you correct this yourself instead of editing your posts like some censor.
- Likewise, stuff like reserving a whole page of posts feels very ambitious and might intimidate any newcomers who wanna join in, so you might wanna tone it down a bit.
- Finally, legality issues are a very grey area, so I won't get into it. Nobody but an actual professional lawyer could clear the matter up. Even OpenXcom's legality is probably dubious, despite all efforts to keep it as clean and original as possible. In any case, anything that comes from this is purely the author's responsibility, so I'd appreciate it if everyone just used common sense and try not to step on anyone's toes, and not get into big ugly fights over what is right and what is wrong either. I expect everyone here to be mature people and behave as such.
With that out of the way, keep up the good work. :)
Everything needs to be updated, sure, but at the same time there is no motivation to work on it if noone is using it =)
I sure hope people will use OpenXcom then! ;)
-
That solves most issues i've had since discovering this project and subsequently these forums.
Don't worry, i'll fix whatever you asked for and stay (as an active participant) here without overstepping any rational "limits" (own or driven by common sense from anyone!) of intervention.
Sorry about this whole mess but i *DO* have a long way to go to still "dream over" superb Hi-Res graphics (4X) for OX.. Okay?
Fact is.. TTS has some great stuff already to wet my appetite. That is until your probable formidable features see the light of days to come.
Any more technical details i'd wish to learn about, i'll simply keep track of your progress.
Gotcha! :-\
-
So far, the actual brand new stuff you gave above is perfectly fine. I'd enjoy having XCView too but again, you decide.
Does it do anything differently than what your have in that archive? I believe XCView is just a renamed version of pckview (I wasnt using source control way back then, /shame on me)
-
XCView (as an indirect "Background Viewer" for some tricky versions) can load all of these files;
TFTD(BDY),
X-Com (SCR) + X-Com Large (PCK)...from UFOGRAPH folder + UFO (SPK),
8bit (BMP),
and allows to Save Palette Stripes & Bars, etc.
While PCKView simply can't for most.
PS; The only difference i could detect from your internal palettes (having the Suite source) is that index #255 has many variable values while it's always pure maximum white on "Regular" valid defaults. Thus, it could be the saving routine_function which introduces the "Green" flaws on (BASEBITS & some others) BMP result files.
-
XCView (as an indirect "Background Viewer" for some tricky versions) can load all of these files;
TFTD(BDY),
X-Com (SCR) + X-Com Large (PCK)...from UFOGRAPH folder + UFO (SPK),
8bit (BMP),
The PCKview version on Sourceforge can open all those formats (maybe it should have a different name :P), although not as intuitively as XCView. To open SCR/DAT image files you need to open the file with *.*, then on the window that pops up select Uncompressed Image and specify the size (SCR images are 320x200).
There are a bunch of issues with the program, but now knowing it's open-source, I feel guilty about reporting them instead of just fixing them myself. :P
-
XCView (as an indirect "Background Viewer" for some tricky versions) can load all of these files;
TFTD(BDY),
X-Com (SCR) + X-Com Large (PCK)...from UFOGRAPH folder + UFO (SPK),
8bit (BMP),
The PCKview version on Sourceforge can open all those formats (maybe it should have a different name :P), although not as intuitively as XCView. To open SCR/DAT image files you need to open the file with *.*, then on the window that pops up select Uncompressed Image and specify the size (SCR images are 320x200).
There are a bunch of issues with the program, but now knowing it's open-source, I feel guilty about reporting them instead of just fixing them myself. :P
Please do report them! not saying anything gives the impression that:
a) everything is working fine
or
b) noone uses it
-
Oh well... i just tried PCKView to loadup some SCR (etc) using the "Uncompressed Routine" and it does - except the files are off-shoot by 75% to the left-side corner, making any of them completely unusable. I suspect most others will react the same.
So, i'll stick with the very old XCView i have and perform a few edits afterward should i need to -- unless, the man wants to compile a new version.
Daishiva,
Btw, speaking of compiling new stuff;
Would it be tooooooo much work to try integrating *all* APOC related PCKs, MAPs (etc) as well while you'd be considering it?
The REST; Cuz, lemme tell you - if it were just me... there would be a highly complex new code_program which certainly could mix-match all three major core titles into a single hell_of_a_ride of absolute Ground_Oceanic_Inter-Dimensional X-Com gameplay fest with all Alien races at once in any five Mega-Primus city-maps, T'leth (Mexican Gulf) and_or Cydonia (On Mars) through options or by default.
I'd even risk a reference to the absolute master of squad_level TBS style... Laser_Squad_Nemesis (to be fair to Gollop genius consistant work). But this might have to wait for a Gaming Industry revolution that excludes the likes of EA, Activision or whomever else has been tracking the X-Com license for quick profits.
Now, *THAT'S* a project worth killing for.
-
Oh well... i just tried PCKView to loadup some SCR (etc) using the "Uncompressed Routine" and it does - except the files are off-shoot by 75% to the left-side corner, making any of them completely unusable. I suspect most others will react the same.
So, i'll stick with the very old XCView i have and perform a few edits afterward should i need to -- unless, the man wants to compile a new version.
Daishiva,
Btw, speaking of compiling new stuff;
Would it be tooooooo much work to try integrating *all* APOC related PCKs, MAPs (etc) as well while you'd be considering it?
The REST; Cuz, lemme tell you - if it were just me... there would be a highly complex new code_program which certainly could mix-match all three major core titles into a single hell_of_a_ride of absolute Ground_Oceanic_Inter-Dimensional X-Com gameplay fest with all Alien races at once in any five Mega-Primus city-maps, T'leth (Mexican Gulf) and_or Cydonia (On Mars) through options or by default.
I'd even risk a reference to the absolute master of squad_level TBS style... Laser_Squad_Nemesis (to be fair to Gollop genius consistant work). But this might have to wait for a Gaming Industry revolution that excludes the likes of EA, Activision or whomever else has been tracking the X-Com license for quick profits.
Now, *THAT'S* a project worth killing for.
ah yeah, the SCR loading is not intuitive. I just tried it out and was thinking 'wtf, this is awful'
If you save the profile, give it a description, then it will show up in the open file dialog and the SCR's will open up fine. they DO NOT look fine in the preview window. I shall have to fix that
I have APOC somewhere around here. Not sure if i can find my cd after all these years. I will have to look
-
Alright then, good news -- do whatever you think might be necessary!
I always liked the TFTD GeoBord.SCR Globe/Arrows "feel"... so i've used XCView to reload some edited bmp, resaved as SCR.
Works just fine, too!
-
There are a bunch of issues with the program, but now knowing it's open-source, I feel guilty about reporting them instead of just fixing them myself. :P
Please do report them! not saying anything gives the impression that:
a) everything is working fine
or
b) noone uses it
Well I might use it if it beats writing my own solutions for tweaking the original resources for OpenXcom. :P And I imagine others might too.
Some issues I remember in PckView (based on the SF download):
- There's 5 UFO palettes (https://www.ufopaedia.org/index.php?title=PALETTES.DAT) but PckView only has 4 (base and battlescape palettes are pretty similar but not the same), dunno about TFTD.
- Loading files through a custom profile doesn't automatically select the palette specified by the profile.
- Loading uncompressed images is limited to 1000x1000 (and resources like game fonts are bigger than that).
-
Speaking of Fonts...
Shouldn't they be considered for some tuning as well, since a few letters aren't exactly "readable" at times (G vs C, etc)?
I don't mind keeping the approximate "Pixel_cornerings" effect (cuz it basicly identifies the stock X-Com titles design), but since they are somehow limited in numbers, we could add some extra characters slots (above the current 33_160 ASCII range that is) and use those for additional features to text fields. Units tags, swift mini_icons, slick but indirect "Animated gifs", maybe some Dingbats thrown in if obvious.
Even a sort of indirect TTF function could be integrated to allow for much more Interface control.
Re-sizing assets is one thing, having a coherent "product" another.
Thus, more smooth Fonts.
-
Any X-Com resources are up for improvement, that includes the fonts. Though they will be expanded from the default ASCII range to Unicode (not the full range obviously) for localization reasons, so there probably won't be room for "custom symbols". There's a TTF library for SDL too but that's probably very v1.0+.
-
So DaiShiva, anything new about XCView?
-
Nothing currently. The one thing I'm looking into is how Paint.net does its sticky tool windows. I'd like to make the interface like that.