I need to save/load a single zone as quickly as possible. A zone may have up to 500x500 tiles representing the terrain. Initially I was emitting XML for each tile and that was dog slow...

Now I'm investigating java.nio.* and I'm converging on serialization an array of 500x500x4 bytes in a ByteBuffer. Most likely I'll keep the in-memory representation of the terrain the same as what's on disk.

My questions: is java.nio the way to go? Any other thoughts surrounding this technique?

Using ANY binary format should drastically (and that's likely to be a big understatement) reduce the memory you need to move across slow buses and to/from a very slow device, so I wouldn't knock myself out with added solutions until you know where that gets you.

If you're planning on serializing a raw chunk of memory to disk, just go all the way and use a MappedByteBuffer

Riven showed me once a nice example using MappedByteBuffer, it might be helpful.

I searched the forum for a bit, to see what you were referring too. The only occasion where we talked about it, I showed you an example of mapping 200GB worth of data into a List<MappedByteBuffer>, which isn't very useful in this case.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I hadn't seen that one before. I don't have the time at the moment to add it, but the jvm-serializers project has many contributors and is run by committee. If you push a fork on github that adds it, it would pulled (or merged or whatever the hell the git nerds arbitrarily decided to call things :p).

Thanks guys. After refactoring my terrain data to be stored in a ByteBuffer and using java.nio for serialization I was able to cut the loading time of 500x500 tiles from 30 sec to under a second. File size is much smaller too.

I may look into compression later on but I'm happy with the performance now and gzip'ing a data file reduces it down to about 1/3 the size.

I may look into compression later on but I'm happy with the performance now and gzip'ing a data file reduces it down to about 1/3 the size.

Its 30x better. If you weren't happy with the performance now I'd stop by to give you a good kick to the bum.

Ah someone that took the plunge and actually uses Scala to do game dev. Might I pose a quick off-topic question and ask you what your experience is? Does it take away effort or is it more of the same using Java (the language)?

Might I pose a quick off-topic question and ask you what your experience is? Does it take away effort or is it more of the same using Java (the language)?

I've been using Scala for about a year and a half now. My IDE is IntelliJ combined with the Scala plugin. I'm really liking the language. At a minimum it's less verbose than Java but it allows you to use Java packages seamlessly.

The harder part is wrapping my head around functional programming and making the most of the various language constructs. Took me about 8 months and taking a course by the Artima group before it really started to click.

How would you rate this setup compared to eclipse for java? One of the reasons I sticked with java is the tools, and I still think Eclipse for java pretty much rocks. I'm interested in Scala though, but I wouldn't want to invest too much into it if the tools are not up there yet or if it is sort of an esoteric dead end.

As an example: I've invested a lot of time in Groovy after a big corporate push where I work, but in the end I found that it didn't help me at all. The tools pretty much sucked, and Groovy (even though it has some nice things) mostly seemed like smaller code was its main goal at the expense of conciseness, performance, and focus about what a language should be. It just seemed like a confused java knock-off with bad performance and some nice features that are implemented better in other languages.Scala as a language seems to be much nicer though.

The IDE tooling for Scala has some pretty awful bugs in both IDEs that support it (Eclipse and IDEA). Eclipse's support seems to be evolving at a much faster rate than the IDEA plugin, but when it breaks, it breaks eclipse-style, by popping up errors, requiring reloads, that sort of thing, whereas with IDEA it's more polished and much more occasional with breakage, only annoyances like pasting into the project always coming out as java and not scala.

Feature-wise they seem to be mostly at parity, both of them can do things like hilight implicit conversions and navigate to implicits in scope. IDEA of course has a richer set of inspections. Compiling on both still sucks, but IDEA has better fsc integration. I'd still recommend just keeping a terminal window running sbt ~compile though (but eclipse does horribly unless you recompile now and then). Both of them will occasionally red-line perfectly good code, and while you'd think Eclipse would do a better job since it uses the actual scala compiler, it sometimes baffingly redlines almost entire files for no reason til you force a recompile, whereas with IDEA it's more a matter of the inference in the type-aware hilighting being weak (and that's steadily improving).

You definitely have to like the language enough to get over the crappy tooling.

As an example: I've invested a lot of time in Groovy after a big corporate push where I work, but in the end I found that it didn't help me at all. The tools pretty much sucked, and Groovy (even though it has some nice things) mostly seemed like smaller code was its main goal at the expense of conciseness, performance, and focus about what a language should be. It just seemed like a confused java knock-off with bad performance and some nice features that are implemented better in other languages.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org