Messages

196

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 17, 2019, 05:05:04 pm »

I want 2.5D engine, not 3D engine :>
I not even try implement drawing triangles. Simply biting 2D sprites with depth (that can be implemented as two normal surfaces but one is not treated as color but as depth).

Where will you get the depth surface? 3d software generates it together with sprite? I remember there was some zombie-shooter game demo, where artists hand-drawn such z-surface onto each pixelart sprite, so dynamic light would highlight these sprite properly from any angle. A ton of work, and I havent heard about them since then. Guess their project is dead. And as I said with just z-buffer you will still get wrong draw order like: https://www.youtube.com/watch?v=BJYH-UrQ2xs
That guy solved it with two zbuffers, one for draw order, another the usual depth buffer. I solved it with topologically linking objects in a tree of what occludes what, but did that locally and only for specific units. I'm not using zbuffer now (although I had it in the first version), instead just sorting by x,y,z towards frustum.

https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/Globe.cpp#L987
https://github.com/Yankes/OpenXcom/blob/master/src/Geoscape/Globe.cpp#L175
This is shading I spoke before, each pixel have predefined normal vector and based on this I calculate sun shading on globe.
And everything still 8bit.

XCOM globe is an actual 3d object, so you get normal vectors for free with it.

197

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 16, 2019, 04:24:51 pm »

You missed one important aspect, EVERY pixel have depth, this mean destination and source too. If unit clip it should look like it dive into water.
And performance will not be very bad, OXC already do half of work that I image will be needed. Overall my idea how it will work is based on my work on OXC.
I already use some custom surfaces to make some special effects, like globe illumination using normal vectors. All done in software.

Triangle rasterizing code is much slower than a direct blit, even if you optimize it with SSE. For each sprite you will have to project 4 vertices, draw 2 triangles, interpolating Z and UV across them. Here is the bare minimum to implement OpenGL-like triangle drawing in software:

Code: [Select]

