2 registered members (Ayumi, 1 invisible),
584
guests, and 1
spider. |
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: What are you working on?
[Re: txesmi]
#475187
11/27/18 08:52
11/27/18 08:52
|
Joined: Mar 2014
Posts: 359
CocaCola
Senior Member
|
Senior Member
Joined: Mar 2014
Posts: 359
|
That ist a smal town or labyrinth editor and a loader, i have make from weekend to yesturday. it can choose 3 kind of tileds with key_cur button and save/load (key_F8) I have 3 kinds of buildings; house1x1, bigHouse2x2 and street and a simply run script I have make a projektfile with 2 exe files to download. https://www.file-upload.net/download-13405948/T-editor_nov27.cd.zip.html it's the download button without the cloud-pic maby you must klick 2 times on the butten because advertisement
Last edited by CocaCola; 11/27/18 08:55.
|
|
|
Re: What are you working on?
[Re: CocaCola]
#475340
12/02/18 19:48
12/02/18 19:48
|
Joined: Mar 2014
Posts: 359
CocaCola
Senior Member
|
Senior Member
Joined: Mar 2014
Posts: 359
|
|
|
|
Re: What are you working on?
[Re: CocaCola]
#475355
12/03/18 23:04
12/03/18 23:04
|
Joined: Apr 2002
Posts: 1,246 ny
jumpman
Serious User
|
Serious User
Joined: Apr 2002
Posts: 1,246
ny
|
@Hellthunder Thank you! I love your magma shader! Ello is awesome! Will your magma be solid or liquid? @CocaCola very cool! Will you make it randomly generated? Here's the latest on what I've been working on, PARTICLE SHADOWSI've made emulated particles cast and receive shadows! Each emulated particle samples the depth render view for soft edges. There is a particle camera that only has emulated particles rendered (each of these particles is the child of the particle view genius). In this view the particles are shaded with a depth shader like the shadow camera view. Then all the relevant shaders combine the depth check of their normal shadow camera, with the particle camera. I've hard coded all particles to have a fixed transparency for their shadow. The water shader can now receive particle shadows at the surface, and the translucent view (what you see through the water but also distorted by the water's normal map). So you can place particles or objects, and there will be a shadow at the water surface, as well as on the bottom of the water floor, since the transparency camera uses the same shadow calculation!
|
|
|
Re: What are you working on?
[Re: jumpman]
#475391
12/05/18 21:11
12/05/18 21:11
|
Joined: May 2009
Posts: 5,370 Caucasus
3run
Senior Expert
|
Senior Expert
Joined: May 2009
Posts: 5,370
Caucasus
|
@jumpman your shaders skills are getting more and more impressive with each post! I'm currently working on a floodfill pathfinding algorithm (thanks to Superku, in the past he poked me in the right direction with arrays) Here is a video on my youtube channel (click screenshot to redirect) Edit2: newer version arrived Same, here is a video (click screenshot to redirect) Edit: I got 1000 function calls (it's called recursion I guess?) to find a path on an empty 4096 tile map (64x64 - from upper left edge to lowest right edge), what do you think about this results? Is it really too slow for this kind of pathfinding, share your thoughts please. Best regards!
Last edited by 3run; 12/06/18 14:44.
|
|
|
Re: What are you working on?
[Re: 3run]
#475405
12/06/18 18:38
12/06/18 18:38
|
Joined: Mar 2014
Posts: 359
CocaCola
Senior Member
|
Senior Member
Joined: Mar 2014
Posts: 359
|
|
|
|
Re: What are you working on?
[Re: 3run]
#475407
12/06/18 20:57
12/06/18 20:57
|
Joined: Jun 2007
Posts: 1,337 Hiporope and its pain
txesmi
Serious User
|
Serious User
Joined: Jun 2007
Posts: 1,337
Hiporope and its pain
|
@3run As a recursive function, it seems like it must be. I saw your function stats leap some ms on the video. Too bad. You will probably need to cut it in some frames or somehow enshort the process. Do you use pointer offsets instead of array coordinates? It can speed up things a lot. There is a way of speeding up short paths but unfortunatelly it is more expensive on long paths. It consists on a list of candidates, where you include new candidates as last member in the list and you take the first in the list, one by one, in order to analyze and add its neighborhood to the candidates list. This way the algorithm checks the cells sorted by the count of steps to the end, so it only runs until it finds the ending point, flooding up only the cells closer than the shortest path length. All this stuff can perfectly fit in a single function. Another way of saving some cycles is to save the direction of the incoming neighbor into the cell struct, so with an offset array like the following:
int cellOffsets[7] = {1, ARRAY_WIDTH, -1, -ARRAY_WIDTH, 1, ARRAY_WIDTH, -1};
you can totally avoid the cell the flood came from. Same for the subsequent path-finding process. It is just a little bost but every cycle takes into account on hard processes.
void recursive(CELL *_c){
int _i = _c->incomingDirection + 1;
int _iLast = _i + 3;
for(; _i<_iLast; _i+=1) {
CELL *_cT = _c + *(cellOffsets + _i);
...
|
|
|
Re: What are you working on?
[Re: txesmi]
#475408
12/06/18 21:09
12/06/18 21:09
|
Joined: May 2009
Posts: 5,370 Caucasus
3run
Senior Expert
|
Senior Expert
Joined: May 2009
Posts: 5,370
Caucasus
|
Hey txesmi! I saw your function stats leap some ms on the video. Too bad. Could this be caused by calling 'draw_text' for each tile? I use it for debugging purpose... Without it f.e. fnc ms goes down to 0.3 from ~8 I'm using something like this - array[tile_size * i + j]. Not sure if it's called an array coordinates (I don't know about offset either unfortunately, you code above is over of my dumb head :< ), or not, but this is the way I access the tiles that I need. I don't use any lists at all right now. To find the shortest path (just found out that it's called Lee algorithm), I simple check all surrounding nodes (tiles) starting from B to A (from finish to start) and increasing each node's (tile's) price by 1 (no G, H, F costs, only one price/cost per tile). So finish node has price of 0, then all surrounding nodes have price 1, then all surrounding nodes around those surrounding nodes have price of 2 etc, till start node is found. Walls and already checked nodes (with price != -1) are ignored. At the point when start node was found, I stop all flood_fill functions and trace back the path, by going from the highest price number to lowest (got this algorithm idea from one of those maze solving mouse robotic videos on youtube). This works pretty well, but it seems to be too slow... Also I got an advice from MasterQ32 to avoid using recursive functions and to take a look into dijkstra algorithm.. It's better to use lists for such stuff, but I will need to implement list usage by myself in Acknex, and that sucks. :< Edit: for those who are interested, here is something very interesting to play with https://qiao.github.io/PathFinding.js/visual/Best regards!
|
|
|
Re: What are you working on?
[Re: 3run]
#475412
12/06/18 22:56
12/06/18 22:56
|
Joined: Jun 2007
Posts: 1,337 Hiporope and its pain
txesmi
Serious User
|
Serious User
Joined: Jun 2007
Posts: 1,337
Hiporope and its pain
|
Could this be caused by calling 'draw_text' for each tile? I use it for debugging purpose... Without it f.e. fnc ms goes down to 0.3 from ~8 grin Sure those constant 7/8 ms is the drawing function, but I meant when you click to solve, it grows to more than 10 caused by the flood I guess, but I can be wrong. You don't really need a list implementation. Two pointers and a linking member into the struct is enough. Here goes a fast and untested implementation of the flood. I was too lazy to build the canvas xP
typedef struct CELL {
int depth; // <0 = wall, 0 = unvisited, >0 = visited
struct CELL *parent;
struct CELL *next;
} CELL;
CELL cells[4096];
BOOL flood(CELL *_cStart, CELL *_cEnd) {
int cellOffsets[4] = {1, 64, -1, -64};
CELL *_cListFirst = _cEnd; // candidate list
CELL *_cListLast = _cEnd; // at the beginning it only contains the ending point
_cEnd->depth = 1; // starting depth
_cEnd->next = NULL; // clean the linker
_cEnd->parent = NULL; // clean the parent
while(_cListFirst != NULL) {
CELL *_c = _cListFirst; // take the first member of the candidates list
_cListFirst = _c->next; // remove it from the list
int _newDepth = _c->depth + 1;
int *_off = cellOffsets;
int *_offLast = _off + 4;
for(; _off<_offLast; _off+=1) { // 4 directions loop
CELL *_cT = _c + *_off; // get the neighbor
if(_cT->depth != 0) // it is a wall or already visited
continue;
_cT->depth = _newDepth; // set the depth
_cT->parent = _c; // set the parent
_cT->next = NULL; // clean the linker
if (_cT == _cStart) // end when the starting point is reached
return TRUE;
// include into the candidates list
if(!_cListFirst) { // if there are no candidates in the list
_cListFirst = _cT;
_cListLast = _cT;
} else { // otherway, set as the last member in the list
_cListLast->next = _cT;
_cListLast = _cT;
}
}
}
return FALSE;
}
As you can see, it is pretty short and, let me praise, the path is solved by the chain built by the parent member.
Last edited by txesmi; 12/06/18 23:47. Reason: little change
|
|
|
|