Linked by Thom Holwerda on Mon 17th Jun 2013 17:52 UTC
Games "MineAssemble is a tiny bootable Minecraft clone written partly in x86 assembly. I made it first and foremost because a university assignment required me to implement a game in assembly for a computer systems course. Because I had never implemented anything more complex than a 'Hello World' bootloader before, I decided I wanted to learn about writing my own kernel code at the same time. Note that the goal of this project was not to write highly efficient hand-optimized assembly code, but rather to have fun and write code that balances readability and speed. This is primarily accomplished by proper commenting and consistent code structuring." Just cool.
Thread beginning with comment 564888
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by aligatro
by Sykobee on Tue 18th Jun 2013 08:43 UTC in reply to "RE: Comment by aligatro"
Sykobee
Member since:
2013-06-18

Each block in Minecraft can take 4 bytes.

The Minecraft world is 256 blocks high by default, and thousands of blocks wide and high (and that extends as required).

So, for a small map, you could have 4096x4096x256x4 bytes used up just for map data. That's 17179869184 bytes - or 16,384MB to you or me. A lot of this is paged out to disk, but I think you can now see why Minecraft can use 1GB without breaking a sweat. And don't you have 4-16 GB in your system anyway?

Think before you comment next time.

Reply Parent Score: 3

RE[3]: Comment by aligatro
by Alfman on Tue 18th Jun 2013 16:40 in reply to "RE[2]: Comment by aligatro"
Alfman Member since:
2011-01-28

Sykobee,

"So, for a small map, you could have 4096x4096x256x4 bytes used up just for map data. That's 17179869184 bytes - or 16,384MB to you or me. A lot of this is paged out to disk, but I think you can now see why Minecraft can use 1GB without breaking a sweat. And don't you have 4-16 GB in your system anyway?"

"Think before you comment next time."

This is exactly the kind of mentality that was different. Older software developers didn't give up when the limited computing resources made problems non-trivial to solve. No, they were far more creative in finding ways to optimize the memory and cpu utilization to make it work. They couldn't take things for granted the way we do today.

Reply Parent Score: 2

RE[4]: Comment by aligatro
by Alfman on Tue 18th Jun 2013 19:48 in reply to "RE[3]: Comment by aligatro"
Alfman Member since:
2011-01-28

Why was this downvoted? That there are programmers who don't even consider the possibility that there may be more efficient ways to use data than in it's raw form is disappointing, at least to me.

I'm not saying optimization is a high priority these days, quite the opposite it's often easier and cheaper to to use the most trivial approach enabled by the hardware at our disposal. But it's still no reason take a close minded approach to what's possible with very clever software algorithms running on less capable hardware than what we are used to.

Reply Parent Score: 2

RE[4]: Comment by aligatro
by Neolander on Tue 18th Jun 2013 20:47 in reply to "RE[3]: Comment by aligatro"
Neolander Member since:
2010-03-08

Actually, in this specific case, Elder Scroll games have shown for decades how large game maps can be used without excessive RAM usage. Simply put:
* Take a huge world map
* Slice it into smaller chunks
* Only keep the current chunk and its nearest neighbours in memory
* Profit !

I would be surprised if Minecraft didn't do something similar on the inside, keeping the whole world map loaded all the time sounds like a needlessly inefficient way to go about it.

Edited 2013-06-18 20:48 UTC

Reply Parent Score: 3

RE[4]: Comment by aligatro
by zima on Wed 19th Jun 2013 12:18 in reply to "RE[3]: Comment by aligatro"
zima Member since:
2005-07-06

This is exactly the kind of mentality that was different. Older software developers didn't give up when the limited computing resources made problems non-trivial to solve. No, they were far more creative in finding ways to optimize the memory and cpu utilization to make it work. They couldn't take things for granted the way we do today.

OTOH "older software developers" gave us something so stupid as y2k bug, so you're probably looking at the past through rose-tinted glasses, a bit.

Software was also notoriously more unstable in general.

Reply Parent Score: 2