static void draw_span(lerp *l, int y, int x, int end_x) {
typedef unsigned short fixcol;
#define fix(x) ((fixcol)(signed short)((x)*0xffff))
#define unfix(x) ((float)(x)/(0xffff))

int tt[640];
memset(tt, 0, 4*640);

// color layout: AAAA|RRRR|GGGG|BBBB

Uint16 mm0[4];
mm0[3] = fix(A(l));
mm0[2] = fix(R(l));
mm0[1] = fix(G(l));
mm0[0] = fix(B(l));

Uint16 mm1[4];
mm1[3] = fix(AD(l));
mm1[2] = fix(RD(l));
mm1[1] = fix(GD(l));
mm1[0] = fix(BD(l));

Uint16 mm2[4];
mm2[3] = fix(0.0); // ambient color shouldn't affect alpha
mm2[2] = fix(ambient_r);
mm2[1] = fix(ambient_g);
mm2[0] = fix(ambient_b);

// uv layout: 0000|0000|VVVV|UUUU
Uint16 mm6[4], uv_delta[4], uv_wh[4], uv_bp[4];

mm6[0] = fix(U(l));
mm6[1] = fix(V(l));
mm6[2] = 0;
mm6[3] = 0;

uv_delta[0] = fix(UD(l));
uv_delta[1] = fix(VD(l));
uv_delta[2] = 0;
uv_delta[3] = 0;

uv_wh[0] = texture->w-1;
uv_wh[1] = texture->h-1;
uv_wh[2] = 0;
uv_wh[3] = 0;

uv_bp[0] = texture->format->BytesPerPixel;
uv_bp[1] = texture->pitch;
uv_bp[2] = 0;
uv_bp[3] = 0;

fixcol one[4] = {0xffff, 0xffff, 0xffff, 0xffff};
float z = Z(l);
float zd = ZD(l);

Uint8 *dst = (Uint8*)screen->pixels + y*screen->pitch +
x*screen->format->BytesPerPixel;

// now we have following arrangements:
// EAX is temporary
// EBX points to zbuffer
// ECX is used for debugging
// EDX holds final location in screen buffer
// ESI points to texture
// EDI points to screen buffer
// MM0 holds light color
// MM1 holds delta for light color
// MM2 holds ambient
// MM3 holds resulting color between stages
// MM4 is temporary
// MM5 is temporary
// MM6 holds uv
// MM7 holds 0
// XMM6 holds Z
// XMM7 holds Z Delta
// others are unsed
// MMX code assumes that botch: screen and textrue are in BGRA format
asm (
"movq %0,%%mm0\n\t"
"movq %1,%%mm1\n\t"
"movq %2,%%mm2\n\t"
"movq %3,%%mm6\n\t"
"pxor %%mm7,%%mm7\n\t" // mm7 = 0

"movss %8,%%xmm6\n\t" // z
"movss %9,%%xmm7\n\t" // zd

"jmp loop_start\n\t"

"loop_body:\n\t"

// Z-BUFFER TEST
"test $1, %%ecx\n\t"
"jz skip_ztest\n\t"
"movss (%%ebx), %%xmm5\n\t"
"cmpss $2, %%xmm6, %%xmm5\n\t" // xmm5 <= xmm6
"movd %%xmm5, %%eax\n\t"
"test %%eax, %%eax\n\t"
"jz loop_advance\n\t"
"movss %%xmm6, (%%ebx)\n\t" // save new z-value of this pixel
"skip_ztest:\n\t"

// TEXTURE MAPPING (mm3 holds result)
"movq %%mm6,%%mm3\n\t" // mm3 = uv
"pmulhuw %5,%%mm3\n\t" // mm3 = u*w, v*h
"pand %5,%%mm3\n\t" // mm3 = (u*w)%w,(u*h)%h : wrap
"pmaddwd %7,%%mm3\n\t" // mm3 = linesz*vh+colorsz*uw
"movd %%mm3,%%eax\n\t"
"movd (%%eax,%%esi),%%mm3\n\t" // mm3 = packed_texture
"punpcklbw %%mm7,%%mm3\n\t" // mm3 = texture

// LIGHTS (mm3 holds result)
"test $2, %%ecx\n\t"
//"jz skip_lights\n\t"
"movq %%mm0,%%mm4\n\t" // mm4 = light
"pmulhuw %%mm3,%%mm4\n\t" // mm4 = light*texture
"pmulhuw %%mm2,%%mm3\n\t" // mm3 = ambient*texture
"paddusb %%mm4,%%mm3\n\t" // mm3 = (light + ambient)*texture
"skip_lights:\n\t"

// BLENDING (mm3 holds result)
"test $4, %%ecx\n\t"
"jz skip_blending\n\t"
"pshufw $0xff,%%mm3,%%mm4\n\t" // mm4 = src_alpha
"psllw $8,%%mm4\n\t" // convert mm4 to fixed point
"pmulhuw %%mm4,%%mm3\n\t" // mm3 = src*src_alpha
"movq %6,%%mm5\n\t" // mm5 = 1
"psubw %%mm4,%%mm5\n\t" // mm5 = 1-src_alpha
"movd (%%edi),%%mm4\n\t" // mm4 = dst_packed
"punpcklbw %%mm7,%%mm4\n\t" // mm4 = dst
"pmulhuw %%mm5,%%mm4\n\t" // mm4 = dst*(1-src_alpha)
"paddw %%mm4,%%mm3\n\t" // mm3 = src*src_alpha + dst*(1-src_alpha)
"skip_blending:\n\t"

// ENDING
"packuswb %%mm7,%%mm3\n\t" // pack pixel in mm3...
"movd %%mm3,(%%edi)\n\t" // and puti it to final resting place

// ADVANCE
"loop_advance:\n\t"
"paddw %%mm1,%%mm0\n\t" // advance light
"paddw %4,%%mm6\n\t" // advance uv
"addss %%xmm7,%%xmm6\n\t" // advance z
"add $4,%%edi\n\t" // advance x
"add $4,%%ebx\n\t"

// LOOP CONTROL
"loop_start:\n\t"
"cmp %%edx,%%edi\n\t"
"jl loop_body\n\t" // jmp if edi < edx

"emms\n\t" // reset FPU after MMX
:
:
"m" (*mm0), // 0
"m" (*mm1), // 1
"m" (*mm2), // 2
"m" (*mm6), // 3
"m" (*uv_delta), // 4
"m" (*uv_wh), // 5
"m" (*one), // 6
"m" (*uv_bp), // 7
"m" (z), // 8
"m" (zd), // 9
"c" (flags), // ecx
"b" (zbuffer+y*screen->w+x), "d" (dst+(end_x-x)*4),  "D" (dst), "S" (texture->pixels)
);
}


198

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 15, 2019, 01:52:04 am »

