Hi-Resolution Interface & Sprites...

[Daiky]

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...

[Zyxpsilon]

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.

[Volutar]

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.

[Zyxpsilon]

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.

[Volutar]

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.

[Zyxpsilon]

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.

[michal]

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

[Zyxpsilon]

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.
-- 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) 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.

[Daiky]

Zyxpsilon,
first of all, do you talk this much in real life to, or just on forums  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) 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.

[DaiShiva]

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]

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.

[Zyxpsilon]

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.

[DaiShiva]

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

[Zyxpsilon]

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.

[anonilsus]

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.