Jump to content




MiniatureCraft 2.x Alpha Edition

game

368 replies to this topic

#41 Lignum

  • Members
  • 558 posts

Posted 15 February 2015 - 08:00 PM

View PostDetective_Smith, on 15 February 2015 - 05:54 PM, said:

Kinda looks ugly, but basically it works like this:
Each number represents a tile. So the number "50" is actually the ID for grass. However, if there is a ":", that means that there is a block on top of the tile. For example, 56:4 would mean that the asset id of 4 is on top of the asset id of 56. I'm not sure how I could get the saves to be any smaller. Other small things, such as the player data, is just saved as a serialized table, taking less than a kilobyte. However, even the smallest worlds (64x64) take up huge amounts of space. The one I just finished generating is around 7/10 the game's size itself (Which is around 112kb atm) and the largest worls (128x128) are nearly three times as large as the game itself. You mentioned something about a binary format. It would be interesting to know if this could help be a solution to making small saves. I'm just not exactly sure how it would work doing so.
You can further cut down the file size by merging repeating tiles into one. E.g: 50|50|50|50|50 becomes 50x5. In addition that, here's some documentation on binary mode. You should switch to that, it'll spare you the separators.

View PostDetective_Smith, on 15 February 2015 - 05:54 PM, said:

It's just the amount of data that needs to be sent over repeatedly. The world, the players, and the entities, all of which you can probably guess have plenty of data tied to them, need to be sent over to the client at a moments notice. Now, serializing the whole world works, but takes quite a few seconds, even on CClite. So, the way I plan to do it, is to copy parts of the world table (The ones necessary for the client) and then serialize it. I haven't tried it yet, but as you imagine, the server could get rather resource intensive pretty quickly. For now, I'm still steadily working on the game's release, but I'll return to the server afterward.
I suggest that you send the whole world to the clients when they connect. After that only send block changes. As for entities, do the same, send all of them at once and after that only send the new information when something has changed. I'm currently working on a game where I do this and it's worked very well so far.

#42 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 15 February 2015 - 10:29 PM

You could use my package API to compress the content before writing it to the drive. Using your own reduction techniques on top of this - eg, the RLE method suggested by Lignum - is still definitely worthwhile. Heck, just the RLE will likely solve your problems.

#43 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 15 February 2015 - 10:54 PM

That's actually pretty clever.
Essentially, binary format let's you work with binary. Each character has eight spaces for either a 1 or a 0. This means there are 64 unique patterns possible in one byte.
However, you could run into issues with having more than 64 different item types. A possible solution I just thought of is writing 2 bytes per pixel, giving a whopping 256 unique possibilities per pixel. This would mean a 1 character reduction per pixel, and 156 more types in 2 bytes.
If you want, I'll upload a beta of game-engine(the file format is finished) in which you can fork my saving from. It works like this: 4 bytes are reserved for which color the pixel is, then the other 4 are Boolean. For new y & x values, there's a certain pattern inserted, so it leaves you with 62 possible patterns per byte. This being said, you could specify the pixel is brown, and that it's type 1 per say, and it knows that brown type 1 is a log.
theorigninalbit helped me greatly in creating this save format, you can also talk to him.

Edited by Geforce Fan, 15 February 2015 - 10:58 PM.


#44 Lignum

  • Members
  • 558 posts

Posted 15 February 2015 - 11:10 PM

View PostGeforce Fan, on 15 February 2015 - 10:54 PM, said:

...
You only need one byte for 256 possibilities. 1 byte = 8 bits -> 2^8 = 256.
If you're using the first 4 bits for the ID, you're left with 2^4 (16) possibilities. So, in this case either more bits should be used or the additional data should be left out completely since the IDs appear to be quite big. Since the existing format doesn't seem to store any additional data, I suppose it's not needed anyway.

#45 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 15 February 2015 - 11:27 PM

View PostLignum, on 15 February 2015 - 11:10 PM, said:

