Re: [glob2-devel] globulation graphic

[dryad]

> If you provide us with the graphics, adapting the code is easy. We
> probably
> need a single layer for "low-quality" graphics, for people that use the
> software renderer.

k, we can generate bothm i'll send it in 2 days cause tomorrow i got lesson^^

>> 4 the area borders should have a lower alpha.

> Do you mean the same colors with alpha? Which percentage of alpha would
> you
> like to? It is very to change in the code :-)

do you prefer values to be calculated in bytes or in floats? (just cause
when i do my graphic calculation i usually make reference scales, so if
you use floats I can use that ones)

> Do you have a suggestions for this? Such as always taking a different tile
> then
> the one at top and at right?

exactly but not top and right. each kind of tile has it's own proximity
check to do. it s maximum 4 checks, but u do it just once anyway and it
improves the graphical looking a lot. i ll send u the list of the squares
to check according to the kind of tile

>> tile incidence, to add "special tiles" to the map less times than
>> "common
>> tiles" based on a 0-7x70% 8-11x20 12-15x10% for both 16 grass and 16
>> sand tiles

16 is ok

>> 6 (i know this one is weird) fix the pixel lines of the areas so it s
>> drawn
>> only in the inner side of the box (if you notice, there is a pixel
>> glitch^^)
>
k i ll send it

> The is interesting. So you would like to have the same amount of frame for
> miniresources then for the unit? Here as well, if you provide us with the
> graphics we can very easily to adapt the code. In general, the graphics
> code
> is easy to change, because you can quickly see the result :-)

well ye but it requires an unit reworking too, dont know if you would like
new units... i personally like these ones even if i thought about other
kinds too. the only thing i would strictly change is to make warriors a
bit more different than the workers


> That is a nice proposal. If you provide us with the graphics, we can adapt
> the
> code.

k i ll make a couple of tries about it


> Actually there is different frames for the building but they show the
> level of
> destruction. We can change this and add support for animations in the
> normal
> frames and support for destruction by appending some -destruction to the
> sprite name. Or we can do as you propose, by alternating between two
> slightly
> different hue. What do the other people think?

they got time to think anyway^^ we should define the buildings first^^

>> 14 (maybe needed) add a percentage based building reference png, like at
>> least 0% and 50% (even for buildings that builds at once, just for
>> further
>> improvements)
>
> I do not understand, we already have frame for buildings in progress. It
> is
> named: BUILDINGNAME|LEVEL|c|FRAME_NUMBER.png (substitute the words in
> captial
> with actual words and remove the | to get the final filename).

it's like 2 or more building frames

> Well, this is a problem if the frames have a different sizes. However, for
> images of all the same size, we can add support for this in addition to
> the
> normal ones. If you provide us with images of this type, that is, with a
> single line of frames (not a 2D grid, it adds complexity) of all the same
> width, we can imagine to write the width in the filename and let the image
> loader do the cut.

mmm why can't u load from a 2D grid giving as a reference the
x,y,widht,height and number of frames to pick?
for the unit walk-rotation would be really nice to use this system
easy to handle and to correct.

> That would mean a big change in the engine. I do not see how to do it
> easily
> with the current engine. Adding the number of frame is easier to do.

but well, if you want to switch to 3D or introduce some kind of reanged or
area of effect units/attack this change should be required