Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

That's right

That is right

[winner]

pixel sprites are easy, you just define the platonic image that you are looking for and then make a genetic algorithm that keeps changing pixels until it looks like what you want.

[CobaltKobold]

If there's one thing I'd want added to Stonesense- that's it.

Ladies, gentlemen, and others: The Cavalier Crusader!

I can't say I didn't think the exact same thing, but still... be nice.  It's not like it would be bad for Stonesense to have that capability, all other things being equal.

Now now, I'm generally nice. I 'ust wanted to share my amusement with the world. I'm not trying to knock down his suggestion or insult him.

To prove this I shall determine what changes needed to implement his tileset, at the least. (True custom shapes would be much harder, custom tilesize should be easy, swapping a global variable read on start from the files for the current TILEWIDTH #define)

*ponders briefly what needs changing* Draw order, location, tilesize are really it from the back end. . . I don't like how the blocks draw themselves and determine all about it.

draws all tiles sorted by z, then x, then y.

if you had stated that more clearly...ah

    for(int32_t vsz=viewedSegment->z; vsz < vszmax; vsz++){
      for(int32_t vsx=viewedSegment->x; vsx < vsxmax; vsx++){
          for(int32_t vsy=viewedSegment->y; vsy < vsymax; vsy++){

That would need a swapping for cavalier if Mayday's to get his wide graphics. It shouldn't otherwise matter which way, as it's symmetric in the current angle.

Spoiler: coderant (click to show/hide)

...grrr. This is being hard to find. That calls block.draw...which determines where it draws by void correctBlockForSegmetOffset, which doesn't hint nicely where it is...turns out to be in common.h/main.cpp...argh you made the anti-escher code nontogglable and hardcoded to 3/4 in block. Among other things.

No wait that isn't it at all where is it saying where to draw the block that's the only thing that should need changing ARGH

Code: [Select]

    if(waterlevel == 7) waterlevel--; //ARGH so you're not using one sprite? Ah it's pointToScreen...where's that? Aha, GUI.cpp. First one that makes any sense.

Code: (pointToScreen) [Select]

void pointToScreen(int *inx, int *iny, int inz){
  static int offx = config.screenWidth / 2;
  static int offy = 50;
  if( config.lift_segment_offscreen ) offy = -200;
int x=*inx, y=*iny, z=inz;
x = (int) (x-0.5*(x+y));
y = (int) (0.5*(x+y));
x+=offx;
y+=offy;
y-=z;

*inx=x;*iny=y;
}...there are five separate getsprite functions. Why are there five separate getsprite functions.

Changes needed:

• Split TILEWIDTH to TILEWIDTH and TILEHEIGHT. well, for frontwise cavalier, also seems to be a TILEHEIGHT already..
• Add CAVALIER/TILESHAPE:CAVALIER option flag somehow to init
• Add the ability to pick your spritesheet filenames(init easiest)
• Also the ability to pick the xml files indicating what's what (Want to be easy to switch, not a matter of swapping out all the config files.)
• Change the anti-Escher line bits to not trigger on Cavalier
• *optional* add top-edge anti-escher linedraw for Cavalier
• add a cavalier-style pointToScreen/surrounding code in Block.cpp
• Casual inspection doesn't suggest it's necessary, but check all those drawx/drawy to see what else may be dependant on the projection angle.

Spoiler: "relevant stuff in block.cpp" (click to show/hide)

   correctBlockForSegmetOffset( drawx, drawy, drawz);
   drawx *= TILEWIDTH;
   drawy *= TILEWIDTH;
   pointToScreen((int*)&drawx, (int*)&drawy, drawz * WALLHEIGHT);
   drawx -= TILEWIDTH>>1;

Spoiler: "pointToScreenCavalier" (click to show/hide)

...Okay, this is for a frontwise Cavalier, rather than the rotated 45. Whoops.

Code: [Select]

void pointToScreenCavalier(int *inx, int *iny, int inz){
  static int offx = 25;
  static int offy = 25; //should these be configurable?
  if( config.lift_segment_offscreen ) offy = -200;
int x=*inx, y=*iny, z=inz;
x = x;
y = y;
x+=offx;
y+=offy;
y-=z;

*inx=x;*iny=y;
}

...hmm. Okay, something's screwed up here to me.Your pointToScreen is going by apparently halves, which would support Mayday's proposed tiles, except going up a Z is HALF a tile.

When I wrote my script to convert basically spritesheets to isometric projections (working with Sol's tileset initially) the y got turned into TILESIZE*((x+y)/4). Here it's being assigned /2.  where's the other /2? I can't find it, but I know it's gotta be somewhere...or things would NOT be displaying right. Dev-guys, please?

Time to go do some noncode for a while.

[Dante]

I tried resizing the existing camels so they were at least bigger than the cat, but failed, so I did some from scratch.

   

Is 32 pixels the right size?

[1138]

^^Ooh, nice camels.

I've been making some sprites for myself. My creatures.png looks like this now.

Some of these still need a lot of work.

[Dante]

Oh, I was just about to try my hand at grizzly bears. Now I don't have to inflict that on the world 

My current fortress is full of tame alligators, which show up as beautiful flurries of purple question marks everywhere, so I added this as a better placeholder



Also cows

         

[kaypy]

I tried resizing the existing camels so they were at least bigger than the cat, but failed, so I did some from scratch.

   

Is 32 pixels the right size?

I've added a size template to the wiki at http://code.google.com/p/stonesense/wiki/Sprites

[Innominate]

For an isometric view the draw order should be back-to-front distance-wise, from the bottom floor upwards.
Something like:

Code: [Select]

  1 
 2 3
4 5 6
 7 8
  9
Assuming (4, 2, 1) is x=0, (7, 5, 3) is x=1, (4, 7, 9) is y=0, (2, 5, 8 ) is y=1, etc.
Then this is rough pseudocode for a diagonal iteration:

Code: [Select]

for(int z=0 -> zRange){
    //first half - in diagram, only (1), (2,3), and (4,5,6) rows
    for(int row=0 -> yRange){
        for(int col=0 -> min(xRange,row)){
            drawCell(col,(yRange-row)+col,z);
        }
    }
    //second half - in diagram, only (7,8), and (9) rows
    for(int row=1 -> xRange){
        for(int col=0 -> min(yRange,xRange-row)){
            drawCell(row+col,col,z);
        }
    }
}Note that <axis>Range is equivalent to the difference in indices between the bounds on that axis.

[CobaltKobold]

This is true, but not entirely necessary, if the sprites all fit in the cube right.
If they do, then Painter's Algorithm only need to have each one drawn after the ones behind it, and aside from that weak ordering, anything works, which is why presently it's

Code: [Select]

  1
 4 2
7 5 3
 8 6
  9and things work.

[Impaler[WrG]]

With a little modification you can use that same code to draw from each of the four compass points which would be a great enhancement.

[CobaltKobold]

If you're using simple things yes. Unfortunately directional crap means a few more changes necessary, but still pretty easy.

...hmm...I think I see a problem. Do ramps render incorrectly if they're at the edge of your viewed segment, because they 'forget' about the stuff out of view?

[Rooster]

Hey people! I'm trying my forces in isometric pixelart



How do you like it? It's actually done for my rpgmaker project, but when I'll do more then I guess they could be usable in stonesense cause they're compatible.

[Mike Mayday]

If there's one thing I'd want added to Stonesense- that's it.

Ladies, gentlemen, and others: The Cavalier Crusader!

I can't say I didn't think the exact same thing, but still... be nice.

It's ok, I LedOL

The blue rectangle (and the automatically calculated way the tile "rectangles" overlap) is actually all that the visualizer should care about for a single layer view- and it should be customizable.

You messed up there- your mockup has the top edges of tiles obscured.

Ah yes, of course. This is what I actually meant.
So Stonsense places the rectangles (32x16 in this case), and it's up to the creator to fill them with properly shaped sprites.

I like it! And guys, see how the grass crawls "out" of the tile? This is one of the reasons why I propose getting rid of the shape constraint. Nice job, Kogucie

[kaypy]

The blue rectangle (and the automatically calculated way the tile "rectangles" overlap) is actually all that the visualizer should care about for a single layer view- and it should be customizable.

You messed up there- your mockup has the top edges of tiles obscured.

Ah yes, of course. This is what I actually meant.

Isn't that exactly the same as the old one?

[Mike Mayday]

Isn't that exactly the same as the old one?

Nope. The rectangle is 32x16 in the latter.

[kaypy]

Nope. The rectangle is 32x16 in the latter.

Ah, I see. The gap is included in the box