To browser these website, it's necessary to store cookies on your computer.
The cookies contain no personal information, they are required for program control.
  the storage of cookies while browsing this website, on Login and Register.

Author Topic:  Unity 2D client  (Read 2289 times)

0 Members and 1 Guest are viewing this topic.


« on: 06, February 2020, 11:42:58 »
Yeah, the new client is still a work in progress. ATM there is no support for lighting (which AFAIK is how the obstructsview works) so it should look roughly the same when it's closer to finished.

Something I've considered is a way of doing smoother/dynamic lighting. At the very least, finding a way to smooth transitions between different light levels so it's not perfectly blocky. IIRC you did something fancy with lighting a long time ago that never made it to release so if you have any tips I'd appreciate it.

Yep, I spent  a while pondering 'smooth' lighting. I couldn't get my head round the math, unsurprisingly, but I think the outline id this:

server sends a 22x22 'light map' as well as the 17x17 object map (22 = 17 + 5 [IIRC the max light source is 9x9 so half of this dismeter])/ The light map includes the central squares and brightness of the actual light sources (we don't send brighttbess per square as now).

Client draws object map (as now but no lighting effects). Then oberlay this with circles of light of appropriate brightness and radius according to light map. Then overlay this with pure black squares where player can't see (as per object map).

I think this should give a nice enough approximation of reality. I don't think SDL (even 2) can do this sort of thing, but Unity?

(It's not so simple as 'overlaying circles of light'. Maybe make a big 22x22 diamond of darkness at the ambient light level, the cut out duitsble circles centered on light sources, then overlay this.

My next thought was multivoloured light...

FoW is  a v cool effect. IIRC the code still exists but is disabled in current client (I hhad FoW in SECoND).

But anyway, lighting is one of my favourite effects and quite undeveloped in Dai.

EDIT: Not 22z22, but 27x27 so 17x17 is centered with a border of 5 on all sides.


« Reply #1 on: 07, February 2020, 10:55:46 »
What's the deal with arches for _people_s client? Are they just bigger?If so there's a pottential problem in that the server/client can't send/receive data above a certain size. This came up with a detailed ship Joe made years ago (I began looking in to a fix but...) So if the image is already in the client's local face pack, BP. But if it must be fetched from the server and has (IIRC) a >32 bit crc then we get garbage.

A solution is maybe chop up such images into multiple packages at send then reassemble them after receipt.


« Reply #2 on: 07, February 2020, 14:50:11 »
Yes I also mentioned this to People and he came up with a work around.  Mainly doing this because a larger resolution is a big step forward, getting away from 800x600 is good.  Also this challenge I've gotten myself into seems so impossible to finish, that I just couldn't resist trying it. ;)
Whoever said "Out of sight, out of mind" never had a spider disappear in their bedroom.


« Reply #3 on: 07, February 2020, 23:32:16 »
So my plan for storing faces is essentially to entirely change how the client retrieves arches. The game server will no longer be involved with faces (and eventually anims). I'd like to have a "data server" which handles this.

Essentially, the client maintains a "facepack version" - just a simple incrementing variable in a text file. The "data server" has a database of every version of the facepack, and every new version will have an xdelta diff from the previous version.

So if you have facepack version 35, and the dataserver has version 40, download the last 5 changes and apply them to your facepack. Then set the client's facepack version to 40.

I plan to do this during initial server connection, so the client will never have to deal with the ugly "LOAD" icons whenever Joe decides to update half our graphics :) I also would like to have at least 2 data servers (one for EU and one for NA) so that clients can pick whichever has lower ping. I think this, combined with the lower overhead on the actual gameserver, warrants having an extra server or 2. I can front the cost of these servers.

There are obviously some nuances here which will need to be resolved - such as players running local servers, or perhaps a dev server with different graphics than the main server. People running local servers might just have to suck it up and use gfx_user whenever they want to change graphics.
-- _people_ :)


« Reply #4 on: 08, February 2020, 10:01:37 »
sounds good, but...

part of the reason (i would think) for "LOAD" is we only fetch updated gfx when they're needed. in theory this means smaller downloads per client and fewer bw bottlenecks for the server.

Example: Joe updates all the raas, lom, vh, and skel dragon faces. Under current scheme these are fetched as needed as each playeer progresses through DT (yes, lots of "LOAD" which I agree is horrid). Under your scheme EVERY client fetches ALL new gfx at connection, eveb, eg, when the player is new and the gfx won't be relevant for many weeks.


