Infinite size
-
@tmo97 (View Post)
I did some benchmarks. On my computer, the slowdown was about 3%. Then I tested it on my server, and it was sped up by 2.7%?? Anyway, inconclusive results which makes me think that the change I made about 2 years ago might have fixed it, or the previous benchmark was wrong. Or I mixed up the files? I don't think I mixed them up ...
So now it just comes down to the work required to do it. Which is still a lot ... for the benchmark I didn't even do it correctly at all. All the major variables like pmap and bmap are still using the constant. If we made size variable, we'd have to destroy and allocate new memory for all of those. Not really any overhead for that every frame, but still a lot of rewriting work to be done.
Then all the interfaces would have to be updated to work with larger sizes. Or they could just center on the screen with black on the edges. TPT looks really bad if you change the constants in the source, because so much code just doesn't expect them to be changed ever.
Then we'd have to figure out saving. We can't just not have any saves at all, otherwise what would be the point. The save format should work fine with alternate sizes, but then you'd have to deal with resizing the game when loading certain saves. That might cause issues, especially with things like double scale mode. Alternate size saves definitely wouldn't be allowed on the server without a lot of server size code.
So it is still a ton of work, and throws out the assumptions present in the code since forever. And i'm still not too positive on the idea anyway ... I wouldn't want to do a ton of work only to have issues with the design / handling of it to come up later. -
You can still save files on your own PC even if they aren't compatible with the server. Remember the ctrl-save option that lets you save to your own PC. I'd like a 1024x768 playing field. I know the devs don't plan to change the default size. And you don't have to. Just provide 2 text boxes in the settings menu that let you type in your own width and height of the playing field.
-
@Videogamer555 (View Post)
Have you read the thread? Especially that post right before yours.
It isn't possible because of how the game engine works to make size modifiable at runtime. It has to be set at compile time. -
That's because you currently use constants for the game size. It would be easy enough to change a constant into a variable.
Instead this code for example "constant int MyVar = 640" you could use "int MyVar = 640". This now creates the variable and initializes it with a default value, instead of creating a constant with its value permanently set. This would then open up the possibility to use the settings menu to set the width and height of the playing field. -
@Videogamer555 (View Post)
It is NOT that simple.
screen size is a #define in a header file somewhere, all of the game state variables use this at compile time to determine how large they are. None of this can be changed at all during runtime. It would require redoing all of the variables that handle game state to allocate memory for themselves at runtime. -
i independantly came up with this idea also
Edited once by Minecrafter777. Last: 20th Nov 2016 -
I don't think this is an absolutely good idea as this would lag most computers and powder would just continuosly fall until the game session has ended.
-
we could make that particles or waves or etc will be freezed after entering 2 pixels of that chunk to only continue them if that specific chunk is loaded by the screen. we could make this an option for users to toggle if they have lag problems with the chunking system. beefy computers could just handle it. and infinite is impossible but we could limit it to a 16 x16 (or less) chunk field.
about the saving:
only save currently rendered chunk and not all of them
Edited 2 times by Tapmemer. Last: 20th Mar 2017 -