I for long time think amount 2.5D graphic engine. This mean that each screen pixel have not only color but depth too. With something like this drawing order will be only secondary thing. You will check for each pixel you draw if you it behind or on front of background pixel.

That is called z-buffering. It is slower than draw-order sorting and doesn't solve the problem of higher layer popping through the layer below, or floor in front of a sprite cutting legs off large characters (that is why XCOM tanks are split into several cubes). Here is an example from Daimonin of what happens with naive approach (notice the cut off dragon legs and the poor botched wurm)


To solve the problem you need actual 3d transformations,  and mapping each sprite as texture to a polygon. I actually tried doing it in software and it is orders of magnitude slower than topological sort. Although Ultima Online did it somehow in 90ies. I.e. it needs OpenGL, which requires 32bit textures in precise 512x512 pages, forcing to pack all graphics into such pages, which requires writing very tricky packing algorithms. In addition OpenGL doesn't support paletted textures, so no way to recolor units or do color cycling, so you need write a lot of tricky shaders to support that. And you will still need to sort transparent surfaces, which is especially nasty, when most of your sprites have some transparency. It is also harder to control 3d polygons. For example, same cell may have a pebbles sprite, a unit standing on top of said pebbles, a weapon that unit is holding and some effect, like explosion or fire over that unit. These elements should be drawn in that precise order, it would be silly if weapon gets drawn before the unit.

So yeah, OpenGL and any 3d brings in more problems than it solves. And of course say good bye to portability, because each graphics card does something differently.

199

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 12, 2019, 12:06:59 am »

Ok. Resized the tree to match the game proportions, and drawn another fir tree. These trees are a bit out of angle, and it can be fixed by scaling it by Y and adding a few backside slopes to branches, but that wont really make it look better - pure isometry is little bit too boring.

Also, in case of XCOM and Magic & Mayhem engine trees, the lower branches would be occluding the stuff on the ground, like the corn. While graphically correct, that isn't really a good thing, because occluded thing can be say an important key, fallen out of a dead monster, and because occlusion requires properly shading the object below (bright corn under branches will look incorrect).

200

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 10, 2019, 11:48:34 pm »

Another tricky design decision: how to implement floating islands. The most robust way appears to be implementing special floating property for tiles. That way it could also be associated with some control structure, allowing it to move in 6 directions, maybe even landing and crushing units below. It would be near impossible to implement even a remotely challenging dueling AI in this setting (given that we still struggle to implement competitive AI for Starcraft), therefore such maps should be kept to XCOM style exploration, puzzles or multiplayer. Although I've plans implementing dueling AI, like in Magic & Mayhem, but on simpler arena maps, and giving AI some bonus, like several lives and more spells.

For now I've redrawn a public domain fir tree: https://opengameart.org/content/pine-tree-16x16

I dislike drawing, but not getting away from it, when there are no suitable free assets.

201

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 10, 2019, 12:27:54 am »

Very nice game Nikita, I like it so far.
Will you make a Russian localization for it one day?

The programming language I use doesn't support unicode.

202

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 09, 2019, 02:55:54 pm »

Some tricky hacks are required to implement even the basic lights in an isometric engine. But lights are a must in a game heavily focused on magic and throwing fireballs, which would look very bland as static sprites.

Although the basic formula is very simple:

Code: [Select]

lighten T E = T + T*E/Factorwhere T is the texture's light receptiveness, and E is the light's energy. Of course you need to apply that formula to each of the RGB components, unless you have the stylish black & white soviet TV. I heard they still use B&W TVs in Russia

Alas I never got why applying light is multiplication, not addition. Guess that is some complicated physics shit with typical square law.

That guy from Stencil forum actually raytraced lights: http://community.stencyl.com/index.php/topic,41034.450.html

surprisingly his code is efficient enough to run even in browser, although slowly. At that level you can just use completely raycast engine. Then again, even my hacky code uses some degenerate form of raycasting. There just no going around traversing space, when you need to draw lights.

203

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 08, 2019, 09:34:38 pm »

Another feature - colored lights for various effects. It is probably possible to ray-trace sun's position and shade terrain behind walls.

204

Offtopic / Another Classic Game Got Reverse Engineered

« on: April 06, 2019, 10:23:44 pm »

This time it is Magic Carpet:
https://github.com/turican0/remc2/wiki

Like most games of its time it was way ahead of its time 

205

