[Ja2 Settings]
VFS_CONFIG_INI = vfs_config.RII.ini

• Download the file [http://www.turboupload.com/files/get/ph9Aii8Ine/ja2-rii-alpha-v1.7z] and copy it to the other ja2 binaries.
• Open ja2.ini and insert the following lines at the end of the file
  

  [RII]
  #WIDTH = your preferred window width
  #HEIGHT = your preferred window height
  #for example
  WIDTH = 1440
  HEIGHT = 960 

  
  This defines the "outer" or the window resolution. The old resolution selection (0=640x480, 1=800x600, 2=1024x768) determines the size of ingame interface image sizes (as it did before too). Defining an outer resolution smaller than the inner resolution can (but doesn't have to) result in a crash, so be warned.
  
• play the game
• have fun
• report bugs

Is it usable for UB and associated mods ?

just played on 1680x1050 and no problems except misaligned images in strategic and tactical view but that's normal at this stage.
if this project is gonna catch on i'm gonna be forced to buy some glasses, i can't read it at this resolution...

Would a High resolution interface be a preferred replacement? I'm sure I could come up with something to solve that issue. Also a new font pack to go with it so you might save some money of glasses?

Would a High resolution interface be a preferred replacement? I'm sure I could come up with something to solve that issue. Also a new font pack to go with it so you might save some money of glasses?

if it can be made to run 1024 x 768 , THAT would be ......... ok \:\)

... images ...

As for the High Resolution interface I was going to make a 1600x1200 one up and if you can resize it then you just reduce the size of the high res images rather than increase the size of small ones. Dunno if its possible. I was gonna do fonts too (otherwise it would look a tad odd) but unless it could be implemented I was a little hesitant to start on it. If you can manage it then by all means let me know and I'll have a crack at it.

Looking forward to it mate

Can this RII resize larger images down to smaller ones? AA may be necessary for good results though.

If I can do what I have in mind I think it may be liked.

The basic idea was to have a set of High Res files that can be resized down in their native size (so one set for widescreen and one for normal). This is for resolutions higher than the ones already ingame.

The thing with the resizing is to get the grids to be in the same position so maybe having an alpha layer with grid locations that can resize too (the code looks to the positioning of the alpha layer grid which isn't visible to the player).

When you resize down it can work relatively well if the resize isn't that large (say 1600x1200 down to 1280x960).

 0.5 * value(P1) + 0.5 * value(P1), value(P1)=10, value(P2)=17
       LightRed          DarkRed

 = 27/2 = 13.5 = 13

but it would have been nice to just make some really good Hi-Res stuff and reduce the size ingame (like done with most game interfaces now).

Oh and if you could remove the overlap from the different STI's from the current interfaces that would be helpful as currently there is overlap that make's integrated camo and other effects really hard to line up.

When we compute rgb values first and then interpolate then, the result may be a color that was not in the palette before. And if we are unlucky we get a new color for every new pixel and eventually run out of free places in the palette (if there were any at all).

BirdFlu

When we compute rgb values first and then interpolate then, the result may be a color that was not in the palette before. And if we are unlucky we get a new color for every new pixel and eventually run out of free places in the palette (if there were any at all).

Only the images in the data files are paletted. For display 16bpp Highcolour is used.

Well, if my memory doesn't fail me, we have 16bpp buffers (FRAME_BUFFER and guiSAVEBUFFER, or so) and the paletted images are blitted directly into these buffers by going over the lines of the image, applying the palette on the index values and writing the resulting color value into the buffer.

Only the images in the data files are paletted. For display 16bpp Highcolour is used.

That's how you translate indexed image data to direct colour. What's your point?

Oh. My intention was actually to say that resizing of paletted images could be hard. Once it is done, blending can indeed be easy. But, as there is no real alpha value in the images and in the 16bpp buffer, real alpha blending could be a little problematic. You can always take an alpha value of 0.5, though.

And since you are here anyway. Lets assume someone wants to replace the original window with a SDL window. How much work would that be? How many files would that change affect? Would it be only the file sgp.cpp where the window is created, or would it also affect Event processing too? I guess the HVOBJECT creation and handling code would have to touched too.

But the blitters could stay as they are, right?

I replaced the code of all (used) blitters, which were written in inline assembler as understood by MSC, by implementations in plain C. Lesh used this very code - a few thousand lines of code - to make his Linux version work.

[...] i already tried to copy Leshs blitters [...]

So, i guess, my actual question was whether the replacement of inline assembler code with C code was done only for portability or also because of other reasons?

To rephrase my question, can a transition to SDL be done for every single module (first window, then event handling, then sound, etc.) separately or does it has to happen at once?

I just mentioned alpha blending as example, which is already there and uses paletted input data (actually one paletted pixel + one direct colour pixel get blended), but produces direct colour as result. Colour interpolation for resizing uses pretty much the same calculations as alpha blending.

Lesh used this very code - a few thousand lines of code - to make his Linux version work.

BirdFlu

[...] i already tried to copy Leshs blitters [...]

I have to be a bit pedantic here: I wrote the C implementations of the blitters, not Lesh. He merely copied them for his JA2-1.13 Linux port.

As I mentioned earlier, you can see how all this was solved in JA2-Stracciatella and use it as basis.

For me as a gfx artist does this mean I can make 16bpp images and use them ingame? Does it allow for transparency? Or is 24bpp needed for that?

Tron

I just mentioned alpha blending as example, which is already there and uses paletted input data (actually one paletted pixel + one direct colour pixel get blended), but produces direct colour as result. Colour interpolation for resizing uses pretty much the same calculations as alpha blending.

I will stay by my statement that blending and resizing are essentially different. You can implement it so that they look similar, but the essential operations do not overlap.

The essence of blending is being able to read a WRITE buffer, that is read a pixel from the WRITE or FRAME buffer, blend it with another pixel and finally write it again into the buffer. Where the other pixel comes from, being it a rgb or paletted source, doesn't matter. The essence of resizing is the computation of one new pixel from one or several source pixels. The way how you compute/interpolate the new pixel determines its quality and what you finally do with it, write it directly into a buffer or use it as input for a blending operation, again doesn't matter.
Now, you can nicely chain these operations, but on an essential level they have nothing to do with each other.

Both are weighted interpolation of pixels.

Map 8bpp source pixels to direct colour and resize the image, am I missing something?