View PostGeforce Fan, on 15 February 2015 - 10:54 PM, said:

...
You only need one byte for 256 possibilities. 1 byte = 8 bits -> 2^8 = 256.
If you're using the first 4 bits for the ID, you're left with 2^4 (16) possibilities. So, in this case either more bits should be used or the additional data should be left out completely since the IDs appear to be quite big. Since the existing format doesn't seem to store any additional data, I suppose it's not needed anyway.
8^2 = 8*8 = 64.
8^2 ~= 256
1 byte has 64 possibilities.
https://duckduckgo.c...=ffab&ia=answer
powers explained:
http://www.purplemat...es/exponent.htm

Edited by Geforce Fan, 15 February 2015 - 11:32 PM.


#46 MKlegoman357

  • Members
  • 1,170 posts
  • LocationKaunas, Lithuania

Posted 15 February 2015 - 11:37 PM

View PostGeforce Fan, on 15 February 2015 - 11:27 PM, said:

View PostLignum, on 15 February 2015 - 11:10 PM, said:

View PostGeforce Fan, on 15 February 2015 - 10:54 PM, said:

...
You only need one byte for 256 possibilities. 1 byte = 8 bits -> 2^8 = 256.
If you're using the first 4 bits for the ID, you're left with 2^4 (16) possibilities. So, in this case either more bits should be used or the additional data should be left out completely since the IDs appear to be quite big. Since the existing format doesn't seem to store any additional data, I suppose it's not needed anyway.
8^2 = 8*8 = 64.
8^2 ~= 256
1 byte has 64 possibilities.
https://duckduckgo.c...=ffab&ia=answer
powers explained:
http://www.purplemat...es/exponent.htm

It's the other way around: 2^8 = 256; you can read about bytes on the wikipedia:

Quote

Computer memory is designed in a binary architecture, multiples are expressed in powers of 2.


#47 Lignum

  • Members
  • 558 posts

Posted 15 February 2015 - 11:37 PM

View PostGeforce Fan, on 15 February 2015 - 11:27 PM, said:

8^2 = 8*8 = 64.
8^2 ~= 256
1 byte has 64 possibilities.
https://duckduckgo.c...=ffab&ia=answer
powers explained:
http://www.purplemat...es/exponent.htm

And 2^8 ~= 8^2. Take a look at this.
EDIT: Ninja'd

Edited by Lignum, 15 February 2015 - 11:38 PM.


#48 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 16 February 2015 - 12:16 AM

View PostMKlegoman357, on 15 February 2015 - 11:37 PM, said:

....
Posted Image
I'm in advanced math and I made this mistake
Anyhow, this means you would have 256 types per byte. So you could probably just live with 1 byte per character, or 2 characters and you get a ridiculous 65536 types.
If you manage to use up all of those types, then someone give you a medal.
-------
Also, how are you rendering the game right now? It's really laggy on minaturecraft 1.0. You're not going through the ENTIRE map while rending are you? You should only be going through what's going to be on the screen.
Another thing I noticed in the 1.0 topic is that you where looking for a different buffer system. If you havn't yet found one, I recommend Redirect by GopherAtl here: http://www.computerc...irect-ctrlkeys/
It's over 2 years old but its stood the test of time, and still works great today.

Edited by Geforce Fan, 16 February 2015 - 01:30 AM.


#49 Antelux

  • Members
  • 295 posts
  • LocationSomewhere in the middle of nowhere.

Posted 16 February 2015 - 04:09 PM

View PostLignum, on 15 February 2015 - 08:00 PM, said:

You can further cut down the file size by merging repeating tiles into one. E.g: 50|50|50|50|50 becomes 50x5. In addition that, here's some documentation on binary mode. You should switch to that, it'll spare you the separators.

I suggest that you send the whole world to the clients when they connect. After that only send block changes. As for entities, do the same, send all of them at once and after that only send the new information when something has changed. I'm currently working on a game where I do this and it's worked very well so far.

This sounds like a pretty good solution. I'll take a look into.

