News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Inconsistent size bounds for map enlargement

Started by ACarlotti, May 13, 2018, 11:59:19 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ACarlotti

I think there is a mistake (which is probably an obscure bug) in the map size limits when enlarging the map. Revision 7116 removed the bound on the product of x and y, in most places it appeared (in enlarging the map, and in world creation), but left it present in one bit of code. The change that I think was intended here is:

diff --git a/gui/enlarge_map_frame_t.cc b/gui/enlarge_map_frame_t.cc
index 1ac21cddb..91c183858 100644
--- a/gui/enlarge_map_frame_t.cc
+++ b/gui/enlarge_map_frame_t.cc
@@ -153,13 +153,13 @@ bool enlarge_map_frame_t::action_triggered( gui_action_creator_t *komp,value_t v
        if(komp==&inp_x_size) {
                sets->set_size_x( v.i );
                inp_x_size.set_increment_mode( v.i>=64 ? (v.i>=512 ? 128 : 64) : 8 );
-               inp_y_size.set_limits( welt->get_size().y, min(32766,16777216/sets->get_size_x()) );
+               inp_y_size.set_limits( welt->get_size().y, 32766 );
                update_preview();
        }
        else if(komp==&inp_y_size) {
                sets->set_size_y( v.i );
                inp_y_size.set_increment_mode( v.i>=64 ? (v.i>=512 ? 128 : 64) : 8 );
-               inp_x_size.set_limits( welt->get_size().x, min(32766,16777216/sets->get_size_y()) );
+               inp_x_size.set_limits( welt->get_size().x, 32766 );
                update_preview();
        }
        else if(komp==&inp_number_of_towns) {


I also have a couple of further questions. Firstly, what was the reason for having this bound on the total area? And secondly, is there likely to be any need for it in Extended if it isn't needed in Standard? I note that when James increased the Extended map size limits last year (having not previously incorporated r7116), he retained an area bound, albeit with an increased value.

TurfIt

removed in the r7116 commit: grund.cc:
// since size_x*size_y < 0x1000000, we have just to shift the high bits
#define get_ground_text_key(k,width) ( ((k).x*(width)+(k).y) + ((k).z << 25) )


That was the reason for the limit - to fit x,y, and z in the 32 bit key;  Now 64 bit key post r7116.
Extended would only still need if it's doing any similar jamming of x,y,z into smaller variables.

---
enlarge routine retaining the limit does seem an oversight...

prissi