Resources / Re: One Stop Shop for Sprite Rips :)

« on: April 05, 2019, 09:30:08 pm »

Dominus. It is a PC game, but for some reason the graphics was in planar format reminiscent of Amiga. Guess it wasn't originally a PC game, because ti my knowledge no PC graphic adapter ever supported planar graphics.

206

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 02, 2019, 05:51:52 pm »

XCOM like Fantasy game which came out two years before XCOM, but I bet you never ever heard of it:
https://www.mobygames.com/game/four-crystals-of-trazere
>Armies of mutants are marauding through the land and it's up to the heroes to scour the cities, dungeons, and wilderness looking for clues to the source of the evil. The party moves from location to location on a strategic map avoiding (or ambushing) enemy patrols and armies while trying to find the clues and items they need in isometric dungeons and cities. The game also features an intricate magic system that lets players design and customize spells.

The game has very involved magic system, where player can adjust spell area of effect, time and range. I.e. instead of a single shot dispel cast, player can have a dispel field, removing enchantment from creatures entering it. Really neat concept although hard to balance and implement properly. I had an idea of refactoring spells into such system, after getting over with the basic game.

207

Offtopic / Re: XCOM Inspired Fantasy Game

« on: April 01, 2019, 07:23:01 pm »

Implemented halved tiles. When designing an isometric engine, there are numerous decisions one has to make:
1. Will the engine allow truly 3d world without hacks? Like i.e. room over room.
2. Would the game world be cell-based, continuous or combine both approaches?
3. For cell based worlds, one has to pick unit-sized cell. Like i.e. 32x32x32 cube of 1x1x1 voxels.
4. What would be the cell format? Are walls going to be embedded into tile as well as floor or use separate tiles?

For example,
1. Magic & Mayhem has cell based world, but uses 32x32x16 cells. That approach is simple and robust, but requires splitting everything into such very small tiles or use some ad-hoc hacks for topologicaly sorting larger tiles, so they won't be ovedrawn with tiles behind
2. Original XCOM uses 16x16x16 cells and embed walls and floor into these cells, making it very involved to say trace a bullet path, while walls look really thin and units cramped into walls. Now cels can block vision from one side, while allowing to see from another.  Such approach also greatly impedes dynamic effects, like water flows. XCOM also allows fatter walls, further complicating engine. Yet it is very efficient, because it greatly cheapens topological sorting and extends map size, because walls are stored as part of cell and sorted with it.
3. Furcadia uses approach similar to XCOM, but walls can have any height, yet they still look very thin.
4. Ultima 8 and Faery Tale 2 use continuous world approach with cell sized tiles.
5. Final Fantasy Tactics allows only varying floor height. Many similar games are lazily implemented by making each tile type into a long pilar, which is just moved up or down to accommodate for height, instead of introducing proper tiling and draw order sorting.
6. Diablo have just floor and objects on top of that floor. The simplest type of isometric game to make.
7. Stronghold used some very complex approach, basically splitting every building into very small cubes, supposedly automatically. All these crenelations on towers properly obscured units. One of the more complex isometric game engines. Still unsure how the implemented pathfinding.

Anyway, picking base cell size doesn't really limit tile size, with some hacks one can implement finer 16x16x16 tiles in 32x32x32 engine.

208

Resources / Re: One Stop Shop for Sprite Rips :)

« on: March 30, 2019, 01:25:02 pm »

Anime style sprites from an online game:

https://ufile.io/ly56y

These are really huge for pixelart with many frames of animation, probably drawn with the help of 3d models, but still a lot of work. Not something you will see in a typical indie game. Makes you think that a work hour of an artist costs zero to nothing in a "developing country".

209

Resources / Re: One Stop Shop for Sprite Rips :)

« on: March 27, 2019, 04:42:26 pm »

Dark Seal 2: Wizard Fire sprites
https://ufile.io/b8b4s

I've ripped these manually long time ago, using a hacked emulator. I've decrypted the video memory pages, but the algorithm to assemble them into the actually sprites was a bit too involved, requiring reverse engineering like half of the game. So a lot of stuff is missing, because it doesn't appear in the game.

210

Resources / Re: One Stop Shop for Sprite Rips :)

« on: March 27, 2019, 04:23:21 pm »

Nice work Nikita

I managed to extract some scourge hive stuff but the ones I found don't fit into the OXC dimensions.

Yeah. OXC engine is severely limited.