Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Thread interaction with new map data structure in java
57 views
Skip to first unread message
numeron...@gmail.com
May 9, 2012, 9:58:44 PM5/9/12
to
Hello all!
Ive been doing some refactoring on the engine I used to build Nightfall and The Man in the Mirror to make it somewhat more memory efficient. Ive just about finished moving from a tile object per tile system to layered byte arrays. This is great because it cut down my memory usage from 130+ bytes per tile to just 6... It was certainly a long time coming. Anyway, I am additionally taking the opportunity to look at making everything threadsafe in anticipation of being able to switch to real-time and multiplayer, and use worker threads to perform paralell operations all over the map.
Since Im using java, my threads synchronize by locking objects, so considering Im no longer using Tile objects, this makes things a bit challenging. In particular, java doesnt seem to provide any way to create an array of volatile bytes (note the SharedByteArray object is based on AtomicIntegerArray which uses an array of ints). I could synchronize the entire arrays as I use them, but I fear that would remove much of the benefit of using threads in the first place.
Is there a good way to accomplish a tile lock in my new system or should I switch back to tile object per tile system? Due to some of the improvements not needing to be reverted, a quick calculation puts my new projected Tile object at 24 or 32 bytes (depending whether 32 or 64 bit system). Using SharedByteArrays takes up 24 bytes per tile anyway.
What is your advice RGRD?
-Numeron
Ive been doing some refactoring on the engine I used to build Nightfall and The Man in the Mirror to make it somewhat more memory efficient. Ive just about finished moving from a tile object per tile system to layered byte arrays. This is great because it cut down my memory usage from 130+ bytes per tile to just 6... It was certainly a long time coming. Anyway, I am additionally taking the opportunity to look at making everything threadsafe in anticipation of being able to switch to real-time and multiplayer, and use worker threads to perform paralell operations all over the map.
Since Im using java, my threads synchronize by locking objects, so considering Im no longer using Tile objects, this makes things a bit challenging. In particular, java doesnt seem to provide any way to create an array of volatile bytes (note the SharedByteArray object is based on AtomicIntegerArray which uses an array of ints). I could synchronize the entire arrays as I use them, but I fear that would remove much of the benefit of using threads in the first place.
Is there a good way to accomplish a tile lock in my new system or should I switch back to tile object per tile system? Due to some of the improvements not needing to be reverted, a quick calculation puts my new projected Tile object at 24 or 32 bytes (depending whether 32 or 64 bit system). Using SharedByteArrays takes up 24 bytes per tile anyway.
What is your advice RGRD?
-Numeron
Julio Sepia
May 10, 2012, 1:52:36 AM5/10/12
to
On 9 mayo, 21:58, numeronreac...@gmail.com wrote:
> Since Im using java, my threads synchronize by locking objects, so considering Im no longer using Tile objects, this makes things a bit challenging. In particular, java doesnt seem to provide any way to create an array of volatile bytes (note the SharedByteArray object is based on AtomicIntegerArray which uses an array of ints). I could synchronize the entire arrays as I use them, but I fear that would remove much of the benefit of using threads in the first place.
>
> Is there a good way to accomplish a tile lock in my new system or should I switch back to tile object per tile system? Due to some of the improvements not needing to be reverted, a quick calculation puts my new projected Tile object at 24 or 32 bytes (depending whether 32 or 64 bit system). Using SharedByteArrays takes up 24 bytes per tile anyway.
How about splitting the big map arrays into small zones? For example,
> Since Im using java, my threads synchronize by locking objects, so considering Im no longer using Tile objects, this makes things a bit challenging. In particular, java doesnt seem to provide any way to create an array of volatile bytes (note the SharedByteArray object is based on AtomicIntegerArray which uses an array of ints). I could synchronize the entire arrays as I use them, but I fear that would remove much of the benefit of using threads in the first place.
>
> Is there a good way to accomplish a tile lock in my new system or should I switch back to tile object per tile system? Due to some of the improvements not needing to be reverted, a quick calculation puts my new projected Tile object at 24 or 32 bytes (depending whether 32 or 64 bit system). Using SharedByteArrays takes up 24 bytes per tile anyway.
if your map size is 80x20, you could implement each map as an array of
16x4 zones, each zone holding 5x5 tiles. That way you don't have to
lock/sync the entire map, just the individual zones that changed. The
memory overhead would be one pointer per zone, most likely less than
if you used Tile objects.
Krice
May 10, 2012, 6:03:33 AM5/10/12
to
On 10 touko, 04:58, numeronreac...@gmail.com wrote:
> but I fear that would remove much of the benefit of using threads in the first place.
What is the use of threads in turn-based(?) roguelike game?
> but I fear that would remove much of the benefit of using threads in the first place.
numeron...@gmail.com
May 10, 2012, 6:48:43 AM5/10/12
to
> > [...] in anticipation of being able to switch to real-time and
> > multiplayer [...]
I plan to focus on multiplayer games from here on out and adhering to the genre for the sake of it is a low priority. So whether this means single player turn-based dungeons with an MMO-like common world where anyone can take turns when they want, or full real time with smooth movement Im not really sure yet... I just want to learn something different.
One way or another I hope to at least keep it capable of turn-based play since I dont really want to make a smooth-movement 7drl.
-Numeron
numeron...@gmail.com
May 10, 2012, 6:49:26 AM5/10/12
to
On Thursday, 10 May 2012 15:22:36 UTC+9:30, Julio Sepia wrote:
> How about splitting the big map arrays into small zones? For example,
> if your map size is 80x20, you could implement each map as an array of
> 16x4 zones, each zone holding 5x5 tiles. That way you don't have to
> lock/sync the entire map, just the individual zones that changed. The
> memory overhead would be one pointer per zone, most likely less than
> if you used Tile objects.
Thanks, I'll think about this.
> How about splitting the big map arrays into small zones? For example,
> if your map size is 80x20, you could implement each map as an array of
> 16x4 zones, each zone holding 5x5 tiles. That way you don't have to
> lock/sync the entire map, just the individual zones that changed. The
> memory overhead would be one pointer per zone, most likely less than
> if you used Tile objects.
-Numeron
0 new messages