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 3484 times)

0 Members and 1 Guest are viewing this topic.


« Reply #45 on: 25, April 2020, 03:27:33 »
OK, so I have good news and bad news.

Good news: I have updated Gridarta to work with our high-res graphics. You can find it at:

Simply overwrite the old editor/DaimoninEditor.jar with this one.

Bad news: Gridarta is exhibiting the same alignment issues I'm seeing in the Unity client. I originally thought it would be a code bug but now I'm wondering if this is because of the dimensions of the new tiles. Old tiles were 48x23 while the new ones are 96x46.

Could it be that the height MUST be an odd number? I don't really know much about isometric projection. I'll do some experimenting tomorrow, but I'm afraid the solution may be to either add or remove 1px to/from the height of the tiles.
-- _people_ :)


« Reply #46 on: 25, April 2020, 11:14:55 »
I'm prob not the right guy to help with numbers. ;)

Is Ragnor still king of G? Maybe ask him (and get your changes as an official part of the project)?


« Reply #47 on: 07, May 2020, 14:24:00 »
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.

Perhaps have a user option. Either (1) Download every new/updated face from server as and when 'seen' (ie, as now) or (2) \download only new faces in this way and updates set a flag. When the flag is set the client will remind the player that updates are available; player can do a one-off full update whenever he wants before login.

So (2) is the default (means no LOAD) but individuals can always go (1) if being bleeding edge is more important to them.


« Reply #48 on: 07, May 2020, 23:42:55 »
I think that's a good way of handling this. I think I'll leave it using the old method until I can get the client to a releasable state so I don't get sidetracked.
-- _people_ :)


« Reply #49 on: 18, October 2020, 22:25:47 »
how have u handled offsets for multis with diff size imgs? do u have 2 archdef.dats or calc the offsets at runtime?


« Reply #50 on: 18, October 2020, 22:47:50 »
Unfortunately that's something I've been putting off for quite some time. I've never been very familiar with multipart arches and without any special handling they look "good enough" that I haven't worked my way back to it.
-- _people_ :)


« Reply #51 on: 19, October 2020, 11:40:51 »
ok. tbh im <100% convinced the mpart_id/nr + archdef.dat stuff is implemented quite right, or even the way to [continue to] go at all. But the SDL client and (AFAict) gridarta use it. hm...


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_