View PostGeforce Fan, on 16 February 2015 - 12:16 AM, said:

Also, how are you rendering the game right now? It's really laggy on minaturecraft 1.0. You're not going through the ENTIRE map while rending are you? You should only be going through what's going to be on the screen.
Another thing I noticed in the 1.0 topic is that you where looking for a different buffer system. If you havn't yet found one, I recommend Redirect by GopherAtl here: http://www.computerc...irect-ctrlkeys/
It's over 2 years old but its stood the test of time, and still works great today.

No, I'm not rendering the entire map. It's always been what's on screen. Right now, I'm using a string buffer that I made a while back. The old buffer was just a table that mapped out the whole screen. As of now, the game seems to run alright on pocket computers, given you don't spam the event system by holding down a key. On computers, however, it's still rather slow. This is probably due to the game having to process more than before. So, as of now, it's recommended you play on a pocket computer.

However. The game runs extremely fast and well when played on a monitor. I'm not entirely sure why, but if you get one of those keyboard peripherals, the speed of the game shouldn't be a problem at all once you play it on a monitor. This was just tested on the latest stable version of computercraft on minecraft 1.7.10

Edited by Detective_Smith, 16 February 2015 - 04:09 PM.


#50 Lignum

  • Members
  • 558 posts

Posted 16 February 2015 - 04:14 PM

You should try out this buffer, which is designed to be fast. I've never used it before but it looks very promising.

#51 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 17 February 2015 - 04:10 AM

View PostLignum, on 16 February 2015 - 04:14 PM, said:

You should try out this buffer, which is designed to be fast. I've never used it before but it looks very promising.
I highly doubt it's faster than redirect

View PostDetective_Smith, on 16 February 2015 - 04:09 PM, said:

....
That's the issue--it lags if you hold down keys
I released a beta of game-engine here: http://www.computerc...gine-for-games/
If you launch the testgame, you'll notice that holding down keys does not cause lag at all. And honestly, if you turn on trace, you'll see that there's quite a lot of function calls. I don't know how you've gotten it to the point where holding keys lags, but it's definitely an issue and is definitely fixable.

Edited by Lyqyd, 17 February 2015 - 06:18 AM.


#52 Antelux

  • Members
  • 295 posts
  • LocationSomewhere in the middle of nowhere.

Posted 17 February 2015 - 04:59 AM

View PostGeforce Fan, on 17 February 2015 - 04:10 AM, said:

That's the issue--it lags if you hold down keys
I released a beta of game-engine here: http://www.computerc...gine-for-games/
If you launch the testgame, you'll notice that holding down keys does not cause lag at all. And honestly, if you turn on trace, you'll see that there's quite a lot of function calls. I don't know how you've gotten it to the point where holding keys lags, but it's definitely an issue and is definitely fixable.

