forum.defence-force.org

I nearly finished adapting PictConv to the latest version of FreeImage.

The most interesting thing will be the support of more types of pictures, including GIF

The second thing, is that FreeImage is now open source, and multi plateform, so this means I will be able to do a native version under Linux and MacOS.

My idea of a perfect Pictconv would be a whole bigger boardgame..

My big problem with pictconv is the ease of access to its powerful facilities.
Having the ability to capture and convert jpg's, gif's, png's, etc. of different sizes and aswell as generating source files or taps is also able to display the physical oric dimensions of the parsed image.
Ability to drop images whose width is not a multiple of 6 in that the program would increase the physical size to accomodate the conversion.

Having the ability to drag/drop an image would be enormously beneficial.
Particularly dragging many images from different places, which could then be converted and compiled in a single .byt source or tap file.
Having the option to autogenerate 6 shifted frames - This would be so useful for creating sprites.

I still use Symoons PCHIRES for quick conversions of images, even though its facilities are now a little outdated, its just alot easier than going to dos and trying to figure out the switches to use to convert a black and white image to the oric.

I can understand both points of view, but I must say that Dbug's idea about having tools that can be used from command line is the way to go.

I am using pictconv in both ways, and I find it *vital* to be able to invoke it from my own scripts and programs. That is how I can generate all the sources for the tiles in Space:1999. I have a world compiler which takes the tile list and generates the appropriate .s files with graphic data and needed structures for the game, among other things, each time I want to build from the sources.

On the other hand characters and other graphics are generated by hand, and here is where I would benefit from having a good graphic tool. Having some kind of paint program which could import graphics, edit them and simulate the oric screen (such as HIDE does, but within Windows) would be perfect for designing.

But that can be done as a separate tool, which can use pictconv and other programs to work as a kind of frontend.

Just my 2 cents

Cheers.

Yes, I prefer the approach of having a command line based utility that can be called from a graphical shell if necessary.

Some time ago Twilighte actually started coding a "shell" for PictConv, all he need to do is to basically use PictConv with the mode that outputs a PC picture as a result (in the Temp folder for example), so the user can test the parameters, and when happy can generate real data.

Damn you human for reminding me, so now its my fault again.. hahaha
Oh well i guess i should blame myself for not finishing projects.
Ok, i have absorbed both points of view and now agree with Chema/Dbug.
Can someone lend me 5 months to finish some projects please?

Well, I will not reject any blame on any one, it's not like if I had been able to do anything remotely useful (on oric side) in the few last month.

Chema wrote:Having some kind of paint program which could import graphics, edit them and simulate the oric screen (such as HIDE does, but within Windows) would be perfect for designing.

Did such a tool ever get produced?

I'm trying to play with some graphics to see what I can achieve, but none of the PC paint programs simulate the odd colour attribute system of the Oric, and the 6x8 character system is at best a bodge with grids.

I'd use HIDE, but Euphoric doesn't like my Windows 7 netbook and Oricutron doesn't support any saving. I don't just want to do a screen grab, I want to retain and be able to edit it in an Oric style.

Antiriad2097 wrote:Oricutron doesn't support any saving.

This will not be a problem for much longer

ok
i'll stop working on my poor own win edit oricgraph

thanks chema

coco.oric wrote:ok
i'll stop working on my poor own win edit oricgraph

Oh no... It would be invaluable to have a windows based editor... I love HIDE, but certainly having mouse support and enhanced cut&paste and other features would be really nice

thanks chema

me? why? I guess you meant Xeron

Hi everyone.
Is there any progress in development of PC GUI utility which can load and convert PC graphics to Oric 240x200x8 images?

peacer wrote:Hi everyone.
Is there any progress in development of PC GUI utility which can load and convert PC graphics to Oric 240x200x8 images?

Can't really say there was an active development, but I started such a thing last year.
The real problem is that conceptually you have to edit the picture, fix the pixels, etc... until the picture works. It means almost writing a complete paint program.

An utility called libpipi / "Pimp" does a great job
http://caca.zoy.org/wiki/libpipi/oric

This libpipi utility might be a start point. It does load any size and colour pictures in jpg, png, gif files and convert into 240x200 coloured tap file. It can even load Oric .tap hires image files

But it is really primitive and does not allow any parameter in pictconv conversion like dithering options etc.

This would be great if the program shows the resulting hires page in selected parameters. After that, using PC mouse capabilities, correction of wrongly converted pixels would be great.

Such an utility would be excellent for future Oric projects. I have many ideas in mind but graphic creation is always a problem under Oric emulation enviroment.

I don't have PC-windows programming skills much except a little primitive visual basic programming. But I can help in any way that I could for such an utility.

Is there anyone willing for this?

I was tempted to start something like that several times. It should be something like HIDE but running on windows, with mouse support.

Never went beside the initial idea, though. As Dbug said it would be like writing a complete new paint program with some sort of support for emulating the Oric display, with at least a secondary panel for editing individual pixels and attributes.

Not really complicated, but also not easy...

I'd do it in SDL, pure and simple, and that way it won't only be Windows-based. Or, if not SDL, them something at least portable across platforms.