« Reply #5 on: 14, February 2020, 20:13:49 »
I've just updated the download for the demo with my progress so far. Significant changes include adding a server select screen (though it doesn't seem to like Main server), line of sight works now (to include Fog of War), lighting, and movement (mouse needs work, keyboard uses arrow keys for now).

Double-height faces (ie walls) are temporarily disabled as I need to rewrite them to be much more performant. As in the previous build, exiting is not yet implemented so use Alt+F4 to close the program.

Download can be found at:

Soon I plan  to add some documentation and put the source on Sourceforge.
-- _people_ :)


« Reply #6 on: 14, February 2020, 21:43:22 »
Happy to see you still working on this, it gives me motivation to keep going with the updated graphics. 

Edit:  Did get some sort of error trying to run it.
« Last Edit: 14, February 2020, 21:55:23 by Joe »
Whoever said "Out of sight, out of mind" never had a spider disappear in their bedroom.


« Reply #7 on: 15, February 2020, 02:02:49 »
Try the link again. I just removed a lighting plugin I was experimenting with (it's not right for our use case). IDK if that's what's causing the false positive but as we don't need it, it's worth removing. I also built it as a release version rather than development so that might help.

If that doesn't work I'll have to try Avast myself and see what's causing it to flag.
-- _people_ :)


« Reply #8 on: 15, February 2020, 02:10:03 »
Yup that fixed it, cheers.

Wow I really like this!  Having the directional buttons use arrows is really nice, and holding 2 directions results in an angle is how it should work.  Well done, I would use this instead of mouse any day.
« Last Edit: 15, February 2020, 09:32:06 by Joe »
Whoever said "Out of sight, out of mind" never had a spider disappear in their bedroom.


« Reply #9 on: 15, February 2020, 12:46:20 »
Wow I really like this!  Having the directional buttons use arrows is really nice, and holding 2 directions results in an angle is how it should work.  Well done, I would use this instead of mouse any day.

Never thought of this. IIRC SDL can't detect simultaneous keypresses (except for modifierd like ctrl, shift, alt). But can unity (and am i wrong about sdl)?


« Reply #10 on: 15, February 2020, 16:40:41 »
Yep, Unity handles it fine. IDK about SDL but I'd imagine you could probably hack together a solution for it. Under the hood, Unity converts anything mapped as a "direction input" to a vector, which also means controller support works almost out of the box (on a 64-bit build, it's broken on 32-bit for now). Although playing around with it, analog stick movement doesn't seem to be a very good fit for Daimonin.
-- _people_ :)


« Reply #11 on: 21, February 2020, 04:33:33 »
I need a way to keep the client always in day light.  The new client is very awesome for testing, but once it gets dark I can no longer test.  :'(  Also it must be something better than having to type /dm_light every time I log in (if possible).  Thanks!

« Last Edit: 21, February 2020, 04:38:26 by Joe »
Whoever said "Out of sight, out of mind" never had a spider disappear in their bedroom.


« Reply #12 on: 21, February 2020, 09:09:22 »
You can use /set_map_light to set the map's brightness higher for as long as the map is loaded in memory.

I did notice that lighting isn't very good ATM. In the version you have, it's actually inverted - so areas around light sources appear darker. I've fixed this locally.

Additionally, while fixing bugs I did notice that the darkest setting is very nearly pure black. That's a problem, because the server already doesn't send the client squares which are supposed to be pitch-black. I'll update darkness to be a bit more visible next release.

As a side note, those graphics are looking really good! :)
-- _people_ :)


« Reply #13 on: 21, February 2020, 13:11:42 »
Speaking of which...

SDL client tweaks the light values it receives to fit its 7 darkness levels.

Which is unnecessary as server has already done this.

In any case, possibly down the line server will send actual brightness (0-1023 IIRC) which client then converts to its alpha (0-255) [or whatever Unity needs].


« Reply #14 on: 23, February 2020, 08:14:39 »
Having some trouble with the floor layers.  They don't seem to quite line up right.  Here are the patterns I'm using, if I go 1 pixel larger for the scale it overlaps.  So yea I'm not quite sure what to do for this.

Whoever said "Out of sight, out of mind" never had a spider disappear in their bedroom.


Related Topics

  Subject / Started by Replies Last post
0 Replies
Last post 26, July 2005, 05:17:58
by Grahf
5 Replies
Last post 15, July 2006, 18:21:46
by longir
5 Replies
Last post 07, August 2007, 05:41:23
by bugbunny
33 Replies
Last post 31, May 2011, 13:32:25
by clobber
0 Replies
Last post 22, July 2013, 03:34:19
by _people_