It's not really an issue. When holding down a key, the event system is spammed as a result. If your program is slowish (Like mine), then it can't update whatever in realtime, causing the computer to still catch up on previous events instead of deal with the current ones. I try to make the processing having to be done when input is given at minimal (A timer updates the world in terms of scripts, the input doesn't). I've considered making a system which filters out spam of keys and alike, but I'll also take a look at your game engine, and see if anything there catches my interest.

As far as the game's buffer goes, I've been experimenting with some other buffers, seeing how they are. I'll get back to you guys on that.

Edited by Detective_Smith, 17 February 2015 - 04:59 AM.


#53 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 17 February 2015 - 05:39 AM

View PostDetective_Smith, on 16 February 2015 - 04:09 PM, said:

However. The game runs extremely fast and well when played on a monitor.

Probably because every time you perform an operation through the regular "term", you're doing it through a window - thanks to multishell. Using an external monitor bypasses all that.

It's possible that you could circumvent this by grabbing term.native() and redirecting to that. I haven't tried it, though. Obviously this would mess up multishell behaviour if it works, but I doubt that's such a great price to pay.

#54 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 17 February 2015 - 10:46 PM

View PostBomb Bloke, on 17 February 2015 - 05:39 AM, said:

....
This is really good advice. I'm actually going to update the test game I made for Game-Engine to do this! The Window API is ridiculously slow.
Kudos to dan2000 for allowing us to bypass it.
Has anyone made a topic about doing this? OSes and games really ought to do this for extra performance. Game-engine runs so much faster!
Not to mention an OS has nothing to loose from this!
Anyhow, I added
term.redirect(term.native())
to the top of miniaturecraft 1.0 and guess what: holding down keys no longer lags it at all. In fact, it goes blazingly fast!
Something to note, though, is the weird delays while moving. It, to my eyes, appears to move 3 or so times, then take a short pause, and move 3 times again. I don't see this in game-engine at all.
Miniaturecraft is actually pretty fun when it's not lagging!
---
Question: What is all the yellow stuff in miniaturecraft?

Edited by Geforce Fan, 17 February 2015 - 11:05 PM.


#55 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 17 February 2015 - 11:41 PM

So the term.native() thing works. Problem is that it really would be quite wonky if people tried to use it alongside multishell's tab system. It's a bit... inelegant.

Better, if possible, to kill multishell with the TLCO, or better yet, to just leave it alone and give the user the choice. Though I've got a vague memory that might not work so well on it (as opposed to against the regular shell), and it wouldn't surprise me if 1.7 squashes it completely.

#56 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 17 February 2015 - 11:47 PM

View PostBomb Bloke, on 17 February 2015 - 11:41 PM, said:

So the term.native() thing works. Problem is that it really would be quite wonky if people tried to use it alongside multishell's tab system. It's a bit... inelegant.

Better, if possible, to kill multishell with the TLCO, or better yet, to just leave it alone and give the user the choice. Though I've got a vague memory that might not work so well on it (as opposed to against the regular shell), and it wouldn't surprise me if 1.7 squashes it completely.
sorry, squashes the top level coroutine hack, or squashes bypassing the window API?

Edited by Geforce Fan, 17 February 2015 - 11:47 PM.


#57 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 17 February 2015 - 11:48 PM

TLCO.

#58 Antelux

  • Members
  • 295 posts
  • LocationSomewhere in the middle of nowhere.

Posted 20 February 2015 - 09:02 PM

Hey guys. Sorry, I've been away from my computer for a bit. Even now, I'm posting from my tablet. I knew the window api did have an effect on the game's performance. However, I never knew it could be bypassed in the way talked about above. That's definitely going to be added to the game for a major speed up. I'll try to finish up some other things once I get on my computer. Though, my birthday is in a few days or so, so I'll probably be caught up in that. Anyway, thanks for your input and suggestions to make the game better. I plan on experimenting with all these, such as the saving in binary and so on. Thanks for being patient too.

Edited by Detective_Smith, 20 February 2015 - 09:02 PM.


#59 MKlegoman357

  • Members
  • 1,170 posts
  • LocationKaunas, Lithuania

Posted 20 February 2015 - 09:20 PM

View PostBomb Bloke, on 17 February 2015 - 11:41 PM, said:

...or better yet, to just leave it alone and give the user the choice...

In other words, make it a setting, whether to redirect to a term.native() or just leave it running in a multishell window.

BTW, happy upcoming birthday! :)

#60 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 20 February 2015 - 10:55 PM

Well, I was more thinking that individual scripts shouldn't try to break multishell, but rather they should rely on the user to eg specifically pre-run a dedicated script for the purpose of performing the break (ideally via TLCO), say via a startup script.

That way if we ever get a "proper" way to disable multishell, there won't be a ton of scripts floating around that need to be tweaked. That said, I doubt thing's'll get too far out of hand if you just take the "easy" route of redirecting to term.native(). It's inelegant, but I'd expect it to work no matter what happens with multishell in the future.

What's this about a birthday? I for one tend to put lots of different birth dates into lots of different sites.





2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users